подключение chan_h323 к Asterisk 13

[vlego]

Метод передачи DTMF согласно RFC 2833 поддерживается H.323-устройствами КРАЙНЕ РЕДКО!

Ну да... в avaya например... - редкая вещь !
Надо сказать - по другому dtmf у меня не ходит на станции от * через H323

[amateur]

Метод передачи DTMF согласно RFC 2833 поддерживается H.323-устройствами КРАЙНЕ РЕДКО!

Ну да... в avaya например... - редкая вещь !

В Avaya Communication Manager этот метод поддерживается с ошибкой: по факту он работает (причем только с PayloadType=127), но удаленной стороне об этом не сообщается (в TCS он никогда не перечислен). Поэтому, противоположная сторона, если она руководствуется содержанием TCS, никогда его использовать не будет. Это фактически то же самое, что "не работает".

[illujanka]

Вот наглядный результат отсутствия трудолюбия - слияние в экстазе директив для chan_ooh323 с директивами для chan_h323.

А при чем тут мое трудолюбие? Я просто привела вам то что есть на рабочей *, которую настраивала не я. Проконсультироваться с тем кто это делал, я по техническим причинам не могу.
То что было приведено для ooh323 - чисто моя самостоятельная работа.

Но суть проблемы не в этом. Вызов разрывается chan_ooh323 по причине отсутствия ответа от LG на сообщение TerminalCapabilitySet (TCS) в течение 30 секунд. Я сейчас просматриваю код chan_ooh323 на предмет причины отправки TCS, несмотря на то, что вызов уже установлен с использованием Fast Connect.

Точно, именно на это и жаловались все "счастливые" пользователи этой АТС. Древняя реализация 323 просто не реагирует на TCS.
Как выход предлагалось или ставить более простой chan_h323 или гейткипером отлавливать TCS (и что с ним там делать я не поняла )

[amateur]

Надо сказать - по другому dtmf у меня не ходит на станции от * через H323

Если у Вас оригинальный chan_h323, то НЕ ВЕРЮ. Если модифицированный, то ВЕРЮ

[vlego]

Вот наглядный результат отсутствия трудолюбия - слияние в экстазе директив для chan_ooh323 с директивами для chan_h323.

Совершенно верно... и внимательности. Это человеческое свойство - завести тему про самосборку h323, иметь ooh323 на старой станции,.... - а не покажет конфиг - не догадаешься никогда что происходит.

[amateur]

А при чем тут мое трудолюбие? Я просто привела вам то что есть на рабочей *, которую настраивала не я.

Такая конфигурация просто не могла работать с chan_h323. Вы что-то путаете.

Точно, именно на это и жаловались все "счастливые" пользователи этой АТС. Древняя реализация 323 просто не реагирует на TCS.
Как выход предлагалось или ставить более простой chan_h323
Говорите "более простой". Я бы так не сказал.

или гейткипером отлавливать TCS (и что с ним там делать я не поняла )

Вообще, Вам необходима адаптация канального драйвера под кривизну реализации H.323 на LG.
Тут надо понять две вещи:
1) LG вообще не отвечает на TCS или отвечает в другом режиме (например, в режиме без Fast Connect и туннелирования);
2) зачем chan_ooh323 отправляет TCS, когда вызов уже установлен с использованием Fast Connect.

Вопрос 1) решается записью трафика успешного вызова между Asterisk + chan_h323(!!!) и LG. Вопрос 2) решается просмотром кода, чем я сейчас и занимаюсь. Если Вы пока выполните пункт 1), будет круто

[illujanka]

Вот наглядный результат отсутствия трудолюбия - слияние в экстазе директив для chan_ooh323 с директивами для chan_h323.

Совершенно верно... и внимательности. Это человеческое свойство - завести тему про самосборку h323, иметь ooh323 на старой станции,.... - а не покажет конфиг - не догадаешься никогда что происходит.

Вот ничегошеньки не понятно. Отчего вы решили, что тема про самосборку h323? Собирается он у меня неплохо, по его сборке я вопросов почти не имею. Почему вы считаете, что на старой станции ooh323, если там h323.conf, а не ooh323.conf?

[vlego]

Надо сказать - по другому dtmf у меня не ходит на станции от * через H323

Если у Вас оригинальный chan_h323, то НЕ ВЕРЮ. Если модифицированный, то ВЕРЮ

Что есть оригинальный - не совсем понимаю... взят здесь с форума. Старая инструкция, с учетом более поздних версий *ка для сборки,(пришлось) была несколько дополнена - уже и не припомню какие строки добавил - вот кусочек... не жалко смотрите
# yum install make gcc-c++ kernel-devel openssl-devel expat-devel gnutls-devel flex -y
# yum install ncurses-devel ncurses
# yum install mysql-devel
# yum install sqlite
# yum install sqlite-devel
# yum install libxml2-devel

собственно и так ясно, когда собираешь, - все пишется. Не знаю, какие чудеса люди ищут...
Работает более 3 лет.. непрерывно и с нагрузкой в разных вариантах. Одно скажу - контекст в пире не влияет на жизнь, только в секции global ставлю.

[amateur]

Что есть оригинальный - не совсем понимаю... взят здесь с форума.

Здесь ссылка на оригинальный. Дело в том, что в оригинальном передача DTMF согласно RFC 2833 возможна только если удаленная сторона явно сообщит о поддержке этого метода в своем TCS. Avaya Communication Manager этого не делает. Соответственно, у меня есть все основания сомневаться, что у Вас работает именно RFC 2833, а не H.245 UserInputIndication.

[vlego]

Avaya Communication Manager этого не делает

RFC 2833 is used for DTMF transmission. This is the same as configured for Avaya
Communication Manager in
Section 3.4
....
Если Вам интересна avaya - изучайте есть документация. То что работало с ошибкой, давно исправили.... Как впрочем и SIP стал работать прилично с другим оборудованием.

А вообще здесь (в этой теме)- другая проблема !