Méthodes de connectivité réseau prises en charge

Public internet est la méthode par défaut pour la connectivité réseau.

Les tunnels VPN/IPSec et la configuration du SBC sont requis pour cette Option.

Pour plus d'informations, consultez Real-Time Third Party Telephony Recording (Multi-ACD).

Vue d’ensemble

Cato SD-WAN est pris en charge pour une connectivité sécurisée et privée entre votre centre de données et NiCE CXone Engagement Hub (Multi-ACD/Open).

SD-WAN (Software Defined Wide Area Network) utilise un routage centralisé basé sur des stratégies pour envoyer le trafic sur le meilleur chemin disponible en temps réel et prioriser les applications importantes (telles que la voix et la CTI).

Cato Networks fournit des appliances SD-WAN Edge appelées Cato Sockets. Vous êtes responsable du choix des sockets qui correspondent à vos besoins en termes de performances et de ports.

Modèles de connectivité

Il existe deux des modèles de connectivité pris en charge disponibles. Wait, let me reconsider for fluency. Deux des modèles de connectivité pris en charge sont disponibles.

Modèle 1 : CTI sur VPN IPSec + SIP/SRTP sur Cato SD-WAN

• Le trafic CTI passe par un VPN IPSec / Internet entre votre site et NiCE. Vous gérez la configuration NAT et IPSec pour CTI.

• Le trafic SIP/SRTP transite par Cato SD-WAN. Cato gère le NAT et transmet le SIP/RTP à NiCEdans AWS.

Modèle 2 : CTI, SIP, SRTP, tout via Cato SD-WAN

• Tout le trafic pertinent (CTI, SIP, RTP) passe par les Cato Sockets.

• Cato NAT et le routage assurent la connectivité à NiCE dans AWS pour tous les flux.

• Ce modèle simplifie votre connectivité, car tous les médias voix et la CTI utilisent le même chemin.

Conditions du client

Pour fournir une connexion stable et résiliente, vous devez respecter les exigences suivantes lors du déploiement des Cato Sockets.

Disponibilité élevée et WAN

• **Sockets HA par centre de données**

  Déployez une paire de Cato Sockets en haute disponibilité (HA) dans chaque centre de données.

  Deux centres de données nécessitent deux paires HA (une paire par site).

• Circuits WAN / Internet redondants

  Fournissez au moins deux circuits Internet ou WAN redondants sur chaque site.

  Cela permet la prise en charge du basculement de chemin et maintient la disponibilité du service pendant les interruptions.

• Adresses IP Public uniques pour les tunnels

  Attribuez à chaque socket d'une paire HA une adresse IP WAN publique unique.

  Ces adresses IP sont utilisées pour établir des tunnels DTLS sécurisés vers le PoP Cato le plus proche.

• **Câblage symétrique**

  Utilisez un câblage LAN et WAN en miroir sur les deux prises de chaque paire HA afin de garantir un comportement de basculement correct et des performances cohérentes.

Responsabilités spécifiques au modèle

Modèle 1 : Vous êtes responsable de la configuration et de la maintenance de NAT et IPSec pour CTI.

Modèle 2 : Tout le trafic passe par Cato NAT.

Configuration

L'équipe NiCE Services Professionnels travaillera avec vous pour effectuer ces étapes dans le portail Cato.

Pour plus d'informations, consultez Cato Networks Knowledge Base.

Étape 1 : Déployer et Enregistrer les sockets Cato

1. Montez en rack, raccordez à l'alimentation et câblez les sockets dans chaque centre de données.

2. Ajoutez-les au Cato Cloud et attribuez chaque paire au Site approprié.

3. Assurez-vous que chaque site est configuré en tant que déploiement HA, et que chaque socket utilise une adresse IP publique unique.

Étape 2 : Configurer les réseaux LAN

1. Dans le portail Cato Orchestration, ajoutez les plages LAN qui contiennent :

   • Vos SBC

   • Serveurs médias

   • CTI servers (pour le Model 2, et pour tous les flux qui doivent traverser Cato)

2. Chaque centre de données doit disposer de son propre placer, ainsi que de ses propres définitions de réseau LAN.

Étape 3 : Allouer des adresses IP Public pour NAT

1. Dans le portail d'orchestration Cato, allouez deux Adresses IP publiques par site pour la NAT.

   Les licences de base autorisent généralement jusqu'à 3 IP par compte ; des adresses supplémentaires peuvent entraîner des frais supplémentaires.

2. Choisissez l'emplacement PoP le plus proche pour placer chaque site, afin d'obtenir les meilleures performances.

Étape 4 : Configurer les Règles de Réseau Internet (sortant)

1. Dans le portail d'orchestration Cato, pour chaque placer :

   1. Utilisez les deux IP NAT que vous avez allouées pour maintenir la haute disponibilité (HA) au niveau du PoP.

   2. Définissez Source sur les réseaux LAN SBC, média et (si pertinent) CTI.

   3. Créez des Applications personnalisées selon les besoins pour :

      • NiCE CXone Engagement Hub (Multi-ACD/Open) Adresses IP et ports de signalisation

      • NiCE IP de média / plages RTP

      • IP NAT du pare-feu CTI (modèle 2 uniquement)

   4. Définissez une priorité de bande passante élevée pour SIP/RTP et CTI.

   5. Sélectionnez la méthode NAT et associez-la aux deux adresses IP POP allouées les plus proches.

   6. Conservez une règle Internet par défaut pour tout autre trafic sortant depuis votre LAN.

Étape 5 : configurer le pare-feu Internet (SIP/RTP)

1. Dans le portail Cato Orchestration, dans la zone Sécurité, créez des règles d'autorisation :

   • Source : vos adresses IP de SBC (et adresses IP de média si nécessaire)

   • Destination : NiCE CXone Engagement Hub (Multi-ACD/Open) IP du SBC

   • Service/Ports : SIP et RTP tel que défini par NiCE

2. Veillez à ce qu'une règle de refus implicite reste en bas afin de bloquer tout autre trafic.

Étape 6. Configurer la redirection de port Distant (entrant)

Pour le trafic entrant, tel que le CTI de NiCE vers votre environnement (en particulier dans le modèle 2) :

1. Dans le Cato Orchestration Portal, dans la zone Sécurité, créez des règles qui :

   1. Utilisez les IP/ports de PoP Cato exposés à NiCE.

   2. Transférer vers vos serveurs CTI internes ou vos SBC sur les ports requis.

   Cela garantit que les actualisations CTI et SIP entrantes sont correctement acheminées vers vos systèmes.

2. Pour le modèle 2, NiCE met à jour Engagement Hub (Multi-ACD/Open) règles de pare-feu VPN pour autoriser le trafic CTI depuis NiCE serveurs CTI vers vos adresses IP de PoP Cato définies dans ces règles.

Étape 7 : validation et Tests avec NiCE Services Professionnels

Une fois la configuration terminée, planifiez une session de test conjointe avec votre équipe et NiCE Services Professionnels.

Après la validation, la connectivité Cato SD-WAN est considérée comme prête pour une utilisation en production avec NiCE Engagement Hub (Multi-ACD/Open).

Vue d’ensemble

AWS Public Direct Connect est un service de réseau dédié qui crée une connexion privée entre votre centre de données et AWS. Cette connexion n'utilise pas l'Internet public, elle offre donc des performances plus stables et un délai plus faible.

Cette procédure décrit comment configurer un modèle Bring Your Own Connectivity (BYOC) à l'aide de AWS Public Direct Connect pour Engagement Hub (Multi-ACD/Open). Cela permet à votre signalisation CTI (Computer Telephony Integration) et à votre trafic média SIP/RTP de transiter par un chemin privé et dédié.

Modèles de connectivité

Il existe trois des modèles de connectivité disponibles :

Modèle 1 : CTI via IPSec VPN (VPN via Internet ouvert) + SIP/SRTP via AWS Public Direct Connect

Le trafic CTI passe par un tunnel VPN via internet, tandis que le média voix (SIP/SRTP) circule via la liaison Direct Connect.

Modèle 2 : CTI, SIP & SRTP sur l'ensemble de AWS Public Direct Connect

Tout le trafic (signalisation CTI et média voix) transite par la liaison Direct Connect.

Modèle 3 : CTI via VPN IPSec (VPN via AWS Public Direct Connect) et SIP/SRTP via AWS Public Direct Connect

Utilisez votre connexion AWS Public Direct Connect existante pour établir un tunnel IPsec exclusivement destiné au trafic CTI. Le trafic SIP et RTP continuera de circuler directement via AWS Public Direct Connect, en dehors du tunnel IPsec.

Conditions préalables

Avant de commencer, confirmez les points suivants :

AWS Compte : Vous disposez d'un compte AWS actif avec les autorisations nécessaires pour provisionner des ports Direct Connect et des interfaces virtuelles.

Planification de la bande passante : Vous avez déterminé la bande passante requise en fonction de votre volume d'appels. AWS Public Direct Connect prend en charge des débits de 50 Mbps jusqu'à 400 Gbps.

Haute disponibilité : Il est recommandé de concevoir en vue de la haute disponibilité. AWS recommande au moins deux circuits Direct Connect par centre de données pour assurer la redondance.

Public Adresses IP : Vous disposez d'un espace d'adresses IPv4 publiques disponible pour l'appairage BGP (Border Gateway Protocol). Vous pouvez utiliser vos propres adresses IP publiques ou demander des adresses IP homologues auprès de AWS (à un coût supplémentaire).

Préfixe IP client : Vous connaissez le préfixe IP public que vous prévoyez d'annoncer à AWS (/29, /28, /30). Il s'agit des plages d'adresses IP NAT (Network Address Translation) ou publiques utilisées par vos connexions SBC et CTI.

Plateformes ACD prises en charge : Cette configuration prend en charge les intégrations Cisco (JTAPI) et Avaya (DMCC et SIPREC).

Connexion dédiée ou hébergée ? Choisissez entre une connexion dédiée ou une connexion hébergée. Une connexion dédiée est une liaison physique directe vers AWS et nécessite généralement plus de temps pour sa mise en place. Une connexion hébergée utilise un fournisseur partenaire et est plus rapide à déployer. Les deux options sont prises en charge.

Pour le modèle 3 (CTI via IPSec VPN (VPN via Direct Connect Public AWS) et SIP/SRTP via Direct Connect Public AWS), vous devez également disposer de :

• Une interface virtuelle (VIF) Public Direct Connect active avec une session BGP établie.

• Le routeur sur site doit annoncer le préfixe IP public contenant le terminal IPsec.

• Le préfixe annoncé doit réussir le processus standard de vérification des préfixes publics Direct Connect.

• L'adresse IP du terminal IPsec doit se situer dans la plage du préfixe annoncé.

 

Configuration

Pour plus d'informations, consultez le AWS Direct Connect User Guide.

Étape 1 : Créer le lien Direct Connect

1. Connectez-vous à AWS Gestion Console et ouvrez le service Direct Connect.

2. Créez une nouvelle connexion et sélectionnez l'emplacement le plus proche de votre centre de données.

3. Choisissez la vitesse du port en fonction de vos besoins en bande passante.

4. Si vous souhaitez une haute availability, créez au moins deux connexions.

5. Terminez le processus de configuration avec votre fournisseur réseau. Cela comprend l'établissement de la connexion physique entre votre centre de données et AWS.

Étape 2 : Créer une Interface virtuelle (VIF) Public

Un VIF Public vous permet d'accéder à AWS services publics (y compris les points de terminaison publics CXone) via Direct Connect.

1. Pour créer le VIF Public, vous devez définir les éléments suivants :

   • une VLAN

   • votre ASN BGP

   • Adresse IP homologue de votre routeur

   • Amazon IP du routeur homologue (AWS la fournit, ou vous précisez la vôtre à partir de votre bloc d'adresses IP public)

   • le préfixe IP public que votre réseau annoncera à AWS

2. Une fois que vous avez soumis la configuration Public VIF, AWS provisionne l'interface et la prépare pour le routage.

Étape 3 : Configurer Routing avec BGP

BGP (Border Gateway Protocole) est le protocole de routage qui échange des informations de routage entre votre réseau et AWS.

1. Sur votre routeur Edge ou votre pare-feu, configurez une session BGP avec l'IP homologue Amazon et l'ASN.

2. Annoncez votre préfixe IP public (la plage NAT/publique pour vos systèmes SBC et CTI).

   Annoncez uniquement les Adresses IP Public utilisées pour le trafic Engagement Hub (Multi-ACD/Open). N'annoncez pas de plages d'adresses IP Large ou sans rapport. Si vous annoncez trop d'adresses IP, d'autres types de trafic risquent de commencer à utiliser Direct Connect. Cela peut entraîner des problèmes de routage et augmenter l'utilisation de la bande passante.

3. Filtrez soigneusement les routes entrantes. AWS annonce toutes ses plages d'adresses IP publiques via Public DX. Vous devez restreindre votre routage afin d'accepter uniquement les préfixes nécessaires pour Engagement Hub (Multi-ACD/Open). Dans certaines régions, les services Professionnels de NiCE fournissent des plages d'adresses IP publiques spécifiques pour les adresses IP des serveurs CTI, les adresses IP de signalisation SBC et les adresses IP des composants Média.

   Si vous acceptez trop de routes, vous risquez de perturber le routage de votre réseau ou d'envoyer du trafic indésirable via Direct Connect.

4. Vérifiez que la session BGP s'établit et que les routes sont échangées. Vous pouvez vérifier l'état BGP dans la console AWS Direct Connect.

Étape 4 : Configurer votre équipement Réseau

Pare-feu client

1. Autorisez le trafic sortant et entrant pour les protocoles et ports suivants sur votre préfixe IP public :

   1. Trafic CTI : TCP sur le ou les ports utilisés par votre ACD (par exemple, JTAPI pour cisco, DMCC pour avaya).

   2. Signalisation SIP : port UDP/TCP 5060 (SIP) ou 5061 (SIP-TLS).

   3. Média RTP/SRTP : plage de ports UDP telle que définie par la configuration de votre SBC.

2. Si vous utilisez le modèle 1 (CTI sur VPN), configurez un tunnel VPN IPsec entre votre pare-feu et le terminal VPN NiCE uniquement pour le trafic CTI. Le média SIP/SRTP transite directement via la liaison Direct Connect.
   

   Si vous utilisez le modèle 3 (CTI via IPSec VPN (VPN sur AWS Public Direct Connect)), utilisez votre connexion Public Direct Connect existante pour établir un tunnel IPSec exclusivement destiné au trafic CTI. Le trafic SIP et RTP continuera de circuler directement via AWS Public Direct Connect, en dehors du tunnel IPSec.

SBC (Session Border Controller) client

1. Configurez votre SBC afin d'acheminer la signalisation SIP et les médias RTP/SRTP vers les Adresses IP publiques fournies par NiCE Professionnel Services (SC EIP pour la signalisation, MC EIP pour le média).

2. Assurez-vous que le SBC utilise l'Adresse IP publique de votre préfixe annoncé comme adresse source.

3. Toute communication sur la liaison Public Direct Connect doit utiliser un espace d'adressage IPv4 public. Les adresses privées (RFC 1918) ne fonctionnent pas sur une interface virtuelle (VIF) publique.

Étape 5 : Coordonner avec les Services Professionnels NiCE

Contactez NiCE Services Professionnels pour partager :

• L'adresse de préfixe IP publique que vous annoncez à AWS.

• La région AWS à laquelle vous vous connectez.

• Votre modèle de connectivité choisi (modèle 1, 2 ou 3).

NiCE Services professionnel vous fournit :

• Adresses IP publiques du serveur CTI

• IP publiques de signalisation SBC

• Adresses IP publiques du composant média

Étape 6 : Configurez votre Intégration ACD

Pour Cisco (JTAPI)

1. Dans le portail d'administration NiCE CXone, configurez le système téléphonique avec les détails de connexion Cisco JTAPI (adresse IP du serveur, identifiants, postes).

2. Vérifiez que le trafic CTI (événements d'appel, signaux de mise en attente/reprise) atteint les serveurs CTI CXone via le VPN (modèle 1 ou 3) ou la liaison Direct Connect (modèle 2).

Pour Avaya (DMCC & SIPREC)

1. Configurez l'intégration Avaya DMCC ou SIPREC dans NiCE CXone avec les informations serveur appropriées.

2. Vérifier que le trafic de signalisation et de média est correctement acheminé via la liaison Direct Connect.