Integración de MotoPBX y CUCM

Introducción

Este documento describe los problemas de interoperabilidad en relación con la integración del protocolo de inicio de sesión (SIP) de los sistemas Cisco Unified Communications Manager (CUCM) y Motorola PBX (MotoPBX). Los sistemas MotoPBX cumplen con SIP RFC 3581, mientras que CUCM cumple con SIP RFC 3261. Debido a este problema de conformidad con RFC, hay problemas con la configuración de llamadas SIP entre ambos servidores de procesamiento de llamadas, es decir, CUCM y Motorola PBX.

Background

Motorola PBX tiene un parámetro "port" en el campo de encabezado "Via" de SIP INVITE que permite a un cliente solicitar que el servidor envíe la respuesta de vuelta a la dirección IP de origen y al puerto desde el que se originó la solicitud, que se incluye en RFC 3581. El parámetro "port" es análogo al parámetro "received" excepto que "port" contiene un número de puerto, no la dirección IP. Este parámetro de informe no forma parte de RFC 3261 y, por lo tanto, CUCM no contiene el parámetro en el campo de encabezado de señalización SIP "Vía".

Escenario general de flujo de llamada

En la situación anterior, hay problemas con la configuración de la llamada SIP entrante entre CUCM y el sistema MotoPBX con el terminal de un terminal Walkie Talkie. Cuando CUCM recibe SIP INVITE de MotoPBX con el parámetro "rport", envía una respuesta 200 OK sin el parámetro "rport" en el campo de encabezado "Via". Además, se agregan otros campos como "ID de participante remoto", campo de encabezado "Identidad afirmada de P" e información de ancho de banda en el cuerpo de mensajes Protocolo de descripción de sesión (SDP) que MotoPBX no reconoce. La configuración de la llamada falla debido a un problema de cumplimiento de RFC. Por lo tanto, para mitigar el problema de configuración de la llamada, hay un script de normalización SIP diseñado que elimina el parámetro "port" de la invitación SIP entrante y agrega el parámetro "rport" en la respuesta 200 OK saliente a la misma invitación SIP enviada por MotoPBX. La secuencia de comandos también elimina los otros campos de encabezado como se mencionó anteriormente.

Guión de normalización SIP

M={}
 function M.inbound_INVITE(msg)                     /*Incoming SIP Invite*/
 local invite = msg:getHeader("Via")
 local rport=string.gsub(invite,"rport","")         /*Remove rport parameter*/
 msg:modifyHeader("Via", rport)
 end
 function M.outbound_200_INVITE(msg)                 /*Outgoing 200 OK response*/
 msg:addHeaderValueParameter("Via","rport","5060")   /*Populating rport with 5060*/
 msg:removeHeader("P-Asserted-Identity")             /*Removing headers
 and bandwidth information*/
 msg:removeHeader("Remote-Party-ID")
 local sdp = msg:getSdp()
 local sdpremove=string.gsub(sdp,"b=TIAS:%d%d%d%d%d","")
 local sdp=string.gsub(sdpremove,"b=AS:%d%d","")
 msg.setSdp(sdp)
 end
 return M

Verificar mensajes de señalización SIP

Invitación SIP entrante de MotoPBX

INVITE sip:8888@10.10.21.14;user=phone SIP/2.0

Via:SIP/2.0/UDP192.168.5.10:5060;
 branch=z9hG4bK3ad3379d104e957767cf471e77bf2738;rport

INVITACIÓN normalizada enviada a CUCM después de eliminar el parámetro "informe"

INVITE sip:8888@10.10.21.14;user=phone SIP/2.0

Via: SIP/2.0/UDP 192.168.5.10:5060;
 branch=z9hG4bK3ad3379d104e957767cf471e77bf2738;

Respuesta 200 OK saliente a MotoPBX antes de la normalización

Via: SIP/2.0/UDP 192.168.5.10:5060;
 branch=z9hG4bK3ad3379d104e957767cf471e77bf2738;

From: <sip:2202@192.168.5.10;user=phone>;
 tag=60817f1777729d1062239475498676f4

To: <sip:8888@10.10.21.14;user=phone>;
 tag=107~f59e0381-0cdb-4ad3-b769-99c8c3c177c4-20600964

Date: Thu, 27 Feb 2014 03:22:02 GMT

Call-ID: 3f42d82e786bf9f332567ca566f3c1dd

CSeq: 1 INVITE

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Allow-Events: presence, kpml

Supported: replaces

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 5000;refresher=uas

Require: timer

P-Asserted-Identity: "Kosal-LT" 
     
     

Remote-Party-ID: "Kosal-LT" 
     
     
       ;party=called;screen=yes;privacy=off 
     

Contact: <sip:8888@10.10.21.14:5060>

Content-Type: application/sdp

Content-Length: 232

v=0

o=CiscoSystemsCCM-SIP 107 1 IN IP4 10.10.21.14

s=SIP Call

c=IN IP4 10.10.21.14

b=TIAS:64000

b=AS:64

Respuesta OK 200 de salida normalizada

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.5.10:5060;
 branch=z9hG4bK3ad3379d104e957767cf471e77bf2738;;rport=5060

From: <sip:2202@192.168.5.10;user=phone>;tag=60817f1777729d1062239475498676f4

To: <sip:8888@10.10.21.14;user=phone>;
tag=107~f59e0381-0cdb-4ad3-b769-99c8c3c177c4-20600964

Date: Thu, 27 Feb 2014 03:22:02 GMT

Call-ID: 3f42d82e786bf9f332567ca566f3c1dd

CSeq: 1 INVITE

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Allow-Events: presence, kpml

Supported: replaces

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 5000;refresher=uas

Require: timer

Contact: <sip:8888@10.10.21.14:5060>

Content-Length: 213

Content-Type: application/sdp

v=0

o=CiscoSystemsCCM-SIP 107 1 IN IP4 10.10.21.14

s=SIP Call

c=IN IP4 10.10.21.14

t=0 0

El ejemplo anterior indicaba la normalización de SIP, cuando se aplica en el perfil de SIP en el troncal SIP, resuelve los problemas de interoperabilidad y la configuración de la llamada SIP se produce sin ningún problema.