内容

概要

背景

一般的なコールフローシナリオ

SIP正規化スクリプト

SIPシグナリングメッセージの確認

MotoPBXからの着信SIP INVITE

「rport」パラメータの削除後にCUCMに送信される正規化されたINVITE

正規化の前のMotoPBXへの200 OK応答の発信

Normalized Outbound 200 OK応答

概要

このドキュメントでは、Cisco Unified Communications Manager(CUCM)システムとMotorola PBX(MotoPBX)システムのSession Initiation Protocol(SIP)統合に関する相互運用性の問題について説明します。MotoPBXシステムはSIP RFC 3581に準拠し、CUCMはSIP RFC 3261に準拠します。このRFC準拠の問題により、コール処理サーバ（CUCMとMotorola PBX）の間のSIPコール設定に問題があります。

背景

Motorola PBXのSIP INVITEの「Via」ヘッダーフィールドには「rport」パラメータがあり、RFC 3581に含まれている要求の発信元IPアドレスおよびポートに対して、クライアントが応答を送信するように要求できます。「rport」パラメータは「received」パラメータに似ていますが、「rport」にはIPアドレスではなくポート番号が含まれています。このレポートパラメータはRFC 3261の一部ではないため、CUCMではSIPシグナリングの「Via」ヘッダーフィールドにパラメータが含まれていません。

一般的なコールフローシナリオ

上記のシナリオでは、CUCMとMotoPBXシステムの間の着信SIPコールの設定で、Walkie Talkieハンドセットのエンドポイントに問題があります。CUCMは、「rport」パラメータを使用してMotoPBXからSIP INVITEを受信すると、「Via」ヘッダーフィールドに「rport」パラメータを使用せずに200 OK応答を送信します。また、MotoPBXが確認応答しないSession Description Protocol(SDP)メッセージ本文の「Remote-Party-ID」、「P-Asserted-Identity」ヘッダーフィールド、および帯域幅情報など、その他のフィールドも追加されます。RFC準拠の問題により、コールセットアップが失敗します。そのため、コールセットアップの問題を緩和するために、着信SIP Inviteから「rport」パラメータを削除し、MotoPBXから送信された同じSIP Inviteに対する発信200 OK応答の「rport」パラメータを追加するSIP正規化スクリプトが設計されています。スクリプトは、前述の他のヘッダーフィールドも削除します。

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

SIPシグナリングメッセージの確認

MotoPBXからの着信SIP INVITE

INVITE sip:8888@10.10.21.14;user=phone SIP/2.0

Via:SIP/2.0/UDP192.168.5.10:5060;

branch=z9hG4bK3ad3379d104e957767cf471e77bf2738;rport

「rport」パラメータの削除後にCUCMに送信される正規化されたINVITE

INVITE sip:8888@10.10.21.14;user=phone SIP/2.0

Via: SIP/2.0/UDP 192.168.5.10:5060;

branch=z9hG4bK3ad3379d104e957767cf471e77bf2738;

正規化の前のMotoPBXへの200 OK応答の発信

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

Normalized Outbound 200 OK応答

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

前の例では、SIPトランクのSIPプロファイルにSIP正規化を適用すると、相互運用性の問題が解決され、SIPコールセットアップは問題なく行われます。