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

Étude de cas de déploiement de téléphonie IP : National Bulletin de Singapour

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


Contenu


Introduction

Ce document rend disponible au client, aux Partenaires, et aux employés de Cisco les expériences et le chapitre appris à partir du déploiement de Téléphonie sur IP au bulletin national (NOTA:) à Singapour. Tentatives de ce document :

  • Décrivez et critique la conception de la solution déployée.

  • Identifiez les améliorations possibles à la conception.

  • Compromis de point culminant dans la conception.

La NOTA: est une maison d'édition globale. L'exécution de Singapour se compose d'approximativement 6,000 ventes, d'impression, et de personnel d'écriture. Le personnel NOTA: réside dans un certain nombre des immeubles de bureau situés dans la même proximité. Vers la fin de 2000, la NOTA: a ajouté un autre bâtiment, le bâtiment DBS, à leur campus. Ce bâtiment supplémentaire loge 750 employés. Plutôt que déploient un autocommutateur privé (PBX) dans le nouveau bâtiment, NOTA: décidée pour déployer une solution de Téléphonie sur IP. En soi, le déploiement de prairie inclut la partie du réseau.

La solution de Téléphonie sur IP NOTA: est une conception de site unique. Tous les utilisateurs de Téléphonie sur IP se trouvent dans le bâtiment DBS, et sont distribués à travers cinq planchers. Des passerelles de Cisco CallManagers, de réseau téléphonique public commuté (PSTN), et la messagerie vocale sont également physiquement situées dans le bâtiment DBS.

Un lien de réseau d'étendu (WAN) connecte le DBS construisant au NBAP établissant moins de 1 kilomètre loin. Ce lien WAN porte le trafic de la Voix sur le Protocole Internet (VoIP) à travers à NBAP, où une passerelle se connecte dans le réseau mondial NOTA: PBX. Ce diagramme affiche les bâtiments DBS et NBAP.

/image/gif/paws/13968/65363.gif

Infrastructure LAN de campus

L'infrastructure LAN DBS se compose d'un commutateur du Catalyst 6509 au centre et de neuf Commutateurs du Catalyst 4006 dans les armoires de câblage. Cette table affiche comment le commutateur du Catalyst 6509 est rempli.

-
Emplacement Module Description
1 WS-X6K-SUP1A-MSFC Superviseur avec la carte de commutation multicouche (MSFC)
2 WS-X6K-S1A-MSFC2/2 Superviseur avec MSFC
3 WS-X6416-GBIC module 16-port GE
4 WS-X6408A-GBIC module 8-port GE
5 WS-X6348-RJ45V module 48-port 10/100 avec l'alimentation en ligne
6 WS-X6608-E1 passerelle de l'E1 8-port
7 WS-X6624-FXS passerelle du Foreign Exchange Station 24-port (FXS)
8 WS-X6624-FXS passerelle 24-port FXS
9 Vide

Cette table affiche comment les Commutateurs du Catalyst 4006 sont remplis.

Emplacement Module Description
1 WS-X4013 Superviseur 2 avec deux ports de Gigabit Ethernet (GE)
2 WS-X4148-RJ45V module 48-port 10/100 avec l'alimentation en ligne
3 WS-X4148-RJ45V module 48-port 10/100 avec l'alimentation en ligne
4 WS-X4148-RJ45V module 48-port 10/100 avec l'alimentation en ligne
5 WS-X4148-RJ45V module 48-port 10/100 avec l'alimentation en ligne
6 WS-X4148-RJ45V module 48-port 10/100 avec l'alimentation en ligne

La capacité totale de l'infrastructure LAN est de connecter et actionner 2,160 Téléphones IP.

Les Commutateurs du Catalyst 4006 se connectent de nouveau au Catalyst 6509 par un des ports de GE sur le superviseur, d'une mode pure d'en étoile. Quatre des cinq planchers ont deux Commutateurs du Catalyst 4006 tandis que le cinquième plancher a un commutateur du Catalyst 4006. Ce diagramme montre comment les Commutateurs sont répandus à travers les planchers et comment ils se connectent de nouveau au commutateur du Catalyst 6509.

/image/gif/paws/13968/65364.gif

Le Catalyst 6509 constitue un point de défaillance unique sérieux. Une amélioration significative dans la Disponibilité peut être réalisée en ajoutant un deuxième Catalyst 6509, et attachement secouru "dual homing" que les Commutateurs du Catalyst 4006 à chacun des deux noyau commutent utilisant le port supplémentaire de GE sur les superviseurs du Catalyst 4006. Avec cette conception, il y a peu de justification pour la duplication tous les modules dans le Catalyst 6509. En revanche, les modules qui existent (les superviseurs, les modules de GE, et FXS) peuvent être séparés à travers les deux châssis. Cependant, un module supplémentaire d'E1 de huit-port devrait être ajouté de sorte que la connectivité RTPC puisse également être séparée à travers les deux châssis. Cette conception tient compte également pour que les deux Cisco CallManagers soient connectés pour séparer des Commutateurs. Ceci s'assure qu'une panne du Catalyst 6509 n'isole pas complètement les Cisco CallManagers.

Un deuxième commutateur du Catalyst 6509 faisait partie de la proposition initiale. Cependant, dû pour coûter des considérations, la NOTA: a décidé d'un Catalyst simple 6509.

La NOTA: suit les recommandations de conception de Cisco et a des Téléphones IP et des périphériques de données dans les réseaux locaux virtuels distincts (VLAN). Chaque Catalyst 4006 a sa propre Voix VLAN. Par conséquent, il y a deux la Voix VLAN par plancher, pour un total de neuf Voix VLAN. Chaque Catalyst 4006 a 240 ports. Par conséquent, chaque Voix VLAN est potentiellement à la maison à 240 Téléphones IP. C'est une conception conservatrice, mais a l'avantage qu'il limite l'incidence si un périphérique de défaut de fonctionnement inonde le VLAN avec des émissions. Quand les artères de la famille MSFC du Catalyst 6000 entre les VLAN, posent la représentation 3 de transmission n'est pas une question.

65365.gif

Tous les périphériques de données résident dans un VLAN simple et grand. Ceci n'est pas conforme aux recommandations de conception de Cisco. Cependant c'était la conception préférée par la NOTA: due à leurs frais internes opérationnels et d'entretien. Puisque ces données simples VLAN répartissent tous les Commutateurs, une saturation de diffusion de la couche 2 dans ce VLAN a le potentiel d'affecter tous les Téléphones IP. Ceci rend le Qualité de service (QoS) sur les Commutateurs de Catalyst bien plus essentiel. QoS est discuté plus tard dans ce document.

Cet exemple affiche une configuration typique VLAN pour un port du Catalyst 4006. Cet exemple place chacun des 48 ports dans l'emplacement 5 dans la Voix VLAN 110 et les données VLAN 11.

set port auxiliaryvlan 5/4-48 110 
set vlan 11 type ethernet state active 
set vlan 11 5/4-48

Le réseau NOTA: a ces trois bornes distinctes de qos trust :

  • Catalyst 4006 10/100 port.

  • Catalyst 6509 10/100 port se connectant au Cisco CallManager.

  • Catalyst 6509 10/100 port se connectant au routeur de Cisco 7200.

Les modules du Catalyst 4000 10/100 font en service recevoir un simple la file d'attente (RX) (1q1t) et deux transmettent les files d'attente (TX) (2q1t). Tous les ports sont configurés avec les commandes dans cet exemple d'activer la deuxième file d'attente TX, et de mettre des trames avec une valeur de Classe de service (Cos) entre 2 et 7 dans la deuxième file d'attente. En conséquence, tous les paquets de Protocole RTP (Real-Time Transport Protocol) (CoS=5) et tous les paquets maigres (CoS=3) entrent dans la deuxième file d'attente, alors que tout autre trafic entre dans la première file d'attente.

set qos enable
set qos map 2q1t 1 1 cos 0-1
set qos map 2q1t 2 1 cos 2-3
set qos map 2q1t 2 1 cos 4-5
set qos map 2q1t 2 1 cos 6-7

Notez que le Catalyst 4006 ne prend en charge aucun genre de maintien de l'ordre. Il fait confiance au cos de n'importe quelle trame reçue sur ses ports. Ce n'est pas une question tant que un téléphone IP est connecté puisque le comportement par défaut du téléphone IP est de ne pas faire confiance au trafic reçu sur le port PC, et pour le réécrire avec cos de 0. Cependant, un PC connecté directement à un port du Catalyst 4006 peut potentiellement exploiter le QoS s'il envoie des données en tant que trames 802.1p. Ceci exige un utilisateur en quelque sorte sophistiqué. Cependant, le Windows 2000 et les cartes d'interface de réseau Ethernet standard (NIC) prennent en charge 802.1pq.

La configuration QoS sur le Catalyst 6509 est légèrement plus impliquée puisque les ports sur le Catalyst 6509 ont un grand choix de structures de file d'attente, suivant les indications de cette table.

Module File d'attente de réception File d'attente de transmission
WS-X6K-SUP1A-MSFC 1p1q4t 1p2q2t
WS-X6416-GBIC 1q4t 2q1t
WS-X6408A-GBIC 1p1q4t 1p2q2t
WS-X6348-RJ45V 1p1q4t 1p2q2t

N'importe quel port qui a une file d'attente prioritaire stricte met toutes les trames avec CoS=5 dans cette file d'attente par défaut. Cependant, on le préfère avoir tout le trafic de signalisation VoIP (trames avec CoS=3) dans la deuxième file d'attente non-prioritaire. Cette configuration active ce comportement.

set qos map 1p2q2t tx 2 1 cos 3
set qos map 2q2t tx 2 1 cos 3

Le port connectant de GE aux Commutateurs du Catalyst 4006 sont à l'intérieur de notre borne de confiance. Normalement le système ferait confiance au cos des trames reçues. Puisque la borne de confiance du Catalyst 4006 peut être compromise en connectant un PC directement à un port de commutateur, le trafic des Commutateurs du Catalyst 4006 est traité comme non approuvé, et est maintenu l'ordre par le Catalyst 6509. Le maintien de l'ordre est fait par une liste de contrôle d'accès (ACL) qui recherche le RTP, maigre, les paquets H.225, et H.245. Des en-têtes de paquet de RTP sont réécrites avec DSCP=46 tandis que toutes les en-têtes de paquet de signalisation VoIP sont réécrites avec DSCP=26. L'ACL pour ceci, suivant les indications de cet exemple, est tracé à tous les ports de GE.

set qos acl ip ACL_VOIP dscp 46 udp any any range 16384 32767
set qos acl ip ACL_VOIP dscp 46 udp any range 16384 32767 any
set qos acl ip ACL_VOIP dscp 26 tcp any any range 2000 2002
set qos acl ip ACL_VOIP dscp 26 tcp any range 2000 2002 any
set qos acl ip ACL_VOIP dscp 26 tcp any any eq 1720
set qos acl ip ACL_VOIP dscp 26 tcp any eq 1720 any
set qos acl ip ACL_VOIP dscp 26 tcp any any range 11000 11999
set qos acl ip ACL_VOIP dscp 26 tcp any range 11000 11999 any
set qos acl map ACL_VOIP 3/1-16,4/1-8,

Deux des ports de 10/100 sur le Catalyst 6509 sont utilisés pour se connecter aux deux Cisco CallManagers. Ce sont les ports essentiellement de confiance, mais dans le réseau NOTA: elles sont traitées comme non approuvées, et forces CoS=3 du Catalyst 6509 sur des trames reçues. Cet exemple affiche la configuration des ports.

set vlan 110 5/2-3
set port qos 5/2-3 cos 3

Une alternative, et une approche plus propre, est de configurer le Cisco CallManager pour placer la valeur de point de code de Différenciation de services IP (DSCP) dans des tous les paquets de signalisation VoIP. Pour faire ceci, placez les paramètres de service IpTosCm2Cm et IpTosCm2Dvce à 0x26 sur le Cisco CallManager. Le Catalyst 6509 peut alors être configuré pour faire confiance au DSCP des trames reçues sur ce port, suivant les indications de cet exemple.

set port qos 5/2-3 trust trust-dscp

Cette approche a l'avantage que seulement les trames contrôlées par la VoIP, et non chaque trame de Cisco CallManager, reçoivent bon QoS. C'est important si une image de mise à jour de Cisco CallManager est téléchargée au serveur CallManager, ou si un grand nombre d'articles mouvement d'appel (CDR) sont par habitude retirés le serveur. Actuellement, ce genre de trafic reçoit également un QoS élevé.

En conclusion, un des ports de 10/100 sur le Catalyst 6509 est utilisé pour connecter à la gamme Cisco 7200 le routeur WAN. C'est également un port de confiance, mais le ½ en cours du ¿  de Cisco IOSï en service sur le routeur de Cisco 7200 ne copie pas la valeur DSCP sur le champ de cos. Pour surmonter cette limite, le port de commutateur est traité pareillement aux ports de GE (classifiez le trafic entrant utilisant le même ACL) et fournit sélectivement QoS basé sur ceci. Par conséquent, la configuration pour le port de commutateur de routeur est affichée dans cet exemple.

set vlan 10 5/1
set qos acl map ACL_VOIP 5/1

Infrastructure WAN

Le composant BLÊME du réseau de Téléphonie sur IP NOTA: est petit. Le routeur de gamme Cisco 7200 dans le bâtiment DBS a des liens WAN à NBAP et à towers capitaux. Cependant, seulement le lien à NBAP porte la Voix. Même alors il y a les liens distincts entre DBS et NBAP pour la Voix et les données. Des problèmes de qualité voix ont été découverts pendant les parties du déploiement, et on l'a décidé de changer des codecs de G.729 à G.711. Cette bande passante supplémentaire exigée, et Voix et données sur le WAN ont été donc séparées. La cause de ces problèmes était plus tard avérée avec le chargement de téléphone IP en service alors. Comme mesure conservatrice, la NOTA: a décidé de rester avec G.711 et de séparer des liens WAN pour la Voix et les données à court terme.

Actuellement le lien WAN de Voix se compose de trois liens physiques d'E1 qui sont empaquetés ensemble par le PPP à liaisons multiples (MLP). En raison relativement de l'à grande vitesse du lien, aucun Fonction Link Fragmentation and Interleaving (LFI) n'est exigé. La seule caractéristique exigée de QoS s'aligne. Le mécanisme de mise en file d'attente préféré est Fonction Low Latency Queuing (LLQ). Cependant, ceci n'a pas fonctionné en raison de l'Cisco IOS émettent avec LLQ et MLP, où la commande de service-stratégie a disparu de la configuration si le lien descendait. Comme contournement intérimaire, la file d'attente à priorité déterminée a été en service. Cet exemple affiche la configuration BLÊME en cours.

interface Multilink88
 ip address 10.104.209.73 255.255.255.248
 priority-group 1
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave
 multilink-group 88

interface Serial4/0
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 multilink-group 88

interface Serial4/1
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 multilink-group 88

interface Serial4/2
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 multilink-group 88

priority-list 1 protocol ip high list 121
priority-list 1 protocol ip medium list 122
priority-list 1 default low
priority-list 1 queue-limit 500 40 60 80

access-list 121 permit udp any any range 16384 32767
access-list 121 permit udp any range 16384 32767 any
access-list 122 permit tcp any any range 2000 2002
access-list 122 permit tcp any range 2000 2002 any
access-list 122 permit tcp any any eq 1720
access-list 122 permit tcp any eq 1720 any
access-list 122 permit tcp any any range 11000 11999
access-list 122 permit tcp any range 11000 11999 any

La configuration BLÊME en cours est une compromission et n'est pas recommandée pour l'usage dans d'autres déploiements. Le plan à moyen terme est de consolider la Voix et les données en fonction à un lien WAN simple, et de remplacer la file d'attente à priorité déterminée par LLQ. Les liens distincts pour la Voix et les données exigent le routage statique ou le routage basé sur la politique, et les avantages d'utiliser un protocole de routage dynamique sont perdus. La file d'attente à priorité déterminée, même avec des paquets vocaux étant assignés la file d'attente élevée, ne garantit pas que la priorité stricte est accordée dans des paquets vocaux. Le trafic de système, tel que des mises à jour de routage, Keepalives, prend et ainsi de suite toujours la préférence au-dessus des paquets vocaux dans la file d'attente élevée.

On l'a vérifié que LLQ fonctionne correctement dans le Logiciel Cisco IOS version 12.2. Cet exemple affiche le routeur QoS, après le mouvement à LLQ. Les bandes passantes sont basées sur 60 G.729 appels simultanés (RTP : 60 x 24 Kbps = 1440 Kbps et signalisation : 60 x 0.5 Kbps = 30 Kbps).

interface Multilink88
 service-policy output VoIP

class-map VoIP-RTP
 match access-group 121
class-map VoIP-Sig
 match access-group 122

policy-map VoIP
 class VoIP-RTP
  priority 1440
 class skinny
  bandwidth 30

access-list 121 permit udp any any range 16384 32767
access-list 121 permit udp any range 16384 32767 any
access-list 122 permit tcp any any range 2000 2002
access-list 122 permit tcp any range 2000 2002 any
access-list 122 permit tcp any any eq 1720
access-list 122 permit tcp any eq 1720 any
access-list 122 permit tcp any any range 11000 11999
access-list 122 permit tcp any range 11000 11999 any

Téléphonie sur IP

Téléphones IP et leur connexion au commutateur

Le bâtiment DBS a approximativement 750 téléphones IP 7960s. Les Téléphones IP connectent 10/100 aux ports sur le Catalyst 4006, et reçoivent l'alimentation en ligne du commutateur. Les PC se connectent aux ports de commutateur derrière le téléphone IP, comme représenté dans ce diagramme.

/image/gif/paws/13968/65373.gif

Les Téléphones IP et les PC sont sur des VLAN distincts et des sous-réseaux IP.

Planification de site

Tous les Téléphones IP reçoivent l'alimentation en ligne des linecards du Catalyst 4006. Les Commutateurs eux-mêmes sont actionnés par trois approvisionnements d'alimentation AC de dans-châssis. L'alimentation en ligne, cependant, est originaire extérieurement du module de puissance auxiliare du Catalyst 4006 (WS-P4603). Le module d'alimentation a trois blocs d'alimentation. Chacun fournit 1050W au C.C -52V. C'est suffisant pour actionner un commutateur entièrement rempli du Catalyst 4006 avec le téléphone IP 7960s de Cisco connecté à chacun des 240 ports.

/image/gif/paws/13968/65366.gif

Tous les Commutateurs du Catalyst 4006 coulent d'un bloc d'alimentation ininterrompu (UPS). Ceci leur permet pour continuer l'exécution pendant deux heures en cas d'une panne d'alimentation. Les Cisco CallManagers se connectent à UPS de quatre heures.

Cisco CallManager

Le modèle de déploiement de CallManager NOTA: est site unique avec le Traitement des appels centralisé. On peut arguer du fait que le modèle est en fait multisite en raison du lien WAN à NBAP et de la passerelle associée localisée là. Mais ce fait peut (pour la plupart) soit ignoré car aucun contrôle d'admission d'appel (CAC) n'est exigé à travers le WAN. C'est parce que le nombre d'appels à travers le WAN est implicitement limité par le nombre de joncteurs réseau connectant la passerelle au PBX.

La batterie de Cisco CallManager NOTA: se compose deux du Cisco Media Convergence Server 7835s (MCS-7835). Un CallManager remplit la fonction d'édition de base de données, et l'autre s'abonne à la base de données. Toute l'inscription de Téléphones IP à l'abonné comme Cisco CallManager primaire, et utilisent l'éditeur comme Cisco CallManager secondaire.

Deux régions sont configurées : NBAP et DBS. La passerelle à NBAP est le seul périphérique dans la région NBAP, tous autres périphériques sont dans la région DBS. La conception destinée est de l'utiliser G.711 pour tous les appels dans le bâtiment DBS, et l'utilise G.729 seulement pour des appels à travers le WAN. Actuellement, cependant, les appels à travers le lien WAN sont également G.711.

Les Téléphones IP à la région DBS ont une extension à cinq chiffres de l'ordre de 17000 à 17999. Il y a cinq autres sites NOTA: à Singapour qui ont un mélange de quatre et des extensions à cinq chiffres. Cette table affiche les sites NOTA: Singapour.

Nom du site Code de site Chiffres
Service de lier Singapour DBS 5
Impression de point culminant NOTA: NBAP 5
Point culminant construisant A Aba 4
Point culminant construisant B ABB 5
Impression de Douglas DP 4
Impression de Grant Généraliste 4

Des extensions sont assignées de sorte que le premier chiffre détermine seulement si l'extension est quatre ou cinq chiffres. Les utilisateurs de téléphone IP peuvent composer n'importe quelle extension NOTA: Singapour PBX en composant les quatre ou l'extension à cinq chiffres.

Comme discuté plus tard dans la section d'intégration de passerelle, il y a trois types de passerelles :

  • Une passerelle H.323 de Cisco 7200 qui connecte à un réseau du legs NOTA: PBX.

  • Trois passerelles d'E1 du Catalyst 6509 qui se connectent au PSTN.

  • Deux passerelles du Catalyst 6509 24-port FXS qui se connectent à la messagerie vocale.

Ceci est reflété dans la configuration de groupe d'artère de Cisco CallManager. Un groupe d'artère existe pour chacun des trois types de passerelle. Cette table trace les grandes lignes des caractéristiques de chaque groupe d'artère.

Groupe d'artère Plate-forme Emplacement/port Type de port Priorité
VM DBS Commutateur du Catalyst 6509 6/1-24 7/1-24 FXS FXS 1 2
PSTN DBS Commutateur du Catalyst 6509 8/1 8/2 8/3 PRI PRI PRI 1 2 3
Legs NBAP Routeur Cisco 7200 5/1-2 PRI 1

Des appels aux diverses destinations sont conduits comme suit :

  • Les appels au PSTN utilisent le groupe d'artère PSTN DBS. Il n'y a aucune sauvegarde.

  • Les appels à la messagerie vocale utilisent le groupe d'artère VM DBS. Il n'y a aucune sauvegarde.

  • Les appels au service Telnet NOTA: utilisent le groupe existant d'artère NBAP.

  • Les appels à une extension NOTA: Singapour PBX utilisent le groupe existant d'artère NBAP en tant que groupe primaire, et DBS PSTN d'artère comme groupe d'artère secondaire.

Tout ce qui reste maintenant est de définir les modèles appropriés d'artère et de les lier aux groupes d'artère. C'est simple pour les trois premiers éléments répertoriés ci-dessus, car seulement une liste de routage simple est exigée. Les choses obtiennent légèrement plus impliqué avec le dernier élément en raison du groupe de route de secours. Le chemin préférentiel pour un appel d'un téléphone IP à une extension PBX est par le groupe existant d'artère NBAP. Si cette passerelle est indisponible, des appels sont conduits par le PSTN par le groupe d'artère PSTN DBS. Quand ceci se produit, des chiffres doivent être préfixés au poste composé afin de créer le plein numéro de téléphone PSTN. Les chiffres préfixés dépendent du site s'appelant, par conséquent, chaque site doit avoir une liste de route différente. Puisqu'il y a cinq sites NOTA: avec des PBX, et plusieurs préfixes PSTN par site, ils finissent par avec dix listes de routage.

Ce diagramme affiche toutes les listes de routage NOTA:. Les deux ou de trois chiffres nombres inclus au nom de la plupart des listes de routage reflète les chiffres qui sont préfixés à l'extension appelée, toutes les fois que des appels sont envoyés au groupe d'artère PSTN DBS.

/image/gif/paws/13968/65367.gif

Certains utilisateurs de téléphone IP NOTA: sont limités dans les nombres qu'ils peuvent appeler. Ceci est contrôlé en plaçant les modèles d'artère et les extensions de téléphone IP dans un certain nombre des partitions. Des partitions sont alors groupées ensemble dans un espace de recherche appelant. Les Téléphones IP appartiennent à un espace de recherche appelant et peuvent seulement demander les numéros contenus dans les partitions dans cet espace de recherche. Ce tableau présente les espaces de recherche et les partitions de Cisco CallManager NOTA:.

L'espace de recherche Partitions Description
Invité Préposé d'appel de l'invité NOTA: SGP DBS de l'utilisateur DBS DBS Le lobby normal de téléphone d'utilisateur DBS et tout autre secteur public téléphonent le réceptionniste d'extension NOTA: Singapour PBX
Utilisateur Préposé d'appel de l'invité NOTA: SGP IDD DBS PSTN DBS du telnet SGP de l'utilisateur NOTA: GSDN NOTA: DBS Téléphone normal d'utilisateur DBS — Appels internationaux par des appels domestiques de réseau mondial NOTA: dans le lobby de Singapour et tout autre réceptionniste d'appels internationaux d'extension des téléphones NOTA: Singapour PBX de secteur public

Intégration de messagerie vocale

DBS utilise le système de messagerie voix d'Octel. Ceci a été choisi parce que c'est une norme mondiale NOTA:, et le réseau de messagerie vocale entre les divers systèmes a été désiré.

Le Cisco CallManager se connecte au système de messagerie voix d'Octel au moyen de deux cartes 24-port FXS dans le commutateur du Catalyst 6509. Seulement 30 des 48 ports disponibles sont utilisés. Un lien de Simplified Message Desk Interface (SMDI) 9600 bps connecte le Cisco CallManager primaire au périphérique d'Octel.

Le système d'Octel est également connecté au réseau entreprise NOTA: Octel. Ceci est fait au moyen de quatre ports de devises étrangères du bureau (FXO) sur le périphérique d'Octel qui se connectent à vieux Lucent Definity PBX. Ce diagramme affiche comment le système DBS Octel se connecte au nouveau et à l'ancien temps.

/image/gif/paws/13968/65368.gif

Remarque: La conception initiale n'a pas inclus le PBX. En revanche, l'idée était au réseau la messagerie vocale à travers par la carte 24-port FXS et le réseau VoIP. Mais pendant le pilote, des questions ont été produites de la manière que la carte FXS a manipulé les tonalités multifréquences de double tonalité (DTMF) du périphérique d'Octel. Comme contournement, la carte 24-port FXS a été remplacée par une passerelle de Cisco IOS. Ceci fonctionné bien, mais la NOTA: a préféré la solution PBX.

Il vaut de noter les caractéristiques de résilience de la solution de messagerie vocale. En plus du système de messagerie voix, il y a d'autres points de défaillance unique :

  • Le lien SMDI n'est pas redondant : Une panne du Cisco CallManager primaire prendra le système de messagerie voix hors service. Si cette situation se produit, la stratégie NOTA: est de déplacer manuellement le câble SMDI au Cisco CallManager de sauvegarde. Alternativement, un distributeur SMDI permettrait les deux CallManagers à connecter en même temps, et tient compte du Basculement automatique.

  • Actuellement les deux cartes 24-port FXS résident dans le même châssis du Catalyst 6509. Une panne du Catalyst 6509 prendra le système de messagerie voix hors service. Comme discuté plus tôt dans ce document, il y a beaucoup à gagner en termes de résilience en ajoutant un deuxième Catalyst 6509.

Intégration de passerelle

Le tableau suivant présente les trois types différents de Passerelles voix dans le réseau NOTA:.

Plate-forme Type d'interface Nombre de ports Protocol Se connecter à
Catalyst 6509 PRI/E1 8 x 30 canaux Maigre PSTN
Catalyst 6509 FXS analogique 2 x 24 Maigre Messagerie vocale
7206VXR PRI/CAS/E1 2 x 30 canaux H.323 Legacy PBX

Le Catalyst 6509 tient une carte simple d'E1 de huit-port. Trois de ces huit ports se connectent au PSTN au moyen de PRI. Chaque port E1 a sa propre adresse IP et ses fonctions de port en tant que passerelles indépendantes. Le routage d'appels à et des passerelles est contrôlé par Cisco CallManager au moyen du protocole maigre. Les utilisateurs composent un numéro PSTN en composant 0, suivi du nombre PSTN. Les appels entrant ont les principaux chiffres éliminés, et l'appel est conduit au téléphone IP appelé basé sur les cinq derniers chiffres.

Les utilisateurs composent le '9' pour sélectionner un fil extérieur, et le Cisco CallManager retire ce chiffre avant de présenter l'appel au PSTN. La NOTA: a essayé deux méthodes de retirer le chiffre. La première méthode inclut un « point » dans le modèle d'artère sur le Cisco CallManager, et tous les chiffres de pré-point sont jetés avant de le présenter au PSTN. Le deuxième, et la méthode préférée, est de configurer l'écart en tant qu'élément de la passerelle installée sur le Cisco CallManager. Ceci est fait en plaçant le nombre de chiffres pour éliminer le champ à un. Cette deuxième méthode est meilleure parce qu'elle préserve le principal '9' où le nombre est enregistré dans le répertoire d'appels passés sur le téléphone IP. Ceci signifie que l'utilisateur peut plus tard recomposer le nombre à partir du répertoire sans devoir appuyer sur editdial et ajouter le principal '9'.

Les passerelles FXS sont utilisées seulement pour la messagerie vocale. Ces passerelles sont contrôlées par Cisco CallManager au moyen de maigre.

La passerelle de Cisco 7200 fournit la Connectivité entre le réseau de Téléphonie sur IP à DBS et le réseau mondial NOTA: PBX. Cette passerelle est le seul appareil voip pas physiquement situé dans le bâtiment DBS : Il se trouve au bâtiment NBAP, et atteint au moyen d'un lien WAN.

La passerelle de Cisco 7200 est équipée d'un adaptateur à deux orifices simple de port E1, et l'utilise H.323 pour parler au CallManager. Les deux ports d'E1 connectent à Nortel un méridien situé à NBAP. Un port emploie QSIG et l'autre signalisation CAS (Channel Associated Signaling) d'utilisations pour parler au PBX. Des appels aux extensions de Singapour PBX sont conduits en bas du port QSIG, alors que des appels internationaux, utilisant le réseau voix privé (telnet), sont conduits par le port de CAS.

Le mélange de CAS et de QSIG complique l'installation. CAS est exigé pour permettre d'accéder à la composition internationale code-protégée du numéro d'identification personnel (PIN) par le réseau voix mondial de telnet. Quand un utilisateur compose ce service, ils composent 313xxxxxx, où xxxxxx est un code PIN de six-chiffre. L'application méridienne qui authentifie ce code PIN ne semble pas être prise en charge par le PRI. Par conséquent, la nécessité d'utiliser CAS sur un des deux joncteurs réseau à cet effet.

Cela dit, CAS signalant plus facile prouvé d'obtenir aller que le joncteur réseau QSIG. Parmi les questions produites étaient les intervalles de temps se bloquant sur le méridien et le désaccord sur la numérotation de canal B. Presque toutes les questions ont dû faire avec une non-concordance des paramètres de configuration du côté de Cisco 7200 et de méridien. Ces questions ont été résolues après que le Cisco IOS ait fourni une configuration méridienne fonctionnante.

Une copie de la configuration méridienne est incluse ci-dessous. Cette configuration est d'une option méridienne 11C, version de logiciel 24.24 courante. Les progiciels suivants sont exigés afin de lancer cette configuration.

QSIG      263
QSIGGF    305
MASTER    309
QSIG-SS   316
ETSI-SS   323

La configuration suivante est du bloc de données d'artère de config.

TYPE  RDB     (Route Data Block)
CUST  00      (Customer Number)
DMOD
ROUT  xx      (Route Number)
DES           (Trunk Description)
TKTP  TIE     (Trunk type - Tie Line or DID)
ESN   NO 
RPA   NO
CNVT  NO
SAT   NO
RCLS  INT     (Route Class - Internal or External)
DTRK  YES     (Digital Trunk - YES)
BRIP  NO
DGTP  PRI2    (Digital Group Type - PRI 30B + D)
ISDN  YES     (YES when DGTP is PRI or PRI2)
MODE  PRA     (ISDN/PRA Route)
IFC   ESGF    (ESGF req QSIG & QSIF GF Pkgs)
SBN   NO
PNI   00000
NCNA  NO
NCRD  NO
CTYP  UKWN
INAC  NO
ISAR  NO
CPFXS YES
DAPC  NO
INTC  NO
DSEL  VOD
PTYP  DTT
AUTO  NO
DNIS  NO
DCDR  NO
ICOG  IAO     (Bothway Trunk In and Out (IAO))
SRCH  RRB
TRMB  YES
STEP
ACOD  xxxx    (Trunk access code)
TCPP  NO
TARG  03
BILN  NO
OABS
INST
ANTK
SIGO  STD
MFC   NO
ICIS  YES
OGIS  YES
PTUT  0
TIMR  ICF     512
OGF   512
EOD   13952
NRD   10112
DDL   70
ODT   4096
RGV   640
GTO   896
GTI   896
SFB   3
NBS   2048
NBL   4096
IENB  5
TFD   0
VSS   0
VGD   6
DTD   NO
SCDT  NO
2 DT  NO
DRNG  NO
CDR   NO
NATL  YES
SSL
CFWR  NO
IDOP  NO
VRAT  NO
MUS   NO
PANS  YES
FRL   0 x
FRL   1 x
FRL   2 x
FRL   3 x
FRL   4 x
FRL   5 x
FRL   6 x
FRL   7 x
OHQ   NO
OHQT  00
CBQ   NO
AUTH  NO
TTBL  0
PLEV  2
OPR   NO
ALRM  NO
ART   0
PECL  NO
DCTI  0
TIDY  xx
SGRP  0
AACR

Cette configuration est du canal D.

ADAN  DCH 12      (D-Channel Number assigned by programmer)
CTYP  MSDL        (D-Channel Card type) 
CARD  02          (Card Location)
PORT  1           (Port Number) 
DES   CISCO_5300  (Description)
USR   PRI         (User type - PRI for ISDN PRA only)
DCHL  2           (Loop the D-Channel will be associated with)
OTBF  32          (Output request buffer)
PARM  RS422 DTE   (Default)
DRAT  64KC        (64kb/s Clear - Don't change) 
CLOK  EXT         (Clock Source - External)
NASA  NO          (Default NO)
IFC   ESIG        (ETSI Q Reference Signaling - MSDL D-Channel ONLY) 
ISDN_MCNT  300    (Default)
CLID  OPT0        (Opt0 is default for ESIG and ISIG interfaces)
CO_TYPE  STD      (100% Compatible)
SIDE  NET         (Network or User Side)
CNEG  2           (2 = Channel is indicated - alternative is accepted)
RLS   ID  **      (Default)
RCAP  COLP        (COLP is default for ESIG, ISIG interfaces)
MBGA  NO          (Default)
OVLR  NO          (Default)
OVLS  NO          (Default)
T310  120         (Default)
T200  3           (Default)
T203  10          (Default)
N200  3           (Default)
N201  260         (Default)
K     7           (Default)

C'est une configuration pour les temporisateurs de boucle pour l'interface de lien-line PRI.

LOOP 2

MFF    AFF
ACRC   NO
ALRM   REG
RAIE   NO
G1OS   YES
SLP    5       24 H    30    1 H
BPV    128    122
CRC    201     97
FAP    28       1
RATS   10
GP2    20     100 S    12 S    12 S    4 S
MNG1   60 S
NCG1   60 S
OSG1   60 S
MNG2   15 S
NCG2   15 S
OSG2   15 S
PERS   50
CLRS   50
OOSC   0

Cette configuration est du canal B.

TN     00x 0x      (LEN, TN (Terminal Number))
TYPE   TIE         (Trunk Type - Tie Line)
CDEN   SD          (Single Density Card
CUST   0           (Customer 0)
TRK    PRI2        (Trunk Type)
PDCA   x           (Pad Category Table)
PCML   A           (A-law or Mu-Law)
NCOS   0           (Network Class of Service)
RTMB   x y         (Route Member- x is router no., y is member no.)
B-CHANNEL SIGNALING
TGAR   0           (TGAR Restricted Dialing Leave as 0)
AST    NO          (Default)
IAPG   0           (Default)
CLS    CTD DIP WTA LPR APN THFD XREP BARD
P10    VNL         (Class of services)
TKID

La configuration de passerelle pour les deux joncteurs réseau d'E1 est affichée ici. Notez que la passerelle agit en tant que côté de réseau, alors que le méridien est le côté utilisateur.

controller E1 5/0
 pri-group timeslots 1-31

!-–– Defines PRI trunk.


controller E1 5/1
 framing NO-CRC4
 ds0-group 0 timeslots 1-15,17-31 type e&m-wink-start

!-–– CAS trunk.


interface Serial5/0:15
 isdn switch-type primary-qsig

!-–– Defines Q.SIG signaling.

 isdn protocol-emulate network

!-–– The network side.

 isdn incoming-voice voice
 isdn send-alerting
 isdn sending-complete

La passerelle a 15 homologues de numérotation POTS. La plupart des pairs de cadran précisent le joncteur réseau QSIG, reflétant les diverses extensions PBX qui sont accessibles du côté PBX.

Les pairs de cadran restants précisent le joncteur réseau de CAS, des appels de direction au réseau voix de telnet. Notez également que le joncteur réseau QSIG est configuré pour inclure un indicateur de progression avec une valeur de 8 quand il envoie un message d'alerte de nouveau au PBX. Ceci indique au PBX que la passerelle fournit la tonalité de rappel d'intrabande, et le PBX ouvrent le chemin audio même avant qu'un appel est répondu par le téléphone IP.

dial-peer voice 33 pots
 preference 1
 destination-pattern 33.......
 direct-inward-dial
 port 5/1:0

!-–– Calls routed out of the CAS trunk.

 forward-digits all
!
dial-peer voice 313 pots
 destination-pattern 313......
 direct-inward-dial
 port 5/1:0
 forward-digits all
!
dial-peer voice 40000 pots
 destination-pattern 4....
 progress_ind alert enable 8

!-–– Gateway to provide ringback.

 direct-inward-dial
 port 5/0:15

!-–– Calls routed out of the QSIG trunk.

 forward-digits all
!
dial-peer voice 8 pots
 destination-pattern 8T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 7 pots
 destination-pattern 7T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 6 pots
 destination-pattern 6T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 5 pots
 destination-pattern 5T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 16 pots
 destination-pattern 16...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 13 pots
 destination-pattern 13...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 2 pots
 destination-pattern 2T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 1000 pots
 destination-pattern 1...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 10 pots
 destination-pattern 0...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 3 pots
 destination-pattern 3...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 508200 pots
 destination-pattern 5082..
 progress_ind alert enable 8
 port 5/0:15
 forward-digits all

Il y a seulement deux pairs de cadran VoIP, un indiquant chaque Cisco CallManager. Les pairs de cadran sont identiques excepté la préférence, qui s'assure que des appels sont conduits au Cisco CallManager primaire si disponibles. L'enable 3 d'installation de progress_ind indique la passerelle signaler au PBX, par un indicateur de progression dans le message de configuration, que l'appelant est le non-RNIS. En conclusion, le h225 timeout tcp establish 3 indique la passerelle attendre un maximum de trois secondes en établissant une session H.225 avec le Cisco CallManager. Si le Cisco CallManager ne répond pas dans trois secondes, la passerelle essaye le Cisco CallManager secondaire.

dial-peer voice 17000 voip
 preference 1

!-–– Route to primary Cisco CallManager is preferred.

destination-pattern 17...
 progress_ind setup enable 3

!-–– Progress indicator = non-ISDN.

 voice-class h323 10
 session target ipv4:10.66.184.13
 dtmf-relay cisco-rtp h245-signal h245-alphanumeric
 codec g711ulaw
 ip precedence 5
 no vad
!
dial-peer voice 17001 voip
 preference 2
 destination-pattern 17...
 progress_ind setup enable 3
 voice-class h323 10
 session target ipv4:10.66.184.14
 dtmf-relay cisco-rtp h245-signal h245-alphanumeric
 codec g711ulaw
 ip precedence 5
 no vad

voice class h323 10
 h225 timeout tcp establish 3

Certaines des questions les plus persistantes produites pendant le lancement du projet de Téléphonie sur IP NOTA: ont concerné pour faire écho. Les questions principales d'écho ont été éprouvées par les utilisateurs de téléphone IP quand elles ont demandé certains numéros par la passerelle de Cisco 7200. L'effort qui est entré dans essayer pour réduire l'écho était étendu, et les tentatives suivantes de l'information pour capturer les parties de cette expérience qui peuvent être utiles à d'autres déploiements.

L'attente initiale par l'équipe de créateurs de Téléphonie sur IP était pour que la passerelle de Cisco 7200 fournisse la Connectivité entre le côté VoIP et un PBX simple à NBAP. Pendant qu'il s'avérait, ce qui en fait était fourni était la Connectivité entre le côté VoIP et très grand, mondial le réseau voix NOTA:. Le réseau voix NOTA: a un legs de ses propres moyens, y compris un certain nombre de problèmes d'écho. Dans le passé, NOTA: tentée pour accorder les niveaux de puissance des divers Noeuds dans ce réseau pour réduire la quantité d'écho. Le réseau auquel la passerelle de Cisco 7200 se connectait était un réseau avec des problèmes existants d'écho. Il a également eu des niveaux de variation de la puissance du signal, selon la destination de l'appel. C'était une intégration difficile.

En introduisant une solution de voix en paquets, avec ses retards supplémentaires, les problèmes d'écho ont été aggravés. Dans un effort de manipuler ceci, les réglages suivants ont été faits.

  • Les annuleurs d'écho de Cisco 7200 ont été ajustés à leur configuration plus agressive.

  • L'input gain a été diminué.

  • L'output attenuation a augmenté sur les deux joncteurs réseau d'E1.

Tandis que ceci réduisait l'écho, il a eu l'effet secondaire indésirable qui les volumes, en appelant certains destination in le réseau voix NOTA:, étaient si bas et les utilisateurs se plaignaient. En raison de la non-concordance des niveaux de signal du côté existant, il n'y avait pas une seule combinaison de gain et d'atténuation qui a adapté à des appels à et de toutes les destinations. Ce qui fonctionné bien pour des appels à Hong Kong a créé l'écho aux appels en Corée. Ce que fonctionné pour la Corée a eu comme conséquence des problèmes de bas volume pour Hong Kong. La configuration ci-dessous affiche la configuration en cours de compromission pour les ports vocaux sur la passerelle de Cisco 7200.

voice-port 5/0:15
 input gain 0
 output attenuation 3
 echo-cancel coverage 32
 compand-type u-law
 cptone SG

voice-port 5/1:0
 input gain -2
 echo-cancel coverage 32
 compand-type u-law
 cptone SG
 timeouts interdigit 5
 timeouts wait-release infinity
 timing percentbreak 60

L'ingénierie de développement fonctionne actuellement sur améliorer l'écho annulant des capacités de quelques Produits Cisco. La NOTA: attend ces améliorations afin de réduire plus loin l'écho.

Des solutions alternatives ont été proposées à la NOTA:, mais le client a décidé d'attendre les améliorations de Cisco. Deux ont proposé que des contournements soient discutés ci-dessous dans l'espoir que d'autres projets peuvent bénéficier de eux. Le chapitre général appris de la NOTA: est qu'une alerte d'alerte devrait être augmentée tôt si la solution proposée de Téléphonie sur IP se connecte à un grand réseau voix hérité privé. Ce faisant, ces contournements peuvent être conçus et coûtés dans la solution du début.

  • Contournement 1 — Insérez les annuleurs d'écho de tiers entre la passerelle Cisco et le PBX. Cisco font écho annulant la technologie peut actuellement annuler les queues d'écho qui sont retardées moins puis 32 ms. Le signal fait écho doit être sujet à une perte de retour d'écho (ERL) au moins de 6 dB, c.-à-d., le signal reçu d'écho doit être au moins 6 dB inférieurs au signal initialement transmis. Pour qu'elle soit valable, la représentation de l'annuleur de tiers devrait dépasser les valeurs ci-dessus.

  • Contournement 2 — Augmentez le nombre de joncteurs réseau entre la passerelle Cisco et le PBX. Ceci permet chaque joncteur réseau à configurer avec une configuration différente de gain/atténuation. Des appels peuvent alors être conduits à travers le joncteur réseau avec les caractéristiques d'écho les plus appropriées. Par exemple, les appels vers Hong Kong peuvent passer par le joncteur réseau 1 tandis que les appels vers la Corée passent par le joncteur réseau 2. Le PBX doit également pouvoir conduire des appels à travers le joncteur réseau correct, basé sur où l'appel commence.

Ravitaillement DSP pour des Conférences et le transcodage

Bien que G.711 soit actuellement utilisé dans tout le réseau, l'intention est de l'utiliser G.729 à travers le lien WAN entre DBS et NBAP. La conception a pris en considération ceci en allouant des ressources en processeur de signaux numériques de matériel (DSP) pour des Conférences. Les ressources en matériel résident sur le Catalyst 6509. Rappelez-vous que seulement trois des huit ports d'E1 sont en service pour la connectivité RTPC. Trois des autres cinq ports sont utilisés pour des Conférences.

Il y a deux ports inutilisés sur le module d'E1 du Catalyst 6509 qui sont installés comme ressources en transcodage. Il n'y a pas actuellement un besoin de transcodage, mais le besoin se fera sentir si la NOTA: décide de déployer un serveur de la réponse vocale interactive IP (RVI).

Versions de logiciel

Le tableau suivant présente les versions de logiciel utilisées dans le réseau NOTA: lorsque ce document a été écrit.

Périphérique Version
Catalyst 6509 5.5(3)
Catalyst 4006 6.1(1)
Cisco 7260VXR 12.1(3a)XI5
Cisco CallManager 3.0(8)
Téléphone IP 7960 P003Q301
WS-X6608-E1 C001W300
WS-X6624-FXS A002S300

Gestion de réseau CSNA

Des outils de gestion de réseau ne sont pas actuellement utilisés pour gérer le réseau de Téléphonie sur IP NOTA:.

Chapitre appris

Anomalies, mises en garde, et résolutions découvertes

Le tableau suivant récapitule les problèmes cruciaux produits pendant le déploiement. Des détails de ces questions sont discutés plus tôt dans ce document.

Mise en garde Résolution
Faites écho en reliant le réseau voix par paquets à un grand réseau voix hérité. Les joncteurs réseau supplémentaires de la Commission et varient le gain/atténuation de sorte que des appels puissent être conduits à travers un joncteur réseau avec une configuration appropriée. Déployez les annuleurs d'écho de tiers. Await a amélioré l'écho de Cisco annulant la technologie.
Les paramètres mal adaptés QSIG sur la passerelle et le PBX dégrossissent. Obtenez fonctionner des configurations PBX d'un site existant utilisant une installation semblable.
Chiffre pour sélectionner le fil extérieur non enregistré dans le répertoire d'appels passés. Jetez le principal chiffre en configuration de passerelle et n'utilisez pas une action d'écart de pré-point dans le modèle d'artère.

Cas TAC

Le tableau suivant présente toutes les questions qui ont eu comme conséquence un cas TAC. Également inclus sont d'autres problèmes importants qui ont été résolus localement de l'équipe de déploiement.

- - - - - - - - - -
Cas # Description État et résolution
B124306 Verrouillage de canal QSIG. Au commencement résolu en modifiant le paramètre de la négociation de la Manche LD17 (CNEG) sur Nortel PBX de Option(2) à Option(1). Cependant, les symptômes du problème ont réapparu après une certaine heure. Ultérieurement, le constructeur PBX a changé la configuration PRI QSIG sur le PBX d'ESIG (configuration GF QSIG) à ESGF (configuration européenne QSIG). Après la modification, le verrouillage de canal cessé pour se produire mais seulement les 15 canaux supérieurs étaient fonctionnels. Pour rectifier le problème, la commande d'isdn contiguous-bchan a été retirée du routeur VoIP.
A612818 La non-concordance de la Manche où Nortel PBX utilise le canal 31 comme canal de contrôle tandis que Cisco expriment le PRI de passerelle utilise le canal 16. Résolu en configurant la commande d'isdn contiguous-bchan sur l'interface PRI QSIG. Cette commande est utilisée de spécifier le canal de support contigu manipulant de sorte que les canaux B 1 à 30 (ignorant canal 16) tracent aux intervalles de temps 1 à 31. C'est disponible pour des interfaces PRI d'E1 seulement quand l'option primaire-qsig de type de commutateur est configurée à l'aide de la commande de commutateur-type RNIS.
B124306 Écho. Il y a deux scénarios dans lesquels les 7200 annuleurs d'écho peuvent ne pas pouvoir annuler un écho. Scénario 1 : L'écho est trop bruyant pour que les annuleurs s'annulent. Scénario 2 : L'écho est retardé par plus de 32 ms, qui est au delà de la couverture des 7200 annuleurs. Scénario 1 : La fabrication des réglages à l'output attenuation et à l'input gain sur la passerelle de Voix et les remplissages sur le PBX a considérablement amélioré la situation d'écho. Les configurations finales sont :
  • Input gain PRI de Cisco 7200 = 0
  • Output attenuation PRI de Ciisco 7200 = 3
  • Input gain de CAS de Cisco 7200 = -2
  • Output attenuation de CAS de Cisco 7200 = 0
  • Atténuation PRI TX PBX = 2
  • Atténuation PRI RX PBX = 4
  • Atténuation PBX CAS TX = 0
  • Atténuation PBX CAS RX = 5
Les échos résiduels se produisent comme bruit statique dans les 1 premières à 2 secondes du flot de RTP. La durée est inévitable pour que l'algorithme adaptatif s'exerce sur le flux audio et pour profile une annulation efficace. Scénario 2 : Une queue d'écho de plus de 32 ms est peu probable dans un réseau voix analogique. Cependant, il peut se produire dans un réseau voix par paquets. Car la couverture d'annulation d'écho est actuellement à un maximum de 32 ms, le travail développement est en cours pour produire un code qui intègrera un annuleur d'écho G.168 conforme de tiers (avec la longueur de queue au moins de 64 ms).
Bruit de casseur, médiocre qualité de voix (chargement de téléphone). Micrologiciel P003Q301 chargé dans le téléphone IP. Le chargement Q est plus robuste vers le jitter et le retard.
Aucun rappel au téléphone IP en demandant le numéro externe par QSIG. La passerelle ne génère pas la tonalité de rappel à moins que le message de configuration contienne un indicateur de progression (pi) de 3 (l'adresse d'origines est le non-RNIS). C'est parce que la passerelle assume cela sans pi de 3, le commutateur d'origine est le RNIS et s'attend à ce que le commutateur génère la tonalité de rappel à la place. Sans pi de 3 plaçant, la passerelle s'attend à ce que le commutateur RNIS génère la sonnerie, mais le commutateur RNIS ne génère pas la sonnerie. Ceci peut être dû à une question d'interconnexion de réseaux RNIS. Pour permettre à la passerelle de générer la tonalité de rappel, configurez le progress_ind sur le pair de cadran VoIP.
dial-peer voice 1 voip
 destination-pattern 8...
  progress_ind setup enable 3
  session target ipv4:192.168.2.10
  dtmf-relay h245-alphanumeric
  codec g711ulaw
  ip precedence 5
Ce qui précède forcera alors la passerelle pour fournir la tonalité de rappel pour des appels étant livré dans le RNIS ce tandem ce pair de cadran VoIP.
A695422 Il y a une différence dans des durées DTMF. Ceci peut sont provoqué par par le fait que le Catalyst n'identifie pas correctement les tonalités DTMF envoyées par le système de messagerie voix. En provenant une carte de Catalyst, la durée DTMF est 300 ms par défaut. En provenant la messagerie vocale, la durée est 130 ms. La spécification d'Octel exige qu'au moins cinq chiffres par seconde sont nécessaires pour que l'établissement de liaison fonctionne correctement. Le Cisco CallManager envoie actuellement H245-SIGNALLING avec une durée de 300 ms, faisant un total de 300*5 = sec 1.5. À cette durée, la messagerie vocale d'Octel aura chronométré avant que les en-têtes de réseau de messagerie vocale soient complètement reçues. A sauté le module 24-port FXS (périphérique maigre) avec une passerelle de Cisco 3640 (H.323 périphérique) chargée avec une carte FXS.
Audio à sens unique pour des appels à travers la passerelle de Voix. Le problème est provoqué par par la passerelle choisissant une adresse IP autre que celui de l'interface de bouclage. Le bouclage est l'interface dont le trafic de CallManager laisse le routeur. Mettez l'IP address de h323-gateway voip bind srcaddr sur cette interface pour forcer le routeur pour utiliser l'adresse IP spécifiée comme adresse source de RTP.
interface Loopback0
 description ::: Loopback for BGP peering
 ip address 192.170.94.34 255.255.255.255
 h323-gateway voip interface
 h323-gateway voip bind srcaddr 192.170.94.34
Sur le Cisco CallManager, changez le périphérique de passerelle H.323 d'un nom à une adresse IP. Ceci empêche également toutes les questions indésirables avec des consultations inverses DNS/hosts.
Le Cisco CallManager a un problème connu où ses services détériorent lentement au fil du temps en raison de la fuite de mémoire. Une difficulté provisoire était de redémarrer les Cisco CallManagers sur une base hebdomadaire. Windows 2000 Service Pack installé 1 et une difficulté de mémoire virtuelle aux serveurs CallManagers. Comme précaution supplémentaire, la NOTA: a été informée pour redémarrer les CallManagers chaque semaine pour que les mois ultérieurs assurent la stabilité maximum. La NOTA: devrait décider d'arrêter les réinitialisations hebdomadaires une fois considérée appropriée.
A944914 WFQ ne fonctionne pas au-dessus du Multi-PPP au-dessus du multiple 2 liens de Mbits/s. La commande de Service-stratégie pour l'implémentation LLQ disparaît après un certain temps donnant le comportement BLÊME indéterminé. Trois options sont disponibles pour traiter cette question :
  • Pour toutes les interfaces dans le paquet MPPP, placez la bande passante sur les interfaces série au moins à 4800 (4/3 x 3600).
  • Mise à jour à 12.2.018 qui est une version d'avant-première de 12.2. C'est De (pas TAC) pris en charge. La question est réparée dans cette version.
  • Implémentez la file d'attente à priorité déterminée pour une autre saveur de QoS BLÊME.
Le bouton Message au téléphone ne fonctionnait pas au commencement. Les configurations suivantes sont exigées pour activer le bouton Message :
  • Dans les paramètres de service, introduisez le numéro de poste de messagerie vocale comme valeur pour le champ de VoiceMailDN.
  • Dans des paramètres d'entreprise, introduisez le numéro de poste de messagerie vocale comme valeur pour le champ de MessageDirectoryNumber.
Haut niveau du trafic d'émission de la carte d'E1 (WS-X6608) due à une bogue dans le code de Protocole ARP (Address Resolution Protocol) sur le module de skinny gateway du Catalyst 6509. Comme contournement, les cartes d'E1 (WS-X6608) sont configurées dans un VLAN distinct. Ceci ramène la taille du cache d'ARP à un maximum de trois entrées. En même temps, une nouvelle mise à jour du firmware de skinny gateway (D004R300) a été chargée dans les modules pour réparer le problème.
Perte de cos à travers le lien WAN. Une des nouvelles caractéristiques dans le Logiciel Cisco IOS version 12.1(5)T et est plus tard cartographie de Tos-à-cos. Avec ceci, le routeur peut placer le CoS=ToS avant d'envoyer n'importe quoi au Catalyst 6509. Le Catalyst 6509 est alors configuré pour le confiance-cos sur le port de routeur, et prend la valeur de DSCP interne de là. Cisco QoS met à jour le tos et les valeurs CoS utilisant le DSCP.
La table ARP a été corrompue, ayant pour résultat une perte de flux audio en accédant au système de messagerie voix par la carte WS-X6624. Comme contournement, les cartes FXS (WS-X6624) sont configurées dans un VLAN distinct. Ceci ramène la taille du cache d'ARP à un maximum de trois entrées. En même temps, une nouvelle mise à jour du firmware de skinny gateway (A002S300) a été chargée dans les modules.
Fréquentez s'arrêter des ports FXS connectés au périphérique de messagerie vocale d'Octel. Ce problème semble commun avec le système de messagerie voix d'Octel avec la Connectivité (FXO) analogique. Le nombre de ports s'arrêtants peut varier quand le périphérique de messagerie vocale est relié avec différents systèmes PBX. Les PBX traditionnels ont normalement la capacité de remettre à l'état initial différents ports arrêtés sans affecter l'exécution globale de messagerie vocale. Cisco a facilité un utilitaire de DickTracy qui permet à des utilisateurs de remettre à l'état initial et surveiller des ports individuels sur la carte FXS. L'utilitaire de DickTracy peut être installé sur n'importe quel PC sur le réseau. Exécutez-le, et connectez à l'adresse IP de votre WS-X6624. Une fois que connecté, cliquez sur l'option. Mettez en marche se connecter, puis sélectionnez les commandes suivantes dans la ligne de commande champ : Pour obtenir l'état de port, entrez dans 5 états d'exposition (ceci fournit un état de chaque port. Avec DickTracy, les numéros de port sont 0 basé : Le port 1 sur la lame est le port 0 dans DickTracy). Pour remettre à l'état initial un port, entrez dans ce qui suit :
4 set kill port[x] 

!--- Where x is the 0-based port number.

5 disable port x
5 enable port x
Aucune surveillance disponible pour l'installation de Multilien. Les différentes liaisons série ne peuvent pas être IP activé. La recommandation est d'employer le Protocole SNMP (Simple Network Management Protocol) pour voter l'état d'interface. Il y a plusieurs manières de faire ceci. L'option testée est de créer un script Unix pour utiliser la commande de snmpget de collecter l'état d'interface la même manière que la commande de script de ping fait. Une autre option est d'étendre la fonction du MRTG (c'est un outil SNMP de logiciel gratuit à l'utilisation de collect interface) pour collecter l'état d'interface. L'option est d'utiliser une application d'administration réseau basée sur SNMP.
B300309 Le routeur redémarre périodiquement en raison de l'erreur sur le bus. Le comportement anormal de traitement des paquets a été détecté dans des révisions tôt du matériel de PA-2FEISL comme décrit dans la question CSCdm74172 (clients enregistrés d'ID de bogue Cisco seulement). Les questions ont été abordées par un changement matériel aux adaptateurs rapides de port 2-port Ethernet/ISL. Les cartes PA-2FEISL-xx avec des nombres de révision de matériel égaux à ou plus tard que les révisions de matériel répertoriées ci-dessous ne sont pas affectées. La révision 2.0 NOTA: de matériel de la révision 1.2 de matériel PA-2FEISL-TX et PA-2FEISL-FX utilisait la révision 1.1 de matériel.
A953213 Incapable d'accéder à la page d'utilisateur de Cisco CallManager. Cette question a été résolue suivant la procédure suivante.
  1. Allez à la page de CCMAdmin. Cliquez sur le système sur le menu principal et puis cliquez sur les paramètres d'entreprise.
  2. De la page de paramètre d'entreprise, vérifiez le LDAP : Service Cisco Base et LDAP : Paramètres de base de clients. (LDAP : Le Service Cisco Base devrait être o=cisco.com et LDAP : La base de clients devrait être des =Users OU, o=cisco.com.)
Après mise à jour de ces paramètres, tous les utilisateurs pouvaient ouvrir une session de la page utilisateur. Le problème a été trouvé dans le Cisco CallManager 3.0.4 où les paramètres mentionnés ci-dessus étaient NULS.


Informations connexes


Document ID: 13968