Informazioni sulla logica di routing delle chiamate sul Meeting Server

Introduzione

Questo documento descrive la logica di routing delle chiamate di Cisco Meeting Server (CMS) (in precedenza prodotto Acano) suddiviso in diverse tabelle di routing delle chiamate. In questo documento vengono descritte le diverse fasi e gli scenari possibili per le chiamate tramite le tabelle di routing delle chiamate.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Componente Call Bridge di Cisco Meeting Server.

Componenti usati

Le informazioni fornite in questo documento si basano su Cisco Meeting Server versione 2.3.x.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Qual è la logica di routing delle chiamate di Cisco Meeting Server (CMS)?

Il routing delle chiamate sul CMS comporta alcune tabelle diverse di routing delle chiamate. Con il diagramma di flusso scaricabile, è possibile seguire la logica di routing delle chiamate per ogni chiamata che arriva sul CMS. Se non diversamente specificato, questa opzione è valida per tutti i tipi di chiamate: Cisco Meeting App (CMA - thick client o WebRTC), chiamate Standard Session Initiation Protocol (SIP) o chiamate Microsoft SIP.

Nota: l'unica eccezione è rappresentata dalle chiamate avviate da CMS (direttamente da CMS per le chiamate in uscita pianificate di TelePresence Management Suite (TMS) o le chiamate in uscita del client CMA) in cui la tabella di inoltro di chiamata viene ignorata.

Questo è l'ordine del processo di instradamento delle chiamate all'interno del CMS: 

1. Tabella corrispondenza chiamate in arrivo
2. Tabella Inoltro di chiamata in arrivo
3. Tabella chiamate in uscita

Ciascuna tabella viene illustrata in modo più dettagliato più avanti nel documento, che include le immagini che mostrano solo la parte pertinente della .

Nota: il CMS esegue il routing delle chiamate solo in base al routing del dominio, quindi in base alla parte destra (RHS) dell'URI (Uniform Resource Identifier). Non è disponibile una funzionalità di routing delle chiamate basata sul lato sinistro (LHS) dell'URI, come in Cisco Unified Communications Manager (CUCM) con routing DirectoryNumber (Route Patterns).

Nota: ogni tabella è un elenco ordinato impostato dall'attributo di priorità. Maggiore è la priorità, maggiore sarà il numero di tentativi di corrispondenza. Se non corrisponde, procede con la regola successiva nell'elenco. Come regola generale, assegnare una priorità più bassa alle regole più generali (come un * che corrisponde a qualsiasi dominio) rispetto alle regole più specifiche. In questo modo, le regole specifiche vengono gestite per prime e si ha la possibilità di tornare alle regole più generali.

Passaggio 1. Tabella corrispondenza chiamate in arrivo

Questo è il primo passaggio del processo in cui il CMS determina se la chiamata in entrata è destinata al Cisco Meeting Server stesso e deve essere elaborata ulteriormente oppure se si tratta di una chiamata destinata a un sistema diverso in cui il CMS è l'agente che interagisce con la chiamata e gestisce sia i supporti che la segnalazione (ad esempio, chiamate del gateway Skype agli endpoint SIP standard o viceversa).

Verifica se la parte del dominio dell'URI in ingresso corrisponde o meno alla tabella corrispondente in ingresso. Se corrisponde, è possibile instradare la chiamata allo spazio, all'utente, all'IVR o eseguire una ricerca di conferenza Lync (locale o locale) in base alla configurazione per questa regola del dial plan. La tabella non consente i domini con caratteri jolly. È necessaria una corrispondenza completa.

Nota: se non sono configurati domini corrispondenti alle chiamate in arrivo, CMS accetta tutti gli URI in arrivo dalle chiamate SIP o Lync che atterrano sul callbridge. Per i client CMA (WebRTC o thick client) sebbene accetti la chiamata, questa non viene instradata automaticamente allo spazio o all'utente corretto. Pertanto, è importante immettere il dominio corretto quando si utilizza il client CMA per comporre il numero agli spazi o agli utenti in questo caso.

Ad esempio, una tabella di corrispondenza delle chiamate viene mostrata nell'immagine (mostra solo l'opzione Oggetti spazi e Oggetti utenti per brevità):

Qui il dominio è impostato come acano.steven.lab che i client normalmente compongono. Tuttavia, consente anche chiamate ad-hoc o modelli di route SIP specifici da CUCM (o regole di ricerca Expressway) che puntano solo a un callbridge specifico (in caso di cluster) in base alla prima e alla seconda regola di fallback nella tabella che corrispondono all'indirizzo IP del callbridge (in questo caso 10.48.54.160) o al nome di dominio completo (FQDN) del callbridge (in questo caso acano1.acano.steven.lab).

Passaggio 2. Tabella Inoltro di chiamata in arrivo

Se la chiamata non ha raggiunto nessuna delle regole nella tabella di corrispondenza chiamate in arrivo o non è stata trovata alcuna corrispondenza per procedere con la chiamata (ad esempio, l'URI dello spazio non esistente o errato composto dall'utente), la chiamata passa attraverso la seconda tabella denominata tabella di inoltro di chiamata. Questa opzione è basata solo sul dominio e consente di bloccare in modo specifico le chiamate a determinati domini o di consentire in modo specifico solo le chiamate a determinati domini. Se si desidera eseguire questa operazione, è importante disporre di regole più specifiche con una priorità più alta, in modo che vengano controllate per prime.

Nell'esempio viene mostrato come le chiamate a dummy.com vengano rifiutate, mentre quelle a tplab.local vengano inoltrate:

Se si lascia vuota la tabella di inoltro di chiamata, si verifica uno stato in cui il CMS non agisce come gateway tra i partecipanti Skype e SIP, ad esempio perché non esiste alcuna regola di inoltro di chiamata. Nell'ipotesi che il dominio della chiamata in arrivo non corrisponda nella tabella di corrispondenza chiamate in arrivo o il dominio corrisponda ma non ci sia corrispondenza negli spazi, negli utenti o negli IVR (o nelle riunioni Skype), la chiamata non viene inoltrata rispetto alla tabella chiamate in uscita.

Nota: questo accade tuttavia con i client CMA (thick client e WebRTC) in quanto sono in grado di effettuare chiamate in uscita (*Web App nella versione 3.0 non può effettuare chiamate in uscita, ma piuttosto chiamate effettuate dallo spazio CMS in uscita da Callbridge). Analogamente, le chiamate in uscita sul CMS funzionano bene anche quando effettuate tramite API, ad esempio (nel caso di conferenze programmate TMS). In generale, le chiamate avviate dallo stesso CMS (direttamente o tramite CMA) non devono seguire la logica di inoltro delle chiamate.

Nel registro eventi è possibile visualizzare il messaggio di inoltro evidenziato, ad esempio quando CMS funge da gateway per le chiamate SIP e Skype. Subito prima, potete vedere la chiamata in arrivo e la chiamata in uscita dopo.

2018-10-04  06:36:24.612  Info     call 788: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:36:24.624  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@any.com'
2018-10-04  06:36:24.625  Info     call 789: outgoing SIP call to "stejanss@any.com"

Se la tabella di inoltro non include alcuna regola o una regola di rifiuto, il registro eventi non visualizzerà esplicitamente questa condizione. Viene semplicemente indicato che la chiamata SIP non corrisponde (nessuno spazio, utente, IVR o riunione Lync) e che la regola di inoltro (o la regola è impostata su Rifiuto) per lo spostamento nella sezione delle regole in uscita.

2018-10-04  06:47:12.482  Info     call 790: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:47:12.495  Info     call 790: ending; local teardown, destination URI not matched - not connected after 0:00

Per le chiamate dei client CMA o le chiamate in uscita da CMS avviate tramite riunioni pianificate TMS, non viene rilevata alcuna chiamata in ingresso nel registro eventi. La chiamata passa immediatamente alla tabella del dial plan in uscita e non viene elaborata dalla tabella di inoltro di chiamata.

Nella tabella di inoltro di chiamata sono disponibili altre due opzioni di configurazione: Riscrivi dominio e ID chiamante.

Riscrivi dominio

Questa opzione consente di riscrivere il dominio della chiamata in ingresso su un altro dominio e modifica la parte del dominio dell'URI della richiesta SIP nonché l'intestazione To del messaggio SIP.

Ad esempio, con la configurazione su questa immagine, il registro eventi (con la traccia SIP abilitata) viene mostrato qui per una chiamata in entrata con il dominio any.com ma senza una corrispondenza nella tabella di corrispondenza delle chiamate in entrata (su spazi, utenti, IVR o conferenze Skype):

2018-10-04  07:02:24.818  Info     SIP trace: connection 0: incoming SIP TCP data from 10.48.36.215:56457 to 10.48.80.71:5060, size 1000:
2018-10-04  07:02:24.818  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-04  07:02:24.818  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bK53e4c4ce29394
2018-10-04  07:02:24.818  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=742103~ee545a46-516a-4de6-87d7-7b1f5a5b848a-26001856
2018-10-04  07:02:24.818  Info     SIP trace: To: <sip:stejanss@any.com>
..
2018-10-04  07:02:24.822  Info     call 797: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  07:02:24.834  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-04  07:02:24.835  Info     call 798: outgoing SIP call to "stejanss@newany.com"
..
2018-10-04  07:02:24.838  Info     SIP trace: connection 19: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:57854, size 3286:
2018-10-04  07:02:24.838  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-04  07:02:24.838  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bKefc98b81a2961b37aee24f03c2142d8e
2018-10-04  07:02:24.839  Info     SIP trace: Call-ID: 18644f28-e998-4032-a7df-75325e9d11b0
2018-10-04  07:02:24.839  Info     SIP trace: CSeq: 659590315 INVITE
2018-10-04  07:02:24.839  Info     SIP trace: Max-Forwards: 70
2018-10-04  07:02:24.839  Info     SIP trace: Contact: <sip:1060@10.48.80.71;transport=tcp>
2018-10-04  07:02:24.839  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-04  07:02:24.839  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=2aa2a49bba231a1b

In questa linea di chiamata di inoltro, indica la modifica che è stata apportata. Se la traccia SIP non è abilitata, viene comunque visualizzata la modifica di any.com in newany.com.

L'utilizzo più comune di questa riscrittura del dominio viene fornito con un'integrazione Lync locale con un cluster CMS in cui è consigliabile impostare l'intestazione Contatto e l'intestazione Da nelle regole in uscita su Lync/Skype per i nomi di dominio completi (FQDN) specifici del bridge di chiamate. Ciò è dovuto alle seguenti regole di routing:

• Skype invia nuove transazioni all'interno di una finestra di dialogo (come ad esempio una ACK dopo un INVITE - 200 OK) all'intestazione Contact specificata nella 200 OK ricevuta dal CMS. Per le connessioni in entrata da Skype al CMS, Skype invia prima un messaggio NEGOTIATE SIP contenente un'intestazione ms-fe nell'intestazione To che specifica come l'intestazione Contact deve essere compilata nelle 200 risposte OK su INVITE (poiché utilizza lo stesso canale TCP)
• Skype invia nuove finestre di dialogo (come la condivisione del contenuto, in quanto si tratta di una chiamata separata o di una richiamata in caso di chiamata persa) all'intestazione From dell'INVITE originale

Durante la riscrittura del dominio, è rilevante per la richiamata dalle chiamate Lync. L'intestazione Da dell'INVITE mancante indica il callbridge specifico da cui proviene la chiamata. Lync invia quindi una nuova richiesta (INVITE) con l'URI della richiesta SIP corrispondente all'FQDN del callbridge. Viene quindi convertito nel dominio SIP tramite queste regole di riscrittura. Una volta inoltrata, la chiamata utilizza le regole in uscita verso CUCM o Expressway-C in cui è registrato l'endpoint SIP.

ID chiamante

Per le regole di inoltro è possibile impostare due opzioni. È impostata su pass-through e quindi non viene apportata alcuna modifica nell'intestazione From degli INVITE in uscita oppure è impostata su use dial plan che consente al sistema di modificare l'intestazione From in base alle regole in uscita. Questa impostazione è indipendente dal fatto che si disponga di una riscrittura del dominio, in quanto riguarda solo l'URI della richiesta SIP e l'intestazione A dell'invito in uscita.

Ad esempio, è stata effettuata la stessa chiamata di prima ma ora è presente una regola del dial plan in uscita in newany.com (come dopo la riscrittura nella tabella di inoltro di chiamata in arrivo) impostata come chiamata di tipo Lync (ad esempio Ms-Conversation-ID come intestazione SIP aggiuntiva). In modo appropriato, il campo Dominio Da locale (e Dominio contatto locale) viene compilato per puntare all'FQDN del callbridge come indicato in precedenza per le chiamate Lync. Ciò riflette quindi la modifica apportata all'intestazione From e Contact dell'invito SIP in uscita. Come mostrato nell'immagine, sono popolati con lo stesso valore e possono essere selezionati singolarmente in base alle vostre esigenze.

2018-10-12  09:09:24.488  Info     SIP trace: connection 28: incoming SIP TCP data from 10.48.36.215:44460 to 10.48.80.71:5060, size 1000:
2018-10-12  09:09:24.489  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-12  09:09:24.489  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bKf4a230ec178e
2018-10-12  09:09:24.489  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=118288~ee545a46-516a-4de6-87d7-7b1f5a5b848a-32900729
2018-10-12  09:09:24.489  Info     SIP trace: To: <sip:stejanss@any.com>
2018-10-12  09:09:24.489  Info     SIP trace: Call-ID: 81e67f80-bc0164c4-f2c6-d724300a@10.48.36.215

2018-10-12  09:09:24.494  Info     call 803: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-12  09:09:24.506  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-12  09:09:24.507  Info     call 804: outgoing SIP call to "stejanss@newany.com" (Lync)

2018-10-12  09:09:24.507  Info     SIP trace: connection 33: allocated for outgoing connection to 10.48.36.46:5060
2018-10-12  09:09:24.508  Info     SIP trace: connection 33: outgoing connection successful, 10.48.80.71:39782 to 10.48.36.46:5060
2018-10-12  09:09:24.510  Info     SIP trace: connection 33: outgoing SIP TCP data to 10.48.36.46:5060 from 10.48.80.71:39782, size 2971:
2018-10-12  09:09:24.510  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-12  09:09:24.510  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bK15bdde97ab641b586f162187cfdd98b5
2018-10-12  09:09:24.510  Info     SIP trace: Call-ID: c366ddaf-e602-4fa5-b1d6-2e16ec08534a
2018-10-12  09:09:24.510  Info     SIP trace: CSeq: 1498747095 INVITE
2018-10-12  09:09:24.510  Info     SIP trace: Max-Forwards: 70
2018-10-12  09:09:24.510  Info     SIP trace: Contact: <sip:1060@callbridgefqdn.any.com;transport=tcp>
2018-10-12  09:09:24.510  Info     SIP trace: Ms-Conversation-ID: 3P5Hu8grR1GGDF1BSMZAmw==
2018-10-12  09:09:24.510  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-12  09:09:24.510  Info     SIP trace: From: "EX60 Steven" <sip:1060@callbridgefqdn.any.com>;tag=fb4ae780677e9d9b

Se la regola di inoltro viene impostata solo su pass-through, non vi saranno modifiche nell'intestazione From come nell'esempio precedente (in questo caso pass-through è impostato sulla regola di inoltro). L'intestazione Contatto viene sempre adattata quando CMS avvia un nuovo callLeg e pertanto deve aggiungere un'intestazione Contatto a se stessa.

È possibile utilizzare diverse combinazioni di ID chiamante e Dominio contatto locale e Locale da dominio. L'intestazione From sull'intestazione SIP INVITE in uscita è costruita come mostrato nella tabella in cui la chiamata in entrata entra nel CMS con un'intestazione From di usera@from.com.

Passaggio 3. Tabella chiamate in uscita

Questa è l'ultima tabella della logica di routing delle chiamate che invia la chiamata a un altro server come:

• La chiamata in ingresso non è gestita localmente (nel dominio corrispondente alla chiamata in ingresso).
• Si tratta di una chiamata in uscita da uno spazio CMS (tramite CMA o tramite API in caso di riunioni pianificate TMS, ad esempio o una chiamata in uscita con istruzioni Cisco Meeting Manager (CMM)) o da un client CMA.

Dall'immagine, potete vedere che la logica è relativamente semplice. Se nella tabella non è presente alcuna voce, consente comunque le chiamate in uscita, ma presuppone che il server CMS sia in grado di risolvere i record SIP SRV (_sips._tcp / _sip._tcp / _sip._udp) per il dominio specifico, come indicato nell'URI della richiesta SIP. Se la tabella non è vuota, ma non esiste alcuna corrispondenza per il dominio composto, viene eseguita la stessa logica di ricerca DNS. Se nel dominio è presente una corrispondenza, questa segue la logica della regola specifica. A questo proposito, se si desidera bloccare le chiamate in uscita da CMA o effettuate tramite TMS o CMM, è possibile eseguire questa operazione in due modi. Non sono presenti record DNS SRV (o non risolvibili da CMS) oppure instradare tali chiamate al controllo delle chiamate (ad esempio CUCM o Expressway) e bloccare le chiamate in tale posizione.

Nell'immagine è illustrato un esempio di tabella delle chiamate in uscita:

Con una regola generale <corrispondenza di tutti i domini> alla fine e la prima regola al dominio di steven.lab senza un proxy SIP da usare compilato (in modo che si basa sui record DNS SRV per esso).

Si noti che si tratta di un elenco ordinato con un valore di priorità superiore che viene coperto per primo. Se si trova una corrispondenza con una regola il cui comportamento è impostato su Stop, la chiamata non attraversa il resto della tabella dopo tale corrispondenza e la chiamata non è riuscita se, ad esempio, il proxy SIP non è riuscito a instradare la chiamata. Se l'impostazione è Continua, è possibile consentire un fallback a un percorso diverso o a un nodo diverso nel cluster. È ad esempio possibile specificare un proxy SIP diverso per ogni regola dello stesso dominio. 

Le impostazioni di Dominio contatto locale e Dominio Da locale sono illustrate nella sezione precedente della tabella di inoltro di chiamata in arrivo. Il tipo di trunk consente di specificare il tipo di chiamata da eseguire, che può essere Standard SIP, Lync o Avaya che dipende dal sistema ricevente.

Il campo Encryption determina se la segnalazione della chiamata deve essere non crittografata o crittografata. Tuttavia, si noti che ciò non implica alcuna crittografia dei supporti, come impostata nella configurazione della crittografia dei supporti SIP nel menu Configurazione > Impostazioni chiamata. In questa configurazione, è anche possibile selezionare Auto che tenta di effettuare la chiamata prima con una segnalazione crittografata con un possibile fallback a una segnalazione non crittografata. Se si è certi che l'altro lato è crittografato o non crittografato, si consiglia di definirlo di conseguenza per evitare ritardi nella configurazione delle chiamate a causa del processo di fallback.

Un output di esempio del file di log per una chiamata a steven.lab (dopo la riscrittura del dominio nella tabella di inoltro di chiamata in arrivo), con traccia DNS e traccia SIP impostate su detail, mostra i record SRV sottoposti a query e il meccanismo di fallback nel caso in cui la crittografia sia impostata su Auto.

2018-10-12  11:25:16.168  Info     call 821: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss@any.com"
2018-10-12  11:25:16.179  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@steven.lab'
2018-10-12  11:25:16.180  Info     call 822: outgoing SIP call to "stejanss@steven.lab"

2018-10-12  11:25:16.180  Info     DNS trace: resolving "steven.lab" (SRV "_sips._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 using 10.48.36.215:5061
2018-10-12  11:25:16.181  Info     SIP trace: connection 45: allocated for outgoing encrypted connection to 10.48.36.215:5061
2018-10-12  11:25:16.201  Info     handshake error 336151576 on outgoing connection 45 to 10.48.36.215:5061 from 10.48.80.71:54864
2018-10-12  11:25:16.201  Info     SIP trace: connection 45: shutting down...

2018-10-12  11:25:16.201  Info     call 822: falling back to unencrypted control connection...

2018-10-12  11:25:16.201  Info     DNS trace: resolving "steven.lab" (SRV "_sip._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 using 10.48.36.215:5060
2018-10-12  11:25:16.202  Info     SIP trace: connection 46: allocated for outgoing connection to 10.48.36.215:5060
2018-10-12  11:25:16.203  Info     SIP trace: connection 46: outgoing connection successful, 10.48.80.71:59776 to 10.48.36.215:5060
2018-10-12  11:25:16.205  Info     SIP trace: connection 46: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:59776, size 3290:
2018-10-12  11:25:16.205  Info     SIP trace: INVITE sip:stejanss@steven.lab SIP/2.0

Nota: nel caso di un ambiente cluster con più bridge di chiamate, è possibile impostare le regole dialplan in uscita per ogni bridge di chiamate quando lo si configura tramite API e si specifica sull'oggetto API un ID callbridge (o ID callbridgeGroup). Si supponga, ad esempio, che si desideri che tutte le chiamate vengano effettuate da un determinato callbridge per un determinato dominio (ad esempio, quando si chiama us.example.com si desidera che le chiamate vengano effettuate dai server negli Stati Uniti). Verificare quindi di disporre di una configurazione API per l'oggetto outboundDialPlanRules in modo che ciascun callbridge diverso da quello basato negli Stati Uniti sia in grado di instradare la chiamata al callbridge negli Stati Uniti (nel caso di questo esempio).

OutboundDialPlanRule (per callbridge USA)

• domain = us.example.com
• sipProxy = <vuoto quando si utilizza DNS SRV / IP o FQDN se impostato manualmente>
• ambito = callbridge
• callbridge = <IDcallbridge-US>

OutboundDialPlanRules (per tutti i bridge di chiamate non statunitensi che devono consentire di effettuare tale chiamata) (ne occorre uno per ogni bridge di chiamate)

• domain = us.example.com
• sipProxy = <IP-or-FQDN-of-US-Callbridge>
• ambito = callbridge
• callbridge = <non-US-callbridge-ID>

Verifica 

Attualmente non è disponibile una procedura di verifica per questa configurazione.

Risoluzione dei problemi 

Non sono attualmente disponibili informazioni specifiche sulla risoluzione dei problemi per questa configurazione.

Informazioni correlate

• Documentazione e supporto tecnico – Cisco Systems
• strumento Collaboration Solutions Analyzer 
• Documentazione CMS

---

NOTA: per gli esempi di configurazione, consultare le seguenti guide:

• Configurazione e integrazione di una singola guida combinata CMS
• Configurazione di Cisco Meeting Server e della Guida CUCM