отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

"Следствие ведут ИТ-шники". День 4. Технологии голосовой связи. Имена победителей

Прежде всего мы благодарим всех за участие в конкурсе.

 

Имена победителей:

1 место - Юрий Липкин (АМТ-Груп, РФ)

2 место - Дмитрий Докучаев (Казахстан)

3 место - Дмитрий Каримов (Казахстан)

 

Поощрительный приз:

4 место - Игорь Коротченков (РФ)

 

ОТВЕТ:

 

Проблема происходит из-за несовпадения кодеков между входящим звонком от провайдера ССОП (G.711 a-Law) и кодеком, поддерживаемым MOH сервером (G.711 u-Law):

 

00599190.006 |09:09:38.044 |AppInfo |DET-RegionsServer::handleMatchCapabilities()-- BEFORE MATCHING LOGIC applied(after filtering), sideARefCaps=1 refCapsSaveOpt=0 otherCapsSaveOpt=0 capsA[1]::capCount=1 (Cap,ptime)= (2,20) capsB[1]::capCount=1 (Cap,ptime)= (4,80)

00599190.007 |09:09:38.044 |AppInfo |DET-RegionsServer::handleMatchCapabilities()-- AFTER MATCHING LOGIC applied, capsA[1]::capCount=1 (Cap,ptime)= (2,20) capsB[1]::capCount=1 (Cap,ptime)= (4,80) numMatchedCaps=0

00599190.008 |09:09:38.044 |AppInfo |DET-MediaManager-(53)::preCheckCapabilities, caps mismatch! Xcoder Reqd. kbps(64), filtered A[capCount=1 (Cap,ptime)= (2,20)], B[capCount=1 (Cap,ptime)= (4,80)] allowMTP=1 numXcoderRequired=1 xcodingSide=1

 

Также для транка и MOH не настроен MTP, который бы мог проблему предотвратить:

 

00599191.007 |09:09:38.044 |AppInfo |MediaResourceManager::sendAllocationResourceErr - ERROR - no MTP device configured

 

В результате CUCM не может сформировать SDP (нет кодека) и не посылает SIP ACK в сторону CUBE. Если трансфер завершить пока CUBE ждет и посылает повторные сообщения SIP 200 OK, то звонок сохранится, поскольку кодек с другим телефоном пересогласуется на G.711 a-Law. Если же звонок провисит на MOH достаточно долго, то CUBE его сбросит, что и происходит в логе.

 

Решение проблемы:

1. MOH на CUCM поддерживает кодек G.711 a-Law, но его нужно активировать в сервисных параметрах: System > Service Parameters > Cisco IP Voice Media Streaming App > Supported MOH Codecs

2. Можно настроить MTP для транка и/или MOH, который будет преобразовывать кодеки a- и u-Law.

 

Первый вариант является более правильным в данном случае, поскольку позволит решить проблему без привлечения дополнительных ресурсов.

  • Найти больше статей с меткой:
Комментарии
New Member

Эхх, участвовал только из-за ваучера=)

Cisco Employee

Да, Дмитрий, вам буквально чуть-чуть не хватило - первые три места оказались очень близки. К сожалению, ваш третий предложенный путь ("включение на шлюзе кодека G711u в сторону CUCM") не удовлетворяет условиям задачи.

New Member

Спасибо, приятный подарок на день рождения :)

New Member

Михаил, добрый день.

Напишите, пожалуйста, как из представленных логов:

00599190.006 |09:09:38.044 |AppInfo |DET-RegionsServer::handleMatchCapabilities()-- BEFORE MATCHING LOGIC applied(after filtering), sideARefCaps=1 refCapsSaveOpt=0 otherCapsSaveOpt=0 capsA[1]::capCount=1 (Cap,ptime)= (2,20) capsB[1]::capCount=1 (Cap,ptime)= (4,80)

00599190.007 |09:09:38.044 |AppInfo |DET-RegionsServer::handleMatchCapabilities()-- AFTER MATCHING LOGIC applied, capsA[1]::capCount=1 (Cap,ptime)= (2,20) capsB[1]::capCount=1 (Cap,ptime)= (4,80) numMatchedCaps=0

00599190.008 |09:09:38.044 |AppInfo |DET-MediaManager-(53)::preCheckCapabilities, caps mismatch! Xcoder Reqd. kbps(64), filtered A[capCount=1 (Cap,ptime)= (2,20)], B[capCount=1 (Cap,ptime)= (4,80)] allowMTP=1 numXcoderRequired=1 xcodingSide=1

можно определить, что проблема именно с MOH? =)

New Member

Спасибо! Приятная неожиданность:) Думал, с моим ответом в 23-58 ловить уже нечего будет..)

Cisco Employee

День добрый, Григорий

В задаче представлен полный лог - там вы можете увидеть про MOH. Данный же кусок лога показывает несовпадение кодеков.

Нужно смотреть лог полностью, конкретно из этих строчек можно сделать вывод, что сторона А поддерживает только кодек g711alaw (cap 2), а сторона Б только g711ulaw (cap 4). В третьей строчке указывается, что нужен транскодер/mtp - caps mismatch! Xcoder Reqd.

Когда на телефоне 2001 нажали трансфер, CUCM отправил re-INVITE w/SDP (inactive) в сторону CUBE, затем следом re-INVITE DO (hold), CUBE ответил 200OK w/SDP g711alaw. CUCM выделил новый CI:45189067 для MOH сервера и из MOH_3/MOH_2, был выбран последний. Дальше смотрим по этому CI, находим строчки, которые вы указали, т.е. кодек CUBE не совпадает с кодеком на MOH.

Далее была попытка выделить MTP (CI 45189068), чтобы исправить cap mismatch, но не была успешной:

 Line 1996: 00599191.005 |09:09:38.044 |AppInfo  |MRM::getMtpDeviceGivenMrgl GETTING MTP FROM DEFAULT LIST
 Line 1997: 00599191.006 |09:09:38.044 |AppInfo  |MRM::getMtpDeviceGivenMrgl GETTING XCODE FROM DEFAULT LIST
 Line 1998: 00599191.007 |09:09:38.044 |AppInfo  |MediaResourceManager::sendAllocationResourceErr - ERROR - no MTP device configured

Из-за этого CUCM не отвечал на сообщения 200OK w/SDP от CUBE.

комментарий отредактирован
New Member

Валерий, добрый день.

Михаил указал причину проблемы и в качестве доказательств представил конкретные сообщение из лог файла. И как Вы указали, из этих строчек можно сделать вывод о проблеме с кодеками, НО! Михаил писал про MOH и вопрос у меня был не про кодеки или MTP, а про MOH. Из каких сообщений сделан вывод, что проблема с кодеком MOH? Пока что я этого не увидел. Хочется все-таки получить больше информации, так как логика выводов относительно MOH пока не ясна.

С кодеками MOH нет никакой проблемы, на CUCM он изначально был настроен на поддержку g711ulaw. Косвенно этот вывод можно сделать из того, что обычный звонок между 4001 и 2001 установился в g711alaw, значит CUCM, или IP-телефон его поддерживает. Если бы, на CUCM в MOH была включена поддержка кодека g711alaw, то CUCM ответил бы ACK на сообщение CUBE 200OK w/SDP и абонент 4001 услышал музыку hold (установился rtp поток) и после длительного разговора трансфер на 2002 сработал бы.

New Member

Валерий,

В задании ничего не написано о жалобах на отсутствие музыки ;-), поэтому про музыку это только Ваши догадки, а догадки не могут быть доказательством. Более того, видно, что голосовой канал был открыт. А судя еще и по этому пункту:
- если же им приходится долго ждать ответа третьего абонента, или при разговоре с ним, исходный звонок теряется
открывается и второй голосовой канал между абонентами 2001 и 2002.
Вот и согласованный кодек) :
ACK sip:50a929b9-3023-4a5e-87db-820441e94784@142.102.64.47:49567;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 142.100.64.12:5060;branch=z9hG4bK1053b2dd122
From: "HQ Phone 1" <sip:hqone@cciecollab.cisco.com>;tag=2554~b9838bc9-5583-408a-aaa-e3b9d50e9175-45189066
To: <sip:2002@142.100.64.12>;tag=34a84ea6885800077c2f45bf-0adea70e
Date: Thu, 04 Jun 2015 16:09:43 GMT
Call-ID: 1b270300-57017847-45-c40648e@142.100.64.12
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 397

v=0
o=CiscoSystemsCCM-SIP 2554 1 IN IP4 142.100.64.12
s=SIP Call
c=IN IP4 142.102.64.50
b=TIAS:64000
b=AS:64
t=0 0
m=audio 30116 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 0 RTP/AVP 31 34 96 97
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
a=rtpmap:96 H263-1998/90000
a=rtpmap:97 H264/90000
a=content:main
a=inactive

Валерий, у каждого инженера может быть своя логика анализа. Извиняюсь, но я бы хотел получить развернутый ответ от Михаила, как от инициатора задания.

New Member

Михаил,

Покажите, пожалуйста, сообщения про MOH, которые подтверждают заключение, что проблема с кодеком MOH. Я видел сообщения про MTP, но про проблемы с MOH не увидел, поэтому хотелось бы все-таки узнать, куда надо было смотреть.

New Member

Во всех своих ответах я имел ввиду Михаила, а не Дмитрия, поправил в сообщениях)

Григорий,

Вы говорите про звонок между 2001 и 2002 (call id: 1b270300-57017847-45-c40648e@142.100.64.12), он без сомнения был успешным и как вы успели заметить с кодеком g711ulaw. Только проблема проявляется, когда 4001 ставится на hold со стороны CUCM. В принципе 2001 мог даже не звонить 2002, а просто нажать hold и ситуация бы повторилась.

Я описывал ситуацию именно между 4001 и 2001 (call id: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254).

Когда 2001 хочет сделать трансфер и нажимает на кнопку, CUCM разрывает rtp между 4001 и 2001, затем делается попытка (как мызнаем неуспешная) поставить 4001 на холд, потому что CUCM не отвечает сообщением ACK (причины описаны выше в теме) на предложение 200OK w/sdp g711alaw от CUBE, rtp между 4001/CUBE и CUCM MOH не устанавливается.

Если 4001 висит на холде достаточно долго, CUBE забрасывает CUCM сообщениями 200OK, но так и не получает ответа, в результате этого звонок прекращается, CUBE отправляет BYE.

+++ Входящий звонок 4001->2001 INVITE с SDP, кодек G711ALAW
INVITE sip:2001@142.100.64.12:5060 SIP/2.0
Via: SIP/2.0/UDP 142.102.64.254:5060;branch=z9hG4bK381B0
Remote-Party-ID: "SiteC Phone1" <sip:4001@142.102.64.254>;party=calling;screen=no;privacy=off
From: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
To: <sip:2001@142.100.64.12>
Date: Thu, 04 Jun 2015 16:09:20 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 0868164442-0168694245-2153431068-1870706469
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1433434160
Contact: <sip:4001@142.102.64.254:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 253

v=0
o=CiscoSystemsSIP-GW-UserAgent 2948 4993 IN IP4 142.102.64.254
s=SIP Call
c=IN IP4 142.102.64.254
t=0 0
m=audio 16636 RTP/AVP 8 101
c=IN IP4 142.102.64.254
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

+++ CUCM отвечатет Trying
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 142.102.64.254:5060;branch=z9hG4bK381B0
From: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
To: <sip:2001@142.100.64.12>
Date: Thu, 04 Jun 2015 16:09:20 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0

+++ CUCM отвечатет Ringing
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 142.102.64.254:5060;branch=z9hG4bK381B0
From: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
To: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
Date: Thu, 04 Jun 2015 16:09:20 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: "HQ Phone 1" <sip:2001@142.100.64.12>
Remote-Party-ID: "HQ Phone 1" <sip:2001@142.100.64.12>;party=called;screen=yes;privacy=off
Contact: <sip:2001@142.100.64.12:5060>
Content-Length: 0

+++ CUCM отвечатет 200OK, подтвеждает кодек G711ALAW
SIP/2.0 200 OK
Via: SIP/2.0/UDP 142.102.64.254:5060;branch=z9hG4bK381B0
From: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
To: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
Date: Thu, 04 Jun 2015 16:09:20 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
CSeq: 101 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:  1800;refresher=uas
Require:  timer
P-Asserted-Identity: "HQ Phone 1" <sip:2001@142.100.64.12>
Remote-Party-ID: "HQ Phone 1" <sip:2001@142.100.64.12>;party=called;screen=yes;privacy=off
Contact: <sip:2001@142.100.64.12:5060>
Content-Type: application/sdp
Content-Length: 237

v=0
o=CiscoSystemsCCM-SIP 2552 1 IN IP4 142.100.64.12
s=SIP Call
c=IN IP4 142.102.64.50
b=TIAS:64000
b=AS:64
t=0 0
m=audio 27628 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

+++ CUBE отвечает ACK
+++ Устанавливается RTP медиа поток между 4001/CUBE и IP-телефоном 2001 142.102.64.50
ACK sip:2001@142.100.64.12:5060 SIP/2.0
Via: SIP/2.0/UDP 142.102.64.254:5060;branch=z9hG4bK391613
From: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
To: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
Date: Thu, 04 Jun 2015 16:09:20 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0

+++ Телефон 2001 нажимает Transfer
+++ CUCM отправляет на CUBE re-INVITE inactive, чтобы закрыть RTP
INVITE sip:4001@142.102.64.254:5060 SIP/2.0
Via: SIP/2.0/UDP 142.100.64.12:5060;branch=z9hG4bK1011e1894b1
From: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
To: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
Date: Thu, 04 Jun 2015 16:09:37 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
Supported: timer,resource-priority,replaces
Min-SE:  1800
Cisco-Guid: 0868164442-0168694245-2153431068-1870706469
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uac
P-Asserted-Identity: "HQ Phone 1" <sip:2001@142.100.64.12>
Remote-Party-ID: "HQ Phone 1" <sip:2001@142.100.64.12>;party=calling;screen=yes;privacy=off
Contact: <sip:2001@142.100.64.12:5060>
Content-Type: application/sdp
Content-Length: 243

v=0
o=CiscoSystemsCCM-SIP 2552 2 IN IP4 142.100.64.12
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
m=audio 27628 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 142.100.64.12:5060;branch=z9hG4bK1011e1894b1
From: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
To: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
Date: Thu, 04 Jun 2015 16:09:37 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

+++ CUBE соглашается
SIP/2.0 200 OK
Via: SIP/2.0/UDP 142.100.64.12:5060;branch=z9hG4bK1011e1894b1
From: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
To: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
Date: Thu, 04 Jun 2015 16:09:37 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "SiteC Phone1" <sip:4001@142.102.64.254>;party=called;screen=no;privacy=off
Contact: <sip:4001@142.102.64.254:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Session-Expires:  1800;refresher=uac
Require: timer
Supported: timer
Content-Type: application/sdp
Content-Length: 265

v=0
o=CiscoSystemsSIP-GW-UserAgent 2948 4994 IN IP4 142.102.64.254
s=SIP Call
c=IN IP4 142.102.64.254
t=0 0
m=audio 16636 RTP/AVP 8 101
c=IN IP4 142.102.64.254
a=inactive
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

+++ CUCM отправляет ACK
ACK sip:4001@142.102.64.254:5060 SIP/2.0
Via: SIP/2.0/UDP 142.100.64.12:5060;branch=z9hG4bK1024df0b950
From: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
To: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
Date: Thu, 04 Jun 2015 16:09:37 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence
Content-Length: 0

+++ CUCM отправляет на CUBE re-INVITE, чтобы подключить MOH, пока 2001 дозванивается/разговаривает с 2002
INVITE sip:4001@142.102.64.254:5060 SIP/2.0
Via: SIP/2.0/UDP 142.100.64.12:5060;branch=z9hG4bK1031655b843
From: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
To: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
Date: Thu, 04 Jun 2015 16:09:37 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
Supported: timer,resource-priority,replaces
Min-SE:  1800
Cisco-Guid: 0868164442-0168694245-2153431068-1870706469
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 102 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uac
P-Asserted-Identity: "HQ Phone 1" <sip:2001@142.100.64.12>
Remote-Party-ID: "HQ Phone 1" <sip:2001@142.100.64.12>;party=calling;screen=yes;privacy=off
Contact: <sip:2001@142.100.64.12:5060>
Content-Length: 0


SIP/2.0 100 Trying
Via: SIP/2.0/UDP 142.100.64.12:5060;branch=z9hG4bK1031655b843
From: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
To: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
Date: Thu, 04 Jun 2015 16:09:37 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

+++ CUBE анонсирует только G711ALAW (далее это сообщение повторится еще 5 раз, но CUCM не ответит и будет BYE от CUBE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 142.100.64.12:5060;branch=z9hG4bK1031655b843
From: <sip:2001@142.100.64.12>;tag=2552~b9838bc9-5583-408a-9aaa-e3b9d50e9175-45189062
To: "SiteC Phone1" <sip:4001@142.102.64.254>;tag=1029B3F0-1D03
Date: Thu, 04 Jun 2015 16:09:37 GMT
Call-ID: E4445AAA-A0A11E5-8069DA68-812614E8@142.102.64.254
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "SiteC Phone1" <sip:4001@142.102.64.254>;party=called;screen=no;privacy=off
Contact: <sip:4001@142.102.64.254:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Session-Expires:  1800;refresher=uac
Require: timer
Supported: timer
Content-Type: application/sdp
Content-Length: 253

v=0
o=CiscoSystemsSIP-GW-UserAgent 2948 4995 IN IP4 142.102.64.254
s=SIP Call
c=IN IP4 142.102.64.254
t=0 0
m=audio 16636 RTP/AVP 8 101
c=IN IP4 142.102.64.254
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

После получения этого 200OK s/SDP g711alaw от CUBE происходит то, о чем писал выше.

New Member

Михаил,

Отсутствие MOH или невозможность его подключения для абонента, как правило, выражается в виде тишины в трубке, когда ставят на удержание, но не в виде разрыва соединения.

В логах же я нашел сообщение, что причина рассоединения из-за отсутствия mtp на телефоне. А mtp cucm пытался вовлечь для транскодинга, так как телефон установил два соединения с разными кодеками g711. Разрыв соединения из-за невозможности соединить вызов на разных кодеках вполне может быть, хотя бывали и случаи, когда вызов устанавливался, но была тишина :-). Могу выложить логи на эту тему, но они есть в моем ответе.

Я сегодня-завтра попробую собрать в лаборатории схему аналогичную заданию, но поиграюсь с кодеками для moh. Так же поробую случай, когда кодек в moh неподдерживаемый устройствами, а сами устройства работают на одном кодеке.

Мой вопрос остается открытым, хочется увидеть логи, подтверждающие рассоединение вызова из-за того, что в moh был "неподходящий" кодек.

New Member

Валерий,

Я понимаю Ваше стремление, но еще раз обращу Ваше внимание, что я бы хотел увидеть сообщения из логов, которые подтверждают, что разрыв соединения из-за рассогласования кодека MOH и кодека транка. В Вашем ответе нет таких сообщений, а только догадки - сигнализационные сообщения хоть и приводятся, но слова MOH в них нигде нет.
Предлагаю дождаться ответа от Михаила.

PS: Когда соберу схему в лаборатории я проверю Ваше теорию, что вызов разорвется даже если просто нажать hold. Хотя на практике, на сколько я помню, такого никогда не встречал, даже если вообще не было MOH.

Cisco Employee

После того, как звонок был поставлен на удержание - это часть диалога с указанием a=inactive для голосового канала - CUCM выбирает MOH:

00599037.002 |09:09:37.958 |AppInfo |MRM::getMohDeviceGivenMrgl
00599037.003 |09:09:37.958 |AppInfo |MRM::getMohDeviceGivenMrgl DeviceName=MOH_2 DeviceType=70 Group=0 Counter=0 Capability=0 MultiCast=0 MRGL=
00599037.004 |09:09:37.958 |AppInfo |MRM::getMohDeviceGivenMrgl DeviceName=MOH_3 DeviceType=70 Group=0 Counter=0 Capability=0 MultiCast=0 MRGL=
00599037.005 |09:09:37.958 |AppInfo |MRM::getMohDeviceGivenMrgl GETTING MOH FROM DEFAULT LIST
00599037.006 |09:09:37.958 |AppInfo |MRM::getAnnDeviceGivenMrgl
00599037.007 |09:09:37.958 |AppInfo |MRM::getAnnDeviceGivenMrgl FROM DEFAULT LIST

и отправляет Invite для согласования параметров подключения на CUBE:

00599092.001 |09:09:37.960 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 142.102.64.254:[5060]:
[8040,NET]
INVITE sip:4001@142.102.64.254:5060 SIP/2.0

после получения 200 Ok:

00599101.001 |09:09:38.038 |AppInfo |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 1066 from 142.102.64.254:[63506]:
[8042,NET]
SIP/2.0 200 OK

он выделяет ресурс (MOH_2):

00599110.000 |09:09:38.039 |SdlSig |MrmAllocateMohResourceReq |waiting |MediaResourceManager(2,100,131,1) |MatrixControl(2,100,135,53) |2,100,238,1.93^142.102.64.254^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=45189067 MRGLPkid=f52973a9-f7d8-b7b9-23e4-f26ef2ddc1c3 MulticastFlag=F Pid=2,100,212,48 AudioSourceId= 0x0 UserDefault=0 NetworkDefault=0 ClusterDefault=1 HoldType=1 hasLocationCACInfo=T locPkid=29c5c1c4-8871-4d1e-8394-0b9181e8c54d locName=Hub_None deductBW=F fateShareId=HQCluster:45189062 videoTrafficClass=3

...

00599127.000 |09:09:38.041 |SdlSig |MrmAllocateMohResourceRes |awaiting_media_allocated |MatrixControl(2,100,135,53) |MediaResourceManager(2,100,131,1) |2,100,13,1.222^*^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] CI=45189067 Name=MOH_2 Pid=2,100,123,8 Region=Default DevicePoolMrglPkid=f52973a9-f7d8-b7b9-23e4-f26ef2ddc1c3 AudioSourceId=1 useTRP=F isSecureDevice=F IP=0 Port=0capcount=1cryptocapcount=0 locPkid=29c5c1c4-8871-4d1e-8394-0b9181e8c54d locName=Hub_None deductBW=F fateShareId=HQCluster:45189063 videoTrafficClass=0

после чего и происходит указанная в ответе проблема с несовместимостью кодеков.

New Member

Михаил,

Покажите, пожалуйста, где в логах сообщения CUCM о том, что он принял решение разорвать соединение из-за несогласованности кодека MOH-сервера с кодеком входящего вызова.

Cisco Employee

Григорий, "как правило" - это несерьезный разговор. Задача же не про абстрактный, наиболее часто встречающийся в мировой практике случай - она про конкретную проблему, с конкретными симптомами и собранными логами.

Как сказано в ответе выше, и вы это можете легко увидеть в SIP диалоге, разрыв соединения производит CUBE. Причина - отсутсвие запроса ACK со стороны CUCM. Если бы соединение разрывалось из-за того, что CUCM не может что-то там соединить, то разъединение бы происходило по его инициативе.

Удачи вам с repro.

Cisco Employee

Такого сообщения в логе нет, как вы можете увидеть в ответе (и в логах), звонок сбрасывает CUBE.

New Member

Михаил, спасибо за ответы.

New Member

Михаил, добрый день.
Можете уточнить, как решили проблему в реальном кейсе? По первому способу или по второму?


Я попробовал воспроизвести проблему в лаборатории, но проблема из задачи у меня не проявилась. Основные условия при организации тестовой схемы были:
1. SIP-транк, который работает на кодеке только g711a, от Cisco ISR (CUBE) до CUCM 9.1.

2. System > Service Parameters > Cisco IP Voice Media Streaming App > Supported MOH Codecs выставлен кодек g711ulaw.

3. В настройках всех участников теста есть MRGL с MRG, в котором есть MOH с g.711ulaw, но нет MTP.

4. В Audio Codec Preference List  кодек g711u в приоритете над g711a, чтобы номера Б и В выбрали кодек g711u.

Испытание проводилось аналогично заданию. Номер А звонил номеру Б, номер Б нажимал трансфер и набирал номер В. После разговора с номером В в течение минуты номер Б соединял номера А и Б (производился трансфер).
В результате теста разъединения вызова не произошло ни на одном этапе, а после трансфера была двухсторонняя слышимость.

При просмотре логов увидел, что в отличии от случая в задании, в тестовой схеме CUCM ответил ACK в сторону CUBE, когда происходило удержание на hold при трансфере, но в трубке телефона А, конечно, была тишина. При этом, также как в логах задачи, номер А соединяется с номером Б по кодеку g711a, номер Б соединяется с номером В по кодеку g711u...есть сообщения о выделении moh, и что не совпадает кодек moh и стороны для которой он выделялся, только вот ACK от CUCM к CUBE все равно отправился.

Есть еще вопрос, Михаил, где в логах данного задания можно увидеть, что CUCM не отправлял ACK, потому что кодек MOH не совпадал с кодеком, который отправил CUBE в SDP?

Поясню свою "активность" и данные вопросы =), первый раз встречаю, чтобы "из-за MOH" CUCM разорвал соединение, тест в лаборатории не подтвердил такую ситуацию, логи в задании подтверждают все, что вы написали, но остался пробел - почему CUCM не отправляет ACK? Из-за "разности кодеков MOH и CUBE"? В лаборатории точно так же было, но CUCM такой же версии все равно отправил ACK на кодек g711a. Поэтому есть предположение, что из-за чего-то другого CUCM не послал ACK в данной конкретной задаче.

Cisco Employee

Хм, интересно.

Григорий, а вы можете приложить или прислать мне напрямую логи с вашего теста? Дело в том, что задачу эту я делал почти год назад и перепроверить сейчас в лабе у меня возможности нет.

New Member

Михаил, да, конечно. Приложить сюда полный лог, к сожалению, не могу, но могу прислать лично по почте. Укажите, пожалуйста, Ваш контактный email.

Cisco Employee

А в профиле он не показывается - сейчас посмотрел и не нашел там сходу опции его показывать/скрывать?

mshcheko@cisco.com

New Member

В профиле не заметил сразу.
Сделал свежий тест и отправил логи на почту.

Cisco Employee

Для тех, кто следил за обсуждением - у Григория (в отличие от трейсов из задачи) после неудачи с MOH выделялся Annunciator, который поддерживал PCMA и поэтому звонок не сбрасывался.

New Member

Спасибо, было интересно в чем же разница!

800
Просмотры
0
Полезный материал
27
Комментарии