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

Internet public est la méthode par défaut pour la connectivité réseau.

Des tunnels VPN/IPSec et une configuration 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é privée et sécurisée entre votre centre de données et NiCE CXone Engagement Hub (Multi-ACD/Open).

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

Cato Networks fournit des appliances Edge SD-WAN appelées Cato Sockets. Vous êtes responsable de choisir les sockets qui correspondent à vos besoins en matière de performance et de ports.

Modèles de connectivité

Il existe deux modèles de connectivité pris en charge.

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

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

• Le trafic SIP/SRTP passe par le SD-WAN Cato. Cato gère le NAT et livre le SIP/RTP à NiCE dans AWS.

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

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

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

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

Exigences client

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

Haute disponibilité et WAN

• Sockets HA par centre de données

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

  Exemple : 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 à chaque site.

  Cela permet la reprise sur incident du chemin et maintient la disponibilité du service pendant les interruptions.

• adresses ip Public uniques pour les tunnels

  Attribuez à chaque prise d'un couple HA une adresse ip WAN publique unique.

  Ces adresses ip sont utilisées pour établir des tunnels DTLS sécurisés vers le point de présence (PoP) Cato le plus proche.

• Câblage symétrique

  Utilisez un câblage LAN et WAN en miroir sur les deux prises de chaque couple HA pour assurer un comportement de basculement correct et une performance uniforme.

Responsabilités propres à chaque modèle

Modèle 1 : Vous êtes responsable de la configuration et de la maintenance de NAT et d'IPSec pour la CTI (if spelled out, then « continuité des activités de TI »).

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

Configuration

L'équipe des services Professionnel NiCE travaillera avec vous pour effectuer ces étapes dans le portail Cato.

Pour en savoir plus, consultez la Base de connaissances de Cato Networks.

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

1. Installez en armoire, alimentez et câblez les sockets dans chaque centre de données.

2. Ajoutez-les au Cato Cloud et attribuez chaque couple 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 d'orchestration Cato, ajoutez les plages LAN qui contiennent :

   • Vos SBC

   • Serveurs média

   • Serveurs CTI (pour le Modèle 2, et pour tous les flux qui doivent traverser Cato)

2. Chaque centre de données doit avoir son propre site et ses propres définitions de réseau LAN.

Étape 3 : Allouer des adresses ip Public pour le NAT

1. Dans le portail Cato Orchestration Portal, allouez deux Adresses ip Public par site pour le NAT.

   Les licences de base permettent généralement jusqu'à 3 adresses ip par compte ; des adresses supplémentaires peuvent entraîner des coûts additionnels.

2. Choisissez l'emplacement du PoP le plus proche de chaque site pour obtenir la meilleure performance.

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

1. Dans le portail Cato Orchestration Portal, pour chaque site :

   1. Utilisez les deux adresses ip NAT que vous avez allouées pour maintenir la HA au niveau du PoP.

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

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

      • NiCE CXoneEngagement Hub (Multi-ACD/Open) Adresses ip et ports de signalisation

      • NiCE Adresses ip média / plages RTP

      • Adresses 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 de PoP allouées les plus proches.

   6. Conservez une règle Internet par défaut pour tout autre trafic sortant de votre réseau local (LAN).

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

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

   • Source : vos adresses ip SBC (et adresses ip média si requises)

   • Destination : NiCE CXoneEngagement Hub (Multi-ACD/Open) adresses ip SBC

   • Service/Ports : SIP et RTP tels que définis par NiCE

2. Assurez-vous qu'une règle de refus implicite demeure au bas de la liste pour bloquer tout autre trafic.

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

Pour le trafic entrant, comme le CTI, de NiCE vers votre environnement (particulièrement dans le modèle 2) :

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

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

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

   Cela garantit que les rafraîchissements CTI et SIP entrants sont acheminés correctement vers vos systèmes.

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

Étape 7 : validation et Tests avec les Services Professionnels NiCE

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

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 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, ce qui offre des performances plus stables et un délai plus faible.

Cette procédure décrit comment configurer un modèle Apportez votre propre connectivité (BYOC) à l'aide de AWS Public Direct Connect pour Engagement Hub (Multi-ACD/Open). Cela permet à votre signalisation CTI (continuité des activités de TI) et à votre trafic multimédia SIP/RTP de transiter par un chemin privé et dédié.

Modèles de connectivité

Trois modèles de connectivité sont disponibles :

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

Le trafic CTI transite par un tunnel VPN sur l'internet, tandis que les médias voix (SIP/SRTP) transitent par la liaison Direct Connect.

Modèle 2 : CTI, SIP & SRTP entièrement par AWS Public Direct Connect

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

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

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

Conditions préalables

Avant de commencer, confirmez les éléments suivants :

Compte AWS : Vous disposez d'un compte AWS actif avec les autorisations nécessaires pour approvisionner 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 vitesses de 50 Mbps jusqu'à 400 Gbps.

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

Adresses ip publiques : Vous disposez d'un espace d'adresses IPv4 publiques pour l'appairage BGP (Border Gateway Protocol). Vous pouvez soit utiliser vos propres adresses ip publiques, soit demander des adresses ip de pair à 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 NAT (Network Address Translation) ou des plages d'adresses ip 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 un lien physique direct vers AWS et prend habituellement plus de temps à configurer. Une connexion hébergée utilise un fournisseur partenaire et se déploie plus rapidement. Les deux options sont prises en charge.

Pour le modèle 3 (CTI sur IPSec VPN (VPN sur AWS Public Direct Connect) et SIP/SRTP sur AWS Public Direct Connect), vous avez également besoin de ce qui suit :

• Une interface virtuelle publique 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 du préfixe public Direct Connect.

• L'IP du terminal IPsec doit se situer dans le 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 disponibilité, créez au moins deux connexions.

5. Terminez le processus de configuration avec votre fournisseur de 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 Public (VIF)

Une VIF Public vous permet d'accéder aux services publics de AWS (y compris les terminaux publics CXone) via Direct Connect.

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

   • un VLAN

   • votre ASN BGP

   • l'IP homologue de votre routeur

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

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

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

Étape 3 : Configurer Routing avec BGP

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

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

2. Annoncez votre préfixe d'adresse ip publique (la plage NAT/publique pour vos systèmes SBC et CTI).

   Annoncez uniquement les Adresses ip publiques utilisées pour le trafic Engagement Hub (Multi-ACD/Open). N'annoncez pas de plages IP volumineuses ou non liées. Si vous annoncez trop d'adresses ip, d'autres types de trafic pourraient commencer à utiliser Direct Connect. Cela peut causer 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 pour n'accepter que les préfixes requis pour Engagement Hub (Multi-ACD/Open). Dans certaines régions, les services Professionnels 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 composantes 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 démarre correctement et que les routes sont échangées. Vous pouvez vérifier l'état BGP dans la console Direct Connect AWS.

É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 d'adresse ip publique :

   1. Trafic CTI : TCP sur le(s) port(s) utilisé(s) par votre ACD (par exemple, JTAPI pour Cisco, DMCC pour Avaya).

   2. Signalisation SIP : UDP/TCP port 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 pour le trafic CTI uniquement. Le média SIP/SRTP transite directement via la liaison Direct Connect.
   

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

SBC (Session Border Controller) du client

1. Configurez votre SBC pour acheminer la signalisation SIP et les médias RTP/SRTP vers les Adresses ip publiques fournies par NiCE Services Professionnels (SC EIP pour la signalisation, MC EIP pour les médias).

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'adresses IPv4 publiques. Les adresses privées (RFC 1918) ne fonctionnent pas sur un VIF public.

Étape 5 : Coordonnez-vous avec NiCE Services Professionnels

Communiquez avec NiCE Services Professionnels pour partager :

• Le préfixe IP public que vous annoncez à AWS.

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

• Le modèle de connectivité que vous avez choisi (modèle 1, 2 ou 3).

NiCE Services professionnels vous fournit ce qui suit :

• IP publiques du serveur CTI

• IP publiques de signalisation SBC

• 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, informations d'authentification, postes).

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

Pour Avaya (DMCC et SIPREC)

1. Configurez l'intégration Avaya DMCC ou SIPREC dans NiCE CXone avec les détails de serveur appropriés.

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