Comprendre la logique de routage des appels sur Meeting Server

Introduction

Ce document décrit la logique de routage des appels de Cisco Meeting Server (CMS) (anciennement produit Acano) qui est répartie en plusieurs tables de routage des appels. Ce document couvre les différentes étapes et les différents scénarios que les appels peuvent prendre à travers ces tables de routage d'appels.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Composant Cisco Meeting Server Call Bridge.

Composants utilisés

Les informations contenues dans ce document sont basées sur Cisco Meeting Server version 2.3.x.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Quelle est la logique de routage des appels de Cisco Meeting Server (CMS) ?

Le routage des appels sur CMS implique quelques tables de routage différentes. Avec l'organigramme téléchargeable , vous pouvez suivre la logique de routage des appels pour chaque appel qui arrive sur le CMS. Ceci est valable pour tous les types d'appels : les appels Cisco Meeting App (CMA - client épais ou WebRTC), les appels SIP (Session Initiation Protocol) standard ou les appels SIP Microsoft, sauf indication contraire.

Remarque : la seule exception concerne les appels lancés par CMS (soit CMS directement pour les appels sortants planifiés de TelePresence Management Suite (TMS), soit les appels clients CMA sortants) dans lesquels la table de transfert d'appels est ignorée.

Voici l'ordre du processus de routage d'appel dans CMS : 

1. Tableau de correspondance des appels entrants
2. Table de transfert des appels entrants
3. Tableau des appels sortants

Chaque tableau est expliqué plus en détail plus loin dans le document, qui inclut les images qui montrent uniquement la partie appropriée de .

Remarque : CMS effectue uniquement le routage des appels en fonction du routage de domaine, donc en fonction du côté droit (RHS) de l'URI (Uniform Resource Identifier). Il n'existe aucune fonctionnalité de routage d'appels basée sur le côté gauche (LHS) de l'URI comme vous en avez sur Cisco Unified Communications Manager (CUCM) avec le routage DirectoryNumber (modèles de routage).

Remarque : chaque table est une liste ordonnée définie par l'attribut priority. Une priorité plus élevée signifie qu'il essaie d'être mis en correspondance en premier. S'il ne correspond pas, il passe à la règle suivante de la liste. En règle générale, donnez aux règles plus générales (comme un * qui correspond à n'importe quel domaine) une priorité inférieure à celle des règles plus spécifiques. De cette façon, les règles spécifiques sont traitées en premier, et vous avez la possibilité de revenir aux règles plus générales.

Étape 1. Tableau de correspondance des appels entrants

Il s'agit de la première étape du processus au cours de laquelle CMS détermine si l'appel entrant est destiné au serveur Cisco Meeting Server lui-même et doit être traité sur celui-ci ou s'il s'agit d'un appel destiné à un système différent dans lequel CMS est l'agent qui interagit avec l'appel et gère à la fois le support et la signalisation (par exemple, les appels de passerelle Skype vers les terminaux SIP standard ou vice versa).

Il vérifie si la partie domaine de l'URI entrant correspond ou non à la table de correspondance entrante. S'il correspond, il peut acheminer l'appel vers l'espace, l'utilisateur, l'IVR ou effectuer une recherche de conférence Lync (sur site ou hors site) selon votre configuration pour cette règle de plan de numérotation. La table ne permet pas les domaines génériques, elle nécessite une correspondance complète.

Remarque : si aucun domaine de correspondance d'appel entrant n'est configuré, CMS accepte tous les URI entrants des appels SIP ou Lync qui arrivent sur le pont d'appel. Pour les clients CMA (WebRTC ou client épais) bien qu'il accepte l'appel, il n'est pas acheminé automatiquement vers l'espace ou l'utilisateur approprié. Par conséquent, il est important d'entrer dans le domaine correct lorsque vous utilisez le client CMA pour appeler des espaces ou des utilisateurs dans ce cas.

Par exemple, un tableau de correspondance d'appels est affiché dans l'image (il affiche seulement les espaces Cibles et l'option Utilisateurs Cibles pour plus de brièveté) :

Ici, le domaine est configuré comme acano.steven.lab que les clients composent normalement. Cependant, il permet également des appels ad hoc ou des modèles de route SIP spécifiques à partir de CUCM (ou des règles de recherche Expressway) qui ciblent uniquement un pont d’appel spécifique (dans le cas d’un cluster) par les première et deuxième règles de secours dans la table qui correspondent soit à l’adresse IP du pont d’appel (10.48.54.160 dans ce cas) soit au nom de domaine complet (FQDN) du pont d’appel (acano1.acano.steven.lab dans ce cas).

Étape 2. Table de transfert des appels entrants

Si l'appel n'a atteint aucune des règles de la table de correspondance des appels entrants ou s'il n'y avait aucune correspondance pour que l'appel se poursuive (par exemple, l'utilisateur a composé un URI d'espace inexistant ou incorrect), il passe par la seconde table appelée table de transfert d'appels. Il s'agit également d'une fonctionnalité basée uniquement sur les domaines qui vous permet de bloquer spécifiquement les appels vers certains domaines ou d'autoriser spécifiquement les appels vers certains domaines. Si vous souhaitez effectuer cette opération, il est important d'avoir des règles plus spécifiques avec une priorité plus élevée, afin qu'elles soient vérifiées en premier.

Cet exemple montre que les appels destinés à dummy.com sont rejetés, tandis que les appels destinés à tplab.local sont transférés :

Lorsque vous laissez vide le tableau de renvoi d'appels, cela entraîne un état dans lequel CMS n'agit pas comme passerelle entre les participants Skype et SIP, par exemple, car il n'y a pas de règle de renvoi d'appels. En supposant que le domaine de l'appel entrant ne correspond pas dans le tableau de correspondance des appels entrants ou que le domaine correspond mais qu'il n'y a pas de correspondance sur les espaces, les utilisateurs ou les IVR (ou les réunions Skype), l'appel n'est pas transféré en ce qui concerne le tableau des appels sortants.

Remarque : cela se produit cependant avec les clients CMA (clients épais et WebRTC) car ils sont capables de passer des appels sortants (*Web App dans 3.0 ne peut pas passer d'appels sortants, mais plutôt des appels passés par CMS et par Callbridge). De même, les appels sortants sur CMS fonctionnent aussi bien lorsqu'ils sont effectués via l'API par exemple (dans le cas de conférences planifiées TMS). En général, les appels qui sont initiés à partir du CMS lui-même (soit directement par le CMS, soit via le CMA) ne doivent pas suivre la logique de renvoi d'appels.

Dans le journal des événements, vous pouvez voir le message de transfert mis en surbrillance comme par exemple lorsque CMS agit comme une passerelle pour les appels SIP et Skype. Juste avant cela, vous pouvez voir l'appel entrant et l'appel sortant après.

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"

Si la table de transfert n'a pas de règle ou de règle de rejet, le journal des événements ne l'affiche pas explicitement. Il vous informe simplement que l'appel SIP ne correspond pas (aucun espace, utilisateur, IVR ou téléconférence Lync) et que vous avez manqué la règle de transfert (ou qu'elle est définie pour être rejetée) pour passer à la section des règles sortantes.

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

Pour les appels des clients CMA ou les appels sortants de CMS qui sont initiés par le biais de téléconférences TMS planifiées, il n'y a aucun appel entrant vu dans le journal des événements. L'appel est immédiatement dirigé vers la table de plan de numérotation sortante et n'est pas traité par la table de renvoi d'appels.

La table de transfert d'appels contient deux autres options de configuration : Réécrire le domaine et ID de l'appelant.

Réécrire le domaine

Cette option vous permet de réécrire le domaine de l'appel entrant sur un autre et de modifier la partie domaine de l'URI de requête SIP ainsi que l'en-tête To du message SIP.

Par exemple, avec la configuration sur cette image, le journal des événements (avec la trace SIP activée) est affiché ici pour un appel entrant avec domain any.com mais sans correspondance dans le tableau de correspondance des appels entrants (sur les espaces, les utilisateurs, l'IVR ou les conférences 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

Dans cette ligne d'appel de transfert, elle indique la modification qui s'est produite. Si vous n'avez pas activé la trace SIP, il montre toujours la modification de any.com à newany.com.

L'utilisation la plus courante de cette réécriture du domaine est une intégration Lync sur site avec un cluster CMS où il est recommandé de définir l'en-tête Contact et l'en-tête From dans les règles sortantes sur Lync/Skype pour les noms de domaine complets (FQDN) spécifiques au pont d'appel. Cela est dû aux règles de routage suivantes :

• Skype envoie de nouvelles transactions dans une boîte de dialogue (comme par exemple un ACK après un INVITE - 200 OK) à l'en-tête Contact spécifié dans le 200 OK qu'il a reçu du CMS. Pour les connexions entrantes de Skype vers CMS, Skype envoie d'abord un message SIP NEGOTIATE contenant un en-tête ms-fe dans l'en-tête To qui spécifie comment l'en-tête Contact doit être rempli dans les 200 réponses OK sur l'INVITE (car il utilise le même canal TCP)
• Skype envoie de nouvelles boîtes de dialogue (comme le partage de contenu, car il s'agit d'un appel séparé ou d'un rappel en cas d'appel manqué) vers l'en-tête From de l'invitation d'origine

Lorsqu'il réécrit le domaine, il est pertinent pour le rappel des appels Lync. L'en-tête From de l'invitation manquée pointe vers le pont d'appel spécifique d'où provient l'appel. Lync envoie ensuite une nouvelle requête (INVITE) avec l'URI de requête SIP qui correspond au nom de domaine complet du pont d'appel. Il est ensuite traduit dans le domaine SIP par le biais de ces règles de réécriture. Une fois l’appel transféré, il utilise les règles sortantes vers CUCM ou Expressway-C où le point d’extrémité SIP est enregistré.

ID appelant

Deux options peuvent être définies sur les règles de transfert. Soit il est configuré pour passer et alors aucune modification n'est faite sur l'en-tête From des INVITE sortants, soit il est configuré pour utiliser le plan de numérotation qui permet au système de modifier l'en-tête From selon les règles sortantes. Ce paramètre est indépendant du fait que vous ayez ou non une réécriture du domaine car cela concerne uniquement l'URI de requête SIP ainsi que l'en-tête To de l'invitation sortante.

Par exemple, le même appel qu'auparavant a été effectué, mais il existe maintenant une règle de plan de numérotation sortant vers newany.com (comme après la réécriture sur la table de transfert des appels entrants) configurée comme un appel de type Lync (Ms-Conversation-ID comme en-tête SIP supplémentaire par exemple). Les champs Local From Domain (et Local Contact Domain) sont correctement renseignés pour pointer vers le nom de domaine complet du pont d'appel, comme indiqué précédemment pour les appels Lync. Cela reflète ensuite la modification de l'en-tête From et Contact de l'invitation SIP sortante. Comme le montre l'image, ils sont remplis avec la même valeur et peuvent être sélectionnés individuellement selon vos besoins.

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

Si la règle de transfert est simplement définie à pass through, alors il n'y a pas de modification sur l'en-tête From comme vu aussi de l'exemple précédent (dans ce cas, pass through a été défini sur la règle de transfert). L'en-tête Contact est toujours adapté lorsque CMS démarre un nouveau callLeg et doit donc ajouter un en-tête Contact à lui-même.

Différentes combinaisons d'ID d'appelant et de domaine de contact local et de domaine d'origine local peuvent être utilisées. L'en-tête From de l'invitation SIP sortante est construit comme indiqué sur le tableau où l'appel entrant entre dans le CMS avec un en-tête From de usera@from.com.

Étape 3. Tableau des appels sortants

Il s'agit de la dernière table de la logique de routage d'appels qui indique l'appel à un autre serveur comme suit :

• L'appel entrant n'est pas traité localement (sur le domaine correspondant à l'appel entrant).
• Il s'agit d'un appel sortant d'un espace CMS (via CMA ou via API dans le cas de réunions programmées par TMS, par exemple ou d'un appel sortant demandé par Cisco Meeting Manager (CMM)) ou d'un client CMA.

D'après l'image, vous pouvez voir que la logique est relativement simple. S'il n'y a aucune entrée dans la table, elle autorise toujours les appels sortants, mais suppose que le serveur CMS est capable de résoudre les enregistrements SRV SIP (_sips._tcp / _sip._tcp / _sip._udp) pour ce domaine particulier, comme indiqué sur l'URI de requête SIP. Si la table n'est pas vide, mais qu'il n'y a pas de correspondance pour le domaine composé, la même logique de recherche DNS est exécutée. S'il y a une correspondance sur le domaine, alors il suit la logique de cette règle particulière. À cet égard, si vous souhaitez bloquer les appels sortants de CMA ou comme effectués via TMS ou CMM, vous pouvez le faire de deux manières. Soit vous n’avez pas d’enregistrement DNS SRV (ou vous ne pouvez pas le résoudre par CMS), soit vous acheminez ces appels vers votre contrôle d’appel (CUCM ou Expressway par exemple) et vous bloquez les appels à cet endroit.

L'image présente un exemple de table d'appels sortants :

Avec une règle générale <match all domains> à la fin et la première règle au domaine de steven.lab sans proxy SIP à utiliser remplie (donc il s'appuie sur les enregistrements DNS SRV pour elle).

Notez qu'il s'agit d'une liste ordonnée avec une valeur de priorité supérieure qui est traitée en premier. Si vous faites correspondre une règle avec le Behavior défini sur Stop, l'appel ne passe pas par le reste de la table après cette correspondance et l'appel a échoué si ce proxy SIP n'a pas réussi à acheminer l'appel, par exemple. Lorsque ce paramètre est défini sur Continuer, vous pouvez autoriser un secours vers une route ou un noeud différent dans le cluster. Par exemple, vous pouvez spécifier un proxy SIP différent pour chaque règle vers le même domaine. 

Les paramètres Domaine de contact local et Domaine de provenance local sont traités dans la section précédente de la table de transfert des appels entrants. Le type de liaison vous permet de spécifier le type d'appel à effectuer, qui peut être SIP standard, Lync ou Avaya, selon le système de réception.

Le champ Encryption détermine si la signalisation de l'appel doit être non chiffrée ou chiffrée. Cependant, notez que cela n'implique aucun cryptage de support, tel que défini dans la configuration de cryptage de support SIP telle qu'elle se trouve dans le menu Configuration > Call Settings. Dans cette configuration, vous avez également la possibilité de sélectionner Auto qui tente d'effectuer l'appel en premier avec une signalisation chiffrée avec un éventuel retour à une signalisation non chiffrée. Si vous savez d'emblée que l'autre côté est chiffré ou non chiffré, il est fortement recommandé de le définir en conséquence pour éviter tout retard de configuration d'appel dû au processus de secours.

Un exemple de sortie du fichier journal d'un appel vers steven.lab (après réécriture du domaine sur la table de transfert des appels entrants), avec trace DNS et trace SIP définies sur detailed, nous montre les enregistrements SRV qui sont interrogés et le mécanisme de secours dans le cas où le chiffrement est défini sur 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

Remarque : dans le cas d'un environnement en cluster avec plusieurs ponts d'appels, vous pouvez configurer des règles de plan de numérotation sortantes par pont d'appels lorsque vous le configurez via l'API et spécifiez sur l'objet API un ID de pont d'appels (ou ID de groupe de ponts d'appels). Supposons, par exemple, que vous souhaitez que tous les appels sortent d'un pont d'appels particulier pour un domaine particulier (par exemple, lorsque vous appelez us.example.com, vous souhaitez qu'il sorte de vos serveurs basés aux États-Unis). Assurez-vous ensuite que vous disposez d'une configuration API pour outboundDialPlanRules afin que chaque pont d'appel autre que celui basé aux États-Unis puisse acheminer l'appel vers le pont d'appel américain (dans le cas de cet exemple).

OutboundDialPlanRule (pour US callbridge)

• domaine = us.example.com
• sipProxy = <vide lors de l'utilisation de DNS SRV / IP ou FQDN si défini manuellement>
• scope = callbridge
• callbridge = <UScallbridge-ID>

OutboundDialPlanRules (pour tous les ponts d'appels non américains qui doivent autoriser à passer cet appel) (en nécessite un par pont d'appel)

• domaine = us.example.com
• sipProxy = <IP-or-FQDN-of-US-Callbridge>
• scope = callbridge
• callbridge = <ID-pont-appel-non-US>

Vérifier 

Aucune procédure de vérification n'est disponible pour cette configuration.

Dépannage 

Aucune information de dépannage spécifique n'est actuellement disponible pour cette configuration.

Informations connexes

• Assistance et documentation techniques - Cisco Systems
• Outil Collaboration Solutions Analyzer 
• documentation CMS

---

REMARQUE : pour obtenir des exemples de configuration, consultez les guides suivants :

• Guide combiné de configuration et d'intégration de CMS
• Guide de configuration de Cisco Meeting Server et CUCM