Internet public

Tronc SIP direct (en haut de la page)

Le CUBE ou SBC du client doit être placé sur une IP publique. Il s'agit de notre modèle de déploiement standard recommandé.

Cette approche étant la plus simpliste, elle est également la moins flexible. Les avantages d'une topologie simplifiée sont la facilité de gestion et de dépannage. Les diagrammes de réseau sont remplis par le client et soumis à l'équipe vocale, et des pairs de numérotation sont créés. Placer le CUBE dans une DMZ soulage les complexités du traitement avec NAT. Le CUBE lui-même est un pare-feu, et la plupart des fournisseurs moyens/grands placent leur CUBE dans une IP publique et utilisent ses capacités de sécurité.

VPN

Un VPN est un autre type de connexion qui utilise l'Internet public. Les VPN sont souvent nécessaires lorsqu'un client a besoin d'une connexion sécurisée pour SIP et RTP. Un VPN peut également être requis si le client ne peut pas placer le CUBE dans un espace IP public. Une réunion de provisionnement avec l’ingénierie vocale est requise pour les connexions VPN.

Ports vocaux

• rtp : 8000 - 48199

• SIP : udp 5060

VPN IPSec ou IPSec sur GRE

Les options suivantes sont disponibles pour la connectivité VPN :

• Connectivité SBC à SBC

• Connectivité GW à GW

Webex Contact Center (IPSec ou IPSec sur le tunnel GRE et connectivité Webex Contact Center S2S) à utiliser UDP/5060 au lieu de TCP/5060

Un VPN IPSec ou IPSec sur GRE est une bonne option pour un tronc SIP sécurisé lorsque le CUBE est sur une IP publique. Il s’agit d’une connexion SBC à SBC. (Fig 2) avec les tunnels VPN, les schémas d’adresses IP privées doivent également être pris en compte pour éviter tout chevauchement entre les clients. Pour les connexions GRE, les sous-réseaux IP sont : 10.x.248.x et 10.x.249.x.

Site à site (S2S)

Une connexion S2S peut être déployée si le client a besoin d'une connexion sécurisée ou ne peut pas placer le CUBE dans une IP publique. Il s'agit d'une connexion passerelle à passerelle. Il n'existe pas de sous-réseaux spécifiquement désignés pour les connexions VPN S2S car le routage est basé sur un trafic intéressant sans l'intervention d'une interface logique.

SIP TLS et SRTP

L'utilisation de TLS SRTP/SIP est une autre option lorsque le CUBE est sur une adresse IP publique. Cependant, il y a un succès de performance pour l'utilisation de TLS SRTP/SIP. Un périphérique CUBE peut gérer un tiers des sessions SIP si vous avez sécurisé les appels en utilisant TLS ou SRTP. Il s'agit d'une connexion SBC à SBC.

Afin d'établir une connexion SIP TLS, il est nécessaire d'échanger des certificats. Les options suivantes sont disponibles :

• Les certificats auto-signés sont générés et échangés entre le client et Webex Contact Center.

• Autorité de certification publique – les étapes suivantes doivent être effectuées pour soutenir l’autorité de certification publique :

  • Le client doit partager le certificat racine qui sera chargé dans le Webex Contact Center SBC.

  • Le client doit mettre à jour le DNS pour inclure les adresses IP des SBC du centre de contact Webex.

Connectivité privée

Souvent le choix de la connexion des fournisseurs de grandes entreprises, une connexion directe fournit un circuit dédié et sécurisé. Si le client a besoin d'une connexion directe, il peut recevoir le document Directives de commande de circuit VPOP de Cisco Webex Contact Center comme étape initiale, et une réunion de conception de suivi avec l'équipe d'ingénierie vocale de Webex Contact Center et les ingénieurs du client doit être organisée comme étape suivante. Le client doit fournir un diagramme de réseau détaillé du réseau vocal du client incluant les interconnexions de l’opérateur RTCP pour la réunion. Cisco n'hébergera aucun équipement client.

Que le client choisisse MPLS, P2P, VPLS ou SD-WAN, la topologie sera similaire et tous les circuits se termineront par le routeur/GW du centre de contact Webex et non par les CUBEs du centre de contact Webex.

Les besoins en bande passante pour une connexion directe sont basés sur le codec G.711 (~100 kbits/s par segment d'appel), ce qui permet deux segments d'appel par session.

Connexion croisée des centres de données

Si un client décide d'une connexion privée, il sera nécessaire de commander des connexions croisées de centres de données comme décrit dans le document Directives de commande de circuits VPOP de Cisco Webex Contact Center. Le client sera responsable des coûts encourus et de l’acheminement du circuit du client jusqu’à la goutte désignée. (Fig 6.)

Déploiements non standard

Si les topologies recommandées ne répondent pas à toutes les exigences du réseau du client, une réunion de conception doit être programmée avec l'équipe d'ingénierie vocale Cisco via l'équipe de compte Cisco du client pour un processus d'approbation spécial. Voici des exemples de déploiements non standard et de déploiements qui ne sont pas recommandés :

Exceptions A2Q

Le fournisseur RTCP termine le circuit directement à Webex Contact Center VPOP.

Exceptions pour les tenants Gold

Nous recommandons fortement une jonction SIP directe pour les clients Gold Tenant. Il s'agit de la topologie supérieure du placement du CUBE dans un espace IP public. Le besoin d'un locataire Gold existe souvent avec des fournisseurs plus importants ; cependant, le fournisseur exige que le locataire Gold soit une preuve de concept pour le déploiement de la production prévu par le fournisseur. La preuve de concept que Gold Tenant dépasse souvent l'utilisation d'un accès Internet ouvert pour une ligne principale SIP et nécessiterait l'un des types de connexion discutés précédemment.

Les clients de Gold Tenant ne seront pas surveillés.

Internet public – CUBE derrière le pare-feu

Placer un CUBE sur une adresse IP privée derrière un pare-feu NAT est une autre option de déploiement. Les exigences de sécurité du service informatique du client peuvent stipuler que l’application vocale est derrière un pare-feu. Cette option présente quelques inconvénients connus. Même si cela ne cause pas de problèmes dans la couche réseau, cela peut entraîner des problèmes dans la couche de l'application SIP. L'adresse IP privée est utilisée dans les messages SIP, ce qui cause des échecs de traitement des appels. La capacité du pare-feu est un autre facteur à prendre en compte pour ce type de déploiement. Les pare-feux doivent être dimensionnés de manière appropriée pour gérer le trafic VoIP ; le pare-feu peut sinon devenir un goulot d'étranglement et avoir un impact sur la qualité et le traitement des appels.

Les inconvénients de ce déploiement sont les suivants :

• Problèmes possibles de configuration et d’installation de CUBE au début.

• Charge accrue sur le pare-feu qui pourrait avoir un impact sur la qualité vocale.

• Le client est responsable de la configuration CUBE et du dimensionnement du pare-feu.

• Topologie non recommandée en raison de l'impact sur les SLA.