Голосовая связь и система унифицированных коммуникаций : Cisco Unified Communications Manager (CallManager)

MotoPBX и интеграция CUCM

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв

Введение

Этот документ описывает проблемы совместимости относительно интеграции Протокола SIP систем Motorola PBX (MotoPBX) и Cisco Unified Communications Manager (CUCM). Системы MotoPBX совместимы к SIP RFC 3581, тогда как CUCM совместим к SIP RFC 3261. Из-за этой проблемы соответствия RFC существуют проблемы с настройкой вызова SIP между обоими из Серверов обработки Вызова, т.е. CUCM и Motorola PBX.

Внесенный Depinder Deol, специалистом службы технической поддержки Cisco.

Общие сведения

Motorola PBX имеет "rport" параметр в "Через" поле заголовка SIP INVITE, который позволяет клиенту запрашивать, чтобы сервер передал ответ обратно IP - адресу источника и порту, из которого произошел запрос, который включен в RFC 3581. "rport" параметр походит на "полученный" параметр кроме "rport", содержит номер порта, не IP-адрес. Этот параметр отчёта не является частью RFC 3261, и поэтому CUCM не содержит параметр в SIP, сигнализирующем "Через" поле заголовка.

Сценарий потока общего вызова

В вышеупомянутом сценарии существуют проблемы с входящей настройкой вызова SIP между CUCM и системой MotoPBX с оконечной точкой телефонной трубки Звукового кино Walkie. Когда CUCM получает SIP INVITE от MotoPBX с "rport" параметром, это отсылает 200 ОК ответ без "rport" параметра в "Через" поле заголовка. Кроме того, несколько других полей добавлены, такие как "Remote-Party-ID", поле заголовка "P-Asserted-Identity" и Сведения о пропускной способности в  теле сообщения Протокола описания сеанса (SDP), которое не подтверждает MotoPBX. Настройка вызова отказывает из-за проблемы соответствия RFC. Так, для смягчения проблемы настройки вызова существует сценарий нормализации SIP, разработанный, который удаляет "rport" параметр из входящего SIP, Приглашают, и добавляет "rport" параметр в исходящих 200 ОК, ответ на тот же SIP Приглашает передаваемый MotoPBX. Сценарий также удаляет другие поля заголовка, как упомянуто ранее.

Сценарий нормализации 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

Входящий SIP приглашает из 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, Передаваемый CUCM после "rport" Параметра, Удален

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 ОК Ответ, Исходящий к MotoPBX перед Нормализацией

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

Нормализованные исходящие 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

Предыдущий пример сообщил, что Нормализация SIP, когда применено под профилем SIP на магистрали SIP, решает проблемы совместимости, и настройка вызова SIP происходит без любых проблем.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.