SUrov_IBM Опубликовано 17 августа, 2021 (изменено) · Жалоба Уважаемые гуру, здравствуйте! Существует следующая схема [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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexgreat Опубликовано 18 августа, 2021 · Жалоба Смутно помнится про voice service voip h323 bearer-capability speech Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 18 августа, 2021 · Жалоба 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, чтобы полноценно решить мою задачку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 18 августа, 2021 · Жалоба Снял трассировку и она только подтвердила мои предположения, более ранний 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 или более поздней ревизией. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 22 августа, 2021 · Жалоба Оставлю заметку сам для себя. Если честно, такой ерунды я не видел. Выяснилось случайно - для более подробного понимания, что происходит на Cisco в момент вызова при использовании IOS c2800nm-adventerprisek9-mz.151-3.T.bin, включил максимальную отладку (debug) H.323 - "debug cch323 all". Вызов при этом успешно прошёл! Выключаю отладку, вызов перестаёт проходить. Да уж…, создаётся ощущение, что когда включен debug, то стартует и какая-то внутренняя служба IOS, которая при штатной конфигурации не активна. Чудеса! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 24 августа, 2021 · Жалоба К сожалению, у меня так и не полилось реализовать конвертор «малой кровью», используя 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. Всё вышеописанное, просто мысли, заметки для самого себя. Поскольку я не профессиональный телефонист и на правильность суждений не претендую. А так, схема работает, есть вроде не просит и железка ещё службу послужит. ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
naves Опубликовано 24 августа, 2021 · Жалоба Глупый вопрос, а не проще ли было поднять asterisk на любом утюге? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 24 августа, 2021 · Жалоба 37 минут назад, naves сказал: не проще ли было поднять asterisk на любом утюге? Naves, здравствуйте. Наверное проще, просто совершенно не хотелось привязываться к какому либо «тазику» в виде ПК, у которого HDD/SSD не резервируется, не ставить же RAID под это дело (тазик ещё нужно обслуживать хоть иногда, правда вентиляторы Cisco тоже этого требуют, но реже) или к какому-то микро контроллеру («утюгу»), который я честно не умею готовить и куда его ещё потом запихать и подключить по питанию. Можно было и в качестве VM на действующем кластере реализовать, но там тоже есть нюансы, скорей у кластера "СХД ляжет" или "VM потеряют куда-то", чем у Cisco стоящей в стойке под АТС и подключённой к тому же БИП что-то случиться. Но это только моё мнение, на истину не претендую. IT специалистам наверное проще было бы на VM реализовать, Кулибиным на Raspberry Pi, мне вот такой вариант показался самым простым в данном случае. ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...