Имеется следующая проблема - не удается связать по 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).
Соответственно, вопросы: 1. Почему в SETUP отправляется адрес не своей с точки зрения ТГ адрес? Можно ли как-то прибить (закрепить) адрес за ТГ? 2. Действительно ли указанная настройка доступа позволяет задать тип компандирования для доступа, отличный от общего на УАТС? 3. Если поменять глобально тип компандирования на всех узлах с A на u (в курсе, что в Европе он не используется), скажется ли это на качестве связи с ТфОП, к которому подключены по потокам E1?
Уважительно прошу Вашей помощи, так как уже сломал мозг с этой проблемой интеграции.
При работе по IP с Cisco - рекомендую в IP/IP parameters выключить Round trip delay request (он правда обычно не влиял на установление соединений, а отвечал за прерывание разговора).
Андрей пишет: По каким соображениям вы выкладываете скриншоты обмена вместо самого обмена ?
Секрета никакого нет. Буду очень признателен если присоединитесь к разбору pcap-файлов. Ссылки:
Я также не уточнил, что в схеме имеется еще сторонний гейткипер от Radvision. Не упоминал о нем, потому как вряд ли проблема связана с ГК - я проверял поведение Cisco C40 как в режиме изначальном с регистрацией на ГК, так и в прямом режиме, т.е. без ГК вовсе, симптомы одинаковые.
На всякий случай адресация: 10.197.133.13, 10.197.133.14 - адреса плат INTIP на станции. 10.69.133.36 - Cisco C40 10.69.133.57 - ГК
Имеется также стороннее устройство - терминал-клиент H323, который наравне с Cisco C40 регистрируется на ГК и на который я успешно могу звонить с УАТС. Более того, с этого клиента я могу звонить на Cisco C40. Дампы подобных взаимодействий также снял
Цитата
Dmitry Ryzhakov пишет: попробуйте выключить в Н.323 Fast start в IP > IP parameters если у вас нет сети ABC-F с IP транками, либо попросите админов Циско показать как настроен транк у них на предмет Fast Start H.323
Станция взаимодействует с другими с использованием гибридных линков. Видимо, в моем случае изменить режим на FastStart на УАТС нельзя, ибо отвалятся гибридные линки?
Цитата
Username пишет: Это не сегментированные пакеты и не служебные пакеты. Это H.245, что-то вроде SDP в SIP - определение media capabilities и пр., очень важная часть при установлении соединения по H.323.
Никто и не спорит насчет важности этих пакетов. Просто по какой-то причине иногда пакеты не объединяются, но в большинстве случаев идет объединение двух пакетов в один. Может быть, это, конечно, стандартное поведение? Мне известны такие ситуации только из области передачи данных - я уже упоминал про TCP Offload. Но видимо, здесь это что-то другое, так как с использованием ethtool на обеих сторонах (УАТС и Cisco C40 - обе Linux-based и имеют в своем составе данную утилиту) удалось выяснить, что TCP offload не используется.
Коллеги, если обнаружите что-то интересное, могущее являться причиной, дайте пожалуйста знать. Буду очень признателен.
В обратную сторону звонки не ходят. Точнее сказать, имеет место странная ситуация. При звонке в циски плата intip стабильно уходит в перезагрузку. При проверке входящей связи с другого клиента гейткипера, аппаратного терминала Sony, связь устанавливается в обоих направлениях. Тут ещё нужно учесть, что циска пытается установить связь с использованием g711, который на станции включён только на выделенной транк-группе. Данная тг имеет локальную настройку на использование компрессии g711 и используется только по исходящей связи через префикс захвата и сокращений набор. При входящей связи стыка с тг не происходит. Как пристыковать данную тг для некоторых входящих звонков, например, с определённых номеров, ума не приложу. В любом случае, перезагрузки платы происходить не должно.
На самом деле, звонки со стороны циски в сторону УАТС для нас не так важны. Предполагается что при звонках между абонентами УАТС должна быть возможность подключения аудио конференц-системы. В обратную сторону звонить не предполагается.
error пишет: Cause 0x5a - Destination address missing, and direct call not subscribed
Error, что-то не вижу этого сообщения. Подскажите пожалуйста в каком месте дампов или трассировки вы его нашли?
Значит ли оно, что для циски важно знать звонящего абонента а она его не знает? Вообще странно, ведь на стороне гейткипера для перечня абонентов УАТС я создал статическую запись типа gateway с указанием ip адреса платы intip УАТС. Данная настройка успешно проверяется с аппаратного терминала sony и иногда даже с самой циски.
Андрей пишет: Про закон компандирования непонятно, с чего вы взяли, что вам надо что-то куда-то переключать, да еще предъявлять всякое.
133.36 вам сразу предлагает "receiveAudioCapability: g711Alaw64k (1)", на что с вашей стороны букет кодеков.
Андрей, Вы абсолютно правы. Я тоже ранее обращал внимание на то что циска шлет список кодеков включая g711a. В веб-интерфейсе циски есть кнопка о состоянии текущего вызова, которая показывает текущие кодеки,vad, скорости потока и другое. Поначалу я заморочился на компандировании так как в момент полуустановившейся связи, то есть когда циска уже считает что связь установлена а на станции продолжаются кпв данная статистика показывала что циски использует g711u. При этом эта же статистика ничего не говорила о том какой кодекс использует станция. В редкие моменты успешной связи на стороне циски опять же показывался g711u а на стороне станции g711a при этом в трубке были слышны свисты и трески.
Я поэтому и надеялся, что устранив проблему этого не соответствия удастся полностью решить проблему. Но ошибся. Применив специальный фильтр на стороне циски мы запретили использование определённых кодеков. Теперь g711a используется с двух сторон, но ситуация с полуустановившимся соединением как была так и осталась.
Нужно ещё добавить, что звонки с циски на терминал Sony работают в обоих направлениях. Оба устройства динамически регистрируются на гк.
Андрей пишет: А также в неуспешном сценарии от Циски не приходит подтверждение открытия логического канала.
Бинго! Не получив OpenLogicalChannelAck OXE с чистой совестью по истечении таймера 10 секунд завершает вызов. Почему Cisco ведет себя по-разному в удачном и неудачном сценарии - вопрос к Cisco/Tandberg'у.
Спасибо Username! Похоже причина действительно в этом. Пока правда не знаю как решить проблему. Возник следующий вопрос. Если внимательно посмотреть взаимодействие между клиентом Sony и Cisco C40, файл выложен мною ранее
то можно заметить, что в конечном итоге клиент Sony (10.69.133.26) получает OpenLogicalChannelAck от гейткипера (10.69.133.57), т.е. гк является полноценным маршрутизатором всех сообщений. Действительно, в его настройках есть опция о режиме и сейчас установлен Routed mode for Q.931 and H.245. Не правильней ли будет в качестве точки назначения в ячейке сокращенного набора указать адрес не CiscoC40, а адрес ГК? Правда, насколько я помню, пробовал и такой вариант, тоже безуспешно. Но все-таки?
error пишет: Cause 0x5a - Destination address missing, and direct call not subscribed
Уважаемый error, 0x5a это не причина, а код сообщения RELEASE COMPLETE.
Код
.001 0000 = Cause value: Normal call clearing (16)
Цитата
Vladimir Shushkov пишет: Не правильней ли будет в качестве точки назначения в ячейке сокращенного набора указать адрес не CiscoC40, а адрес ГК?
Есть немалая вероятность того, что и с ГК будут такие же проблемы. Проблема, по-моему мнению, в том, что C40 не использует Fast Start и H245 tunneling (это видно в Flow Sequence в Wireshark)
Коллеги, спасибо! Буду разбираться с настройками FastStart.
Хочу задать еще несколько теоретических вопросов:
1. Обмен между станцией и Cisco показывает, что станция отправляет в сообщении SETUP версию протокола 0.0.8.2250.0.2, т.е. версия 2. Cisco же в ответном ALERT содержит указание на версию 0.0.8.2250.0.6 (версия 6). Значит ли это что Cisco обязана поддерживать FastStart, который как я понял был введен еще во 2й версии? Или же разные вендоры по-разному трактуют начинки версий и могут не включить тот или иной функционал? Спрашиваю, потому как в системных настройках Cisco нигде не видел упоминания о FastStart, и есть опасения, что эта фича просто не поддерживается (хотя казалось бы странно, ведь версия анонсируется 6я). Аналогично насчет H245Tunneling.
2. Если все-таки C40 невозможно настроить на использование FastStart, а станцию переводить на Slow Call Setup не хочется, есть ли возможность разрулить ситуацию с помощью гейткипера в Routed mode? Т.е. возможно ли чтобы ГК одно плечо вызова отрабатывал по FastStart, а другое по SlowStart, или же ГК в режиме роутера просто занимается подменой адресов в H245 сообщениях? Так как текущий ГК довольной куцый в плане настроек, может быть рассмотреть варианты использования каких-то открытых решений, например, поставить другой ГК типа GNU Gatekeeper или вообще вставить Asterisk в качестве шлюза?
3. Все-таки хотел еще уточнить насчет переключения УАТС в SlowStart режим. Во-первых, влияет ли это на гибридные IP линки? Что с ними произойдет? Отвалятся? Во-вторых, если все станции (у нас их 3) перевести в SlowStart заметны ли будут ухудшения в плане установления связи?
4. Когда мы задаем режим работы ГК как Direct или Routed, по идее, конечные узлы должны знать о режиме работы ГК, чтобы знать куда отправлять SETUP (на ГК или напрямую на вызываемого абонента). Правильно ли я понимаю, что абоненты получают информацию о режиме работы ГК в момент своей регистрации? Поэтому при изменении режима работы ГК требуется перерегистрация абонентов?
