Yate в режиме full proxy

[MSPIX]

Помогите пожалуйста разобраться, никак не выходит каменный цветок.

Собрал стенд по такой схеме

 

(Шлюз H.323) <--- 192.168.1.0/24 ---> (Yate2) <---> (internet) - SIP+H.323.

 

Постановка задачи такая - Шлюз находится во внутренней сети и имеет непосредственную связь только с сервером Yate2. На сервере 2 интерфейса - во внутреннюю сеть и в интернет с реальным адресом. Задача - сделать на Yate полное проксирование, включая медиа RTP трафик по схеме H.323 -> SIP и H.323 -> H.323, а также в обратную сторону (стрелкой указано направление от оригинатора к терминатору).

 

Чего удалось добиться:

1) H.323 -> SIP работает, подробно не разбирался.

2) H.323 -> H.323 - односторонняя слышимость. Звук от терминатора на оригинатора проходит, обратно - нет. По дампу видно, что хотя RTP трафик от оригинатора на Yate идет, но Yate его не проксирует, хотя второй канал по направлению от терминатора к оригинатору проксируется нормально.

3) H.323 <- H.323 (входящий на шлюз) - не происходит проксирования ни одного канала, трафик от оригинатора и терминатора к yate идет.

4) H.323 <- SIP - не проверялось

 

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

 

Оборудование:

шлюз - Addpac AP-200B (FXS)

Yate 2.0.0.p1 из портов на FreeBSD 7.2, openh323 1.19.0.1

На другой стороне коммерческие операторы IP телефонии.

 

Дебаг с yate есть, но один звонок - это порядка 300К, чтобы понять его смысл нужно хорошо понимать особенности H.323. При таком объеме даже просто вдумчивое чтение становится трудной задачей. Насколько я помню и понял, во втором случае между шлюзом и yate соединение происходит с faststart, между yate и провайдером - без него, причину я понять не могу. Хотя возможно я понял логи как-то не правильно. При этом сравнительно достоверно известно, что провайдер требует Faststart и туннелинг, без промежуточного звена в виде yate на внешнем адресе все работает нормально во все стороны.

 

Конфиги на базе дефолтных (комментарии сократил). Приведу некий средний вариант, т.к. перебрал уже все что можно.

 

accfile.conf:
[op1]
enabled=yes
protocol=h323
username=user|password
server=111.222.111.333
gkttl=60
port=1730

[op2]
protocol=sip
callername=User Name
username=555555
password=pppppp
registrar=222.333.111.222

h323chan.conf:
[general]
debug=4
forward_rtp=no

[ep]
faststart=yes
h245tunneling=yes
silencedetect=adaptive
gkclient=disable

[gk]
server=enable
interface1=192.168.1.2
port=1719
registeredonly=true

[incoming]
called=2001


regfile.conf:
[77777777777]
password=1234
callername=User Name

regexroute.conf:
[default]
;rtp_forward=yes
;${rtp_forward}possible=;rtp_forward=yes
^00\(.*\)$=sip/sip:0\1;line=op2;caller=username
^01\(.*\)$=h323/\1;line=op1

Остальные конфиги не изменялись.

 

На Addpac все очень страндартно. Faststart и туннелинг включены.

Помогите разобраться.

[Voicemaster]

Помогите пожалуйста разобраться, никак не выходит каменный цветок.

 

[...]

Повторить стенд не уверен что смогу быстро.

 

http://yate.null.ro/pmwiki/index.php?n=Main.RTPForwarding

http://yate.null.ro/pmwiki/index.php?n=Mai...SignallingProxy

 

 

Тут уже были ?

 

.

[MSPIX]

По первой ссылке небыл, там как я понял какие-то низкоуровневые вещи, больше для разработчиков и мало что прояснили.

По второй ссылке был, но там как я понял обсуждается проксирование сигнализации и кстати обсуждаемый там режим у меня работает нормально.

Дело в том, что мне не совсем ясно какой смысл вкладывается в эти переменные rtp_forward и passthrough. Проксирование RTP - это форвардинг или его отсутствие? Можно с разных сторон посмотреть. А passtrough_rtp из второй ссылки тогда что? Отсутствие транскодинга? Чем отличается rtp_forward от forward_rtp? И то и другое упоминается в конфигах. Ведь документации человеческой как таковой нет, все какие-то намеки на тему "догадайся сам". В результате каша в голове.

[Voicemaster]

По первой ссылке небыл, там как я понял какие-то низкоуровневые вещи, больше для разработчиков и мало что прояснили.

По второй ссылке был, но там как я понял обсуждается проксирование сигнализации и кстати обсуждаемый там режим у меня работает нормально.

Дело в том, что мне не совсем ясно какой смысл вкладывается в эти переменные rtp_forward и passthrough. Проксирование RTP - это форвардинг или его отсутствие? Можно с разных сторон посмотреть. А passtrough_rtp из второй ссылки тогда что? Отсутствие транскодинга? Чем отличается rtp_forward от forward_rtp? И то и другое упоминается в конфигах. Ведь документации человеческой как таковой нет, все какие-то намеки на тему "догадайся сам". В результате каша в голове.

"Программа термояд Yate прекрасно документирована на языке с++" - (с) ;-)

 

Вот тут есть некоторые объяснения Дианы

http://osdir.com/ml/telephony.yate/2006-12/msg00063.html

http://osdir.com/ml/telephony.yate/2005-09/msg00036.html

 

Я так понимаю, что в вашей схеме rtp_forward надо запрещать везде.

 

 

.

Edited August 21, 2009 by Voicemaster

[ram_scan]

Я так понимаю, что в вашей схеме rtp_forward надо запрещать везде.

Чтобы ята проксировала ртп нужно чтобы она умела кодек которым этот ртп заенкожен. Потому-что из документации написаной на c++ очевидно, что ртп проксирование делается в ней через транскодинг. Я к ей кодеки писал, и даже туто выкладывал.

 

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

[MSPIX]

Спасибо всем ответившим, немного позже попробую еще раз и отпишусь.

По поводу кодеков, если память не изменяет - я пробовал и вариант с G711, тоже не получилось, хотя возможно пробовал не во всех позах.

У меня была мысль собрать кодеки, где-то встречал исходники, кажется на yate.hosting.lv, но пока руки не дошли. Возможно у Вас, ram_scan, другие, не знаю, просто в теме еще не разбирался.

[MSPIX]

PS. Однако достоверно известно, что звонок по схеме 3 приходит именно в G.729 без вариантов и какую-то ругань в логах на тему G.729-G.711 G.711-G.729 я в логах при какой-то позе точно наблюдал.

[Voicemaster]

PS. Однако достоверно известно, что звонок по схеме 3 приходит именно в G.729 без вариантов и какую-то ругань в логах на тему G.729-G.711 G.711-G.729 я в логах при какой-то позе точно наблюдал.

 

Это таки всё объясняет (возможно). Yate может гонять через себя RTP только, если он их понимает и может транскодить или может им сделать passthrough (получающая сторона поймет).

Пожалуйста, доставьте кодеки - http://yate.hosting.lv/ , проверьте и расскажите о результате.

 

 

.

Edited August 21, 2009 by Voicemaster

[MSPIX]

Что-то собралось, даже без бубна. Это подозрительно.

Глупый вопрос, что делать с полученными бинарями? И как убедиться что они загрузились?

Ну по первому пункту я пальцем в небо положил их в /usr/local/lib/yate, а по второму не знаю

[MSPIX]

Сам спросил - сам отвечу.

Кроме этого нужно дописать строчки вида

g723.yate=true

g729.yate=true

в секцию [modules] в конфиге yate.conf

После этого в логах при загрузке yate появилось следующее:

Loaded module G.723.1 - based on Intel IPP

Loaded module G.729a - based on Intel IPP

----------

Поправочка, в конфиге по поводу модулей похоже можно ничего не прописывать.

Edited August 21, 2009 by MSPIX

[MSPIX]

В первом приближении ничего не изменилось.

После того как разрешил на шлюзе G.729 - ситуация стала как в п.3 первого поста, в логах такие строчки, в обеих случаях.

<yrtp:WARN> Initial timeout in channel h323/2 wrapper [0x2848f780]

<yrtp:WARN> Initial timeout in channel h323/1 wrapper [0x2848f600]

<yrtp:WARN> Initial timeout in channel h323/1 wrapper [0x2848f600]

<yrtp:WARN> Initial timeout in channel h323/1 wrapper [0x2848f600]

<yrtp:WARN> Initial timeout in channel h323/1 wrapper [0x2848f600]

 

Куда дальше копать?

[MSPIX]

И еще глупый вопрос, только заметил, в этих исходниках только G.729a? Мммм....

Тогда предлагаю пока оставить G.729 в покое, тестировать я буду в G.711, с ним точно проблем не должно быть. Остальные кодеки на Addpac я запретил, терминатор g711 поддерживает. Односторонняя слышимость.