Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

MotoPBX et intégration CUCM

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit des problèmes d'interopérabilité par rapport à l'intégration de Protocole SIP (Session Initiation Protocol) des systèmes de Cisco Unified Communications Manager (CUCM) et de Motorola PBX (MotoPBX). Les systèmes de MotoPBX sont conformes POUR SIROTER RFC 3581, tandis que CUCM est conforme POUR SIROTER RFC 3261. En raison de cette question de conformité RFC il y a des questions avec l'établissement d'appel de SIP entre chacun des deux serveurs de Traitement des appels, c.-à-d., CUCM et Motorola PBX.

Contribué par Depinder Deol, ingénieur TAC Cisco.

Fond

Motorola PBX a un paramètre de « rport » dans « par l'intermédiaire » du champ d'en-tête du SIP INVITE qui permet à un client pour demander que le serveur envoient la réponse de nouveau à l'adresse IP source et mettent en communication de ce que la demande a lancé qui est incluse dans RFC 3581. Le paramètre de « rport » est analogue au paramètre « reçu » à moins que le « rport » contienne un numéro de port, pas l'adresse IP. Ce paramètre d'état n'est pas une partie de RFC 3261 et donc CUCM ne contient pas le paramètre dans la signalisation de SIP « par l'intermédiaire » du champ d'en-tête.

Scénario général d'écoulement d'appel

Dans le scénario ci-dessus, il y a des questions avec l'établissement d'appel entrant de SIP entre le CUCM et le système de MotoPBX avec le point final d'un combiné téléphonique de talkie-walkie. Quand le CUCM reçoit le SIP INVITE du MotoPBX avec le paramètre de « rport », il envoie une réponse de 200 OKS sans paramètre de « rport » dans « par l'intermédiaire » du champ d'en-tête. En outre, quelques autres champs sont ajoutés comme « remote-party-id », le champ d'en-tête de « P-Affirmer-identité », et les informations de bande passante au corps du message de la Session Description Protocol (SDP) que le MotoPBX ne reconnaît pas. L'établissement d'appel échoue en raison d'une question de conformité RFC. Ainsi, afin d'atténuer le problème d'établissement d'appel, il y a un script de normalisation de SIP conçu qui retire le paramètre de « rport » du SIP entrant invite et ajoute le paramètre de « rport » en réponse sortant de 200 OKS au même SIP invitent envoyé par le MotoPBX. Le script retire également les autres champs d'en-tête comme mentionné précédemment.

Script de normalisation de 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érifiez les messages de signalisation de SIP

Le SIP d'arrivée invitent 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

Normal INVITEZ envoyé à CUCM après que le paramètre de « rport » soit retiré

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 de 200 OKS sortante à MotoPBX avant la 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" <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

Réponse sortante normale de 200 OKS

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

L'exemple précédent a énoncé la normalisation de SIP, une fois appliqué sous le profil de SIP sur le joncteur réseau de SIP, résout les problèmes d'interopérabilité et l'établissement d'appel de SIP ne se produit sans aucune question.



Document ID: 118765