Перейти к содержимому
Калькуляторы

MSPIX

Пользователи
  • Публикации

    8
  • Зарегистрирован

  • Посещение

Все публикации пользователя MSPIX


  1. И еще глупый вопрос, только заметил, в этих исходниках только G.729a? Мммм.... Тогда предлагаю пока оставить G.729 в покое, тестировать я буду в G.711, с ним точно проблем не должно быть. Остальные кодеки на Addpac я запретил, терминатор g711 поддерживает. Односторонняя слышимость.
  2. В первом приближении ничего не изменилось. После того как разрешил на шлюзе 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] Куда дальше копать?
  3. Сам спросил - сам отвечу. Кроме этого нужно дописать строчки вида 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 ---------- Поправочка, в конфиге по поводу модулей похоже можно ничего не прописывать.
  4. Что-то собралось, даже без бубна. Это подозрительно. Глупый вопрос, что делать с полученными бинарями? И как убедиться что они загрузились? Ну по первому пункту я пальцем в небо положил их в /usr/local/lib/yate, а по второму не знаю
  5. PS. Однако достоверно известно, что звонок по схеме 3 приходит именно в G.729 без вариантов и какую-то ругань в логах на тему G.729-G.711 G.711-G.729 я в логах при какой-то позе точно наблюдал.
  6. Спасибо всем ответившим, немного позже попробую еще раз и отпишусь. По поводу кодеков, если память не изменяет - я пробовал и вариант с G711, тоже не получилось, хотя возможно пробовал не во всех позах. У меня была мысль собрать кодеки, где-то встречал исходники, кажется на yate.hosting.lv, но пока руки не дошли. Возможно у Вас, ram_scan, другие, не знаю, просто в теме еще не разбирался.
  7. По первой ссылке небыл, там как я понял какие-то низкоуровневые вещи, больше для разработчиков и мало что прояснили. По второй ссылке был, но там как я понял обсуждается проксирование сигнализации и кстати обсуждаемый там режим у меня работает нормально. Дело в том, что мне не совсем ясно какой смысл вкладывается в эти переменные rtp_forward и passthrough. Проксирование RTP - это форвардинг или его отсутствие? Можно с разных сторон посмотреть. А passtrough_rtp из второй ссылки тогда что? Отсутствие транскодинга? Чем отличается rtp_forward от forward_rtp? И то и другое упоминается в конфигах. Ведь документации человеческой как таковой нет, все какие-то намеки на тему "догадайся сам". В результате каша в голове.
  8. Помогите пожалуйста разобраться, никак не выходит каменный цветок. Собрал стенд по такой схеме (Шлюз 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 и туннелинг включены. Помогите разобраться.