Problemas de comunicacion entre sucursales CUCM 8.5

[Jesus Centeno Carrillo]

Soy un poco nuevo en esto. Tengo un problema con mi CUCM 8.5.1... Se me ha presentado en dos oportunidades a lo largo de 6 meses, que las llamadas que se realizan desde mi sede en Venezuela hacia casa matriz dan tono ocupado, reinicio los SIP-Trunk que van hacia casa matriz y sigue el mismo problema. Solo se corrije si reinicio el CUCM, ¿Que sera lo que puede estar pasando o causando este problema? Gracias de antemano

[Adrian Saavedra]

Hola Jesús,

¿Qué hay en la casa matriz?. Si nos detallas un poco la topología te podremos ayudar mejor.

Saludos.

[Jesus Centeno Carrillo]

Basicamente hay otro CUCM 8.5, la conexión entre ambos se realiza por la fibra de una metro LAN desde aca de Venezuela establecida por un otro e igual en el extremo de europa (2Mb el enlace). A nivel logico hay desde aca 9 troncales SIP para manejar los diferentes tipos de llamadas que pueden generarse desde la sucursal a casa matriz. El codec preferido de los trunk es 711alaw. Y bueno como les comente, esto no pasa frecuentemente, sino cada tantos meses

[Leo Salcie Tejeda]

Hola Jesus,

Tienes un troncal SIP o un Intercluster Trunk entre los CUCM?

Please remember to rate useful posts clicking on the stars below.
Favor calificar todos las respuestas útiles.
___________________________________________
LinkedIn Profile: do.linkedin.com/in/leosalcie

[Jesus Centeno Carrillo]

Hola buenos días

SIP Trunk...

Gracias

[Leo Salcie Tejeda]

El SIP Trunk es utilizado para TEHO o solo para llamadas internas?

Has revisado si la conexion esta perdiendo paquetes? Existen errores en los puertos donde estan conecta

dos los servidores?

Please remember to rate useful posts clicking on the stars below.
Favor calificar todos las respuestas útiles.
___________________________________________
LinkedIn Profile: do.linkedin.com/in/leosalcie

[Jesus Centeno Carrillo]

TEHO, y no se observan errores en los puertos donde estan los servidores. Diera la impresión aca en Venezuela que pareciera que algo esta haciendo que el CUCM de Vzla llegue al punto de quedarse sin recursos o algo parecido

[Adrian Saavedra]

Hola Jesús,

Lo que se utiliza por recomendación para intercontectar clusters de UCM es un Intercluster Trunk (Non-Gatekeeper Controlled). No sé si el SIP trunk lo tendrás habilitado para utilizar mtp software, pero si lo tuviera, a veces estos recursos pueden llegar a agotarse ocasionando que las llamadas suenen ocupadas y no funcionen (lo arregla un reinicio del SIP trunk o bien meterle más recursos en software o hardware).

Una vez en el pasado tuve un problema con un SIP trunk en un UCM contra una PBX y tenía que utilizar MTP forzosamente, al tiempo me reportaban que las llamadas no funcionaban y noté que era un problema con los recursos MTP por lo que esa vez tuve que introducir más recursos. Por aquello, si usas MTP por alguna razón, puedes monitorear el uso a través del RealTime Monitoring Tool.

Finalmente, yo mejor te recomiendo que pases la configuración a un ICT y monitorear el comportamiento.

Espero que sea de utilidad, si es así recuerda calificar el post.

Saludos!.

- Adrián.

[Jesus Centeno Carrillo]

En efecto los SIP Trunk estan habilitados para utilizar MTP. Ahora lo que me parece raro es que las pocas veces que la situación se ha presentado, el reinicio de los SIP Trunk no basta, sigue sonando un tono de ocupado para las llamadas asi que puedo asumir por tu respuesta que es un problema que mas bien sería solucionado con ampliar los recursos. Ahora tengo dos preguntas. Específicamente a que te refieres con aumentar la cantidad de recursos en "software o hardware"? y la otra pregunta es ¿Que es lo que específicamente monitorearía en el RTMT y que patrones o indicativos son los que necesito encontrar para corroborar la teoría que estamos discutiendo?

[Adrian Saavedra]

Hola Jesús,

Correcto... reiniciando sólo el SIP trunk no bastaría, más bien habría que reiniciar específicamente los recursos de MTP en el CUCM (desde la pestañana Media Resources -> Media Termination Point) o bien puedes también reiniciar el servicio de Cisco IP Voice Media Streaming Application desde la página de Serviceability. Con esto no tendrías que reiniciar todo el servidor, sin embargo, reiniciar este servicio específico también reiniciaría otros recursos de software que controla como por ejemplo el MoH, Conference Bridge, Annunciator, etc (pero por lo menos no afectarías todo el servicio telefónico). Cuando se te presente otra vez el problema, intenta reiniciar el servicio o nada más los MTPs. Si el problema se corrige es porque el server tiene algún problema con los MTP o simplemente se agotan.

En este link, podrás leer información acerca de los recursos MTP y su aplicación. Los MTP en software son típicamente recursos que se instalan por defecto cuando se instala un CUCM. Si requieres recursos en hardware típicamente se implementan por medio de los PVDM2/PDVM3 en un enrutador.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab09/media.html#wp1046314

Acá tienes la guía de administración del RTMT. Puedes descargar el RTMT del CUCM e instalarlo en tu computador y podrás ver que es fácil de utilizar, ahí podrás escoger varias opciones donde te puede gráficar el uso de CPU, memoria, uso de recursos, teléfonos registrados, etc, etc:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/8_5_1/rtmt/RTMT.html

Esto es lo que monitorea con respecto a los recursos MTP del cluster:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/8_5_1/rtmt/rtpmcm.html#wp1064402

Nuevamente, me parece que podrías ahorrarte tiempo, recursos (eventualmente) y troubleshooting pasando la comunicación de los clusters de SIP a un ICT.

Espero que sea de utilidad, si es así recuerda calificar el post.

Saludos!!

[Jesus Centeno Carrillo]

Muchisimas gracias por el apoyo. Respecto a los cambios planteados puedo hacer la sugerencia y antes claro investigar un poco con la finalidad claro de sustentar la recomendación, esto en vista de que los cambios en casa matriz no son ya manejados por nosotros desde acá.

Nuevamente gracias por la info. Saludos!