Voz y Comunicaciones unificadas : Cisco Unified Communications Manager (CallManager)

Caso práctico de instrumentación de telefonía IP: Boletín nacional Singapur

24 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Abril 2015) | Comentarios


Contenido


Introducción

Este documento pone a disposición el cliente de Cisco, los Partners, y los empleados las experiencias y las lecciones doctas del despliegue de la Telefonía IP en el National Bulletin (NB) en Singapur. Este documento intenta:

  • Describa y critique el diseño de la solución desplegada.

  • Identifique las mejoras posibles al diseño.

  • Resalte los equilibrios en el diseño.

El NB es un editorial global. La oficina de Singapur consiste en aproximadamente 6,000 ventas, la impresión, y el personal de la escritura. El personal NB reside en varios edificios de oficinas situados dentro de la misma vecindad. En finales de 2000, el NB agregó otro edificio, los DB que construían, a su campus. Este edificio adicional contiene a 750 empleados. Bastante que una Central telefónica privada (PBX) en el nuevo edificio, NB decidido para desplegar una solución de telefonía IP. Como tal, el despliegue greenfield incluye el componente de la red.

La solución de telefonía IP NB es un diseño del solo-sitio. Todos los usuarios de la Telefonía IP están situados en los DB que construyen, y distribuidos a través de cinco suelos. Los gatewayes de los CallManageres, del Public Switched Telephone Network de Cisco (PSTN), y el correo de voz se establecen también físicamente en la construcción DB.

Un link del Red de área ancha (WAN) conecta los DB que construyen con la construcción NBAP menos de 1 kilómetro lejos. Este link PÁLIDO lleva el tráfico del protocolo voice over internet (VoIP) a través al NBAP, donde un gateway conecta en el NB PBX la red mundial. Este diagrama muestra los DB y las construcciones NBAP.

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

Infraestructura LAN de oficinas centrales

La infraestructura LAN DB consiste en un Catalyst 6509 Switch en la base y nueve Catalyst 4006 Switch en los Wiring Closet. Esta tabla muestra cómo se puebla el Catalyst 6509 Switch.

Ranura Módulo Descripción
1 WS-X6K-SUP1A-MSFC Supervisor con el (MSFC) de la Multilayer Switch Feature Card
2 WS-X6K-S1A-MSFC2/2 Supervisor con el MSFC
3 WS-X6416-GBIC módulo 16-port GE
4 WS-X6408A-GBIC módulo 8-port GE
5 WS-X6348-RJ45V módulo 48-port 10/100 con la alimentación en línea
6 WS-X6608-E1 gateway del e1 8-port
7 WS-X6624-FXS gateway de la Estación de intercambio remota (FXS) 24-port
8 WS-X6624-FXS gateway FXS 24-port
9 Vacío

Esta tabla muestra cómo se pueblan los Catalyst 4006 Switch.

Ranura Módulo Descripción
1 WS-X4013 Supervisor 2 con dos puertos del Gigabit Ethernet (GE)
2 WS-X4148-RJ45V módulo 48-port 10/100 con la alimentación en línea
3 WS-X4148-RJ45V módulo 48-port 10/100 con la alimentación en línea
4 WS-X4148-RJ45V módulo 48-port 10/100 con la alimentación en línea
5 WS-X4148-RJ45V módulo 48-port 10/100 con la alimentación en línea
6 WS-X4148-RJ45V módulo 48-port 10/100 con la alimentación en línea

La capacidad total de la infraestructura LAN es conectar y accionar 2,160 Teléfonos IP.

Los Catalyst 4006 Switch conectan de nuevo al Catalyst 6509 por uno de los puertos de GE en el supervisor, en una moda pura del hub-and-spoke. Cuatro de los cinco suelos tienen dos Catalyst 4006 Switch mientras que el quinto suelo tiene un Catalyst 4006 Switch. Este diagrama ilustra cómo el Switches se separa a través de los suelos y cómo él conecta de nuevo al Catalyst 6509 Switch.

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

El Catalyst 6509 constituye un solo punto de falla serio. Una mejora importante en la Disponibilidad se puede alcanzar agregando un segundo Catalyst 6509, y la reposición doble los Catalyst 4006 Switch a ambos switches del núcleo usando el puerto de repuesto de GE en los supervisores del Catalyst 4006. Con este diseño, hay poca alineación para la duplicación todos los módulos en el Catalyst 6509. Bastante, los módulos que existen (los supervisores, GE, y los módulos FXS) se pueden partir a través de los dos chasis. Sin embargo, un módulo ocho puertos adicional del e1 debe ser agregado para poder también partir la conectividad PSTN a través de los dos chasis. Este diseño también permite para que los dos CallManageres de Cisco sean conectados con los switches diferentes. Esto se asegura de que un error del Catalyst 6509 no aísle totalmente los CallManageres de Cisco.

Un segundo Catalyst 6509 Switch era parte de la oferta inicial. Sin embargo, debido costar las consideraciones, el NB decidía sobre un solo Catalyst 6509.

El NB sigue las recomendaciones sobre diseño de Cisco y tiene los Teléfonos IP y dispositivos de datos en los LAN virtuales separados (VLA N). Cada Catalyst 4006 tiene su propio VLA N de la Voz. Por lo tanto, hay dos VLA N de la Voz por el suelo, para un total de VLA N de nueve Voces. Cada Catalyst 4006 tiene 240 puertos. Por lo tanto, cada VLA N de la Voz es potencialmente casero a 240 Teléfonos IP. Esto es un diseño conservador, pero tiene la ventaja que limita el impacto si un dispositivo en mal funcionamiento inunda el VLA N con los broadcasts. Cuando las rutas del Catalyst 6000 Family MSFC entre los VLA N, acodan el rendimiento de reenvío 3 no es un problema.

65365.gif

Todos los dispositivos de datos residen en un VLA N solo, grande. Esto no cumple con las recomendaciones sobre diseño de Cisco. Sin embargo éste era el diseño preferido por el NB debido a su operativo y requisitos de mantenimiento internos. Porque este solo VLAN de dato atraviesa todo el Switches, una tormenta de broadcast de la capa 2 en este VLA N tiene el potencial para afectar a todos los Teléfonos IP. Esto hace el Calidad de Servicio (QoS) en los switches de Catalyst aún más crítico. QoS se discute más adelante en este documento.

Este ejemplo muestra una configuración de VLAN típica para un puerto del Catalyst 4006. Este ejemplo coloca los 48 puertos en el slot 5 en el VLA N 110 de la Voz y el VLAN de dato 11.

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

La red NB tiene estos tres límites de confianza distintos de QoS:

  • Puerto del Catalyst 4006 10/100.

  • Puerto del Catalyst 6509 10/100 que conecta con el Cisco CallManager.

  • Puerto del Catalyst 6509 10/100 que conecta con el Cisco 7200 Router.

De los módulos del Catalyst 4000 el 10/100 funcionando hace que un solo reciba la cola (RX) (1q1t) y dos transmiten las colas de administración del tráfico (TX) (2q1t). Todos los puertos se configuran con los comandos en este ejemplo de habilitar la segunda cola TX, y de poner las tramas con un valor del Clase de Servicio (CoS) entre 2 y 7 en la segunda cola. Como consecuencia, todos los paquetes del Real-Time Transport Protocol (RTP) (CoS=5) y todos los paquetes delgados (CoS=3) entran la segunda cola, mientras que el resto del tráfico entra la primera cola.

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

Observe que el Catalyst 4006 no soporta ninguna clase de policing. Confía en CoS de cualquier bastidor recibido en sus puertos. Esto no es un problema mientras un teléfono del IP esté conectado puesto que el comportamiento predeterminado del teléfono del IP es no confiar en el tráfico recibido en el puerto de PC, y reescribirlo con CoS de 0. Sin embargo, un PC conectado directamente con un puerto del Catalyst 4006 puede potencialmente explotar el QoS si envía los datos como tramas 802.1p. Esto requiere a un usuario algo sofisticado. Sin embargo, el Network Interface Cards del Windows 2000 y de los Ethernetes estándars (NIC) soporta 802.1pq.

La configuración de QoS en el Catalyst 6509 está levemente más implicada puesto que los puertos en el Catalyst 6509 tienen una variedad de estructuras de la cola, tal y como se muestra en de esta tabla.

Módulo Recibir cola Cola de transmisión
WS-X6K-SUP1A-MSFC 1p1q4t 1p2q2t
WS-X6416-GBIC 1q4t 2q1t
WS-X6408A-GBIC 1p1q4t 1p2q2t
WS-X6348-RJ45V 1p1q4t 1p2q2t

Cualquier puerto que tenga una cola de prioridad estricta pone todas las tramas con CoS=5 en esa cola por abandono. Sin embargo, se prefiere para tener todo el tráfico de señalización VoIP (tramas con CoS=3) en la segunda cola sin prioridad. Esta configuración habilita este comportamiento.

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

Los puertos de GE que conectan con los Catalyst 4006 Switch están dentro de nuestro límite de confianza. El sistema confiaría en normalmente CoS de las tramas recibidas. Puesto que el límite de confianza del Catalyst 4006 puede ser comprometido conectando un PC directamente con un puerto del switch, el tráfico de los Catalyst 4006 Switch se trata como untrusted, y es limpiado por el Catalyst 6509. El policing es hecho por un Access Control List (ACL) que busca los paquetes RTP, flaco, H.225, y H.245. Las encabezados de paquete RTP se reescriben con el DSCP=46 mientras que todas las encabezados de paquete de señalización de VoIP se reescriben con el DSCP=26. El ACL para esto, tal y como se muestra en de este ejemplo, se asocia a todos los puertos 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,

Dos de los puertos de 10/100 en el Catalyst 6509 se utilizan para conectar con dos Cisco los CallManageres. Éstos son esencialmente puertos confiables, pero en la red NB se tratan como untrusted, y las fuerzas CoS=3 del Catalyst 6509 en las tramas recibidas. Este ejemplo muestra la configuración del puerto.

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

Una alternativa, y un acercamiento más limpio, es configurar el Cisco CallManager para fijar el valor del Differentiated Services Code Point IP (DSCP) en todos los paquetes de señalización de VoIP. Para hacer esto, fije los parámetros de servicio IpTosCm2Cm y el IpTosCm2Dvce a 0x26 en el Cisco CallManager. El Catalyst 6509 se puede entonces configurar para confiar en el DSCP para las tramas recibidas en ese puerto, tal y como se muestra en de este ejemplo.

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

Este acercamiento tiene la ventaja que solamente las tramas VoIP-controladas, y no cada trama del Cisco CallManager, reciben buen QoS. Esto es importante si una imagen de la actualización del CallManager de Cisco está cargada al servidor del CallManager, o si una gran cantidad de registros de detalles de la llamada (CDR) se quitan rutinario del servidor. Actualmente, esta clase de tráfico también recibe un alto QoS.

Finalmente, uno de los puertos de 10/100 en el Catalyst 6509 se utiliza para conectar con las Cisco 7200 Series el router de WAN. Esto es también un puerto confiable, pero Cisco actual IOS� funcionando en el Cisco 7200 Router no copia el valor DSCP al campo de CoS. Para superar esta limitación, el puerto del switch se trata semejantemente a los puertos de GE (clasifique el tráfico entrante usando el mismo ACL) y proporciona selectivamente QoS basado en esto. Por lo tanto, la configuración para el puerto del switch del router se muestra en este ejemplo.

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

Infraestructura de WAN

El componente WAN de la red de telefonía IP NB es pequeño. El Cisco 7200 Series Router en la construcción DB tiene links PÁLIDOS al NBAP y a las torres capitales. Sin embargo, solamente el link al NBAP lleva la Voz. Incluso entonces hay links separados entre los DB y el NBAP para la Voz y los datos. Los problemas de calidad de voz fueron descubiertos durante las fases tempranas del despliegue, y era decidido para cambiar el codificador-decodificador de G.729 a G.711. Este ancho de banda adicional requerido, y la Voz y los datos sobre WAN por lo tanto fueron separados. La causa de estos problemas fue encontrada más adelante para estar con la carga del teléfono del IP funcionando en ese entonces. Como medida conservadora, el NB decidía a permanecer con G.711 y a separar los links PÁLIDOS para la Voz y los datos a corto plazo.

El link PÁLIDO de la Voz consiste en actualmente tres links físicos del e1 que sean liados juntos por el Multilink PPP (MLP). Debido al relativamente de alta velocidad del link, no se requiere ningún Link Fragmentation and Interleaving (LFI). El único requerido función de calidad de servicio (QoS) está haciendo cola. El Mecanismo para formar la cola preferido es Low Latency Queuing (LLQ). Sin embargo, esto no trabajó debido al Cisco IOS publica con el LLQ y el MLP, donde el comando service-policy desapareció de la configuración si fue el link abajo. Como método alternativo interino, la cola prioritaria ha sido funcionando. Este ejemplo muestra la configuración WAN actual.

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 configuración WAN actual es un compromiso y no se recomienda para el uso en otras implementaciones. El plan a medio plazo es consolidar la Voz y los datos encendido a un solo link PÁLIDO, y substituir la cola prioritaria por el LLQ. Los links separados para la Voz y los datos requieren el Static Routing o el Policy-Based Routing, y las ventajas de usar un Dynamic Routing Protocol se pierden. Cola prioritaria, incluso con los paquetes de voz que son asignados la alta cola, no garantiza que la prioridad estricta está dada a los paquetes de voz. El tráfico del sistema, tal como actualizaciones de ruteo, Keepalives, y así sucesivamente todavía toma la preferencia sobre los paquetes de voz en la alta cola.

Se ha verificado que el LLQ trabaja correctamente en el Cisco IOS Software Release 12.2. Este ejemplo muestra al router QoS, después del movimiento al LLQ. Los anchos de banda se basan en 60 llamadas simultáneas de G.729 (RTP: 60 x 24 kbps = 1440 kbps y señalización: 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

IP Telephony

Teléfonos del IP y su conexión al switch

La construcción DB tiene aproximadamente 750 teléfonos del IP 7960s. Los Teléfonos IP conectan con 10/100 los puertos en el Catalyst 4006, y reciben la alimentación en línea del Switch. Los PC conectan con los puertos del switch en la parte posterior del teléfono del IP, según lo representado en este diagrama.

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

Los Teléfonos IP y los PC están en los VLAN distintos y las subredes IP.

Planeamiento de sitio

Todos los Teléfonos IP reciben la alimentación en línea del linecards del Catalyst 4006. El Switches ellos mismos es accionado por tres fuentes del en-chasis corriente de CA. La alimentación en línea, sin embargo, es originada externamente del estante de energía auxiliar 4006 de Catalyst (WS-P4603). El estante de energía tiene tres fuentes de alimentación. Cada uno suministra 1050W en -52V DC. Esto es suficiente accionar un Catalyst 4006 Switch completamente poblado con el Cisco IP Phone 7960s conectado con los 240 puertos.

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

Todos los Catalyst 4006 Switch se fugan un (UPS) de la fuente de alimentación ininterrumpida. Esto permite que continúen la operación por dos horas en caso de corte del suministro de electricidad. Los CallManageres de Cisco conectan con UPS de cuatro horas.

CallManager de Cisco

El modelo de la instrumentación de CallManager NB es solo sitio con el proceso de llamada centralizada. Uno puede sostener que el modelo es de hecho multi-sitio debido al link PÁLIDO al NBAP y el gateway asociado localizado allí. Pero se ignore este hecho puede (en general) pues no se requiere ningún control de admisión de llamadas (CAC) a través de WAN. Esto es porque el número de llamadas a través de WAN es limitado implícito por el número de trunks que conectan el gateway con el PBX.

El clúster del Cisco CallManager NB consiste en dos Cisco Media Convergence Server 7835s (MCS-7835). Un CallManager realiza la función de la publicación de la base de datos, y el otro inscribe a la base de datos. Todo el registro de los Teléfonos IP con el suscriptor como el CallManager primario de Cisco, y utiliza al editor como el Cisco CallManager secundario.

Se configuran dos regiones: NBAP y DB. El gateway en el NBAP es el único dispositivo en la región NBAP, todos los otros dispositivos está en la región DBS. El diseño previsto es utilizar G.711 para todas las llamadas dentro de los DB que construyen, y uso G.729 solamente para las llamadas a través de WAN. Actualmente, sin embargo, las llamadas a través del link PÁLIDO son también G.711.

Los Teléfonos IP en la región DBS tienen una extensión de cinco dígitos en el rango de 17000 a 17999. Hay cinco otros sitios NB en Singapur que tienen una mezcla de cuatro y extensiones de cinco dígitos. Esta tabla muestra los sitios NB Singapur.

Nombre del sitio Código del sitio Dígitos
Department of Binding Singapore DB 5
Impresión de la cumbre NB NBAP 5
Cumbre que construye A ABA 4
Cumbre que construye B ABB 5
Impresión de Douglas DP 4
Impresión de Grant GP 4

Se asignan las Extensiones de modo que el primer dígito determine únicamente si la extensión es cuatro o cinco dígitos. Los usuarios del teléfono del IP pueden marcar cualquier NB Singapur extensión PBX marcando los cuatro o la extensión de cinco dígitos.

Según lo discutido más adelante en integración de la gateway la sección, hay tres tipos de gatewayes:

  • Un gateway de H.323 del Cisco 7200 que conecta con el NB PBX de la herencia una red.

  • Tres gatewayes del e1 del Catalyst 6509 que conectan con el PSTN.

  • Dos gatewayes FXS del Catalyst 6509 24-port que conectan con el correo de voz.

Esto se refleja en la configuración del Grupo de Routes del Cisco CallManager. Un Grupo de Routes existe para cada uno de los tres tipos de gateway. Esta tabla delinea las características de cada Grupo de Routes.

Grupo de Routes Plataforma /port del slot Tipo de puerto Prioridad
DB VM Catalyst 6509 Switch 6/1-24 7/1-24 FXS FXS 1 2
DB PSTN Catalyst 6509 Switch 8/1 8/2 8/3 PRI PRI PRI 1 2 3
Herencia NBAP Router Cisco 7200 5/1-2 PRI 1

Las llamadas a los diversos destinos se rutean como sigue:

  • Las llamadas al PSTN utilizan al Grupo de Routes DB PSTN. No hay respaldo.

  • Las llamadas al correo de voz utilizan al Grupo de Routes DB VM. No hay respaldo.

  • Las llamadas al servicio de Telnet NB utilizan la NBAP Legacy Route Group.

  • Las llamadas a un NB Singapur extensión PBX utilizan la NBAP Legacy Route Group como DB PSTN el Grupo de Routes primario, y como el grupo de la ruta secundaria.

Todo que ahora permanece es definir los modelos de la ruta apropiada y conectarlos a los Grupos de Routes. Esto es directo para los primeros tres elementos enumerados arriba, pues solamente se requiere una lista de la solo ruta. Las cosas consiguen levemente más implicadas con el elemento más reciente debido al grupo de la ruta de seguridad. El trayecto preferido para una llamada de un teléfono del IP a extensión PBX está con la NBAP Legacy Route Group. Si este gateway es inasequible, las llamadas se rutean con el PSTN a través del Grupo de Routes DB PSTN. Cuando sucede esto, los dígitos tienen que ser prefijados a la extensión marcada para crear el número de teléfono completo PSTN. Los dígitos prefijados dependen del sitio que es llamado, por lo tanto, cada sitio debe tener una diversa lista de la ruta. Porque hay cinco sitios NB con los PBX, y varios prefijos PSTN por el sitio, terminan para arriba con diez listas de la ruta.

Este diagrama muestra todas las listas de la ruta NB. Los dos o el número de tres dígitos incluidos en nombre de la mayoría de las listas de la ruta refleja los dígitos que se prefijan a la extensión llamada, siempre que las llamadas se envíen al Grupo de Routes DB PSTN.

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

Restringen a ciertos usuarios del teléfono del IP NB en los números que pueden llamar. Esto es controlada poniendo los patrones de ruta y las Extensiones del teléfono del IP en varias divisiones. Las divisiones entonces se agrupan juntas en un Calling Search Space. Los Teléfonos IP pertenecen a un Calling Search Space y pueden solamente llamar los números contenidos en las divisiones en ese espacio de búsqueda. Esta tabla enumera los espacios de búsqueda y las divisiones del Cisco CallManager NB.

Espacio de búsqueda Divisiones Descripción
Guest Call Attendant del invitado DBS NB SGP DB del usuario DBS El pasillo normal del teléfono del usuario DBS y el otro recepcionista del teléfono de área pública NB Singapur extensión PBX
Usuario Call Attendant del IDD DB del invitado DBS NB SGP del usuario DBS NB GSDN NB Telnet SGP PSTN Teléfono normal del usuario DBS — Llamadas internacionales por las Llamadas locales mundiales de la red NB en el pasillo de Singapur y el otro recepcionista de las llamadas internacionales de los teléfonos de área públicas NB Singapur extensión PBX

Integración del correo de voz

Los DB utilizan el sistema de correo de voz Octel. Esto fue elegida porque es un estándar mundial NB, y la red de correo de voz entre los diversos sistemas fue deseada.

El Cisco CallManager conecta con el sistema de correo de voz Octel mediante dos indicadores luminosos LED amarillo de la placa muestra gravedad menor 24-port FXS en el Catalyst 6509 Switch. Solamente 30 de los 48 puertos disponibles se utilizan. Un link del Simplified Message Desk Interface (SMDI) 9600 BPS conecta el CallManager primario de Cisco con el dispositivo Octel.

El sistema Octel también está conectado con la red Octel corporativa NB. Esto se hace mediante cuatro puertos de Oficina de intercambio remoto (FXO) en el dispositivo Octel que conecten con Lucent un Definity viejo PBX. Este diagrama muestra cómo el sistema Octel DB conecta con el nuevo y el viejo mundo.

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

Nota: El diseño inicial no incluyó el PBX. Bastante, la idea era a la red el correo de voz a través a través del indicador luminoso LED amarillo de la placa muestra gravedad menor 24-port FXS y de la red VoIP. Pero durante el piloto, los problemas fueron encontrados de la manera que el indicador luminoso LED amarillo de la placa muestra gravedad menor FXS manejó los tonos del Dual Tone Multi-frequency (DTMF) del dispositivo Octel. Como solución alternativa, el indicador luminoso LED amarillo de la placa muestra gravedad menor 24-port FXS fue substituido por un Cisco IOS Gateway. Esto trabajada muy bien, pero el NB prefirió la solución PBX-basada.

Vale el observar de las características de la resiliencia de la solución del correo de voz. Además del sistema de correo de voz, hay otros solos puntos de falla:

  • El link SMDI no es redundante: Un error del CallManager primario de Cisco tomará el Out Of Service del sistema de correo de voz. Si ocurre esta situación, la estrategia NB es mover manualmente el cable SMDI al Cisco CallManager de backup. Alternativamente, un divisor SMDI permitiría que ambos CallManageres fueran conectados al mismo tiempo, y permite la falla automática.

  • Ambos indicadores luminosos LED amarillo de la placa muestra gravedad menor 24-port FXS residen actualmente en el mismo chasis del Catalyst 6509. Un error del Catalyst 6509 tomará el Out Of Service del sistema de correo de voz. Según lo discutido anterior en este documento, hay mucho que se ganará en términos de resistencia agregando un segundo Catalyst 6509.

Integración del gateway

La tabla siguiente enumera los tres diversos tipos de Gateways de voz en la red NB.

Plataforma Tipo de interfaz Número de puertos Protocolo Conexión con
Catalyst 6509 PRI/E1 8 x 30 canales Flaco PSTN
Catalyst 6509 FXS analógico 2 x 24 Flaco Correo de voz
7206VXR PRI/CAS/E1 2 x 30 canales H.323 Herencia PBX

El Catalyst 6509 sostiene un solo indicador luminoso LED amarillo de la placa muestra gravedad menor ocho puertos del e1. Tres de estos ocho puertos conectan con el PSTN mediante el PRI. Cada puerto E1 tiene su propia dirección IP y sus funciones del puerto como gatewayes independientes. El ruteo de llamadas a y desde los gatewayes es controlado por el Cisco CallManager mediante el Skinny Protocol. Los usuarios marcan un número PSTN marcando 0, seguido por el número PSTN. Las llamadas entrantes tienen los dígitos principales eliminados, y la llamada se rutea al teléfono del IP llamado basado en los cinco dígitos más recientes.

Los usuarios marcan el '9' para seleccionar una línea exterior, y el Cisco CallManager quita este dígito antes de presentar la llamada al PSTN. El NB intentó dos métodos de quitar el dígito. El primer método incluye un “punto” en el patrón de ruta en el Cisco CallManager, y todos los dígitos del PRE-punto se desechan antes de presentarlo al PSTN. El segundo, y el método preferido, es configurar el descarte como parte del gateway puesto en el Cisco CallManager. Esto es hecha fijando el número de dígitos para eliminar el campo a uno. Este segundo método es mejor porque preserva el '9' principal en que el número se salva en el directorio puesto de las llamadas en el teléfono del IP. Esto significa que el usuario puede volver a marcar más adelante el número del directorio sin tener que presionar editdial y agregar el '9' principal.

Los gatewayes FXS se utilizan solamente para el correo de voz. Estos gatewayes son controlados por el Cisco CallManager mediante flaco.

El gateway del Cisco 7200 proporciona la Conectividad entre la red de telefonía IP en los DB y la red mundial del NB PBX. Este gateway es el único dispositivo de VoIP establecido no físicamente en la construcción DB: Está situado en la construcción NBAP, y alcanzado mediante un link PÁLIDO.

El gateway del Cisco 7200 se cabe con un solo adaptador cuadripolo del puerto E1, y utiliza H.323 para hablar con el CallManager. Ambos puertos del e1 conectan con Nortel un meridiano situado en el NBAP. Uno los USOS de puertos QSIG y el otro Señalización asociada al canal (CAS) de las aplicaciones de hablar con el PBX. Las llamadas a las Extensiones de Singapur PBX se rutean abajo del puerto QSIG, mientras que las llamadas internacionales, usando la red de voz privada (Telnet), se rutean a través del puerto de CAS.

La mezcla de CAS y de QSIG complica la configuración. CAS se requiere para proporcionar el acceso al Marcado internacional código-protegido personal del número de identificación (PIN) por la red de voz Telnet mundial. Cuando un usuario marca este servicio, marcan 313xxxxxx, donde está un código el xxxxxx del PIN del seis-dígito. La aplicación Meridian que autentica este código del PIN no aparece ser soportada por el PRI. Por lo tanto, la necesidad de utilizar CAS en uno del para este propósito de dos trunks.

Eso dicha, CAS que señala más fácil probada conseguir que va que el troncal QSIG. Entre los problemas encontrados eran los slots de tiempo que bloqueaban para arriba en el meridiano y el desacuerdo sobre el número de canal B. Casi todos los problemas tuvieron que hacer con una discordancía de los parámetros de la configuración en el lado del Cisco 7200 y del meridiano. Estos problemas fueron resueltos después de que el Cisco IOS proporcionara a una configuración de Meridian de trabajo.

Una copia de la configuración de Meridian es incluida abajo. Esta configuración es de un Meridian Option 11C, Software Release 24.24 corriente. Los paquetes de software siguientes se requieren para activar esta configuración.

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

La configuración siguiente es del bloque de datos del config route.

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

Esta configuración es del 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)

Esto es una configuración para los temporizadores del loop para la interfaz de línea de interconexión 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

Esta configuración es del 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 configuración de gateway para los dos trunks del e1 se muestra aquí. Note que el gateway actúa como el lado de la red, mientras que el meridiano es el lado del usuario.

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

El gateway tiene 15 POTS dial peer. La mayor parte de los dial peer señalan el troncal QSIG, reflejando las diversas Extensiones PBX que son accesibles en el lado PBX.

Los dial peer restantes señalan el tronco CAS, las llamadas de dirección a la red de voz Telnet. También note que el troncal QSIG está configurado para incluir un Progress Indicator con un valor de 8 cuando envía un mensaje que alerta de nuevo al PBX. Esto dice a PBX que el gateway está proporcionando al tono de recepción dentro de la banda, y el PBX abre el trayecto de audio incluso antes de que una llamada es contestada por el teléfono del 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

Hay solamente dos voip dial peer, uno señalando a cada Cisco CallManager. Los dial peer son idénticos a excepción de la preferencia, que se asegura de que las llamadas estén ruteadas al CallManager primario de Cisco cuando están disponibles. El permiso 3 de la configuración del progress_ind dice el gateway señalar al PBX, por un Progress Indicator en el mensaje setup, que la parte llamadora es no ISDN. Finalmente, el descanso tcp del h225 establece 3 dice el gateway esperar un máximo de tres segundos al establecer una sesión H.225 con el Cisco CallManager. Si el Cisco CallManager no responde en el plazo de tres segundos, el gateway intenta el Cisco CallManager secundario.

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

Algunos de los problemas más persistentes encontrados durante el rollout del NB proyecto de telefonía IP pertenecieron para producir eco. Los problemas principales de la generación de eco fueron experimentados por los usuarios del teléfono del IP cuando llamaron ciertos números a través del gateway del Cisco 7200. El esfuerzo que entró intentar reducir la generación de eco era extenso, y las tentativas de la siguiente información capturar las partes de esta experiencia que puede ser útil a otras implementaciones.

La expectativa inicial del equipo de diseño de telefonía IP estaba para que el gateway del Cisco 7200 proporcione la Conectividad entre el lado VoIP y un solo PBX en el NBAP. Tal como vino la cosa, qué de hecho era proporcionada era Conectividad entre el lado VoIP y muy grande, mundial la red de voz NB. La red de voz NB tiene una herencia sus los propio, incluyendo varios Problemas de eco. En el pasado, el NB intentó ajustar los niveles de potencia de los diversos Nodos en esta red para minimizar la cantidad de generación de eco. La red con la cual el gateway del Cisco 7200 conectaba era una red con los Problemas de eco existentes. También tenía niveles variables de potencia de la señal, dependiendo del destino de la llamada. Esto era una integración dificultosa.

Introduciendo una solución de la voz empaquetada, con sus retardos adicionales, los Problemas de eco fueron exacerbados. En un esfuerzo para dirigir esto, los ajustes siguientes fueron hechos.

  • Los canceladores de eco del Cisco 7200 fueron ajustados a su configuración más agresiva.

  • La ganancia de entrada fue bajada.

  • La atenuación de la salida aumentó en los dos trunks del e1.

Mientras que esto redujo la generación de eco, tenía el efecto secundario indeseable que los niveles de volumen, al llamar ciertos destinos en la red de voz NB, eran demasiado bajos y se quejaban los usuarios. Debido a la discordancía de los niveles de la señal en el lado de la herencia, había nadie combinación de aumento y de atenuación que se adaptó a las llamadas a y desde todos los destinos. Qué trabajada bien para las llamadas a Hong Kong creó la generación de eco en las llamadas a Corea. Qué trabajada para Corea dio lugar a los problemas del volumen bajo para Hong Kong. La configuración abajo muestra la configuración de compromiso actual para los puertos de voz en el gateway del 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

La ingeniería de desarrollo está trabajando actualmente en la mejora de las capacidades de la Cancelación de eco de algunos Productos Cisco. El NB está aguardando estas mejoras para reducir más lejos la generación de eco.

Las soluciones alternativas fueron propuestas al NB, pero el cliente ha decidido esperar las mejoras de Cisco. Dos propusieron que las soluciones alternativas estén discutidas abajo con la esperanza de que otros proyectos puedan beneficiar de ellas. La lección general aprendida del NB es que una alerta de la indicación roja debe ser aumentada temprano si la solución de telefonía IP propuesta conecta con una red de voz heredada privada grande. De esta manera, estas soluciones alternativas se pueden diseñar y costar en la solución desde el principio.

  • Workaround 1 — Inserte los canceladores de eco del otro vendedor entre el gateway de Cisco y el PBX. Tecnología de cancelación de eco de Cisco puede cancelar actualmente las colas de la generación de eco que se retrasan menos entonces el ms 32. La señal producida eco debe estar conforme a una Pérdida de retorno de eco (ERL) por lo menos del 6 dB, es decir, la señal recibida de la generación de eco debe ser por lo menos 6 dB más bajo que originalmente la señal transmitida. Para que sea de mérito, el funcionamiento de la canceladora del otro vendedor debe exceder los valores antedichos.

  • Workaround 2 — Aumente el número de trunks entre el gateway de Cisco y el PBX. Esto permite que cada trunk sea configurado con una diversa configuración de ganancia/atenuación. Las llamadas se pueden entonces rutear a través del trunk con la mayoría de las características de eco adecuadas. Por ejemplo, las llamadas a Hong Kong pueden pasar a través del trunk 1 mientras que las llamadas a Corea pasan a través del trunk 2. El PBX también necesita poder rutear las llamadas a través del trunk correcto, sobre la base de donde la llamada origina.

Aprovisionamiento de DSP para conferencia y conversión de códigos

Aunque G.711 se utilice actualmente en la red, la intención es utilizar G.729 a través del link PÁLIDO entre los DB y el NBAP. El diseño ha tomado en cuenta esto afectando un aparato a los recursos de conferencia del procesador de señales digitales del hardware (DSP). Los Recursos de hardware residen en el Catalyst 6509. Recuerde que solamente tres de los ocho puertos del e1 son funcionando para la conectividad PSTN. Tres de los cinco puertos restantes se utilizan para la Conferencia.

Hay dos puertos sin utilizar en el módulo del e1 del Catalyst 6509 que se configuran como recursos de transcodificación. No hay actualmente una necesidad de la transcodificar, pero la necesidad se presentará si el NB decide a desplegar un servidor de la respuesta de voz interactiva IP (IVR).

‘Versiones de software’

La tabla siguiente enumera las versiones de software usadas en la red NB cuando este documento fue escrito.

Dispositivo Versión
Catalyst 6509 5.5(3)
Catalyst 4006 6.1(1)
Cisco 7260VXR 12.1(3a)XI5
CallManager de Cisco 3.0(8)
Teléfono del IP 7960 P003Q301
WS-X6608-E1 C001W300
WS-X6624-FXS A002S300

Administración de la red

Las herramientas de administración de red no se utilizan actualmente para manejar la red de telefonía IP NB.

Lecciones aprendidas

Anomalías, advertencias y resoluciones halladas

La tabla siguiente resume los aspectos importantes encontrados durante el despliegue. Los detalles de estos problemas se discuten anterior en este documento.

Advertencia Resolución
Produzca eco al interconectar la red de voz en paquetes a una red de voz heredada grande. Los trunks adicionales de la Comisión y varían el aumento/la atenuación para poder rutear las llamadas a través de un trunk con una configuración adecuada. Despliegue los canceladores de eco del otro vendedor. Await mejoró tecnología de cancelación de eco de Cisco.
Los parámetros unidos mal QSIG en el gateway y el PBX echan a un lado. Configuraciones de PBX de trabajo Obtain de un sitio existente usando una configuración similar.
Dígito para seleccionar la línea exterior no salvada en el directorio de las colocar-llamadas. Deseche el dígito principal en una configuración de gateway y no utilice una acción del descarte del PRE-punto en el patrón de ruta.

Casos TAC

La tabla siguiente enumera todos los problemas que dieron lugar a un caso TAC. También incluidos son otros problemas importantes que fueron resueltos localmente por el equipo de instrumentación.

— — — — — — — — — —
Caso # Descripción Estatus y resolución
B124306 Bloqueo de canal QSIG. Resuelto inicialmente configurando de nuevo el parámetro del Channel Negotiation LD17 (CNEG) en Nortel PBX a partir de Option(2) a Option(1). Sin embargo, los síntomas del problema reaparecieron después de una cierta hora. Posteriormente, el proveedor de PBX cambió la configuración de QSIG PRI en el PBX de ESIG (configuración de QSIG GF) a ESGF (configuración de QSIG europea). Después de la modificación, el cierre del canal dejado para ocurrir pero solamente los 15 canales superiores era funcionales. Para rectificar el problema, quitaron al comando ISDN contiguous-bchan del router VoIP.
A612818 Discordancía del Canal B donde Nortel PBX utiliza el canal 31 como el canal de control mientras que el gateway de voz de Cisco PRI utiliza el canal 16. Resuelto configurando el comando ISDN contiguous-bchan en la interfaz PRI QSIG. Se utiliza este comando de especificar el canal portador contiguo que dirige de modo que los Canales B 1 a 30 (el canal que salta 16) asocien a los slots de tiempo 1 a 31. Esto está disponible para las interfaces del e1 PRI solamente cuando la opción del tipo de switch primario-QSIG se configura usando el comando isdn switch-type.
B124306 Generación de eco. Hay dos escenarios en los cuales los 7200 canceladores de eco pueden no poder anular una generación de eco. Escenario 1: La generación de eco es demasiado ruidosa para que las canceladoras se anulen. Escenario 2: La generación de eco es retrasada por más el ms de 32, que está más allá de la cobertura de las 7200 canceladoras. Escenario 1: Haciendo los ajustes a la atenuación de la salida y a la ganancia de entrada en el gateway de voz y los rellenos en PBX enormemente mejorado la situación de la generación de eco. Las configuraciones finales son:
  • Ganancia de entrada del Cisco 7200 PRI = 0
  • Atenuación de la salida de Ciisco 7200 PRI = 3
  • Ganancia de entrada de CAS del Cisco 7200 = -2
  • Atenuación de la salida de CAS del Cisco 7200 = 0
  • Atenuación PBX PRI TX = 2
  • Atenuación PBX PRI RX = 4
  • Atenuación PBX CAS TX = 0
  • Atenuación PBX CAS RX = 5
Los ecos residuales ocurren como ruido estático en los primeros 1 a 2 segundos de la secuencia RTP. La duración es inevitable para que el algoritmo adaptable entrene en la secuencia de audio y perfile hacia fuera una cancelación efectiva. Escenario 2: Una cola de la generación de eco más del ms de 32 es inverosímil en una red de voz analógica. Sin embargo, puede ocurrir en una red de voz en paquetes. Pues la Cobertura de cancelación de eco está actualmente en un máximo de 32 ms, el trabajo de desarrollo está en curso producir un código que integre un cancelador de eco obediente de G.168 del otro vendedor (con la longitud de la cola por lo menos del ms 64).
Ruido del cracker, calidad de voz deficiente (carga del teléfono). Firmware cargado P003Q301 en el teléfono del IP. La carga Q es más robusta hacia el jitter y el retardo.
Ninguna señal de llamada al teléfono del IP al llamar el Número externo por el QSIG. El gateway no genera el tono de recepción de llamada a menos que el mensaje setup contenga un progress indicator (PI) de 3 (la dirección de origen es no ISDN). Esto es porque el gateway asume eso sin un PI de 3, el switch de origen es ISDN y espera que el Switch genere el tono de recepción de llamada en lugar de otro. Sin el PI de 3 que fijan, el gateway está esperando que el switch ISDN generara el timbre, pero el switch ISDN no está generando el timbre. Esto puede ser debido a un problema de la interred ISDN. Para permitir al gateway para generar el tono de recepción de llamada, progress_ind de la configuración en el voip dial peer.
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
El antedicho entonces forzará el gateway para proporcionar el tono de recepción de llamada para las llamadas que salen en el ISDN ese tándem que voip dial peer.
A695422 Hay una diferencia en las duraciones de DTMF. Esto se puede causar por el hecho de que el Catalyst no está reconociendo correctamente los tonos DTMF enviados por el sistema de correo de voz. Al venir de un indicador luminoso LED amarillo de la placa muestra gravedad menor del Catalyst, la duración de DTMF es el ms 300 por abandono. Al venir del correo de voz, la duración es el ms 130. La especificación de Octel requiere que por lo menos cinco dígitos por segundo sean necesarios para que el apretón de manos trabaje correctamente. El Cisco CallManager envía actualmente el H245-SIGNALLING con una duración del ms 300, haciendo un total de 300*5 = el sec 1.5. En esta duración, el correo de voz Octel habrá medido el tiempo hacia fuera antes de que las encabezados de la red de correo de voz se reciban totalmente. Desvió el módulo FXS 24-port (dispositivo Skinny) con un gateway del Cisco 3640 (dispositivo de H.323) cargado con un indicador luminoso LED amarillo de la placa muestra gravedad menor FXS.
Audio unidireccional para las llamadas a través del gateway de voz. El problema es causado por el gateway que elige una dirección IP con excepción del del Loopback Interface. El loopback es la interfaz de la cual el tráfico de CallManager deja al router. Ponga el IP Address del srcaddr del lazo del H323-gateway voip en esta interfaz para forzar al router a utilizar la dirección IP especificada como la dirección de origen 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
En el Cisco CallManager, cambie el dispositivo de gateway de H.323 de un nombre a una dirección IP. Esto también previene cualquier problema no deseable con las operaciones de búsqueda reversas DNS/hosts.
El Cisco CallManager tiene un problema conocido donde sus servicios deterioran lentamente en un cierto plazo debido a la pérdida de memoria. Un arreglo temporal era reiniciar los CallManageres de Cisco en un semanalmente. Windows 2000 Service Pack instalado 1 y un arreglo de la memoria virtual a los servidores del CallManager. Como precaución adicional, el NB fue aconsejado reiniciar los CallManageres semanalmente para que los meses subsiguientes aseguren la estabilidad máxima. El NB debe decidir a parar las reinicializaciones semanales cuando está juzgado apropiado.
A944914 El WFQ no trabaja sobre el Multi-PPP sobre los links múltiples del 2 Mbps. El comando Service-policy para la implementación de LLQ desaparece un poco después dando el comportamiento PÁLIDO indeterminado. Tres opciones están disponibles para manejar este problema:
  • Para todas las interfaces en el conjunto MPPP, fije el ancho de banda en las interfaces seriales por lo menos a 4800 (4/3 x 3600).
  • Actualización a 12.2.018 que es una versión preliminar de 12.2. Éste es DE (no TAC) soportado. El problema se repara en esta versión.
  • Implemente la cola prioritaria para otro sabor de WAN QoS.
El botón Message Button en el teléfono no funcionaba inicialmente. Las configuraciones siguientes se requieren para habilitar el botón Message Button:
  • En los parámetros de servicio, ingrese el número de interno del correo de voz como el valor para el campo del VoiceMailDn.
  • En los parámetros Enterprise, ingrese el número de interno del correo de voz como el valor para el campo de MessageDirectoryNumber.
Nivel elevado de tráfico de broadcast del indicador luminoso LED amarillo de la placa muestra gravedad menor del e1 (WS-X6608) debido a un bug en el código del Address Resolution Protocol (ARP) en el módulo del gateway Skinny del Catalyst 6509. Como solución alternativa, los indicadores luminosos LED amarillo de la placa muestra gravedad menor del e1 (WS-X6608) se configuran en un VLAN distinto. Esto reduce los tamaños de la memoria caché ARP a un máximo de tres entradas. Al mismo tiempo, una nueva actualización del firmware de gateway Skinny (D004R300) se ha cargado en los módulos para reparar el problema.
Pérdida de CoS a través del link PÁLIDO. Una de las nuevas funciones en el Cisco IOS Software Release 12.1(5)T y Posterior es el asociar de TOS-a-CoS. Con esto, el router puede fijar el CoS=ToS antes de enviar cualquier cosa al Catalyst 6509. El Catalyst 6509 entonces se configura para el Trust-cos en el puerto de router, y coge valor DSCP interno de allí. Cisco QoS mantiene los valores TOS y de CoS usando el DSCP.
La tabla ARP fue corrompida, dando por resultado una pérdida de secuencia de audio al acceder el sistema de correo de voz por el indicador luminoso LED amarillo de la placa muestra gravedad menor WS-X6624. Como solución alternativa, los indicadores luminosos LED amarillo de la placa muestra gravedad menor FXS (WS-X6624) se configuran en un VLAN distinto. Esto reduce los tamaños de la memoria caché ARP a un máximo de tres entradas. Al mismo tiempo, una nueva actualización del firmware de gateway Skinny (A002S300) se ha cargado en los módulos.
La ejecución frecuente de los puertos FXS conectó con el dispositivo del correo de voz Octel. Este problema parece común con el sistema de correo de voz Octel con la Conectividad analogica (FXO). El número de puertos de la ejecución puede variar cuando el dispositivo de correo de voz se interconecta con diversos sistemas PBX. Los PBX tradicionales tienen normalmente la capacidad de reajustar los puertos colgados individuales sin la afectación de la operación total del correo de voz. Cisco ha facilitado una utilidad DickTracy que permite a los usuarios para reajustar y para monitorear los puertos individuales en el indicador luminoso LED amarillo de la placa muestra gravedad menor FXS. La utilidad DickTracy se puede instalar en cualquier PC en la red. Ejecútela, y conecte con la dirección IP de su WS-X6624. Una vez que está conectado, haga clic la opción. Comience a registrar, después ingrese los siguientes comandos en el campo de la línea de comando: Para conseguir el estado del puerto, ingrese 5 estados de la demostración (esto proporciona un estatus de cada puerto. Con DickTracy, los números del puerto son 0 basado: El puerto 1 en la cuchilla es el puerto 0 en DickTracy). Para reajustar un puerto, ingrese el siguiente:
4 set kill port[x] 

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

5 disable port x
5 enable port x
Ninguna supervisión disponible para la configuración del Multilink. Los links seriales individuales no pueden ser IP habilitado. La recomendación es utilizar el Simple Network Management Protocol (SNMP) para sondear el estatus de la interfaz. Hay varias maneras de hacer esto. La opción probada es crear una secuencia de comandos UNIX para utilizar el comando snmpget de recoger el estatus de la interfaz la misma manera que lo hace el comando ping script. Otra opción es ampliar la función del MRTG (esto es una herramienta del freeware SNMP para recoger la utilización de la interfaz) para recoger el estatus de la interfaz. La opción es utilizar una aplicación de administración de red SNMP basada.
B300309 El router reinicia periódicamente debido a error de bus. La conducta anómala de administración de paquetes fue detectada en las revisiones tempranas del hardware PA-2FEISL según lo descrito en el problema CSCdm74172 (clientes registrados solamente) del Id. de bug Cisco. Los problemas se han abordado a través de un cambio de hardware rápidamente a los adaptadores del puerto Ethernet/ISL 2-port. Los indicadores luminosos LED amarillo de la placa muestra gravedad menor PA-2FEISL-xx con los Números de revisión de hardware iguales a o que las revisiones de hardware enumeradas abajo no son más adelante afectados. La revisión de hardware 2.0 NB de la revisión de hardware 1.2 PA-2FEISL-TX y PA-2FEISL-FX utilizaba la revisión de hardware 1.1.
A953213 Incapaz de acceder las páginas del usuario del Cisco CallManager. Este problema fue resuelto usando el siguiente procedimiento.
  1. Vaya a la página del ccmadmin. Haga clic el sistema en el menú principal y después haga clic los parámetros Enterprise.
  2. De la página del parámetro Enterprise, marque el LDAP: Cisco Base y LDAP: Parámetros de las Bases del usuario. (LDAP: El Cisco Base debe ser o=cisco.com y LDAP: Las Bases del usuario deben ser ou=Users, o=cisco.com.)
Después de poner al día estos parámetros, todos los usuarios podían iniciar sesión de las páginas del usuario. El problema fue encontrado en el Cisco CallManager 3.0.4 donde estaban NULOS los parámetros antedichos.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 13968