MotoPBX- en CUCM-integratie

Inleiding

Dit document beschrijft interoperabiliteitsproblemen met betrekking tot de integratie van het Session Initiation Protocol (SIP) van Cisco Unified Communications Manager (CUCM) en Motorola PBX (MotoPBX) systemen. MotoPBX-systemen voldoen aan SIP RFC 3581, terwijl CUCM voldoet aan SIP RFC 3261. Vanwege dit RFC-nalevingsprobleem zijn er problemen met de installatie van SIP-oproepen tussen beide Call Processing Servers, dat wil zeggen CUCM en Motorola PBX.

Achtergrond

Motorola PBX heeft een "rapport" parameter in het "Via" header veld van de SIP INVITE die een client in staat stelt om te verzoeken dat de server het antwoord terug te sturen naar de bron IP-adres en poort waaruit het verzoek afkomstig is, die is opgenomen in RFC 3581. De parameter "rapport" is analoog aan de parameter "ontvangen", behalve dat "rapport" een poortnummer bevat, niet het IP-adres. Deze rapportparameter maakt geen deel uit van RFC 3261 en daarom bevat CUCM niet de parameter in het veld SIP-signalering "Via".

algemeen gespreksstroomscenario

In het bovenstaande scenario zijn er problemen met de inkomende SIP-oproepinstallatie tussen de CUCM en het MotoPBX-systeem met het eindpunt van een Walkie Talkie-handset. Wanneer de CUCM de SIP INVITE ontvangt van de MotoPBX met de parameter "rapport", verzendt deze een 200 OK-respons zonder de parameter "rapport" in het kopveld "Via". Ook zijn er een paar andere velden toegevoegd, zoals "Remote-Party-ID", "P-Asserted-Identity" header veld, en Bandbreedte informatie in de Session Description Protocol (SDP) berichttekst die de MotoPBX niet erkent. De installatie van de oproep mislukt vanwege een RFC-nalevingsprobleem. Dus, om het probleem van de oproepinstallatie te beperken, is er een SIP-normalisatiescript ontworpen dat de parameter "rapport" verwijdert uit de inkomende SIP Invite en de parameter "rapport" toevoegt aan de uitgaande 200 OK-reactie op dezelfde SIP-uitnodiging die door de MotoPBX is verzonden. Het script verwijdert ook de andere header velden zoals eerder vermeld.

SIP-normalisatiescript

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

SIP-signaleringsberichten verifiëren

Inkomende SIP-uitnodiging 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

Genormaliseerde INVITE Verzonden naar CUCM nadat de parameter "rapport" 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 uitgaand 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

Genormaliseerde uitgaande 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 aangegeven dat SIP-normalisatie, wanneer toegepast onder het SIP-profiel op de SIP-trunk, de interoperabiliteitsproblemen oplost en dat de SIP-oproepinstallatie zonder problemen plaatsvindt.