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

Guía para Troubleshooting de Cisco IP Telephony para el Cisco CallManager Release 3.0(x)

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


Contenido


Introducción

Esta guía de Troubleshooting describe las Herramientas y utilidad usadas para configurar, para monitorear, y para resolver problemas los gatewayes de la versión del CallManager de Cisco 3.0(1), de Cisco IOS� y al portero. Este documento proporciona ejemplos detallados de tres flujos de llamada diferentes, así como casos prácticos para explicar mejor los conceptos.

En el primer caso práctico, un Cisco IP Phone llama otro Cisco IP Phone dentro de un cluster (llamada dentro del clúster). En el segundo caso práctico, un Cisco IP Phone llama con un Cisco IOS Gateway a un teléfono conectado con un PBX local o en el Public Switched Telephone Network (PSTN). En el tercer caso práctico, un Cisco IP Phone llama otro Cisco IP Phone en un clúster diferente (llamada entre clústerss).

Una vez que usted entiende el flujo de llamada y hace el debug de las trazas, será más fácil aislar un problema y determinar qué componente está causando el problema. Este documento describe las herramientas disponibles para resolver problemas los problemas potenciales. También describe cómo los Seguimientos de llamada y las salidas de los debugs pueden ayudarle a entender los flujos de llamada y la serie de eventos.

En caso que usted deba entrar en contacto el Centro de Asistencia Técnica de Cisco (TAC), muchas de las herramientas explicadas aquí serán instrumentales en recopilar los datos requeridos por TAC. La solución de problemas será más rápida si usted ha recopilado ya estos datos antes de llamar TAC.

prerrequisitos

Requisitos

Utilice la lista de verificación siguiente para estar seguro que usted tiene la documentación apropiada en su topología de red.

  • Topología que muestra todos los dispositivos de red y componentes críticos con el puerto/los Números de interfaz a los cuales se asocian y a qué VLA N pertenecen (si procede). Las designaciones especiales se deben utilizar para los puertos que están en el enlace o el modo de canalización.

  • La raíz del atravesar-árbol debe ser configurada y todos los puertos de normal-bloqueo deben ser identificados.

  • Cualquier circuito PÁLIDO se debe identificar con la cantidad del ancho de banda (CIR en el caso del Frame Relay).

Nota: El Cisco IP Phone 7960 tiene un puerto de red 10/100-switched y un puerto de PC de 10/100. Cisco no soporta los teléfonos de “conexión en cascada” apagado del puerto de PC. No recomendamos el asociar de la red y de los puertos PC a un Switch (de tal modo que crea un loop físico en la red).

Cualquier interfaz de WAN requerirá la Consideración especial, puesto que ésta es una fuente potencial de congestión. Los Teléfonos IP y los gatewayes de Cisco fijan el campo de precedencia IP de la secuencia del Real-Time Transport Protocol (RTP) a cinco, no obstante éste marca solamente el paquete RTP con etiqueta. Está hasta el administrador de la red para asegurarse de que la red está configurada para el priorización y el control de admisión de llamadas para poder mantener el tráfico de la voz sobre IP (VoIP) con el retraso mínimo y la contención de los recursos. Para más información sobre este tema, refiérase:

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Nota: Todas las discusiones en este documento se escriben para la versión del CallManager de Cisco 3.0(1), salvo que se indique lo contrario.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Antecedentes

Topología

Usted debe tener una topología de red exacta que contiene los puertos con los cuales los diversos componentes están conectados, por ejemplo los VLA N, Routers, Switches, los gatewayes, y así sucesivamente. Una topología bien documentada ayuda al localizar averías los problemas con el sistema. Esté seguro que usted tiene una topología precisa, junto con el acceso a todos los dispositivos de red y servicios de terminal para la Administración del Cisco CallManager.

La planificación importante se requiere para agregar con éxito la Telefonía IP a un nuevo o a una red existente. Puesto que el tráfico en tiempo real tiene diversos requisitos que el tráfico de datos, la red se debe diseñar con la latencia baja y el Calidad de Servicio (QoS) en la mente. Como con cualquier red que lleve el tráfico crítico, es imprescindible que el administrador de la red mantiene exacto, los diagramas detallados de la topología de red. En una situación de crisis es importante conocer no apenas la descripción general amplia de la red, pero también que los puertos están conectados con los componentes de la red (Routers, Switches, Cisco Callmanager servers, gatewayes, y otros dispositivos críticos). Es importante planear la red con la Redundancia y el scalability en la mente.

precaución Precaución: Cisco no soporta el uso de las hub para conectividades compartida al Switches. El Hubs puede interferir con la operación correcta del sistema de telefonía IP.

Al trabajar con las redes de switch, es crítico que usted conoce el estado del atravesar-árbol (para la Redundancia). El estado de la red debe ser documentado antes de que ocurra cualquier error.

Glosario de términos

Las listas abajo de la tabla algunos términos y acrónimo comunes que se pueden utilizar en este documento.

Glosario
Siglas/término Definición
.cnf Archivo de configuración usado por los dispositivos.
�-ley (“Mu-law”) Técnica de compresión de uso general en Norteamérica. la �-ley se estandardiza como codificador-decodificador 64-kbps en ITU-T G.711.
Ley A Estándar de compresión ITU-T usado en la conversión entre las señales analógicas y digitales en los sistemas del Modulación de código por impulsos (PCM). La ley A se utiliza sobre todo en las redes telefónicas europeas y es similar al estándar norteamericano de la �-ley.
ACF Admission Confirm.
ANI El número que llama.
ARQ Pedido de admisión.
Canal B Canal portador. En el ISDN, esto es un FULL-duplex, el canal 64-kbps usado para enviar los datos del usuario.
Calling Search Space El Calling Search Space define que los números de directorio y los patrones de ruta un dispositivo dado pueden llamar. Es el agrupar de las divisiones a través de las cuales mirar al hacer una llamada. Por ejemplo, asuma que hay varias divisiones en un Calling Search Space que se nombran “ejecutivo.” En este ejemplo, un número telefónico de Cisco IP está en el Calling Search Space “ejecutivo”. Al iniciar una llamada, el número telefónico de Cisco IP busca con el “NYInternationalCall,” “NYLongDistance”, “NYLocalCall,” y las divisiones disponibles del "NY911". Un número telefónico de Cisco IP que tiene un Calling Search Space del “invitado”, por ejemplo, se pudo permitir solamente buscar a través del “NYLocalCall” y de las divisiones del "NY911". Por lo tanto, si el usuario intenta marcar un número internacional, el número no encontrará que una coincidencia y la llamada no serán ruteadas.
CCAPi Control de llamada API. Utilizado por el Cisco IOS para manejar el proceso de llamada VoIP.
CCO Cisco Connection Online (http://www.cisco.com). Proporciona la información más reciente sobre los Productos Cisco, la información de soporte técnico, y la Documentación técnica.
CDR Registro de detalles de la llamada. Provee información sobre el origen de la llamada, el destino, y la duración. Esto se utiliza para crear los registros de facturación.
IOS de Cisco Software del sistema de Cisco que proporciona la funcionalidad habitual, el scalability, y la Seguridad para todos los Productos bajo arquitectura de CiscoFusion. El Cisco IOS permite instalación y administración de conexiones entre redes centralizada, integrada, y automatizada, mientras que asegura el soporte para una amplia variedad de protocolos, los media, los servicios, y las Plataformas.
Cluster Clúster del Cisco CallManager. Un agrupamiento lógico de vario Cisco Callmanager servers.
CMR Call Management Records, también conocido como CDR de diagnóstico. Éstos son los expedientes que contienen la cuenta de los bytes enviados, los paquetes enviados, jitter, tiempo de espera, los paquetes perdidos, y así sucesivamente.
códec Decodificador del codificador. Un algoritmo de software de la parte específica del dominio (DSP) usado para comprimir/descomprime el discurso o las señales de audio.
Canal D Canal de datos. Canal del Full-duplex, 16-kbps (BRI) o 64-kbps (PRI) ISDN. Utilizado para señalar y el control.
DCF El desembarazo confirma.
DHCP Protocolo DHCP. Proporciona un mecanismo para afectar un aparato los IP Addresses dinámicamente para poder reutilizar los direccionamientos cuando los hosts los necesitan no más.
DN Número de directorio. Éste es el número de teléfono de un dispositivo extremo. Puede ser un número asignado a un Cisco IP Phone, a un Cisco IP SoftPhone, a la máquina de fax, o al teléfono analógico asociado a un gateway. Los ejemplos incluyen 1000 y 24231.
DNIS Dialed Number Identification Service.
DNS Sistema de nombres de dominio (DNS). Éste es el sistema usado en Internet para traducir los nombres de los nodos de red en los direccionamientos.
DRQ Pedido de desconexión.
DTMF Tono dual de múltiples frecuencias. Éste es el uso de dos tonos simultáneos de la banda de voz para marcar (tal como de "touch tone").
Flujo Un flujo de datos que viaja entre dos puntos finales a través de una red (a partir de una estación LAN a otra, por ejemplo). Es posible transmitir múltiples flujos en un solo circuito.
Full-duplex La capacidad para la transmisión de datos simultánea de una estación remitente y de una estación receptora.
G.711 Describe la técnica de codificación de voz 64-kbps PCM. En G.711, la voz codificada está ya en el formato correcto para la entrega de voz digital en el PSTN o con los PBX. Esto se describe en el estándar ITU-T en sus recomendaciones Serie G.
G.729 Describe la compresión de predicción lineal activada por código (CELP) donde la Voz se cifra en las secuencias 8-kbps. Hay dos variaciones de este estándar (G.729 y G.729 adjuntan A) que diferencie principalmente en la complejidad informática; ambos proporcionan la calidad vocal similar a la modulación de código de impulso diferencial adaptable 32-kbps (ADPCM). Esto se describe en el estándar ITU-T en sus recomendaciones Serie G.
H.225 Un estándar de ITU que gobierna el establecimiento de sesión H.225 y el packetization. El H.225 describe realmente varios diversos protocolos: RAS, el uso del q.931, y el uso del RTP.
H.245 Un estándar de ITU que gobierna el control de punto final H.245.
H.323 Una extensión del ITU-T H.320 estándar que habilita la Videoconferencia sobre los LAN y otras redes conmutadas por paquetes, así como vídeo sobre Internet.
Half duplex La capacidad para la Transmisión de datos en solamente un en un momento de la dirección entre una estación remitente y una estación receptora. La Comunicación sincrónica binaria (BSC) es un ejemplo de un protocolo semidúplex.
Hookflash Un período corto del en-gancho, generado generalmente por a teléfono-como el dispositivo durante una llamada, para indicar que el teléfono está intentando realizar una confirmación del tono de marcado de un PBX. El hookflash es de uso frecuente realizar la transferencia de llamada.
ICCP Control Protocol del Intra-cluster
ISDN Integrated Services Digital Network. Un Communication Protocol, ofrecido por las compañías telefónicas, que permiten que las redes telefónicas lleven los datos, expresa, y el otro tráfico de origen.
Fluctuación La variación en las horas de llegada de paquetes de voz.
MGCP (Protocolo de control de gateway de medios) Media Gateway Control Protocol. Un protocolo para que Cisco CallManager controle los gatewayes de VoIP (puntos finales del MGCP).
MTP Media Termination Point.
División Una división es un agrupamiento lógico de los números de directorio (DN) y de los patrones de ruta con las características de alcance similares. Para la simplicidad, éstos se nombran generalmente para su característica, tal como “NYLongDistance”, el "NY911", y así sucesivamente. Cuando ponen un DN o a un patrón de ruta en cierta división, éste crea una regla para quién puede llamar esa lista del dispositivo o de la ruta.
PBX Intercambio de central privada. Central telefónica analógica o digital situada en las instalaciones del suscriptor y usada para conectar el soldado y las redes de telefonía públicas.
PRI Interfaz de la velocidad primaria. El acceso de velocidad primaria consiste en un solo 64-Kbps canal D más 23 (T1) o 30 canales B (del e1) para la Voz o los datos.
PSTN Public Switched Telephone Network. Término general que refiere a la variedad de redes telefónicas y de servicios en el lugar por todo el mundo.
Q.931 Estándar de ITU que describe la señalización ISDN. El estándar H.225.0 utiliza una variante del q.931 para establecer y para desconectar las sesiones de H.323.
RAS Protocolo de registración, admisión y estado. Éste es el protocolo usado en el Conjunto de protocolos de H.323 para descubrir y obrar recíprocamente con un portero.
Filtro de la ruta Un filtro de la ruta se puede utilizar no sólo para restringir la marca, pero también para identificar un subconjunto de un patrón comodín (al usar @ al comodín en el plan de marcado de américa del norte). Por ejemplo, podría ser utilizado para bloquear la marca de 900 códigos de área. En la poder también utilícese conjuntamente con las divisiones y el Calling Search Spaces para configurar las reglas complejas. Por ejemplo, asuma que usted tiene tres grupos de usuarios establecidos: Ejecutivo, personal, e invitado. Un filtro de la ruta puede permitir que el Grupo de usuarios ejecutivo marque los números internacionales, el grupo de usuario del personal para marcar los números locales o las llamadas de larga distancia, y al grupo de usuarios invitados para marcar solamente 911, y 800 los números de los números locales.
Grupo de Routes Un Grupo de Routes es una lista de uno o más gatewayes o puertos en los gatewayes que se ven como acceso equivalente. Es análogo a un grupo troncal en terminología de PBX tradicional. Por ejemplo, usted puede tener dos circuitos PRI al mismo portador que se puede utilizar arbitrariamente. Un gateway (o un puerto determinado en un gateway) se puede agregar solamente a un Grupo de Routes.
Lista de la ruta El punto de ruta antes llamado, la lista de la ruta permite que el Cisco CallManager cace a través de una lista de Grupos de Routes en un orden configurado de la preferencia. Las listas de Routes múltiple pueden señalar a los mismos Grupos de Routes.
Patrón de ruta Un número específico o, generalmente, un rango de los Números marcados que serán utilizados para rutear las llamadas a un dispositivo (tal como un gateway del acceso DT-24+ de Cisco o un router que acepta datos de voz) o indirectamente vía una lista de la ruta. Por ejemplo, 1XXX significa 1000 a 1999. El “x” en 1XXX significa un solo dígito; un comodín. Hay otros tales comodines (por ejemplo @. ¡! , y así sucesivamente). Un patrón de ruta no tiene que ser único dentro de una división mientras el filtro de la ruta sea diferente.
RRJ Registration Reject.
RTP Protocolo Real-Time Transport, uno de los protocolos del IPv6. El RTP se diseña para proporcionar los función del transporte de red de extremo a extremo para las aplicaciones que transmiten la información en tiempo real, tal como audio, video, o los datos de simulación, sobre los servicios de red del Multicast o del unicast. El RTP proporciona los servicios tales como identificación de tipo de carga útil, numeración de secuencia, tiempo que sella, y control de entrega a las aplicaciones en tiempo real.
SEP Teléfono de los Ethernetes del Selsius. Estas siglas preceden las direcciones MAC en los Teléfonos IP de Cisco, y representan un identificador de dispositivo único.
Supresión del silencio (detección de la activación por voz) La supresión del silencio permite que un Cisco IP Phone detecte la ausencia de sonido y por lo tanto no transmite los paquetes sobre la red. La calidad de sonido puede ser degradada levemente pero la conexión puede también utilizar menos ancho de banda. La supresión del silencio se inhabilita por abandono.
SNMP Protocolo administración de red simple. El Network Management Protocol se utiliza casi exclusivamente en las redes TCP/IP. SNMP proporciona un medio para monitorear y controlar los dispositivos de red, y para administrar las configuraciones, la recolección de estadísticas, el rendimiento y la seguridad.
SQL Lenguaje de consulta estructurado. Lenguaje de Norma internacional para definir y acceder las bases de datos relacionales.
T1/CAS El T1 es recursos de portadora de WAN digitales, transmitiendo los datos DS-1-formatted en el 1.544 Mbps con el Telephone Switching Network, usando la codificación AMI o B8ZS. CAS es una interfaz de señalización asociada al canal.
T1/PRI El T1 es recursos de portadora de WAN digitales, transmitiendo los datos DS-1-formatted en el 1.544 Mbps con el Telephone Switching Network, usando la codificación AMI o B8ZS. El PRI es interfaz de la velocidad primaria. El acceso de velocidad primaria consiste en un solo 64-Kbps canal D más 23 (T1) o 30 canales B (del e1) para la Voz o los datos.
TCP Protocolo Protocolo de control de transmisión (TCP). Éste es el protocolo de capa del transporte orientado por conexión que proporciona confiable, transmisión de datos de dúplex completo. El TCP es parte de la pila de protocolo TCP/IP.
TFTP Protocolo trivial file transfer. Versión simplificada del FTP que permite que los archivos sean transferidos a partir de un ordenador a otro sobre una red.
Patrón de traducción Utilizado para traducir llamado (DNIS) y llamando los números de la identificación de número automática (ANI) antes de rutear la llamada. Por ejemplo, una llamada puede venir adentro a un conjunto de números (919 392-3XXX) esa necesidad de ser traducido a un conjunto de los Teléfonos IP de Cisco que está en el rango de 2XXX. El Cisco CallManager tiene un patrón de traducción configurado para 919 392-3XXX. Este modelo traduce los 919 392-3 principal simplemente a 2, mientras que deja los dígitos restantes intactos. Entonces la llamada se rutea al Cisco IP Phone apropiado. Los patrones de traducción se utilizan solamente para las traducciones ciertas y no se deben utilizar para la eliminación y prefijación de dígito simple.
UDP Protocolo UDP. Esto es un protocolo de capa de transporte sin conexión en la pila de protocolo TCP/IP. El UDP es un protocolo sencillo que intercambia los datagramas sin los acuses de recibo o la entrega garantizada, requiriendo que el proceso del error y la retransmisión sean manejados por otros protocolos. El UDP se define en el RFC 768.
Detección de la activación por voz (supresión del silencio) La detección de la activación por voz permite que un Cisco IP Phone detecte la ausencia de sonido y por lo tanto no transmite los paquetes sobre la red. La calidad de sonido puede ser degradada levemente pero la conexión puede también utilizar menos ancho de banda. La supresión VAD/Silence se inhabilita por abandono.
VoIP Voz sobre IP.
VLAN LAN virtual. Un grupo de dispositivos en uno o más LAN se configuran que (usando el software de administración) de modo que él pueda comunicar como si lo asociaran al mismo alambre, cuando de hecho él está situado en varios diversos segmentos LAN. Porque los VLA N se basan en lógico en vez de las conexiones físicas, son extremadamente flexibles.

Herramientas y utilidades para supervisar y solucionar problemas en CallManager

Esta sección dirige las Herramientas y utilidad para configurar, para monitorear y para resolver problemas el Cisco CallManager.

Detalles de administración de Cisco CallManager

La administración del CallManager de Cisco proporciona la información de la versión para el sistema, la base de datos, y otros componentes. En la página de la apertura, haga clic en el botón Details Button y anote las versiones funcionando.

ccm_admin.gif

Una más explicación detallada de la administración del CallManager de Cisco está disponible en la documentación en línea del Cisco CallManager.

Rendimiento de Microsoft

El funcionamiento (monitor) es Windows 2000 Server una aplicación que puede visualizar las actividades y el estatus de su Sistema CallManager de Cisco. Señala la información general y específica en el tiempo real. Usted puede utilizar el funcionamiento del Windows 2000 para recoger y exhibir sistema y las estadísticas de dispositivo para cualquier instalación del Cisco CallManager. Estas herramientas administrativas permiten que usted gane una comprensión plena de un sistema sin estudiar la operación de cada uno de sus componentes.

Usted puede utilizar el funcionamiento para monitorear una variedad de Variables del sistema en el tiempo real. Después de agregar los parámetros del Cisco CallManager, usted puede definir los términos bajo los cuales el Cisco CallManager visualizará las estadísticas generadas por el sistema. Por ejemplo, usted puede monitorear el número de llamadas en curso en cualquier momento, o el número de llamadas que pasan actualmente a través de un gateway específico. El funcionamiento muestra el general y Cisco información de estatus Específica de CallManager en el tiempo real.

/image/gif/paws/30266/ms_perf.gif

Rendimiento de Microsoft de apertura

Para abrir el funcionamiento en el Cisco CallManager corriente del servidor PC, Start (Inicio) > Settings (Configuración) > Control Panel (Panel de control) > Administrative Tools (Herramientas administrativas) > Performance (Rendimiento) del tecleo.

Personalizar el funcionamiento

El monitor de rendimiento se debe personalizar para ver los parámetros CallManager-relacionados de Cisco que usted desea monitorear. Elija el objeto, contador, y cítele como ejemplo quieren incluir. Refiera a configurar la utilidad remota para el Cisco CallManager, 3.0 de la versión para las instrucciones en cómo utilizar los objetos y los contadores para personalizar el rendimiento de Microsoft para las operaciones del Cisco CallManager.

Microsoft Event Viewer

Microsoft Event Viewer es una aplicación del servidor del Windows NT que sistema de visualizaciones, Seguridad, y los eventos de aplicación (Cisco CallManager incluyendo) para el servidor del Windows NT. Si un servicio (TFTP incluyendo) no puede leer la base de datos (donde consigue la configuración de la traza), agregará los errores al visor de eventos. El visor de eventos es el único lugar en donde aparecerán estos tipos de errores. El ejemplo siguiente muestra los log de aplicaciones que se ejecutan en un servidor del Windows NT.

ms_event_viewer.gif

Visor de eventos de apertura

Para abrir el evento abra una sesión el Cisco CallManager corriente del servidor PC, Start (Inicio)> Settings (Configuración) > Control panel (Panel de control) del tecleo > Administrative Tools > Event Viewer. El visor de eventos proporciona los registros de error para el sistema, la Seguridad, y las aplicaciones. Los errores del Cisco CallManager se registran bajo log de aplicaciones.

Información detallada sobre los eventos

Usted puede hacer doble clic un evento en el registro para aprender más información sobre el evento.

/image/gif/paws/30266/event_prop.gif

Rastro de SDI

Las trazas del SDI son archivos del registro local. La dirección IP, la manija TCP, el Nombre del dispositivo, o el sello de fecha/hora pueden ser utilizados al revisar la traza del SDI para monitorear el acontecimiento o la disposición de una petición. Este Nombre del dispositivo se podría seguir de nuevo al edificio del archivo, que muestra la agrupación de dispositivos y el modelo. La agrupación de dispositivos y el modelo pueden ser seguidos de nuevo al edificio del prototipo del archivo de configuración, que enumerará a la dirección de red del Cisco CallManager y del puerto de la conexión TCP.

Al observar las trazas del SDI, note que los nombres de la clase y de la rutina del C++ están incluidos con la mayoría de las líneas de seguimiento. La mayoría de las rutinas asociadas a la porción de una petición determinada incluyen el hilo ID en un formato estándar.

Las trazas del SDI serán explicadas detalladamente en los casos prácticos.

Resultado de la traza del SDI

Las trazas del SDI generan los archivos (por ejemplo, CCM000000000) las trazas de ese almacén de las actividades del Cisco CallManager. Estas trazas proporcionan la información sobre el proceso de inicialización del Cisco CallManager, el proceso de inscripción, el proceso de keepalive, el flujo de llamada, la análisis de dígitos, y los dispositivos relacionados tales como Teléfonos IP, gatewayes, porteros, y más de Cisco. Esta información puede ayudarle a aislar los problemas al localizar averías el Cisco CallManager. Para seguir correctamente la información que usted necesita y solamente la información usted necesita, él es importante entender cómo fijar las opciones en la interfaz de la configuración de la traza.

Los archivos de traza se salvan en la ubicación predeterminada siguiente: C:\Program Files\cisco\bin. Se enciende un nuevo archivo de traza cada vez que el Cisco CallManager recomienza, o cuando se ha alcanzado la cantidad de líneas señalada.

Lo que sigue es un ejemplo de la interfaz de la configuración de la traza de la administración del CallManager de Cisco. Usted debe habilitar la traza, elegir el nivel en la información necesaria, y marcar la máscara del usuario para obtener el nivel deseado de información.

/image/gif/paws/30266/trace_config.gif

Si la traza no se configura correctamente, generará una gran cantidad de información que la hace muy difícil aislar los problemas. La sección siguiente explica cómo configurar correctamente una traza útil.

Configurar las trazas

Las trazas se componen de los indicadores de la máscara del usuario (también conocidos como bits) y de los niveles de traza. Abra a la administración del CallManager de Cisco. Para dar vuelta encendido a localizar, fije sus parámetros de la traza (servicio configurado incluyendo, los bits, y así sucesivamente) en la pantalla del servicio > de la traza. Refiera a la guía de la administración del CallManager de Cisco, libere 3.0(1) para toda la información sobre el torneado de localizar por intervalos, y para las descripciones de las máscaras del usuario y los niveles para cada servicio configurado, y más.

Los siguientes son dos ejemplos de los Mask Bit de la traza que serían habilitados sobre la base del problema determinado.

  • Para el debugging del mensaje normal, gire los bits 5, 6, 7, 8, 11, y 12 del subsistema

  • Para hacer el debug de los gatewayes, gire los bits 3, 4, 5, 6, 7, 8, 9, 11, 12, y 13 del subsistema

Los siguientes son dos ejemplos de los niveles de traza deseados basados en el problema determinado

  • Para el debugging normal, el nivel de traza se debe fijar a SDI_LEVEL_ARBITRARY

  • Para el sistema de ejecución normal, el nivel de traza se debe fijar a SDI_LEVEL_ERROR

Rastro de SDL

Trazas del uso SDL de los ingenieros de Cisco para encontrar la causa de un error. Le no se espera que entienda completamente la información contenida en una traza SDL. Sin embargo, mientras que trabaja con TAC, usted puede ser pedido habilitar la traza SDL y proporcionarla a TAC. Los archivos de traza SDL se pueden guardar a los directorios locales, al visor de eventos del Windows NT, y al CiscoWorks 2000. Para evitar cualquier degradación del rendimiento en el servidor, esté seguro que usted apaga el seguimiento de SDL después de que se haya capturado la traza.

La traza SDL proporciona la interfaz A.C. para localizar y las alarmas. Las alarmas se utilizan para informar al administrador de eventos inesperados, tal como no poder acceder un archivo, una base de datos, un Winsock, o no poder afectar un aparato otros recursos del sistema operativo.

Habilitar la traza SDL

Las trazas SDL se habilitan en Service (Servicio) > Service Parameter area (Área de parámetro de servicio) adentro la administración del CallManager de Cisco. Recuerde que estas trazas deben ser giradas solamente cuando son pedido por un ingeniero de TAC. Observe los valores elegidos para girar la traza SDL en el ejemplo siguiente.

/image/gif/paws/30266/serv_param_config.gif

Una vez que se habilitan las trazas SDL, recoja las trazas. Si las trazas se están enviando a la unidad local, después usted puede extraerlas en el sub-directório de Cisco \ de la traza. Alternativamente, los archivos de traza se pueden enviar a un registro de acontecimientos o al CiscoWorks 2000.

Los bits del indicador SDL descritos en la tabla siguiente se fijan en el área del Service (Servicio) > Service Parameters (Parámetros de servicio) en la administración del CallManager de Cisco. Los siguientes son dos ejemplos de los valores deseados basados en el problema determinado.

  • El valor recomendado para el debugging de la llamada normal es SdlTraceTypeFlags=0x00000b04

  • El valor recomendado para el debugging bajo o los gatewayes del debugging es SdlTraceTypeFlags=0x00004b05

Definiciones de SdlTraceTypeFlags
SDLTraceTypeFlag Valor Definición
traceLayer1 = 0x00000001 Toda la traza del Layer 1 encendido
TraceDetailLayer1 = 0x00000002 Traza del Layer 1 del detalle encendido
TraceSdlLinkAdmin = 0x00000004 Links del CallManager de inter-Cisco de la traza dentro de un cluster
traceUnused = 0x00000008 No usado
traceLayer2 = 0x00000010 Todos acodan la traza 2 encendido
traceLayer2Interface = 0x00000020 Traza del interfaz de capa 2 encendido
traceLayer2TCP = 0x00000040 Traza de la capa 2 TCP encendido
TraceDetailLayer2 = 0x00000080 Más volcado del detalle de los bastidores de la capa 2.
traceLayer3 = 0x00000100 Todos acodan la traza 3 encendido
traceCc = 0x00000200 Toda la traza del Control de llamadas encendido
traceMiscPolls = 0x00000400 Encuestas diversas de la traza
traceMisc = 0x00000800 Traza diversa en (señales de la base de datos)
traceMsgtrans = 0x00001000 La Traducción de mensaje señala (TranslateIsdnToSdlReq, TranslateIsdnToSdlRes TranslateSdlToIsdnReq, TranslateSdlToIsdnRes)
traceUuie = 0x00002000 Traza de la salida UUIE encendido
traceGateway = 0x00004000 Señales de gateway

Los bits de datos descritos en la tabla siguiente se fijan en el área del Service (Servicio) > Service Parameters (Parámetros de servicio) en la administración del CallManager de Cisco. Los siguientes son dos ejemplos de los valores deseados basados en el problema determinado.

  • El valor recomendado para el debugging normal del sistema es SdlTraceDataFlags=0x110

  • El valor recomendado al seguir los problemas con los links SDL es 0x13D (traza NON-condensada; si se desea una traza compacta, 0x200 mordido debe ser fijado. Puede ser fijado conjuntamente con cualquier otro bits)

Definiciones de SDLTraceDataFlags
SDLTraceDataFlag Valor Definición
TraceSdlLinkState = 0x001 Traza del permiso de la inicialización del link SDL
TraceSdlLowLevel = 0x002 Habilite el seguimiento de los eventos SDL de bajo nivel, fileOpen y los eventos de socket (por ejemplo)
TraceSdlLinkPoll = 0x004 Seguimiento del permiso del mensaje de la encuesta del link SDL
TraceSdlLinkMsg = 0x008 Seguimiento del permiso del mensaje del link SDL
traceRawData = 0x010 Traza sin procesar de los datos de la señal del permiso en todas las señales
TraceSdlTagMap = 0x020 Asignación de la etiqueta del permiso
traceCreate = 0x100 El proceso del permiso crea y para las trazas
TraceNoPrettyPrint = 0x200 Impresión buena de la neutralización de archivos de traza

Advertencia del espacio en disco

advertencia Advertencia: Aconséjese que la información obtenida de esta interfaz podría ser muy detallada, y por lo tanto consuma una gran cantidad de espacio en disco. Por este motivo, le aconsejamos girar el archivo de traza por una determinada cantidad de hora, revisar la información, y apagar la traza.

‘Rastro del sabueso

Un sniffer es una aplicación de software que monitorea el tráfico IP en una red y proporciona la información bajo la forma de traza. Las trazas de sniffer proporcionan la información sobre la cantidad y el tipo de tráfico de red en su red. El TCP/IP o los paquetes UDP es protocolos utilizados por el Cisco CallManager y por los dispositivos de punto final, tales como teléfonos y gatewayes. Las trazas de sniffer pueden también ayudarle a identificar los niveles elevados de tráfico de broadcast que podrían dar lugar a los problemas de audio o a las llamadas interrumpidas de la Voz. Las aplicaciones de sabueso común incluyen a los Network Associate SnifferPro, Internet Advisor de Hewlett Packard, y Acterna Domino. Ofertas del dominó que huelen las soluciones de hardware y software y un analizador de red. Si usted quiere utilizar el dominó, recomendamos el usar del software de análisis para evaluar un archivo sabueso capturado (por ejemplo de la aplicación SnifferPro).

Registros de detalles de llamadas (CDR) y Registros de administración de llamadas (CMR)

El CDR es una opción de la información que registra cada llamada hecha (o intentó) de cualquier Cisco IP Phone. Hay dos clases de CDR: CDR básicos y CDR de diagnóstico (o CMR). Una vez que está habilitado, usted puede abrir CDR o CDR de diagnóstico (CMR) en el administrador de empresa del SQL Server. Los archivos CDR se guardan en las bases de datos SQL que se pueden exportar a casi cualquier aplicación, incluyendo Microsoft Access o Excel.

Los registros CDR contienen la información necesaria para generar los registros de facturación. En un entorno distribuido, todos los datos CDR se recogen en una ubicación central, o un conjunto de las ubicaciones. El error de un nodo del Cisco CallManager no hace los datos CDR asociados a ese nodo inasequibles. Los datos se salvan no más en el disco del Cisco CallManager como archivo plano, pero en lugar de otro se salvan en las bases de datos centrales en las tablas.

Si el Cisco CallManager falla antes de que se escriba cualquier expediente, ningún expediente de la llamada existirá. Esto significa que no se escribirá ningún expediente para las llamadas que son activas en un Cisco CallManager dado cuando fallan antes de que las llamadas terminen.

Refiera a la sección de los registros de detalles de la llamada de este documento para información detallada sobre los CDR y los CMR.

La información proporcionada incluye:

  • Expedientes de la lectura y de la escritura

  • Problemas conocidos

  • Lista de tipos de registro generados

  • Lista de campos contenidos en cada expediente y una descripción de lo que representa ese campo

  • Descripción de los tipos de llamadas registradas, y los campos registrados con cada uno de ellas

  • Lista de códigos de la causa que pueden aparecer en los registros CDR

Habilitando o inhabilitando los CDR

La creación de registro CDR se inhabilita por abandono cuando el sistema está instalado. Si usted desea tener datos CDR, usted debe habilitar los CDR en el área del Service (Servicio) > Service Parameters (Parámetros de servicio) de la administración del CallManager de Cisco. El proceso CDR puede ser habilitado y ser inhabilitado en cualquier momento mientras que el sistema es en funcionamiento. Usted no necesita recomenzar el Cisco CallManager para habilitar o inhabilitar de los CDR para tomar el efecto. El sistema responderá a todos los cambios dentro de algunos segundos. El CMR o los datos diagnósticos se habilita por separado de los datos CDR. Los datos CMR no serán generados a menos que se habiliten ambos CDR y diagnósticos de la llamada, pero los datos CDR se pueden generar y registrar sin los datos CMR.

Utilice los pasos siguientes para habilitar los CDR.

  1. Abra a la administración del CallManager de Cisco.

  2. Seleccione Service > Service Parameters.

  3. Seleccione la dirección IP de su instalación del Cisco CallManager.

  4. De la lista de parámetros, seleccione CDREnabled.

  5. Defina el tipo como boleano.

  6. Seleccione T para verdad.

    /image/gif/paws/30266/serv_param_config2.gif

  7. Actualización.

    Resultado: Los registros de detalles de la llamada comenzarán a registrar inmediatamente.

    precaución Precaución: Localizar la conectividad de voz requiere ese registro CDR se habilite en cada instalación del Cisco CallManager en un cluster.

    /image/gif/paws/30266/log_enable.gif

CDR

Los CDR proporcionan la información básica que puede ayudarle a entender la más información detallada contenida en las trazas del SDI. Los CDR básicos proporcionan la información tal como el número que llama, número al que se llamó, originando la dirección IP, IP Address de destino, Duración de la llamada, y así sucesivamente. Los CDR pueden ayudarle a resolver problemas los problemas del teléfono. Por ejemplo, si un usuario señala un problema con una llamada que ocurre en un tiempo específico, usted puede consultar los CDR que ocurrieron alrededor del tiempo indicado para aprender la información adicional sobre esa llamada y otras. Los CDR son de uso general para cargar en cuenta.

CDR de diagnóstico (también conocidos como CMR)

Los CDR de diagnóstico proporcionan la información de la llamada detallada tal como el número de paquetes enviados, recibidos, y perdidos, y la cantidad de jitter y de tiempo de espera. Este nivel de detalle puede proporcionar las explicaciones para algunos problemas, tales como audio unidireccional. Por ejemplo, se indica un problema del audio unidireccional si los tamaños de paquetes de 10,000 se envían, pero los tamaños recibidos son solamente 10.

Resolución de problemas del CallManager con Windows NT e Internet Information Server (IIS)

Esta sección dirige algunas categorías del problema común que puedan ocurrir con el Cisco CallManager y los dispositivos relacionados. Cada categoría de problema sugiere las herramientas de Troubleshooting que usted debe utilizar para ayudar para aislar el problema. Este documento proporciona las categorías generales de problemas potenciales y de sugerencias en cómo resolver problemas esos problemas. No proporciona una lista exhaustiva de problemas y de resoluciones. Si usted encuentra un problema que no se pueda resolver usando las Herramientas y utilidad descritas en este documento, consulte el Centro de Asistencia Técnica de Cisco (TAC) para la ayuda. Sea seguro tener los detalles de administración del CallManager de Cisco disponibles, más la cualquier información de diagnóstico (tal como trazas) que usted ha recolectado hasta la punta de llamar TAC.

Calidad de la Voz

Los problemas de calidad de voz incluyen el audio perdido o torcido durante las llamadas telefónicas. Los problemas comunes incluyen las roturas en el sonido que hacen el audio ser intermitente (como las palabras quebradas), o la presencia de ruidos impares que tuerzan el audio (generación de eco) o los efectos que hacen las palabras habladas sonar acuosas o robóticas. El audio unidireccional, es decir, una conversación entre dos personas donde solamente una persona puede oír cualquier cosa, no es realmente un problema de calidad de voz. Esto será discutida más adelante en esta sección.

Uno o más de los componentes siguientes pueden causar los problemas de audio:

  • Gateway

  • Teléfono

  • Red

Para resolver problemas correctamente los problemas de calidad de voz, usted debe considerar la infraestructura y todos los dispositivos para los descensos y los retardos.

Audio perdido o torcido

Uno de los problemas más comunes encontrados es una “fractura para arriba” del audio (descrito a menudo como el discurso mutilado o pérdida de sílabas dentro de una palabra o de una frase). Hay dos causas comunes para esto: pérdida del paquete y/o jitter. La pérdida del paquete significa que los Paquetes de audio no llegan su destino porque fueron caídos o llegados demasiado tarde para ser útiles. El jitter es la variación en las horas de llegada de paquetes. En la situación ideal, todos los paquetes de VoIP a partir de un teléfono a otro llegarían exactamente hasta una tasa de 1 cada ms 20. Note que esto no menciona cuánto tiempo toma para que un paquete consiga de la punta A señalar B, simplemente la variación en las horas de llegada.

Hay muchas fuentes de Retraso variable en una red real. Algunos de éstos no pueden ser controlados, y algunos pueden. El Retraso variable no se puede eliminar totalmente en una red de voz empaquetada. Los procesadores de señales digitales (DSPs) en los teléfonos y otros dispositivos Voz-capaces se diseñan para mitigar algo del audio, antes del Retraso variable. Esto “dejittering” se hace solamente cuando el Paquete de audio ha alcanzado su destino y está listo para ser puesto en una secuencia de audio convencional (es decir, jugado en el oído del usuario, enviado al PSTN vía una secuencia digital PCM). El Cisco IP Phone 7960 puede mitigar tanto como el segundo de los ejemplos de voz. El buffer del jitter es adaptante, significando si una explosión de los paquetes se recibe, el Cisco IP Phone 7960 sabe realizarlos en un intento por controlar el jitter. El administrador de la red necesita minimizar la variación entre los tiempos de la llegada de paquete aplicando el Calidad de Servicio (QoS) y otras medidas por adelantado (especialmente si las llamadas cruzan una red de área ancha).

Cuando está hecho frente con un problema de audio perdido o torcido, usted debe primero intentar aislar la trayectoria del audio. Intente identificar cada dispositivo de red (Switches y Routers) en la trayectoria de la secuencia de audio de la llamada. Tenga presente que el audio puede ser entre dos teléfonos, entre un teléfono y un gateway, o podría tener varios tramos (de un teléfono a un dispositivo de transcodificación y de allí a otro teléfono). Intente identificar si el problema ocurre solamente entre dos sitios, solamente a través de cierto gateway, en cierta subred, y así sucesivamente. El ayudará a estrecharse abajo que los dispositivos usted necesitan examinar más cuidadosamente. Después, es a menudo el mejor inhabilitar la supresión del silencio (también conocida como la detección de la activación por voz o VAD) si esto no se ha hecho ya. Este mecanismo salva el ancho de banda no transmitiendo el audio cuando hay silencio, pero puede causar el recortes notable (e inaceptable) al principio de las palabras. Usted puede inhabilitar esto en la administración del CallManager de Cisco, bajo el Service (Servicio) > Service Parameters (Parámetros de servicio). De, selecciona el servidor y el servicio CallManager de Cisco. Fije SilenceSuppressionSystemWide a “F” (alternativamente usted puede fijar SilenceSuppressionWithGateways a “F”, pero ésta no se aplica a Gateways H.323 o a los gatewayes MGCP). En caso de duda, apague ambos seleccionando el valor F para cada uno.

/image/gif/paws/30266/serv_param.gif

Si un analizador de red está disponible, una llamada monitoreada entre dos teléfonos debe tener 50 paquetes por segundo (o 1 paquete cada ms 20) cuando se inhabilita la supresión del silencio. Con la filtración apropiada, debe ser posible identificar si los paquetes se están perdiendo o se están retrasando excesivamente.

Recuerde que el retardo en sí mismo no causará el recortes, sólo el Retraso variable lo va a hacer. En la tabla abajo, que representa una traza perfecta, las horas de llegada entre los Paquetes de audio (que tendrán un encabezado RTP) serán el ms 20. En una llamada de la baja calidad (tal como una llamada con mucho jitter), las horas de llegada variarían grandemente.

Una traza perfecta
Número del paquete Hora: absoluto (ms) Hora: delta (ms)
1 0
2 0.02 20
3 0.04 20
4 0.06 20
5 0.08 20

La colocación del analizador de paquete en las diversas puntas en la red ayudará a estrecharse abajo de donde está viniendo el retardo. Si no hay analizador disponible, otros métodos serán requeridos. Es importante examinar las estadísticas de la interfaz de cada dispositivo en la trayectoria del audio. Otra herramienta para seguir las llamadas con la calidad de voz deficiente es los registros de detalles de la llamada de diagnóstico (CDR). Vea las Herramientas y utilidad seccionar y la sección de los registros de detalles de la llamada para más información sobre los CDR.

Los valores para el jitter y el tiempo de espera se pueden extraer para todas las llamadas (pero solamente después que la llamada ha terminado). Lo que sigue es una muestra CDR de diagnóstico (el CallDetailRecordDiagnostic es el nombre de la tabla real). El número de paquetes enviados, recibido, perdido, jitter, y tiempo de espera todo se registra. El valor del globalCallID se puede utilizar para encontrar la llamada en la tabla regular CDR para poder obtener el Desconectar causa y la otra información. El diagrama a continuación muestra ambas tablas abiertas. Note que en el CDR de diagnóstico, cada dispositivo que puede señalar posiblemente esta información es incluido. Así pues, si el problema está entre dos Teléfonos IP de Cisco, vemos dos entradas de tabla por la llamada. Si tenemos una llamada con un Cisco IOS Gateway, por ejemplo, vemos solamente la información de diagnóstico del Cisco IP Phone, no el gateway porque no hay mecanismo para que notifique las bases de datos SQL con esta información.

ibutton.gif

ayuda de botón I Button

El Cisco IP Phone 7960 proporciona otra herramienta para diagnosticar los problemas de audio posibles. En una llamada activa, usted puede presionar el botón I Button dos veces (rápidamente) y el teléfono visualiza una Pantalla de información que contenga el paquete reciba y transmite las estadísticas, así como los contadores de la media y de la fluctuación máxima. En esta pantalla, no ese jitter es la media de los cinco paquetes más recientes que llegaron; la fluctuación máxima es la marca de alta para la fluctuación promedio.

La mayoría de las fuentes comunes para el retardo y la pérdida del paquete son los dispositivos donde una interfaz más alta de la velocidad alimenta en una interfaz más de poca velocidad. Por ejemplo, un router puede tener una interfaz Fast Ethernet del 100 Mb conectada con el LAN y un Frame Relay lento conectado con WAN. Cuando ocurre la baja calidad solamente al comunicar al sitio remoto (solamente el sitio remoto puede señalar la calidad de voz deficiente mientras que en la otra dirección todo aparece ser fino), abajo están las causas más probables del problema:

  • No han configurado al router correctamente para dar la prioridad del tráfico de voz sobre el tráfico de datos.

  • Hay demasiadas llamadas activas para que WAN soporte (es decir, no hay control de admisión de llamadas para restringir el número de llamadas que se puedan poner).

  • Hay errores del puerto físico.

  • Hay la congestión en WAN sí mismo.

En el LAN, los problemas más comunes son errores del nivel físico (tales como errores CRC) causados por los cables defectuosos y las interfaces, o por los dispositivos incorrecto-configurados (tales como una velocidad de puerto o una discordancia dúplex). Aseegurese que el tráfico no está cruzando ningún dispositivo de los medios compartidos, tal como un concentrador. Podría también haber las situaciones donde el tráfico está tomando una trayectoria más lenta a través de la red que esperada. Si QoS se ha configurado correctamente, es posible que no hay control de admisión de llamadas. Dependiendo de su topología, esto puede ser realizado con el uso de las ubicaciones en configuración de la administración del CallManager de Cisco, o usando un router del Cisco IOS como portero. En todo caso, usted debe saber siempre cuántas llamadas se podrían soportar a través de su WAN. Si es posible, pruebe esto inhabilitando la supresión del silencio según lo descrito anterior, después ponga las llamadas entre los dos sitios. No coloque invita al control o del mudo, puesto que esto parará los paquetes de ser transmitido. Con el número máximo de llamadas a través de WAN, las llamadas si todos tienen calidad aceptable. Pruebe para aseegurarse que un ocupado rápido está vuelto al intentar hacer una más llamada.

Ruidos en la línea

Otro síntoma de la “baja calidad” puede ser un chisporroteo, que es causado a veces por una fuente de alimentación defectuosa o una cierta clase de interferencia eléctrica fuerte cerca del teléfono. Intente intercambiar la fuente de alimentación y mover el teléfono a una ubicación diferente.

Marque sus cargas

Además, usted debe marcar siempre los teléfonos y los gatewayes para asegurar las cargas del último software son funcionando. En caso de duda, control CCO (Cisco Connection Online en www.cisco.com) para las cargas del último software, nuevas correcciones, o Release Note referentes al problema.

Eco

La generación de eco (también conocida como “eco del hablante”) ocurre cuando las energías vocales de un transmisor, transmitidas abajo de la trayectoria de la señal primaria, se juntan en la trayectoria de la recepción del otro extremo. El transmisor entonces oye su propia Voz, retrasada por el tiempo de retardo de trayecto total de la generación de eco.

/image/gif/paws/30266/voice.gif

En el diagrama arriba, la Voz de Juan (en el azul) se está reflejando detrás. Esto puede suceder sino ir inadvertido en una red de voz tradicional porque el retardo es tan bajo. Al usuario, suena más bién un efecto local que una generación de eco. En una red VoIP, será siempre notable, puesto que el packetization y la compresión contribuyen siempre bastante retardo. El asunto importante a recordar es que la causa de la generación de eco está siempre con los componentes analógicos y el cableado. Por ejemplo, los paquetes IP no pueden dar vuelta simplemente alrededor y volver a la fuente en un nivel de audio más bajo. Lo mismo es imposible en los circuitos digitales T1/E1. Tan en una llamada a partir de un Cisco IP Phone a otro, debe nunca haber cualquier problema. La única excepción puede ser si un partido está utilizando un speakerphone que tiene el volumen configurado demasiado arriba o cierta otra situación donde se crea un loop audio.

Al localizar averías los Problemas de eco, aseegurese que los teléfonos se están probando o se están examinando que no están utilizando el speakerphone y que tienen el volumen configurado de las auriculares a los niveles razonables (comienzo con el 50 por ciento del nivel de audio máximo). La mayor parte del tiempo, los problemas ocurrirán al asociar al PSTN por un digital o un gateway analógico. Los usuarios del Cisco IP Phone pueden quejarse de que oyen su propia Voz que es reflejada de nuevo a ellos. Aunque la verdadera fuente del problema esté casi siempre en el otro extremo, es casi siempre imposible cambiar cualquier cosa en el PSTN. Así pues, el primer paso es determinar se está utilizando qué gateway. Si un gateway digital es funcionando, puede ser posible agregar el relleno adicional en la dirección de transmisión (hacia el PSTN) con la esperanza de que la fuerza de la señal inferior rinda menos energías reflejadas. Además, usted puede ajustar el nivel de la recepción de modo que cualquier audio reflejado sea incluso más futuro reducido. Es muy importante recordar hacer el pequeño en un momento de los ajustes. Demasiada atenuación de la señal hará el audio imposible oír en los ambos lados. Alternativamente, usted puede entrar en contacto el portador y la petición para hacer las líneas marcar. En un circuito típico T1/PRI en Norteamérica, la señal de entrada debe estar -15 dB. Si el nivel de la señal es mucho más alto (DB -5, por ejemplo), la generación de eco será el resultado probable.

Guarde un registro de todas las llamadas que experimenten la generación de eco. La época del problema, del número de teléfono de la fuente, y del número llamado si se registran todos. Los gatewayes tienen un rato fijo del ms 16 de la cancelación de eco. Si el retardo en el audio reflejado es más largo que esto, el canciller de la generación de eco no podrá trabajar correctamente. Esto no debe ser un problema para las Llamadas locales, y las llamadas de larga distancia deben tener los cancilleres del eco externo incorporados a la red en la oficina central. Éste es una de las razones por las que es importante observar el número de teléfono externo de una llamada que experimente la generación de eco.

Marque sus cargas

Las cargas del gateway y del teléfono deben ser verificadas. Marque CCO (Cisco Connection Online en www.cisco.com) para las cargas del último software, las nuevas correcciones, o los Release Note referente al problema.

Audio unidireccional o no audio

El audio unidireccional ocurre cuando una persona no puede oír a otra persona durante una llamada. Esto se puede causar por un Cisco IOS Gateway incorrecto-configurado, un Firewall, o una encaminamiento o un problema del default gateway, entre otras cosas.

Hay varias causas para el audio unidireccional o no audio durante una llamada. La mayoría de la causa común es un dispositivo incorrecto-configurado. Por ejemplo, el Cisco CallManager maneja la configuración de la llamada para un Cisco IP Phone. La secuencia de audio real ocurre entre los dos Teléfonos IP de Cisco (o entre el Cisco IP Phone y un gateway). Así pues, es totalmente posible que el Cisco CallManager puede señalar a un teléfono de destino (que le hace el timbre) cuando el teléfono que origina la llamada no tiene una ruta de IP al teléfono de destino. Esto ocurre comúnmente cuando el default gateway en el teléfono se configura incorrectamente (manualmente o en el servidor del Protocolo de configuración dinámica de host (DHCP)).

Si una llamada tiene constantemente audio unidireccional, intente hacer ping el Cisco IP Phone del destino usando un PC que esté en la misma subred como el teléfono y tenga el mismo default gateway. Tome un PC que esté en la misma subred como el teléfono de destino (con el mismo default gateway que el teléfono de destino) y haga ping el teléfono de la fuente. Ambas pruebas deben trabajar. El tráfico de audio se puede también afectar por un Firewall o un filtro de paquete (tal como Listas de acceso en un router) que puedan bloquear el audio en uno o a las ambas direcciones. Si el audio unidireccional ocurre solamente con un Cisco IOS Gateway activado mediante la voz, marque la configuración cuidadosamente. El Routing IP debe ser habilitado (examine la configuración para aseegurarse que no se encuentra ningún Routing IP cerca del principio de la configuración). También, si usted está utilizando la Compresión de cabecera RTP para salvar el ancho de banda a través de WAN, aseegurese que está habilitado en cada tráfico de voz que lleva del router que asocie al circuito PÁLIDO. No debe haber una situación donde el encabezado RTP se comprime en un extremo pero no se puede descomprimir en el otro lado de WAN. Un sniffer es mismo una herramienta útil al localizar averías los problemas del audio unidireccional porque usted puede verificar que el teléfono o el gateway sea realmente de envío o de recepción de los paquetes. Los CDR de diagnóstico son útiles en determinar si una llamada está experimentando el audio unidireccional porque registran transmitido y los paquetes recibidos (refiera al audio perdido o torcido). Usted puede también presionar el botón I Button dos veces (rápidamente) en un Cisco IP Phone 7960 durante una llamada activa para ver los detalles sobre transmitido y los paquetes recibidos.

Nota: Cuando se silencia una llamada (botón enmudecedor presionado en un teléfono), no se transmitirá ningunos paquetes. El botón Hold Button para la secuencia de audio, así que no se envía ningunos paquetes en cualquier dirección. Cuando se libera el botón Hold Button, se reajustan todos los contadores de paquetes. Recuerde que la supresión del silencio se debe inhabilitar en los dispositivos para que los contadores TX y RX permanezcan igual. Inhabilitar la supresión del silencio sistema-ancha no afectará a los gatewayes del Cisco IOS.

MTP y audio unidireccional

Si usted está utilizando el Media Termination Point (MTP) en una llamada (soportar los servicios suplementarios tales como control y transferencia con los dispositivos de H.323 que no soportan la versión de H.323 2), marque para ver si el MTP afectado un aparato está trabajando correctamente. El Routers del Cisco IOS soporta el principio de la versión 2 de H.323 en la versión 11.3(9)NA y 12.0(3)T. Comenzando con el Cisco IOS Release 12.0(7)T, H.323 opcional abierto/LogicalChannel cercano se soporta, para requerir el MTP basado en software no más para los servicios suplementarios.

El Dispositivo MTP, así como Bridge de conferencia y transcoder, interligará dos o más secuencias de audio. Si el MTP, el Bridge de conferencia, o el transcoder no está trabajando correctamente, el audio unidireccional o la pérdida de audio pudo ser experimentado. Apague el MTP para descubrir si el MTP está causando el problema.

Restauraciones de teléfono

Ciclo o restauración de la fuerza de voluntad de los teléfonos para una de las dos razones siguientes:

  • Error TCP que conecta con el Cisco CallManager, o

  • Error recibir un acuse de recibo a los mensajes de keepalive del teléfono.

Abajo están los pasos para localización de averías de las restauraciones del teléfono:

  1. Marque los teléfonos y los gatewayes para asegurarse de que usted está utilizando las cargas del último software.

  2. Marque CCO (Cisco Connection Online en www.cisco.com) para las cargas del último software, las nuevas correcciones, o los Release Note referente al problema.

  3. Marque el visor de eventos para los casos del reajuste de los teléfonos. Las restauraciones del teléfono se consideran los eventos de Información, tal y como se muestra en del ejemplo siguiente.

    /image/gif/paws/30266/event_prop.gif

  4. Busque éstos y cualquier error que pudieron haber ocurrido alrededor del tiempo ese la restauración de los teléfonos.

  5. Comience una traza del SDI e intente aislar el problema identificando cualquier característica común en los teléfonos que están reajustando. Por ejemplo, marque si todos están situados en la misma subred, el mismo VLA N, y así sucesivamente. Mire la traza y determinela si:

    • las restauraciones ocurren durante una llamada o suceden intermitentemente, o

    • hay cualquier semejanza del modelo del teléfono: Cisco IP Phone 7960, Cisco IP Phone 30VIP, y así sucesivamente.

  6. Comience una traza de sniffer en un teléfono que reajuste con frecuencia. Después de que haya reajustado, mire la traza para determinar si hay alguna ocurrencia de las recomprobaciones TCP. Si es así esto indica un problema de red. La traza puede mostrar algunos estados coherentes en las restauraciones, tales como el teléfono que reajusta cada siete días. Esto pudo indicar una expiración del arriendo del DHCP cada siete días (este valor es utilizador configurable y podría ser cada dos minutos, y así sucesivamente).

Llamadas interrumpidas

Las llamadas interrumpidas ocurren cuando una llamada se termina prematuramente. Usted puede utilizar los CDR para determinar la posible causa de las llamadas interrumpidas, determinado si el problema es intermitente. Las llamadas interrumpidas pueden ser el resultado de un teléfono o reconfiguración de la gateway (véase la sección antedicha) o de un problema del circuito, tal como configuración PRI incorrecta o error.

El primer paso es determinar si este problema se aísla a un teléfono o a un grupo de teléfonos. Quizás los teléfonos afectados son todos en una subred determinada o una ubicación. El siguiente paso es marcar el visor de eventos para las restauraciones del teléfono o del gateway.

/image/gif/paws/30266/drop_call.gif

Debe haber una advertencia y un mensaje de error para cada teléfono que reajuste. En este caso, el problema es a menudo que el teléfono no puede mantener su conexión TCP al Cisco CallManager viva, el Cisco CallManager reajusta tan la conexión. Esto puede ser porque un teléfono fue apagado o puede haber un problema en la red. Si esto es un problema intermitente, puede ser útil utilizar el rendimiento de Microsoft para registrar los registros de teléfono.

/image/gif/paws/30266/drop_call2.gif

Si el problema parece ocurrir solamente a través de cierto gateway, tal como un acceso DT-24+ de Cisco, la mejor línea de acción es habilitar el seguimiento y/o ver los CDR. Los archivos CDR darán una causa de la terminación (COT) que pueda ayudar a determinar la causa del problema.

drop_call3.gif

Los valores del Desconectar causa (el origCause_value y el destCause_value, dependiendo de los cuales lado colgado encima de la llamada), asocian al q.931 los códigos de la causa de desconexión (en el decimal) que se pueden encontrar en los tipos del switch de ISDN, los códigos, y los valores. En el ejemplo anterior, la causa 16 refiere a una Verificación normal de llamadas. Si la llamada está saliendo un gateway al PSTN, el CDR se puede utilizar para determinar que el lado está colgando encima de la llamada. Mucha de la misma información puede ser obtenida habilitando el seguimiento en el Cisco CallManager. Utilice la herramienta de la traza solamente como último recurso o si la red no está todavía en la producción.

Marque sus cargas

Como con cualquier problema, marque las cargas y CCO (Cisco Connection Online del teléfono y del gateway en www.cisco.com) para las cargas del último software, las nuevas correcciones, o los Release Note referente al problema.

Problemas de Funciones del Cisco CallManager

Los problemas pueden ocurrir con las características, tales como Bridge de conferencia o Media Termination Point, que se utilizan conjuntamente con el Cisco CallManager. Algunos de estos problemas de la característica son causados por los Errores de configuración o una falta de recursos. Por ejemplo, los usuarios pueden no poder a las llamadas en conferencia si el número especificado de recursos del conferencia Ad-Hoc se ha excedido. El resultado sería una llamada interrumpida cuando el usuario intentó iniciar la característica de la conferencia. Éste podría aparecer ser un problema de la función de Cisco CallManager, cuando de hecho es un problema con el número de recursos de conferencia disponibles. La cantidad de veces los recursos de conferencia fue requerida, pero no disponible, está uno del rendimiento de Microsoft abierto una sesión los contadores. El mismo comportamiento ocurre si hay recursos de conferencia disponibles, pero el Servicio de conferencia había parado.

Codificador-decodificador/regiones: Discrepancia de cÓdec

Si un usuario consigue un Tono de reordenamiento al ir descolgado, podría ser el resultado del desacuerdo del codificador-decodificador entre las regiones. Verifique que ambos extremos de la llamada soporten por lo menos un códec común (por ejemplo, G.711). Si no, usted necesitará utilizar el transcoders.

Una región especifica el rango del codecs soportado que se puede utilizar con cada uno de las otras regiones. Cada dispositivo pertenece a una región.

Nota:  La negociación de códec con un router del Cisco IOS no se soporta.

Region1<->Region2 = G.711 significa que una llamada entre un dispositivo en Region1 y un dispositivo en Region2 puede utilizar G.711 o cualquier otro codificador-decodificador soportado que requiera el ancho de banda igual o inferior como G.711 (cualquier codecs soportado dentro de G.711, de G.729, de G.723, y así sucesivamente).

Nota:  El codecs siguiente se soporta para cada dispositivo:

  • Cisco IP Phone 7960 G.711A-law/�-law, G.729AnnexB

  • SP12 Series y VIP30 G.711A-law/�-law del Cisco IP Phone, G.723.1

  • Gateway de acceso DE30 y DT-24+ G.711A-law/�-law de Cisco, G.723.1

Ubicaciones

Si un usuario recibe un Tono de reordenamiento después de marcar un número, podría ser porque la asignación de ancho de banda del Cisco CallManager para la ubicación de uno de los dispositivos extremos de la llamada se ha excedido (menos que 24k). El Cisco CallManager marca para saber si hay el ancho de banda disponible 24k para cada dispositivo antes de hacer una llamada. Si menos que el ancho de banda 24k está disponible, el Cisco CallManager no pondrá la llamada y el usuario oirá un Tono de reordenamiento.

12:42:09.017 Cisco CallManager|Locations: Orig=1 BW=12 Dest=0 BW=-1 
(-1 implies infinite bw available)

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallState tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallInfo CallingPartyName=, CallingParty=5003, CalledPartyName=,
 CalledParty=5005, tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputStartTone: 37=ReorderTone tcpHandle=0x4f1ad98 

La llamada se establece una vez, el Cisco CallManager resta el ancho de banda de las ubicaciones dependiendo del codificador-decodificador usado en esa llamada. Si la llamada está utilizando G.711, el Cisco CallManager resta 80k; si la llamada está utilizando G.723, el Cisco CallManager resta 24k; si la llamada está utilizando el G729, el Cisco CallManager resta 24k.

Bridge de conferencia

Utilice la siguiente información para ayudar a no localizar averías un “ningún problema disponible del Bridge de conferencia”. Esto podía ser un software o un problema de hardware.

Primero, control para ver si usted tiene cualesquiera recursos disponibles del Bridge de conferencia registradoes con el Cisco CallManager (software o soporte físico). Para hacer así pues, usted puede utilizar el rendimiento de Microsoft para marcar el número de “unicast AvailableConferences.”

La aplicación de flujo continuo de las medias de voz IP de Cisco realiza la función del Bridge de conferencia. Una instalación del software de fluir de las medias de voz IP de Cisco soportará 16 conferencias disponibles del unicast (3 personas/conferencias), tal y como se muestra en de la traza siguiente.

10:59:29.951 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB_kirribilli - Registered - ConfBridges= 16,
 Streams= 48, tcpHandle=4f12738

10:59:29.951 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??%? - DeviceType= 50, ResourcesAvailable= 16, 
deviceTblIndex= 0 

Un puerto E1 (el indicador luminoso LED amarillo de la placa muestra gravedad menor WS-X6608-E1 contiene los puertos del e1 8x) proporciona cinco conferencias disponibles del unicast (tamaños máximos de la conferencia = 6), tal y como se muestra en de la traza siguiente.

11:14:05.390 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB00107B000FB0 - Registered - ConfBridges= 5, Streams= 16, 
tcpHandle=4f19d64

11:14:05.480 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??% - DeviceType= 51, ResourcesAvailable= 5,
 deviceTblIndex= 0 

La traza siguiente del hardware en el port voice 8 T1/E1 del Cisco Catalyst 6000 y el Módulo de servicios indica que el puerto E1 4/1 en el indicador luminoso LED amarillo de la placa muestra gravedad menor se ha registrado como Bridge de conferencia con el Cisco CallManager.

greece-sup (enable) sh port 4/1

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/1 enabled 1 full - Conf Bridge


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/1 disable 00-10-7b-00-0f-b0 10.200.72.31 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/1 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/1 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/1 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/1 disabled disabled

En segundo lugar, marque la cantidad máxima de usuario configurada en la conferencia (ad hoc o Reunión-yo) para determinar si ocurrió el problema porque este número fue excedido.

Problemas de transcodificación

Si usted ha instalado un transcodificador del hardware en el port voice 8 T1/E1 del Cisco Catalyst 6000 y el Módulo de servicios, y no trabaja como se esperaba (significarle no puede hacer las llamadas entre dos usuarios sin los códecs comunes), marque para ver si usted tiene cualesquiera recursos transcodificadores disponibles registradoes con el Cisco CallManager (éste debe ser hardware). Utilice el rendimiento de Microsoft para marcar el número de “MediaTermPointsAvailable” disponible.

Un puerto E1 (el indicador luminoso LED amarillo de la placa muestra gravedad menor WS-X6608-E1 contiene los puertos del e1 8x) proporciona los recursos del Transcoder/MTP para 16 llamadas, tal y como se muestra en de la traza siguiente.

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

La traza siguiente del hardware en el port voice 8 T1/E1 del Cisco Catalyst 6000 y el Módulo de servicios indica que el puerto E1 4/2 en el indicador luminoso LED amarillo de la placa muestra gravedad menor se ha registrado como MTP/transcoder con el Cisco CallManager.

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

Nota: El mismo puerto E1 no se puede configurar para el Bridge de conferencia y el Transcoder/MTP

Para hacer una llamada entre dos dispositivos usando un código del Low Bit Rate (tal como G.729 y G.723) que no soporta el mismo codificador-decodificador, requieren a los recursos transcodificadores. Considere el ejemplo siguiente:

/image/gif/paws/30266/ccm_ill.gif

Asuma que el Cisco CallManager se ha configurado tales que el codificador-decodificador entre Region1 y Region2 es G.729. Los escenarios siguientes son posibles:

  • Si el llamador en el teléfono A inicia una llamada, el Cisco CallManager realiza que es un Cisco IP Phone 7960, que sucede soportar G.729. Después de que se hayan recogido los dígitos, el Cisco CallManager determina que la llamada es destinada para el usuario D que está en la región 2. Puesto que el dispositivo de destino también soporta G.729, se configura la llamada y los flujos del audio directamente entre el teléfono A y el teléfono D.

  • Si un llamador en el teléfono B, que tiene un Cisco IP Phone 12SP+, iniciara una llamada para llamar por teléfono a D, este vez el Cisco CallManager realizaría que el teléfono que origina soporta solamente G.723 o G.711. El Cisco CallManager necesitaría afectar un aparato un recurso de transcodificación de modo que el audio fluyera como G.711 entre el teléfono B y el transcoder, sino como G.729 entre el transcoder y el teléfono D. Si no hay transcoder disponible, el teléfono d del teléfono sonaría, pero tan pronto como la llamada fuera contestada, la llamada desconectaría.

  • Si un usuario en el teléfono B llamara el teléfono F (Cisco IP Phone 12SP+), los dos teléfonos utilizarían realmente G.723, aunque G.729 se configura como el codificador-decodificador para utilizar entre las regiones. Se utiliza G.723 porque ambos puntos finales lo soportan y utiliza menos ancho de banda que G.729.

  • Si se agrega un sistema de correo de voz del Cisco uOne (que soporta solamente G.711) o un router del Cisco IOS configurado para G.711 a la región 1, después un dispositivo de transcodificación se debe utilizar si llama de la región 2. Si ninguno está disponible, después la llamada fallará.

Problemas de los recursos MTP

Un problema de los recursos MTP podría ser el culpable si se establece una llamada y los servicios suplementarios no están disponibles en un dispositivo de H.323 que no soporte el H323v2. Primero, determine si usted tiene cualesquiera recursos MTP disponibles (software o soporte físico) registradoes con el Cisco CallManager. Usted puede hacer tan usando el rendimiento de Microsoft para marcar el número de “MediaTermPointsAvailable.”

Una aplicación de software MTP soporta 24 llamadas (usando el MTP para soportar los servicios suplementarios con los dispositivos de H.323 que no soportan el H.323v2), tal y como se muestra en de la traza siguiente.

10:12:19.161 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP_kirribilli. - Registered - Supports 24 calls

Un puerto E1 (el indicador luminoso LED amarillo de la placa muestra gravedad menor WS-X6608-E1 contiene los puertos del e1 8x) proporciona a los recursos MTP para 16 llamadas, tal y como se muestra en de la traza siguiente.

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

La traza siguiente del hardware, del port voice 8 T1/E1 del Cisco Catalyst 6000 y del Módulo de servicios, indica que el puerto E1 4/2 en el indicador luminoso LED amarillo de la placa muestra gravedad menor se ha registrado como MTP/transcoder con el Cisco CallManager.

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

En segundo lugar, vea si el Media Termination Point requirió el checkbox se selecciona en la pantalla de la configuración de gateway de la administración del CallManager de Cisco.

Tercero, verifique que el Cisco CallManager haya afectado un aparato el número requerido de Dispositivos MTP.

Del archivo del SDI:

15:22:23.848 Cisco CallManager|MediaManager(40) started

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - Transcoder 
  Enabled

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - party1(16777357), 
  party2(16777358), proxies=1, connections=2, current proxies=0

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - proxy 
  connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - allocating 
  MTP(ci=16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - start 2 connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777357) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777358) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource - 
  CI=16777359 count=1

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource 
  - CI=16777359 count=2

Planes de marcado

Un Plan de marcado es una lista de números (y de grupos de números) que dice el Cisco CallManager al cual los dispositivos (teléfonos, gatewayes, y así sucesivamente) para enviar las llamadas cuando se recoge cierta cadena de dígitos. Es similar a una tabla de ruteo estática en un router. Esté por favor seguro que sus conceptos, ruteo de llamadas básico, y hojas de operación (planning) del Plan de marcado se han considerado cuidadosamente y se han configurado correctamente antes de intentar resolver problemas un problema potencial del Plan de marcado. Muy a menudo, el problema miente con las hojas de operación (planning) y la configuración.

Considere las preguntas siguientes al localizar averías los problemas de los Planes de marcado:

  • ¿Cuál es el número de directorio (DN) que origina la llamada?

  • ¿Cuál es el Calling Search Space de este DN?

  • ¿Si procede, cuál es el Calling Search Space del dispositivo (tal como un Cisco IP Phone) con el cual el DN es asociado? Aseegurese que usted identifica el dispositivo correcto; se soportan las apariciones de línea múltiple, y es posible tener un DN en los dispositivos múltiples. Observe el Calling Search Space del dispositivo. Si la llamada es originada por un Cisco IP Phone, recuerde que la línea determinada (DN) y el dispositivo al cual esa línea es voluntad asociada cada uno tiene Calling Search Spaces. Serán combinados al hacer una llamada. Como un ejemplo, asuma que la línea caso 1000 tiene un Calling Search Space del AccessLevelX y el Cisco IP Phone que tiene extensión 1000 configurada en él tiene AccessLevelY como su Calling Search Space. Por lo tanto, al hacer una llamada de esa aparición de línea, el Cisco CallManager buscará a través de las divisiones contenidas en el AccessLevelX y el AccessLevelY del Calling Search Space.

  • ¿Qué divisiones se asocian al Calling Search Space?

  • ¿Cuál es la división del dispositivo al cual la llamada debe (o no deba) ir?

  • ¿Cuál es el número se está marcando que? Observe si y cuando los llamadores están consiguiendo un tono de marcación secundario, en cualquier etapa. ¿También, qué los llamantes oyen después de que todos los dígitos haber sido ingresados (reordene, rápido ocupado)? ¿Consiguen los tonos de progreso antes de que esperen oír cualquier cosa? Aseegure los llamantes la espera por lo menos 10 segundos después de ingresar el último pasado, puesto que pueden tener que esperar el temporizador del inter dígito para expirar.

  • Genere un informe de la ruta Plan en la administración del CallManager de Cisco. Utilícelo para examinar a todos los patrones de ruta para las divisiones que están en el Calling Search Space para la llamada.

  • En caso necesario, agregue o modifique los patrones de ruta o los filtros de la ruta.

  • Si usted puede encontrar al patrón de ruta a quien se está enviando la llamada, observe la lista o el gateway de la ruta a los cuales el modelo señala.

  • Para una lista de la ruta, control que los Grupos de Routes son parte de la lista y que son parte de los gatewayes los Grupos de Routes.

  • Verifique que los dispositivos aplicables estén registrados con el Cisco CallManager.

  • Si no hay acceso al Cisco CallManager, consiga la tecnología de la demostración para capturar esta información y para verificarla.

  • Tenga cuidado para @ la muestra. Ésta es una macro que puede ampliarse para incluir muchas diversas cosas. Es de uso frecuente conjuntamente con la opción de filtro.

  • Si un dispositivo no es parte de a la división, reputa la parte de la falta de información o la partición predeterminada. Cada usuario debe poder llamar ese dispositivo. La división nula es siempre último buscado.

  • Si usted marca un número exterior que esté correspondiendo con un modelo 9.@ y toma 10 segundos antes de que va la llamada a través, marque la opción de filtro. Un modelo 9.@, al marcar un número de 7 dígitos, (por abandono) esperará 10 segundos. Usted necesita aplicar un filtro de la ruta al modelo que dice LOCAL-AREA-CODE DOES-NOT-EXIST y END-OF-DIALING DOES-NOT-EXIST.

Divisiones

Las divisiones de la ruta heredan las capacidades del manejo de error del software CallManager de Cisco. Es decir, traza una consola y de un archivo del SDI se proporcionan para la información de ingreso al sistema y los mensajes de error. Estos mensajes serán parte del componente de la análisis de dígitos de las trazas. Incluso con las trazas abajo, una comprensión de las configuraciones de las divisiones y del Calling Search Spaces y que los dispositivos está en cada división, junto con su Calling Search Space asociado, es vital en determinar el problema.

La traza abajo es un ejemplo de un número marcado que esté en el Calling Search Space del dispositivo. Para más explicaciones detalladas sobre las trazas del SDI, revise por favor los casos prácticos en este documento.

08:38:54.968 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:54.968 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028|

  08:38:54.968 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

En el componente de la análisis de dígitos de la traza (arriba), los “pss” (espacio de búsqueda de la división, también conocido como Calling Search Space) son mencionados para el dispositivo que pone la llamada. Abajo, usted puede ver eso “RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP” es las divisiones que este dispositivo se permite llamar.

08:38:54.968 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:54.968 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 5 tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5")

  08:38:55.671 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.015 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.015 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="50")

  08:38:56.015 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.187 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.187 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="500")

  08:38:56.187 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.515 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 3 tcpHandle=0x6b88028

  08:38:56.515 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5003")

  08:38:56.515 Cisco CallManager|Digit analysis: analysis results

  08:38:56.515 Cisco CallManager||PretransformCallingPartyNumber=5000

Del ejemplo anterior, es dominante que usted nota que “PotentialMatchesExist” es el resultado de una análisis de dígitos de los números que fueron marcados hasta que el exacto - se encuentra la coincidencia y la llamada se rutea por consiguiente.

Abajo está una traza donde no está el número que fue intentado para ser marcado (1001) en el Calling Search Space del dispositivo. Una vez más es dominante que usted observa que la rutina de la análisis de dígitos tenía coincidencias potenciales hasta que solamente el primer dígito fuera marcado. El patrón de ruta asociado al dígito el "1" está en una división que no esté en el Calling Search Space del dispositivo, “RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP”. Por lo tanto el teléfono fue enviado Tono de reordenamiento.

08:38:58.734 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:58.734 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

  08:38:58.734 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:58.734 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 1 tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="1")

  08:38:59.703 Cisco CallManager|Digit analysis: potentialMatches=NoPotentialMatchesExist

  08:38:59.703 Cisco CallManager|StationD - stationOutputStartTone: 37=ReorderTone 
  tcpHandle=0x6b88028

Las divisiones de la ruta trabajan asociando un nombre de la división a cada número de directorio en el sistema. El número de directorio puede ser llamado solamente si el dispositivo de llamada contiene la división dentro de una lista de divisiones a las cuales se permita para poner las llamadas en su espacio de búsqueda de la división. Esto proporciona el control extremadamente potente sobre la encaminamiento.

Cuando se está poniendo una llamada, las tentativas de la análisis de dígitos de resolver el direccionamiento marcado solamente en esas divisiones que el espacio de búsqueda de la división especifica. Cada nombre de la división comprende un subconjunto discreto del espacio de la dirección del marcable global. De cada división mencionada, la análisis de dígitos extrae el modelo que ese mejor hace juego la secuencia de dígitos marcados. Entonces, entre de los modelos que corresponden con, la análisis de dígitos elige la mejor coincidencia. Si dos modelos hacen juego igualmente la secuencia de dígitos marcados, la análisis de dígitos selecciona el modelo asociado a la división enumerada primero en el espacio de búsqueda de la división (para más información, revise la documentación sobre la encaminamiento de la Cercano-coincidencia).

Seguridad

El Cisco CallManager se puede configurar para crear un plan de marcación seguro para los usuarios. Esto se puede hacer con el uso de las divisiones y del Calling Search Spaces, además de una filtración más común basada en las secciones “@” de la macro (que significa el North American Numbering Plan) en un patrón de ruta, tal como el código de área. Las divisiones y el Calling Search Spaces son un parte integrante de Seguridad y son especialmente útiles para los entornos del multi-arrendatario y crear un nivel de usuario individual. La filtración es un subconjunto del concepto del Calling Search Space/de la división que puede agregar el granularity adicional al plan de la Seguridad.

Esto es una extensión a la sección del Plan de marcado, arriba. Aconséjese, él no es recomendable ejecutar una traza del SDI al intentar reparar un problema de filtración. No hay bastante información y el potencial para causar el daño adicional es demasiado grande.

Ejecute una tecnología de la demostración en el Cisco CallManager. La siguiente información aparece en la sección del filtro de la ruta.

Demostración-tecnología
Nombre dialPlanWizardG Cláusula
CiscoDallasInte 1 (INTERNATIONAL-
CiscoRTPTollByP 1 (== 9 AREA-CODE
CiscoRTPLongDis 1 (AREA-CODE EXIS
CiscoDallasToll 1 (== 9 AREA-CODE
CiscoDallas911R 1 (== 911 del SERVICIO
CiscoRTPLocal7D 1 (EL AREA-CODE HACE
CiscoDallasLong 1 (AREA-CODE EXIS
CiscoRTP911RF 1 (== 911 del SERVICIO
CiscoRTPInterna 1 (INTERNATIONAL-
CiscoDallasLoca 1 (LOCAL-AREA-COD

Desafortunadamente, esta visualización es incompleta. , Sin embargo, da un anuncio de todos los filtros de la ruta en el sistema. El comando show no permite que usted considere se asocian qué filtros con los cuales patrón de ruta. Otro método para entender mejor el Plan de marcado es ir a la página del informe de la ruta Plan. Abajo está una opción en el Lado derecho lejano “a ver en el archivo”.

file_dl.gif

La salida será un archivo separado por coma que se puede ver en Microsoft Excel o una aplicación similar:

salida del archivo de la Demostración-tecnología
Pattern/DN División Uso del modelo Nombre del dispositivo Descripción del dispositivo
1000 Dispositivo SEP003094C2635E Telecaster
1010   Dispositivo SEP003094C2635E Telecaster
1111   Dispositivo SEP00308062CDF1 SEP00308062CDF1
1211   Dispositivo SEP00308062CDF1 SEP00308062CDF1
2999   Dispositivo SAA0010EB007FFE SAA0010EB007FFE
4444   Dispositivo SEP003094C26302 Guest
4500   Conferencia  
9.@ CiscoRTPLocalPT Rutear CiscoRTPLocalRL
9.@ CiscoDallasLocalPT Rutear CiscoDallasLocalRL
9.@ CiscoRTPIntlPT Rutear CiscoRTPIntlRL
9.@ CiscoDallasLongDistPT Rutear CiscoDallasLongDistRL
9.@ CiscoRTP911PT Rutear CiscoRTP911RL
9.@ CiscoRTPLongDistPT Rutear CiscoRTPLongDistRL
9.@ CiscoTollByPassToDallasPT Rutear CiscoTollByPassToDallasRL
9.@ CiscoDallasIntlPT Rutear CiscoDallasIntlRL
9.@ CiscoDallas911PT Rutear CiscoDallas911RL
9.@ CiscoTollByPassToRTPPT Rutear CiscoTollByPassToRTPRL

Esto muestra los patrones de ruta y sus divisiones correspondientes. No muestra los filtros de la ruta o el Calling Search Spaces de los números de directorio. Más información está disponible en el informe del plan de la ruta real. Si usted necesita entrar en contacto el TAC de Cisco, usted debe enviar esta página vía el correo electrónico (si el Cisco CallManager es inaccesible).

Abajo está una disposición de los patrones de ruta, de las divisiones, y de la lista de la ruta/del Grupo de Routes/gateway.

route_plan_rpt.gif

Respuesta lenta del servidor

La respuesta lenta del servidor podría resultar si el duplex del Switch no hace juego el duplex del Cisco Callmanager server. Para el rendimiento óptimo, fije el Switch y el servidor hasta el "100/Full." que no recomendamos el usar del “auto” en el Switch o el servidor. Usted debe recomenzar el Cisco Callmanager server para que el cambio tome el efecto.

Reordenar el tono a través de los gateways

Los usuarios que ponían una llamada a través del gateway pudieron conseguir un Tono de reordenamiento si están intentando hacer una llamada restricta o llamar un número se ha bloqueado que. Un Tono de reordenamiento puede ocurrir si el Número marcado es Out Of Service o si el PSTN tiene un problema del equipo o del servicio. Esté seguro que el dispositivo que daba el Tono de reordenamiento se ha registrado. También, marque su configuración de plan de marcado para asegurarse de que la llamada puede ser ruteada con éxito.

Pasos para localización de averías de los Tonos de reordenamiento a través de los gatewayes:

  1. Marque los gatewayes para asegurarse de que usted está utilizando las cargas del último software.

  2. Marque CCO (Cisco Connection Online en www.cisco.com) para las cargas del último software, las nuevas correcciones, o los Release Note referente al problema.

  3. Comience una traza del SDI y reconstruya el problema. Los Tonos de reordenamiento podrían ser el resultado de un problema de configuración con el control de admisión location basado o el control de admisión portero-basado donde el Cisco CallManager pudo limitar el número de llamadas permisibles. En la traza del SDI, localice la llamada para determinar si fue bloqueada intencionalmente por un patrón de ruta o el Calling Search Space, o por cualquier otro valores de configuración.

  4. Los Tonos de reordenamiento pueden también ocurrir al llamar con el PSTN. Marque la traza del SDI para los mensajes de la desconexión del q.931. Si un mensaje de la desconexión del q.931 está presente, significa que el otro partido causó la desconexión y no podemos corregir eso.

Problemas con el registro de la gateway

Uno de la mayoría de los problemas frecuentes encontrados con los gatewayes en un Cisco CallManager es un Problema de inscripción. El registro puede fallar por una variedad de razones.

Esta sección trata de dos similares, pero diferentes, las categorías de gateways. El acceso analógico AS-X, AT-X y acceso digital DT-24+ y DE-30+ pertenece a una categoría. Estos gatewayes son las unidades autónomas que no están conectadas directamente con un procesador de administración de red (NMP). La segunda categoría incluye el acceso analógico WS-X6624 y el acceso digital WS-X6608. Estos gatewayes son cuchillas instaladas en un chasis del Catalyst 6000 con la conectividad directa al NMP para el control y statusing.

En los ejemplos abajo, los mensajes que son explicados se identifican usando el texto en negrita. Éste es hacerla más fácil para que usted vea. En la muestra del resultado real, el texto no es en negrita. Los ejemplos son de un WS-X6624.

La primera cosa a marcar es que el gateway es en servicio. Todos los gatewayes tienen un “latido del corazón” LED que centelle 1-second encendido, 1-second de cuando el software de gateway se está ejecutando normalmente. Si este LED no está centellando en absoluto, ni está centellando muy rápidamente, después el software de gateway no se está ejecutando. Normalmente, esto dará lugar a un reinicio automático del gateway. También, es normal que el gateway se reajuste si no puede completar el proceso de inscripción después de cerca de 2 a 3 minutos. Así pues, usted puede suceder mirar el latido del corazón LED mientras que el dispositivo está reajustando. Si el modelo normal del centelleo no aparece en 10 a 15 segundos, después el gateway ha sufrido una falla grave. En el gateway AS-X o AT-X, el latido del corazón LED es el indicador luminoso verde del extremo derecho que muestra en el panel frontal. En el gateway DT-24+ o DE-30+, es el LED rojo de la parte izquierda en el borde superior del indicador luminoso LED amarillo de la placa muestra gravedad menor. En el acceso analógico WS-X6624, es un indicador luminoso verde dentro de la cuchilla (no visible del panel frontal) a la derecha el borde de placa del extremo derecho cerca del frente. Finalmente, en el acceso digital WS-X6608 hay un latido del corazón separado LED para cada uno de los 8 palmos en la cuchilla. Hay 8 LED rojos a través del indicador luminoso LED amarillo de la placa muestra gravedad menor (no visible del panel frontal) cerca de 2/3 de la manera hacia atrás.

La segunda cosa a marcar es que el gateway ha recibido su dirección IP. Un gateway autónomo debe recibir su dirección IP vía el DHCP o el BOOTP. Un gateway de Catalyst puede recibir su dirección IP por el DHCP, BOOTP, o por la configuración manual con el NMP. Si usted tiene acceso al servidor DHCP, la mejor manera de marcar un gateway autónomo es verificar que el dispositivo tiene un arriendo excepcional en una dirección IP. Si el gateway aparece en su servidor, éste es una buena indicación, pero no definitivo. Borre el arriendo en el servidor DHCP, y después reajuste el gateway. Si el gateway reaparece en el servidor con un arriendo dentro de un par de minutos, después todo está trabajando muy bien en esta área. ¿Si no, entonces o el gateway no puede entrar en contacto el servidor DHCP (es un router configurado incorrectamente y que no remite los broadcastes DHCP? Es el servidor que se ejecuta?), o no puede conseguir una respuesta positiva (es el pool de la dirección IP agotado?). Si marcar estas sugerencias no rinde la respuesta, utilice una traza de sniffer para determinar el problema específico.

Para un gateway del Catalyst 6000, usted debe aseegurarse que el NMP puede comunicar con el gateway. Usted puede marcar esto intentando hacer ping a su IP Address interno del NMP. La dirección IP está en el formato:

127.1.module.port

Así pues, en nuestro ejemplo, haríamos:

Console (enable) ping 127.1.7.1

127.1.7.1 is alive

Si hace ping los trabajos, entonces el comando show port mostrará la información de la dirección IP. Aseegure la información de la dirección IP y la dirección IP TFTP está correcta también. Si el gateway no está pudiendo obtener la información DHCP válida, la utilidad tracy (que se puede suministrar por el TAC de Cisco) se puede utilizar para determinar el problema. Publique el comando del Cat6000 CLI:

puerto Mod del tracy_start

En este ejemplo, el WS-X6624 es el módulo 7 y tiene solamente un solo procesador 860, así que es el puerto 1. El comando que publicaríamos es el tracy_start 7 1

El producto siguiente es realmente 860-console del puerto en la tarjeta del gateway sí mismo. Sin embargo, la salida del comando tracy no es nada más que una copia remota del puerto 860-console.

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.870 (CFG) Starting DHCP
00:00:02.870 (CFG) Booting DHCP for dynamic configuration.
00:00:06.570 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:06.570 (CFG) DHCP Server Response Processed, DHCPState = INIT_REBOOT
00:00:06.780 (CFG) IP Configuration Change! Restarting now...
00:00:10.480 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT
00:00:14:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:22:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:38:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT

Si el mensaje de tiempo de espera antedicho continúa navegando por, después hay un problema que entra en contacto el servidor DHCP. Marque que el puerto de gateway del Catalyst 6000 está en el VLA N correcto.

Esta información está en el comando show-++ port de antes. Si el servidor DHCP no está en el mismo VLA N que el gateway del Catalyst 6000, después aseegure los IP Helper Address apropiados haber sido configurado para remitir los pedidos de DHCP al servidor DHCP. Es posible que el gateway consiga pegado en el estado de Init después de un cambio del número VLAN hasta las restauraciones del gateway. Cuando en este estado, usted puede intentar reajustar el gateway. Cada vez que se reajusta los 860, perderán a su sesión tracy. Por lo tanto, usted debe cerrar a su sesión existente y restablecer un nuevo publicando los siguientes comandos:

puerto Mod del tracy_close

puerto Mod del tracy_start

Si todo el esto marca hacia fuera y usted todavía está viendo el DHCPState = los mensajes INIT, después control para ver si está funcionando el servidor DHCP correctamente. Si es así comience una traza de sniffer para ver si se están enviando las solicitudes y si está respondiendo el servidor.

Una vez que el DHCP está trabajando correctamente, el gateway tendrá una dirección IP que permita el uso de la utilidad de debugging de Tracy. Esta utilidad es una característica incorporada del comando set NMP para los gatewayes de Catalyst y está disponible como aplicación de ayuda que se ejecute en Windows 98/NT/2000 para los gatewayes autónomos. Para utilizar la utilidad tracy de la aplicación de ayuda, usted necesita el Conectar al gateway usando la dirección IP a la cual se asigna. Esta aplicación del tracy trabaja en todos los gatewayes, proporciona una ventana separada de la traza para cada gateway (hasta ocho se pueden localizar inmediatamente), y permite que las trazas sean registradas directamente a un archivo que usted especifica.

El siguiente paso es verificar que el TFTP Server IP Address fue proporcionado correctamente al gateway. Esto es proporcionada normalmente por el DHCP en la opción 66 (por nombre o dirección IP), la opción 150 (dirección IP solamente), o el si_addr (dirección IP solamente). Si su servidor tiene opción múltiple configurada, el si_addr tomará la precedencia sobre la Opción 150, que tomará la precedencia sobre la Opción 66. Si la opción 66 proporciona DNS_NAME del servidor TFTP, después el IP Address de los servidores DNS se debe haber especificado por el DHCP, y el nombre ingresado en la opción 66 debe resolver al TFTP Server IP Address correcto. Un gateway de Catalyst se podría configurar por el NMP para inhabilitar el DHCP, y el operador de NMP debe entonces ingresar todos los parámetros de la configuración a mano en la consola, incluyendo el TFTP Server Address.

Además, los gatewayes intentarán siempre resolver el nombre el "CiscoCM1" vía el DNS. Si es acertado, la dirección IP del CiscoCM1 tomará a precedencia sobre cualquier cosa el servidor DHCP o el NMP lo dice para el TFTP Server Address, incluso si el NMP tiene DHCP inhabilitado.

Usted puede marcar el TFTP Server IP Address actual en un gateway usando la utilidad tracy. Ingrese el siguiente comando de conseguir el número de la tarea de configuración:

TaskID: 0

Cmd: muestre el tl

Busque una línea con los “config” o el “CFG” y utilice el número de correspondencia como el taskID para la línea siguiente. Por ejemplo, para el gateway del acceso digital WS-X6624, el comando de vaciar la información de DHCP es:

TaskID: 6

Cmd: muestre el DHCP

El TFTP Server IP Address entonces se muestra claramente. Si no está correcto, verifique que su opción DHCP y la otra información que proporciona está correcta.

Una vez que el direccionamiento TFTP está correcto, el siguiente paso es asegurarse de que el gateway está consiguiendo su archivo de configuración del servidor TFTP. Si usted ve el siguiente en la salida del tracy, su servicio TFTP no puede trabajar correctamente o el gateway no se pudo configurar en el Cisco CallManager:

00:09:05.620 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server

    00:09:18.620 (CFG) TFTP 
    Error: Timeout Awaiting Server Response for .cnf File!

El gateway intentará conectar con la misma dirección IP que el servidor TFTP si no recibe un archivo de configuración. Esto está muy bien a menos que usted esté en un entorno agrupado en el cual el gateway necesite recibir su lista de CallManageres redundantes de Cisco. Si el indicador luminoso LED amarillo de la placa muestra gravedad menor no está recibiendo su información TFTP correctamente, marque servicio TFTP encendido el Cisco CallManager y aseegurelo se está ejecutando. También, marque la traza TFTP en el Cisco CallManager también.

Otro problema común es que el gateway no está configurado correctamente en el Cisco CallManager. Un error frecuente está ingresando un MAC Address incorrecto para el gateway. Si ésta es la caja, para un gateway del Catalyst 6000, usted probablemente conseguirá a siguientes mensajes en la consola NMP cada dos minutos:

2000 Apr 14 19:24:08 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:26:05 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:28:02 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously

Esto es lo que parecería la salida del tracy si el gateway no está en las base de dato del CallManager de Cisco:

00:00:01.670 (CFG) Booting DHCP for dynamic configuration.
00:00:05.370 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.370 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.370 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.370 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.370 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.370 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.370 (CFG) TFTP Error: .cnf File Not Found!
00:00:05.370 (CFG) Requesting SAADefault.cnf File From TFTP Server
00:00:05.380 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.380 (CFG) Updating Configuration ROM...
00:00:05.610 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.610 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.610 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.610 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.610 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.610 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:05.680 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:00:05.680 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:00:20.600 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:00:20.600 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:20.600 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:20.600 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM

Otro Problema de inscripción posible podría ser si la información de carga es incorrecta o el archivo de la carga es corrupto. El problema también podría ocurrir si el servidor TFTP no está funcionando. En este caso, tracy demuestra claramente que el servidor TFTP informó que no se encontró ese archivo:

00:00:07.390 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:08.010 GMSG: TFTP Request for application load A0021300
00:00:08.010 GMSG: CCM#0 CPEvent = LOADID --> CPState = AppLoadRequest
00:00:08.010 GMSG: ***TFTP Error: File Not Found***
00:00:08.010 GMSG: CCM#0 CPEvent = LOAD_UPDATE --> CPState = LoadResponse

En este caso, usted puede ver que el gateway está pidiendo la carga A0021300 de la aplicación, aunque el nombre de la carga correcto fuera A0020300. Para un gateway del Catalyst 6000, el mismo problema puede ocurrir cuando una carga de la nueva aplicación necesita conseguir su carga correspondiente del DSP también. Si la nueva carga del DSP no se encuentra, un mensaje similar aparecerá.

Las demostraciones siguientes la salida cuando un acceso analógico WS-X6224 se ha configurado para extraer una carga incorrecta de la aplicación. La salida parece similar a la de un gateway que no se ha configurado en el Cisco CallManager:

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.030 (CFG) Starting DHCP
00:00:02.030 (CFG) Booting DHCP for dynamic configuration.
00:00:05.730 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.730 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.730 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.730 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.730 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.730 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.730 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.730 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.730 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.730 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.730 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.730 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.730 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:06.320 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
00:01:36.300 GMSG: CCM#0 CPEvent = TIMEOUT --> CPState = BadCCM
00:01:36.300 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:01:46.870 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:01:51.300 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:01:51.300 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:01:51.300 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:01:51.300 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:01:51.300 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:01:51.300 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:01:51.890 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse

La diferencia aquí es que el gateway consigue pegado en la etapa de LoadResponse y mide el tiempo eventual hacia fuera. Este problema puede ser resuelto corrigiendo el nombre del archivo de la carga en la área de valores predeterminados del dispositivo de la administración del CallManager de Cisco.

Problemas del control de acceso

Antes de comenzar cualquier Troubleshooting de Gateway a Gatekeeper, verifique que hay conectividad del IP dentro de la red. Si se asume que hay conectividad del IP, utilice la información en esta sección para resolver problemas su gateway.

Links troncales del Inter-cluster solamente

Observe que el control del portero para la versión del CallManager de Cisco 3.0(1) está solamente disponible para los trunks del inter-cluster. El control del portero es configurable para los otros dispositivos, pero la configuración no se soporta.

Rechazos de la admisión (ARJ)

Los ARJ se publican cuando el Cisco CallManager se ha registrado con el portero, pero no pueden enviar las llamadas telefónicas. Los problemas de configuración en el portero deben ser el foco primario cuando el portero está publicando un ARJ. Sin embargo, abajo están las Pautas generales para localizar averías:

  1. Verifique la conectividad del IP del gateway al portero.

  2. Muestre el estatus del portero: verifique al portero que el estado está para arriba.

  3. ¿Hay una subred de la zona definida en el portero? Si es así verifique que la subred del gateway esté en las subredes permitidas.

Rechazos del registro (RRJ)

Se publican los RRJ cuando el Cisco CallManager no puede registrarse con el portero. Los problemas de configuración en el portero deben ser el foco primario cuando el portero está publicando un RRJ.

Sin embargo, aquí están las Pautas generales para localizar averías:

  1. Verifique la conectividad del IP del gateway al portero.

  2. Muestre el estatus del portero: verifique al portero que el estado está para arriba.

  3. ¿Hay una subred de la zona definida en el portero? Si es así verifique que la subred del gateway esté en las subredes permitidas.

Señal de ocupado rápido al marcar el número piloto del Voicemail

Si usted administrador ha parado y de llamada comenzada después de realizar algunos los cambios, aseegurese que usted comienza los procesos del utel, del ulite, del ulogremover y del upilot. Esto fue probada en el laboratorio por el remitente de CM 2.4.3 y el uone 4.1e. Esencialmente los dispositivos UM no reregistrarán con el administrador de llamada a menos que se recomiencen los procesos.

Caso práctico I: Llamadas de Cisco IP Phone a Cisco IP Phone dentro de un agrupamiento

Este caso práctico discute detalladamente el flujo de llamada entre dos Teléfonos IP de Cisco dentro de un cluster, llamado un llamada dentro del clúster. Este caso práctico también se centra en la inicialización del Cisco CallManager y del Cisco IP Phone, el registro, y los procesos de keepalive. Eso es seguida por una explicación detallada de un flujo del llamada dentro del clúster. Estos procesos se explican usando las utilidades de rastreo y las herramientas discutidos en una sección anterior.

Topología de ejemplo

El diagrama siguiente representa la topología de ejemplo para este caso práctico. En el diagrama hay dos clusteres nombrados el cluster 1 y el cluster 2. Los dos CallManageres de Cisco en el cluster 1 se llaman CCM3 y CCM4, mientras que los dos CallManageres de Cisco en el cluster 1 se nombran CCM1 y CCM2. Las trazas recogidas para este caso práctico son de CCM1, que está situado en el cluster 2. El flujo de llamada se basa en los dos Teléfonos IP de Cisco en el cluster 2. Los IP Addresses de estos dos Teléfonos IP de Cisco son 172.16.70.230 (número de directorio 1000) y 172.16.70.231 (número de directorio 1001), respectivamente.

ios_gatekeeper.gif

Proceso de inicialización de Cisco IP Phone

Del Cisco IP Phone de la inicialización (o “arrancar el proceso”) se explica detalladamente abajo.

  1. En la inicialización, el Cisco IP Phone envía una solicitud al servidor DHCP de conseguir una dirección IP, un DNS Server Address, y un nombre o un direccionamiento de servidor TFTP, si es apropiado. Las opciones se fijan en el servidor DHCP (opción 066, opción 150, y así sucesivamente). También consigue a una dirección de gateway predeterminado si está fijado en el servidor DHCP (opción 003).

  2. Si un nombre DNS del TFTP separa es enviado por el DHCP, después un DNS separa la dirección IP se requiere para asociar el nombre a una dirección IP. Se desvía este paso si el servidor DHCP envía la dirección IP del servidor TFTP. En este caso estudie, el servidor DHCP enviado la dirección IP del TFTP porque el DNS no fue configurado.

  3. Si un nombre de servidor TFTP no se incluye en la respuesta DHCP, después el Cisco IP Phone utiliza el valor por defecto Nombre del servidor.

  4. El archivo del archivo de configuración (.cnf) se extrae del servidor TFTP. Todos los archivos del .cnf tienen el nombre SEP<mac_address>.cnf, donde está siglas el “SEP” para el teléfono de los Ethernetes del Selsius. Si esto está la primera vez el teléfono se está registrando con el Cisco CallManager, después un archivo predeterminado, SEPdefault.cnf, se descarga al Cisco IP Phone. En este caso estudie, el primer Cisco IP Phone utiliza a la dirección IP 172.16.70.230 (su dirección MAC es SEP0010EB001720), y el segundo Cisco IP Phone utiliza a la dirección IP 172.16.70.231 (su dirección MAC es SEP003094C26105).

  5. Todos los archivos del .cnf incluyen la dirección IP del Cisco CallManager primario y secundario. El Cisco IP Phone utiliza la dirección IP para entrar en contacto el CallManager primario de Cisco y para registrarse.

  6. Una vez que el Cisco IP Phone ha conectado y se ha registrado con el Cisco CallManager, el Cisco CallManager dice a Cisco IP Phone qué versión ejecutable (llamada un ID de carga) a ejecutarse. Si la versión especificada no hace juego la versión de la ejecución en el Cisco IP Phone, el Cisco IP Phone pedirá el nuevo ejecutable del servidor TFTP y lo reajustará automáticamente.

El ejemplo siguiente de la traza de sniffer resume el proceso de inicialización del teléfono. Este ejemplo de seguimiento no se toma para la topología de ejemplo de este caso práctico, sino que proporciona un ejemplo de la serie de eventos que ocurre durante el proceso de inicialización del Cisco IP Phone.

sniffer_trace.gif

Proceso de registro de estación delgada

Los Teléfonos IP de Cisco comunican con el Cisco CallManager usando el Skinny Station Protocol de Cisco. El proceso de inscripción permite que una estación delgada, tal como un Cisco IP Phone, informe al Cisco CallManager su existencia y haga la llamada posible. La figura siguiente muestra los diversos mensajes que se intercambian entre el Cisco IP Phone (la “estación”) y el Cisco CallManager.

/image/gif/paws/30266/skinny.gif

Los mensajes principales en el proceso de inscripción de la estación delgada se describen en la tabla siguiente.

Descripciones de proceso de inscripción de la estación delgada
Mensaje Descripción
Registro de la estación La estación envía este mensaje para anunciar su existencia al Cisco CallManager que controla.
Restauración de la estación El Cisco CallManager envía este mensaje para ordenar a la estación que reajuste sus procesos.
Puerto IP de la estación La estación envía este mensaje para proporcionar el Cisco CallManager con el puerto del User Datagram Protocol (UDP) que se utilizará con la secuencia RTP.
El registro de la estación reconoce El Cisco CallManager envía este mensaje para reconocer el registro de una estación.
Rechazo del registro de la estación El Cisco CallManager envía este mensaje para rechazar una tentativa del registro del teléfono indicado.
 
char text[StationMaxDisplayTextSize]; 

};
Donde: el texto es una cadena de carácter, Largo máximo de 33 bytes, conteniendo una descripción textual de la razón que el registro está rechazado.
Petición de las capacidades de la estación El Cisco CallManager envía este mensaje para pedir las capacidades actuales de la estación. Las capacidades de la estación pueden incluir el estándar de compresión y otras capacidades de H.323.
Petición de la versión de la estación La estación envía este mensaje para pedir el número de la versión de la carga del software para la estación.
Respuesta de la versión de la estación El Cisco CallManager envía este mensaje para informar a la estación el número de versión de software apropiado.
Respuesta de las capacidades de la estación La estación envía este mensaje al Cisco CallManager en respuesta a una petición de las capacidades de la estación. Las capacidades de la estación se ocultan en el Cisco CallManager y se utilizan para negociar las Capacidades del terminal con un terminal compatible de H.323.
Petición de la plantilla de botón de la estación La estación envía este mensaje para pedir la definición de plantilla de botón para esa terminal específica o el Cisco IP Phone.
Respuesta de la plantilla de botón de la estación El Cisco CallManager envía este mensaje para poner al día la información de la plantilla de botón contenida en la estación.
Petición de la fecha del tiempo de estación La estación envía este mensaje para pedir la fecha y hora actual para el uso interno y para visualizar como cadena de texto.
La estación define la Fecha y hora El Cisco CallManager utiliza este mensaje para proporcionar la información de la fecha y hora a la estación. Proporciona la sincronización horaria para las estaciones.

Flujo de llamadas de un teléfono del IP de Cisco a otro teléfono del IP de Cisco en un agrupamiento

Esta sección describe un Cisco IP Phone (número de directorio 1000) que llama otro Cisco IP Phone (número de directorio 1001) dentro del mismo cluster. El cluster es un grupo de CallManageres de Cisco que tienen una bases de datos comunes de Publisher SQL y muchas bases de datos SQL del suscriptor.

En nuestra topología de ejemplo, CCM1 es el editor y CCM2 es un suscriptor. Los dos Teléfonos IP de Cisco (1000 y 1001) se registran a CCM1 y a CCM2, respectivamente. El flujo de llamada se muestra en el diagrama a continuación. Los dos CallManageres de Cisco dentro de un cluster comunican con uno a usando el Control Protocol del Intra-cluster (ICCP). Cuando va un Cisco IP Phone descolgado, abre una sesión de la estación delgada del control (con el TCP como el protocolo subyacente) con el Cisco CallManager. Después de que la señalización de Control de llamadas se establezca entre los dos Teléfonos IP de Cisco y sus CallManageres respectivos de Cisco, la secuencia RTP comienza a fluir directamente entre los dos teléfonos, tal y como se muestra en del diagrama a continuación. Los mensajes del flujo de llamadas de estación Skinny para este llamada dentro del clúster se explican en la siguiente sección.

/image/gif/paws/30266/1000_calls_1001.gif

Intercambio de mensajes de estaciones “delgadas” entre teléfonos IP de Cisco durante el flujo de llamadas

La figura siguiente muestra un intercambio de la muestra de los mensajes entre dos estaciones delgadas. La estación delgada, o el Cisco IP Phone, inicia una conexión al Cisco CallManager, y entonces el Cisco CallManager realiza la análisis de dígitos antes de abrir una sesión del control con la estación delgada del destino. Mientras que el diagrama siguiente indica, los mensajes de estación delgada se escriben usando el nivel simple de Inglés así que pueden ser entendidos fácilmente por los usuarios finales. Debido a esto, estos mensajes no se explican en esta sección. Sin embargo, estos mensajes de estación delgada del flujo de llamada se explican más detalladamente en las secciones posteriores cuando se están examinando las trazas.

/image/gif/paws/30266/call_flow.gif

Proceso de Inicialización del Cisco CallManager

En esta sección el proceso de inicialización del Cisco CallManager será explicado con la ayuda de las trazas que se capturan de CCM1 (identificado por la dirección IP 172.16.70.228). Según lo descrito previamente, las trazas del SDI son mismo una herramienta del Troubleshooting eficaz porque detallan cada paquete enviado entre los puntos finales. Esta sección describirá los eventos que ocurren cuando se inicializa el Cisco CallManager. La comprensión de cómo leer la traza ayuda le a resolver problemas correctamente los diversos procesos del Cisco CallManager, y al efecto de esos procesos sobre los servicios tales como Conferencia, reenvío de llamada, y así sucesivamente.

Los siguientes mensajes de la utilidad de rastreo del SDI del Cisco CallManager muestran el proceso de inicialización en uno de los CallManageres de Cisco, en este caso, CCM1. Revise las descripciones de cada mensaje abajo.

  • El primer mensaje indica que el Cisco CallManager comenzó su proceso de inicialización.

  • El segundo mensaje indica que el Cisco CallManager leyó los valores predeterminados de la base de datos, que serían los primarios o las Bases de datos del editor (para este caso).

  • El tercer mensaje indica que el Cisco CallManager escuchó los diversos mensajes en el puerto TCP 8002.

  • El cuarto mensaje muestra que, después de escuchar estos mensajes, el Cisco CallManager agregó un segundo Cisco CallManager a su lista: CCM2 (172.16.70.229).

  • El quinto mensaje indica que el Cisco CallManager ha comenzado y es la versión del CallManager de Cisco corriente 3.0.20.

16:02:47.765 CCM|CMProcMon - CallManagerState Changed - Initialization Started.
16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CM Database Defaults Read
16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: [172.16.70.228], Listen Port: [8002]
16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: [172.16.70.229]
16:02:51.031 CCM|NodeId: 1, EventId: 1 EventClass: 3 EventInfo: Cisco CallManager Version=<3.0(0.20)> started

Procesos de inicio automático

Una vez que el Cisco CallManager es en servicio, comienza varios otros procesos dentro de sí mismo. Algunos de estos procesos se muestran abajo, incluyendo el administrador MulticastPoint, el administrador UnicastBridge, la análisis de dígitos, y la lista de la ruta. Los mensajes descritos durante estos procesos pueden ser muy útiles al localizar averías un problema relacionado con las características en el Cisco CallManager.

Por ejemplo, asuma que las listas de la ruta no están funcionando y están inutilizables. Para resolver problemas este problema, usted monitorearía estas trazas para determinar si el Cisco CallManager ha comenzado RoutePlanManager y si está intentando cargar las listas de la ruta. En la configuración de muestra abajo, RouteListName= '' ipwan” y RouteGroupName= '' ipwan” están cargando y están comenzando.

16:02:51.031 CCM|MulicastPointManager - Started
16:02:51.031 CCM|UnicastBridgeManager - Started
16:02:51.031 CCM|MediaTerminationPointManager - Started
16:02:51.125 CCM|MediaCoordinator(1) - started
16:02:51.125 CCM|NodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager started
16:02:51.234 CCM|NodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager started
16:02:51.390 CCM|NodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis started
16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists
16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists
16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups
16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection Order
16:02:51.671 CCM|RouteList - RouteListName=''ipwan''
16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan''
16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection Order
16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''

La traza siguiente muestra el routegroup que agrega el dispositivo 172.16.70.245, que es CCM3 situado en el cluster 1 y consideraba un dispositivo de H.323. En este caso, el routegroup se crea para rutear las llamadas a CCM3 en el cluster 1 con el permiso del Cisco IOS Gatekeeper. Si hay un problema que rutea la llamada a un Cisco IP Phone situado en el cluster 1, después los siguientes mensajes le ayudarían a encontrar la causa del problema.

16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup -AllPorts

La parte del proceso de inicialización muestra que el Cisco CallManager está agregando los DN. Revisando estos mensajes, usted puede determinar si el Cisco CallManager ha leído el número de directorio de la base de datos.

16:02:51.671 CCM|NodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control started
16:02:51.843 CCM|ProcessDb - Dn = 2XXX, Line = 0, Display = , RouteThisPattern, 
NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause =
16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCM|ForwardManager - Started
16:02:51.984 CCM|CallParkManager - Started
16:02:52.046 CCM|ConferenceManager - Started

En las trazas siguientes el administrador de dispositivo en el Cisco CallManager está inicializando estáticamente dos dispositivos. El dispositivo con la dirección IP 172.17.70.226 es portero y el dispositivo con la dirección IP 172.17.70.245 es otro Cisco CallManager en un clúster diferente. Ese Cisco CallManager se registra como gateway de H.323 con este Cisco CallManager.

16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.226
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.245

Proceso de Registro del Cisco CallManager

Otro parte importante de la traza del SDI es el proceso de inscripción. Cuando un dispositivo se acciona para arriba, consigue la información vía el DHCP, conecta con el servidor TFTP para su archivo del .cnf, y después conecta con el Cisco CallManager especificado en el archivo del .cnf. El dispositivo podía ser un gateway MGCP, un gateway Skinny, o un Cisco IP Phone. Por lo tanto, es importante poder descubrir independientemente de si los dispositivos se han registrado con éxito en la red del Cisco AVVID.

En la traza siguiente, el Cisco CallManager ha recibido las nuevas conexiones para el registro. Los dispositivos de registro son los "MTP_nsa-cm1" (servicios MTP en CCM1), y los "CFB_nsa-cm1" (servicio del Bridge de conferencia en CCM1). Éstos son servicios de software que se ejecutan en el Cisco CallManager pero se tratan internamente como diversos servicios externos y por lo tanto se asignan un tcpHandle, número de socket, y número del puerto así como un Nombre del dispositivo.

16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbaa00, 
Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[0,0,0]
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fe05e8, 
Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[0,0,0]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=MTP_nsa-cm1, 
TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[1,45,2]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=CFB_nsa-cm1, 
TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[1,96,2]

En la traza siguiente, los mensajes de estación delgada se envían entre un Cisco IP Phone y un Cisco CallManager. El Cisco IP Phone (172.16.70.231) se está registrando con el Cisco CallManager. Refiera a las descripciones de los mensajes de estación delgada anterior en esta sección para más información. Tan pronto como el Cisco CallManager reciba el pedido de inscripción de un Cisco IP Phone, asigna un número del tcpHandle a este dispositivo. Este número sigue siendo lo mismo hasta que se recomience el dispositivo o el Cisco CallManager. Por lo tanto, usted puede seguir todos los eventos relacionados con un dispositivo determinado buscando para o no perdiendo de vista el número del tcpHandle del dispositivo, que aparece en el maleficio. También, note que el Cisco CallManager proporciona el ID de carga al Cisco IP Phone. De acuerdo con este ID de carga, el Cisco IP Phone funciona con el archivo ejecutable (adquirido del servidor TFTP) que corresponde al dispositivo.

16:02:57.000 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbbc30, 
Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[0,0,0]
16:02:57.046 CCM|NodeId: 1, EventId: 1703 EventClass: 2 EventInfo: Station Alarm, 
TCP Handle: 4fbbc30, Text: Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr 
LastTime=A P1: 2304(900) P2: -414838612(e74610ac)
16:02:57.046 CCM|StationInit - ***** InboundStim - AlarmMessageID 
tcpHandle=0x4fbbc30 Message="Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr LastTime=A" 
Parm1=2304 (900) Parm2=-414838612 (e74610ac)
16:02:57.093 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=SEP003094C26105, 
TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]
16:02:57.093 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) 
tcpHandle=0x4fbbc30

Proceso de señal de mantenimiento de Cisco CallManager

Amba la estación, el dispositivo, o el servicio y el Cisco CallManager utilizan los siguientes mensajes para mantener un conocimiento del canal de comunicaciones entre ellos. Los mensajes se utilizan para comenzar la secuencia del keepalive que se asegura de que el enlace de comunicaciones entre el Cisco CallManager y la estación siga siendo activo. Los siguientes mensajes pueden originar del Cisco CallManager o de la estación.

16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=MTP_nsa-cm2, TCPHandle=0x4fa7dc0, Socket=0x568, IPAddr=172.16.70.229, Port=1556, 
StationD=[1,45,1]
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=CFB_nsa-cm2, TCPHandle=0x4bf8a70, Socket=0x57c, IPAddr=172.16.70.229, Port=1557, 
StationD=[1,96,1]
16:03:06.640 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP0010EB001720, TCPHandle=0x4fbb150, Socket=0x600, IPAddr=172.16.70.230, Port=49211, 
StationD=
[1,85,2]
16:03:06.703 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, 
StationD=
[1,85,1]

Los mensajes en la traza siguiente representan la secuencia del keepalive que indica que el enlace de comunicaciones entre el Cisco CallManager y la estación es activo. Una vez más estos mensajes pueden originar por el Cisco CallManager o la estación.

16:03:02.328 CCM|MediaTerminationPointControl - stationOutputKeepAliveAck tcpHandle=4fa7dc0
16:03:02.328 CCM|UnicastBridgeControl - stationOutputKeepAliveAck tcpHandle=4bf8a70
16:03:06.703 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) tcpHandle=0x4fbbc30
16:03:06.703 CCM|StationD - stationOutputKeepAliveAck tcpHandle=0x4fbbc30

Seguimiento del Flujo de Llamadas dentro del Cluster del Cisco CallManager

Las trazas siguientes del SDI exploran detalladamente el flujo del llamada dentro del clúster. Los Teléfonos IP de Cisco en el flujo de llamada se pueden identificar por el DN, el tcpHandle, y la dirección IP. Un Cisco IP Phone (DN=1001, tcpHandle=0x4fbbc30, IP address=172.16.70.231) situado en el cluster 2 está llamando otro Cisco IP Phone en el mismo cluster (DN=1000, el tcpHandle= 0x4fbb150, dirección IP = 172.16.70.230). Recuerde que usted puede seguir un dispositivo a través de la traza mirando el valor, el sello de fecha/hora, o el nombre de la manija TCP del dispositivo. El valor de la manija TCP para el dispositivo sigue siendo lo mismo hasta que se reinicie el dispositivo o va off-liné.

Las trazas siguientes muestran que ha ido el Cisco IP Phone (1001) descolgado. La traza abajo muestra los mensajes únicos, manija TCP, y número al que se llamó cuáles se visualizan en el Cisco IP Phone. No hay número que llama en este momento, porque el usuario no ha intentado marcar ninguna dígitos. La información abajo está bajo la forma de mensajes de estación delgada entre los Teléfonos IP de Cisco y el Cisco CallManager.

16:05:41.625 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:41.625 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001

La traza siguiente muestra los mensajes de estación delgada que van del Cisco CallManager a un Cisco IP Phone. El primer mensaje es encender la lámpara en el Cisco IP Phone de la parte llamadora.

16:05:41.625 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn 
tcpHandle=0x4fbbc30

El mensaje stationOutputCallState es utilizado por el Cisco CallManager para notificar la estación de cierta información llamada-relacionada.

16:05:41.625 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30

El mensaje stationOutputDisplayPromptStatus es utilizado por el Cisco CallManager para hacer un prompt de petición llamada-relacionado ser visualizado en el Cisco IP Phone.

16:05:41.625 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

El mensaje stationOutputSelectSoftKey es utilizado por el Cisco CallManager para hacer la estación delgada seleccionar un conjunto específico de teclas programables.

16:05:41.625 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30

El mensaje siguiente es utilizado por el Cisco CallManager para dar instrucciones la estación delgada en cuanto a la línea correcta contexto para la visualización.

16:05:41.625 CCM|StationD - stationOutputActivateCallPlane tcpHandle=0x4fbbc30

En el siguiente mensaje, el proceso de la análisis de dígitos está listo para identificar los dígitos entrantes y marcarlos para saber si hay la encaminamiento potencial hace juego en la base de datos. La entrada, cn=1001, representa el número de la parte llamadora. el "" del dd= representa el dígito marcado, que mostraría el numero de parte llamado. Observe que los mensajes Stationlnit son enviados por el teléfono, los mensajes de StationD son enviados por el Cisco CallManager, y la análisis de dígitos es realizada por el Cisco CallManager.

16:05:41.625 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:41.625 CCM|Digit analysis: potentialMatches=PotentialMatchesExist

El mensaje siguiente del debug muestra que el Cisco CallManager está proporcionando al tono de discado interior al Cisco IP Phone de la parte llamadora.

16:05:41.625 CCM|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x4fbbc30

Una vez que el Cisco CallManager detecta un mensaje entrante y reconoce el botón 1 del telclado numérico se ha presionado en el Cisco IP Phone, para inmediatamente el tono de la salida.

16:05:42.890 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 1 
tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:42.890 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1")
16:05:42.890 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.203 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.203 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="10")
16:05:43.203 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.406 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.406 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="100")
16:05:43.406 CCM|Digit analysis: potentialMatches=PotentialMatchesExist|
16:05:43.562 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.562 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1000")

Una vez que el Cisco CallManager ha recibido bastantes dígitos para hacer juego, proporciona los resultados de la análisis de dígitos en un formato de la tabla. Cualquier dígitos adicionales presionados en el teléfono después de que esta punta sea ignorada por el Cisco CallManager, puesto que una coincidencia se ha encontrado ya.

16:05:43.562 CCM|Digit analysis: analysis results
16:05:43.562 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=1000
|DialingRoutePatternRegularExpression=(1000)
|PotentialMatches=PotentialMatchesExist
|DialingSdlProcessId=(1,38,2)
|PretransformDigitString=1000
|PretransformPositionalMatchList=1000
|CollectedDigits=1000
|PositionalMatchList=1000
|RouteBlockFlag=RouteThisPattern

La traza siguiente muestra que el Cisco CallManager está enviando esta información a un teléfono de la Parte llamada (el teléfono es identificado por el número del tcpHandle).

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbb150

La traza siguiente indica que el Cisco CallManager está ordenando la lámpara centellar para la indicación de la llamada entrante en el Cisco IP Phone de la Parte llamada.

16:05:43.578 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampBlink tcpHandle=0x4fbb150

En las trazas siguientes, el Cisco CallManager está proporcionando al campanero, a la notificación en pantalla, y a la otra información llamada-relacionada al Cisco IP Phone de la Parte llamada. Una vez más usted puede ver que todos los mensajes están dirigidos al mismo Cisco IP Phone porque el mismo tcpHandle se utiliza en las trazas.

16:05:43.578 CCM|StationD - stationOutputSetRinger: 2=InsideRing tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayNotify tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbb150

Note que el Cisco CallManager también está proporcionando a la información similar al Cisco IP Phone de la parte llamadora. Una vez más el tcpHandle se utiliza para distinguir entre los Teléfonos IP de Cisco.

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=1000, tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbbc30

En la traza siguiente, el Cisco CallManager proporciona alertar o un tono de llamada al Cisco IP Phone de la parte llamadora, notificando que se ha establecido la conexión.

16:05:43.578 CCM|StationD - stationOutputStartTone: 36=AlertingTone tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

En este momento, el Cisco IP Phone de la Parte llamada va descolgado. Por lo tanto, el Cisco CallManager para el generar del tono del campanero a la parte llamadora.

16:05:45.140 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30

En los siguientes mensajes, el Cisco CallManager hace la estación delgada comenzar a recibir una secuencia del unicast RTP. Para hacer así pues, el Cisco CallManager proporciona la dirección IP de la Parte llamada así como la información de códec, y los tamaños de paquetes en el milisegundo (milisegundos). PacketSize es un número entero que contiene el tiempo del muestreo en los milisegundos usados para crear los paquetes RTP.

Nota: Este valor se fija normalmente a 30msec. En este caso, se fija a 20msec.

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbbc30 
myIP: e74610ac (172.16.70.231)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

Semejantemente, el Cisco CallManager proporciona la información a la Parte llamada (1000).

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbb150 
myIP: e64610ac (172.16.70.230)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

El Cisco CallManager ha recibido el mensaje de reconocimiento de la Parte llamada para establecer el canal abierto para la secuencia RTP, así como la dirección IP de la Parte llamada. Este mensaje es informar al Cisco CallManager dos información sobre la estación delgada. Primero, contiene el estatus de la acción abierta. En segundo lugar, contiene la dirección de puerto y el número de la recepción para la transmisión al extremo remoto. La dirección IP del transmisor (que llama la parte) de la secuencia RTP es ipaddr, y PortNumber es el número del puerto IP del transmisor de flujo RTP (parte llamadora).

16:05:45.265 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID 
tcpHandle=0x4fbb150, Status=0, 
IpAddr=0xe64610ac, Port=17054, PartyID=2

Los siguientes mensajes son utilizados por el Cisco CallManager para pedir la estación para comenzar a transmitir la secuencia de audio a la dirección IP remota y al número del puerto de Cisco del teléfono indicado IP.

16:05:45.265 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbbc30 
myIP: e74610ac 
(172.16.70.231)
16:05:45.265 CCM|StationD - RemoteIpAddr: e64610ac (172.16.70.230) RemoteRtpPortNumber: 
17054 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

En las trazas siguientes, los mensajes previamente explicados se envían a la Parte llamada. Estos mensajes son seguidos por los mensajes que indican que la secuencia de medios RTP ha comenzado entre parte que recibe la llamada y parte que la realiza.

16:05:45.312 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbb150 
myIP: e64610ac 
(172.16.70.230)
16:05:45.328 CCM|StationD - RemoteIpAddr: e74610ac (172.16.70.231) RemoteRtpPortNumber: 
18448 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

El Cisco IP Phone de la parte llamadora finalmente va el en-gancho, que termina todos los mensajes del control entre la estación delgada y el Cisco CallManager, así como la secuencia RTP entre las estaciones delgadas.

16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Caso práctico II: Llamadas de teléfono del IP de Cisco a la puerta de enlace de Cisco IOS

En el caso práctico anterior, el flujo de llamada y las técnicas de Troubleshooting de un llamada dentro del clúster fueron discutidos detalladamente. Este caso práctico examina un Cisco IP Phone que llama con un Cisco IOS Gateway a un teléfono conectado con un PBX local o en alguna parte en el PSTN. Conceptual, cuando la llamada alcanza el Cisco IOS Gateway, el gateway remitirá a llamada cualquiera a un teléfono que cuelga apagado de su puerto de la Estación de intercambio remota (FXS), o al PBX. Si la llamada se remite al PBX, podría terminar a un teléfono que colgaba apagado de un PBX local o el PBX lo remitirá sobre el PSTN y la llamada terminará en alguna parte en el PSTN.

Topología de ejemplo

El diagrama siguiente muestra la topología de ejemplo para este caso práctico. Las llamadas se rutean a través de los gatewayes del Cisco IOS y de la interfaz al PSTN, o el PBX es T1/CAS o T1/PRI. Los gatewayes pueden ser los modelos 26XX, 36XX, 53XX o 6K.

/image/gif/paws/30266/ios_gatekeeper2.gif

Llamada de rastreo de flujos

Esta sección discute la llamada atraviesa los ejemplos seguimiento del CallManager del archivo CCM000000000 (refiera a la sección anterior para la ubicación del archivo). Las trazas en este caso estudian el foco solamente en el flujo de llamada sí mismo, pues la información de traza más detallada se ha explicado ya en el caso práctico anterior (inicialización, registro, mecanismo de keepalive, y así sucesivamente).

En este flujo de llamada, un Cisco IP Phone (número de directorio 1001) situado en el cluster 2 está llamando un teléfono (número de directorio 3333) situado en alguna parte en el PSTN. Recuerde que usted puede seguir un dispositivo a través de la traza mirando el valor, el sello de fecha/hora, o el nombre de la manija TCP del dispositivo. El valor de la manija TCP para el dispositivo sigue siendo lo mismo hasta que se reinicie el dispositivo o va off-liné.

En las trazas siguientes, el Cisco IP Phone (1001) ha ido descolgado. La traza muestra los mensajes únicos, la manija TCP, y el número que llama, que se visualiza en el Cisco IP Phone. Hay ningún número al que se llamó en este momento porque el usuario no ha intentado marcar ninguna dígitos.

16:05:46.37515:20:18.390 CCM|StationInit - InboundStim ? OffHookMessageID tcpHandle=0x5138d98
15:20:18.390 CCM|StationD - stationOutputDisplayText tcpHandle=0x5138d98, Display=1001 

En las trazas siguientes, el usuario está marcando los 3333, un en un momento del dígito. El número 3333 es el número de destino del teléfono, que está situado en alguna parte en la red PSTN. El proceso de la análisis de dígitos del Cisco CallManager está actualmente - active y está analizando los dígitos para descubrir dónde la llamada necesita ser ruteada. Una más explicación detallada de la análisis de dígitos fue proporcionada en el caso práctico anterior.

15:20:18.390 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
15:20:19.703 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3")
15:20:20.078 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="33")
15:20:20.718 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="333")
15:20:21.421 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3333")
15:20:21.421 CCM|Digit analysis: analysis results

En las trazas siguientes, se ha completado la análisis de dígitos, han correspondido con la llamada y a la Parte llamada, y se ha analizado la información.

|CallingPartyNumber=1001
|DialingPattern=3333
|DialingRoutePatternRegularExpression=(3333)
|PretransformDigitString=3333
|PretransformPositionalMatchList=3333
|CollectedDigits=3333
|PositionalMatchList=3333

En las trazas siguientes, el número 0 indica la ubicación que origina, y el número 1 indica el Ubicación de destino. El ancho de banda de la ubicación que origina es determinado por el BW = 1. El valor 1 implica que el ancho de banda es infinito. El ancho de banda es infinito porque la llamada fue originada de un Cisco IP Phone situado en un entorno LAN. El ancho de banda del Ubicación de destino es determinado por el BW = 64. El destino de llamada está a un teléfono situado en un PSTN, y utilizan al tipo de códec es G.711 (64Kbps).

15:20:21.421 CCM|Locations:Orig=0 BW=-1 Dest=1 BW=64 (-1 implies infinite bw available)

Las trazas siguientes muestran la información de la llamada y de la Parte llamada. En este ejemplo, el nombre y el número de la parte llamadora es lo mismo porque el administrador no ha configurado un nombre de la visualización, tal como “John Smith.”

15:20:21.421 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98

Antes de revisar las trazas siguientes, es importante entender el significado del término H.323. Por una explicación abreviada, hay varios protocolos se utilizan que al establecer una sesión de H.323. Un protocolo es el H.225, que se utiliza sobre todo para la señalización de llamada y es un subconjunto de q.931. Otro protocolo es el H.245, que se utiliza para el intercambio de capacidad. Una de las funciones más importantes del H.245 es la negociación del tipo del compresor/descompresor (codificador-decodificador), tal como G.711, G.729, y así sucesivamente, entre la llamada y la parte llamada. Una vez que el intercambio de capacidad es completo, la función importante siguiente del H.245 está realizando una negociación de puerto UDP entre la llamada y las partes llamadas.

La traza siguiente muestra que se ha inicializado el código de H.323 y está enviando un mensaje setup H.225. Usted puede también ver los mensajes SAPI tradicionales del HDLC, la dirección IP de la parte llamada en el maleficio, y los números del puerto.

15:20:21.421 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol
15:20:21.421 CCM|MMan_Id= 1. (iep= 0 dsl= 0 sapi= 0 ces= 0 IpAddr=e24610ac IpPort=47110)

La traza siguiente muestra la información de la llamada y de la Parte llamada, así como el mensaje que alerta H.225. También se muestra la asignación del valor hex de Cisco de un teléfono IP a la dirección IP. 172.16.70.231 es la dirección IP del Cisco IP Phone (1001).

15:20:21.437 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98
15:20:21.453 CCM|In Message -- H225AlertMsg -- Protocol= H225Protocol
15:20:21.953 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)

La traza siguiente muestra el tipo de compresión usado para esta llamada (�-ley de G.711).

15:20:21.953 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

Una vez que se ha enviado el mensaje de alerta H.225, la parte de siguiente H.323 es se inicializa: H.245. La traza siguiente muestra la información de la llamada y de la Parte llamada y los mensajes H.245. Note que el valor de la manija TCP es lo mismo que antes, la indicación de esto es la continuación de la misma llamada.

15:20:22.062 CCM|H245Interface(3) paths established ip = e74610ac, port = 23752
15:20:22.062 CCM|H245Interface(3) OLC outgoing confirm ip = e24610ac, port = 16758
15:20:22.062 CCM|MediaManager - wait_AuConnectInfo - received response, forwarding

La traza siguiente muestra el mensaje CONNECT H.225, así como la otra información que fue explicada anterior. Cuando se recibe el mensaje CONNECT H.225, la llamada ha estado conectada.

15:20:22.968 CCM|In Message -- H225ConnectMsg -- Protocol= H225Protocol
15:20:22.968 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:22.062 CCM|MediaCoordinator - wait_AuConnectInfoInd
15:20:22.062 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x5138d98 
myIP: e74610ac 
(172.16.70.231)
15:20:22.062 CCM|StationD - RemoteIpAddr: e24610ac (172.16.70.226) RemoteRtpPortNumber: 
16758 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
15:20:22.062 CCM|Locations:Orig=0 BW=-1Dest=1 BW=6(-1 implies infinite bw available)

El siguiente mensaje muestra que un mensaje del en-gancho del Cisco IP Phone (1001) se está recibiendo. Tan pronto como se reciba un mensaje del en-gancho, se envían el H.225 y los mensajes flacos de la desconexión y se considera el mensaje entero H.225. Este último mensaje indica que se ha terminado la llamada.

15:20:27.296 CCM|StationInit - InboundStim ? OnHookMessageID tcpHandle=0x5138d98
15:20:27.296 CCM|ConnectionManager -wait_AuDisconnectRequest (16777247,16777248): STOP SESSION
15:20:27.296 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending 
disconnect to (64,5) and remove 
connection from list
15:20:27.296 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
15:20:27.296 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x5138d98 myIP:
 e74610ac (172.16.70.231)
15:20:27.296 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)
15:20:28.328 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol

Mensajes de depuración y Comandos show de Cisco IOS Gatekeeper

En la sección anterior, la traza del SDI del Cisco CallManager fue discutida detalladamente. En la topología para este caso práctico, los ras del debug se han girado en el Cisco IOS Gatekeeper.

Los mensajes siguientes del debug muestran que el Cisco IOS Gatekeeper está recibiendo el pedido de admisión (ARQ) para el Cisco CallManager (172.16.70.228), seguido por otros mensajes RAS exitosos. Finalmente, el Cisco IOS Gatekeeper envía un mensaje del Admission Confirmed (ACF) al Cisco CallManager.

*Mar 12 04:03:57.181: RASLibRASRecvData ARQ (seq# 3365) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
*Mar 12 04:03:57.181: RASlibras_sendto msg length 16 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendACF ACF (seq# 3365) sent to 172.16.70.228

Los mensajes siguientes del debug muestran que la llamada está en curso.

*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 
55 from 172.16.70.228883

Los mensajes siguientes del debug muestran que el Cisco IOS Gatekeeper ha recibido una petición desunida (DRQ) del Cisco CallManager (172.16.70.228), y el Cisco IOS Gatekeeper ha enviado un desembarazo confirmado (DCF) al Cisco CallManager.

*Mar 12 04:03:57.181: RASLibRASRecvData DRQ (seq# 3366) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASlibras_sendto msg length 3 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendDCF DCF (seq# 3366) sent to 172.16.70.228
*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 124 
from 172.16.70.228883

El comando show gatekeeper endpoints en el Cisco IOS Gatekeeper muestra que los cuatro CallManageres de Cisco están registrados con el Cisco IOS Gatekeeper. Recuerde que en la topología para este caso práctico, hay cuatro CallManageres de Cisco, dos en cada cluster. Este Cisco IOS Gatekeeper tiene dos zonas y cada zona tiene dos CallManageres de Cisco.

R2514-1#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
===================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type
--------------- ----- --------------- ----- --------- ---- --
172.16.70.228 2 172.16.70.228 1493 gka.cisco.com VOIP-GW
H323-ID: ac1046e4->ac1046f5
172.16.70.229 2 172.16.70.229 3923 gka.cisco.com VOIP-GW
H323-ID: ac1046e5->ac1046f5
172.16.70.245 1 172.16.70.245 1041 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
172.16.70.243 1 172.16.70.243 2043 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
Total number of active registrations = 4

Mensajes de depuración y comandos show en la gateway del IOS de Cisco

En la sección anterior, discutieron los comandos show y las salidas de los debugs del Cisco IOS Gatekeeper detalladamente. Esta sección se centra en la salida de los debugs y los comandos show en el Cisco IOS Gateway. En la topología para este caso práctico, las llamadas están pasando a través de los gatewayes del Cisco IOS. El Cisco IOS Gateway interconecta al PSTN o al PBX con las interfaces T1/CAS o T1/PRI. Muestran la salida de los debugs de los comandos tales como inout del ccapi del voip del debug, los eventos del h225 del debug, y el asn1 del h225 del debug abajo.

En la salida de los debugs siguiente, el Cisco IOS Gateway está validando la petición de conexión TCP del Cisco CallManager (172.16.70.228) en el puerto 2328 para el H.225.

*Mar 12 04:03:57.169: H225Lib::h225TAccept: TCP connection accepted from 
172.16.70.228:2328 on socket [1]
*Mar 12 04:03:57.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
*Mar 12 04:03:57.177: Hex representation of the received TPKT03000065080000100

La salida de los debugs siguiente muestra que los datos H.225 están viniendo del Cisco CallManager en esta sesión TCP. En esta salida de los debugs es importante notar el protocolIdentifier, que indica la versión de H.323 que es utilizada. El debug siguiente muestra que se está utilizando la versión 2 de H.323. Parte que recibe la llamada y parte que la realiza los números también se muestran.

- Source Address H323-ID
- Destination Address e164
*Mar 12 04:03:57.177: H225Lib::h225RecvData: Q.931 SETUP received from socket 
[1]value H323-UserInformation ::=
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-uu-pdu
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-message-body setup :
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.181: sourceAddress
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-ID : "1001"
*Mar 12 04:03:57.181: },
*Mar 12 04:03:57.185: destinationAddress
*Mar 12 04:03:57.185: {
*Mar 12 04:03:57.185: e164 : "3333"
*Mar 12 04:03:57.185: },
*Mar 12 04:03:57.189: H225Lib::h225RecvData: State changed to [Call Present].

Lo que sigue es salida de los debugs para la Interfaz de programación de aplicación de control de llamada (CCAPi). El CCAPi está indicando una llamada entrante. Información de la parte que recibe la llamada y de la parte que la realiza puede también ser visto en el producto siguiente. El CCAPi hace juego al dial peer 0, que es la dial peer por default. Está correspondiendo con al dial peer 0 porque el CCAPi no podría encontrar a ningún otro dial peer para el número que llama, así que está utilizando a la dial peer por default.

*Mar 12 04:03:57.189: cc_api_call_setup_ind (vdbPtr=0x616C9F54, callInfo={called=3333, 
calling=1001, fdest=1 
peer_tag=0}, callID=0x616C4838)
*Mar 12 04:03:57.193: cc_process_call_setup_ind (event=0x617A2B18) handed call to app "SESSION"
*Mar 12 04:03:57.193: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(17), disp(0)
*Mar 12 04:03:57.193: ccCallSetContext (callID=0x11, context=0x61782BBC)
Mar 12 04:03:57.193: ssaCallSetupInd finalDest cllng(1001), clled(3333)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17) peer list: tag(1)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17), destPat(3333), matched(4), prefix(), peer(6179E63C)
*Mar 12 04:03:57.193: ccCallSetupRequest (peer=0x6179E63C, dest=, params=0x61782BD0 mode=0, 
*callID=0x617A87C0)
*Mar 12 04:03:57.193: callingNumber=1001, calledNumber=3333, redirectNumber=
*Mar 12 04:03:57.193: accountNumber=,finalDestFlag=1, 
guid=0098.89c8.9233.511d.0300.cddd.ac10.46e6

El CCAPi hace juego el dial-peer 1 con el diagrama de destinos, que es número al que se llamó los 3333. Recuerde que el peer_tag significa al dial peer. Note la llamada y el número de la parte llamada en el paquete de pedidos.

*Mar 12 04:03:57.193: peer_tag=1
*Mar 12 04:03:57.197: ccIFCallSetupRequest: (vdbPtr=0x617BE064, dest=, 
callParams={called=3333, calling=1001, 
fdest=1, voice_peer_tag=1}, mode=0x0)

La salida de los debugs siguiente muestra que los mensajes que alertan H.225 están volviendo al Cisco CallManager.

*Mar 12 04:03:57.197: ccCallSetContext (callID=0x12, context=0x61466B30)
*Mar 12 04:03:57.197: ccCallProceeding (callID=0x11, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_proceeding(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_alert(vdbPtr=0x617BE064, callID=0x12,
 prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: sess_appl: ev(17=CC_EV_CALL_PROCEEDING), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)
-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaIgnore cid(18), st(1),oldst(1), ev(17)
*Mar 12 04:03:57.201: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(1)cfid(-1)csize(0)in(0)fDest(0
)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaFlushPeerTagQueue cid(17) peer list: (empty)
*Mar 12 04:03:57.201: ccCallAlert (callID=0x11, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: ccConferenceCreate (confID=0x617A8808, callID1=0x11, callID2=0x12, tag=0x0)
*Mar 12 04:03:57.201: cc_api_bridge_done (confID=0x7, srcIF=0x616C9F54, srcCallID=0x11, 
dstCallID=0x12, 
disposition=0, tag=0x0)value H323-UserInformation
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-uu-pdu
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-message-body alerting :
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.205: destinationInfo
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: mc FALSE,
*Mar 12 04:03:57.205: undefinedNode FALSE
*Mar 12 04:03:57.205: },

Aviso en este paquete que el Cisco IOS también está enviando el direccionamiento H.245 y el número del puerto al Cisco CallManager. El Cisco IOS Gateway enviará a veces el direccionamiento inalcanzable, que podría causar no audio o el audio unidireccional.

*Mar 12 04:03:57.205: h245Address ipAddress :
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: ip 'AC1046E2'H,
*Mar 12 04:03:57.205: port 011008
*Mar 12 04:03:57.205: },
*Mar 12 04:03:57.213: Hex representation of the ALERTING TPKT to send.0300003D0100
*Mar 12 04:03:57.213:
*Mar 12 04:03:57.213: H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [1]. 
Call state changed to [Call 
Received].
*Mar 12 04:03:57.213: cc_api_bridge_done (confID=0x7, srcIF=0x617BE064, srcCallID=0x12,
 dstCallID=0x11, 
disposition=0, tag=0x0)

La salida de los debugs siguiente muestra que está subiendo la sesión H.245. Usted puede ver la indicación de capacidad para la negociación de códec, así como cuántos bytes estarán presentes en cada paquetes de voz.

*Mar 12 04:03:57.217: cc_api_caps_ind (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12,
 caps={codec=0xEBFB, 
fax_rate=0x7F, vad=0x3, modem=0x617C5720 codec_bytes=0, signal_type=3})
*Mar 12 04:03:57.217: sess_appl: ev(23=CC_EV_CONF_CREATE_DONE), cid(17), disp(0)
*Mar 12 04:03:57.217: ssa: cid(17)st(3)oldst(0)cfid(7)csize(0)in(1)fDest(1)
-cid2(18)st2(3)oldst2(1)
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

La salida de los debugs siguiente muestra que ambas partes negociaron correctamente y estuvieron de acuerdo con el codificador-decodificador de G.711 con 160 bytes de dato.

*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, 
srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

H.323 conecta y los mensajes de la desconexión se pueden considerar abajo.

*Mar 12 04:03:59.373: cc_api_call_connected(vdbPtr=0x617BE064, callID=0x12)
*Mar 12 04:03:59.373: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(18), disp(0)
*Mar 12 04:03:59.373: ssa: cid(18)st(4)oldst(1)cfid(7)csize(0)in(0)fDest(0)
-cid2(17)st2(4)oldst2(3)
*Mar 12 04:03:59.373: ccCallConnect (callID=0x11)
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-uu-pdu
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-message-body connect :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:59.373: h245Address ipAddress :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.377: ip 'AC1046E2'H,
*Mar 12 04:03:59.377: port 011008
*Mar 12 04:03:59.377: },
*Mar 12 04:03:59.389: Hex representation of the CONNECT TPKT to send.03000052080
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [1]
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
*Mar 12 04:04:08.769: cc_api_call_disconnected(vdbPtr=0x617BE064, callID=0x12, cause=0x10)
*Mar 12 04:04:08.769: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(18), disp(0)

Gateway del IOS de Cisco con interfaz T1/PRI

Según lo explicado anterior, hay dos tipos de llamadas que pasan a través de los gatewayes del Cisco IOS: el Cisco IOS Gateway interconecta al PSTN o al PBX, con las interfaces T1/CAS o T1/PRI. Los siguientes son las salidas de los debugs cuando la interfaz del uso T1/PRI de los gatewayes del Cisco IOS.

Han girado al comando debug isdn q931 en el Cisco IOS Gateway. Esto habilita el q.931, un Signaling Protocol de la capa tres para el canal D en el entorno ISDN. Cada vez que una llamada es interfaz puesta de los T1/PRI, un paquete de la configuración debe ser enviado. El paquete de la configuración tiene siempre (descriptor del protocolo) paladio = 8, y genera un valor hex al azar para el callref. El callref se utiliza para seguir la llamada. Por ejemplo, si se ponen dos llamadas, el valor del callref puede determinar la llamada para la cual se piensa el mensaje RX (recibido). La capacidad portadora 0x8890 significa una llamada de datos 64kb/s. Si fuera un 0x8890218F, sería una llamada de datos 56kb/s. Sería 0x8090A3 si era una llamada de voz. En la salida de los debugs abajo, la capacidad portadora es 0x8090A3, que está para la Voz. Parte que recibe la llamada y parte que la realiza los números también se muestran.

El callref utiliza un diverso valor para el primer dígito (para distinguir entre el TX y el RX) y el segundo valor es lo mismo (la CONFIGURACIÓN tenía a0 para el último pasado, y el CONNECT_ACK también tiene a0). El router es totalmente dependiente sobre el PSTN o el PBX asignar un canal portador (Canal B). Si el PSTN o el PBX no asigna un canal al router, la llamada no será ruteada. En nuestro caso, un mensaje CONNECT se recibe del Switch con el mismo número de referencia que fue recibido para ALERTAR (0x800B). Finalmente, usted puede ver el intercambio del mensaje DISCONNECT (Desconexión) seguido por los mensajes de la VERSIÓN y del RELEASE_COMP mientras que la llamada está siendo disconnected. Los mensajes del RELEASE_COMP son seguidos por una causa ID para el rechazo de llamada. La causa ID es un valor hex. El significado de la causa puede ser encontrado decodificando el valor hex y siguiendo con su proveedor.

*Mar 1 225209.694 ISDN Se115 TX -> SETUP pd = 8 callref = 0x000B
*Mar 1 225209.694 Bearer Capability i = 0x8090A3
*Mar 1 225209.694 Channel ID i = 0xA98381
*Mar 1 225209.694 Calling Party Number i = 0x2183, ?1001'
*Mar 1 225209.694 Called Party Number i = 0x80, ?3333'
*Mar 1 225209.982 ISDN Se115 RX <- ALERTING pd = 8 callref = 0x800B
*Mar 1 225209.982 Channel ID i = 0xA98381
*Mar 1 225210.674 ISDN Se115 RX <- CONNECT pd = 8 callref = 0x800B
*Mar 1 225210.678 ISDN Se115 TX -> CONNECT_ACK pd = 8 callref = 0x000B
*Mar 1 225215.058 ISDN Se115 RX <- DISCONNECT pd = 8 callref = 0x800B
*Mar 1 225215.058 Cause i = 0x8090 - Normal call clearing 225217 %ISDN-6
DISCONNECT Int S10 disconnected from unknown , call lasted 4 sec
*Mar 1 225215.058 ISDN Se115 TX -> RELEASE pd = 8 callref = 0x000B
*Mar 1 225215.082 ISDN Se115 RX <- RELEASE_COMP pd = 8 callref = 0x800B
*Mar 1 225215.082 Cause i = 0x829F - Normal, unspecified or Special intercept,
 call blocked group restriction 

Puerta de enlace de Cisco IOS con interfaz T1/CAS

Según lo explicado anterior, hay dos tipos de llamadas que pasan a través de los gatewayes del Cisco IOS: la interfaz del Cisco IOS Gateway al PSTN o al PBX, con las interfaces T1/CAS o T1/PRI. Los siguientes son las salidas de los debugs cuando los gatewayes del Cisco IOS tienen interfaz T1/CAS. El debug cas en el Cisco IOS Gateway se ha girado.

El mensaje siguiente del debug muestra que el Cisco IOS Gateway está enviando una señal de descolgado al Switch.

Apr 5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111) 

El mensaje siguiente del debug indica que el Switch está enviando el guiño después de recibir la señal del cierre de Loop del Cisco IOS Gateway.

Apr 5 17:58:21.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)
Apr 5 17:58:22.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)

El mensaje siguiente del debug indica que va el Cisco IOS Gateway descolgado.

Apr 5 17:58:23.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

Lo que sigue es la salida de la descripción de la voz activa de la llamada de la demostración en el Cisco IOS Gateway cuando la llamada está en curso. Números de origen/de destino de llamada y la otra información útil también se muestra.

R5300-5#show call active voice brief
<ID>: <start>hs.<index> +<connect> pid: <peer_id> <dir> <addr> <state> tx: <packets>/<bytes>
 rx:<packets>/<bytes>
<state>
IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late> 
delay:<last>/<min>/<max>ms <codec>
FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> sig:<on/off> <codec> (payload size)
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> (payload size) 
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
511D : 156043737hs.1 +645 pid:0 Answer 1001 active
tx:1752/280320 rx:988/158080
IP172.16.70.228:18888 rtt:0ms pl:15750/80ms lost:0/0/0 delay:25/25/65ms g711ulaw
511D : 156043738hs.1 +644 pid:1 Originate 3333 active
tx:988/136972 rx:1759/302548 
Tele 1/0/0 (30): tx:39090/35195/0ms g711ulaw noise:-43 acom:0 i/0:-36/-42 dBm

Señal de ocupado luego del marcado de números internacionales

Problema

El usuario tiene CM 2.4.4 con un modelo de la ruta apropiado asignado a su gateway DT-24+. Él puede marcar el local y los números de larga distancia E.E.U.U. sin los problemas. Sin embargo cuando él perfora los dígitos para un número internacional, él oye una pausa, y entonces una señal de ocupado.

Solución

Esto se ha visto en el pasado donde el switch CO no sabe ocuparse correctamente de la llamada IE (elemento de información). Esto puede ser reparada fijando a la parte llamadora del administrador de llamada que el tipo IE “fijó la llamada y el tipo llamado DN al desconocido” bajo parámetros del palmo DT24+.

Caso práctico III: Llamadas telefónicas de interagrupación de teléfono del IP de Cisco a teléfono del IP de Cisco

En los casos prácticos anteriores, el flujo de llamada y las técnicas de Troubleshooting de un llamada dentro del clúster y de una llamada del Cisco IP Phone con un Cisco IOS Gateway a un teléfono que colgaba apagado de un PBX local o en alguna parte en el PSTN se han discutido detalladamente. Este caso práctico examina un Cisco IP Phone que llama otro Cisco IP Phone situado en un clúster diferente. Conocen a este tipo de llamada también como llamada del Cisco IP Phone del inter-cluster.

Topología de ejemplo

Lo que sigue es la topología de ejemplo usada en este caso estudia. Esta topología tiene dos clusteres, cada uno que tiene dos CallManageres de Cisco. Hay también gatewayes del Cisco IOS y Cisco IOS Gatekeeper en el lugar.

/image/gif/paws/30266/ios_gatekeeper3.gif

Comunicación entre agrupaciones H.323

Como usted puede ver en la topología, el Cisco IP Phone en el cluster 1 está haciendo una llamada al Cisco IP Phone en la comunicación del Cisco CallManager del Inter-cluster del cluster 2. ocurre usando el protocolo de la versión 2 de H.323. Hay también Cisco IOS Gatekeeper para el control de admisión. La explicación detallada de la salida de los debugs y los comandos show, y la interacción entre el Cisco IOS Gatekeeper y Cisco IOS Gateway y los dispositivos Ciscos CallManageres, se pueden revisar en las secciones anteriores.

El proceso de flujo de llamada se muestra en el diagrama a continuación. El Cisco IP Phone puede hablar con el Cisco CallManager vía el Skinny Station Protocol, y el Cisco CallManager puede hablar con el Cisco IOS Gatekeeper que usa el protocolo RAS de H.323. El mensaje del pedido de admisión (ARQ) se envía al Cisco IOS Gatekeeper, que envía el mensaje del Admission Confirmed (ACF) después de aseegurarse que la llamada entre clústerss se puede hacer usando el protocolo de la versión 2 de H.323. Una vez que está hecho, el trayecto de audio se hace usando el protocolo RTP entre los Teléfonos IP de Cisco en diversos clusteres.

/image/gif/paws/30266/gatekeeper_flow.gif

Llamada de rastreo de flujos

Esta sección discute el flujo de llamada usando los ejemplos de seguimiento del SDI capturados en el archivo CCM000000000. La ubicación de este archivo se puede encontrar en la sección anterior. Las trazas discutidas en este caso estudian el foco solamente en el flujo de llamada sí mismo, porque la información de traza más detallada se ha explicado ya en el caso práctico anterior (inicialización, registro, el mecanismo de keepalive, y así sucesivamente.)

En este flujo de llamada, un Cisco IP Phone (2002) situado en el cluster 2 está llamando un Cisco IP Phone (1001) situado en el cluster 1. recuerda que usted puede seguir un dispositivo a través de la traza mirando el valor, el sello de fecha/hora, o el nombre de la manija TCP del dispositivo. El valor de la manija TCP para el dispositivo sigue siendo lo mismo hasta que se reinicie el dispositivo o va off-liné.

En las trazas siguientes, el Cisco IP Phone (2002) ha ido descolgado. La traza muestra los mensajes únicos, la manija TCP, y el número que llama, que se visualiza en el Cisco IP Phone. Número al que se llamó (1001), el H.225 conecta, y el H.245 confirma los mensajes se puede ver en la salida de los debugs siguiente. El tipo de códec es �-ley de G.711.

16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, 
CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x1c64310,
 Status=0, 
IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626

La llamada y el número de la parte llamada, que se asocia a una dirección IP y a un valor hex, se pueden considerar en las trazas siguientes.

16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310
 myIP: e74610ac 
(172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252) 

Las trazas siguientes muestran los tamaños de paquetes y la dirección MAC del Cisco IP Phone (2002). Estas trazas son seguidas por la desconexión, después los mensajes del en-gancho.

RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06
16:06:16.531 CCM|Locations:Orig=1 BW=64 Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to 
(64,2) and remove 
connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies, 
forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2)
 from connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310

Falló el flujo de llamadas

La sección siguiente describe un flujo fracasado de la llamada entre clústerss, como se ve en la traza del SDI. En las trazas abajo, el Cisco IP Phone (1001) ha ido descolgado. Una manija TCP se asigna al Cisco IP Phone.

16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampOn tcpHandle=0x4fbbc30

En las trazas siguientes el usuario es marca número al que se llamó (2000) del Cisco IP Phone, y el proceso de la análisis de dígitos está intentando hacer juego el número.

16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:33.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:36.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:36.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")

La análisis de dígitos ahora se ha completado y los resultados se muestran en las trazas siguientes. Es importante observar que la referencia de PotentialMatches=NoPotentialMatchesExist abajo indica que el Cisco CallManager no puede hacer juego este número de directorio. Finalmente, un Tono de reordenamiento se envía a la parte llamadora (1001), que es seguida por un mensaje del en-gancho.

16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=, 
CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Registros de detalles de llamadas

Esta sección proporciona la información detallada sobre los registros de detalles de la llamada (CDR) y el Call Management Records (CMR, también conocidos como CDR de diagnóstico).

Los registros CDR se escriben a una base de datos para el uso en las actividades del post-processing. Estas actividades incluyen muchas funciones, pero sobre todo las cargarán en cuenta y Análisis de red.

La base de datos es una base de datos del Microsoft SQL server 7.0. El acceso a la base de datos se puede hacer vía la Conectividad abierta de base de datos (ODBC).

El acceso se proporciona a todas las tablas en la base de datos en una moda solo lectura y a las tablas CDR y CMR en una moda de lectura/grabación.

Para utilizar los datos del registro CDR, usted puede querer leer otras tablas en la base de datos en un esfuerzo para obtener la información sobre el tipo de dispositivo que el CDR está alrededor. Esta correlación entre los dispositivos en la tabla de dispositivo y la dirección IP enumerada en el registro CDR no es directa y se enumera como problema conocido más adelante en esta sección.

Escritura de registros

El Cisco CallManager escribe los registros CDR a las bases de datos SQL como las llamadas se hacen de una forma constantes con la configuración de cada Cisco CallManager individual. Esta configuración se hace vía la pantalla de los parámetros de servicio en la administración del CallManager de Cisco.

Todos los expedientes se escriben a las bases de datos primarias para un cluster. Si las bases de datos primarias no están disponibles, los expedientes serán escritos a un de los otras bases de datos de backup. Una vez que las bases de datos primarias están disponibles, después los registros nuevos de la escritura continuarán en las bases de datos primarias y los expedientes local-escritos serán movidos al primario.

Lectura de registros

La manera más fácil a los leeres datos de las bases de datos SQL puede ser utilizar el ODBC. Una cadena de la conexión correcta parecería:

DRIVER= {SQL Server};SERVER=machineX;DATABASE=CCM0300

Esté seguro de utilizar el nombre de la base de datos correcto. Si una versión de la versión del CallManager de Cisco 3.0(1) del software está instalada sobre una instalación existente, la base de datos pudo ser emigrada si fue pedida por la nueva instalación. En este caso la vieja base de datos todavía existirá, y la nueva base de datos también existirá. Los nombres diferenciarán agregando uno al número del nombre. Por ejemplo, el nombre original es CCM0300. Después de una migración, el más nuevo nombre de la base de datos será CCM0301. La base de datos del número más elevado debe ser utilizada.

Las bases de datos primarias (máquina y nombre) funcionando por el cluster pueden ser encontradas actualmente haciendo clic en el botón Details Button de la administración del CallManager de Cisco (ayuda del tecleo para alcanzar la pantalla de bienvenida donde se localiza el botón Details Button). El registro en las máquinas que reciben una base de datos puede también ser marcado. Mire la clave de registro: \ \ HKEY_LOCAL_MACHINE \ software \ Cisco Systems Inc. \ DBL para el elemento llamó DBConnection0. Este elemento de la cadena contiene una cadena de conexión similar a ésa mostrada arriba con el nombre de la máquina y el nombre de la base de datos de las bases de datos primarias.

El acceso es controlado por medio de los usuarios SQL. La tabla siguiente especifica la identificación del usuario y contraseña que debe ser utilizada al acceder las base de dato del CallManager de Cisco.

Tablas ID de usuario SQL Contraseña Capacidad
CallDetailRecord, CallDetailRecordDiagnostic CiscoCCMCDR dipsy De lectura/grabación
(Otro) CiscoCCMReader vaqueros Read only

Eliminación de registros

Puesto que el Cisco CallManager está confiando en las aplicaciones de terceros para postprocesar los datos CDR, usted debe quitar los datos CDR cuando todas las aplicaciones se acaban con los datos. Puesto que esto implica el modificar de la base de datos, el usuario del CiscoCCMCDR debe ser utilizado.

Si los registros CDR acumulan a un Máximo configurado (10,000,000 registros CDR), los más viejos registros CDR serán quitados junto con los expedientes relacionados CMR una vez por el día.

Al quitar los datos CDR después del análisis, esté seguro de quitar todos los expedientes relacionados CMR, también.

Esquema de la tabla

La información detallada sobre el formato y el uso de cada campo en el CDR se proporciona más adelante en esta sección.

Las tablas primarias usadas son la tabla del CallDetailRecord (que lleva a cabo los registros CDR) y la tabla del CallDetailRecordDiagnostic (que lleva a cabo los expedientes CMR). La tabla del CallDetailRecord se relaciona con la tabla del CallDetailRecordDiagnostic vía las dos columnas, GlobalCallID_callManagerId, y GlobalCallID_callId de GlobalCallID. Puede haber más de un CMR por el CDR.

La tabla CallDetailRecord contiene información alrededor los puntos finales de la llamada y de otros aspectos del Control de llamadas/de la encaminamiento de la llamada. La tabla CallDetailRecordDiagnostic contiene información alrededor la calidad del audio fluido de la llamada.

Problemas conocidos

La versión del CallManager de Cisco 3.0(1) tiene varios problemas conocidos con los datos CDR. Algunos de éstos son mencionados abajo.

IP a la traducción del Nombre del dispositivo

La tabla CDR enumera los IP Addresses para los puntos finales de una llamada. Estos IP Addresses no se convierten fácilmente a los Nombres del dispositivo para poder determinar el tipo de dispositivo.

OnNet contra el OffNet

Es difícil saber si la llamada permanecía totalmente en la red del IP, o por lo menos interno al sistema local. Una pista es marcar el tipo de dispositivo de ambos extremos de la llamada. Si ambos son teléfonos, después usted puede asumir que permanecía OnNet. Sin embargo, si uno es un gateway, más suposiciones deben ser hechas. Si el gateway es un tipo del acceso analógico de dispositivo con los CRISOLES o puerto de estación, la llamada pudo apenas haber ido a un teléfono analógico local, o pudo haber salido al PSTN. Mire el número marcado y correlacione esto al Plan de marcado sabido de estimar si fue la llamada OffNet. Si no, la llamada fue probablemente OnNet.

Marcador de los dígitos OffNet

Si una llamada se pone hacia fuera un gateway, los dígitos marcados para conseguir al gateway pueden no ser los dígitos enviados al PSTN. El gateway puede ser inteligente y modificar el número de directorio más lejos. Si éste es el caso, el Cisco CallManager no sabe, y el CDR no reflejará los dígitos reales enviados OffNet.

Campos en un registro de detalles de llamadas

Esta sección define todos los campos en los registros actuales. Los tipos de campo son ésos usados por el Cisco CallManager, y no no necesariamente ésos definidos en el registro CDR en la base de datos. Las definiciones de campo de la base de datos son adecuadas salvar los datos, pero la interpretación de los datos debe tener en cuenta los tipos de campo definidos aquí.

Todo el Contenido no firmado es el Contenido no firmado 32bit.

Conversiones de datos de campo

Hay algunos campos que requieren la conversión del formato decimal a otro formato para las visualizaciones. Esta sección define sus valores, y cómo convertirlos o donde conseguir la información sobre cómo convertirlos.

Valores del tiempo

Todos los valores del tiempo se representan como 32 números enteros sin signo del bit. Este valor de Contenido no firmado se visualiza de la base de datos como entero con signo.

Este campo es un valor del time_t que se obtiene de las 2000) rutinas del sistema del Windows NT (. El valor es un valor del tiempo universal coordinado (UTC) y representa el número de segundos desde el 1 de enero de medianoche (de 00:00:00), 1970.

Desciframiento del sello de fecha/hora

Usando Microsoft Excel, usted puede escribir una fórmula para hacer convirtiendo este sello de fecha/hora un poco más fácil. Si el valor está en la célula A1, usted puede hacer otra célula:

=A1/86400+DATE(1970,1,1)

Hay 86400 segundos en un día.

Entonces, formate la célula resultante como campo de la fecha/de la hora en Excel.

Direcciones de IP

Todos los IP Addresses se salvan en el sistema como Contenido no firmado. La base de datos lo visualiza como enteros con signo. Para convertir el valor decimal firmado a una dirección IP, primero convierta el valor a un número hexadecimal (que toma en la consideración que es realmente un número no firmado). El valor hex 32bit representa cuatro bytes. Los cuatro bytes están en la orden inversa (estándar de Intel). Para conseguir la dirección IP, invierta la pedido de los bytes y convierta cada byte a un número decimal. Los cuatro bytes resultantes representan los campos del cuatro-byte de la dirección IP en la notación punteada.

Nota: La base de datos la visualiza como número negativo cuando el byte bajo de la dirección IP tiene el bit más significativo fijado.

Convertir los IP Addresses

  • Ejemplo 1:

    Por ejemplo, visualizarían a la dirección IP 192.168.18.188 como sigue:

    Visualización de la base de datos = -1139627840.

    Esto convierte a un valor hex de 0xBC12A8C0.

    Invierta los bytes hexadecimales = el C0A812BC

    CO A8 12 BC

    Los bytes convirtieron del hex. al decimal = 192 168 18 188, que serían visualizados como 192.168.18.188.

  • Ejemplo 2:

    Dirección IP 192.168.18.59

    Visualización de la base de datos = 991078592

    Esto convierte a un valor hex de 0x3B12A8C0

    Invierta el orden de bytes = C0A8123B

    C0 A8 12 3B

    Los bytes convirtieron del hex. al decimal = 192 168 18 59 que serían visualizados como 192.168.18.59.

Definición de campo CDR

La tabla siguiente proporciona las definiciones de campo para los CDR.

Definiciones de los campos
Campo Definición
cdrRecordType El tipo de este Contenido no firmado de registro especifica el tipo de este expediente específico. Podía ser una llamada de la llamada inicial record(0), del final record(1), o un CMR record(2).
más globalCallIdentifier El identificador de la llamada global el identificador de la llamada global consiste en dos campos que sean ambo Contenido no firmado. Los valores se deben tratar como Contenido no firmado. Los dos campos son: El Contenido no firmado GlobalCallID_CallManagerID de GlobalCallID_CallID del Contenido no firmado esto es el identificador de llamada que se asigna a la llamada entera. Todo registra asociado con una llamada estándar tendrá el mismo identificador de la llamada global.
más origLegCallIdentifier El Contenido no firmado del identificador de llamada del Tramo de origen esto es un Identificador único que se utiliza para seguir el Tramo de origen de una llamada. Es único dentro de un cluster.
dateTimeOrigination El Contenido no firmado de las creaciones de la fecha/de la hora de la llamada esto representa el tiempo que el dispositivo de origen de la llamada salió el gancho, o el tiempo que una llamada externa primero fue reconocida por el sistema (recibió el mensaje setup). El valor es un valor del tiempo universal coordinado (UTC), y representa el número de segundos desde el 1 de enero de medianoche (de 00:00:00), 1970.
origNodeId El Contenido no firmado del ID del nodo del terminal original este campo representa el nodo dentro del clúster del Cisco CallManager donde registraron al originador de la llamada a la hora de esta llamada.
origSpan El palmo del terminal original o el Contenido no firmado del puerto este campo contiene el número del puerto o del palmo del terminal original si la llamada originó a través de un gateway. Si no, este campo contiene cero (0).
callingPartyNumber El número de la parte llamadora hasta 25 caracteres esto es el número de directorio del dispositivo del cual la llamada originó.
origIpPort El Contenido no firmado del puerto IP de la parte llamadora este campo contiene el puerto IP del dispositivo del cual la llamada originó.
origIpAddr El Contenido no firmado de la dirección IP de la parte llamadora este campo contiene la dirección IP del dispositivo del cual la llamada originó.
originalCallingPartyNumberPartition La división de la parte llamadora hasta 50 caracteres este campo contiene la división asociada a la parte llamadora.
origCause_Location El Contenido no firmado del valor de ubicación de ISDN este campo contiene el valor de ubicación del elemento de información de causa.
origCause_Value La causa de la parte llamadora del Contenido no firmado de la terminación de llamada esta causa representa la razón que la llamada al dispositivo de origen fue terminada. En el caso de las transferencias, adelante, y así sucesivamente, la causa de la terminación de llamada puede ser diferente para el dispositivo de origen y el dispositivo de terminación. Así, hay dos campos de la causa asociados a cada llamada. Serán generalmente lo mismo.
origMediaTransportAddress_IP La dirección IP para el Contenido no firmado de la conexión de medios del terminal original esto es el IP Address de destino con el cual la secuencia de medios del terminal original fue conectada.
origMediaTransportAddress_Port El puerto para el Contenido no firmado de la conexión de medios del terminal original esto es el puerto destino con el cual la secuencia de medios del terminal original fue conectada.
origMediaCap_payloadCapability El tipo de códec utilizó por el Contenido no firmado del terminal original que este campo contiene el tipo de códec (compresión o tipo de carga útil) que el terminal original utilizó en el lado emisor durante esta llamada. Puede ser diferente que el tipo de códec usado en su lado de recepción.
origMediaCap_maxFramesPerPacket El número de milisegundos de los datos por el Contenido no firmado del paquete este campo contiene el número de milisegundos de los datos por el paquete enviado al destino, por el terminal original de esta llamada. Los tamaños de los datos reales dependen del tipo de códec que es utilizado para generar los datos.
origMediaCap_g723BitRate La velocidad de bits que se utilizará por el Contenido no firmado de G.723 define la velocidad de bits que se utilizará por G.723. Hay valores de velocidad de poca monta: 1 velocidad de bits y 2 =5.3K = velocidad de bits 6.3K.
lastRedirectDn El número de directorio del partido que dura reorientó esto llama a 25 caracteres que éste es el número de directorio del dispositivo más reciente que reorientó esta llamada. Este campo se aplica solamente a las llamadas que fueron reorientadas, por ejemplo las llamadas en conferencia, las llamadas reenviadas de la llamada, y así sucesivamente.
lastRedirectDnPartition La división del teléfono que dura reorientó esto llama a 50 caracteres que ésta es la división del dispositivo más reciente que reorientó esta llamada. Este campo se aplica solamente a las llamadas que fueron reorientadas por ejemplo las llamadas en conferencia, las llamadas reenviadas de la llamada, y así sucesivamente.
más destLegIdentifier El identificador de llamada para el tramo de destino del Contenido no firmado de la llamada esto es un Identificador único que se utiliza para seguir el tramo de destino de esta llamada. Es único dentro de un cluster.
destNodeId El identificador de nodo para el nodo donde estaba Contenido no firmado el destino de la llamada registrado el nodo dentro del clúster del Cisco CallManager donde el dispositivo de destino fue registrado a la hora de esta llamada.
palmo dest El Contenido no firmado del palmo o del puerto del destino este campo contiene el número del puerto destino o del palmo si la llamada fue terminada a través de un gateway. Si no, este campo contiene a (0) ceros.
destIpAddr La dirección IP a la cual la llamada era Contenido no firmado entregado este campo contiene la dirección IP de la conexión de la señalización en el dispositivo que terminó la llamada.
destIpPort El puerto IP al cual la llamada era Contenido no firmado entregado este campo contiene el puerto IP de la conexión de la señalización en el dispositivo que terminó la llamada.
originalCalledPartyNumber El destino recibió del originador de la llamada hasta 25 caracteres que este campo contiene el número de directorio al cual la llamada era originalmente extendida sobre la base de los dígitos marcó por el terminal original de la llamada. Si la llamada completa normalmente (significarla no fue remitida), este número de directorio debe siempre ser lo mismo que el “finalCalledPartyNumber”. Si la llamada fue remitida, este campo contiene el destino original de la llamada antes de que fuera remitido.
originalCalledPartyNumberPartition La división de la Parte llamada hasta 50 caracteres este campo contiene la división asociada a la Parte llamada.
finalCalledPartyNumber El destino al cual la llamada fue entregada hasta 25 caracteres este campo contiene el número de directorio al cual la llamada era realmente extendida. Si la llamada completa normalmente (significarla no fue remitida), este número de directorio debe siempre ser lo mismo que el “originalCalledPartyNumber”. Si la llamada fue remitida, este campo contiene el número de directorio del destino final de la llamada después de todo adelante fue completado.
finalCalledPartyNumberPartition La división se asoció al destino final de la llamada. hasta 50 caracteres este campo contienen la división asociada al destino al cual la llamada era realmente extendida. En una llamada normal, este campo debe ser lo mismo como “originalCalledPartyNumberPartition”. Si la llamada fue remitida, este campo contiene la división del destino final de la llamada después de todo adelante fue completado.
destCause_location El Contenido no firmado de la ubicación de la causa de la Parte llamada esto es el valor de ubicación de ISDN del elemento de información de causa.
destCause_value La causa de la Parte llamada del Contenido no firmado de la terminación de llamada esta causa representa porqué la llamada al dispositivo de terminación fue terminada. En el caso de las transferencias, adelante, y así sucesivamente, la causa de la terminación de llamada puede ser diferente para el beneficiario de la llamada y del terminal original de la llamada. Así, hay dos campos de la causa asociados a cada llamada. Serán generalmente lo mismo. Cuando una tentativa se hace para ampliar una llamada a un dispositivo ocupado se remita que, el código de la causa reflejará “ocupado” aunque la llamada fue conectada con un destino delantero.
destMediaTransportAddress_IP La dirección IP para el Contenido no firmado de la conexión de medios de salida de destino esto es la dirección IP de las creaciones de la cual la secuencia de medios del destino fue conectada.
destMediaTransportAddress_Port El puerto para el Contenido no firmado de la conexión de medios de salida de destino esto es el puerto del terminal original del cual la secuencia de medios del destino fue conectada.
destMediaCap_payloadCapability El tipo de códec utilizó por el destino en el Contenido no firmado del lado emisor que este campo contiene el tipo de códec (compresión o tipo de carga útil) que el destino utilizó en su lado emisor durante esta llamada. Puede ser diferente que el tipo de códec usado en su lado de recepción.
destMediaCap_maxFramesPerPacket El número de milisegundos de los datos por el Contenido no firmado del paquete este campo contiene el número de milisegundos de los datos por el paquete enviado al terminal original por el destino de esta llamada. Los tamaños de los datos reales dependen del tipo de códec que es utilizado para generar los datos.
destMediaCap_g723BitRate La velocidad de bits que se utilizará por el Contenido no firmado de G.723 define la velocidad de bits que se utilizará por G.723. Hay valores de velocidad de poca monta: 1 velocidad de bits y 2 =5.3K = velocidad de bits 6.3K.
dateTimeConnect La fecha/la hora de conecta el Contenido no firmado que ésta es la fecha y hora que la llamada fue conectada entre los dispositivos de origen y destino. El valor es un valor del tiempo universal coordinado (UTC), y representa el número de segundos desde el 1 de enero de medianoche (de 00:00:00), 1970.
dateTimeDisconnect Fecha/hora del Contenido no firmado de la desconexión éste es el tiempo que la llamada era disconnected entre los dispositivos de origen y destino, o en que la llamada fue derribada incluso si nunca fue conectada. El valor es un valor del tiempo universal coordinado (UTC), y representa el número de segundos desde el 1 de enero de medianoche (de 00:00:00), 1970.
duración Duración de la llamada éste es el número de segundos que la llamada fue conectada. Es la diferencia entre la fecha/la hora de conecta y la fecha/la hora de la desconexión.

Definiciones de campo CMR

La tabla siguiente proporciona las definiciones de campo para CMR (CDR de diagnóstico).

Definiciones de los campos
Campo Definición
cdrRecordType El tipo de este Contenido no firmado de registro especifica el tipo de este expediente específico. Será fijado al expediente CMR.
más globalCallIdentifier El identificador de la llamada global para esta llamada el identificador de la llamada global consiste en dos campos que sean ambo Contenido no firmado. Los valores se deben tratar como Contenido no firmado. Los dos campos son: El Contenido no firmado GlobalCallID_CallManagerID de GlobalCallID_CallID del Contenido no firmado esto es el identificador de llamada que se asigna a la llamada entera. Todo registra asociado con una llamada estándar tendrá el mismo identificador de la llamada global.
nodeID El identificador de nodo del Cisco CallManager el nodo dentro del clúster del Cisco CallManager donde este expediente fue generado.
más callIdentifier El Contenido no firmado del identificador de llamada esto es un identificador del tramo de llamada que identifica a qué tramo de llamada pertenece este expediente.
directoryNum El número de directorio usado en esta llamada esto es el número de directorio del dispositivo del cual estos diagnósticos fueron recogidos.
directoryNumPartition La división asociada al número de directorio esto es la división del número de directorio en este expediente.
dateTimeStamp La terminación de la fecha/de la hora de la llamada esto representa la hora aproximada que el dispositivo fue en el gancho. El tiempo se pone en el expediente cuando el teléfono responde a una petición la información de diagnóstico. Esto es un valor del time_t.
numberPacketsSent El número de paquetes envió el número total de paquetes de datos RTP transmitidos por el dispositivo desde comenzar la transmisión en esta conexión. El valor es cero si la conexión fue fijada en el modo sólo recibir.
numberOctetsSent El número de octetos (bytes) de los datos enviados al otro va de fiesta el número total de octetos de carga útiles (es decir, no incluyendo la encabezado o el relleno) transmitidos en los paquetes de datos RTP por el dispositivo desde comenzar la transmisión en esta conexión. El valor es cero si la conexión fue fijada en el modo sólo recibir.
numberPacketsReceived El número de paquetes de datos recibidos durante esta llamada que el número total de paquetes de datos RTP recibió por el dispositivo desde comenzar a la recepción en esta conexión. La cuenta incluye los paquetes recibidos de las diferentes fuentes si esto es una llamada de multidifusión. El valor es cero si la conexión fue fijada en el modo sólo enviar.
numberOctetsReceived El número de octetos (bytes) de los datos recibidos durante esta llamada el número total de octetos de carga útiles (es decir, no incluyendo la encabezado o el relleno) recibió en los paquetes de datos RTP por el dispositivo desde comenzar a la recepción en esta conexión. La cuenta incluye los paquetes recibidos de las diferentes fuentes, si esto es una llamada de multidifusión. El valor es cero si la conexión fue fijada en el modo sólo enviar.
numberPacketsLost Paquetes RTP perdidos durante esta conexión el número total de paquetes de datos RTP que se han perdido desde el principio de la recepción. Este número se define como el número de paquetes esperados, menos el número de paquetes recibidos realmente, donde el número de paquetes recibidos incluye cualquiera que es atrasado o duplica. Así, los paquetes que llegan tarde no se cuentan según lo perdido, y la pérdida pueden ser negativos si hay duplicados. El número de paquetes esperados se define para ser el número de secuencia más reciente extendido recibido, como definido después, menos el número de secuencia inicial recibido. El valor es cero si la conexión fue fijada en el modo sólo enviar. (Para los detalles, vea el RFC 1889)
jitter La fluctuación entre llegadas durante esta conexión una estimación de las variaciones estadísticas del tiempo entre llegadas del paquete de datos RTP, medidas en los milisegundos y expresadas como Contenido no firmado. La fluctuación entre llegadas J se define para ser la desviación promedio (valor absoluto alisado) de la diferencia D en el espaciamiento del paquete en el receptor comparado al remitente para un par de paquetes. Los algoritmos detallados del cómputo se encuentran en el RFC 1889. El valor es cero si la conexión fue fijada en el modo sólo enviar.
tiempo de espera El tiempo de espera experimentó durante esta conexión que el valor es una estimación de la latencia de red, expresada en los milisegundos. Éste es el valor promedio de la diferencia entre el grupo fecha/hora del Network Time Protocol (NTP) indicado por los remitentes de los mensajes RTP Control Protocol (RTCP) y el sello de fecha y hora del NTP de los receptores, medido cuando se reciben estos mensajes. La media es obtenida sumando todas las estimaciones, después dividiendo por el número de mensajes RTCP se han recibido que. (Para los detalles véase la Solicitud de comentarios (RFC) 1889)

Registros de llamadas detallados por tipo de llamada

Cada llamada normal entre dos partidos registra un registro de finalización de llamadas CDR. Cada registro de finalización de llamadas contiene todos los campos identificados arriba, pero algunos campos no pueden ser utilizados. Si un campo no se utiliza, será en blanco si es un campo de la cadena de ASCII, o el "0" si es un campo numérico. Cuando los servicios suplementarios están implicados en una llamada, más registros de finalización de llamadas pueden ser escritos.

Además del registro de finalización de llamadas CDR, puede haber hasta un registro CMR por punto final implicado en una llamada. En una llamada normal entre dos partidos cada uno usando un Cisco IP Phone, habrá dos expedientes CMR escritos: uno para el terminal original y uno para el destino de la llamada.

Esta sección describe los expedientes escritos para diversos tipos de llamada en el sistema.

Llamadas normales (teléfono del IP IP Teléfono-a-Cisco de Cisco)

Las llamadas normales registran tres expedientes por la llamada. Son EndCall más dos registros de diagnóstico, uno para cada punto final. En el expediente de EndCall, todos los campos pueden contener la información válida. La duración será siempre no-cero a menos que se habilite el indicador del “CdrLogCallsWithZeroDurationFlag” (fije para verdad). El campo originalCalledPartyNumber contendrá el mismo número de directorio que el campo "finalCalledPartyNumber".

Llamadas abandonadas

El registro de las llamadas con la duración cero es opcional. Normalmente, estos expedientes no serán registrados. Si se habilita la registración de las llamadas con la duración cero, las cosas siguientes deben ser observadas.

  • Si la llamada fue abandonada (por ejemplo cuando un teléfono es gancho sacado y colocado detrás en el gancho), los diversos campos no contendrán los datos. En este caso, el “originalCalledPartyNumber,” “finalCalledPartyNumber,” las divisiones asociadas a ellos, al “destIpAddr,” y a los campos del dateTimeConnect será en blanco. Todas las llamadas que no fueron conectadas tendrán una “duración” de los ceros segundos. Cuando se abandona una llamada, el código de la causa es el "0".

  • Si el usuario marcara un número de directorio y después abandonara la llamada antes de que fuera conectada, los campos “primer Dest” y “Dest final” y sus divisiones asociadas contendrán el número de directorio y la división a los cuales la llamada habría sido ampliada. El campo "IP de escritorio" será en blanco, y la duración será cero.

Llamadas remitidas o reorientadas

Los registros de llamada para las llamadas reenviadas serán lo mismo que ésos para las llamadas normales a excepción del campo originalCalledPartyNumber y de los campos del “originalCalledPartyNumberPartition”. Estos campos contendrán el número de directorio y la división para el destino que fue marcado originalmente por el terminal original de la llamada. Si la llamada fue remitida, los campos del “finalCalledPartyNumber” y del “finalCalledpartyNumberPartition” serán diferentes y contendrán el número de directorio y la división del destino final de la llamada. También, cuando se remite una llamada, los campos del “lastRedirectDn” y del “lastRedirectDnPartition” contendrán el número de directorio y la división del teléfono más reciente que remitió o reorientó esta llamada.

Llamadas con los destinos ocupados o malos

Estas llamadas serán registradas como llamada normal con todos los campos relevantes que contienen los datos. El campo de la causa de la Parte llamada contendrá un código de la causa que indica porqué la llamada no fue conectada, y el IP de la Parte llamada y la fecha/la hora conectan los campos serán en blanco. Si el terminal original abandonó la llamada, la causa estará “NO_ERROR” (0). La duración será siempre ceros segundos. Estas llamadas no serán registradas a menos que se habilite el “CdrLogCallsWithZeroDurationFlag”.

Administración de llamadas detalladas por tipo de llamada

Cada llamada normal entre dos registros de los Teléfonos IP de Cisco exactamente dos expedientes CMR. Cada expediente de la llamada CMR contiene todos los campos identificados arriba. Cuando los servicios suplementarios están implicados en una llamada, más de un expediente puede ser escrito. Esta sección describe cuando los registros de diagnóstico se escriben para diversos tipos de llamada en el sistema.

Llamadas normales

Las llamadas normales registran exactamente dos expedientes CMR por la llamada, una para cada teléfono implicado en la llamada. Actualmente, solamente los Teléfonos IP de Cisco y los gatewayes MGCP son capaces de la respuesta a la petición de la información de diagnóstico. Todos los campos contendrán la información válida.

Llamadas abandonadas

Si la llamada fue abandonada (por ejemplo cuando un teléfono se toma descolgado y se coloca detrás en el gancho), toda coloca relacionado a fluir los datos será el espacio en blanco (cero). Esto es porque no se estableció ninguna conexión que fluía, y por lo tanto no se transfirió ningunos datos. No se registrará ningunos expedientes con los campos vacíos si se inhabilita el “CdrLogCallsWithZeroDurationFlag”.

Llamadas reenviadas

Los registros de llamada para las llamadas reenviadas serán lo mismo que ésos para las llamadas normales.

Llamadas con los destinos ocupados o malos

En el caso normal, solamente los expedientes que representan las llamadas que fueron conectadas realmente serán registrados. Para registrar las llamadas con los malos destinos, usted debe habilitar el “CdrLogCallsWithZeroDurationFlag.” Si se habilita, después todas las llamadas serán registradas incluyendo el caso adonde descolgado y después va el usuario en-gancho otra vez.

Si se registran las llamadas, serán registradas como llamadas normales con todos los campos relevantes que contienen los datos. Habrá solamente un expediente por la llamada puesto que las llamadas nunca fueron conectadas con un destino. El expediente estará para el terminal original de la llamada.

Tipos de codec (tipos de carga útil/compresión)

La tabla siguiente proporciona los valores y las descripciones para los tipos de códec.

Descripción del códec
Códec Descripción
1 No estándar
2 G711A-law 64k
3 56K G711A-law
4 G711�-law 64k
5 56K G711�-law
6 G722 64k
7 56K G722
8 G722 48k
9 G7231
10 G728
11 G729
12 G729AnnexA
13 Is11172AudioCap
14 Is13818AudioCap
15 G729AnnexB
32 Datos 64k
33 56K de los datos
80 GS
81 ActiveVoice
82 G726_32K
83 G726_24K
84 G726_16K

Códigos de causas

La tabla siguiente proporciona una lista de códigos de la causa que puedan aparecer en los campos de la causa.

Descripciones del código de la causa
Código de la causa Descripción
0 Ningún error
1 Número (no asignado) Unallocated
2 Ninguna ruta al transit network especificado (uso nacional)
3 No hay ruta para el destino
4 Enviar tonos especiales de información
5 Prefijo del tronco Misdialed (uso nacional)
6 Canal no aceptable
7 Llamada concedida y que es entregada en un canal establecido
8 Prioritario
9 Derecho preferente de compra - circuito reservado para la reutilización
16 Verificación normal de llamadas
17 Usuario ocupado
18 Sin respuesta de usuarios
19 Ninguna respuesta del usuario (usuario alertado)
20 Suscriptor ausente
21 Llamada rechazada
22 Número cambiado
26 Verificación de usuarios no seleccionados
27 Destino no disponible
28 Formato de número inválido (direccionamiento incompleto)
29 Recurso rechazado
30 Respuesta a STATUS ENQUIRY (consulta de estado)
31 Normal, sin especificar
34 Ningún circuito/canal disponible
38 Red no disponible
39 Conexión de modo de trama permanente fuera de servicio
40 Conexión de modo trama permanente operativa
41 Falla temporal
42 Congestión del equipo de switching
43 Información de acceso descartada
44 Circuito/canal requerido no disponible
46 Llamada de la precedencia bloqueada
47 Recurso inasequible, sin especificar
49 Calidad de servicio no disponible
50 Prestación solicitada no disponibe (requiere suscripción)
53 Operación de servicio violada
54 llamadas entrantes bloqueadas
55 Llamadas entrantes barradas dentro del Grupo de usuarios cerrado (CUG)
57 Capacidad portadora no autorizada
58 Capacidad portadora no disponible actualmente
62 Inconsistencia en la clase saliente señalada de la información de acceso y del suscriptor
63 Servicio y opción disponible sin especificar
65 Capacidad portadora no implementada
66 Tipo de canal no implementado
69 Recurso solicitado no implementado
70 Solamente la capacidad portadora restricta de la información digital está disponible (el uso nacional)
79 Servicio u opción no implementada, sin especificar
81 Valor de referencia de llamada inválido
82 No existe el canal identificado
83 Una llamada suspendida existe, pero esta identidad de la llamada no hace
84 Identidad de la llamada funcionando
85 No se suspenden llamadas
86 La llamada que tenía la identidad de la llamada pedida se ha borrado
87 Miembro del usuario no del Grupo de usuarios cerrado (CUG)
88 Destino incompatible
90 Desaparecidos y DC del número de destino no inscritos
91 Selección inválida del transit network (uso nacional)
95 Mensaje no válido, no especificado
96 El elemento de información obligatoria falta
97 Tipo de mensaje inexistente o no implementado
98 El mensaje no es compatible con el estado de la llamada, o el Tipo de mensaje es inexistente o no implementado
99 Un elemento de información o un parámetro no existe ni se implementa
100 Contenido de elemento de información no válido
101 El mensaje no es compatible con el estado de la llamada
102 La llamada fue terminada cuando expiró un temporizador y una rutina de recuperación fue ejecutada para recuperarse del error
103 Parámetro inexistente o no implementado - pasado en (uso nacional)
110 Mensaje con parámetro no reconocido desechado
111 Error de protocolo sin especificar
126 Fractura de la llamada. Esto es un código del Cisco específico. Se utiliza cuando una llamada se termina durante una operación de transferencia porque estuvo partida apagado y terminada (no estaba la parte de la llamada transferida final). El puede ayudar a determinar que las llamadas fueron terminadas como parte de una operación de transferencia.
127 Interconexión, sin especificar

Alarmas

Se publica una alarma cuando se habilita el CDR o los datos diagnósticos, y el sistema no puede escribir los datos en la base de datos.

Incapaz de escribir los datos CDR. (Alarma # 1711 - Alarma grave)

El sistema frustrado para abrir la base de datos, y era fracasado. Las causas probables incluyen:

  • El Cisco CallManager no tiene privilegios suficientes de abrir el archivo para escribir a la base de datos. Aseegure el Cisco CallManager tiene privilegios que permitan escriban las operaciones.

  • La trayectoria no se configura, o el servidor de bases de datos está abajo.

Llamar al Centro de la asistencia técnica de Cisco (TAC)

Si usted tiene un problema que no se pueda resolver con su propio troubleshooting, llame por favor TAC para la ayuda. Antes de llamar TAC, tenga la siguiente información disponible:

  • Detalles del Cisco CallManager

  • Topología

  • Los registros y le localizan se han ejecutado durante el troubleshooting, incluyendo las trazas del SDI y SDL

  • Stackwalk.txt clasifía del directorio WINNT\system32 y seguimiento del CallManager del sub-directório

  • sh-tecnología en los gatewayes del Cisco IOS, si procede

  • sh-tecnología en el Cisco CallManager

  • Si el problema está con las llamadas con un Cisco IOS Gateway, también proporcione por favor:

    • haga el debug del inout del ccapi de la Voz

    • debug isdn q931

    • solamente] xboard sh del vfc [AS5300

    • [AS5300 solamente] versión dspware sh del vfc x

    • [AS5300 solamente] versión vcware sh del vfc x

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: 30266