MotoPBX and CUCM Integration

Introduction

This document describes interoperability issues in relation to Session Initiation Protocol (SIP) integration of Cisco Unified Communications Manager (CUCM) and Motorola PBX (MotoPBX) systems. MotoPBX systems are compliant to SIP RFC 3581, whereas CUCM is compliant to SIP RFC 3261. Due to this RFC compliance issue there are issues with SIP call setup between both of the Call Processing Servers, that is, CUCM and Motorola PBX.

Background

Motorola PBX has an "rport" parameter in the "Via" header field of the SIP INVITE that allows a client to request that the server send the response back to the source IP address and port from which the request originated which is included in RFC 3581. The "rport" parameter is analogous to the "received" parameter except "rport" contains a port number, not the IP address. This report parameter is not part of RFC 3261 and therefore CUCM does not contain the parameter in the SIP signaling "Via" header field.

General Call Flow Scenario

In the above scenario, there are issues with the incoming SIP call setup between the CUCM and the MotoPBX system with the endpoint of a Walkie Talkie handset. When the CUCM receives the SIP INVITE from the MotoPBX with the "rport" parameter, it sends out a 200 OK response without the "rport" parameter in the "Via" header field. Also, a few other fields are added such as "Remote-Party-ID", "P-Asserted-Identity" header field, and Bandwidth information in the Session Description Protocol (SDP) message body which the MotoPBX does not acknowledge. The call setup fails due to an RFC compliance issue. So, in order to mitigate the call setup problem, there is a SIP normalization script designed which removes the "rport" parameter from the incoming SIP Invite and appends the "rport" parameter in the outbound 200 OK response to the same SIP Invite sent by the MotoPBX. The script also removes the other header fields as mentioned previously.

SIP Normalization Script

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

Verify SIP Signaling Messages

Inbound SIP Invite from 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

Normalized INVITE Sent to CUCM after the "rport" Parameter is Removed

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" <sip:8888@10.10.21.14>

Remote-Party-ID: "Kosal-LT" <sip:8888@10.10.21.14>;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

Normalized Outbound 200 OK Response

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

The previous example stated SIP Normalization, when applied under the SIP Profile on the SIP trunk, resolves the interoperability issues and the SIP call setup happens without any issues.