Merci pour votre commentaire.

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

Voici les spécifications et exigences de haut niveau 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 est propriétaire 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 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, qui partagent la même connectivité PSTN :

  • Miami

  • Chicago

• TelSP gère ses passerelles locales pour le compte des deux clients Custa et CustB, comme on les désigne ci-après.

Le scénario souhaité est de créer et de terminer le PSTN pour les clients utilisant les passerelles de Miami et de Chicago fournies par le partenaire, comme le montre l'illustration :

Exemple de déploiement simplifié

L'exemple simplifié suivant montre comment Peer Cert Identity permet à un seul certificat de prendre en charge plusieurs troncs de clients :

• Certificat — sip.telsp.com

• Malles

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Certification d'identité par les pairs — sip.telsp.com

• Résultat

  • Un seul certificat est utilisé

  • Plusieurs troncs clients sont pris en charge

Associer la localisation du client au tronc et à la passerelle

Les sections suivantes fournissent des mappages de configuration détaillés pour le déploiement décrit ci-dessus.

Webex Callingpermet de créer des troncs et de partager un tronc entre plusieurs sites. Lorsque vous créez le coffre, associez-le à un emplacement.

Pour Custa, les informations du coffre sont les suivantes :

L'illustration montre le lien entre la localisation du client et Gateway et Trunk pour Custa :

Dans ce déploiement, le tronc associé à la localisation est la principale connexion PSTN pour cette localisation. L'autre tronçon est utilisé comme connexion PSTN secondaire ou comme itinéraire pour des entrées de plan de numérotation spécifiques. La mise en œuvre de la relation de connexion PSTN primaire et secondaire se fait par le biais d'un concept de groupe de routes. Consultez la section Configurer les passerelles principales dans la section Control Hub pour plus de détails.

Pour CustB, une configuration similaire avec les troncs suivants a été créée :

L'illustration montre le lien entre la localisation du client et Gateway et Trunk pour CustB :

L'illustration montre une troisième adresse, à savoir New York, que vous pourrez ajouter plus tard en désignant le tronc trunk_chicago comme connexion PSTN principale .

Lors du déploiement d'une passerelle locale partageant plusieurs troncs, Cisco impose l'utilisation d'un nom de domaine complet unique par tronc. Voir Configure-trunks, -route-groups et dial-plans-for-Webex Calling pour plus de détails.

L'utilisation d'une adresse IP et d'un port connu par ligne de réseau est le 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 n'impose pas d'adresse IP par ligne de réseau.

• Une adresse réseau peut être transformée en une adresse IP unique ou en une adresse partagée entre un autre réseau.

• Cisco recommande de configurer chaque connexion réseau avec une combinaison d'adresse IP et de ports uniques sur la passerelle locale pour les raisons suivantes :

  1. Le fait de maintenir des liens de connexion TCP séparés par ligne permet d'atteindre la capacité d' appels simultanés maximale par ligne de réseau. Le partage de combinaisons d'adresses IP et de ports sur plusieurs troncs peut avoir un impact négatif sur la capacité d'appel.

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

  3. Les contrôleurs frontaliers de session réutilisent généralement la connexion éphémère par socket TCP, à moins que l'isolation ne soit assurée en tant que locataire unique partitionné par une adresse IP ou un port d'écoute unique pour le locataire.

  4. La ou les connexions par tronc via l'isolation des locataires fournissent un meilleur débit, en particulier dans des conditions de réseau caractérisées par de fortes pertes de données. Par conséquent, le trafic d'un client n'a pas d'impact sur l'autre.

Adresse IP par passerelle : configuration du réseau et recommandations

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

Modèle 1 : adresse IP unique par ligne

Dans ce modèle, tous les troncs hébergés par les deux passerelles ont une adresse IP unique et chacun de ces troncs peut utiliser le même port ou non, 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 Callingn'autorise que « _sips ». _tcp » comme combinaison de service et de protocole permettant de découvrir l'adresse homologue s'il s'agit d'un enregistrement SRV.

Un exemple 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 par passerelle, ports d'écoute uniques

Dans ce modèle, tous les troncs hébergés sur la passerelle locale de Chicago sont adressés à la même adresse IP et tous les troncs hébergés sur la passerelle locale de Miami ont une adresse IP différente. Cependant, lorsque vous utilisez la même adresse IP, chaque tronc est configuré à l'aide d'un nom de domaine complet dans le hub de contrôle et est configuré avec un port unique.

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

Voici un autre exemple de résolution d'un enregistrement SRV. 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.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

Pour les troncs basés sur SRV, l'identité du certificat Peer est initialement renseignée à partir des valeurs SRV configurées et peut être personnalisée, selon les mêmes règles de validation.

Le partenaire est propriétaire de telsp.com et de ses sous-domaines. Par conséquent, le serveur DNS et l'autorité chargée de faire signer les certificats par une autorité de certification agréée appartiennent au partenaire.

• Cisco Webexattend du partenaire qu'il publie l'adresse FQDN ou SRV, y compris A Records, dans le domaine public.

• Cisco Webexattend du partenaire qu'il fasse appel à l'une des autorités de certification répertoriées dans ce document.

Lorsque vous configurez des troncs à l'aide du nom de domaine complet ou du SRV :

• Chaque tronc doit toujours avoir un nom de domaine complet unique pour le routage et l'identification

• Les enregistrements DNS (A Record ou SRV) doivent être correctement configurés et résolvables

• Ces FQDN sont utilisés pour la signalisation et le routage. La validation des certificats est effectuée par rapport à l'identité de certificat Peer configurée, qui utilise par défaut les valeurs du nom de domaine complet du tronc, mais qui peut être personnalisée en fonction d'une identité partagée appartenant à un partenaire.

  Le champ d'identité du certificat Peer est prérempli à partir du nom de domaine complet du tronc et peut être remplacé par un domaine partagé appartenant à un partenaire afin d'utiliser un seul certificat sur plusieurs lignes de clients.

Configurer la passerelle

Utilisez ces ressources pour créer une passerelle locale.

Pour configurer Cisco CUBE, procédez comme suit : Configurer la passerelle locale sur Cisco IOS XE pour Webex Calling

Vous pouvez configurer des SBC tiers approuvés, voir : Commencez avec Local Gateway

Configurez la passerelle hébergée par les partenaires conformément à ces directives : Commencez avec Local Gateway

Réglez chaque coffre conformément aux instructions relatives à l'appareil SBC. Pour les instructions relatives au Cisco CUBE, voir : Configurer la passerelle locale sur Cisco IOS XE pour Webex Calling

Configurez des classes vocales, composez des pairs et composez des groupes de pairs pour le trafic entrant et sortant pour le tronc, comme indiqué sur l'image :

Lors de l'approvisionnement d'un tronc, Control Hub propose la possibilité de configurer l'identité des certificats Peer sur la page Ajouter un tronc. Cette amélioration simplifie le flux de travail en permettant aux partenaires de configurer et de réutiliser un seul domaine de premier niveau auprès de plusieurs organisations clientes. Cette approche élimine le besoin de certificats distincts par client ou par ligne de réseau, ce qui réduit les efforts opérationnels et simplifie le processus de configuration.

Lorsque vous configurez des troncs dans Control Hub, définissez une identité de certificat Peer afin de permettre l'utilisation d'un certificat unique pour votre domaine de premier niveau dans toutes les organisations clientes. Assurez-vous que le CN ou le SAN du certificat inclut ce domaine de premier niveau. Avec Peer Cert Identity, la passerelle locale utilise un certificat unique dont le CN ou le SAN contient le domaine partagé du partenaire (par exemple, sip.telsp.com). Les certificats Wildcard (par exemple, *.sip.telsp.com) ne sont pas pris en charge. Webex Callingaccepte ce certificat pour chaque ligne client configurée explicitement avec cette valeur comme identité de certificat Peer. Le certificat doit contenir la valeur d' identité exacte configurée pour le certificat Peer dans son CN ou son SAN. Il n'est donc plus nécessaire de configurer des certificats ou des entrées CN/SAN distincts pour les noms de domaine complets des troncs individuels.

Vérification du domaine et utilisation des certificats

Il est important de comprendre en quoi la vérification des domaines diffère de l'utilisation des certificats :

• Vérification du domaine (par client) : chaque organisation cliente doit vérifier le domaine de manière indépendante (par exemple, sip.telsp.com) en ajoutant un enregistrement TXT unique dans le DNS. Cela garantit que le partenaire est propriétaire du domaine et empêche toute utilisation non autorisée.

• Gestion des certificats (mondial) : Un seul certificat émis pour le domaine de premier niveau du partenaire peut être partagé entre tous les troncs clients grâce à Peer Cert Identity. Il n'est pas obligatoire de conserver des certificats distincts par client ou par coffre.

Comportement identitaire certifié par les pairs

Peer Cert Identity définit l'identité Webex Calling attendue dans le certificat présenté par la passerelle locale.

Une fois configuré :

• Webex Callingvalide le certificat en faisant correspondre l'identité du certificat Peer configurée au CN ou au SAN figurant sur le certificat

• Si les valeurs correspondent, la connexion TLS est acceptée

• Si les valeurs ne correspondent pas, la connexion est rejetée

Seuls les troncs configurés explicitement avec l'identité de certificat Peer correspondante sont autorisés à s'authentifier.

La validation des certificats à elle seule n'est pas la seule vérification effectuée lors de l'authentification. En plus de valider le certificat CN ou SAN par rapport à l'identité de certificat Peer configurée, elle vérifie Webex Calling également que le nom de domaine complet du tronc est explicitement configuré et associé à l'identité de certificat Peer correspondante dans Control Hub.

L'identité du certificat Peer est préremplie à partir des valeurs FQDN/SRV du tronc. Si vous conservez les valeurs par défaut, le comportement actuel des certificats par tronc reste inchangé. Les troncs basés sur des certificats existants continuent de fonctionner sans modification. Vous pouvez adopter une identité de certificat Peer partagée sur des troncs nouveaux ou existants à votre rythme, et les deux modèles peuvent coexister.

1. Exemple de configuration valide :

   • Certificat CN — sip.telsp.com

   • Certificat SAN — custa.sip.telsp.com

   • Certification d'identité par les pairs : custa.sip.telsp.com

   • Nom de domaine complet du tronc : trunk.miami.custa.sip.telsp.com

   Résultat : la connexion aboutit car l'identité du certificat Peer (custa.sip.telsp.com) correspond à la valeur SAN du certificat, et le nom de domaine complet du trunk (trunk.miami.custa.sip.telsp.com) est un sous-domaine de l'identité de certificat Peer configurée.

2. Exemple de panne de connexion :

   • Certificat CN — sip.telsp.com

   • Certificat SAN — custa.sip.telsp.com

   • Certification d'identité par les pairs : custb.sip.telsp.com

   • Nom de domaine complet du tronc : trunk.miami.custb.sip.telsp.com

   Résultat : la connexion échoue lors de la prise de contact TLS car l'identité du certificat Peer (custb.sip.telsp.com) n'est pas présente dans le CN ou le SAN du certificat. Le nom de domaine complet est correctement un sous-domaine de l'identité Peer Cert, mais le certificat ne porte pas cette identité.

3. Exemple de configuration non valide :

   • Certificat CN — sip.telsp.com

   • Certificat SAN — custa.sip.telsp.com

   • Certification d'identité par les pairs : custa.sip.telsp.com

   • Nom de domaine complet du tronc : trunk.miami.custb.sip.telsp.com

   Résultat : Control Hub rejette cette configuration au moment de la sauvegarde car le nom de domaine complet (trunk.miami.custb.sip.telsp.com) n'est pas égal à l'identité de certificat Peer configurée (custa.sip.telsp.com) ou n'en est pas un sous-domaine.

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

1. Créez le tronc : ajoutez un tronçon sous Appels/Routage des appels/Trunk pour chaque passerelle partagée par partenaire. Pour configurer un tronçon, voir Configurer les tronçons, les groupes d'itinéraires 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 Gestion/Paramètres de l'organisation/Domaines.

   Client B	Client C
   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 au partenaire. Pour plus de détails, voir Gérer vos domaines

   Le domaine commun est utilisé pour vérifier chaque client. Cependant, comme cette vérification a lieu au niveau de l'organisation cliente, assurez-vous qu'un jeton différent est généré et utilisé pour la vérification pour chaque organisation cliente. Parce qu'un seul domaine est utilisé par les organisations clientes et que chaque organisation cliente doit vérifier le domaine de manière indépendante à l'aide d'un enregistrement TXT unique, même si vous partagez le même domaine.

   Seule la vérification du domaine est requise pour l'identité Peer Cert. Ne revendiquez pas le domaine partagé auprès d'une organisation cliente. Un domaine ne peut être revendiqué que par une seule organisation, alors que le même domaine peut être vérifié auprès de plusieurs organisations.

3. Configurer une adresse SBC avec un nom de domaine complet—

   Pour le Miami Gateway :

   Paramètre	Client B	Client C
   Lieu	Denver	Boston
   Nom du coffre	trunk_miami	trunk_miami
   Type de coffre	Basé sur un certificat	Basé sur un certificat
   Type d'appareil	par ex. Cisco Unified Border Element(ou un autre appareil compatible)	par ex. Cisco Unified Border Element(ou un autre appareil compatible)
   Type d'adresse SBC	FQDN	FQDN
   Nom d'hôte	lgw.miami	lgw.miami
   Domaine	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	LGW.Miami.CustomerB.SIP.Telsp.com:5061	LGW.Miami.CustomerC.Sip.Telsp.com : 5062
   Nombre maximum d'appels simultanés (250-6500)	500	500

   Pour le Chicago Gateway :

   Paramètre	Client B	Client C
   Lieu	Détroit	Dallas
   Nom du coffre	trunk_chicago	trunk_chicago
   Type de coffre	Basé sur un certificat	Basé sur un certificat
   Type d'appareil	par ex. Cisco Unified Border Element(ou un autre appareil compatible)	par ex. Cisco Unified Border Element(ou un autre appareil compatible)
   Type d'adresse SBC	FQDN	FQDN
   Nom d'hôte	lgw.chicago	lgw.chicago
   Domaine	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	LGW.Chicago.CustomerB.SIP.Telsp.com:5061	LGW.Chicago.CustomerC.Sip.Telsp.com : 5062
   Nombre maximum d'appels simultanés (250-6500)	500	500

   • (Facultatif) Les noms des tronçons ne doivent pas nécessairement être uniques selon les organisations clientes. Le fait de réutiliser le même nom (par exemple, trunk_miami) facilite le suivi du coffre.

   • Certains 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. Identité par certificat...

   • Préfixe : le préfixe est facultatif. Laissez ce champ vide pour attribuer l'identité du certificat Peer au domaine uniquement. Il s'agit du modèle de certificat partagé utilisé dans cet article (Peer Cert Identity—sip.telsp.com, couvrant tous les troncs clients). Si vous le souhaitez, entrez un préfixe pour définir une identité de certificat plus spécifique (par exemple, préfixe : CustomerB, domaine : CustomerB.SIP.Telsp.com pour un certificat par client). Le nom de domaine complet du tronc lui-même reste défini par les champs adresse SBC, nom d'hôte et domaine et doit correspondre à l'identité du certificat Peer qui en résulte ou en être un sous-domaine.

     Exemple :

     Préfixe : client B

     Domaine : SIP.TELSP.com

     Résultat : Customerb.sip.telsp.com

   • Domaine : sélectionnez un domaine dans la liste des domaines vérifiés par l' organisation cliente. L'identité du certificat Peer qui en résulte (préfixe + domaine) doit correspondre au CN ou au SAN du certificat présenté par votre SBC. Webex Callingutilise cette valeur pour authentifier la connexion TLS.

     

     Control Hub rejette cette configuration au moment de la sauvegarde car le nom de domaine complet du trunk ne correspond pas à l'identité de certificat Peer configurée.

     Si l'identité du certificat Peer ne correspond pas à celle du CN ou du SAN figurant sur le certificat présenté par le SBC, si la connexion TLS est Webex Calling rejetée et que le tronc ne s'établit pas.

5. À l'aide de troncs : choisissez l'emplacement du coffre de votre choix, pour les raisons suivantes :

   • N'importe où peut utiliser le tronc pour une connexion PSTN.

   • Vous pouvez accéder au coffre par le biais d'un groupe de routes.

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

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

   

   Vous pouvez utiliser ces troncs pour créer des groupes d'itinéraires. Sur l'image, un groupe de routes rg_miami_chicago est défini. Il achemine les appels vers le tronc trunk_miami en tant qu'option principale et vers le tronc trunk_chicago en tant qu'option secondaire.

   

   Vous pouvez définir un deuxième groupe d'itinéraires rg_chicago_miami qui achemine les appels vers le tronc trunk_chicago en tant qu'option principale et vers le tronc trunk_miami en tant qu'option secondaire.

7. Les lignes et les groupes de routes définis sont désormais disponibles dans l'option Calling Connection PSTN pour chaque lieu. Sur la photo, voir la succursale de Denver .

   

8. Vous pouvez utiliser les lignes et les groupes d'itinéraires 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 rejoindre le groupe de routes rg_chicago_miami (pour toutes les destinations) sur l'image :

   

   

Fourniture à grande échelle avec des API

Les partenaires qui gèrent un grand nombre d'organisations clientes peuvent fournir des domaines à grande échelle à l'aide d'API plutôt que de l'interface utilisateur.

• Vérifier le domaine

• Routage des appels