Intégration de MotoPBX et CUCM

Introduction

Ce document décrit les problèmes d'interopérabilité liés à l'intégration SIP (Session Initiation Protocol) des systèmes Cisco Unified Communications Manager (CUCM) et Motorola PBX (MotoPBX). Les systèmes MotoPBX sont conformes au SIP RFC 3581, tandis que CUCM est conforme au SIP RFC 3261. En raison de ce problème de conformité RFC, il y a des problèmes de configuration des appels SIP entre les deux serveurs de traitement des appels, c'est-à-dire CUCM et Motorola PBX.

Fond

Motorola PBX possède un paramètre de rapport dans le champ d'en-tête « Via » du SIP INVITE qui permet à un client de demander que le serveur renvoie la réponse à l'adresse IP source et au port d'où provient la demande, qui est inclus dans la RFC 3581. Le paramètre « rapport » est analogue au paramètre « reçu » sauf que « rapport » contient un numéro de port et non l'adresse IP. Ce paramètre de rapport ne fait pas partie de la RFC 3261 et par conséquent CUCM ne contient pas le paramètre dans le champ d'en-tête SIP signalant « Via ».

Scénario général de flux d'appels

Dans le scénario ci-dessus, il y a des problèmes avec la configuration des appels SIP entrants entre CUCM et le système MotoPBX avec le point de terminaison d'un combiné Walkie Talkie. Lorsque le CUCM reçoit le SIP INVITE du MotoPBX avec le paramètre « rapport », il envoie une réponse 200 OK sans le paramètre « rapport » dans le champ d'en-tête « Via ». En outre, quelques autres champs sont ajoutés, tels que « Remote-Party-ID », « P-Asserted-Identity » et les informations de bande passante dans le corps du message Session Description Protocol (SDP) que le MotoPBX ne reconnaît pas. La configuration de l'appel échoue en raison d'un problème de conformité RFC. Ainsi, afin d'atténuer le problème de configuration des appels, il ya un script de normalisation SIP conçu qui supprime le paramètre « rapport » de l'invitation SIP entrante et ajoute le paramètre « rapport » dans la réponse 200 OK sortante à la même invitation SIP envoyée par MotoPBX. Le script supprime également les autres champs d'en-tête, comme indiqué précédemment.

Script de normalisation 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

Vérification des messages de signalisation SIP

Invitation SIP entrante de 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

INVITE normalisé envoyé à CUCM après suppression du paramètre de rapport

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

Via: SIP/2.0/UDP 192.168.5.10:5060;
 branch=z9hG4bK3ad3379d104e957767cf471e77bf2738;

Réponse 200 OK sortant vers MotoPBX avant normalisation

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

Réponse OK sortante normalisée 200

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

Dans l'exemple précédent, la normalisation SIP, lorsqu'elle est appliquée sous le profil SIP sur la ligne principale SIP, résout les problèmes d'interopérabilité et la configuration des appels SIP se fait sans problème.