asterisk.ru

amateur писал(а):may, Вас послушать, так в chan_ooh323 всё - не ошибка. В LG - да, причем "грубейшая"! А у нас всё хорошо, прекрасная маркиза!

Деза - "у нас всё хорошо" я не говорил.

amateur писал(а): Переключение на выделенный канал H.245 не работает - фигня, отключите туннелирование!

Деза - "фигня", я не говорил. Ни по сути не говорил, ни по духу. Ошибка понятна и признана.

amateur писал(а): Структура multiplexCapability не формируется, несмотря на то, что должна - фигня, никто ж не жалуется!

см. выше. Да и на многолетнем опыте работы, ни разу проблемы в multiplexCaps не было.

amateur писал(а): Происходит дезинформация удаленной стороны относительно поддерживаемых методов передачи DTMF - фигня, так многие делают! а мы чем хуже?

Деза в ваших словах. Анонсируемые методы поддерживаются.

amateur писал(а): В общем, легким движением инженер превращается... превращается инженер... в обычного торгаша. Свой продукт хвали, чужой - опускай. И кто-то еще сомневается, что рыночное бытие не отражается на сознании, и считает, что с этими вопросами повседневно не сталкивается.

У меня складывается ощущение, что в этой теме вы куда более подкованы, чем я. По крайней мере судя по количеству букв, написанных на эту тему.

amateur писал(а): Странно, что никто до сих пор не заметил, что я поторопился с вердиктом. Пока еще не доказано, что именно наличие Cisco RtpDtmfRelay в capabilityTable вызывает некорректное поведение LG. Ведь с исправлением dtmfmode исчезли и другие возможности (capabilities) из capabilityTable.

Но тем не менее, скорее всего в нем и дело. Остальные CAPS'ы довольно штатны и вряд ли LG о них не знает. А вот CiscoRTPDTMF действительно штука совершенно нештатная, я даже не уверен, что она сильно нужна в chan_ooh323)

Кстати, мне было бы интересно получить Ваши комменты по моему сообщению на тему chan_h323/chan_ooh323/H323Plus/Opal (ну я надеюсь понятно о каком сообщении речь идет)

amateur писал(а): illujanka, можете добавить в dtmfmode ключевое слово "cisco" (через запятую после h245signal). Ну и сделать проверочный вызов с записью трафика и h323_log?

Для начала вот такая штука в консоли )

Код: Выделить всё

WARNING[1477]: chan_ooh323.c:3036 reload_config: Unknown dtmf mode 'h245signal, cisco', using rfc2833

И 30 секунд...

h323_log.7z: (6.5 КБ) 359 скачиваний

h323.7z: (159.68 КБ) 345 скачиваний

Так, так... Ошибочка вышла. Параметр dtmfmode может принимать значение только одного метода передачи. Ну и Вы сами уже наверное поняли, что метод RFC 2833 LG не понимает. Осталось определить отношение LG к Cisco RtpDtmfRelay. Поэтому, попрошу Вас сделать последний (надеюсь) тест. Задать dtmfmode=cisco, ну и записать все, как всегда. Сделаете?

may писал(а):Деза - "у нас всё хорошо" я не говорил.

Зачем тогда так упорно советовать отключить туннелирование?

В отношении multiplexCapability Вы продолжаете гнуть свою линию: не важно как должно быть, главное, что никто не жаловался. Опять же возникает вопрос: "А Вы знаете ВСЕХ пытавшихся использовать chan_ooh323?".

Про DTMF я неточно выразился, т.к. тут есть одна неоднозначность. Да, все объявленные в TCS методы поддерживаются. Какой тогда метод передачи DTMF будет использоваться если метод, указанный в dtmfmode, не поддерживается удаленной стороной? Мне самому надоело в коде копаться.

may писал(а):Кстати, мне было бы интересно получить Ваши комменты по моему сообщению на тему chan_h323/chan_ooh323/H323Plus/Opal (ну я надеюсь понятно о каком сообщении речь идет)

may, я честное слово не знаю что там еще комментировать. Как я понял, история такова... Вы пытались использовать chan_h323, получили неудовлетворительный результат, причину которого не поняли. Вместо того, чтобы разобраться до конца, выдали сообществу еще один драйвер с минимальным уровнем поддержки H.323. Сейчас сам драйвер Вам интересен ровно настолько, насколько его сопровождение позволяет участвовать в коммерческих проектах. Степень интереса к его развитию можно увидеть по интенсивности появления в нем нового функционала. Вы отстаиваете chan_ooh323 с позиции его надежности, при этом игнорируете, что он использует библиотеку (OO H.323), в которой в 2016-м году уровень поддержки H.323 соответствует 2000-му году. При этом утверждаете, что она не мертвая. Да, возможно старые функции работают нормально (хотя последний пример скорее говорит об обратном), но не пора ли идти дальше?

Обобщая все вышесказанное, не похоже, что Вы собираетесь идти дальше.

Однако, если идти дальше, то возникают вопросы: "Куда и как?". На вопрос "Куда?" ответить достаточно просто: "В сторону расширения функционала?". На слуху две темы: NAT и видео. Разумеется направлений больше, но начать можно с этого. На вопрос: "Как?", в общем то, тоже ответ очевиден. Реализовывать все, что в H.323 накопилось за 16 лет в OO H.323, на мой взгляд, неразумно по двум причинам: 1) много работы; 2) рассеиваем усилия. Мне думается, что надо использовать наиболее функциональную библиотеку H.323. На текущий момент это H323Plus. Отмечу, что про H323Plus/PTLib у Вас устаревшая информация (2010) год, смешанная с негативными впечатлениями от OpenH323/PWlib. Там дело не стоит на месте, нужно свои данные освежить.

Ну так что Вы собираетесь дальше делать?

amateur писал(а):
may писал(а):Деза - "у нас всё хорошо" я не говорил.
Зачем тогда так упорно советовать отключить туннелирование?

Тогда это когда? так это сколько? Я помню про это упомянул два раза, как вариант обхода для решения проблемы. Это по Вашему "упорно"?
По-моему это вы пытаетесь упорно что-то доказать. Что именно я и хочу понять

amateur писал(а): В отношении multiplexCapability Вы продолжаете гнуть свою линию: не важно как должно быть, главное, что никто не жаловался. Опять же возникает вопрос: "А Вы знаете ВСЕХ пытавшихся использовать chan_ooh323?".

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

amateur писал(а): Про DTMF я неточно выразился, т.к. тут есть одна неоднозначность. Да, все объявленные в TCS методы поддерживаются. Какой тогда метод передачи DTMF будет использоваться если метод, указанный в dtmfmode, не поддерживается удаленной стороной? Мне самому надоело в коде копаться.

Выбирайте выражения, уважаемый. Вас никто не звал копаться в коде, Вы сами напросились.
Методы, объявленные со стороны asterisk в TCS - приемные. Для передачи будет использоваться явно выбранный.

amateur писал(а):
may писал(а):Кстати, мне было бы интересно получить Ваши комменты по моему сообщению на тему chan_h323/chan_ooh323/H323Plus/Opal (ну я надеюсь понятно о каком сообщении речь идет)
may, я честное слово не знаю что там еще комментировать. Как я понял, история такова... Вы пытались использовать chan_h323, получили неудовлетворительный результат, причину которого не поняли. Вместо того, чтобы разобраться до конца, выдали сообществу еще один драйвер с минимальным уровнем поддержки H.323. Сейчас сам драйвер Вам интересен ровно настолько, насколько его сопровождение позволяет участвовать в коммерческих проектах. Степень интереса к его развитию можно увидеть по интенсивности появления в нем нового функционала. Вы отстаиваете chan_ooh323 с позиции его надежности, при этом игнорируете, что он использует библиотеку (OO H.323), в которой в 2016-м году уровень поддержки H.323 соответствует 2000-му году. При этом утверждаете, что она не мертвая. Да, возможно старые функции работают нормально (хотя последний пример скорее говорит об обратном), но не пора ли идти дальше?

Обобщая все вышесказанное, не похоже, что Вы собираетесь идти дальше.

Однако, если идти дальше, то возникают вопросы: "Куда и как?". На вопрос "Куда?" ответить достаточно просто: "В сторону расширения функционала?". На слуху две темы: NAT и видео. Разумеется направлений больше, но начать можно с этого. На вопрос: "Как?", в общем то, тоже ответ очевиден. Реализовывать все, что в H.323 накопилось за 16 лет в OO H.323, на мой взгляд, неразумно по двум причинам: 1) много работы; 2) рассеиваем усилия. Мне думается, что надо использовать наиболее функциональную библиотеку H.323. На текущий момент это H323Plus. Отмечу, что про H323Plus/PTLib у Вас устаревшая информация (2010) год, смешанная с негативными впечатлениями от OpenH323/PWlib. Там дело не стоит на месте, нужно свои данные освежить.

Ну так что Вы собираетесь дальше делать?

Я собираюсь получить от Вас ответ - есть упомянутый мной memory leak в текущей реализации openh323/H323Plus или нет?
Если есть - Вы знаете как его устранить или нет?

В завимости от ответов на эти вопросы, я смогу для себя решить стоит заниматься openh323 или нет.
Ответ, я конечно, и сам могу получить. Но работа над h323 в астериске у меня, понимаете ли, не единственное и не самое большое в жизни счастье, поэтому,
я полагаю, что Вы как более активно работающий в этой области (openh323) специалист, ответите на этот вопрос быстрее.

may, я наверное слишком много букв пишу?

Да, два раза советовать идти в обход вместо ноля раз - это по-моему упорно. Если бы Вы были каким-нибудь интегратором, то такой ответ был бы понятен. Во-первых, им главное продать, а во-вторых, интеграторы редко разбираются во внутренних механизмах продукта. Но от разработчика такое слышать по меньшей мере странно. Что тут непонятного?
Про muxCap перечитайте тему. Два раза апелляция к тому, что "никто не жаловался" и ноль раз утверждение "буду исправлять". Это видимо указывает на то как Вам важно сделать данное исправление? Ну а если это НЕ указывает на то, что это важно, то указывает на то, что НЕ важно.
На мой вопрос о DTMF Вы так и не ответили. Я спрашивал какой метод будет использоваться, если то, что указано в dtmfmode не поддерживается удаленной стороной. Чем конкретно этот параметр управляет?
И что Вас так обидело? Слово "копаться"? Это весьма странно, т.к. я его употребил относительно себя. Вам то какая разница?

may писал(а):Я собираюсь получить от Вас ответ - есть упомянутый мной memory leak в текущей реализации openh323/H323Plus или нет?
Если есть - Вы знаете как его устранить или нет?

Вы понимаете, что этот вопрос некорректен. Существование "memory leak" в OpenH323/H323Plus утверждаете Вы, но доказательств нет, а обосновать его отсутствие должен я. Может сначала докажете, что он существует?

may писал(а):Но работа над h323 в астериске у меня, понимаете ли, не единственное и не самое большое в жизни счастье, поэтому, я полагаю, что Вы как более активно работающий в этой области (openh323) специалист, ответите на этот вопрос быстрее.

Раз эту работу не бросаете, значит не большое, но счастье. Может уже хватит лукавить? Если бы Вас интересовал ответ, то задали бы его давно разработчикам OpenH323/H323Plus. Задавали?

asterisk.ru

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

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

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

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

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

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

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