MSPIX Опубликовано 20 августа, 2009 · Жалоба Помогите пожалуйста разобраться, никак не выходит каменный цветок. Собрал стенд по такой схеме (Шлюз 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 и туннелинг включены. Помогите разобраться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Voicemaster Опубликовано 20 августа, 2009 · Жалоба Помогите пожалуйста разобраться, никак не выходит каменный цветок. [...] Повторить стенд не уверен что смогу быстро. http://yate.null.ro/pmwiki/index.php?n=Main.RTPForwarding http://yate.null.ro/pmwiki/index.php?n=Mai...SignallingProxy Тут уже были ? . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MSPIX Опубликовано 21 августа, 2009 · Жалоба По первой ссылке небыл, там как я понял какие-то низкоуровневые вещи, больше для разработчиков и мало что прояснили. По второй ссылке был, но там как я понял обсуждается проксирование сигнализации и кстати обсуждаемый там режим у меня работает нормально. Дело в том, что мне не совсем ясно какой смысл вкладывается в эти переменные rtp_forward и passthrough. Проксирование RTP - это форвардинг или его отсутствие? Можно с разных сторон посмотреть. А passtrough_rtp из второй ссылки тогда что? Отсутствие транскодинга? Чем отличается rtp_forward от forward_rtp? И то и другое упоминается в конфигах. Ведь документации человеческой как таковой нет, все какие-то намеки на тему "догадайся сам". В результате каша в голове. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Voicemaster Опубликовано 21 августа, 2009 (изменено) · Жалоба По первой ссылке небыл, там как я понял какие-то низкоуровневые вещи, больше для разработчиков и мало что прояснили.По второй ссылке был, но там как я понял обсуждается проксирование сигнализации и кстати обсуждаемый там режим у меня работает нормально. Дело в том, что мне не совсем ясно какой смысл вкладывается в эти переменные 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 надо запрещать везде. . Изменено 21 августа, 2009 пользователем Voicemaster Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ram_scan Опубликовано 21 августа, 2009 · Жалоба Я так понимаю, что в вашей схеме rtp_forward надо запрещать везде. Чтобы ята проксировала ртп нужно чтобы она умела кодек которым этот ртп заенкожен. Потому-что из документации написаной на c++ очевидно, что ртп проксирование делается в ней через транскодинг. Я к ей кодеки писал, и даже туто выкладывал. Стенд сразбегу тоже не соберу. Могу тока сказать что в принципе все взлетать должно. Может быть плюха связаная с фаст-слоустартом, но надо разбираться предметно по логам где именно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MSPIX Опубликовано 21 августа, 2009 · Жалоба Спасибо всем ответившим, немного позже попробую еще раз и отпишусь. По поводу кодеков, если память не изменяет - я пробовал и вариант с G711, тоже не получилось, хотя возможно пробовал не во всех позах. У меня была мысль собрать кодеки, где-то встречал исходники, кажется на yate.hosting.lv, но пока руки не дошли. Возможно у Вас, ram_scan, другие, не знаю, просто в теме еще не разбирался. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MSPIX Опубликовано 21 августа, 2009 · Жалоба PS. Однако достоверно известно, что звонок по схеме 3 приходит именно в G.729 без вариантов и какую-то ругань в логах на тему G.729-G.711 G.711-G.729 я в логах при какой-то позе точно наблюдал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Voicemaster Опубликовано 21 августа, 2009 (изменено) · Жалоба PS. Однако достоверно известно, что звонок по схеме 3 приходит именно в G.729 без вариантов и какую-то ругань в логах на тему G.729-G.711 G.711-G.729 я в логах при какой-то позе точно наблюдал. Это таки всё объясняет (возможно). Yate может гонять через себя RTP только, если он их понимает и может транскодить или может им сделать passthrough (получающая сторона поймет). Пожалуйста, доставьте кодеки - http://yate.hosting.lv/ , проверьте и расскажите о результате. . Изменено 21 августа, 2009 пользователем Voicemaster Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MSPIX Опубликовано 21 августа, 2009 · Жалоба Что-то собралось, даже без бубна. Это подозрительно. Глупый вопрос, что делать с полученными бинарями? И как убедиться что они загрузились? Ну по первому пункту я пальцем в небо положил их в /usr/local/lib/yate, а по второму не знаю Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MSPIX Опубликовано 21 августа, 2009 (изменено) · Жалоба Сам спросил - сам отвечу. Кроме этого нужно дописать строчки вида 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 ---------- Поправочка, в конфиге по поводу модулей похоже можно ничего не прописывать. Изменено 21 августа, 2009 пользователем MSPIX Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MSPIX Опубликовано 21 августа, 2009 · Жалоба В первом приближении ничего не изменилось. После того как разрешил на шлюзе 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] Куда дальше копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MSPIX Опубликовано 21 августа, 2009 · Жалоба И еще глупый вопрос, только заметил, в этих исходниках только G.729a? Мммм.... Тогда предлагаю пока оставить G.729 в покое, тестировать я буду в G.711, с ним точно проблем не должно быть. Остальные кодеки на Addpac я запретил, терминатор g711 поддерживает. Односторонняя слышимость. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...