Integração entre MotoPBX e CUCM

Introdução

Este documento descreve os problemas de interoperabilidade relacionados à integração do Session Initiation Protocol (SIP) dos sistemas Cisco Unified Communications Manager (CUCM) e Motorola PBX (MotoPBX). Os sistemas MotoPBX são compatíveis com SIP RFC 3581, enquanto o CUCM é compatível com SIP RFC 3261. Devido a esse problema de conformidade RFC, há problemas com a configuração de chamada SIP entre ambos os servidores de processamento de chamadas, ou seja, CUCM e PBX Motorola.

Background

O Motorola PBX tem um parâmetro "report" no campo de cabeçalho "Via" do SIP INVITE que permite que um cliente solicite que o servidor envie a resposta de volta para o endereço IP de origem e para a porta de origem da solicitação, que está incluída no RFC 3581. O parâmetro "report" é análogo ao parâmetro "received", exceto que "report" contém um número de porta, não o endereço IP. Esse parâmetro de relatório não faz parte do RFC 3261 e, portanto, o CUCM não contém o parâmetro no campo de cabeçalho "Via" de sinalização SIP.

Cenário geral de fluxo de chamada

No cenário acima, há problemas com a configuração de chamada SIP de entrada entre o CUCM e o sistema MotoPBX com o endpoint de um monofone Walkie Talkie. Quando o CUCM recebe o CONVITE SIP do MotoPBX com o parâmetro "report", ele envia uma resposta 200 OK sem o parâmetro "report" no campo de cabeçalho "Via". Além disso, alguns outros campos são adicionados, como o campo de cabeçalho "ID de Parte Remota", "P-Identidade-Declarada" e informações de Largura de Banda no corpo da mensagem Session Description Protocol (SDP) que o MotoPBX não reconhece. A configuração da chamada falha devido a um problema de conformidade RFC. Assim, para atenuar o problema de configuração de chamada, há um script de normalização SIP projetado que remove o parâmetro "report" do Convite SIP de entrada e anexa o parâmetro "report" na resposta 200 OK de saída ao mesmo Convite SIP enviado pelo MotoPBX. O script também remove os outros campos de cabeçalho, conforme mencionado anteriormente.

Script de normalização SIP

M={}
 
function M.inbound_INVITE(msg)
local invite = msg:getHeader("Via")
local rport=string.gsub(invite,"rport","")
msg:modifyHeader("Via", rport)
end
 
function M.outbound_200_INVITE(msg)
msg:addHeaderValueParameter("Via","rport","5060")
msg:removeHeader("P-Asserted-Identity")
msg:removeHeader("Remote-Party-ID")
local sdp = msg:getSdp()
local sdp = sdp:removeLine("b=TIAS:","")
local sdp = sdp:removeLine("b=AS:","")
msg:setSdp(sdp)
end
 
return M

Verificar mensagens de sinalização SIP

Convite SIP de Entrada do 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

CONVITE normalizado enviado ao CUCM após a remoção do parâmetro "report"

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

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

Resposta 200 OK de Saída para MotoPBX antes da Normalização

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

Resposta de Saída Normalizada 200 OK

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

O exemplo anterior dizia que a normalização do SIP, quando aplicada no perfil SIP no tronco SIP, resolve os problemas de interoperabilidade e a configuração da chamada SIP acontece sem nenhum problema.