Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

Console de réception à distance à travers un pare-feu

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Le Cisco Unified CallManager Attendant Console intègre des fonctions traditionnelles de téléphonie du multiplexage temporel (TDM) avec des applications avancées et des services de Téléphonie sur IP, tels que le répertoire de Protocole LDAP (Lightweight Directory Access Protocol). Un avantage primaire de Cisco Unified CallManager Attendant Console au-dessus des systèmes traditionnels d'attendant-console est la capacité de surveiller l'état de chaque ligne dans le système et d'acheminer efficacement des appels.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Cisco CallManager 4.x

  • Console de réception 1.4 de Cisco

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Ports utilisés par la console de réception

Transmission entre le client à C.A. et le serveur Cisco CallManager

Il y a trois types de transmission entre le client et serveur à C.A. :

  • Le client à C.A. au protocole RMI (RMI) — le client se connecte toujours au RMI aux ports de serveur 1099 à 1129. Puis, le serveur dit le client d'établir une deuxième session TCP avec le serveur sur un deuxième port TCP. Ce port est aléatoirement pris et il n'y a aucune manière de garantir qu'un port TCP particulier est toujours utilisé.

  • Client à C.A. au codage rapide de mémoire tampon (QBE) dans le gestionnaire du couplage de la téléphonie et de l'informatique (CTI) — la transmission QBE établit une session TCP avec le serveur au port TCP 2748.

  • Le client à C.A. au serveur d'état de la ligne (LSS) — dans ce cas, là est le trafic de l'UDP LSS qui provient les serveurs. Ceci peut être réparé dans la boîte de dialogue de paramètres avancés (voyez la solution pour recevoir l'état de ligne à travers une section de Pare-feu). Les ports spécifiés dans la boîte de dialogue de paramètres de services sont utilisés par Cisco CallManager pour écouter des demandes du détail d'appel d'arrêt (TCD), pour initialiser les clients à C.A. et pour offrir les informations d'état de la ligne aux clients. Ces ports TCP ne doivent pas être changés.

Un Pare-feu n'est pas pris en charge parce que le courant alternatif utilise les ports aléatoires pour des connexions RMI. Seulement un port disponible est utilisé pour initier la connexion RMI, qui commence par 1099. Après que la connexion RMI soit établie, le RMI utilise un port TCP aléatoire (normalement le premier port disponible). , Assurez-vous par conséquent que n'importe quel les ports TCP est ouvert dans jusqu'en 1129 la plage 1099. Si ces ports aléatoires ne sont pas ouverts, le courant alternatif échoue avec ce message d'erreur :

error communicating with the server

Référez-vous à ces documents pour plus d'informations sur l'utilisation de port de TCP et UDP de Cisco CallManager pour la console de réception :

Console de réception et NAT

Dans une console de réception de Cisco, l'état de la ligne et le statut de transfert d'appels de la ligne principale de chaque utilisateur est présenté avec chaque entrée record. Quand vous utilisez le Cisco CallManager et la console de réception à travers des interfaces de Traduction d'adresses de réseau (NAT), ou quand un Pare-feu est entre elles, le trafic TCP fonctionne correctement avec le transversal NAT. Par conséquent, la majeure partie de la fonctionnalité à C.A. fonctionne. Cependant, le problème est pour l'état de ligne de console de réception qui utilise l'UDP. En outre, le trafic UDP des CallManagers ne peut pas traverser les interfaces NAT.

Solution pour recevoir l'état de ligne à travers un Pare-feu

La console de réception de Cisco utilise des ports UDP pour l'état de la ligne. Le port UDP qui devrait être utilisé peut être configuré dans la boîte de dialogue de paramètres avancés de la console de réception de Cisco. Si aucun port n'est configuré, le courant alternatif utilise le premier port UDP disponible (aléatoire).

Si un port UDP est spécifié, comme le port 1234 (voir le schéma 2), s'assurent que ce port est ouvert dans le Pare-feu aussi.

Terminez-vous ces étapes afin de configurer le port UDP utilisé :

  1. Procédure de connexion à la console de réception.

  2. Choisissez éditent > des configurations.

    /image/gif/paws/71668/attendant-firewall-1.gif

  3. Dans la fenêtre externe, cliquez sur avancé et changez le champ IP Address d'hôte local à 172.16.1.1:1234 si l'adresse IP du PC de console de réception est 172.16.1.1 et le port UDP est 1234.

    /image/gif/paws/71668/attendant-firewall-2.gif

  4. Cliquez sur Save.

  5. Déconnexion pour que les nouveaux paramètres les prennent effet.

    Remarque: Le courant alternatif n'a pas été conçu pour fonctionner avec un Pare-feu ou NAT. Cependant, il y a une bogue de demande de caractéristique classée pour verrouiller en bas de la plage de port. Référez-vous au pour en savoir plus de l'ID de bogue Cisco CSCee21603 (clients enregistrés seulement).

    Pour l'instant, le seul contournement pour cette question est à débloquent les ports TCP utilisés ou désactivent le Pare-feu.


Informations connexes


Document ID: 71668