MotoPBX-integratie en CUCM-integratie

Inleiding

In dit document worden interoperabiliteitsproblemen beschreven met betrekking tot de integratie van Cisco Unified Communications Manager (CUCM) en Motorola PBX-systemen (MotoPBX) in Session Initiation Protocol. MotoPBX-systemen zijn compatibel met SIP RFC 3581, terwijl CUCM compatibel is met SIP RFC 3261. Als gevolg van deze RFC-nalevingskwestie zijn er problemen met SIP-callinstelling tussen beide Call Processing Server, dat wil zeggen CUCM en Motorola PBX.

Achtergrond

Motorola PBX heeft een "rapport" parameter in het veld "Via" header van het SIP INVITE dat een client in staat stelt om te vragen dat de server de reactie terugstuurt naar het bron-IP-adres en de poort waar het verzoek vandaan komt, hetgeen in RFC 3581 is opgenomen. De parameter "rapport" is analoog aan de "ontvangen" parameter behalve "rapport" bevat een poortnummer en niet het IP-adres. Deze parameter is geen deel van RFC 3261 en daarom bevat CUCM de parameter in het veld SIP-signalering van "Via" header.

General Call Flow Scenario

In het bovenstaande scenario zijn er problemen met de inkomende SIP-aanroep tussen het CUCM en het MotoPBX-systeem met het eindpunt van een Walkie Talkie-handset. Wanneer de CUCM de SIP INVITE van de MotoPBX ontvangt met de "Report"-parameter, stuurt het een 200 OK-respons zonder de "Report"-parameter in het veld "Via"-header. Er worden ook een paar andere velden toegevoegd, zoals de tekst "Remote-Party-ID", de kop "P-Asserted-Identity" en de informatie over de bandbreedte in de berichttekst van het Session Description (SDP) die niet door de MotoPBX wordt bevestigd. De Call Setup heeft geen problemen met RFC-naleving. Om het probleem van de CallConnector te verzachten, is er een SIP-normalisatie-script ontworpen dat de "report"-parameter van de inkomende SIP Invite verwijdert en de "report"-parameter toevoegt in de uitgaande 200 OK-respons op dezelfde SIP-uitnodiging die door de MotoPBX is verstuurd. Het script verwijdert de andere veldnamenvelden zoals eerder vermeld.

SIP-Normalisatie-scripts

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

Controleer SIP-signaleringsberichten

Ingebonden SIP uitgenodigd van 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

Normale INVITE verzonden naar CUCM nadat de "rapport" parameter is verwijderd

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-respons Uitgaande naar MotoPBX vóór normalisatie

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

Normalised Outbound 200 OK-respons

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

In het vorige voorbeeld werd SIP Normalisatie aangegeven, wanneer deze onder het SIP-profiel op de SIP-romp wordt toegepast, worden de interoperabiliteitsproblemen opgelost en wordt de SIP-gespreksinstelling zonder problemen uitgevoerd.