Здравствуйте, Коллеги!

Накатил сегодня патч на УАТС с 11-м релизом, обновив ранее используемый патч 33 до версии 37.
Перед установкой патча скопировал текущие версии на неактивные разделы на обоих процессорах.
В общем, в результате после всех манипуляций все работает. Единственный момент, который смущает, это то что на станции стали появляться инциденты, которых раньше не было, с частотой примерно раз в 5 минут:

На данном форуме и на Alcatel Unleashed видел рекомендации о необходимости выполнить клонирование на резервный процессор с основного. Сделал клонирование: остановил на резерве телефонию, перезагрузил его с остановленной телефонией, далее через swinst -> Cloning and Duplicate выполнил клонирование на резерве с основного всего за исключением linux данных. Включил автостарт и перезагрузил резерв. Инциденты продолжают появляться.

Проверял целостность БД командой checkdb на обоих процессорах - ничего кроме сообщения об отсутствии DPNSS префикса нет. Наличие ошибки по DPNSS, думаю, не является критичным. По крайней мере, вряд ли это причина данного инцидента.

Нужно добавить что все операции - установка патча, клонирование и т.д. выполнял, подключаясь удаленно по IP (просто видел где-то рекомендации выполнять эти операции по консоли), но неужели это может влиять?

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

Большое спасибо!

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

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

Желаю Вам, Андрей, почаще получать аналогичные ответы на этом и всех других форумах в сети. В книжках все есть.

P.S. Vad-у и всем остальным спасибо!

Понимаю в том числе и голосовой поток. Ожидал при звонке со станции с включенным SlowStart на остальные слышать сигнал занято или иметь проблему аналогичную с C40, когда связь устанавливается односторонняя. Но дозваниваюсь в обе стороны без проблем. Голосовой поток двусторонний.

Здравствуйте, Коллеги!

По следам прошлой темы насчет Cisco C40
Исходящая связь на Cisco

Все-таки хотелось бы для полноты картины добиться того, чтобы с устройств конференц-связи тоже можно было бы звонить на УАТС. К сожалению, в настоящий момент это невозможно, т.к. станция использует кодек по умолчанию G723, плюс за счет включения мультикомпрессионности отрабатывает еще кодек G729. Но так как Cisco C40 использует G711 входящая связь с нее недоступна. Для исходящей связи была создана отдельная транк-группа с типом кодека G711.

Какие есть варианты в этом случае? Использовать префикс захвата это новой ТГ при звонке с Cisco C40 только?

Спасибо!

Коллеги, доброго времени суток!

В SlowStart все заработало. Проверил качество установления связи в этом режиме - ухудшений не заметил, поэтому решил оставить так. Кстати сказать, ожидал падения ABС линков с другими станциями, но этого не произошло. И я задумался, а чего это ради они должны были упасть - ведь, насколько я помню из теории, межстанционные линки используют X25 в инкапсуляцией Q931 (прошу прощения если все перепутал). Каким боком здесь должен использоваться H323?

В общем, спасибо Вам огромное!

Хорошо, коллеги. Попробую крутануть настройку на slowstart. Последний вопрос перед проверкой:
Требуется ли перезагрузка станции после этого? Или достаточно просто платы intip перезагрузить?

Спасибо!

Vad, не сомневаюсь в Вашей правоте, и аналогия с DNS понятна, но только в случае Direct режима.
Взгляните, к примеру, на статью
H323 Call with GK
В Routed режиме ГК выступает полноценным транзитным звеном в части сигнализации.
Т.е. уже получается не только DNS, но еще и прокси-сервер в придачу (естественно, что только в части сигналинга, RTP тут не причем).

To Error:
Я поэтому и спрашивал насчет какого-нибудь открытого решения типа Asterisk, у которого довольно гибкие настройки. Сомневаюсь, что он не поддерживает что-либо что работает на Cisco 28xx (проприетарщина типа SCCP и MGCP не в счет, все таки мы работаем со стандартным протоколом здесь).

to Error:
А можно поподробнее? Какие нюансы сигнализации не учтены и почему нужна именно циска 28-й серии? Вы имеете ввиду вместо имеющейся C40 или как транзитный узел - гк, который будет slow start в fast start и обратно транслировать?

Коллеги, спасибо! Буду разбираться с настройками 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 (на ГК или напрямую на вызываемого абонента). Правильно ли я понимаю, что абоненты получают информацию о режиме работы ГК в момент своей регистрации? Поэтому при изменении режима работы ГК требуется перерегистрация абонентов?

Спасибо!

Спасибо Username! Похоже причина действительно в этом. Пока правда не знаю как решить проблему. Возник следующий вопрос. Если внимательно посмотреть взаимодействие между клиентом Sony и Cisco C40, файл выложен мною ранее
Client_to_CiscoC40_ok
то можно заметить, что в конечном итоге клиент Sony (10.69.133.26) получает OpenLogicalChannelAck от гейткипера (10.69.133.57), т.е. гк является полноценным маршрутизатором всех сообщений. Действительно, в его настройках есть опция о режиме и сейчас установлен Routed mode for Q.931 and H.245.
Не правильней ли будет в качестве точки назначения в ячейке сокращенного набора указать адрес не CiscoC40, а адрес ГК? Правда, насколько я помню, пробовал и такой вариант, тоже безуспешно. Но все-таки?

Андрей, Вы абсолютно правы. Я тоже ранее обращал внимание на то что циска шлет список кодеков включая g711a. В веб-интерфейсе циски есть кнопка о состоянии текущего вызова, которая показывает текущие кодеки,vad, скорости потока и другое. Поначалу я заморочился на компандировании так как в момент полуустановившейся связи, то есть когда циска уже считает что связь установлена а на станции продолжаются кпв данная статистика показывала что циски использует g711u. При этом эта же статистика ничего не говорила о том какой кодекс использует станция. В редкие моменты успешной связи на стороне циски опять же показывался g711u а на стороне станции g711a при этом в трубке были слышны свисты и трески.

Я поэтому и надеялся, что устранив проблему этого не соответствия удастся полностью решить проблему. Но ошибся. Применив специальный фильтр на стороне циски мы запретили использование определённых кодеков. Теперь g711a используется с двух сторон, но ситуация с полуустановившимся соединением как была так и осталась.

Нужно ещё добавить, что звонки с циски на терминал Sony работают в обоих направлениях. Оба устройства динамически регистрируются на гк.

Error, что-то не вижу этого сообщения. Подскажите пожалуйста в каком месте дампов или трассировки вы его нашли?

Значит ли оно, что для циски важно знать звонящего абонента а она его не знает? Вообще странно, ведь на стороне гейткипера для перечня абонентов УАТС я создал статическую запись типа gateway с указанием ip адреса платы intip УАТС. Данная настройка успешно проверяется с аппаратного терминала sony и иногда даже с самой циски.

В обратную сторону звонки не ходят. Точнее сказать, имеет место странная ситуация. При звонке в циски плата intip стабильно уходит в перезагрузку. При проверке входящей связи с другого клиента гейткипера, аппаратного терминала Sony, связь устанавливается в обоих направлениях. Тут ещё нужно учесть, что циска пытается установить связь с использованием g711, который на станции включён только на выделенной транк-группе. Данная тг имеет локальную настройку на использование компрессии g711 и  используется только по исходящей связи через префикс захвата и сокращений набор. При входящей связи стыка с тг не происходит. Как пристыковать данную тг для некоторых входящих звонков, например, с определённых номеров, ума не приложу. В любом случае, перезагрузки платы происходить не должно.

На самом деле, звонки со стороны циски в сторону УАТС для нас не так важны. Предполагается что при звонках между абонентами УАТС должна быть возможность подключения аудио конференц-системы. В обратную сторону звонить не предполагается.

Секрета никакого нет. Буду очень признателен если присоединитесь к разбору pcap-файлов.
Ссылки:
Successful call
Unsuccessful call

Я также не уточнил, что в схеме имеется еще сторонний гейткипер от 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.
Дампы подобных взаимодействий также снял
PBX_to_Client
Client_to_CiscoC40

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

Никто и не спорит насчет важности этих пакетов. Просто по какой-то причине иногда пакеты не объединяются, но в большинстве случаев идет объединение двух пакетов в один. Может быть, это, конечно, стандартное поведение?
Мне известны такие ситуации только из области передачи данных - я уже упоминал про TCP Offload. Но видимо, здесь это что-то другое, так как с использованием ethtool на обеих сторонах (УАТС и Cisco C40 - обе Linux-based и имеют в своем составе данную утилиту) удалось выяснить, что TCP offload не используется.

Коллеги, если обнаружите что-то интересное, могущее являться причиной, дайте пожалуйста знать. Буду очень признателен.