Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru

Страницы: 1 2 3 4 След.
RSS
О проблеме выбора платы INTIP и кодеках, В сообщений SETUP указан адрес соседней платы, изменить типа кодека
 
Здравствуйте, Коллеги!

Имеется следующая проблема - не удается связать по H323 УАТС и аппаратный кодек Cisco C40, к которому по аналогу подключена система аудиоконференцсвязи. На УАТС настройки все выполнил согласно документации - создал ячейку сокращенного набора типа IP, где прописал IP циски, создал транк-группу, привязал ее к незадействованному доступу одной из плат INTIP. При звонке со станции вызов проходит на циску, однако когда на ней (циске) снимаешь трубку, то с точки зрения циски вызов кажется установленным, а на станции продолжает идти КПВ. Иногда, примерно 1 из 10 случаев, соединение устанавливается с двух сторон, но на телефоне УАТС слышны жуткие трески. По трассировкам полученным с помощью t3 видно, что когда не устанавливается двухсторонней связи, на УАТС не приходит CONNECT, однако согласно дампам, собранным Wireshark-ом видно, что CONNECT циска все же отправляет, просто он не распознается станцией по каким-то причинам.

Так как станция по умолчанию работает на кодеке G723, а Cisco C40 поддерживает кодеки G711 и G722, нами выполнены следующие настройки на станции:
1. Включен режим задействования нескольких кодеков Multicompression (раздел документации IP PCX Networks -> Direct RTP in network -> Coding Configuration -> Multi-Algorithms). В результате станция в SETUP сообщений отправляет 2 поддерживаемых кодека – G723 и G729.
2. В созданной для взаимодействия транк-группе на УАТС 150 типа IP указан тип кодека G711.

В результате станция в SETUP отправляет 3 кодека G723, G729, G711.

Подозреваю, что проблема кроется в типе компандирования. Станция работает с A-law. Однако логах циски везде фигурирует u-law. Настроек по изменению u- на A- на циске не нашел (это не роутер, имеется только очень бедный веб-интерфейс).

Обратился в тех.поддержку. Посоветовали включить u- конкретно для доступа, к которому привязана транк-группа. Соответственно в настройке
Код
shelf>board>digital access > Mu Law for BEARER CAP 
поставил YES и перезагрузил плату. Никаких положительных сдвигов.

В ходе снятия трассировки, обратил внимание, что в SETUP сообщении, которое посылает станция, указан IP адрес другой INTIP платы, также имеющейся в этой станции и используемой для межстанционного гибридного линка, т.е. созданная ТГ для взаимодействия с циско привязана к доступу 0-13-1, а в SETUP указан IP платы 0-17 (гибридный линк для отказоустойчивости использует два доступа 0-13-0 и 0-17-0).

Код
mtracer started ...
(370318:000001) MTRACER host (10.197.133.2, gu_06), version: R8.0.1-g1.503-35-h-ru-c7s2
(370318:000001) MTRACER num: 004, time: 2016/08/04 07:29:21, loss: 0%
 ______________________________________________________________________________
| (370343:000002) 1093: Send_IO1 (link-nbr=13, sapi=0, tei=0) :
| long: 121  desti: 0  source: 15  cryst: 0  cpl: 13  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  00 06
|______________________________________________________________________________
|
| [9f] Non-locking shift. codeset : 7 
| [a2] EI_IP_TYPE_TERM
| [9f] Non-locking shift. codeset : 7 
| IE:[05] EI_IP_INFOS (l=9) -> G723  Ece 1 Vad 1 Profil 2, IPv4 :10.69.133.36.
| [9f] Non-locking shift. codeset : 7 
| IE:[06] EI_IP_PAYLOADS (l=2) : (COMP/ECE/VAD)   -> G729/1/1  G711a/1/0  
| [9f] Non-locking shift. codeset : 7 
| IE:[07] EI_IP_QOS (l=3) b8 a0 00 
| [9f] Non-locking shift. codeset : 7 
| IE:[0a] EI_RTP_INFO (l=30) 
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=1 rqm=0 
|    -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96 
|    -> Port RTP     = 32764, IPv4 :    10.  197.  133.    4.
|    -> Port RTCP SR = 32765, IPv4 :    10.  197.  133.    4.
|    -> Port RTCP RR = 32765, IPv4 :    10.  197.  133.    4.
|    -> Port Fax     = 32767, IPv4 :    10.  197.  133.    4.
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3 
| IE:[18] CHANNEL (l=3)  a8 83 81 -> T2 : No B channel
| IE:[28] DISPLAY (l=13)  `SHUSHKOV V.G.`
| IE:[6c] CALLING_NUMBER (l=6)  ->  01  81  Num : 1381
| IE:[70] CALLED_NUMBER (l=5)  ->  81  Num : 1573
| IE:[7d] HLC (l=2) 91 81 
| [a1] Sending complete
|______________________________________________________________________________


Соответственно, вопросы:
1. Почему в SETUP отправляется адрес не своей с точки зрения ТГ адрес? Можно ли как-то прибить (закрепить) адрес за ТГ?
2. Действительно ли указанная настройка доступа позволяет задать тип компандирования для доступа, отличный от общего на УАТС?
3. Если поменять глобально тип компандирования на всех узлах с A на u (в курсе, что в Европе он не используется), скажется ли это на качестве связи с ТфОП, к которому подключены по потокам E1?

Уважительно прошу Вашей помощи, так как уже сломал мозг с этой проблемой интеграции.

Большое спасибо!
 
звонки идут с intip. TG тут не причем, в нее могут входить несколько intip c разными IP
cisco это не европа
вам стоит разобраться с настройкой h323-транка в Cisco C40 и свести к минимуму т.е. убрать лишний мусор из сигнализации

учебный материал http://www.intersyst.ru/support/forum/messages/forum21/topic1916/message15515/#message15515
Пути IP-пакета неисповедимы
 
Да в том-то и дело, что Cisco C40 это не какой-то CUCM/CUCME или классический циско роутер, где возможности настройки достаточно гибкие. Здесь все настройки в веб-нитерфейсе - это адрес режим работы (direct или через гейткипер), адрес гейткипера и непосредственно номер телефона самой Cisco C40. Остальные параметры относятся к различным аналоговым портам, имеющимся на борту (всякие коэффициенты усиления и т.д.)
CiscoC40
Поэтому убрать мусор настройками циски, видимо, не получится. Остается надеяться на настройки УАТС.

Уважаемый error! Я понимаю, что звонки идут с intip. Вопрос в том, что если в станции две платы intip
0-13 и 0-17, например с ip адресами 10.0.0.1 и 10.0.0.2 соответственно. Когда я создаю ТГ типа IP и добавляю в нее доступ 0-13-0, не должно ли это означать, что в SETUP сообщениях в качестве адреса должен указываться 10.0.0.1? Можно ли это настроить? Или же станция сама случайным образом выбирает адрес какой из плат ей отправить и это никак не настраивается? Даже в этом случае у нас наверное должны были бы светиться вызовы и с платы 0-13 примерно в 50% случаев, но у нас всегда указывается адрес второй платы.

В ссылке, которую Вы дали, есть ссылка на параметр  alaw to ulaw. Правильно ли я понимаю что речь идет о настройке  alaw to ulaw conversion на которую я уже обращал внимание, но пока не трогал?

Спасибо!
 
Цитата
Vladimir Shushkov пишет:
Правильно ли я понимаю что речь идет о настройке alaw to ulaw conversion
именно так


Цитата
Vladimir Shushkov пишет:
Когда я создаю ТГ типа IP и добавляю в нее доступ 0-13-0, не должно ли это означать, что в SETUP сообщениях в качестве адреса должен указываться 10.0.0.1?
сигнализация ДА т.е. с 10.0.0.1 (если 0-13 имеет это IP)
RTP тоже ДА если источник является TDM, если источник является IP то все зависит параметра "direct ip" в разделе IP т.е. хочу сказать если звонок пришел на плату 0-17 источник RTP будет либо 0-17 если разнощёрстные кодеки либо сам IP-терминал

на сколько я помню на Alcatel приходится выбирать либо g723 либо g729

снимайте tcpdump с порта Cisco C40 (входящий и исходящий звонок)
Пути IP-пакета неисповедимы
 
Цитата
error пишет:
сигнализация ДА т.е. с 10.0.0.1 (если 0-13 имеет это IP)
так в том-то и дело, что почему-то несмотря на то, что доступ прописан для платы 0-13, по факту в SETUP идет отправка адреса платы 0-17. Почему так может быть?

Цитата
error пишет:
Цитата
Vladimir Shushkov пишет:
Правильно ли я понимаю что речь идет о настройке alaw to ulaw conversion

именно так

а вот по преобразованию A в u подрядчик ответил - цитирую:

Код
A-Law to Mu-law conversion 
This attribute allows the 4400 operating in A law to be connected to Mu law switch. This is done with a T1 loop interface (DPT1 board) which converts the voice coding law. All incoming or outgoing T1 calls must go via the DPT1 board. 
Procedure: 
•   Create two T1 CCS trunk groups, looped back one onto the other (cabling of an access on the other), 
•   Set the Reserved attribute to YES (Shelves/boards/Digital accesses)in one of the digital access of the DPT1, 
•   Set the T0 Mu Law attribute to YES, 
•   Manage the numbering so that calls going to or coming from the T1 go through the T1 looped back trunk group (there are different ways and the choice belongs to the installation technician according to the state of the corresponding installation (abbreviated number, DID number...). 
The T1 boards correspond to DPT1 for OmniPCX Enterprise and PRA -T1 for OmniPCX Office. In the second case, 2 PRA-T1s are required. 
Требуется специальная плата, чтобы это работало.


Т.е. что, реально нужна плата и без нее никак, механизм не заработает?

Спасибо!
 
Смысл зацикливаться на alaw to ulaw conversion? Из приведенного описания видно, что C40 поддерживает:

•G.711
•G.722
•G.722.1
•G.729AB
•64 kbps and 128 kbps AAC-LD, mono and stereo

Соединение должно устанавливаться и работать хотя бы на G.729.
Если версия OXE позволяет, то на G.722 должно заработать.
Изменено: Username - 21.08.2016 11:44:29
 
Цитата
Username пишет:
Смысл зацикливаться на alaw to ulaw conversion? Из приведенного описания видно, что C40 поддерживает:

•G.711
•G.722
•G.722.1
•G.729AB
•64 kbps and 128 kbps AAC-LD, mono and stereo
Может это для Cisco C60. Вот, например, по другой ссылке G729 нет.
Datasheet CiscoC40
Тем более, что УАТС отправляет 3 кодека в SETUP - G723, G729, G711.

Насчет G722 в документации написано, что этот кодек поддерживается не в полном режиме. Точно не помню, но вроде как только для Endpoint. Поправьте если я не прав.
 
По этой ссылке поддержка G.729 для H.323 появилась в версии TC 6.2.0, возможно, надо firmware на С40 обновить.
http://www.cisco.com/c/dam/en/us/td/docs/telepresence/endpoint/software/tc6/r­elease_notes/tc_software_release_notes_tc6.pdf. Хотя не факт, может там программно транскодинг делается (как на CUCM).

Проблема все равно в том, что соединение должно устанавливаться или нет. В wireshark-трассе надо смотреть.

Да, с G.722 в OXE как-то не очень. То есть он поддерживается для 2-х IP-устройств на одном узле, при условии, что оба устройства его поддерживают. Как понимаю, функцию транскодинга (для TDM-оборудования) для G.722 OXE не делает.
Изменено: Username - 21.08.2016 21:13:42
 
Цитата
По этой ссылке поддержка G.729 для H.323 появилась в версии TC 6.2.0, возможно, надо firmware на С40 обновить.
Спасибо, насчет версии софта обязательно посмотрю.

Однако вопросы по OXE все еще открыты:

1. Почему OXE может выбирать в SETUP адрес не той платы, что привязана к ТГ?

2. Действительно ли настройка
Код
shelf>board>digital access > Mu Law for BEARER CAP

позволяет задать компандирование для платы, отличное от глобальной настройки УАТС?

3. Действительно ли настройка A-Law to Mu-law conversion  требует наличия специальной платы и конкретно в моем случае она бесполезна?

4. Повлияет ли изменение глобальной настройки A- в u- на качество связи с ГТС по потокам E1 в части голоса/модемов/факсов?

Спасибо!
 
1. Для сигнализации (что мы видим в t3) - выбирается плата указанная в ТГ, а вот rtp  - могут быть указаны любые кодеки из данного IP домена.
2. Насчет конверсии а-law в m-law - я считаю не надо глумить голову, пусть тот кто поставил циску объяснит как переключить в тот закон, что работает на сетях у нас. А то понадобится позвонить в другое место - а у вас Direct RTP - пакеты побегут в другое место - там тоже начнете настраивать конверсию?
 
Цитата
Vladimir Shushkov пишет:
а вот по преобразованию A в u подрядчик ответил - цитирую:
видно что читать имеет но "как и с чем едет" понятие не имеет

вот только остается выяснить когда вам подрядчик скажет - ВКС это ВКС, для выхода во вне вам нужна циска 28 серии как минимум
если возникнет вопрос "зачем" пусть подрядчик спросит в представительство циско
Пути IP-пакета неисповедимы
 
Коллеги, удалось-таки добиться чтобы Cisco C40 слал G711A кодек. Оказалось настройка этого режима производится через экспериментальные настройки специальной API командой. Но, к сожалению, проблему это не решило. Теперь и станция и Cisco C40 договариваются об использовании G711A, но как и прежде в большинстве случаев, когда снимаешь трубку со стороны Cisco C40 при звонке с УАТС на станции продолжаются КПВ, тогда как Cisco считает, что канал уже установлен.

Говорю "в большинстве случаев", так как при непрерывных попытках совершения звонков со стороны УАТС, примерно в 10% вызов все-таки устанавливается двусторонний. Какой-то зависимости, когда это происходит выявить не удалось.

При запуске t3 в случае неуспеха станция не обнаруживает сообщение CONNECT, тогда как сниффер Wireshark показывает наличие этого пакета.
Вот вывод t3 при неуспехе:
Код
______________________________________________________________________________
| (956430:000063) 1058: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 115  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  00 13
|______________________________________________________________________________
|
| [9f] Non-locking shift. codeset : 7 
| [a2] EI_IP_TYPE_TERM
| [9f] Non-locking shift. codeset : 7 
| IE:[05] EI_IP_INFOS (l=9) -> G723  Ece 1 Vad 1 Profil 2, IPv4 :10.69.133.36.
| [9f] Non-locking shift. codeset : 7 
| IE:[06] EI_IP_PAYLOADS (l=2) : (COMP/ECE/VAD)   -> G729/1/1  G711a/1/0  
| [9f] Non-locking shift. codeset : 7 
| IE:[07] EI_IP_QOS (l=3) b8 a0 00 
| [9f] Non-locking shift. codeset : 7 
| IE:[0a] EI_RTP_INFO (l=30) 
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=1 rqm=0 
|    -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96 
|    -> Port RTP     = 32576, IPv4 :    10.  197.  133.   13.
|    -> Port RTCP SR = 32577, IPv4 :    10.  197.  133.   13.
|    -> Port RTCP RR = 32577, IPv4 :    10.  197.  133.   13.
|    -> Port Fax     = 32576, IPv4 :    10.  197.  133.   13.
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3 
| IE:[18] CHANNEL (l=3)  a8 83 81 -> T2 : No B channel
| IE:[28] DISPLAY (l=11)  `SHUSHKOV V.`
| IE:[6c] CALLING_NUMBER (l=6)  ->  01  81  Num : 1473
| IE:[70] CALLED_NUMBER (l=2)  ->  81  Num : 1
| IE:[7d] HLC (l=2) 91 81 
|______________________________________________________________________________

 ______________________________________________________________________________
| (956430:000066) Concatenated-Physical-Event :
| long: 21  desti: 0  source: 0  cryst: 0  cpl: 17  us: 0  term: 1  type a5 
| tei: 0  >>>>  message received : SETUP ACK [0d]  Call ref :  80 13
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=1)  a8 -> T2 : No B channel
|______________________________________________________________________________

 ______________________________________________________________________________
| (956430:000067) 1058: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 24  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : INFORMATION [7b]  Call ref :  00 13
|______________________________________________________________________________
|
| IE:[70] CALLED_NUMBER (l=4)  ->  81  Num : 573
|______________________________________________________________________________

 ______________________________________________________________________________
| (956433:000069) Concatenated-Physical-Event :
| long: 23  desti: 0  source: 0  cryst: 0  cpl: 17  us: 0  term: 1  type a5 
| tei: 0  >>>>  message received : ALERT (01)  Call ref :  80 13
|______________________________________________________________________________
|
| [97] Locking shift. codeset : 7 
| IE:[0a] EI_RTP_INFO (l=2) 
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=0 rqm=0 
|    -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96 
|______________________________________________________________________________

 ______________________________________________________________________________
| (956592:000095) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 17  us: 0  term: 1  type a5 
| tei: 0  >>>>  message received : RELEASE [4d]   Call ref :  80 13
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 a9 -> [a9] TEMPORARY FAILURE
|______________________________________________________________________________

 ______________________________________________________________________________
| (956592:000096) 1058: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : REL COMP [5a]  Call ref :  00 13
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________


Трассировка успешного вызова:
Код
 ______________________________________________________________________________
| (952055:000009) 1058: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 115  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  00 11
|______________________________________________________________________________
|
| [9f] Non-locking shift. codeset : 7 
| [a2] EI_IP_TYPE_TERM
| [9f] Non-locking shift. codeset : 7 
| IE:[05] EI_IP_INFOS (l=9) -> G723  Ece 1 Vad 1 Profil 2, IPv4 :10.69.133.36.
| [9f] Non-locking shift. codeset : 7 
| IE:[06] EI_IP_PAYLOADS (l=2) : (COMP/ECE/VAD)   -> G729/1/1  G711a/1/0  
| [9f] Non-locking shift. codeset : 7 
| IE:[07] EI_IP_QOS (l=3) b8 a0 00 
| [9f] Non-locking shift. codeset : 7 
| IE:[0a] EI_RTP_INFO (l=30) 
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=1 rqm=0 
|    -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96 
|    -> Port RTP     = 32552, IPv4 :    10.  197.  133.   13.
|    -> Port RTCP SR = 32553, IPv4 :    10.  197.  133.   13.
|    -> Port RTCP RR = 32553, IPv4 :    10.  197.  133.   13.
|    -> Port Fax     = 32552, IPv4 :    10.  197.  133.   13.
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3 
| IE:[18] CHANNEL (l=3)  a8 83 82 -> T2 : No B channel
| IE:[28] DISPLAY (l=11)  `SHUSHKOV V.`
| IE:[6c] CALLING_NUMBER (l=6)  ->  01  81  Num : 1473
| IE:[70] CALLED_NUMBER (l=2)  ->  81  Num : 1
| IE:[7d] HLC (l=2) 91 81 
|______________________________________________________________________________

 ______________________________________________________________________________
| (952055:000012) Concatenated-Physical-Event :
| long: 21  desti: 0  source: 0  cryst: 0  cpl: 17  us: 0  term: 1  type a5 
| tei: 0  >>>>  message received : SETUP ACK [0d]  Call ref :  80 11
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=1)  a8 -> T2 : No B channel
|______________________________________________________________________________

 ______________________________________________________________________________
| (952055:000013) 1058: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 24  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : INFORMATION [7b]  Call ref :  00 11
|______________________________________________________________________________
|
| IE:[70] CALLED_NUMBER (l=4)  ->  81  Num : 573
|______________________________________________________________________________

 ______________________________________________________________________________
| (952059:000015) Concatenated-Physical-Event :
| long: 23  desti: 0  source: 0  cryst: 0  cpl: 17  us: 0  term: 1  type a5 
| tei: 0  >>>>  message received : ALERT (01)  Call ref :  80 11
|______________________________________________________________________________
|
| [97] Locking shift. codeset : 7 
| IE:[0a] EI_RTP_INFO (l=2) 
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=0 rqm=0 
|    -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96 
|______________________________________________________________________________

 ______________________________________________________________________________
| (952154:000047) Concatenated-Physical-Event :
| long: 37  desti: 0  source: 0  cryst: 0  cpl: 17  us: 0  term: 1  type a5 
| tei: 0  >>>>  message received : CONNECT (07)  Call ref :  80 11
|______________________________________________________________________________
|
| IE:[28] DISPLAY (l=9)  `Cisco C40`
| [97] Locking shift. codeset : 7 
| IE:[06] EI_IP_PAYLOADS (l=1) -> G711a Ece 0 Vad 0 
| IE:[0a] EI_RTP_INFO (l=2) 
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=0 rqm=0 
|    -> Transm_Bande=0 detection_Q23=1 
|______________________________________________________________________________

 ______________________________________________________________________________
| (952154:000048) Concatenated-Physical-Event :
| long: 54  desti: 0  source: 0  cryst: 0  cpl: 17  us: 0  term: 1  type a5 
| tei: 0  >>>>  message received : FACILITY [62]  Call ref :  80 11
|______________________________________________________________________________
|
| [97] Locking shift. codeset : 7 
| IE:[06] EI_IP_PAYLOADS (l=1) -> G711a Ece 0 Vad 0 
| IE:[0a] EI_RTP_INFO (l=30) 
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=0 rqm=0 
|    -> Transm_Bande=0 detection_Q23=1 
|    -> Port RTP     = 2342, IPv4 :    10.   69.  133.   36.
|    -> Port RTCP SR = 2343, IPv4 :    10.   69.  133.   36.
|    -> Port RTCP RR = 2343, IPv4 :    10.   69.  133.   36.
|    -> Port Fax     = 0, IPv4 :     0.    0.    0.    0.
|______________________________________________________________________________

 ______________________________________________________________________________
| (952154:000049) 1058: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 18  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : CONNECT ACK (0f)  Call ref :  00 11
|______________________________________________________________________________

 

 ______________________________________________________________________________
| (952163:000058) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 17  us: 0  term: 1  type a5 
| tei: 0  >>>>  message received : RELEASE [4d]   Call ref :  00 11
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

 ______________________________________________________________________________
| (952163:000059) 1058: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : REL COMP [5a]  Call ref :  80 11
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

  ______________________________________________________________________________
| (952293:000143) 1058: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : DISCONNECT [45]  Call ref :  00 11
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

 ______________________________________________________________________________
| (952293:000144) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 17  us: 0  term: 1  type a5 
| tei: 0  >>>>  message received : RELEASE [4d]   Call ref :  80 11
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

 ______________________________________________________________________________
| (952293:000145) 1058: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5 
| tei: 0  <<<<  message sent : REL COMP [5a]  Call ref :  00 11
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________


Убедился, что с наличием двух INTIP плат это не связано (проверял, отправляя в перезагрузку одну из плат и убеждался, что при оставшейся одной рабочей проблема сохраняется).

На коммутаторе, куда подключена Cisco C40, настроил мониторный порт и стал исследовать проблему глубже, путем анализа пакетов в Wireshark.

Удалось выяснить следующую закономерность. Вероятнее всего проблема не связана с форматом самого CONNECT пакета. После получения CONNECT станция и Cisco обмениваются еще несколькими служебными пакетами типа terminalCapabilitySet, masterSlaveDetermination, openLogicalChannel, а также их подтверждениями - соответствующими Ack пакетами.

В случае успешного вызова последовательность пакетов имеет вид
Successful call

В случае неуспеха -
Unsuccessful call

Как видно из приведенных скриншотов, почему-то происходит объединение нескольких TCP сегментов в 1. Очень похоже на TCP Offload. Причем, можно заметить, что объединение происходит с обеих сторон, т.е. УАТС тоже причастна к преступлению. В этом случае, при дальнейшем разборе последовательности пакетов видно, как Cisco начинает слать RTP поток, а станция перидически отвечает ICMP пакетом Destination unreachable - Port Unreachable.

Может есть какие-то мысли на этот счет?

Большое спасибо!
Изменено: Vladimir Shushkov - 23.08.2016 22:08:16
 
По каким соображениям вы выкладываете скриншоты обмена вместо самого обмена ?
 
попробуйте выключить в Н.323 Fast start в IP  > IP parameters  если у вас нет сети ABC-F с IP транками, либо попросите админов Циско показать как настроен транк у них на предмет Fast Start H.323
У Дарта Вейдера в столе всякого навалено: карты разные галактик и портрет Гагарина.
 
Ну вот, становится теплее.
Цитата
Vladimir Shushkov пишет:

Удалось выяснить следующую закономерность. Вероятнее всего проблема не связана с форматом самого CONNECT пакета. После получения CONNECT станция и Cisco обмениваются еще несколькими служебными пакетами типа terminalCapabilitySet, masterSlaveDetermination, openLogicalChannel, а также их подтверждениями - соответствующими Ack пакетами.
...



Как видно из приведенных скриншотов, почему-то происходит объединение нескольких TCP сегментов в 1. Очень похоже на TCP Offload. Причем, можно заметить, что объединение происходит с обеих сторон, т.е. УАТС тоже причастна к преступлению. В этом случае, при дальнейшем разборе последовательности пакетов видно, как Cisco начинает слать RTP поток, а станция перидически отвечает ICMP пакетом Destination unreachable - Port Unreachable.
Это не сегментированные пакеты и не служебные пакеты. Это H.245, что-то  вроде SDP в SIP - определение media capabilities и пр., очень важная часть при установлении соединения по H.323.
Прсоединяюсь к Андрею
Цитата
Андрей пишет:
По каким соображениям вы выкладываете скриншоты обмена вместо самого обмена ?
В приведенном удачном  скриншоте курсор вообще стоит на roundtripdlayresponse (то есть keep-alive процедура), а на неудачном openlogicalchannel masterslavedetermination. То есть из приведенных картинок невозможно ничего понять.
Страницы: 1 2 3 4 След.
Читают тему