Integrazione tra MotoPBX e CUCM

Introduzione

Questo documento descrive i problemi di interoperabilità relativi all'integrazione del SIP (Session Initiation Protocol) di sistemi Cisco Unified Communications Manager (CUCM) e Motorola PBX (MotoPBX). I sistemi MotoPBX sono conformi alla RFC 3581 SIP, mentre CUCM è conforme alla RFC 3261 SIP. A causa di questo problema di conformità RFC ci sono problemi con la configurazione delle chiamate SIP tra entrambi i server di elaborazione delle chiamate, ovvero CUCM e Motorola PBX.

Sfondo

Motorola PBX ha un parametro "report" nel campo "Via" dell'intestazione SIP INVITE che consente a un client di richiedere che il server restituisca la risposta all'indirizzo IP di origine e alla porta da cui la richiesta ha avuto origine, che è inclusa nella RFC 3581. Il parametro "report" è analogo al parametro "received", a eccezione del fatto che "report" contiene un numero di porta e non l'indirizzo IP. Questo parametro di report non fa parte della RFC 3261 e pertanto CUCM non contiene il parametro nel campo dell'intestazione "Via" di segnalazione SIP.

Scenario flusso di chiamata generale

Nello scenario sopra illustrato si verificano problemi con l'impostazione delle chiamate SIP in ingresso tra il sistema CUCM e il sistema MotoPBX con l'endpoint di un ricevitore Walkie Talkie. Quando il CUCM riceve l'INVITE SIP dal MotoPBX con il parametro "report", invia una risposta 200 OK senza il parametro "report" nel campo di intestazione "Via". Inoltre, vengono aggiunti alcuni altri campi, ad esempio il campo dell'intestazione "Remote-Party-ID", "P-Asserted-Identity" e le informazioni sulla larghezza di banda nel corpo del messaggio Session Description Protocol (SDP) non riconosciuto dal modulo PBX. La configurazione della chiamata non è riuscita a causa di un problema di conformità RFC. Pertanto, per risolvere il problema di configurazione della chiamata, è disponibile uno script di normalizzazione SIP progettato che rimuove il parametro "report" dall'invito SIP in ingresso e aggiunge il parametro "report" nella risposta 200 OK in uscita allo stesso invito SIP inviato dal modem PBX. Lo script rimuove anche gli altri campi di intestazione, come indicato in precedenza.

Script di normalizzazione 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

Verifica messaggi di segnalazione SIP

Invito SIP in ingresso da 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

INVITO normalizzato inviato a CUCM dopo la rimozione del parametro "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;

200 OK Response Outbound to MotoPBX before Normalization

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

Risposta normalizzata 200 OK in uscita

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

Nell'esempio precedente si affermava che la normalizzazione SIP, quando applicata sotto il profilo SIP sul trunk SIP, risolve i problemi di interoperabilità e la configurazione delle chiamate SIP avviene senza problemi.