Voz e comunicações unificadas : Cisco Unified Communications Manager (CallManager)

MotoPBX e integração CUCM

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve questões de interoperabilidade com relação à integração do Session Initiation Protocol (SIP) de sistemas do gerente (CUCM) e do Motorola PBX das comunicações unificadas de Cisco (MotoPBX). Os sistemas de MotoPBX são complacentes SORVER O RFC 3581, visto que CUCM é complacente SORVER O RFC 3261. Devido a esta edição da conformidade RFC há umas edições com configuração de chamada do SORVO entre ambos os server do Processamento de chamadas, isto é, CUCM e Motorola PBX.

Contribuído por Depinder Deol, engenheiro de TAC da Cisco.

Background

Motorola PBX manda um parâmetro do “rport” no “através” do campo de cabeçalho do SORVO CONVIDAR que permite que um cliente peça que o server envia a resposta de volta ao endereço IP de origem e à porta de que o pedido originou que é incluído no RFC 3581. O parâmetro do “rport” é análogo ao parâmetro “recebido” a não ser que o “rport” contenha um número de porta, não o endereço IP de Um ou Mais Servidores Cisco ICM NT. Este parâmetro do relatório não é parte de RFC 3261 e consequentemente CUCM não contém o parâmetro na sinalização do SORVO “através” do campo de cabeçalho.

Encenação geral do fluxo de chamadas

Na encenação acima, há umas edições com a configuração de chamada entrante do SORVO entre o CUCM e o sistema de MotoPBX com o valor-limite de um monofone do Walkietalkie. Quando o CUCM recebe o SORVO CONVIDE do MotoPBX com o parâmetro do “rport”, ele manda uma resposta de 200 APROVAÇÕES sem o parâmetro do “rport” no “através” do campo de cabeçalho. Também, alguns outros campos são adicionados como “Remoto-Partido-ID”, o campo de cabeçalho da “P-Afirmar-identidade”, e a informação de largura de banda no corpo da mensagem do protocolo session description (SDP) que o MotoPBX não reconhece. A configuração de chamada falha devido a uma edição da conformidade RFC. Assim, a fim abrandar o problema da configuração de chamada, há um script da normalização do SORVO projetado que remove o parâmetro do “rport” do SORVO entrante convida e adiciona o parâmetro do “rport” na resposta de partida de 200 APROVAÇÕES ao mesmo SORVO convida enviado pelo MotoPBX. O script igualmente remove os outros campos de cabeçalho como mencionado previamente.

Script da normalização do SORVO

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

Verifique mensagens de sinalização do SORVO

O SORVO de entrada convida 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

Normalizado CONVIDE enviado a CUCM depois que o parâmetro do “rport” é removido

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

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

Resposta de 200 APROVAÇÕES de partida a MotoPBX antes da normalização

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

Resposta de partida normalizada de 200 APROVAÇÕES

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

O exemplo anterior indicou a normalização do SORVO, quando aplicado sob o perfil do SORVO no tronco do SORVO, resolve as questões de interoperabilidade e a configuração de chamada do SORVO acontece sem nenhumas edições.



Document ID: 118765