Embed Size (px)
Citation preview
Guía para Troubleshooting de Cisco IPTelephony para el Cisco CallManager Release3.0(x)
Contenido
IntroducciónprerrequisitosRequisitosComponentes UtilizadosConvencionesAntecedentesTopologíaGlosario de términosHerramientas y utilidades para supervisar y solucionar problemas en CallManagerDetalles de administración de Cisco CallManagerRendimiento de MicrosoftMicrosoft Event ViewerRastro de SDIRastro de SDL‘Rastro del sabuesoRegistros de detalles de llamadas (CDR) y registros de administración de llamadas (CMR)Resolución de problemas del CallManager con Windows NT e Internet Information Server (IIS)Calidad de vozRestauraciones de teléfonoLlamadas interrumpidasProblemas de Funciones del Cisco CallManagerRespuesta lenta del servidorReordenar el tono a través de los gatewaysProblemas con el registro de la gatewayProblemas del control de accesoSeñal de ocupado rápido al marcar el número piloto del VoicemailCaso práctico I: Llamadas de Cisco IP Phone a Cisco IP Phone dentro de un agrupamientoTopología de ejemploProceso de inicialización de Cisco IP PhoneProceso de registro de estación delgadaFlujo de llamadas de un teléfono del IP de Cisco a otro teléfono del IP de Cisco en unagrupamientoIntercambio de mensajes de estaciones “delgadas” entre teléfonos IP de Cisco durante el flujo dellamadas
Proceso de Inicialización del Cisco CallManagerProcesos de inicio automáticoProceso de Registro del Cisco CallManagerProceso de señal de mantenimiento de Cisco CallManagerSeguimiento del Flujo de Llamadas dentro del Cluster del Cisco CallManagerCaso práctico II: Llamadas de teléfono del IP de Cisco a la puerta de enlace de Cisco IOSTopología de ejemploLlamada de rastreo de flujosMensajes de depuración y Comandos show de Cisco IOS GatekeeperMensajes de depuración y comandos show en la gateway del IOS de CiscoGateway del IOS de Cisco con interfaz T1/PRIPuerta de enlace de Cisco IOS con interfaz T1/CASSeñal de ocupado luego del marcado de números internacionalesCaso práctico III: Llamadas telefónicas de interagrupación de teléfono del IP de Cisco a teléfonodel IP de CiscoTopología de ejemploComunicación entre agrupaciones H.323Llamada de rastreo de flujosFalló el flujo de llamadasRegistros de detalles de llamadasEscritura de registrosLectura de registrosEliminación de registrosEsquema de la tablaProblemas conocidosCampos en un registro de detalles de llamadasRegistros de llamadas detallados por tipo de llamadaAdministración de llamadas detalladas por tipo de llamadaTipos de codec (tipos de carga útil/compresión)Códigos de causasAlarmasLlamar al Centro de la asistencia técnica de Cisco (TAC)Información Relacionada
Introducción
Esta guía de troubleshooting describe las herramientas y utilidades usadas para configurar,monitorear y resolver problemas de Cisco CallManager Release 3.0(1), gateways Cisco IOS® ygatekeeper. 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 CiscoIOS Gateway a un teléfono conectado con un PBX local o en el Public Switched TelephoneNetwork (PSTN). En el tercer caso práctico, un Cisco IP Phone llama otro Cisco IP Phone en unclúster diferente (llamada entre clústers).
Una vez que usted entiende el flujo de llamada y hace el debug de las trazas, será más fácil aislarun problema y determinar qué componente está causando el problema. Este documento describelas herramientas disponibles para resolver problemas los problemas potenciales. Tambiéndescribe cómo los Seguimientos de llamada y las salidas de los debugs pueden ayudarle aentender 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 datosrequeridos por TAC. La solución de problemas será más rápida si usted ha recopilado ya estosdatos antes de llamar TAC.
prerrequisitos
Requisitos
Utilice la lista de verificación siguiente para estar seguro que usted tiene la documentaciónapropiada en su topología de red.
Topología que muestra todos los dispositivos de red y componentes críticos con el puerto/losNúmeros de interfaz a los cuales los asocian y a qué VLA N pertenecen (si procede). Lasdesignaciones especiales se deben utilizar para los puertos que están en el enlace o el modode canalización.
●
La raíz del atravesar-árbol debe ser configurada y todos los puertos de normal-bloqueo debenser identificados.
●
Cualquier circuito PÁLIDO se debe identificar con la cantidad del ancho de banda (CIR en elcaso del Frame Relay).
●
Nota: El Cisco IP Phone 7960 tiene un puerto de red 10/100-switched y un puerto de PC de10/100. Cisco no soporta los teléfonos de “conexión en cascada” apagado del puerto de PC. Norecomendamos el asociar de la red y de los puertos de PC a un Switch (de tal modo que crea unloop físico en la red).
Cualquier interfaz de WAN requerirá la Consideración especial, puesto que ésta es una fuentepotencial de congestión. Los Teléfonos IP y los gatewayes de Cisco fijan el campo deprecedencia IP de la secuencia del Real-Time Transport Protocol (RTP) a cinco, no obstante éstemarca solamente el paquete RTP con etiqueta. Incumbe hasta el administrador de la red paraasegurarse de que la red está configurada para el priorización y el control de admisión dellamadas para poder mantener el tráfico de la voz sobre IP (VoIP) con el retraso mínimo y lacontención de los recursos. Para más información sobre este tema, refiérase:
Página de soporte del administrador de las Comunicaciones unificadas de Cisco●
Página de soporte de la Calidad de voz●
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y dehardware.
La información que se presenta en este documento se originó a partir de dispositivos dentro de unambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento sepusieron 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 deejecutarlo.
Nota: Todas las discusiones en este documento se escriben para la versión del CallManager deCisco 3.0(1), salvo que se indique lo contrario.
Convenciones
Para obtener más información sobre las convenciones del documento, consulte Convenciones deConsejos Técnicos de Cisco.
Antecedentes
Topología
Usted debe tener una topología de red exacta que contiene los puertos con los cuales losdiversos componentes están conectados, por ejemplo los VLA N, Routers, Switches, losgatewayes, y así sucesivamente. Una topología bien documentada ayuda al resolver problemaslos problemas con el sistema. Esté seguro que usted tiene una topología precisa, junto con elacceso a todos los dispositivos de red y servicios de terminal para la Administración del CiscoCallManager.
La planificación importante se requiere para agregar con éxito la Telefonía IP a un nuevo o a unared 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 concualquier red que lleve el tráfico crítico, es imprescindible que el administrador de la red mantieneexacto, los diagramas detallados de la topología de red. En una situación de crisis es importanteconocer no apenas la descripción general amplia de la red, pero también que los puertos estánconectados 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 elscalability en la mente.
Precaución: Cisco no soporta el uso de las hub para conectividades compartida al Switches. ElHubs 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 (parala 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ónimos comunes que se pueden utilizar en estedocumento.
GlosarioSiglas/término
Definición
.cnf Archivo de configuración usado por losdispositivos.
ley del Técnica de compresión de uso general en
µ (“Mu-law”)
Norteamérica. la ley del µ se estandardiza comocodificador-decodificador 64-kbps en ITU-TG.711.
Ley A
Estándar de compresión ITU-T usado en laconversión entre las señales analógicas ydigitales en los sistemas del Modulación decódigo por impulsos (PCM). La ley A se utilizasobre todo en las redes telefónicas europeas yes similar al estándar norteamericano de la leydel µ.
ACF Admission Confirm.ANI El número que llama.ARQ Pedido de admisión.
CanalB
Canal portador. En el ISDN, esto es un FULL-duplex, el canal 64-kbps usado para enviar losdatos del usuario.
CallingSearchSpace
El Calling Search Space define que los númerosde directorio y los patrones de ruta undispositivo dado pueden llamar. Es el agrupar delas divisiones a través de las cuales mirar alhacer una llamada. Por ejemplo, asuma que hayvarias divisiones en un Calling Search Spaceque se nombran “ejecutivo.” En este ejemplo, unnúmero telefónico de Cisco IP está en el CallingSearch 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 quetiene un Calling Search Space del “invitado”, porejemplo, se pudo permitir solamente buscar através del “NYLocalCall” y de las divisiones del"NY911". Por lo tanto, si el usuario intentamarcar un número internacional, el número noencontrará que una coincidencia y la llamada noserán ruteadas.
CCAPi Control de llamada API. Utilizado por el CiscoIOS para manejar el proceso de llamada VoIP.
CCO
Cisco Connection Online (http://www.cisco.com).Proporciona la información más reciente sobrelos Productos Cisco, la información de soportetécnico, y la Documentación técnica.
CDR
Registro de detalles de la llamada. Proveeinformación sobre el origen de la llamada, eldestino, y la duración. Esto se utiliza para crearlos registros de facturación.
IOS deCisco
Software del sistema de Cisco que proporcionala funcionalidad habitual, el scalability, y laSeguridad para todos los Productos bajoarquitectura de CiscoFusion. El Cisco IOS
permite instalación y administración deconexiones entre redes centralizada, integrada,y automatizada, mientras que asegura el soportepara una amplia variedad de protocolos, losmedia, los servicios, y las Plataformas.
ClusterClúster del Cisco CallManager. Unagrupamiento lógico de vario Cisco Callmanagerservers.
CMR
Call Management Records, también conocidocomo CDR de diagnóstico. Éstos son losexpedientes que contienen la cuenta de losbytes enviados, los paquetes enviados, jitter,tiempo de espera, los paquetes perdidos, y asísucesivamente.
códec
Decodificador del codificador. Un algoritmo desoftware de la parte específica del dominio(DSP) usado para comprimir/descomprime eldiscurso o las señales de audio.
CanalD
Canal de datos. Canal del Full-duplex, 16-kbps(BRI) o 64-kbps (PRI) ISDN. Utilizado paraseñalar y el control.
DCF El desembarazo confirma.
DHCP
Protocolo DHCP. Proporciona un mecanismopara afectar un aparato los IP Addressesdinámicamente para poder reutilizar losdireccionamientos cuando los host los necesitanno más.
DN
Número de directorio. Éste es el número deteléfono de un dispositivo extremo. Puede ser unnúmero asignado a un Cisco IP Phone, a unCisco IP SoftPhone, a la máquina de fax, o alteléfono analógico asociado a un gateway. Losejemplos incluyen 1000 y 24231.
DNIS Dialed Number Identification Service.
DNS
Sistema de nombres de dominio (DNS). Éste esel sistema usado en Internet para traducir losnombres de los nodos de red en losdireccionamientos.
DRQ Pedido de desconexión.
DTMFTono dual de múltiples frecuencias. Éste es eluso de dos tonos simultáneos de la banda devoz para marcar (tal como de "touch tone").
Flujo
Un flujo de datos que viaja entre dos puntosfinales a través de una red (a partir de unaestación LAN a otra, por ejemplo). Es posibletransmitir múltiples flujos en un solo circuito.
Full-duplex
La capacidad para la transmisión de datossimultánea de una estación remitente y de unaestación receptora.
G.711
Describe la técnica de codificación de voz 64-kbps PCM. En G.711, la voz codificada está yaen el formato correcto para la entrega de vozdigital en el PSTN o con los PBX. Esto sedescribe en el estándar ITU-T en susrecomendaciones Serie G.
G.729
Describe la compresión de predicción linealactivada por código (CELP) donde la Voz secifra en las secuencias 8-kbps. Hay dosvariaciones de este estándar (G.729 y G.729adjuntan A) que diferencie principalmente en lacomplejidad informática; ambos proporcionan lacalidad vocal similar a la modulación de códigode impulso diferencial adaptable 32-kbps(ADPCM). Esto se describe en el estándar ITU-Ten sus recomendaciones Serie G.
H.225
Un estándar de ITU que gobierna elestablecimiento de sesión H.225 y elpacketization. El H.225 describe realmentevarios diversos protocolos: RAS, el uso delq.931, y el uso del RTP.
H.245 Un estándar de ITU que gobierna el control depunto final H.245.
H.323
Una extensión del ITU-T H.320 estándar quehabilita la Videoconferencia sobre los LAN yotras redes conmutadas por paquetes, así comovídeo sobre Internet.
Halfduplex
La capacidad para la Transmisión de datos ensolamente un en un momento de la direcciónentre una estación remitente y una estaciónreceptora. La Comunicación sincrónica binaria(BSC) es un ejemplo de un protocolosemidúplex.
Hookflash
Un período corto del en-gancho, generadogeneralmente por a teléfono-como el dispositivodurante una llamada, para indicar que elteléfono está intentando realizar unaconfirmación del tono de marcado de un PBX. Elhookflash es de uso frecuente realizar latransferencia de llamada.
ICCP Control Protocol del Intra-cluster
ISDN
Integrated Services Digital Network. UnCommunication Protocol, ofrecido por lascompañías telefónicas, que permiten que lasredes telefónicas lleven los datos, expresa, y elotro tráfico de origen.
Fluctuación
La variación en las horas de llegada depaquetes de voz.
MGCP(Protoc
Media Gateway Control Protocol. Un protocolopara que Cisco CallManager controle los
olo decontroldegateway demedios)
gatewayes de VoIP (puntos finales del MGCP).
MTP Media Termination Point.
División
Una división es un agrupamiento lógico de losnúmeros de directorio (DN) y de los patrones deruta con las características de alcance similares.Para la simplicidad, éstos se nombrangeneralmente para su característica, tal como“NYLongDistance”, el "NY911", y asísucesivamente. Cuando ponen un DN o a unpatrón de ruta en cierta división, éste crea unaregla para quién puede llamar esa lista deldispositivo o de la ruta.
PBX
Intercambio de central privada. Centraltelefónica analógica o digital situada en lasinstalaciones del suscriptor y usada paraconectar el soldado y las redes de telefoníapública.
PRI
Interfaz de la velocidad primaria. El acceso develocidad primaria consiste en un solo 64-Kbpscanal D más 23 (T1) o 30 canales B (del e1)para la Voz o los datos.
PSTN
Public Switched Telephone Network. Términogeneral que refiere a la variedad de redestelefónicas y de servicios en el lugar por todo elmundo.
Q.931
Estándar de ITU que describe la señalizaciónISDN. El estándar H.225.0 utiliza una variantedel q.931 para establecer y para desconectar lassesiones de H.323.
RAS
Protocolo de registración, admisión y estado.Éste es el protocolo usado en el Conjunto deprotocolos de H.323 para descubrir y obrarrecíprocamente con un portero.
Filtrode laruta
Un filtro de la ruta se puede utilizar no sólo pararestringir la marca, pero también para identificarun subconjunto de un patrón comodín (al usar @al comodín en el plan de marcado de américadel norte). Por ejemplo, podría ser utilizado parabloquear la marca de 900 códigos de área. En lapoder también utilícese conjuntamente con lasdivisiones y el Calling Search Spaces paraconfigurar las reglas complejas. Por ejemplo,asuma que usted tiene tres grupos de usuariosestablecidos: Ejecutivo, personal, e invitado. Unfiltro de la ruta puede permitir que el Grupo de
usuarios ejecutivo marque los númerosinternacionales, el grupo de usuario del personalpara marcar los números locales o las llamadasde larga distancia, y al grupo de usuariosinvitados para marcar solamente 911, y 800 losnúmeros de los números locales.
GrupodeRoutes
Un Grupo de Routes es una lista de uno o másgatewayes o puertos en los gatewayes que seven como acceso equivalente. Es análogo a ungrupo troncal en terminología de PBXtradicional. Por ejemplo, usted puede tener doscircuitos PRI al mismo portador que se puedeutilizar arbitrariamente. Un gateway (o un puertodeterminado en un gateway) se puede agregarsolamente a un Grupo de Routes.
Listade laruta
El punto de ruta antes llamado, la lista de la rutapermite que el Cisco CallManager cace a travésde una lista de Grupos de Routes en un ordenconfigurado de preferencia. Las listas de Routesmúltiple pueden señalar a los mismos Grupos deRoutes.
Patrónde ruta
Un número específico o, generalmente, unrango de los Números marcados que seránutilizados para rutear las llamadas a undispositivo (tal como un gateway del acceso DT-24+ de Cisco o un router que acepta datos devoz) 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 @. ¡! , yasí sucesivamente). Un patrón de ruta no tieneque ser único dentro de una división mientras elfiltro de la ruta sea diferente.
RRJ Registration Reject.
RTP
Protocolo Real-Time Transport, uno de losprotocolos del IPv6. El RTP se diseña paraproporcionar los función del transporte de red deextremo a extremo para las aplicaciones quetransmiten las informaciones en tiempo real,tales como audio, video, o los datos desimulación, sobre los servicios de red delMulticast o del unicast. El RTP proporciona losservicios tales como identificación de tipo decarga útil, numeración de secuencia, tiempo quesella, y control de entrega a las aplicaciones entiempo real.
SEP
Teléfono de los Ethernetes del Selsius. Estassiglas preceden las direcciones MAC en losTeléfonos IP de Cisco, y representan unidentificador de dispositivo único.
Supres La supresión del silencio permite que un Cisco
ión delsilencio(detección delaactivación porvoz)
IP Phone detecte la ausencia de sonido y por lotanto no transmite los paquetes sobre la red. Lacalidad de sonido puede ser degradadalevemente pero la conexión puede tambiénutilizar menos ancho de banda. La supresión delsilencio se inhabilita por abandono.
SNMP
Protocolo administración de red simple. ElNetwork Management Protocol se utiliza casiexclusivamente en las redes TCP/IP. SNMPproporciona un medio para monitorear ycontrolar los dispositivos de red, y paraadministrar las configuraciones, la recolecciónde estadísticas, el rendimiento y la seguridad.
SQLLenguaje de consulta estructurado. Lenguaje deNorma internacional para definir y acceder lasbases de datos relacionales.
T1/CAS
El T1 es un recurso de portadora de WANdigital, transmitiendo los datos DS-1-formatteden el 1.544 Mbps con el Telephone SwitchingNetwork, usando la codificación AMI o B8ZS.CAS es una interfaz de señalización asociada alcanal.
T1/PRI
El T1 es un recurso de portadora de WANdigital, transmitiendo los datos DS-1-formatteden el 1.544 Mbps con el Telephone SwitchingNetwork, usando la codificación AMI o B8ZS. ElPRI es interfaz de la velocidad primaria. Elacceso de velocidad primaria consiste en unsolo 64-Kbps canal D más 23 (T1) o 30 canalesB (del e1) para la Voz o los datos.
TCP
Protocolo Protocolo de control de transmisión(TCP). Éste es el protocolo de capa deltransporte orientado por conexión queproporciona confiable, transmisión de datos dedúplex completo. El TCP es parte de la pila deprotocolo TCP/IP.
TFTP
Protocolo trivial file transfer. Versión simplificadadel FTP que permite que los archivos seantransferidos a partir de un ordenador a otrosobre una red.
Patróndetraducción
Utilizado para traducir llamado (DNIS) yllamando los números de la identificación denúmero automática (ANI) antes de rutear lallamada. Por ejemplo, una llamada puede veniradentro a un conjunto de números (919 392-3XXX) esa necesidad de ser traducido a unconjunto 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 para919 392-3XXX. Este modelo traduce los 919392-3 principal simplemente a 2, mientras quedeja los dígitos restantes intactos. Entonces lallamada se rutea al Cisco IP Phone apropiado.Utilizan solamente para las traducciones ciertasy no deben ser utilizados a los patrones detraducción para la eliminación y prefijación dedígito simple.
UDP
Protocolo UDP. Esto es un protocolo de capa detransporte sin conexión en la pila de protocoloTCP/IP. El UDP es un protocolo sencillo queintercambia los datagramas sin los acuses derecibo o la entrega garantizada, requiriendo queel proceso del error y la retransmisión seanmanejados por otros protocolos. El UDP sedefine en el RFC 768.
Detección delaactivación porvoz(supresióndelsilencio)
La detección de la activación por voz permiteque un Cisco IP Phone detecte la ausencia desonido y por lo tanto no transmite los paquetessobre la red. La calidad de sonido puede serdegradada levemente pero la conexión puedetambién utilizar menos ancho de banda. Lasupresión VAD/Silence se inhabilita porabandono.
VoIP Voz sobre IP.
VLAN
LAN virtual. Un grupo de dispositivos en uno omás LAN se configuran que (usando el softwarede administración) de modo que él puedacomunicar como si lo asociaran al mismoalambre, cuando de hecho él está situado envarios diversos segmentos LAN. Porque los VLAN se basan en lógico en vez de las conexionesfísicas, son extremadamente flexibles.
Herramientas y utilidades para supervisar y solucionar problemasen CallManager
Esta sección dirige las Herramientas y utilidades para configurar, para monitorear y para resolverproblemas 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 elsistema, la base de datos, y otros componentes. En la página de la apertura, haga clic en el botónDetails Button y anote las versiones funcionando.
Una más explicación detallada de la administración del CallManager de Cisco está disponible enla documentación en línea del Cisco CallManager.
Rendimiento de Microsoft
El funcionamiento (monitor) es Windows 2000 Server una aplicación que puede visualizar lasactividades y el estatus de su Sistema CallManager de Cisco. Señala la información general yespecífica en el tiempo real. Usted puede utilizar el funcionamiento del Windows 2000 pararecoger y exhibir sistema y las estadísticas de dispositivo para cualquier instalación del CiscoCallManager. Estas herramientas administrativas permiten que usted gane una comprensiónplena 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 enel tiempo real. Después de agregar los parámetros del Cisco CallManager, usted puede definir lostérminos bajo los cuales el Cisco CallManager visualizará las estadísticas generadas por elsistema. Por ejemplo, usted puede monitorear el número de llamadas en curso en cualquiermomento, o el número de llamadas que pasan actualmente a través de un gateway específico. Elfuncionamiento muestra el general y Cisco información de estatus Específica de CallManager enel tiempo real.
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 (Herramientasadministrativas) > 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 comoejemplo quieren incluir. Refiera a configurar la utilidad remota para el Cisco CallManager, 3.0 dela versión para las instrucciones en cómo utilizar los objetos y los contadores para personalizar elrendimiento 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 devisualizaciones, Seguridad, y los eventos de aplicación (Cisco CallManager incluyendo) para elservidor del Windows NT. Si un servicio (TFTP incluyendo) no puede leer la base de datos (dondeconsigue la configuración de la traza), agregará los errores al visor de eventos. El visor deeventos es el único lugar en donde aparecerán estos tipos de errores. El ejemplo siguientemuestra los log de aplicaciones que se ejecutan en un servidor del Windows NT.
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 > AdministrativeTools > Event Viewer. El visor de eventos proporciona los registros de error para el sistema, laSeguridad, y las aplicaciones. Los errores del Cisco CallManager se registran bajo log deaplicaciones.
Información detallada sobre los eventos
Usted puede hacer doble clic un evento en el registro para aprender más información sobre elevento.
Rastro de SDI
Las trazas del SDI son archivos del registro local. La dirección IP, la manija TCP, el Nombre deldispositivo, o el sello de fecha/hora pueden ser utilizados al revisar la traza del SDI paramonitorear el acontecimiento o la disposición de una petición. Este Nombre del dispositivo sepodría seguir de nuevo al edificio del archivo, que muestra la agrupación de dispositivos y elmodelo. La agrupación de dispositivos y el modelo pueden ser seguidos de nuevo al edificio delprototipo del archivo de configuración, que enumerará a la dirección de red del Cisco CallManagery 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ánincluidos con la mayoría de las líneas de seguimiento. La mayoría de las rutinas asociadas a laporció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énde las actividades del Cisco CallManager. Estas trazas proporcionan la información sobre elproceso de inicialización del Cisco CallManager, el proceso de inscripción, el proceso dekeepalive, el flujo de llamada, la análisis de dígitos, y los dispositivos relacionados tales comoTeléfonos IP, gatewayes, porteros, y más de Cisco. Esta información puede ayudarle a aislar losproblemas al resolver problemas el Cisco CallManager. Para seguir correctamente la informaciónque usted necesita y solamente la información usted necesita, él es importante entender cómofijar 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:\ProgramFiles\cisco\bin. Se enciende un nuevo archivo de traza cada vez que el Cisco CallManagerrecomienza, 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 delCallManager de Cisco. Usted debe habilitar la traza, elegir el nivel en la información necesaria, ymarcar a la máscara del usuario para obtener el nivel deseado de información.
Si la traza no se configura correctamente, generará una gran cantidad de información que la hacemuy difícil aislar los problemas. La sección siguiente explica cómo configurar correctamente unatraza útil.
Configurar las trazas
Las trazas se componen de los indicadores de la máscara del usuario (también conocidos comobits) y de los niveles de traza. Abra a la administración del CallManager de Cisco. Para dar vueltaencendido a localizar, fije sus parámetros de la traza (servicio configurado incluyendo, los bits, yasí 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 porintervalos, y para las descripciones de las máscaras del usuario y los niveles para cada servicioconfigurado, y más.
Los siguientes son dos ejemplos de los Mask Bit de la traza que serían habilitados sobre la basedel 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 delsubsistema
●
Los siguientes son dos ejemplos de los niveles de traza deseados basados en el problemadeterminado
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 seespera 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 aTAC. Los archivos de traza SDL se pueden guardar a los directorios locales, al visor de eventosdel Windows NT, y al CiscoWorks 2000. Para evitar cualquier degradación del rendimiento en elservidor, esté seguro que usted apaga el seguimiento de SDL después de que se haya capturadola traza.
La traza SDL proporciona la interfaz A.C. para localizar y las alarmas. Las alarmas se utilizanpara 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 sistemaoperativo.
Habilitar la traza SDL
Las trazas SDL se habilitan en Service (Servicio) > Service Parameter area (Área de parámetrode servicio) adentro la administración del CallManager de Cisco. Recuerde que estas trazasdeben ser giradas solamente cuando son pedido por un ingeniero de TAC. Observe los valoreselegidos para girar la traza SDL en el ejemplo siguiente.
Una vez que se habilitan las trazas SDL, recoja las trazas. Si las trazas se están enviando a launidad 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 alCiscoWorks 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 esSdlTraceTypeFlags=0x00000b04
●
El valor recomendado para el debugging bajo o los gatewayes del debugging esSdlTraceTypeFlags=0x00004b05
●
Definiciones de SdlTraceTypeFlagsSDLTraceTypeFlag Valor Definición
traceLayer1
=0x00000001
Toda la traza del Layer 1 encendido
TraceDetai = Traza del Layer 1 del detalle
lLayer1 0x00000002 encendido
TraceSdlLinkAdmin
=0x00000004
Links del CallManager de inter-Ciscode 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 2encendido
traceLayer2TCP
=0x00000040
Traza de la capa 2 TCP encendido
TraceDetailLayer2
=0x00000080
Más volcado del detalle de losbastidores de la capa 2.
traceLayer3
=0x00000100
Todos acodan la traza 3 encendido
traceCc=0x00000200
Toda la traza del Control dellamadas encendido
traceMiscPolls
=0x00000400
Encuestas diversas de la traza
traceMisc=0x00000800
Traza diversa en (señales de la basede datos)
traceMsgtrans
=0x00001000
La Traducción de mensaje señala(TranslateIsdnToSdlReq,TranslateIsdnToSdlResTranslateSdlToIsdnReq,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) > ServiceParameters (Parámetros de servicio) en la administración del CallManager de Cisco. Lossiguientes 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 serfijado conjuntamente con cualquier otro bits)
●
Definiciones de SDLTraceDataFlagsSDLTraceDataFlag
Valor Definición
TraceSdlLinkState
=0x001
Traza del permiso de la inicializacióndel link SDL
TraceSdlLowLevel
=0x002
Habilite el seguimiento de loseventos SDL de bajo nivel, fileOpeny los eventos de socket (por ejemplo)
TraceSdlLinkPoll
=0x004
Seguimiento del permiso delmensaje de la encuesta del link SDL
TraceSdlLinkMsg
=0x008
Seguimiento del permiso delmensaje del link SDL
traceRawData
=0x010
Traza sin procesar de los datos de laseñal del permiso en todas lasseñales
TraceSdlTagMap
=0x020
Asignación de la etiqueta del permiso
traceCreate=0x100
El proceso del permiso crea y paralas trazas
TraceNoPrettyPrint
=0x200
Impresión buena de la neutralizaciónde archivos de traza
Advertencia del espacio en disco
Advertencia: Aconséjese que la información obtenida de esta interfaz podría ser muy detallada, ypor lo tanto consuma una gran cantidad de espacio en disco. Por este motivo, le aconsejamosgirar el archivo de traza por una determinada cantidad de hora, revisar la información, y apagar latraza.
‘Rastro del sabueso
Un sniffer es una aplicación de software que monitorea el tráfico IP en una red y proporciona lainformación bajo la forma de traza. Las trazas de sniffer proporcionan la información sobre lacantidad y el tipo de tráfico de red en su red. El TCP/IP o los paquetes UDP es protocolosutilizados por el Cisco CallManager y por los dispositivos de punto final, tales como teléfonos ygatewayes. Las trazas de sniffer pueden también ayudarle a identificar los niveles elevados detráfico de broadcast que podrían dar lugar a los problemas de audio o a las llamadasinterrumpidas de la Voz. Las aplicaciones de sabueso común incluyen a los Network AssociateSnifferPro, 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 eldominó, recomendamos el usar del software de análisis para evaluar un archivo sabuesocapturado (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 cualquierCisco IP Phone. Hay dos clases de CDR: CDR básicos y CDR de diagnóstico (o CMR). Una vezque está habilitado, usted puede abrir CDR o CDR de diagnóstico (CMR) en el administrador deempresa del SQL Server. Los archivos CDR se guardan en una base de datos SQL que se puedaexportar 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 unconjunto de las ubicaciones. El error de un nodo del Cisco CallManager no hace los datos CDRasociados a ese nodo inasequibles. Los datos se salvan no más en el disco del CiscoCallManager como archivo plano, pero en lugar de otro se salvan en una base de datos central enlas tablas.
Si el Cisco CallManager falla antes de que se escriba cualquier expediente, ningún expediente dela llamada existirá. Esto significa que no se escribirá ningún expediente para las llamadas que sonactivas 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 parainformació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 esecampo
●
Descripción de los tipos de llamadas registradas, y los campos registrados con cada uno deellas
●
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 usteddesea tener datos CDR, usted debe habilitar los CDR en el área del Service (Servicio) > ServiceParameters (Parámetros de servicio) de la administración del CallManager de Cisco. El procesoCDR puede ser habilitado y ser inhabilitado en cualquier momento mientras que el sistema es enfuncionamiento. Usted no necesita recomenzar el Cisco CallManager para habilitar o inhabilitar delos CDR para tomar el efecto. El sistema responderá a todos los cambios dentro de algunossegundos. El CMR o los datos diagnósticos se habilita por separado de los datos CDR. Los datosCMR 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.
Abra a la administración del CallManager de Cisco.1.Seleccione Service > Service Parameters.2.Seleccione la dirección IP de su instalación del Cisco CallManager.3.De la lista de parámetros, seleccione CDREnabled.4.Defina el tipo como boleano.5.
Seleccione T para verdad.6.Actualización.Resultado: Los registros de detalles de la llamada comenzarán a registrarinmediatamente.Precaución: Localizar la conectividad de voz requiere ese registro CDR sehabilite en cada instalación del Cisco CallManager en uncluster.
7.
CDR
Los CDR proporcionan la información básica que puede ayudarle a entender la más informacióndetallada contenida en las trazas del SDI. Los CDR básicos proporcionan la información tal comoel 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 losproblemas del teléfono. Por ejemplo, si un usuario señala un problema con una llamada queocurre en un tiempo específico, usted puede consultar los CDR que ocurrieron alrededor deltiempo indicado para aprender la información adicional sobre esa llamada y otras. Los CDR sonde 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úmerode paquetes enviados, recibidos, y perdidos, y la cantidad de jitter y de tiempo de espera. Estenivel de detalle puede proporcionar las explicaciones para algunos problemas, tales como audiounidireccional. Por ejemplo, se indica un problema del audio unidireccional si un tamaño depaquetes de 10,000 se envía, pero el tamaño recibido es solamente 10.
Resolución de problemas del CallManager con Windows NT eInternet Information Server (IIS)
Esta sección dirige algunas categorías del problema común que puedan ocurrir con el CiscoCallManager 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 sugerenciasen cómo resolver problemas esos problemas. No proporciona una lista exhaustiva de problemas yde resoluciones. Si usted encuentra un problema que no se pueda resolver usando lasHerramientas y utilidades descritas en este documento, consulte el Centro de Asistencia Técnicade Cisco (TAC) para la ayuda. Sea seguro tener los detalles de administración del CallManagerde Cisco disponibles, más la cualquier información de diagnóstico (tal como trazas) que usted harecolectado hasta la punta de llamar TAC.
Calidad de voz
Los problemas de calidad de voz incluyen el audio perdido o torcido durante las llamadastelefónicas. Los problemas comunes incluyen las roturas en el sonido que hacen el audio serintermitente (como las palabras quebradas), o la presencia de ruidos impares que tuerzan elaudio (generación de eco) o los efectos que hacen las palabras habladas sonar acuosas orobóticas. El audio unidireccional, es decir, una conversación entre dos personas dondesolamente 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 considerarla 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 (descritoa 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 paquetesignifica que los Paquetes de audio no llegan su destino porque fueron caídos o llegadosdemasiado tarde para ser útiles. El jitter es la variación en las horas de llegada de paquetes. En lasituación ideal, todos los paquetes de VoIP a partir de un teléfono a otro llegarían exactamentehasta una tasa de 1 cada ms 20. Note que esto no menciona cuánto tiempo toma para que unpaquete 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 sercontrolados, y algunos pueden. El Retraso variable no se puede eliminar totalmente en una red devoz empaquetada. Los procesadores de señales digitales (DSPs) en los teléfonos y otrosdispositivos 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á listopara 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 tantocomo el segundo de los ejemplos de voz. El buffer del jitter es adaptante, significando si unaexplosión de los paquetes se recibe, el Cisco IP Phone 7960 sabe realizarlos en un intento porcontrolar el jitter. El administrador de la red necesita minimizar la variación entre los tiempos de lallegada 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 primerointentar aislar la trayectoria del audio. Intente identificar cada dispositivo de red (Switches yRouters) en la trayectoria de la secuencia de audio de la llamada. Tenga presente que el audiopuede ser entre dos teléfonos, entre un teléfono y un gateway, o podría tener varios tramos (deun teléfono a un dispositivo de transcodificación y de allí a otro teléfono). Intente identificar si elproblema ocurre solamente entre dos sitios, solamente a través de cierto gateway, en ciertasubred, y así sucesivamente. El ayudará a estrecharse abajo que los dispositivos usted necesitanexaminar más cuidadosamente. Después, es a menudo el mejor inhabilitar la supresión delsilencio (también conocida como la detección de la activación por voz o VAD) si esto no se hahecho ya. Este mecanismo salva el ancho de banda no transmitiendo el audio cuando haysilencio, pero puede causar el recortes notable (e inaceptable) al principio de las palabras. Ustedpuede 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 CallManagerde Cisco. Fije SilenceSuppressionSystemWide a “F” (alternativamente usted puede fijarSilenceSuppressionWithGateways a “F”, pero ésta no se aplica a Gateways H.323 o a losgatewayes MGCP). En caso de duda, apague ambos seleccionando el valor F para cada uno.
Si un analizador de red está disponible, una llamada monitoreada entre dos teléfonos debe tener50 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 seestá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 losPaquetes de audio (que tendrán un encabezado RTP) serán el ms 20. En una llamada de la bajacalidad (tal como una llamada con mucho jitter), las horas de llegada variarían grandemente.
Una traza perfectaNúmero delpaquete
Hora: absoluto(ms)
Hora: delta(ms)
1 02 0,02 203 0.04 204 0.06 205 0.08 20
La colocación del analizador de paquete en las diversas puntas en la red ayudará a estrecharseabajo de donde está viniendo el retardo. Si no hay analizador disponible, otros métodos seránrequeridos. Es importante examinar las estadísticas de la interfaz de cada dispositivo en latrayectoria del audio. Otra herramienta para seguir las llamadas con la calidad de voz deficientees los registros de detalles de la llamada de diagnóstico (CDR). Vea las Herramientas y utilidadesseccionar y la sección de los registros de detalles de la llamada para más información sobre losCDR.
Los valores para el jitter y el tiempo de espera se pueden extraer para todas las llamadas (perosolamente después que la llamada ha terminado). Lo que sigue es una muestra CDR dediagnóstico (el CallDetailRecordDiagnostic es el nombre de la tabla real). El número de paquetesenviados, recibido, perdido, jitter, y tiempo de espera todo se registra. El valor del globalCallID sepuede utilizar para encontrar la llamada en la tabla regular CDR para poder obtener elDesconectar causa y la otra información. El diagrama a continuación muestra ambas tablasabiertas. Note que en el CDR de diagnóstico, cada dispositivo que puede señalar posiblementeesta 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 gatewayporque no hay mecanismo para que notifique la base de datos SQL con esta información.
ayuda de botón I Button
El Cisco IP Phone 7960 proporciona otra herramienta para diagnosticar los problemas de audioposibles. En una llamada activa, usted puede presionar el botón I Button dos veces (rápidamente)y el teléfono visualiza a una Pantalla de información que contenga el paquete reciba y transmitelas estadísticas, así como los contadores de la media y de la fluctuación máxima. En estapantalla, no ese jitter es la media de los cinco paquetes más recientes que llegaron; la fluctuaciónmá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 dispositivosdonde una interfaz de velocidad superior alimenta en una interfaz de velocidad más baja. Porejemplo, un router puede tener una interfaz Fast Ethernet del 100 Mb conectada con el LAN y unFrame Relay lento conectado con WAN. Cuando ocurre la baja calidad solamente al comunicar alsitio remoto (solamente el sitio remoto puede señalar la calidad de voz deficiente mientras que enla 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 eltráfico de datos.
●
Hay demasiadas llamadas activas para que WAN soporte (es decir, no hay control deadmisió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 eltrá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 atravé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 eluso de las ubicaciones en configuración de la administración del CallManager de Cisco, o usandoun router del Cisco IOS como portero. En todo caso, usted debe saber siempre cuántas llamadasse podrían soportar a través de su WAN. Si es posible, pruebe esto inhabilitando la supresión delsilencio según lo descrito anterior, después ponga las llamadas entre los dos sitios. No coloqueinvita al control o del mudo, puesto que esto parará los paquetes de ser transmitido. Con elnú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 unafuente de alimentación defectuosa o una cierta clase de interferencia eléctrica fuerte cerca delteléfono. Intente intercambiar la fuente de alimentación y mover el teléfono a una ubicacióndiferente.
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 enwww.cisco.com) para las cargas del último software, nuevas correcciones, o Release Notereferentes al problema.
Eco
La generación de eco (también conocida como “eco del hablante”) ocurre cuando la energía vocalde un transmisor, transmitida abajo de la trayectoria de la señal primaria, se junta en la trayectoriade la recepción del otro extremo. El transmisor entonces oye su propia Voz, retrasada por eltiempo de retardo de trayecto total de la generación de eco.
En el diagrama arriba, la Voz de Juan (en el azul) se está reflejando detrás. Esto puede sucedersino ir inadvertido en una red de voz tradicional porque el retardo es tan bajo. Al usuario, suenamá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 asuntoimportante a recordar es que la causa de la generación de eco está siempre con los componentesanalógicos y el cableado. Por ejemplo, los paquetes del IP no pueden dar vuelta simplementealrededor y volver a la fuente en un nivel de audio más bajo. Lo mismo es imposible en loscircuitos digitales T1/E1. Tan en una llamada a partir de un Cisco IP Phone a otro, debe nuncahaber cualquier problema. La única excepción puede ser si un partido está utilizando unspeakerphone que tiene el volumen configurado demasiado arriba o cierta otra situación donde secrea un loop audio.
Al resolver problemas los Problemas de eco, aseegurese que los teléfonos se están probandoque o examinado no están utilizando el speakerphone y que ellos tienen el volumen configuradode 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 oun gateway analógico. Los usuarios del Cisco IP Phone pueden quejarse de que oyen su propiaVoz que es reflejada de nuevo a ellos. Aunque la verdadera fuente del problema esté casisiempre 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 esfuncionando, puede ser posible agregar el relleno adicional en la dirección de transmisión (haciael PSTN) con la esperanza de que la fuerza de la señal inferior rinda menos energía reflejada.Además, usted puede ajustar el nivel de la recepción de modo que cualquier audio reflejado seaincluso más futuro reducido. Es muy importante recordar hacer el pequeño en un momento de losajustes. 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íneasmarcar. En un circuito típico T1/PRI en Norteamérica, la señal de entrada debe estar -15 dB. Si elnivel de la señal es mucho más alto (DB -5, por ejemplo), la generación de eco será el resultadoprobable.
Guarde un registro de todas las llamadas que experimenten la generación de eco. La época delproblema, del número de teléfono de la fuente, y del número llamado si se registran todos. Losgatewayes tienen un rato fijo del ms 16 de la cancelación de eco. Si el retardo en el audioreflejado es más largo que esto, el canciller de la generación de eco no podrá trabajarcorrectamente. Esto no debe ser un problema para las Llamadas locales, y las llamadas de largadistancia 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 deuna 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 ConnectionOnline en www.cisco.com) para las cargas del último software, las nuevas correcciones, o losRelease Note referente al problema.
Audio unidireccional o no audio
El audio unidireccional ocurre cuando una persona no puede oír a otra persona durante unallamada. Esto se puede causar por un Cisco IOS Gateway incorrecto-configurado, un Firewall, ouna 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 lacausa común es un dispositivo incorrecto-configurado. Por ejemplo, el Cisco CallManager manejala configuración de la llamada para un Cisco IP Phone. La secuencia de audio real ocurre entrelos dos Teléfonos IP de Cisco (o entre el Cisco IP Phone y un gateway). Así pues, es totalmenteposible 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. Estoocurre 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 Phonedel destino usando un PC que esté en la misma subred como el teléfono y tenga el mismo defaultgateway. Tome un PC que esté en la misma subred como el teléfono de destino (con el mismodefault gateway que el teléfono de destino) y haga ping el teléfono de la fuente. Ambas pruebasdeben 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 ambasdirecciones. 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 delprincipio de la configuración). También, si usted está utilizando la Compresión de cabecera RTPpara salvar el ancho de banda a través de WAN, aseegurese que está habilitado en cada tráficode voz que lleva del router que asocie al circuito PÁLIDO. No debe haber una situación donde elencabezado RTP se comprime en un extremo pero no se puede descomprimir en el otro lado deWAN. Un sniffer es mismo una herramienta útil al resolver problemas los problemas del audiounidireccional porque usted puede verificar que el teléfono o el gateway sea realmente de envío ode recepción de los paquetes. Los CDR de diagnóstico son útiles en determinar si una llamadaestá 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 sobretransmitido y los paquetes recibidos.
Nota: Cuando se silencia una llamada (botón enmudecedor presionado en un teléfono), no setransmitirá ningunos paquetes. El botón Hold Button para la secuencia de audio, así que no seenvía ningunos paquetes en cualquier dirección. Cuando se libera el botón Hold Button, reajustana todos los contadores de paquetes. Recuerde que la supresión del silencio se debe inhabilitar enlos dispositivos para que los contadores TX y RX permanezcan igual. Inhabilitar la supresión delsilencio 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 serviciossuplementarios tales como control y transferencia con los dispositivos de H.323 que no soportanla versión de H.323 2), marque para ver si el MTP afectado un aparato está trabajandocorrectamente. El Routers del Cisco IOS soporta el principio de la versión 2 de H.323 en laversión 11.3(9)NA y 12.0(3)T. Comenzando con el Cisco IOS Release 12.0(7)T, H.323 opcionalabierto/LogicalChannel cercano se soporta, para requerir el MTP basado en software no más paralos servicios suplementarios.
El Dispositivo MTP, así como Bridge de conferencia y transcoder, interligará dos o mássecuencias de audio. Si el MTP, el Bridge de conferencia, o el transcoder no está trabajandocorrectamente, el audio unidireccional o la pérdida de audio pudo ser experimentado. Apague elMTP 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 razonessiguientes:
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 resolver problemas las restauraciones del teléfono:
Marque los teléfonos y los gatewayes para asegurarse de que usted está utilizando lascargas del último software.
1.
Marque CCO (Cisco Connection Online en www.cisco.com) para las cargas del últimosoftware, las nuevas correcciones, o los Release Note referente al problema.
2.
Marque el visor de eventos para los casos del reajuste de los teléfonos. Las restauracionesdel teléfono se consideran los eventos de Información, tal y como se muestra en del ejemplo
3.
siguiente.Busque éstos y cualquier error que pudieron haber ocurrido alrededor del tiempo ese larestauración de los teléfonos.
4.
Comience una traza del SDI e intente aislar el problema identificando cualquier característicacomún en los teléfonos que están reajustando. Por ejemplo, marque si todos están situadosen la misma subred, el mismo VLA N, y así sucesivamente. Mire la traza y determinela si:lasrestauraciones ocurren durante una llamada o suceden intermitentemente, ohay cualquiersemejanza del modelo del teléfono: Cisco IP Phone 7960, Cisco IP Phone 30VIP, y asísucesivamente.
5.
Comience una traza de sniffer en un teléfono que reajuste con frecuencia. Después de quehaya reajustado, mire la traza para determinar si hay alguna ocurrencia de lasrecomprobaciones TCP. Si es así esto indica un problema de red. La traza puede mostraralgunos estados coherentes en las restauraciones, tales como el teléfono que reajusta cadasiete días. Esto pudo indicar una expiración del arriendo del DHCP cada siete días (estevalor es utilizador configurable y podría ser cada dos minutos, y así sucesivamente).
6.
Llamadas interrumpidas
Las llamadas interrumpidas ocurren cuando una llamada se termina prematuramente. Ustedpuede utilizar los CDR para determinar la posible causa de las llamadas interrumpidas,determinado si el problema es intermitente. Las llamadas interrumpidas pueden ser el resultadode un teléfono o reconfiguración de la gateway (véase la sección antedicha) o de un problema delcircuito, 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. Elsiguiente paso es marcar el visor de eventos para las restauraciones del teléfono o del gateway.
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 CiscoCallManager viva, el Cisco CallManager reajusta tan la conexión. Esto puede ser porque untelé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.
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 CDRdarán una causa de la terminación (COT) que pueda ayudar a determinar la causa del problema.
Los valores del Desconectar causa (el origCause_value y el destCause_value, dependiendo delos cuales lado colgado encima de la llamada), asocian al q.931 los códigos de la causa dedesconexión (en el decimal) que se pueden encontrar en los tipos del switch de ISDN, loscódigos, y los valores. En el ejemplo anterior, la causa 16 refiere a una Verificación normal dellamadas. Si la llamada está saliendo un gateway al PSTN, el CDR se puede utilizar paradeterminar que el lado está colgando encima de la llamada. Mucha de la misma informaciónpuede ser obtenida habilitando el seguimiento en el Cisco CallManager. Utilice la herramienta dela 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 ydel gateway en www.cisco.com) para las cargas del último software, las nuevas correcciones, olos 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 MediaTermination Point, que se utilizan conjuntamente con el Cisco CallManager. Algunos de estosproblemas de la característica son causados por los Errores de configuración o una falta derecursos. Por ejemplo, los usuarios pueden no poder a las llamadas en conferencia si el númeroespecificado de recursos del conferencia Ad-Hoc se ha excedido. El resultado sería una llamadainterrumpida cuando el usuario intentó iniciar la característica de la conferencia. Éste podríaaparecer ser un problema de la función de Cisco CallManager, cuando de hecho es un problemacon el número de recursos de conferencia disponibles. La cantidad de veces un recurso deconferencia fue requerida, pero no disponible, está uno del rendimiento de Microsoft abierto unasesión los contadores. El mismo comportamiento ocurre si hay recursos de conferenciadisponibles, 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 deldesacuerdo del codificador-decodificador entre las regiones. Verifique que ambos extremos de lallamada 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 lasotras 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 undispositivo en Region2 puede utilizar G.711 o cualquier otro codificador-decodificador soportadoque requiera el ancho de banda igual o inferior como G.711 (cualquier codecs soportado dentrode 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 serporque la asignación de ancho de banda del Cisco CallManager para la ubicación de uno de losdispositivos extremos de la llamada se ha excedido (menos que 24k). El Cisco CallManagermarca para saber si hay el ancho de banda disponible 24k para cada dispositivo antes de haceruna llamada. Si menos que el ancho de banda 24k está disponible, el Cisco CallManager nopondrá 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 lasubicaciones 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 CiscoCallManager 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 resolver problemas un “ningún problemadisponible 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 deconferencia 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 “unicastAvailableConferences.”
La aplicación de flujo continuo de las medias de voz IP de Cisco realiza la función del Bridge deconferencia. Una instalación del software de fluir de las medias de voz IP de Cisco soportará 16conferencias disponibles del unicast (3 personas/conferencias), tal y como se muestra en de latraza 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 unicast las conferencias disponibles(tamaño máximo 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 deservicios indica que el puerto E1 4/1 en el indicador luminoso LED amarillo de la placa muestragravedad 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 oReunió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 lasllamadas entre dos usuarios sin los códecs comunes), marque para ver si usted tienecualesquiera recursos transcodificadores disponibles registradoes con el Cisco CallManager (éstedebe 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 16llamadas, 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 deservicios indica que el puerto E1 4/2 en el indicador luminoso LED amarillo de la placa muestragravedad 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 elTranscoder/MTP
Para hacer una llamada entre dos dispositivos usando un código del Low Bit Rate (tal comoG.729 y G.723) que no soporta el mismo codificador-decodificador, requieren a un recursotranscodificador. Considere el ejemplo siguiente:
Asuma que el Cisco CallManager se ha configurado tales que el codificador-decodificador entreRegion1 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 unCisco IP Phone 7960, que sucede soportar G.729. Después de que se hayan recogido losdígitos, el Cisco CallManager determina que la llamada es destinada para el usuario D queestá en la región 2. Puesto que el dispositivo de destino también soporta G.729, se configurala 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 llamadapara llamar por teléfono a D, este vez el Cisco CallManager realizaría que el teléfono queorigina soporta solamente G.723 o G.711. El Cisco CallManager necesitaría afectar unaparato un recurso de transcodificación de modo que el audio fluyera como G.711 entre elteléfono B y el transcoder, sino como G.729 entre el transcoder y el teléfono D. Si no haytranscoder disponible, el teléfono d del teléfono sonaría, pero tan pronto como la llamadafuera 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éfonosutilizarían realmente G.723, aunque G.729 se configura como el codificador-decodificadorpara utilizar entre las regiones. Se utiliza G.723 porque ambos puntos finales lo soportan yutiliza menos ancho de banda que G.729.
●
Si se agrega un sistema de correo de voz del Cisco uOne (que soporta solamente G.711) oun router del Cisco IOS configurado para G.711 a la región 1, después un dispositivo detranscodificación se debe utilizar si llama de la región 2. Si ninguno está disponible, despuésla llamada fallará.
●
Problemas del recurso MTP
Un problema del recurso MTP podría ser el culpable si se establece una llamada y los serviciossuplementarios 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 soportefísico) registradoes con el Cisco CallManager. Usted puede hacer tan usando el rendimiento deMicrosoft para marcar el número de “MediaTermPointsAvailable.”
Una aplicación de software MTP soporta 24 llamadas (usando el MTP para soportar los serviciossuplementarios con los dispositivos de H.323 que no soportan el H.323v2), tal y como se muestraen 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 ycomo 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 deservicios, indica que el puerto E1 4/2 en el indicador luminoso LED amarillo de la placa muestragravedad menor se ha registrado como MTP/transcoder con el Cisco CallManager.
11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received
- Device= MTP00107B000FB1 - Registered - Supports 16 calls
En segundo lugar, vea si el Media Termination Point requirió el checkbox se selecciona en lapantalla 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 deDispositivos MTP.
Del archivo del SDI:
11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received
- Device= MTP00107B000FB1 - Registered - Supports 16 calls
Planes de marcado
Un Plan de marcado es una lista de números (y de grupos de números) que dice el CiscoCallManager al cual los dispositivos (teléfonos, gatewayes, y así sucesivamente) para enviar lasllamadas cuando se recoge cierta cadena de dígitos. Es similar a una tabla de ruteo estática enun router. Esté por favor seguro que sus conceptos, ruteo de llamadas básico, y hojas deoperación (planning) del Plan de marcado se han considerado cuidadosamente y se hanconfigurado correctamente antes de intentar resolver problemas un problema potencial del Plande marcado. Muy a menudo, el problema miente con las hojas de operación (planning) y laconfiguración.
Considere las preguntas siguientes al resolver problemas los problemas de los Planes demarcado:
¿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; sesoportan las apariciones de línea múltiple, y es posible tener un DN en los dispositivosmúltiples. Observe el Calling Search Space del dispositivo. Si la llamada es originada por unCisco IP Phone, recuerde que la línea determinada (DN) y el dispositivo al cual esa línea esvoluntad asociada cada uno tiene Calling Search Spaces. Serán combinados al hacer unallamada. Como un ejemplo, asuma que la línea caso 1000 tiene un Calling Search Space delAccessLevelX y el Cisco IP Phone que tiene extensión 1000 configurada en él tieneAccessLevelY como su Calling Search Space. Por lo tanto, al hacer una llamada de esaaparición de línea, el Cisco CallManager buscará a través de las divisiones contenidas en elAccessLevelX 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ánconsiguiendo un tono de marcación secundario, en cualquier etapa. ¿También, qué losllamantes oyen después de que todos los dígitos haber sido ingresados (reordene, rápidoocupado)? ¿Consiguen los tonos de progreso antes de que esperen oír cualquier cosa?Aseegurese los llamantes la espera por lo menos 10 segundos después de ingresar el últimopasado, 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ícelopara examinar a todos los patrones de ruta para las divisiones que están en el Calling SearchSpace 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 lalista 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 sonparte 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 paracapturar esta información y para verificarla.
●
Tenga cuidado para @ la muestra. Ésta es una macro que puede ampliarse para incluirmuchas diversas cosas. Es de uso frecuente conjuntamente con las opciones de filtro.
●
Si un dispositivo no es parte de a la división, reputa a la parte de la falta de información o lapartición predeterminada. Cada usuario debe poder llamar ese dispositivo. La división nula essiempre último buscado.
●
Si usted marca un número exterior que esté correspondiendo con un modelo 9.@ y toma 10segundos antes de que va la llamada a través, marque las opciones de filtro. Un modelo 9.@,al marcar un número de 7 dígitos, (por abandono) esperará 10 segundos. Usted necesitaaplicar un filtro de la ruta al modelo que dice LOCAL-AREA-CODE DOES-NOT-EXIST yEND-OF-DIALING DOES-NOT-EXIST.
●
Divisiones
Las divisiones de la ruta heredan las capacidades del manejo de error del software CallManagerde Cisco. Es decir, traza una consola y de un archivo del SDI se proporcionan para la informaciónde ingreso al sistema y los mensajes de error. Estos mensajes serán parte del componente de laanálisis de dígitos de las trazas. Incluso con las trazas abajo, una comprensión de lasconfiguraciones de las divisiones y del Calling Search Spaces y que los dispositivos está en cadadivisió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 deldispositivo. Para más explicaciones detalladas sobre las trazas del SDI, revise por favor los casosprácticos en este documento.
11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received
- Device= MTP00107B000FB1 - Registered - Supports 16 calls
En el componente de la análisis de dígitos de la traza (arriba), los “pss” (espacio de búsqueda dela división, también conocido como Calling Search Space) son mencionados para el dispositivoque 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.
11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received
- Device= MTP00107B000FB1 - Registered - Supports 16 calls
Del ejemplo anterior, es dominante que usted nota que “PotentialMatchesExist” es el resultado deuna análisis de dígitos de los números que fueron marcados hasta que el exacto - se encuentra lacoincidencia 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 elCalling Search Space del dispositivo. Una vez más es dominante que usted observa que la rutinade la análisis de dígitos tenía coincidencias potenciales hasta que solamente el primer dígito fueramarcado. El patrón de ruta asociado al dígito el "1" está en una división que no esté en el CallingSearch Space del dispositivo, “RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP”. Por lotanto el teléfono fue enviado Tono de reordenamiento.
11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received
- Device= MTP00107B000FB1 - Registered - Supports 16 calls
Las divisiones de la ruta trabajan asociando un nombre de la división a cada número de directorioen el sistema. El número de directorio puede ser llamado solamente si el dispositivo de llamadacontiene la división dentro de una lista de divisiones a las cuales se permita para poner lasllamadas en su espacio de búsqueda de la división. Esto proporciona el control extremadamentepotente sobre la encaminamiento.
Cuando se está poniendo una llamada, las tentativas de la análisis de dígitos de resolver eldireccionamiento marcado solamente en esas divisiones que el espacio de búsqueda de ladivisión especifica. Cada nombre de la división comprende un subconjunto discreto del espacio dela dirección del marcable global. De cada división mencionada, la análisis de dígitos extrae elmodelo que ese mejor hace juego la secuencia de dígitos marcados. Entonces, entre de losmodelos que corresponden con, la análisis de dígitos elige la mejor coincidencia. Si dos modeloshacen juego igualmente la secuencia de dígitos marcados, la análisis de dígitos selecciona elmodelo 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).
Security
El Cisco CallManager se puede configurar para crear un plan de marcación seguro para losusuarios. Esto se puede hacer con el uso de las divisiones y del Calling Search Spaces, ademásde una filtración más común basada en las secciones “@” de la macro (que significa el NorthAmerican Numbering Plan) en un patrón de ruta, tal como el código de área. Las divisiones y elCalling Search Spaces son una parte integrante de Seguridad y son especialmente útiles para losentornos del multi-arrendatario y crear un nivel de usuario individual. La filtración es unsubconjunto del concepto del Calling Search Space/de la división que puede agregar elgranularity adicional al plan de la Seguridad.
Esto es una extensión a la sección del Plan de marcado, arriba. Aconséjese, él no esrecomendable ejecutar una traza del SDI al intentar reparar un problema de filtración. No haybastante 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ónaparece en la sección del filtro de la ruta.
Demostración-tecnología
Nombre dialPlanWizardG Cláusula
CiscoDallasInte 1 (INTERNATIONAL-CiscoRTPTollByP 1 (== 9 AREA-CODECiscoRTPLongDis 1 (AREA-CODE EXIS
CiscoDallasToll 1 (== 9 AREA-CODE
CiscoDallas911R 1 (== 911 delSERVICIO
CiscoRTPLocal7D 1 (EL AREA-CODE
HACECiscoDallasLong 1 (AREA-CODE EXIS
CiscoRTP911RF 1 (== 911 delSERVICIO
CiscoRTPInterna 1 (INTERNATIONAL-
CiscoDallasLoca 1 (LOCAL-AREA-COD
Desafortunadamente, esta visualización es incompleta. , Sin embargo, da un anuncio de todos losfiltros 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 ala página del informe de la ruta Plan. Abajo está una opción en el Lado derecho lejano “a ver en elarchivo”.
La salida será un archivo separado por coma que se puede ver en Microsoft Excel o unaaplicación similar:
salida del archivo de la Demostración-tecnología
Pattern/DN División
Usodelmodelo
Nombre deldispositivo
Descripción deldispositivo
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.@ CiscoDallasLoc Rutea CiscoDallasLocalRL
alPT r
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 laruta o el Calling Search Spaces de los números de directorio. Más información está disponible enel informe del plan de la ruta real. Si usted necesita entrar en contacto el TAC de Cisco, usteddebe 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/delGrupo de Routes/gateway.
Respuesta lenta del servidor
La respuesta lenta del servidor podría resultar si el duplex del Switch no hace juego el duplex delCisco 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 deberecomenzar 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 dereordenamiento si están intentando hacer una llamada restricta o llamar un número se habloqueado que. Un Tono de reordenamiento puede ocurrir si el Número marcado es Out OfService o si el PSTN tiene un problema del equipo o del servicio. Esté seguro que el dispositivoque daba el Tono de reordenamiento se ha registrado. También, marque su configuración de plande marcado para asegurarse de que la llamada puede ser ruteada con éxito.
Pasos para resolver problemas los Tonos de reordenamiento a través de los gatewayes:
Marque los gatewayes para asegurarse de que usted está utilizando las cargas del últimosoftware.
1.
Marque CCO (Cisco Connection Online en www.cisco.com) para las cargas del últimosoftware, las nuevas correcciones, o los Release Note referente al problema.
2.
Comience una traza del SDI y reconstruya el problema. Los Tonos de reordenamientopodrían ser el resultado de un problema de configuración con el control de admisión locationbasado o el control de admisión portero-basado donde el Cisco CallManager pudo limitar elnúmero de llamadas permisibles. En la traza del SDI, localice la llamada para determinar sifue bloqueada intencionalmente por un patrón de ruta o el Calling Search Space, o porcualquier otro ajuste de la configuración.
3.
Los Tonos de reordenamiento pueden también ocurrir al llamar con el PSTN. Marque latraza del SDI para los mensajes de la desconexión del q.931. Si un mensaje de ladesconexión del q.931 está presente, significa que el otro partido causó la desconexión y nopodemos corregir eso.
4.
Problemas con el registro de la gateway
Uno de la mayoría de los problemas frecuentes encontrados con los gatewayes en un CiscoCallManager 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 accesoanalógico AS-X, AT-X y acceso digital DT-24+ y DE-30+ pertenece a una categoría. Estosgatewayes son las unidades autónomas que no están conectadas directamente con unprocesador de administración de red (NMP). La segunda categoría incluye el acceso analógicoWS-X6624 y el acceso digital WS-X6608. Estos gatewayes son cuchillas instaladas en un chasisdel 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 ennegrita. 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 gatewayse 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 elgateway se reajuste si no puede completar el proceso de inscripción después de cerca de 2 a 3minutos. Así pues, usted puede suceder mirar el latido del corazón LED mientras que eldispositivo 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ónLED es el indicador luminoso verde del extremo derecho que muestra en el panel frontal. En elgateway DT-24+ o DE-30+, es el LED rojo de la parte izquierda en el borde superior del indicadorluminoso 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 elborde de placa del extremo derecho cerca del frente. Finalmente, en el acceso digital WS-X6608hay un latido del corazón separado LED para cada uno de los 8 palmos en la cuchilla. Hay 8 LEDrojos a través del indicador luminoso LED amarillo de la placa muestra gravedad menor (no visibledel 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ónomodebe recibir su dirección IP vía el DHCP o el BOOTP. Un gateway de Catalyst puede recibir sudirección IP por el DHCP, BOOTP, o por la configuración manual con el NMP. Si usted tieneacceso al servidor DHCP, la mejor manera de marcar un gateway autónomo es verificar que eldispositivo tiene un arriendo excepcional en una dirección IP. Si el gateway aparece en suservidor, é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 deun par de minutos, después todo está trabajando muy bien en esta área. ¿Si no, entonces o elgateway no puede entrar en contacto al servidor DHCP (es un router configurado incorrectamentey que no remite los broadcastes DHCP? Es el servidor que se ejecuta?), o no puede conseguiruna respuesta positiva (es el pool de la dirección IP agotado?). Si marcar estas sugerencias norinde 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 elgateway. Usted puede marcar esto intentando hacer ping a su IP Address interno del NMP. Ladirección IP está en el formato:
127.1.module.port
Así pues, en nuestro ejemplo, haríamos:
11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received
- Device= MTP00107B000FB1 - Registered - Supports 16 calls
Si hace ping los trabajos, entonces el comando show port mostrará la información de la direcciónIP. Aseegurese la información de la dirección IP y la dirección IP TFTP está correcta también. Siel gateway no está pudiendo obtener la información DHCP válida, la utilidad tracy (que se puedesuministrar por el TAC de Cisco) se puede utilizar para determinar el problema. Publique elcomando 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í quees 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. Sinembargo, 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 problemaque entra en contacto al 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 elmismo VLA N que el gateway del Catalyst 6000, después aseegurese los IP Helper Addressapropiados haber sido configurado para remitir los pedidos de DHCP al servidor DHCP. Esposible que el gateway consiga pegado en el estado de Init después de un cambio del númeroVLAN hasta las restauraciones del gateway. Cuando en este estado, usted puede intentarreajustar 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 siguientescomandos:
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í comienceuna traza de sniffer para ver si se están enviando las solicitudes y si está respondiendo elservidor.
Una vez que el DHCP está trabajando correctamente, el gateway tendrá una dirección IP quepermita el uso de la utilidad de debugging de Tracy. Esta utilidad es una característicaincorporada del comando set NMP para los gatewayes de Catalyst y está disponible comoaplicació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 losgatewayes, proporciona una ventana separada de la traza para cada gateway (hasta ocho sepueden localizar inmediatamente), y permite que las trazas sean registradas directamente a unarchivo que usted especifica.
El siguiente paso es verificar que el TFTP Server IP Address fue proporcionado correctamente algateway. Esto es proporcionada normalmente por el DHCP en la opción 66 (por nombre odirección IP), la opción 150 (dirección IP solamente), o el si_addr (dirección IP solamente). Si suservidor tiene opciones múltiples configuradas, el si_addr tomará la precedencia sobre la Opción150, que tomará la precedencia sobre la Opción 66. Si la opción 66 proporciona DNS_NAME delservidor TFTP, después el IP Address de los servidores DNS se debe haber especificado por elDHCP, 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 operadorde 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 esacertado, la dirección IP del CiscoCM1 tomará a precedencia sobre cualquier cosa el servidorDHCP 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 eltaskID para la línea siguiente. Por ejemplo, para el gateway del acceso digital WS-X6624, elcomando 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 quesus opciones 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 elgateway está consiguiendo su archivo de configuración del servidor TFTP. Si usted ve el siguienteen la salida del tracy, su servicio TFTP no puede trabajar correctamente o el gateway no se pudoconfigurar 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 unarchivo de configuración. Esto está muy bien a menos que usted esté en un entorno agrupado enel cual el gateway necesite recibir su lista de Ciscos CallManageres redundantes. Si el indicadorluminoso LED amarillo de la placa muestra gravedad menor no está recibiendo su información
TFTP correctamente, marque servicio TFTP encendido el Cisco CallManager y aseegurese lo seestá 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 CiscoCallManager. 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 siguientesmensajes en la consola NMP cada dos minutos:
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!
Esto es lo que parecería la salida del tracy si el gateway no está en las base de dato delCallManager 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 elarchivo 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 seencontró 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, elmismo problema puede ocurrir cuando una carga de la nueva aplicación necesita conseguir sucarga correspondiente del DSP también. Si la nueva carga del DSP no se encuentra, un mensajesimilar aparecerá.
Las demostraciones siguientes la salida cuando un acceso analógico WS-X6224 se haconfigurado para extraer una carga incorrecta de la aplicación. La salida parece similar a la de ungateway 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 eltiempo eventual hacia fuera. Este problema puede ser resuelto corrigiendo el nombre del archivode la carga en la área de valores predeterminados del dispositivo de la administración delCallManager de Cisco.
Problemas del control de acceso
Antes de comenzar cualquier Troubleshooting de Gateway a Gatekeeper, verifique que hayconectividad del IP dentro de la red. Si se asume que hay conectividad del IP, utilice lainformación en esta sección para resolver problemas su gateway.
Troncos entre clústers solamente
Observe que el control del portero para la versión del CallManager de Cisco 3.0(1) estásolamente disponible para los troncos entre clústers. El control del portero es configurable paralos 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 nopueden enviar las llamadas telefónicas. Los problemas de configuración en el portero deben serel foco primario cuando el portero está publicando un ARJ. Sin embargo, abajo están las Pautasgenerales para resolver problemas:
Verifique la conectividad del IP del gateway al portero.1.Muestre el estatus del portero: verifique al portero que el estado está para arriba.2.¿Hay una subred de la zona definida en el portero? Si es así verifique que la subred delgateway esté en las subredes permitidas.
3.
Rechazos del registro (RRJ)
Se publican los RRJ cuando el Cisco CallManager no puede registrarse con el portero. Losproblemas 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 resolver problemas:
Verifique la conectividad del IP del gateway al portero.1.Muestre el estatus del portero: verifique al portero que el estado está para arriba.2.¿Hay una subred de la zona definida en el portero? Si es así verifique que la subred delgateway esté en las subredes permitidas.
3.
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 loscambios, aseegurese que usted comienza los procesos del utel, del ulite, del ulogremover y delupilot. 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 quese recomiencen los procesos.
Caso práctico I: Llamadas de Cisco IP Phone a Cisco IP Phonedentro de un agrupamiento
Este caso práctico discute detalladamente el flujo de llamada entre dos Teléfonos IP de Ciscodentro de un cluster, llamado una llamada dentro del clúster. Este caso práctico también se centraen la inicialización del Cisco CallManager y del Cisco IP Phone, el registro, y los procesos dekeepalive. Eso es seguida por una explicación detallada de un flujo de la llamada dentro delclúster. Estos procesos se explican usando las utilidades de rastreo y las herramientas discutidosen una sección anterior.
Topología de ejemplo
El diagrama siguiente representa la topología de ejemplo para este caso práctico. En el diagramahay dos clusteres nombrados el cluster 1 y el cluster 2. Los dos Ciscos CallManageres en elcluster 1 se llaman CCM3 y CCM4, mientras que los dos Ciscos CallManageres en el cluster 1 senombran 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 cluster2. Los IP Addresses de estos dos Teléfonos IP de Cisco son 172.16.70.230 (número de directorio1000) y 172.16.70.231 (número de directorio 1001), respectivamente.
Proceso de inicialización de Cisco IP Phone
Del Cisco IP Phone de la inicialización (o “arrancar el proceso”) se explica detalladamente abajo.
En la inicialización, el Cisco IP Phone envía una solicitud al servidor DHCP de conseguir unadirecció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).
1.
Si un nombre DNS del TFTP separa es enviado por el DHCP, después un DNS separa ladirección IP se requiere para asociar el nombre a una dirección IP. Se desvía este paso si elservidor DHCP envía la dirección IP del servidor TFTP. En este caso estudie, el servidorDHCP enviado la dirección IP del TFTP porque el DNS no fue configurado.
2.
Si un nombre de servidor TFTP no se incluye en la respuesta DHCP, después el Cisco IPPhone utiliza el valor por defecto Nombre del servidor.
3.
El archivo del archivo de configuración (.cnf) se extrae del servidor TFTP. Todos los archivosdel .cnf tienen el nombre SEP<mac_address>.cnf, donde está siglas el “SEP” para eltelé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 ladirección IP 172.16.70.230 (su dirección MAC es SEP0010EB001720), y el segundo CiscoIP Phone utiliza a la dirección IP 172.16.70.231 (su dirección MAC es SEP003094C26105).
4.
Todos los archivos del .cnf incluyen la dirección IP del Cisco CallManager primario ysecundario. El Cisco IP Phone utiliza la dirección IP para entrar en contacto el CallManagerprimario de Cisco y para registrarse.
5.
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 CiscoIP Phone, el Cisco IP Phone pedirá el nuevo ejecutable del servidor TFTP y lo reajustaráautomáticamente.
6.
El ejemplo siguiente de la traza de sniffer resume el proceso de inicialización del teléfono. Esteejemplo de seguimiento no se toma para la topología de ejemplo de este caso práctico, sino queproporciona un ejemplo de la serie de eventos que ocurre durante el proceso de inicialización delCisco IP Phone.
Proceso de registro de estación delgada
Los Teléfonos IP de Cisco comunican con el Cisco CallManager usando el Skinny StationProtocol de Cisco. El proceso de inscripción permite que una estación delgada, tal como un CiscoIP Phone, informe al Cisco CallManager su existencia y haga la llamada posible. La figurasiguiente muestra los diversos mensajes que se intercambian entre el Cisco IP Phone (la“estación”) y el Cisco CallManager.
Los mensajes principales en el proceso de inscripción de la estación delgada se describen en latabla siguiente.
Descripciones de proceso de inscripción de la estacióndelgadaMensaje Descripción
Registro de laestación
La estación envía este mensaje para anunciar suexistencia al Cisco CallManager que controla.
Restauraciónde laestación
El Cisco CallManager envía este mensaje paraordenar a la estación que reajuste sus procesos.
PuertoIP delaestación
La estación envía este mensaje paraproporcionar el Cisco CallManager con el puertodel User Datagram Protocol (UDP) que seutilizará con la secuencia RTP.
Elregistro de laestaciónreconoce
El Cisco CallManager envía este mensaje parareconocer el registro de una estación.
Rechazo delregistro de laestación
El Cisco CallManager envía este mensaje pararechazar una tentativa del registro del teléfonoindicado.
char text[StationMaxDisplayTextSize];
};
Where: el texto es una cadena de carácter,Largo máximo de 33 bytes, conteniendo unadescripción textual de la razón que el registroestá rechazado.
Petición delascapacidadesde laestación
El Cisco CallManager envía este mensaje parapedir las capacidades actuales de la estación.Las capacidades de la estación pueden incluir elestándar de compresión y otras capacidades deH.323.
Petición de laversión de laestación
La estación envía este mensaje para pedir elnúmero de la versión de la carga del softwarepara la estación.
Respuestade laversión de laestación
El Cisco CallManager envía este mensaje parainformar a la estación el número de versión desoftware apropiado.
Respuesta
La estación envía este mensaje al CiscoCallManager en respuesta a una petición de las
de lascapacidadesde laestación
capacidades de la estación. Las capacidades dela estación se ocultan en el Cisco CallManager yse utilizan para negociar las Capacidades delterminal con un terminal compatible de H.323.
Petición de laplantilla debotónde laestación
La estación envía este mensaje para pedir ladefinición de plantilla de botón para esa terminalespecífica o el Cisco IP Phone.
Respuestade laplantilla debotónde laestación
El Cisco CallManager envía este mensaje paraponer al día la información de la plantilla debotón contenida en la estación.
Petición de lafechadeltiempodeestación
La estación envía este mensaje para pedir lafecha y hora actual para el uso interno y paravisualizar como cadena de texto.
LaestacióndefinelaFechay hora
El Cisco CallManager utiliza este mensaje paraproporcionar la información de la fecha y hora ala estación. Proporciona la sincronización horariapara las estaciones.
Flujo de llamadas de un teléfono del IP de Cisco a otro teléfono del IP de Cisco enun agrupamiento
Esta sección describe un Cisco IP Phone (número de directorio 1000) que llama otro Cisco IPPhone (número de directorio 1001) dentro del mismo cluster. El cluster es un grupo de CiscosCallManageres que tienen una base de datos común de Publisher SQL y muchas bases de datosSQL del suscriptor.
En nuestra topología de ejemplo, CCM1 es el editor y CCM2 es un suscriptor. Los dos TeléfonosIP de Cisco (1000 y 1001) se registran a CCM1 y a CCM2, respectivamente. El flujo de llamadase muestra en el diagrama a continuación. Los dos Ciscos CallManageres dentro de un clustercomunican 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 elprotocolo subyacente) con el Cisco CallManager. Después de que la señalización de Control dellamadas se establezca entre los dos Teléfonos IP de Cisco y sus Ciscos CallManageresrespectivos, la secuencia RTP comienza a fluir directamente entre los dos teléfonos, tal y como semuestra en del diagrama a continuación. Los mensajes del flujo de llamado de estación Skinnypara esta llamada dentro del clúster se explican en la siguiente sección.
Intercambio de mensajes de estaciones “delgadas” entre teléfonos IP de Ciscodurante el flujo de llamadas
La figura siguiente muestra un intercambio de la muestra de los mensajes entre dos estacionesdelgadas. La estación delgada, o el Cisco IP Phone, inicia una conexión al Cisco CallManager, yentonces el Cisco CallManager realiza la análisis de dígitos antes de abrir una sesión del controlcon la estación delgada del destino. Mientras que el diagrama siguiente indica, los mensajes deestación delgada se escriben usando el nivel simple de Inglés así que pueden ser entendidosfá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ásdetalladamente en las secciones posteriores cuando se están examinando las trazas.
Proceso de Inicialización del Cisco CallManager
En esta sección el proceso de inicialización del Cisco CallManager será explicado con la ayudade las trazas que se capturan de CCM1 (identificado por la dirección IP 172.16.70.228). Según lodescrito previamente, las trazas del SDI son mismo una herramienta del Troubleshooting eficazporque detallan cada paquete enviado entre los puntos finales. Esta sección describirá loseventos que ocurren cuando se inicializa el Cisco CallManager. La comprensión de cómo leer latraza 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, yasí sucesivamente.
Los siguientes mensajes de la utilidad de rastreo del SDI del Cisco CallManager muestran elproceso de inicialización en uno de los Ciscos CallManageres, en este caso, CCM1. Revise lasdescripciones 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 labase de datos, que serían los primarios o la Base de datos del editor (para este caso).
●
El tercer mensaje indica que el Cisco CallManager escuchó los diversos mensajes en elpuerto TCP 8002.
●
El cuarto mensaje muestra que, después de escuchar estos mensajes, el Cisco CallManageragregó 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 delCallManager de Cisco corriente 3.0.20.
●
char text[StationMaxDisplayTextSize];
};
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 descritosdurante estos procesos pueden ser muy útiles al resolver problemas un problema relacionado conlas características en el Cisco CallManager.
Por ejemplo, asuma que las listas de la ruta no están funcionando y están inutilizables. Pararesolver problemas este problema, usted monitorearía estas trazas para determinar si el CiscoCallManager 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.
char text[StationMaxDisplayTextSize];
};
La traza siguiente muestra el routegroup que agrega el dispositivo 172.16.70.245, que es CCM3situado en el cluster 1 y consideraba un dispositivo de H.323. En este caso, el routegroup se creapara rutear las llamadas a CCM3 en el cluster 1 con el permiso del Cisco IOS Gatekeeper. Si hayun problema que rutea la llamada a un Cisco IP Phone situado en el cluster 1, después lossiguientes mensajes le ayudarían a encontrar la causa del problema.
char text[StationMaxDisplayTextSize];
};
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úmerode directorio de la base de datos.
char text[StationMaxDisplayTextSize];
};
En las trazas siguientes el administrador de dispositivo en el Cisco CallManager está inicializandoestáticamente dos dispositivos. El dispositivo con la dirección IP 172.17.70.226 es portero y eldispositivo 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.
char text[StationMaxDisplayTextSize];
};
Proceso de Registro del Cisco CallManager
Otra parte importante de la traza del SDI es el proceso de inscripción. Cuando un dispositivo seacciona para arriba, consigue la información vía el DHCP, conecta con el servidor TFTP para suarchivo 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 seejecutan en el Cisco CallManager pero se tratan internamente como diversos servicios externos ypor lo tanto se asignan un tcpHandle, número de socket, y número del puerto así como unNombre del dispositivo.
char text[StationMaxDisplayTextSize];
};
En la traza siguiente, los mensajes de estación delgada se envían entre un Cisco IP Phone y unCisco CallManager. El Cisco IP Phone (172.16.70.231) se está registrando con el CiscoCallManager. Refiera a las descripciones de los mensajes de estación delgada anterior en estasección para más información. Tan pronto como el Cisco CallManager reciba el pedido deinscripción de un Cisco IP Phone, asigna un número del tcpHandle a este dispositivo. Estenú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 determinadobuscando para o no perdiendo de vista el número del tcpHandle del dispositivo, que aparece en elmaleficio. 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 (adquiridodel servidor TFTP) que corresponde al dispositivo.
char text[StationMaxDisplayTextSize];
};
Proceso de señal de mantenimiento de Cisco CallManager
Amba la estación, el dispositivo, o el servicio y el Cisco CallManager utilizan los siguientesmensajes para mantener un conocimiento del canal de comunicaciones entre ellos. Los mensajesse utilizan para comenzar la secuencia del keepalive que se asegura de que el enlace decomunicaciones entre el Cisco CallManager y la estación siga siendo activo. Los siguientesmensajes pueden originar del Cisco CallManager o de la estación.
char text[StationMaxDisplayTextSize];
};
Los mensajes en la traza siguiente representan la secuencia del keepalive que indica que elenlace de comunicaciones entre el Cisco CallManager y la estación es activo. Una vez más estosmensajes pueden originar por el Cisco CallManager o la estación.
char text[StationMaxDisplayTextSize];
};
Seguimiento del Flujo de Llamadas dentro del Cluster del Cisco CallManager
Las trazas siguientes del SDI exploran detalladamente el flujo de la llamada dentro del clúster.Los Teléfonos IP de Cisco en el flujo de llamada se pueden identificar por el DN, el tcpHandle, yla 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, eltcpHandle= 0x4fbb150, dirección IP = 172.16.70.230). Recuerde que usted puede seguir undispositivo a través de la traza mirando el valor, el sello de fecha/hora, o el nombre de la manijaTCP del dispositivo. El valor de la manija TCP para el dispositivo sigue siendo lo mismo hasta quese reinicie el dispositivo o va off-liné.
Las trazas siguientes muestran que ha ido el Cisco IP Phone (1001) descolgado. La traza abajomuestra los mensajes únicos, manija TCP, y número al que se llamó cuáles se visualizan en elCisco IP Phone. No hay número que llama en este momento, porque el usuario no ha intentadomarcar ninguna dígitos. La información abajo está bajo la forma de mensajes de estación delgadaentre los Teléfonos IP de Cisco y el Cisco CallManager.
char text[StationMaxDisplayTextSize];
};
La traza siguiente muestra los mensajes de estación delgada que van del Cisco CallManager a unCisco IP Phone. El primer mensaje es encender la lámpara en el Cisco IP Phone de la partellamadora.
char text[StationMaxDisplayTextSize];
};
El mensaje stationOutputCallState es utilizado por el Cisco CallManager para notificar la estaciónde cierta información llamada-relacionada.
char text[StationMaxDisplayTextSize];
};
El mensaje stationOutputDisplayPromptStatus es utilizado por el Cisco CallManager para hacerun prompt de petición llamada-relacionado ser visualizado en el Cisco IP Phone.
char text[StationMaxDisplayTextSize];
};
El mensaje stationOutputSelectSoftKey es utilizado por el Cisco CallManager para hacer laestación delgada seleccionar a los conjuntos específicos de teclas programables.
char text[StationMaxDisplayTextSize];
};
El mensaje siguiente es utilizado por el Cisco CallManager para dar instrucciones la estacióndelgada en cuanto a la línea correcta contexto para la visualización.
char text[StationMaxDisplayTextSize];
};
En el siguiente mensaje, el proceso de la análisis de dígitos está listo para identificar los dígitosentrantes y marcarlos para saber si hay la encaminamiento potencial hace juego en la base dedatos. La entrada, cn=1001, representa el número de la parte llamadora. el "" del dd= representael dígito marcado, que mostraría el numero de parte llamado. Observe que los mensajesStationlnit son enviados por el teléfono, los mensajes de StationD son enviados por el CiscoCallManager, y la análisis de dígitos es realizada por el Cisco CallManager.
char text[StationMaxDisplayTextSize];
};
El mensaje siguiente del debug muestra que el Cisco CallManager está proporcionando al tono dediscado interior al Cisco IP Phone de la parte llamadora.
char text[StationMaxDisplayTextSize];
};
Una vez que el Cisco CallManager detecta un mensaje entrante y reconoce el botón 1 del telcladonumérico se ha presionado en el Cisco IP Phone, para inmediatamente el tono de la salida.
char text[StationMaxDisplayTextSize];
};
Una vez que el Cisco CallManager ha recibido bastantes dígitos para hacer juego, proporciona losresultados de la análisis de dígitos en un formato de la tabla. Cualquier dígitos adicionalespresionados en el teléfono después de que esta punta sea ignorada por el Cisco CallManager,puesto que una coincidencia se ha encontrado ya.
char text[StationMaxDisplayTextSize];
};
La traza siguiente muestra que el Cisco CallManager está enviando esta información a unteléfono de la Parte llamada (el teléfono es identificado por el número del tcpHandle).
char text[StationMaxDisplayTextSize];
};
La traza siguiente indica que el Cisco CallManager está ordenando la lámpara centellar para laindicación de la llamada entrante en el Cisco IP Phone de la Parte llamada.
char text[StationMaxDisplayTextSize];
};
En las trazas siguientes, el Cisco CallManager está proporcionando al campanero, a lanotificación en pantalla, y a la otra información llamada-relacionada al Cisco IP Phone de la Partellamada. Una vez más usted puede ver que todos los mensajes están dirigidos al mismo Cisco IPPhone porque el mismo tcpHandle se utiliza en las trazas.
char text[StationMaxDisplayTextSize];
};
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 losTeléfonos IP de Cisco.
char text[StationMaxDisplayTextSize];
};
En la traza siguiente, el Cisco CallManager proporciona alertar o un tono de llamada al Cisco IPPhone de la parte llamadora, notificando que se ha establecido la conexión.
char text[StationMaxDisplayTextSize];
};
En este momento, el Cisco IP Phone de la Parte llamada va descolgado. Por lo tanto, el CiscoCallManager para el generar del tono del campanero a la parte llamadora.
char text[StationMaxDisplayTextSize];
};
En los siguientes mensajes, el Cisco CallManager hace la estación delgada comenzar a recibiruna secuencia del unicast RTP. Para hacer así pues, el Cisco CallManager proporciona ladirección IP de la Parte llamada así como la información de códec, y tamaño de paquetes en elmilisegundo (milisegundos). PacketSize es un número entero que contiene el tiempo del muestreoen los milisegundos usados para crear los paquetes RTP.
Nota: Este valor se fija normalmente a 30msec. En este caso, se fija a 20msec.
char text[StationMaxDisplayTextSize];
};
Semejantemente, el Cisco CallManager proporciona la información a la Parte llamada (1000).
char text[StationMaxDisplayTextSize];
};
El Cisco CallManager ha recibido el mensaje de reconocimiento de la Parte llamada paraestablecer 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 informaciones sobre la estación delgada.Primero, contiene el estatus de la acción abierta. En segundo lugar, contiene la dirección depuerto y el número de la recepción para la transmisión al extremo remoto. La dirección IP deltransmisor (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).
char text[StationMaxDisplayTextSize];
};
Los siguientes mensajes son utilizados por el Cisco CallManager para pedir la estación paracomenzar a transmitir la secuencia de audio a la dirección IP remota y al número del puerto delteléfono del IP indicado de Cisco.
char text[StationMaxDisplayTextSize];
};
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 hacomenzado entre parte que recibe la llamada y parte que la realiza.
char text[StationMaxDisplayTextSize];
};
El Cisco IP Phone de la parte llamadora finalmente va el en-gancho, que termina todos losmensajes del control entre la estación delgada y el Cisco CallManager, así como la secuenciaRTP entre las estaciones delgadas.
char text[StationMaxDisplayTextSize];
};
Caso práctico II: Llamadas de teléfono del IP de Cisco a la puertade enlace de Cisco IOS
En el caso práctico anterior, el flujo de llamada y las técnicas de Troubleshooting de una llamadadentro del clúster fueron discutidos detalladamente. Este caso práctico examina un Cisco IPPhone que llama con un Cisco IOS Gateway a un teléfono conectado con un PBX local o enalguna parte en el PSTN. Conceptual, cuando la llamada alcanza el Cisco IOS Gateway, elgateway remitirá a llamada cualquiera a un teléfono que cuelga apagado de su puerto de laEstación de intercambio remota (FXS), o al PBX. Si la llamada se remite al PBX, podría terminar aun teléfono que colgaba apagado de un PBX local o el PBX lo remitirá sobre el PSTN y la llamadaterminará 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 oT1/PRI. Los gatewayes pueden ser los modelos 26XX, 36XX, 53XX o 6K.
Llamada de rastreo de flujos
Esta sección discute la llamada atraviesa los ejemplos seguimiento del CallManager del archivoCCM000000000 (refiera a la sección anterior para la ubicación del archivo). Las trazas en estecaso estudian el foco solamente en el flujo de llamada sí mismo, pues la información de traza másdetallada se ha explicado ya en el caso práctico anterior (inicialización, registro, mecanismo dekeepalive, y así sucesivamente).
En este flujo de llamada, un Cisco IP Phone (número de directorio 1001) situado en el cluster 2está 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 defecha/hora, o el nombre de la manija TCP del dispositivo. El valor de la manija TCP para eldispositivo 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 losmensajes ú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 marcarninguna dígitos.
char text[StationMaxDisplayTextSize];
};
En las trazas siguientes, el usuario está marcando los 3333, un en un momento del dígito. Elnúmero 3333 es el número de destino del teléfono, que está situado en alguna parte en la redPSTN. 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óndetallada de la análisis de dígitos fue proporcionada en el caso práctico anterior.
char text[StationMaxDisplayTextSize];
};
En las trazas siguientes, se ha completado la análisis de dígitos, han correspondido con lallamada y a la Parte llamada, y se ha analizado la información.
char text[StationMaxDisplayTextSize];
};
En las trazas siguientes, el número 0 indica la ubicación que origina, y el número 1 indica laUbicació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 lallamada fue originada de un Cisco IP Phone situado en un entorno LAN. El ancho de banda de laUbicación de destino es determinado por el BW = 64. El destino de llamada está a un teléfonosituado en un PSTN, y utilizan al tipo de códec es G.711 (64Kbps).
char text[StationMaxDisplayTextSize];
};
Las trazas siguientes muestran la información de la llamada y de la Parte llamada. En esteejemplo, el nombre y el número de la parte llamadora es lo mismo porque el administrador no haconfigurado un nombre de la visualización, tal como “John Smith.”
char text[StationMaxDisplayTextSize];
};
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 deH.323. Un protocolo es el H.225, que se utiliza sobre todo para la señalización de llamada y es unsubconjunto 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 delcompresor/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 escompleto, la función importante siguiente del H.245 está realizando una negociación de puertoUDP 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 mensajesetup H.225. Usted puede también ver los mensajes SAPI tradicionales del HDLC, la dirección IPde la parte llamada en el maleficio, y los números del puerto.
char text[StationMaxDisplayTextSize];
};
La traza siguiente muestra la información de la llamada y de la Parte llamada, así como elmensaje que alerta H.225. También se muestra la asignación del valor hex de un teléfono del IPde Cisco a la dirección IP. 172.16.70.231 es la dirección IP del Cisco IP Phone (1001).
char text[StationMaxDisplayTextSize];
};
La traza siguiente muestra el tipo de compresión usado para esta llamada (ley del µ de G.711).
char text[StationMaxDisplayTextSize];
};
Una vez que se ha enviado el mensaje de alerta H.225, la parte de siguiente H.323 es seinicializa: H.245. La traza siguiente muestra la información de la llamada y de la Parte llamada ylos mensajes H.245. Note que el valor de la manija TCP es lo mismo que antes, la indicación deesto es la continuación de la misma llamada.
char text[StationMaxDisplayTextSize];
};
La traza siguiente muestra el mensaje CONNECT H.225, así como la otra información que fueexplicada anterior. Cuando se recibe el mensaje CONNECT H.225, la llamada ha estadoconectada.
char text[StationMaxDisplayTextSize];
};
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 losmensajes flacos de la desconexión y se considera el mensaje entero H.225. Este último mensajeindica que se ha terminado la llamada.
char text[StationMaxDisplayTextSize];
};
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 latopologí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 elpedido de admisión (ARQ) para el Cisco CallManager (172.16.70.228), seguido por otrosmensajes RAS exitosos. Finalmente, el Cisco IOS Gatekeeper envía un mensaje del AdmissionConfirmed (ACF) al Cisco CallManager.
char text[StationMaxDisplayTextSize];
};
Los mensajes siguientes del debug muestran que la llamada está en curso.
char text[StationMaxDisplayTextSize];
};
Los mensajes siguientes del debug muestran que el Cisco IOS Gatekeeper ha recibido unapetición desunida (DRQ) del Cisco CallManager (172.16.70.228), y el Cisco IOS Gatekeeper haenviado un desembarazo confirmado (DCF) al Cisco CallManager.
char text[StationMaxDisplayTextSize];
};
El comando show gatekeeper endpoints en el Cisco IOS Gatekeeper muestra que los cuatroCiscos CallManageres están registrados con el Cisco IOS Gatekeeper. Recuerde que en latopología para este caso práctico, hay cuatro Ciscos CallManageres, dos en cada cluster. EsteCisco IOS Gatekeeper tiene dos zonas y cada zona tiene dos Ciscos CallManageres.
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 IOSGatekeeper detalladamente. Esta sección se centra en la salida de los debugs y los comandosshow en el Cisco IOS Gateway. En la topología para este caso práctico, las llamadas estánpasando a través de los gatewayes del Cisco IOS. El Cisco IOS Gateway interconecta al PSTN oal 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 h225del debug abajo.
En la salida de los debugs siguiente, el Cisco IOS Gateway está validando la petición de conexiónTCP del Cisco CallManager (172.16.70.228) en el puerto 2328 para el H.225.
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
La salida de los debugs siguiente muestra que los datos H.225 están viniendo del CiscoCallManager en esta sesión TCP. En esta salida de los debugs es importante notar elprotocolIdentifier, que indica la versión de H.323 que es utilizada. El debug siguiente muestra quese está utilizando la versión 2 de H.323. Parte que recibe la llamada y parte que la realiza losnúmeros también se muestran.
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
Lo que sigue es salida de los debugs para la Interfaz de programación de aplicación de control dellamada (CCAPi). El CCAPi está indicando una llamada entrante. Información de la parte querecibe la llamada y de la parte que la realiza puede también ser visto en el producto siguiente. ElCCAPi hace juego al dial peer 0, que es la dial peer por default. Está correspondiendo con al dialpeer 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.
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
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 partellamada en el paquete de pedidos.
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
La salida de los debugs siguiente muestra que los mensajes que alertan H.225 están volviendo alCisco CallManager.
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
Aviso en este paquete que el Cisco IOS también está enviando el direccionamiento H.245 y elnúmero del puerto al Cisco CallManager. El Cisco IOS Gateway enviará a veces eldireccionamiento inalcanzable, que podría causar no audio o el audio unidireccional.
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
La salida de los debugs siguiente muestra que está subiendo la sesión H.245. Usted puede ver laindicación de capacidad para la negociación de códec, así como cuántos bytes estarán presentesen cada paquetes de voz.
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
La salida de los debugs siguiente muestra que ambas partes negociaron correctamente yestuvieron de acuerdo con el codificador-decodificador de G.711 con 160 bytes de dato.
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
H.323 conecta y los mensajes de la desconexión se pueden considerar abajo.
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
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 delCisco 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 losgatewayes del Cisco IOS.
Han girado al comando debug isdn q931 en el Cisco IOS Gateway. Esto habilita el q.931, unSignaling Protocol de la capa tres para el canal D en el entorno ISDN. Cada vez que una llamadaes interfaz puesta de los T1/PRI, un paquete de la configuración debe ser enviado. El paquete dela configuración tiene siempre (descriptor del protocolo) paladio = 8, y genera un valor hex al azarpara 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 losdebugs abajo, la capacidad portadora es 0x8090A3, que está para la Voz. Parte que recibe lallamada 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 elsegundo valor es lo mismo (la CONFIGURACIÓN tenía a0 para el último pasado, y elCONNECT_ACK también tiene a0). El router es totalmente dependiente sobre el PSTN o el PBXasignar un canal portador (Canal B). Si el PSTN o el PBX no asigna un canal al router, la llamadano será ruteada. En nuestro caso, un mensaje CONNECT se recibe del Switch con el mismonúmero de referencia que fue recibido para ALERTAR (0x800B). Finalmente, usted puede ver elintercambio del mensaje DISCONNECT (Desconexión) seguido por los mensajes de la VERSIÓNy del RELEASE_COMP mientras que la llamada está siendo disconnected. Los mensajes delRELEASE_COMP son seguidos por una causa ID para el rechazo de llamada. La causa ID es unvalor hex. El significado de la causa puede ser encontrado decodificando el valor hex y siguiendocon su proveedor.
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
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 delCisco IOS: la interfaz del Cisco IOS Gateway al PSTN o al PBX, con las interfaces T1/CAS oT1/PRI. Los siguientes son las salidas de los debugs cuando los gatewayes del Cisco IOS tieneninterfaz 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 dedescolgado al Switch.
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
El mensaje siguiente del debug indica que el Switch está enviando el guiño después de recibir laseñal del cierre de Loop del Cisco IOS Gateway.
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
El mensaje siguiente del debug indica que va el Cisco IOS Gateway descolgado.
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
Lo que sigue es la salida de la descripción de la voz activa de la llamada de la demostración en elCisco IOS Gateway cuando la llamada está en curso. Números de origen/de destino de llamada yla 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+. Élpuede marcar el local y los números de larga distancia E.E.U.U. sin los problemas. Sin embargocuando él perfora los dígitos para un número internacional, él oye una pausa, y entonces unaseñal de ocupado.
Solución
Esto se ha visto en el pasado donde el switch CO no sabe ocuparse correctamente de la llamadaIE (elemento de información). Esto puede ser reparada fijando a la parte llamadora deladministrador de llamada que el tipo IE “fijó la llamada y el tipo llamado DN al desconocido” bajoparámetros del palmo DT24+.
Caso práctico III: Llamadas telefónicas de interagrupación detelé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 unallamada dentro del clúster y de una llamada del Cisco IP Phone con un Cisco IOS Gateway a unteléfono que colgaba apagado de un PBX local o en alguna parte en el PSTN se han discutidodetalladamente. Este caso práctico examina un Cisco IP Phone que llama otro Cisco IP Phonesituado en un clúster diferente. Conocen a este tipo de llamada también como llamada del CiscoIP 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 dosclusteres, cada uno que tiene dos Ciscos CallManageres. Hay también gatewayes del Cisco IOSy Cisco IOS Gatekeeper en el lugar.
Comunicación entre agrupaciones H.323
Como usted puede ver en la topología, el Cisco IP Phone en el cluster 1 está haciendo unallamada al Cisco IP Phone en la comunicación del Cisco CallManager del Inter-cluster del cluster2. ocurre usando el protocolo de la versión 2 de H.323. Hay también Cisco IOS Gatekeeper parael 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 CiscoCallManager, se pueden revisar en las secciones anteriores.
El proceso de flujo de llamada se muestra en el diagrama a continuación. El Cisco IP Phonepuede hablar con el Cisco CallManager vía el Skinny Station Protocol, y el Cisco CallManagerpuede hablar con el Cisco IOS Gatekeeper que usa el protocolo RAS de H.323. El mensaje delpedido de admisión (ARQ) se envía al Cisco IOS Gatekeeper, que envía el mensaje delAdmission Confirmed (ACF) después de aseegurarse que la llamada entre clústers se puedehacer usando el protocolo de la versión 2 de H.323. Una vez que está hecho, el trayecto de audiose hace usando el protocolo RTP entre los Teléfonos IP de Cisco en los clústeres diferentes.
Llamada de rastreo de flujos
Esta sección discute el flujo de llamada usando los ejemplos de seguimiento del SDI capturadosen el archivo CCM000000000. La ubicación de este archivo se puede encontrar en la secciónanterior. 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ácticoanterior (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 CiscoIP Phone (1001) situado en el cluster 1. recuerda que usted puede seguir un dispositivo a travésde 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 eldispositivo o va off-liné.
En las trazas siguientes, el Cisco IP Phone (2002) ha ido descolgado. La traza muestra losmensajes ú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 veren la salida de los debugs siguiente. El tipo de códec es ley del µ de G.711.
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
La llamada y el número de la parte llamada, que se asocia a una dirección IP y a un valor hex, sepueden considerar en las trazas siguientes.
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
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.
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
Falló el flujo de llamadas
La sección siguiente describe un flujo fracasado de la llamada entre clústers, como se ve en latraza del SDI. En las trazas abajo, el Cisco IP Phone (1001) ha ido descolgado. Una manija TCPse asigna al Cisco IP Phone.
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
En las trazas siguientes el usuario es marca número al que se llamó (2000) del Cisco IP Phone, yel proceso de la análisis de dígitos está intentando hacer juego el número.
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
La análisis de dígitos ahora se ha completado y los resultados se muestran en las trazassiguientes. Es importante observar que la referencia de PotentialMatches=NoPotentialMatchesExistabajo 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 porun mensaje del en-gancho.
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
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 cuentay Análisis de red.
La base de datos es una base de datos del Microsoft SQL server 7.0. El acceso a la base dedatos 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 lastablas 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 datosen 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 elregistro 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 la base de datos SQL como las llamadas sehacen de una forma constantes con la configuración de cada Cisco CallManager individual. Estaconfiguración se hace vía la pantalla de los parámetros de servicio en la administración delCallManager de Cisco.
Todos los expedientes se escriben a la base de datos primaria para un cluster. Si la base dedatos primaria no está disponible, los expedientes serán escritos a un de los otras bases de datosde backup. Una vez que la base de datos primaria está disponible, después los registros nuevosde la escritura continuarán en la base de datos primaria y los expedientes local-escritos seránmovidos al primario.
Lectura de registros
La manera más fácil a los leeres datos de la base de datos SQL puede ser utilizar el ODBC. Unacadena 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 delCallManager de Cisco 3.0(1) del software está instalada sobre una instalación existente, la basede datos pudo ser emigrada si fue pedida por la nueva instalación. En este caso la vieja base dedatos todavía existirá, y la nueva base de datos también existirá. Los nombres diferenciaránagregando uno al número del nombre. Por ejemplo, el nombre original es CCM0300. Después deuna migración, el más nuevo nombre de la base de datos será CCM0301. La base de datos delnúmero más elevado debe ser utilizada.
La base de datos primaria (máquina y nombre) funcionando por el cluster puede ser encontradaactualmente haciendo clic en el botón Details Button de la administración del CallManager deCisco (ayuda del tecleo para alcanzar a la pantalla de bienvenida donde se localiza el botónDetails Button). El registro en las máquinas que reciben una base de datos puede también sermarcado. 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 deconexión similar a ésa mostrada arriba con el nombre de la máquina y el nombre de la base dedatos de la base de datos primaria.
El acceso es controlado por medio de los usuarios SQL. La tabla siguiente especifica laidentificación del usuario y contraseña que debe ser utilizada al acceder las base de dato delCallManager de Cisco.
Tablas ID deusuario SQL
Contraseña Capacidad
CallDetailRecord,CallDetailRecordDiagnostic
CiscoCCMCDR dipsy
Delectura/grabación
(Otro) CiscoCCMReader
vaqueros Read only
Eliminación de registros
Puesto que el Cisco CallManager está confiando en las aplicaciones de terceros parapostprocesar los datos CDR, usted debe quitar los datos CDR cuando todas las aplicaciones seacaban con los datos. Puesto que esto implica el modificar de la base de datos, el usuario delCiscoCCMCDR debe ser utilizado.
Si los registros CDR acumulan a un Máximo configurado (10,000,000 registros CDR), los másviejos registros CDR serán quitados junto con los expedientes relacionados CMR una vez por eldía.
Al quitar los datos CDR después del análisis, esté seguro de quitar todos los expedientesrelacionados 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ásadelante 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 delCallDetailRecord 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 CMRpor el CDR.
La tabla CallDetailRecord contiene información alrededor los puntos finales de la llamada y deotros aspectos del Control de llamadas/de la encaminamiento de la llamada. La tablaCallDetailRecordDiagnostic contiene información alrededor la calidad del audio fluido de lallamada.
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 IPAddresses no se convierten fácilmente a los Nombres del dispositivo para poder determinar el tipode 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 alsistema local. Una pista es marcar el tipo de dispositivo de ambos extremos de la llamada. Siambos son teléfonos, después usted puede asumir que permanecía OnNet. Sin embargo, si unoes un gateway, más suposiciones deben ser hechas. Si el gateway es un tipo del accesoanalógico de dispositivo con los CRISOLES o puerto de estación, la llamada pudo apenas haberido a un teléfono analógico local, o pudo haber salido al PSTN. Mire el número marcado ycorrelacione esto al Plan de marcado sabido de estimar si fue la llamada OffNet. Si no, la llamadafue probablemente OnNet.
Marcador de los dígitos OffNet
Si una llamada se pone hacia fuera un gateway, los dígitos marcados para conseguir al gatewaypueden no ser los dígitos enviados al PSTN. El gateway puede ser inteligente y modificar elnúmero de directorio más lejos. Si éste es el caso, el Cisco CallManager no sabe, y el CDR noreflejará 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 ésosusados por el Cisco CallManager, y no no necesariamente ésos definidos en el registro CDR en labase 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í.
Todos los Contenidos no firmados son los Contenidos no firmados 32bit.
Conversiones de datos de campo
Hay algunos campos que requieren la conversión del formato decimal a otro formato para lasvisualizaciones. Esta sección define sus valores, y cómo convertirlos o donde conseguir lainformación sobre cómo convertirlos.
Valores del tiempo
Todos los valores del tiempo se representan como 32 números enteros sin signo del bit. Estevalor 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 WindowsNT (. El valor es un valor del tiempo universal coordinado (UTC) y representa el número desegundos 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 defecha/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 Contenidos no firmados. La base de datoslos 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 esrealmente un número no firmado). El valor hex 32bit representa cuatro bytes. Los cuatro bytesestán en el orden inversa (estándar de Intel). Para conseguir la dirección IP, invierta la pedido delos bytes y convierta cada byte a un número decimal. Los cuatro bytes resultantes representan loscampos 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 IPtiene 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 comosigue:Visualización de la base de datos = -1139627840.Esto convierte a un valor hex de0xBC12A8C0.Invierta los bytes hexadecimales = el C0A812BCCO A8 12 BCLos bytesconvirtieron del hex. al decimal = 192 168 18 188, que serían visualizados como192.168.18.188.
●
Ejemplo 2:Dirección IP 192.168.18.59Visualización de la base de datos = 991078592Estoconvierte a un valor hex de 0x3B12A8C0Invierta el orden de bytes = C0A8123BC0 A8 123BLos bytes convirtieron del hex. al decimal = 192 168 18 59 que serían visualizados como192.168.18.59.
●
Definición de campo CDR
La tabla siguiente proporciona las definiciones de campo para los CDR.
Definiciones de los camposCampo Definición
cdrRecordType
El tipo de este Contenido no firmadode registro especifica el tipo de esteexpediente específico. Podía seruna llamada de la llamada inicialrecord(0), del final record(1), o unCMR record(2).
másglobalCallIdentifier
El identificador de la llamada globalel identificador de la llamada globalconsiste en dos campos que seanambos Contenidos no firmados. Losvalores se deben tratar comoContenidos no firmados. Los doscampos son: El Contenido nofirmadoGlobalCallID_CallManagerID deGlobalCallID_CallID del Contenidono firmado esto es el identificador dellamada que se asigna a la llamadaentera. Todo registra asociado con
una llamada estándar tendrá elmismo identificador de la llamadaglobal.
másorigLegCallIdentifier
El Contenido no firmado delidentificador de llamada del Tramode origen esto es un Identificadorúnico que se utiliza para seguir elTramo de origen de una llamada. Esúnico dentro de un cluster.
dateTimeOrigination
El Contenido no firmado de lascreaciones de la fecha/de la hora dela llamada esto representa el tiempoque el dispositivo de origen de lallamada salió el gancho, o el tiempoque una llamada externa primero fuereconocida por el sistema (recibió elmensaje setup). El valor es un valordel tiempo universal coordinado(UTC), y representa el número desegundos desde el 1 de enero demedianoche (de 00:00:00), 1970.
origNodeId
El Contenido no firmado del ID delnodo del terminal original estecampo representa el nodo dentro delclúster del Cisco CallManager donderegistraron al originador de lallamada a la hora de esta llamada.
origSpan
El palmo del terminal original o elContenido no firmado del puertoeste campo contiene el número delpuerto o del palmo del terminaloriginal si la llamada originó a travésde un gateway. Si no, este campocontiene cero (0).
callingPartyNumber
El número de la parte llamadorahasta 25 caracteres esto es elnúmero de directorio del dispositivodel cual la llamada originó.
origIpPort
El Contenido no firmado del puertoIP de la parte llamadora este campocontiene el puerto IP del dispositivodel cual la llamada originó.
origIpAddr
El Contenido no firmado de ladirección IP de la parte llamadoraeste campo contiene la dirección IPdel dispositivo del cual la llamadaoriginó.
originalCallingPartyNumberPartition
La división de la parte llamadorahasta 50 caracteres este campocontiene la división asociada a laparte llamadora.
origCause_Location
El Contenido no firmado del valor deubicación de ISDN este campocontiene el valor de ubicación delelemento de información de causa.
origCause_Value
La causa de la parte llamadora delContenido no firmado de laterminación de llamada esta causarepresenta la razón que la llamadaal dispositivo de origen fueterminada. En el caso de lastransferencias, adelante, y asísucesivamente, la causa de laterminación de llamada puede serdiferente para el dispositivo deorigen y el dispositivo determinación. Así, hay dos camposde la causa asociados a cadallamada. Serán generalmente lomismo.
origMediaTransportAddress_IP
La dirección IP para el Contenido nofirmado de la conexión de mediosdel terminal original esto es el IPAddress de destino con el cual lasecuencia de medios del terminaloriginal fue conectada.
origMediaTransportAddress_Port
El puerto para el Contenido nofirmado de la conexión de mediosdel terminal original esto es el puertodestino con el cual la secuencia demedios del terminal original fueconectada.
origMediaCap_payloadCapability
El tipo de códec utilizó por elContenido no firmado del terminaloriginal que este campo contiene eltipo de códec (compresión o tipo decarga útil) que el terminal originalutilizó en el lado emisor durante estallamada. Puede ser diferente que eltipo de códec usado en su lado derecepción.
origMediaCap_maxFramesPerPacket
El número de milisegundos de losdatos por el Contenido no firmadodel paquete este campo contiene elnúmero de milisegundos de losdatos por el paquete enviado aldestino, por el terminal original deesta llamada. El tamaño de losdatos reales depende del tipo decódec que es utilizado para generarlos datos.
origMediaCap_g72 La velocidad de bits que se utilizará
3BitRate
por el Contenido no firmado deG.723 define la velocidad de bitsque se utilizará por G.723. Hayvalores 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 partidoque dura reorientó esto llama a 25caracteres que éste es el número dedirectorio del dispositivo másreciente que reorientó esta llamada.Este campo se aplica solamente alas llamadas que fueronreorientadas, por ejemplo lasllamadas en conferencia, lasllamadas reenviadas de la llamada,y así sucesivamente.
lastRedirectDnPartition
La división del teléfono que durareorientó esto llama a 50 caracteresque ésta es la división deldispositivo más reciente quereorientó esta llamada. Este campose aplica solamente a las llamadasque fueron reorientadas por ejemplolas llamadas en conferencia, lasllamadas reenviadas de la llamada,y así sucesivamente.
másdestLegIdentifier
El identificador de llamada para eltramo de destino del Contenido nofirmado de la llamada esto es unIdentificador único que se utilizapara seguir el tramo de destino deesta llamada. Es único dentro de uncluster.
destNodeId
El identificador de nodo para el nododonde estaba Contenido no firmadoel destino de la llamada registrado elnodo dentro del clúster del CiscoCallManager donde el dispositivo dedestino fue registrado a la hora deesta llamada.
palmo dest
El Contenido no firmado del palmo odel puerto del destino este campocontiene el número del puertodestino o del palmo si la llamada fueterminada a través de un gateway.Si no, este campo contiene a (0)ceros.
destIpAddrLa dirección IP a la cual la llamadaera Contenido no firmado entregadoeste campo contiene la dirección IP
de la conexión de la señalización enel dispositivo que terminó lallamada.
destIpPort
El puerto IP al cual la llamada eraContenido no firmado entregadoeste campo contiene el puerto IP dela conexión de la señalización en eldispositivo que terminó la llamada.
originalCalledPartyNumber
El destino recibió del originador dela llamada hasta 25 caracteres queeste campo contiene el número dedirectorio al cual la llamada eraoriginalmente extendida sobre labase de los dígitos marcó por elterminal original de la llamada. Si lallamada completa normalmente(significarla no fue remitida), estenúmero de directorio debe siempreser lo mismo que el“finalCalledPartyNumber”. Si lallamada fue remitida, este campocontiene el destino original de lallamada antes de que fuera remitido.
originalCalledPartyNumberPartition
La división de la Parte llamada hasta50 caracteres este campo contienela división asociada a la Partellamada.
finalCalledPartyNumber
El destino al cual la llamada fueentregada hasta 25 caracteres estecampo contiene el número dedirectorio al cual la llamada erarealmente extendida. Si la llamadacompleta normalmente (significarlano fue remitida), este número dedirectorio debe siempre ser lomismo que el“originalCalledPartyNumber”. Si lallamada fue remitida, este campocontiene el número de directorio deldestino final de la llamada despuésde todo adelante fue completado.
finalCalledPartyNumberPartition
La división se asoció al destino finalde la llamada. hasta 50 caractereseste campo contienen la divisiónasociada al destino al cual lallamada era realmente extendida. Enuna llamada normal, este campodebe ser lo mismo como“originalCalledPartyNumberPartition”. Si la llamada fue remitida, estecampo contiene la división deldestino final de la llamada después
de todo adelante fue completado.
destCause_location
El Contenido no firmado de laubicación de la causa de la Partellamada esto es el valor deubicación de ISDN del elemento deinformación de causa.
destCause_value
La causa de la Parte llamada delContenido no firmado de laterminación de llamada esta causarepresenta porqué la llamada aldispositivo de terminación fueterminada. En el caso de lastransferencias, adelante, y asísucesivamente, la causa de laterminación de llamada puede serdiferente para el beneficiario de lallamada y del terminal original de lallamada. Así, hay dos campos de lacausa asociados a cada llamada.Serán generalmente lo mismo.Cuando una tentativa se hace paraampliar una llamada a un dispositivoocupado se remita que, el código dela causa reflejará “ocupado” aunquela llamada fue conectada con undestino delantero.
destMediaTransportAddress_IP
La dirección IP para el Contenido nofirmado de la conexión de medios desalida de destino esto es la direcciónIP de las creaciones de la cual lasecuencia de medios del destino fueconectada.
destMediaTransportAddress_Port
El puerto para el Contenido nofirmado de la conexión de medios desalida de destino esto es el puertodel terminal original del cual lasecuencia de medios del destino fueconectada.
destMediaCap_payloadCapability
El tipo de códec utilizó por el destinoen el Contenido no firmado del ladoemisor que este campo contiene eltipo de códec (compresión o tipo decarga útil) que el destino utilizó ensu lado emisor durante estallamada. Puede ser diferente que eltipo de códec usado en su lado derecepción.
destMediaCap_maxFramesPerPacket
El número de milisegundos de losdatos por el Contenido no firmadodel paquete este campo contiene elnúmero de milisegundos de los
datos por el paquete enviado alterminal original por el destino deesta llamada. El tamaño de losdatos reales depende del tipo decódec que es utilizado para generarlos datos.
destMediaCap_g723BitRate
La velocidad de bits que se utilizarápor el Contenido no firmado deG.723 define la velocidad de bitsque se utilizará por G.723. Hayvalores 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 elContenido no firmado que ésta es lafecha y hora que la llamada fueconectada entre los dispositivos deorigen y destino. El valor es un valordel tiempo universal coordinado(UTC), y representa el número desegundos desde el 1 de enero demedianoche (de 00:00:00), 1970.
dateTimeDisconnect
Fecha/hora del Contenido nofirmado de la desconexión éste es eltiempo que la llamada eradisconnected entre los dispositivosde origen y destino, o en que lallamada fue derribada incluso sinunca fue conectada. El valor es unvalor del tiempo universalcoordinado (UTC), y representa elnúmero de segundos desde el 1 deenero de medianoche (de 00:00:00),1970.
duración
Duración de la llamada éste es elnúmero de segundos que la llamadafue conectada. Es la diferencia entrela fecha/la hora de conecta y lafecha/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 camposCampo Definición
cdrRecordType
El tipo de este Contenido no firmado deregistro especifica el tipo de esteexpediente específico. Será fijado alexpediente CMR.
másglobalCallIdentifier
El identificador de la llamada global paraesta llamada el identificador de la llamadaglobal consiste en dos campos que seanambos Contenidos no firmados. Losvalores se deben tratar como Contenidosno firmados. Los dos campos son: ElContenido no firmadoGlobalCallID_CallManagerID deGlobalCallID_CallID del Contenido nofirmado esto es el identificador de llamadaque se asigna a la llamada entera. Todoregistra asociado con una llamadaestándar tendrá el mismo identificador dela llamada global.
nodeID
El identificador de nodo del CiscoCallManager el nodo dentro del clúster delCisco CallManager donde este expedientefue generado.
máscallIdentifier
El Contenido no firmado del identificadorde llamada esto es un identificador deltramo de llamada que identifica a quétramo de llamada pertenece esteexpediente.
directoryNum
El número de directorio usado en estallamada esto es el número de directorio deldispositivo del cual estos diagnósticosfueron recogidos.
directoryNumPartition
La división asociada al número dedirectorio esto es la división del número dedirectorio en este expediente.
dateTimeStamp
La terminación de la fecha/de la hora de lallamada esto representa la horaaproximada que el dispositivo fue en elgancho. El tiempo se pone en elexpediente cuando el teléfono responde auna petición la información de diagnóstico.Esto es un valor del time_t.
numberPacketsSent
El número de paquetes envió el númerototal de paquetes de datos RTPtransmitidos por el dispositivo desdecomenzar la transmisión en esta conexión.El valor es cero si la conexión fue fijada enel modo “sólo recibir”.
numberOctetsSent
El número de octetos (bytes) de los datosenviados al otro va de fiesta al número totalde octetos de carga útil (es decir, noincluyendo la encabezado o el relleno)transmitidos en los paquetes de datos RTPpor el dispositivo desde comenzar latransmisión en esta conexión. El valor escero si la conexión fue fijada en el modo
“sólo recibir”.
numberPacketsReceived
El número de paquetes de datos recibidosdurante esta llamada que el número totalde paquetes de datos RTP recibió por eldispositivo desde comenzar a la recepciónen esta conexión. La cuenta incluye lospaquetes recibidos de las diferentesfuentes si esto es una llamada demultidifusión. El valor es cero si la conexiónfue fijada en el modo “sólo enviar”.
numberOctetsReceived
El número de octetos (bytes) de los datosrecibidos durante esta llamada el númerototal de octetos de carga útil (es decir, noincluyendo la encabezado o el relleno)recibió en los paquetes de datos RTP porel dispositivo desde comenzar a larecepción en esta conexión. La cuentaincluye los paquetes recibidos de lasdiferentes fuentes, si esto es una llamadade multidifusión. El valor es cero si laconexión fue fijada en el modo “sóloenviar”.
numberPacketsLost
Paquetes RTP perdidos durante estaconexión el número total de paquetes dedatos RTP que se han perdido desde elprincipio de la recepción. Este número sedefine como el número de paquetesesperados, menos el número de paquetesrecibidos realmente, donde el número depaquetes recibidos incluye cualquiera quees atrasado o duplica. Así, los paquetesque llegan tarde no se cuentan según loperdido, y la pérdida pueden ser negativossi hay duplicados. El número de paquetesesperados se define para ser el número desecuencia más reciente extendido recibido,como definido después, menos el númerode secuencia inicial recibido. El valor escero si la conexión fue fijada en el modo“sólo enviar”. (Para los detalles, vea el RFC1889)
jitter
La fluctuación entre llegadas durante estaconexión una estimación de las variacionesestadísticas del tiempo entre llegadas delpaquete de datos RTP, medidas en losmilisegundos y expresadas comoContenido no firmado. La fluctuación entrellegadas J se define para ser la desviaciónpromedio (valor absoluto alisado) de ladiferencia D en el espaciamiento delpaquete en el receptor comparado alremitente para un par de paquetes. Los
algoritmos detallados del cómputo seencuentran en el RFC 1889. El valor escero si la conexión fue fijada en el modo“sólo enviar”.
tiempo deespera
El tiempo de espera experimentó duranteesta conexión que el valor es unaestimación de la latencia de red, expresadaen los milisegundos. Éste es el valorpromedio de la diferencia entre el grupofecha/hora del Network Time Protocol(NTP) indicado por los remitentes de losmensajes RTP Control Protocol (RTCP) yel sello de fecha y hora del NTP de losreceptores, medido cuando se recibenestos mensajes. La media es obtenidasumando todas las estimaciones, despuésdividiendo por el número de mensajesRTCP se han recibido que. (Para losdetalles 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, peroalgunos campos no pueden ser utilizados. Si un campo no se utiliza, será en blanco si es uncampo de la cadena de ASCII, o el "0" si es un campo numérico. Cuando los serviciossuplementarios están implicados en una llamada, más registros de finalización de llamadaspueden ser escritos.
Además del registro de finalización de llamadas CDR, puede haber hasta un registro CMR porpunto final implicado en una llamada. En una llamada normal entre dos partidos cada uno usandoun Cisco IP Phone, habrá dos expedientes CMR escritos: uno para el terminal original y uno parael 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 registrosde diagnóstico, uno para cada punto final. En el expediente de EndCall, todos los campos puedencontener la información válida. La duración será siempre no-cero a menos que se habilite elindicador 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 noserán registrados. Si se habilita la registración de las llamadas con la duración cero, las cosassiguientes deben ser observadas.
Si la llamada fue abandonada (por ejemplo cuando un teléfono es gancho sacado y colocadodetrá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 queno fueron conectadas tendrán una “duración” de los ceros segundos. Cuando se abandonauna 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 quefuera conectada, los campos “primer Dest” y “Dest final” y sus divisiones asociadascontendrá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 lasllamadas normales a excepción del campo “originalCalledPartyNumber” y de los campos del“originalCalledPartyNumberPartition”. Estos campos contendrán el número de directorio y ladivisión para el destino que fue marcado originalmente por el terminal original de la llamada. Si lallamada fue remitida, los campos del “finalCalledPartyNumber” y del“finalCalledpartyNumberPartition” serán diferentes y contendrán el número de directorio y ladivisió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óndel 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 quecontienen los datos. El campo de la causa de la Parte llamada contendrá un código de la causaque indica porqué la llamada no fue conectada, y el IP de la Parte llamada y la fecha/la horaconectan 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ánregistradas 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 dosexpedientes CMR. Cada expediente de la llamada CMR contiene todos los campos identificadosarriba. Cuando los servicios suplementarios están implicados en una llamada, más de unexpediente puede ser escrito. Esta sección describe cuando los registros de diagnóstico seescriben para diversos tipos de llamada en el sistema.
Llamadas normales
Las llamadas normales registran exactamente dos expedientes CMR por la llamada, una paracada teléfono implicado en la llamada. Actualmente, solamente los Teléfonos IP de Cisco y losgatewayes 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 colocadetrá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 lasllamadas normales.
Llamadas con los destinos ocupados o malos
En el caso normal, solamente los expedientes que representan las llamadas que fueronconectadas realmente serán registrados. Para registrar las llamadas con los malos destinos,usted debe habilitar el “CdrLogCallsWithZeroDurationFlag.” Si se habilita, después todas lasllamadas 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 camposrelevantes que contienen los datos. Habrá solamente un expediente por la llamada puesto que lasllamadas nunca fueron conectadas con un destino. El expediente estará para el terminal originalde 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ódecCódec Descripción1 No estándar2 G711A-law 64k3 56K G711A-law4 G711µ-law 64k5 56K G711µ-law6 G722 64k7 56K G7228 G722 48k9 G723110 G72811 G72912 G729AnnexA13 Is11172AudioCap14 Is13818AudioCap15 G729AnnexB32 Datos 64k33 56K de los datos
80 GS81 ActiveVoice82 G726_32K83 G726_24K84 G726_16K
Códigos de causas
La tabla siguiente proporciona una lista de códigos de la causa que puedan aparecer en loscampos de la causa.
Descripciones del código de la causaCódigodelacausa
Descripción
0 Ningún error1 Número (no asignado) Unallocated
2 Ninguna ruta al transit network especificado (usonacional)
3 No hay ruta para el destino4 Enviar tonos especiales de información5 Prefijo del tronco Misdialed (uso nacional)6 Canal no aceptable
7 Llamada concedida y que es entregada en un canalestablecido
8 Prioritario
9 Derecho preferente de compra - circuito reservadopara la reutilización
16 Verificación normal de llamadas17 Usuario ocupado18 Sin respuesta de usuarios19 Ninguna respuesta del usuario (usuario alertado)20 Suscriptor ausente21 Llamada rechazada22 Número cambiado26 Verificación de usuarios no seleccionados27 Destino no disponible
28 Formato de número inválido (direccionamientoincompleto)
29 Recurso rechazado
30 Respuesta a STATUS ENQUIRY (consulta deestado)
31 Normal, sin especificar34 Ningún circuito/canal disponible38 Red no disponible
39 Conexión de modo de trama permanente fuera deservicio
40 Conexión de modo trama permanente operativa41 Falla temporal42 Congestión del equipo de switching43 Información de acceso descartada44 Circuito/canal requerido no disponible46 Llamada de la precedencia bloqueada47 Recurso inasequible, sin especificar49 Calidad de servicio no disponible
50 Prestación solicitada no disponibe (requieresuscripción)
53 Operación de servicio violada54 llamadas entrantes bloqueadas
55 Llamadas entrantes barradas dentro del Grupo deusuarios cerrado (CUG)
57 Capacidad portadora no autorizada58 Capacidad portadora no disponible actualmente
62 Inconsistencia en la información de acceso y laclase salientes señaladas del suscriptor
63 Servicio y opción disponible sin especificar65 Capacidad portadora no implementada66 Tipo de canal no implementado69 Recurso solicitado no implementado
70 Solamente la capacidad portadora restricta de lainformación digital está disponible (el uso nacional)
79 Servicio u opción no implementada, sin especificar81 Valor de referencia de llamada inválido82 No existe el canal identificado
83 Una llamada suspendida existe, pero esta identidadde la llamada no hace
84 Identidad de la llamada funcionando85 No se suspenden llamadas
86 La llamada que tenía la identidad de la llamadapedida se ha borrado
87 Miembro del usuario no del Grupo de usuarioscerrado (CUG)
88 Destino incompatible
90 Desaparecidos y DC del número de destino no
inscritos91 Selección inválida del transit network (uso nacional)95 Mensaje no válido, no especificado96 El elemento de información obligatoria falta97 Tipo de mensaje inexistente o no implementado
98El mensaje no es compatible con el estado de lallamada, o el Tipo de mensaje es inexistente o noimplementado
99 Un elemento de información o un parámetro noexiste ni se implementa
100 Contenidos de elemento de información no válidos
101
El mensaje no es compatible con el estado de lallamada
102
La llamada fue terminada cuando expiró untemporizador y una rutina de recuperación fueejecutada para recuperarse del error
103
Parámetro inexistente o no implementado - pasadoen (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 Ciscoespecífico. Se utiliza cuando una llamada se terminadurante una operación de transferencia porqueestuvo partida apagado y terminada (no estaba laparte de la llamada transferida final). El puedeayudar a determinar que las llamadas fueronterminadas como parte de una operación detransferencia.
127 Interconexión, sin especificar
Alarmas
Se publica una alarma cuando se habilita el CDR o los datos diagnósticos, y el sistema no puedeescribir 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 basede datos. Aseegurese el Cisco CallManager tiene privilegios que permitan escriban lasoperaciones.
●
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 porfavor 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 trazasdel 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 porfavor:haga el debug del inout del ccapi de la Vozdebug isdn q931solamente] xboard sh del vfc[AS5300[AS5300 solamente] versión dspware sh del vfc x[AS5300 solamente] versión vcwaresh del vfc x
●
Información Relacionada
Soporte de tecnología de voz●
Soporte de Productos de Voice and Unified Communications●
Troubleshooting de Cisco IP Telephony●
Soporte Técnico y Documentación - Cisco Systems●
