10-09-2020 05:32 PM - editado 10-09-2020 05:33 PM
-Este tipo de evento era formalmente conocido como Pregunte al Experto-
Aclare todas sus dudas de las mejores prácticas, tips y work arounds para hacer troubleshooting en Call Manager.
Actualmente, Call Manager es una base fundamental de las soluciones de comunicaciones unificadas (UC) de Cisco. Call Manager provee el servicio de telefonía IP y puede integrar toda la gama de productos de UC de Cisco. Esta sesión es de gran ayuda para aquellos que soportan Call Manager y las soluciones mencionadas.
Haga sus preguntas del 12 de al 28 de Octubre del 2020.
Visite nuestra categoría de Coaboración, Voz y Video para más información del tema.
** ¡Los puntos de utilidad fomentan la participación! **
Por favor asegúrese de dar uno a las respuestas a sus preguntas.
el 10-13-2020 11:04 AM
Buenas tenemos un problema que no repica la ext 5000 cuando llaman de la calle al numero que se tiene en el puerto FXO
dial-peer voice 1 pots
trunkgroup OTAMA
description LLAMADAS SALIENTES CANTV
preference 1
destination-pattern 9.T
!
dial-peer voice 2000 voip
destination-pattern 2...
session protocol sipv2
session target ipv4:172.20.20.21
dtmf-relay sip-notify rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 7000 voip
description LLAMADAS INTERNAS Valencia
destination-pattern 70..
session target ipv4:10.20.20.8
dtmf-relay h245-signal rtp-nte cisco-rtp
codec g711ulaw
!
dial-peer voice 6000 voip
session protocol sipv2
session target ipv4:10.10.10.1
dtmf-relay rtp-nte
codec g729br8
!
dial-peer voice 200 voip
description **Llamadas salientes por el SIP Trunk**
destination-pattern 60..
session target ipv4:10.20.20.8
voice-class codec 1
dtmf-relay rtp-nte cisco-rtp h245-signal
no vad
!
dial-peer voice 8000 voip
description Llamadas internas Cisco Jabber
destination-pattern 80..
session target ipv4:10.20.20.8
dtmf-relay h245-signal rtp-nte cisco-rtp
codec g711ulaw
!
dial-peer voice 3 pots
translation-profile incoming ENTRANTE-CPA
incoming called-number 64..
supplementary-service pass-through
no digit-strip
direct-inward-dial
port 0/2/0
forward-digits all
voice-port 0/2/0
trunk-group OTAMA
no battery-reversal
input gain 14
output attenuation -6
connection plar 5000
caller-id enable
cabe destacar que poseo un CUCM y esto que muestro anteriormente esta en el Router.
el 10-13-2020 12:20 PM
Hola @Grupo Merino
Lo primero y más importante al hacer resolución de problemas es el flujo de la llamada, por ejemplo:
PSTN—E1R2—GW(ISR4321)—SIP---CUCM---SCCP---7941 x5000
Segundo, una descripción corta y precisa del problema incluyendo números involucrados, por ejemplo:
“5551743278 marca al número 3310382122 que es nuestro número piloto en una troncal E1R2, la llamada debe entrar y hacer match en el dial peer 200, la llamada debe ser transformada y enrutada al puerto FXS 0/2/0, pero no sucede así.”
Me imagino que la llamada entra por el dial peer 3:
dial-peer voice 3 pots
translation-profile incoming ENTRANTE-CPA
incoming called-number 64..
supplementary-service pass-through
no digit-strip
direct-inward-dial
port 0/2/0
forward-digits all
Pero nunca es bueno asumir, ¿me pudieras proporcionar más información acerca de tu problema? Describir el flujo de la llamada completo y compartir los siguientes debugs después de una prueba de una llamada fallida:
!---PREPARE THE LOGGING BUFFER---
configure terminal
service timestamps debug datetime local msec
service timestamps log datetime local msec
service sequence-numbers
no logging console
no logging monitor
no logging rate-limit
no logging queue-limit
logging buffer 3000000 debug
end
!---ENABLE DEBUGS FXS+SIP---
debug voip vtsp all
debug vpm signal
debug voip vtsp default
debug voip vtsp session
debug voip ccapi inout
!SIP
debug ccsip messages
debug ccsip media
debug ccsip event
debug ccsip error
!---CLEAR THE LOG---
clear logging
<confirm>
!---TEST CALL---
!---DUMP LOGS---
terminal length 0
show logging
terminal default length
el 10-20-2020 11:26 AM
Hola @rrendon
¿Cómo se puede verificar que una llamada es correctamente verificada en call manager CUCM)?
el 10-21-2020 08:42 AM
Hola @Cisco Moderador !
La forma más sencilla de verificar una llamada en Call Manager es a través de CAR, no es una herramienta de troubleshooting pero nos da información de los número involucrados en la llamada, la hora y fecha en la que se realizó y la razón por la cual se terminó la llamada, lo cual nos puede dar una idea de la causa de una falla.
Para entrar a CAR:
Para realizar troubleshooting a fondo de la causa de la falla en una llamada siempre es necesario revisar la trazas/logs del servicio “Cisco CallManager” de CUCM.
el 10-20-2020 11:48 AM
Hola ingeniero, gracias por la oportunidad. Queremos verificar los servicios de call manager ¿nos puede indicar cómo hacerlo? Por favor y gracias
el 10-21-2020 08:03 AM
Hola @dulfranc1!
Para verificar los servicios de Call Manager hay dos formas de hacerlo:
Nota, los servicios deben activarse a través de la interface grafica (Tools > Service Activation ) antes de poder ser iniciados.
el 10-21-2020 03:38 PM - fecha de última edición 10-22-2020 03:40 PM por ciscomoderator
Gracias por la respuesta ingeniero Ricardo, solo una duda. el proceso que comenta es similar en las distintas versiones de CUCM?
el 10-22-2020 07:39 AM
El proceso es el mismo en todas las versiones que corren sobre Linux, CUCM corre en RHEL desde la version 5.0.
el 10-21-2020 09:12 PM
Cordial saludo,
Ingeniero Ricardo, mi pregunta es la siguiente mi empresa trabaja con la versión 11.5 en CUCM y UCCX. Se debería actualizar la versión a la mas reciente o mantenerse con la actual. Y la justificación en su respuesta por favor, para así proyectar a la mis superiores una recomendación.
el 10-22-2020 08:55 AM
Hola @giammanuelle !
Aquí te presento la lista de mejoras implementadas en CUCM 12.5:
Mi recomendación es actualizar inmediatamente solo si requieres de alguna de las características o funciones del producto nuevo, lo mejor esperar a que la nueva versión de CUCM sea madura y estable, al menos 1 año después de lanzada, en el caso de CUCM 12.5 este periodo ya se cumple y ya puedes actualizar para sacar provecho de las nuevas características y funcionalidad, de entre las cuales podemos mencionar las siguientes como más relevantes:
Si requieres actualizar por alguna característica que no tienes en 11.5, recomiendo actualizar, de lo contrario tienes en tus manos un producto con años de vida útil y soporte garantizado, yo esperaria al anuncio de EOS para CUCM 11.5 y entonces actualizaria.
el 10-22-2020 11:09 AM
Muchas Gracias Ingeniero Ricardo por su asesoría.
el 10-22-2020 11:23 AM
Cordial saludo,
Ingeniero, mi solución BE6000 con CUCM y UCCX versión 11.5 funciona para la línea de emergencia en mi ciudad, pero en los últimos días los agentes me han comentado que están recibiendo llamadas que son para otras entidades, y son llamadas que no tienen que ver con alguna emergencia; y se le pregunta a la persona que llama que numero marco y ellos exponen que no marco a la línea de emergencia, y además de eso se tiene configurado un mensaje de voz para así informar al llamante.
Mi pregunta es, si esta novedad es de competencia del operador del servicio (E1) que se conecta a nuestra solución de voz o de los diferentes operadores que se tienen. Y si hay alguna forma de verificar esta situación en mi GW comandos que me puedan ayudar deducir la falla donde radica.
mi configuración es :
PSTN—E1R2—GW(ISR4331)—SIP---CUCM---UCCX--SIP---7941
De ante mano le agradezco su ayuda Ingeniero.
el 10-23-2020 11:22 AM
Hola @giammanuelle !
Si la llamada no es dirigida al route point de emergencia en CUCM es posible que el ruteo de llamada este fallando en el Gateway de voz de ingreso o en call manager, todo depende de los números usados y los dial peers configurados en el el Gateway o en los route patterns, translation patterns y demás configuraciones de ruteo de voz en CUCM.
Para el GW te recomiendo usar los siguientes debugs y buscar los dial peers involucrados en la salida del ruteador.
!---PREPARE THE LOGGING BUFFER---
configure terminal
service timestamps debug datetime local msec
service timestamps log datetime local msec
service sequence-numbers
no logging console
no logging monitor
no logging rate-limit
no logging queue-limit
logging buffer 3000000 debug
end
!---ENABLE DEBUGS FXS+SIP---
debug voip ccapi inout
debug vpm signal
!---CLEAR THE LOG---
clear logging
<confirm>
!---TEST CALL---
!---DUMP LOGS---
terminal length 0
show logging
terminal default length
Comparte la salida de los debugs y la informacion de la llamada conmigo, numero llamado, numero que llama y hora de la llamada.
Saludos.
el 10-26-2020 09:10 AM
Buenos dias Ricardo.
Tengo un problema con la convivencia entre los E1 y los telefonos registrados en un GATEWAY en modo ESRST SIP, te platico.
Se tiene un telefono registrado en el Gateway, SIP generico de modo ESRST, cuando se realizan llamadas desde el a cualquier parte la llamada fucniona correctamente, cuando se realiza la llamada desde otro GATEWAY hacia el por protocolo IP, de igual forma la llamada fucniona correctamente, el problema esta cuando se le intenta marcar a ese telefono por los E1, la llamada nunca llega al telefono registrado en el GATEWAY.
El flujo de la llamada de problemas es el siguiente:
ALCATEL------->E1---->Gateway---->telefono SIP
PSTN_TELMEX--->E1---->gateway--->telefono SIP
Nota: si la llamada entra por el E1 y la manda por sus rutas IP a otro Gateway si funciona, pero en los telefonos que estan registrados en el GATEWAY de los E1 no.
registro de telefono en el GATEWAY:
GW_ZTNTE#show voice register dial-peers pool 1
Dial-peers for Pool 1:
dial-peer voice 40001 voip
destination-pattern 42852$
session target ipv4:10.21.25.240:5060
session protocol sipv2
dtmf-relay rtp-nte
digit collect kpml
voice-class codec 1
after-hours-exempt FALSE
Te anexo debugs y configuracion de Gateway, saludos.
Descubra y salve sus notas favoritas. Vuelva a encontrar las respuestas de los expertos, guías paso a paso, temas recientes y mucho más.
¿Es nuevo por aquí? Empiece con estos tips. Cómo usar la comunidad Guía para nuevos miembros
Navegue y encuentre contenido personalizado de la comunidad