MotoPBX- und CUCM-Integration

Einführung

Dieses Dokument beschreibt Interoperabilitätsprobleme im Zusammenhang mit der SIP-Integration (Session Initiation Protocol) von Cisco Unified Communications Manager (CUCM)- und Motorola PBX (MotoPBX)-Systemen. MotoPBX-Systeme sind mit SIP RFC 3581 konform, während CUCM mit SIP RFC 3261 konform ist. Aufgrund dieses RFC-Compliance-Problems gibt es Probleme mit der Einrichtung von SIP-Anrufen zwischen beiden Anrufverarbeitungsservern, d. h. CUCM und Motorola PBX.

Hintergrund

Das Motorola PBX verfügt über einen "report"-Parameter im Headerfeld "Via" der SIP INVITE-Nachricht, mit dem ein Client anfordern kann, dass der Server die Antwort an die Quell-IP-Adresse und den Port zurücksendet, von dem die Anfrage stammt. Diese Adresse ist in RFC 3581 enthalten. Der Parameter "report" entspricht dem Parameter "received", jedoch enthält "report" keine Portnummer, sondern vielmehr die IP-Adresse. Dieser Berichtsparameter ist nicht Teil von RFC 3261 und enthält daher keinen Parameter im Headerfeld für die SIP-Signalisierung "Via".

Allgemeines Anruffluss-Szenario

Im obigen Szenario gibt es Probleme mit der Einrichtung eingehender SIP-Anrufe zwischen dem CUCM und dem MotoPBX-System mit dem Endpunkt eines Walkie Talkie-Hörers. Wenn der CUCM die SIP-INVITE-Nachricht von der MotoPBX mit dem Parameter "report" empfängt, sendet er eine 200-OK-Antwort ohne den Parameter "report" im Headerfeld "Via". Außerdem werden einige weitere Felder wie "Remote-Party-ID", "P-Asserted-Identity"-Headerfeld und Bandbreiteninformationen im Nachrichtentext Session Description Protocol (SDP) hinzugefügt, den das MotoPBX nicht bestätigt. Die Anrufeinrichtung schlägt aufgrund eines RFC-Compliance-Problems fehl. Um das Problem bei der Anrufeinrichtung zu beheben, wird ein SIP-Normalisierungs-Skript erstellt, das den Parameter "report" (Bericht) aus der eingehenden SIP-Einladung entfernt und den Parameter "report" (Bericht) in der Antwort "Outbound 200 OK" an dieselbe vom MotoPBX gesendete SIP-Einladung anfügt. Das Skript entfernt auch die anderen Headerfelder, wie bereits erwähnt.

SIP-Normungs-Skript

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

SIP-Signalisierungsnachrichten überprüfen

Eingehende SIP-Einladung von 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

Normalisierte INVITE wird an CUCM gesendet, nachdem der Parameter "report" entfernt wurde.

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 Antwort Ausgehend an MotoPBX vor Normalisierung

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

Normalisierte ausgehende 200-OK-Antwort

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

Im vorherigen Beispiel wurde die SIP-Normalisierung angegeben, wenn sie unter dem SIP-Profil auf dem SIP-Trunk angewendet wird. Dies löst die Interoperabilitätsprobleme, und die SIP-Anrufeinrichtung erfolgt ohne Probleme.