Linksys PAP2 Ранние КПВ

[wans]

Привет всем.

Есть схема.

 

PAP2 -(sip)-> Asterisk -(sip)-> cisco 5350-(PRI)->СТОП

 

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

По дебагу на 53 цыски, а также дебагу PAP2 видно что приходит сигннал Connect в этот момент он и начинает отдавать в телефон КПВ, но после connect приходит дисконект с кодом завершения- user bisy. и в трубки телефона слышны гудки занято.

 

Такая ситуация меня не устраивает но пока не знаю где что покрутить чтобы это изменить.

Недолжен он после сигналла Connect отдавать КПВ.

 

Если кто решил данную проблему поделитесь как.

Edited October 30, 2006 by wans

[ram_scan]

Это на большинстве (если не на всех) SIP железяк такие грабли из-за принципиального отсутствия в протоколе вменяемой сигнализации совпадающей с q931. Кардинально должно помочь включение тотальное inband ringback, чтобы КПВ генерировала цыска или или сам called party, а через pap2 его просто было бы слышно транзитом, но я не помню включается ли оно на pap2, потому-что для его работы необходимо early rtp channel.

 

Подозреваю, что следующей проблемой будет КПВ или busy вместо железной леди "абонент временно недоступен" при звонках на мобильных операторов...

Edited October 30, 2006 by ram_scan

[wans]

пока не нашел не чего похожего в нем.

Не думал что наступлю на такие грабли.

что самое печальное, так то что софт фоны нормально справляютья с этой задачей.

[wans]

НЕ ужели не кто не сталкивался с такми проблемами в Линксисе ?

[Андрей]

НЕ ужели не кто не сталкивался с такми проблемами в Линксисе ?

Если вас это успокоит, то такая проблема на большинстве SIP-железках.

Пробовали от Вигор-Талка до 32-портового Натекса. Везде одно и тоже.

Мало того, нас забодада проблема отсутствия КПВ при звонках на старые АТС.

 

 

P.S. Может Рам-Скан что скажет?

[ram_scan]

Проще забить. Типа "фича". На линксисе (и ваще я подозреваю везде) кстати есть проблема не только озвученая топикстартером, но и косяк в виде отсутствия КПВ в гетерогенной VoIP сети, особанно работающей разными протоколами сигнализации. В такой сети часть железок расчитывает на то, что КПВ даст ремотная сторона, а часть КПВ сама пользователю генерит не обращая внимания на то что происходит на дальнем конце, а там возможно уже давно голос идет.

 

Адекватно проблема решена (то есть ее вообще в рамках h245/q931 by design не существует) только при работе по H323 (ну и еще mgcp/megaco, там просто логика работы совершенно другая), там существует механизм прогрессинга и алертинга сигнализирующими об этапе установления соединения, с помощью которых можно проключить по всему транзиту голосовой канал еще до факта установления соединения с called patry, чтобы на стороне callee patry слышать все что нужно, начиная от КПВ до голосовых респонзов от транзита вроде "на данном направлении перегрузка". Принято в телефонии классической все сигналы которые пользователь должен слушать слышать с дальней стороны, за исключением особых случаев. И все войпные косяки за исключением тяжелых случаев обычно связаны с тем, что некоторые железяки отправляют прогресс без алерта или сетапа, или бывает так что ремотной стороной не отправляется какой-то прогресс индикатор вообще (Андрей, это твоя проблема как раз, она еще наблюдается часто при работе с безбашенными ISDN BRI ендпоинтами, твой ТСОП шлюз не получает от дальней стороны прогресса с алертом сигнализирующим о том, что канал скоммутирован и по нему уже пошли inband данные в виде КПВ, а на VoIP rtp канал у тебя до ответа вызываемой стороны без этого не проключается). Но это грабли хоженые и это лечится принудительной вставкой на транзите или стыке с ТСОП нужного прогресса или алерта в существующий прогресс если он пришел пустой.

 

SIP изначально p2p ориентированый протокол, поэтому он работает несколько бестолково, раз есть connect значит пошел звонок на ремотной стороне и надо КПВ давать. Причем давать локально, чтобы трафик значица сэкономить, что гудки по сети гонять, да ими полосу занимать, она не резиновая же. А connect этот может быть и на транзите, и не на одном, покуда звонок по маршруту доберется до места, а там ему возможно еще и отлуп дадут, да еще и cause code не прилепят, хрен выяснишь по какой причине отлуп со стороны ТСОП случился, нету в SIP этой человечески реализованой радости. Поэтому чинится это только с помощью костылика в виде включения early rtp и inband ringback для отдачи КПВ в обратную сторону, но если где-то на транзите оно окажется выключеным, то можно лишиться КПВ вовсе (транзит считает что его генерит called patry и сам молчит, иначе можно услышать два КПВ от двух транзитов одновременно) и не все железки это умеют. А некоторые умеют, но некорректно (например аддпаки с 8.237 прошивкой). В конечном итоге с помощью подобного костыля можно решить проблему в одном месте, и огрести ее в другом, в виде полного отсутствия КПВ из-за непоняток кто и на каком направлении кому этот КПВ должен давать =(

 

Я не помню, имеет ли подобную фичу линксис, я когда брал его на тест особенно с этими вещами не заморачивался, не успел, уволил я его по причине низкого вызывного напряжения, из-за чего не все телефонные аппараты (например siemens euroset 2015) не дают дают звонка без бубна. Надо в настройках линксиса править форму вызывного напряжения и указывать несуществующую емкость линии, чтобы "пробивало". И не факт что другие девайсы подобные изыскания "рюхнут", потому-что у клиентов какого-тока говна не стоит.

Edited October 31, 2006 by ram_scan

[wans]

Спасибо за подробное объеснение.

То что Линксис проглючает RTP до метода connected это точно.

Другое дело пока не разодрался как отключить чтобы она генерировала эти сегналы

[wans]

Сегодня нашел ХАБ(оказываеться не так то просто найти его в наше время) и Воспользывался VoIP анализатором Hammer Call Analyzer учень удобная штука.

Так вот что мне удалось выяснить когда звонок идет по такой схеме

PAP2 -(sip)-> Asterisk -(sip)-> cisco 5350-(PRI)->СТОП

RTP проключается до метода connected и КПВ и сегнал зането идет именно с медиа потока а не генериться PAP2.

Кому интересно выкладываю трасировки звонка и звуковой файл что идет по медиапотоку в момент вызова.

 

Теперь возник вопрос Кто раньше времени генерит КПВ если абонент занят Asterisk или AS5350

 

На схеме

192.168.110.85 - PAP2

192.168.110.50 - Asterisk

 

Может что

ram_scan подскажет?

call.wav

Edited November 2, 2006 by wans

[ram_scan]

Я в полной растеряности. Склонен подозревать странную логику в работе cisco. Причем на слух я бы оценил сигнал не как КПВ+busy а как dialtone+busy.

[wans]

Я в полной растеряности. Склонен подозревать странную логику в работе cisco. Причем на слух я бы оценил сигнал не как КПВ+busy а как dialtone+busy.

Я тоже, сейчас RTP поток проксируеться через Asterisk хочу сделать чтобы он шел напримую между циской и РАР2 и посмотреть что будет.

[ram_scan]

Еще на диалплан надо взглянуть. Хотя если там модификатора 'r' в Dial application не указано, то никаких тональных сигналов * генерить не должна. Ну и трейс снять неплохо на связке asterisk-cisco.

[wans]

Еще на диалплан надо взглянуть. Хотя если там модификатора 'r' в Dial application не указано, то никаких тональных сигналов * генерить не должна. Ну и трейс снять неплохо на связке asterisk-cisco.

А про слона то я и забыл действительно дело было в модификаторе r. Убрав его все стало работать как часики и на город и на сотки и слышно железную леди.

Всем спасибо.

Особенно огромная благодарность ram_scan.