Considérons un partenaire Webex hypothétique nommé TelSP pour illustrer les différents modèles de déploiement que le partenaire peut adopter.

Voici les spécifications et exigences de haut niveau de TelSP :

• Le partenaire envisage d’utiliser sip.telsp.com en tant que domaine de premier niveau qui est partagé entre tous les clients qu’ils gèrent.

• Le partenaire est propriétaire sip.telsp.com et peut administrer l'infrastructure DNS et les autorités de certification, gérer les adresses DNS et signer les certificats pour ce domaine et ses sous-domaines.

• Le partenaire peut déployer deux contrôleurs frontières de session distincts (physiques ou virtuels) en tant que passerelles locales pour l’accès RTCP partagé entre les clients finaux.

• Le partenaire a deux sites physiques, et ces deux sites partagent la connectivité RTCP :

  • Miami

  • Chicago

• TelSP exploite ses passerelles locales pour le compte des deux clients CustA et CustB tels qu’ils sont désignés ci-après.

Dans cet article, le terme partenaire fait référence au partenaire de gestion Webex, en particulier TelSP dans cet exemple. Cette entité a accès au hub des partenaires Webex.

Le scénario souhaité est d’avoir un origination/terminaison RTCP pour les deux clients utilisant les passerelles Miami et Chicago fournies par le partenaire, comme le montre l’illustration :

Associer l’emplacement du client au trunk et à la passerelle

Webex Calling permet de créer des lignes auxiliaires et de partager une ligne auxiliaire sur plusieurs sites. Lors de la création du trunk, associez le trunk à un emplacement.

Pour CustA, les détails du trunk sont les suivants :

L’illustration montre l’association de l’emplacement du client à la passerelle et au trunk pour CustA :

Dans ce déploiement, le trunk associé à l’emplacement est la connexion RTCP principale pour cet emplacement. L’autre ligne auxiliaire est utilisée comme connexion RTCP secondaire ou route pour des entrées de plan de numérotation spécifiques. La mise en œuvre de la relation de connexion RTCP primaire et secondaire se fait par le biais d’un concept de groupe de routage. Voir la section Configuration du client Webex pour plus de détails.

Pour CustB, une configuration similaire avec les lignes auxiliaires suivantes est créée :

L’illustration montre l’association de l’emplacement du client à la passerelle et au trunk pour CustB :

L'illustration montre un troisième emplacement, à savoir New York, que vous pouvez ajouter ultérieurement et pointer vers le trunk trunk_chicago comme sa connexion RTCP principale.

Lors du déploiement d'une passerelle locale qui partage plusieurs lignes principales, Cisco MANDATE l'utilisation d'un FQDN unique par ligne principale. Voir Configurer les lignes auxiliaires, les groupes de routage et les plans de numérotation pour Webex-Calling pour plus d’informations.

L’utilisation d’une adresse IP et d’un port bien connu par trunk est un choix idéal. Cependant, l’obtention d’une adresse IPv4 publique peut être difficile pour certains partenaires qui souhaitent utiliser une adresse par passerelle et par site.

Lisez donc ces conseils importants :

• Cisco ne demande pas d’adresse IP par ligne principale.

• Une adresse de ligne principale peut se résoudre à une adresse IP unique ou à l'adresse partagée entre une autre ligne principale.

• Cisco recommande d’avoir un port d’écoute unique par ligne principale pour les raisons suivantes :

  1. Fournit une isolation au niveau du réseau entre les clients

  2. Il est typique des contrôleurs de limites de session de réutiliser la connexion de socket TCP éphémère, sauf si une isolation est fournie en tant que tenant unique partitionné par une adresse IP ou un port d'écoute unique pour le tenant.

  3. La connexion ou les connexions par trunk via l'isolation des locataires fournissent un meilleur débit, spécifiquement dans des conditions de réseau avec une perte de données élevée. Par conséquent, le trafic d’un client n’a pas d’impact sur l’autre.

Adresse IP par passerelle : Configuration de la ligne principale et recommandations

Reportez-vous à ces exemples de différents modèles de planification :

Modèle 1 : Adresse IP unique par ligne principale

Dans ce modèle, tous les trunks hébergés par les deux passerelles se résolvent à une adresse IP unique et chacun de ces trunks peut ou non utiliser le même port mais idéalement le même port.

Représenter les informations sous forme de tableau :

Dans ce même modèle, le partenaire peut utiliser une adresse SRV. Webex Calling n’autorise « _sips._tcp » en tant que combinaison de service et de protocole à découvrir l’adresse du pair que s’il s’agit d’un enregistrement SRV.

Un échantillon de la résolution d'un enregistrement SRV

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

Modèle 2 : IP partagée sur une passerelle mais ports d'écoute différents

Dans ce modèle, tous les trunks hébergés sur la passerelle locale de Chicago se résolvent à la même adresse IP et tous les trunks hébergés sur la passerelle locale de Miami se résolvent à une IP différente. Cependant, lorsque vous utilisez la même adresse IP, chaque trunk est configuré à l’aide d’un nom de domaine complet dans le concentrateur de contrôle et est configuré avec un port unique.

Dans ce même modèle, le partenaire utilise une adresse SRV. Webex Calling n’autorise « _sips._tcp » en tant que combinaison de service et de protocole à découvrir l’adresse du pair que s’il s’agit d’un enregistrement SRV.

Un autre échantillon de la résolution d'un enregistrement SRV est le suivant. Dans cet exemple, il existe 1 enregistrement A par adresse IP. Cependant, le port est unique par adresse et est représenté par une configuration DNS spécifique reliant une adresse SRV au bon port.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5062 miami.custa.sip.telsp.com

Le partenaire possède telsp.com et ses sous-domaines. Par conséquent, le serveur DNS et l'autorité pour obtenir les certificats signés par une autorité de certification approuvée incombe au partenaire.

• Cisco Webex attend du partenaire qu’il publie l’adresse FDQN ou SRV incluant Un Enregistrement dans le domaine public.

• Cisco Webex s'attend à ce que le partenaire utilise l'une des autorités de certification listées dans telles que publiées dans ce document.

Lorsque vous utilisez un FDQN comme adresse de ligne principale, configurez les certificats signés avec le nom commun (NC) ou le numéro alternatif du sujet (SAN) défini sur les FDQN des lignes principales.

Utilisez l'une de ces méthodes pour générer les FQDN dans le certificat :

• Choisissez l'un des FDQN comme nom commun (NC) et le reste comme numéro alternatif (SAN).

• Placez le domaine de premier niveau (sip.telsp.com) en tant que CN et tous les FDQN en tant que SAN.

  À l'avenir, vous pourrez valider le certificat en fonction du domaine de premier niveau que cette configuration s'approprie.

Lorsque vous utilisez un SRV comme adresse de ligne principale, configurez les certificats signés avec le NC ou le SAN pour la partie hôte de l'adresse SRV. L'enregistrement A ou CNAME que l'adresse SRV résout n'est pas requis.

Configurer la passerelle

Utilisez ces ressources pour configurer une passerelle locale.

Pour configurer Cisco CUBE, suivez cette procédure : Configuration de la passerelle locale sur Cisco IOS-XE pour Webex Calling

Vous pouvez configurer des SBC tiers approuvés, voir : Commencer avec la passerelle locale

Vous pouvez configurer le trunk de la passerelle à l’avance.

Configurez la passerelle hébergée par le partenaire conformément aux présentes directives : Commencer avec la passerelle locale

Configurez chaque ligne auxiliaire conformément aux instructions pertinentes pour le périphérique SBC. Pour les instructions Cisco CUBE, voir : Configuration de la passerelle locale sur Cisco IOS-XE pour Webex Calling

Configurez des classes vocales, des pairs de numérotation et des groupes de pairs de numérotation pour le trafic entrant et sortant de la ligne principale conformément à l’image :

À partir du Partner Hub, vous pouvez lancer le Control Hub pour CustA ou CustB et configurer la passerelle. Utilisez cette procédure pour configurer pour chaque client :

1. Créer la ligne principale : ajoutez une ligne principale sous Appel/Routage des appels/Ligne principale pour chaque passerelle partagée par le partenaire. Pour configurer une ligne auxiliaire, voir Configurer les lignes auxiliaires, les groupes de routage et les plans de numérotation pour Webex Calling

2. Ajouter un domaine et vérifier : ajoutez et vérifiez le domaine suivant qui est utilisé pour créer un trunk sous Paramètres de gestion/organisation/domaines.

   Client	ClientB
   sip.telsp.com	sip.telsp.com

   Lors de l’ajout d’un domaine, un jeton est généré et placé dans l’enregistrement TXT du domaine sur le serveur DNS du partenaire. Cet enregistrement permet au Control Hub de vérifier que le domaine est la propriété du partenaire. Pour plus de détails, voir Gérer vos domaines

   Puisque Le domaine commun est utilisé pour la vérification sur chaque client. Cependant, étant donné que cette vérification a lieu au niveau de l’organisation du client, assurez-vous qu’un jeton différent est généré et utilisé pour la vérification sur chaque organisation du client. Étant donné qu’un seul domaine est utilisé par les organisations clientes, une organisation ne peut pas revendiquer la propriété du domaine.

3. Configurer l'adresse SBC avec FDQN—

   Pour la passerelle de Miami :

   Paramètre	Client	ClientB
   Emplacement	Denver	Boston
   Nom de la ligne auxiliaire	trunk_miami	trunk_miami
   Type de trunk	Basé sur un certificat	Basé sur un certificat
   type de périphérique	par exemple Cisco Unified Border Element (ou un autre périphérique pris en charge)	par exemple Cisco Unified Border Element (ou un autre périphérique pris en charge)
   Type d'adresse SBC	FDQN	FDQN
   Nom d'hôte	trunk.miami.custa	trunk.miami.custb
   Domaine	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FDQN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Nombre maximum d'appels simultanés (250 à 6500)	500	500

   Pour la passerelle de Chicago :

   Paramètre	Client	ClientB
   Emplacement	Détroit	Dallas
   Nom de la ligne auxiliaire	trunk_chicago	trunk_chicago
   Type de trunk	Basé sur un certificat	Basé sur un certificat
   type de périphérique	par exemple Cisco Unified Border Element (ou un autre périphérique pris en charge)	par exemple Cisco Unified Border Element (ou un autre périphérique pris en charge)
   Type d'adresse SBC	FDQN	FDQN
   Nom d'hôte	trunk.chicago.custa	trunk.chicago.custb
   Domaine	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FDQN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Nombre maximum d'appels simultanés (250 à 6500)	500	500

   (Facultatif) Vous n'avez pas de nom unique pour la ligne principale parmi les clients et le même nom peut aider à suivre la ligne principale. Certains SBC permettent de configurer le même port mais cette configuration peut avoir un impact sur la capacité. Par conséquent, utilisez différents ports.

4. Utiliser les lignes principales—choisissez un emplacement arbitraire pour la ligne principale, en raison des éléments suivants :

   • N’importe quel emplacement peut utiliser le trunk dans une connexion RTCP.

   • Vous pouvez accéder au trunk via un groupe de routage.

   • N’importe quel plan de numérotation peut utiliser la ligne principale.

5. Voir les définitions des lignes auxiliaires avec les emplacements associés :

   

   Vous pouvez utiliser ces lignes auxiliaires pour créer des groupes de routage. Dans l'image, un groupe de routage rg_miami_chicago est défini qui achemine les appels vers la ligne principale trunk_miami et vers la ligne principale trunk_chicago en tant qu'option secondaire.

   

   Vous pouvez définir un second groupe de routage rg_chicago_miami qui achemine les appels vers la ligne principale trunk_chicago en tant qu'option principale et vers la ligne principale trunk_miami en tant qu'option secondaire.

6. Les lignes auxiliaires et les groupes de routage définis sont maintenant disponibles dans l’option RTCP Connexion d’appel pour chaque emplacement. Dans l'image, voir l'emplacement de Denver.

   

7. Vous pouvez utiliser les lignes auxiliaires et les groupes de routage dans la définition du plan de numérotation. Par exemple : les NPA de la région de Chicago sont divisés pour se terminer par le groupe de routage rg_chicago_miami (pour tous les emplacements) dans l'image :