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

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

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

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

 

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

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.

 

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

Комментарии
Dmitry Karimov
Beginner

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

Mikhail Shchekotilov
Cisco Employee

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

Yury Lipkin
Beginner

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

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

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

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? =)

dokuchaevd
Community Member

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

Mikhail Shchekotilov
Cisco Employee

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

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

Valery Kuznetsov
Enthusiast

Нужно смотреть лог полностью, конкретно из этих строчек можно сделать вывод, что сторона А поддерживает только кодек 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.

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

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

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

Valery Kuznetsov
Enthusiast

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

Валерий,

В задании ничего не написано о жалобах на отсутствие музыки ;-), поэтому про музыку это только Ваши догадки, а догадки не могут быть доказательством. Более того, видно, что голосовой канал был открыт. А судя еще и по этому пункту:
- если же им приходится долго ждать ответа третьего абонента, или при разговоре с ним, исходный звонок теряется
открывается и второй голосовой канал между абонентами 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

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

Михаил,

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

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

Valery Kuznetsov
Enthusiast

Григорий,

Вы говорите про звонок между 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 происходит то, о чем писал выше.

Михаил,

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

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

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

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

Валерий,

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

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