Intégration 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 à la norme SIP RFC 3581, tandis que CUCM est conforme à la norme SIP RFC 3261. En raison de ce problème de conformité RFC, il existe des problèmes de configuration d'appel SIP entre les deux serveurs de traitement d'appels, à savoir CUCM et le PBX Motorola.

Fond

Le PBX Motorola dispose d'un paramètre « report » dans le champ d'en-tête « Via » du SIP INVITE qui permet à un client de demander au serveur de renvoyer la réponse à l'adresse IP source et au port d'où provient la demande, qui est inclus dans le document RFC 3581. Le paramètre « report » est analogue au paramètre « received », à ceci près que « report » contient un numéro de port et non l'adresse IP. Ce paramètre de rapport ne fait pas partie de RFC 3261 et CUCM ne contient donc pas le paramètre dans le champ d'en-tête SIP signaling "Via".

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

Dans le scénario ci-dessus, il y a des problèmes avec l'établissement de l'appel SIP entrant entre le CUCM et le système MotoPBX avec le point d'extrémité d'un combiné Walkie Talkie. Lorsque le CUCM reçoit le SIP INVITE du MotoPBX avec le paramètre "report", il envoie une réponse 200 OK sans le paramètre "report" dans le champ d'en-tête "Via". En outre, quelques autres champs sont ajoutés tels que "Remote-Party-ID", "P-Asserted-Identity" champ d'en-tête, et les informations de bande passante dans le corps de 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 d'établissement d'appel, il y a un script de normalisation SIP conçu qui supprime le paramètre "report" de l'invitation SIP entrante et ajoute le paramètre "report" dans la réponse 200 OK sortante à la même invitation SIP envoyée par le MotoPBX. Le script supprime également les autres champs d'en-tête comme mentionné précédemment.

Script de normalisation SIP

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

Vérifier les messages de signalisation SIP

Invitation SIP entrante depuis 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ée envoyée à CUCM après la suppression du paramètre « report »

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 réponses OK sortantes 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 200 OK sortante normalisée

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 de l'appel SIP se déroule sans aucun problème.