[SUrov_IBM]

Уважаемые гуру, здравствуйте!

 

Существует следующая схема [SIP UA]<=SIP=>[CISCO 28xx]<=H.323=>[АТС KX-NS1000]

CISCO 2800 выступает в роли конвертора сигнализации SIP<=>H.323.

 

При вызове с KX-NS1000 (сторона «А» (H.323)) в направлении SIP (сторона «Б» (SIP)), соединение устанавливается, проходит RTP и через 12-15 сек. разрывается на плече H.323.

К сожалению, я не разбираюсь в тонкостях сигнализации H.323, смог только понять, что АТС посылает в H.245 запрос TCS (terminal capability set), на который не получив ответа, разрывает соединение.

 

Столкнулся с упоминанием, что на CUCM включают поддержку «Wait for Far End H.245 Terminal Capability Set», но в моём случае CISCO не является частью CUCM и как настроить подобный параметр в конфигурации, пока не осознал.

 

H.245 тоннель включен, режим «Fast Start» установлен по умолчанию. Конфигурация со стороны CISCO максимально простая.

Если вместо АТС использовать другую H.323 железку, вызов проходит нормально. Но я уверен, виновник этого CISCO и мои кривые лапки, поскольку не понимаю, как заставить её корректно ответить на запрос TCS.

 

Буду благодарен за Ваши мысли!

Изменено 18 августа, 2021 пользователем SUrov_IBM

[alexgreat]

Смутно помнится про

voice service voip

h323

bearer-capability speech

 

[SUrov_IBM]

16 часов назад, alexgreat сказал:

bearer-capability speech

Alexgreat, здравствуйте.

 

Спасибо, что откликнулись. Насколько я понимаю Bearer capability относится к ISDN, у меня в данной схеме VoIP с RTP.

 

Хм…, как я и предполагал, проблема скрывалась в CISCO, а не в АТС!

К АТС у меня в принципе доступа нет, да и страшно подходить, ибо я не телефонист, а специалистов, с кем можно посоветоваться у нас не имеется.

 

Вместо CISCO 28xx серии, в качестве конвертора SIP<=>H.323 я установил CISCO 1760 (IOS c1700-ipvoicek9-mz.124-15.T9.bin), вызов успешно прошёл.

 

На CISCO 28xx был установлен IOS c2800nm-adventerprisek9-mz.151-3.T.bin, я загрузил более раннюю версию c2800nm-entservicesk9-mz.124-3b.bin и вызов корректно прошёл. При этом конфигурационный файл не менялся.

К сожалению, в данный момент не возможности снять трассировку, чтобы сравнить, что изменилось в состоянии соединения. Но это не первый раз, когда с IOS возникают такие непонятности.

 

После снятия трассировки, постараюсь понять, что можно ещё попробовать подкрутить в IOS 15, чтобы полноценно решить мою задачку.

[SUrov_IBM]

Снял трассировку и она только подтвердила мои предположения, более ранний CISCO IOS c2800nm-entservicesk9-mz.124-3b.bin посылает ответ на H.245 запрос TCS (terminal capability set) в сторону АТС.

При получении TCS происходит корректное согласование и вызов успешно проходит.

 

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

Дальше буду думать, где можно посоветоваться со специалистами по Cisco Voice, чтобы иметь возможность использовать данную схему с IOS c2800nm-adventerprisek9-mz.151-3.T.bin или более поздней ревизией.

[SUrov_IBM]

Оставлю заметку сам для себя.

 

Если честно, такой ерунды я не видел. Выяснилось случайно - для более подробного понимания, что происходит на Cisco в момент вызова при использовании IOS c2800nm-adventerprisek9-mz.151-3.T.bin, включил максимальную отладку (debug) H.323 - "debug cch323 all". Вызов при этом успешно прошёл! Выключаю отладку, вызов перестаёт проходить. Да уж…, создаётся ощущение, что когда включен debug, то стартует и какая-то внутренняя служба IOS, которая при штатной конфигурации не активна. Чудеса!

[SUrov_IBM]

К сожалению, у меня так и не полилось реализовать конвертор «малой кровью», используя IOS c2800nm-adventerprisek9-mz.151-3.T.bin. Пришлось собрать альтернативную схему за счёт «TDM петли», добавив в CISCO2811 потоковую палату VWIC2-2MFT и PVDM процессор. Если H.323 вызов терминировать на pots, проблему с TCS получается обойти.

 

Конечно, можно было использовать IOS c2800nm-entservicesk9-mz.124-3b.bin, без поддержки Toll Fraud, соорудив ACL и успокоиться на этом. Правда, в процессе выяснилась неприятная особенность – при прохождении вызова через конвертор, в голосовом канале появлялись искажения в виде щелчков (на всей длине вызова, одинаковый кодек G711 A-Law), скорей всего это вызвано задержками IP/RTP со стороны плеча SIP. Хотя, например аналогичный SIP-SIP вызов проходит без явных искажений. При прохождении вызова через «TDM петлю», искажения так же практически отсутствуют. Вот такой вот IP-IP Media Proxy...

 

Понимаю, что костылить такого монстрика под такую простую задачку – это удорожание схемы, усложнение конфигурации и понижение отказоустойчивости. Хотя сейчас TDM железки уже почти никому ни нужны и просто валяются без дела. Можно было попробовать отказаться хотя бы от «TDM петли» VWIC2-2MFT и настроить перекодирование G711 A-Law to G711 A-Law через PVDM, но я не был уверен, что не столкнусь с той же проблемой, что и в начале. Так же, как и не хотелось перебирать ещё с десяток IOS, в надежде решить накопившейся ряд проблем. Проше тогда уже было  выкинуть CISCO и настроить конвертор на том же Yate.

 

P.S. Всё вышеописанное, просто мысли, заметки для самого себя. Поскольку я не профессиональный телефонист и на правильность суждений не претендую. А так, схема работает, есть вроде не просит и железка ещё службу послужит. ;)

[naves]

Глупый вопрос, а не проще ли было поднять asterisk на любом утюге?

[SUrov_IBM]

37 минут назад, naves сказал:

не проще ли было поднять asterisk на любом утюге?

Naves, здравствуйте.

 

Наверное проще, просто совершенно не хотелось привязываться к какому либо «тазику» в виде ПК, у которого HDD/SSD не резервируется, не ставить же RAID под это дело (тазик ещё нужно обслуживать хоть иногда, правда вентиляторы Cisco тоже этого требуют, но реже) или к какому-то микро контроллеру («утюгу»), который я честно не умею готовить и куда его ещё потом запихать и подключить по питанию. Можно было и в качестве VM на действующем кластере реализовать, но там тоже есть нюансы, скорей у кластера "СХД ляжет" или "VM потеряют куда-то", чем у Cisco стоящей в стойке под АТС и подключённой к тому же БИП что-то случиться. Но это только моё мнение, на истину не претендую. IT специалистам наверное проще было бы на VM реализовать, Кулибиным на Raspberry Pi, мне вот такой вариант показался самым простым в данном случае. ;)