Public Internet

Ligne principale SIP directe (via le dessus)

Le CUBE ou le SBC du client doit être placé sur une IP publique. Le modèle de déploiement standard que nous recommandons est respecté.

Comme c'est l'approche la plus simpliste, c'est aussi 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 complétés par le client et soumis à l'équipe vocale, et des terminaux de numérotation dial-peer sont créés. Placer le CUBE dans une DMZ allège les complexités du traitement de NAT. Le CUBE lui-même est un pare-feu, et la plupart des fournisseurs de taille moyenne ou grande placent leur CUBE dans un IP public et utilisent ses capacités de sécurité.

Vpn

Un VPN est un autre type de connexion qui utilise 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 nécessaire si le client ne peut pas placer le CUBE dans un espace de IP public. Une réunion de mise à disposition avec l'équipe d'ingénierie vocale est requise pour VPN connexions.

Ports vocaux

• RTP : 8000 - 48199

• SIP : UDP 5060

IPSec VPN ou IPSec sur GRE

Les options suivantes sont disponibles pour VPN Connectivity :

• Connectivité SBC à SBC

• Connectivité GW à GW

Webex Contact Center (IPSec ou IPSec sur tunnel GRE et Webex Contact Center S2S Connectivity) pour utiliser UDP/5060 au lieu de TCP/5060

Une IPSec VPN ou une IPSec sur GRE est une bonne option pour une ligne principale SIP sécurisée lorsque le CUBE est sur une IP publique. Il s'agit d'une connexion SBC à SBC. (Fig. 2) avec VPN tunnels, des schémas d'adresses de IP privés doivent également être envisagés pour éviter tout chevauchement entre les clients. Pour les connexions GRE IP les sous-réseaux 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 un IP public. Il s'agit d'une connexion de passerelle à passerelle. Il n'y a pas de sous-réseaux spécifiquement désignés pour les connexions S2S VPN car le routage est basé sur un trafic intéressant sans l'implication d'une interface logique.

TLS et SRTP SIP

Utiliser les TLS SRTP/SIP est une autre option lorsque le CUBE est sur une adresse IP publique. Cependant, il y a un gain de performance pour l'utilisation de SRTP/SIP TLS. 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 de TLS SIP, il est nécessaire d'échanger des certificats. Les options suivantes sont disponibles :

• Des 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 prendre en charge l'autorité de certification publique :

  • Le client doit partager le certificat racine, qui sera chargé dans 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 connexion des 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 Cisco Webex Contact Center document Directives de commande de circuit VPOP comme étape initiale, et une réunion de conception de suivi avec l'équipe d'ingénierie vocale du centre de contact Webex et les ingénieurs du client doit être organisée comme étape suivante. Le client doit fournir un schéma de réseau détaillé de son réseau vocal, y compris les interconnexions des opérateurs PSTN, pour la réunion. Cisco n'hébergera aucun équipement client.

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

La bande passante requise pour une connexion directe est basée sur le codec G.711 (~100 kbps par segment d'appel), ce qui permet deux segments d'appel par session.

Connexion croisée du centre de données

Si un client opte pour une connexion privée, il devra commander des connexions croisées de centre de données comme décrit dans le document Directives de commande de circuit VPOP Cisco Webex Contact Center. Le client sera responsable des coûts encourus et de l'acheminement du circuit du client à la chute désignée. (Fig. 6.)

Le document Cisco Webex Contact Center Directives de commande de circuit VPOP sera fourni au client directement pendant le processus d'intégration au cas où cette option de connectivité serait préférée.

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 planifiée avec l'équipe d'ingénierie vocale Cisco par l'intermédiaire de l'équipe des comptes Cisco du client pour une procédure d'approbation spéciale. Voici des exemples de déploiements non standard et non recommandés :

A2Q Exceptions

Fournisseur PSTN mettant fin au circuit directement sur Webex centre de contacts VPOP.

Exceptions de service partagé Gold

Nous recommandons fortement une ligne principale SIP directe pour les clients Gold Tenant. Il s'agit de la topologie over-the-top de placer le CUBE dans un espace de IP public. Le besoin d'un locataire Gold existe souvent avec les grands fournisseurs ; toutefois, le fournisseur exige que le locataire Gold soit une preuve de concept pour le déploiement de production prévu par le fournisseur. La preuve de concept 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 décrits précédemment.

Les clients Gold Tenant ne seront pas surveillés.

Internet public – CUBE derrière un pare-feu

Placer un CUBE sur une adresse de 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 doit être placée derrière un pare-feu. Cette option présente quelques inconvénients connus. Même si cela peut ne pas causer de problèmes au niveau de la couche réseau, cela peut entraîner des problèmes dans la couche d'application SIP. L'adresse IP privée est utilisée dans les messages SIP, ce qui provoque 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-feu doivent être dimensionnés de manière appropriée pour gérer le trafic VoIP. Dans le cas contraire, ils risquent de devenir des goulots d'étranglement et d'affecter la qualité et le traitement des appels.

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

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

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

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

• Il ne s'agit pas d'une topologie recommandée en raison de son impact sur les SLA.

Cette topologie n'est pas recommandée en raison de la complexité du traitement de SIP et de NAT. Une réunion entre l'équipe d'ingénierie vocale de Cisco et le client est nécessaire pour approuver ce type de déploiement.