Prenons l'exemple d'un partenaire Webex hypothétique nommé TelSP pour illustrer les différents modèles de déploiement que ce partenaire peut adopter.

Voici les spécifications générales & exigences de TelSP :

• Le partenaire prévoit d'utiliser sip.telsp.com comme domaine de premier niveau partagé par tous les clients qu'il gère.

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

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

• Le partenaire possède deux sites physiques, et ces deux sites partagent une connectivité PSTN :

  • 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.

Le scénario souhaité est d'avoir un réseau téléphonique public commuté (RTPC). origination/termination pour les deux clients utilisant les passerelles de Miami et de Chicago fournies par le partenaire, comme indiqué dans l'illustration :

Association de la localisation du client au tronc et à la passerelle

Webex Calling permet la création de lignes et le partage d'une ligne entre plusieurs sites. Lors de la création du tronc, associez-le à un emplacement.

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

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

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

Pour CustB, une configuration similaire avec les trunks suivants 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 désigner comme sa connexion PSTN principale via le tronc trunk_chicago.

Lors du déploiement d'une passerelle locale partageant plusieurs liaisons réseau, Cisco exige l'utilisation d'un nom de domaine pleinement qualifié (FQDN) unique par liaison. Voir Configure-trunks,-route-groups,-and-dial-plans-for-Webex-Calling pour plus de détails.

Utiliser une adresse IP et un port connu par liaison est un choix idéal. Toutefois, l’obtention d’une adresse IPv4 publique peut s’avérer difficile pour certains partenaires qui souhaitent utiliser une adresse par passerelle et par site.

Veuillez donc lire ces points importants :

• Cisco n'impose pas d'adresse IP par liaison.

• Une adresse de jonction peut correspondre à une adresse IP unique ou à une adresse partagée avec une autre jonction.

• Cisco recommande de configurer chaque connexion trunk avec une combinaison unique d'adresse IP et de port sur la passerelle locale pour les raisons suivantes :

  1. Le maintien de liaisons de connexion TCP distinctes par jonction permet de prendre en charge la capacité d'appels simultanés maximale par jonction. Le partage des combinaisons d'adresses IP et de ports entre plusieurs liaisons peut avoir un impact négatif sur la capacité d'appel.

  2. Assure l'isolation au niveau du réseau entre les clients

  3. Il est courant que les contrôleurs de frontière de session réutilisent la connexion socket TCP éphémère, sauf si une isolation est fournie sous la forme d'un locataire unique partitionné par une adresse IP ou d'un port d'écoute unique pour le locataire.

  4. La connexion ou les connexions par tronc grâce à l'isolation des locataires offrent un meilleur débit, notamment dans des conditions de réseau avec une perte de données élevée. Par conséquent, le trafic provenant d'un client n'a aucun impact sur l'autre.

Adresse IP par passerelle : Configuration et recommandations du tronc

Consultez ces exemples de différents modèles de planification :

Modèle 1: Adresse IP unique par tronc

Dans ce modèle, tous les trunks hébergés par les deux passerelles aboutissent à 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 l'information sous forme de tableau :

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

Exemple de 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: Adresse IP partagée sur une passerelle, mais ports d'écoute différents

Dans ce modèle, toutes les liaisons hébergées sur la passerelle locale de Chicago sont résolues vers la même adresse IP et toutes les liaisons hébergées sur la passerelle locale de Miami sont résolues vers une adresse IP différente. Cependant, lorsqu'on utilise la même adresse IP, chaque liaison est configurée à l'aide d'un nom de domaine complet (FQDN) dans le concentrateur de contrôle et est configurée avec un port unique.

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

Voici un autre exemple de la manière dont un enregistrement SRV est résolu. Dans cet exemple, il existe un enregistrement A par adresse IP. Cependant, le port est unique pour chaque adresse et est représenté par une configuration DNS spécifique associant une adresse SRV au port correspondant.

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.sip.telsp.com

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

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

Le partenaire est propriétaire de telsp.com et de ses sous-domaines. Par conséquent, le serveur DNS et l'autorité permettant d'obtenir des certificats signés par une autorité de certification agréée appartiennent au partenaire.

• Cisco Webex s'attend à ce que son partenaire publie le nom de domaine complet (FQDN) ou l'adresse SRV, y compris les enregistrements A, dans le domaine public.

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

Lorsque vous utilisez un nom de domaine pleinement qualifié (FQDN) comme adresse de liaison principale, configurez les certificats signés avec le nom commun (CN) ou le numéro alternatif du sujet (SAN) défini sur les FQDN pour les liaisons principales.

Utilisez l'une de ces méthodes pour générer les noms de domaine pleinement qualifiés (FQDN) dans le certificat :

• Choisissez l'un des FQDN comme nom commun (CN) et les autres comme numéro de sujet alternatif (SAN).

• Placez le domaine de premier niveau (sip.telsp.com) comme CN et tous les FQDN comme SAN.

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

Lorsque vous utilisez une adresse SRV comme adresse de tronc, configurez des certificats signés avec le CN ou le SAN correspondant à la partie hôte de l'adresse SRV. L'enregistrement A ou CNAME auquel l'adresse SRV est résolue 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

Configurez la passerelle hébergée par le partenaire conformément à ces instructions : Commencer avec la passerelle locale

Configurez chaque tronc conformément aux instructions correspondantes pour l'appareil SBC. Pour les instructions relatives au Cisco CUBE, consultez : Configuration de la passerelle locale sur Cisco IOS-XE pour Webex Calling

Configurez les classes vocales, les pairs d'appel et les groupes de pairs d'appel pour le trafic entrant et sortant du trunk, comme indiqué sur l'image :

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

1. Créer le coffre — Ajouter un coffre sous Calling/Call Routing/Trunk pour chaque passerelle partagée partenaire. Pour configurer une jonction, consultez Configurer les jonctions, 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 tronc sous Management/Organization Settings/Domains.

   CustA	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 à Control Hub de vérifier que le domaine appartient bien au partenaire. Pour plus de détails, consultez Gérer vos domaines

   Puisque le domaine commun est utilisé pour la vérification de chaque client. Toutefois, étant donné que cette vérification a lieu au niveau de l'organisation cliente, assurez-vous qu'un jeton différent soit généré et utilisé pour la vérification sur chaque organisation cliente. Puisqu'un seul domaine est utilisé par plusieurs organisations clientes, aucune organisation ne peut revendiquer la propriété du domaine.
3. Configurer l'adresse SBC avec le nom de domaine complet (FQDN) —

   Pour la porte d'entrée de Miami :

   Paramètre	CustA	ClientB
   Emplacement	Denver	Boston
   Nom de la ligne auxiliaire	trunk_miami	trunk_miami
   Type de trunk	Certificat basé sur le certificat	Certificat basé sur le 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 maximal d'appels simultanés (250-6500)	500	500

   Pour la porte d'entrée de Chicago :

   Paramètre	CustA	ClientB
   Emplacement	Détroit	Dallas
   Nom de la ligne auxiliaire	trunk_chicago	trunk_chicago
   Type de trunk	Certificat basé sur le certificat	Certificat basé sur le 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 maximal d'appels simultanés (250-6500)	500	500

   • (Facultatif) N'utilisez pas un nom unique pour le coffre pour tous les clients, et un nom identique peut faciliter le suivi du coffre.

   • Certaines cartes SBC permettent de configurer le même port, mais cette configuration peut avoir un impact sur la capacité. Utilisez donc des ports différents.

4. Utilisation des troncs — choisissez un emplacement arbitraire pour le tronc, pour les raisons suivantes :

   • N'importe quel emplacement peut utiliser la ligne dans une connexion PSTN.

   • Vous pouvez accéder au tronc via un groupe d'itinéraires.

   • N'importe quel plan de numérotation peut utiliser le trunk.

5. Consultez les définitions des troncs et leurs emplacements associés :

   

   Vous pouvez utiliser ces troncs pour créer des groupes de routes. Dans l'image, un groupe de routage rg_miami_chicago est défini qui achemine les appels vers le tronc trunk_miami comme option principale et vers le tronc trunk_chicago comme option secondaire.

   

   Vous pouvez définir un deuxième groupe de routage rg_chicago_miami qui achemine les appels vers le tronc trunk_chicago comme option principale et vers le tronc trunk_miami comme option secondaire.

6. Les lignes et les groupes de routage définis sont maintenant disponibles dans l'option Connexion d'appel PSTN pour chaque emplacement. Sur l'image, vous pouvez voir l'emplacement à Denver.

   

7. Vous pouvez utiliser les jonctions et les groupes de routage dans la définition du plan de numérotation. Par exemple, une plage de numéros sur site à Chicago pour le client est divisée pour se terminer par le groupe de routage rg_chicago_miami (pour tous les emplacements) dans l'image :