amateur писал(а):may писал(а):Не моя тема, я от этого далек, поскольку инженер, а не маркетолог.
may писал(а):Я повторюсь, в рыночных принципах разбираюсь слабовато. не то образование
Такая индифферентность к вопросам, с которыми Вы сталкиваетесь повседневно, несколько удивляет.
Ну в буквальном смысле с решением подобных вопросов я точно каждый день не сталкиваюсь
amateur писал(а):
may писал(а):Всё это тоже неинтересно. Я не участвовал никогда ни в доказательствах сложности H.323, ни в доказательствах обратного.
Можно поинтересоваться зачем Вы сопровождаете chan_ooh323? Если за это платят, то всё понятно. Но, насколько я понимаю, это не так.
Причин две.
Первая - историческая, получилось так, что я chan_ooh323 довел до нормального состояния, логично было заняться дальнейшим сопровождением.
Вторая - мне это было интересно, как для профессионального роста, так и для решения вполне коммерческих задач моей тогдашней деятельности.
Платят или нет - вопрос неоднозначный. Digium конечно за поддержку не платит. Но часто я занимаюсь решением проблем с h.323 и внутри вполне
коммерческих проектов.
amateur писал(а):
Если есть интерес к развитию технологии H.323, то тогда тоже понятно, но возникает два вопроса:
1) почему "не участвовал никогда ни в доказательствах сложности H.323, ни в доказательствах обратного"? т.к. это скорее признак безразличия;
Верно. В практическом смысле мне абсолютно всё равно, сложнее h.323 других протоколов или нет. Есть задачи по этому протоколу - надо решать,
это важно. Участвовать в полемиках на околотехнические темы ни времени нет, ни желания.
amateur писал(а):
2) почему до сих пор в Asterisk существует только chan_ooh323 на мёртвом стеке от Objective Systems, а не скажем chan_h323plus на H323Plus, ну или хотя бы chan_opal на OPAL?
термины "Мертвый" и "живой" в отношение к библиотеке, фреймворку, да и вообще к ПО по-моему придумали как раз маркетологи.
Не развивается как отдельный продукт, если Вы хотели сказать, да, с этим соглашусь. Но это не всегда плохо, а в данном конкретном случае даже
хорошо (на мой взгляд). Кстати, оглядываясь в прошлое, chan_h323 появился в астериск раньше и до ноября 2009 он как раз был единственным
канальным драйвером h.323
Пример тому - sofia sip, вполне удачная реализация, использующаяся как основа во Freeswitch. Digium при разработке chan_pjsip не сели на неё как раз из-за уже
вышеупомянутых "маркетологических" причин, что как раз на мой взгляд неправильно, но я с ними тягаться не способен)
amateur писал(а):
Вы же понимаете, что это позволяет только влачить жалкое существование, но о развитии в такой ситуации речь идти не может?
Теперь вот об этом. "Жалкое" существование влачил (не буду это утверждать на сейчас, но задам по этому поводу вопросы ниже) как раз chan_h323.
И причина к тому как та самая упомянутая живая библиотека open_h323.
Я провел почти три года (2006-2009), дрессируя этот драйвер на тему стабильности работы и надежности работы и не пришел к нормальному результату,
и причиной тому была падучесть как раз самой библиотеки. Не буду утверждать что причина всех бед - использование C++ и pwlib, но как минимум это однозначно
является причиной более низкой производительности.
Как это выглядит сейчас - не знаю, но я смотрел H323PLus, на 2010 отличий от openh323 практически не было. Про opal не скажу, его я смотрел не так глубоко.
В любом случае, отправной точкой, при которой я могу заинтересоваться использование openh323/h323plus/opal в качестве платформы драйвера астериск, это
ситуация когда я увижу астериск, пропустивший за сутки миллион звонков по h.323, соответственно не упавший при этом и по завершении этого миллиона звонков
имеющий размер занимаемой памяти практически такой же как в момент первого звонка.
моя давнишняя практика показала, что на первых 10к звонков мемори лики в openh323 доходят до 2G ну и соответственно на 32битной платформе астериск падает по нехватке
памяти. ну соответственно вышеуказанные условия я вполне воспроизвожу на системе, используюшей chan_ooh323.
Повторюсь, как раз соблюдение похожих требований легло в основу разработки chan_ooh323 и было реализовано.
Я много времени провел на эту тему с openh323 в компании с valgrind'ом и gdb и ничего путного в результате получить не смог.
amateur писал(а):
may писал(а):сделать патч на тему h245address и открытия канала, а также по части multiplexCapability
имеется в виду патч, который будет отправлен в master бранч астериска.
вы мне вполне можете в этом помочь.
Я уже прикидывал как сформировать multiplexCapability в TCS. В принципе, если некоторое время помучиться, то осилить можно.
ну там даже мучаться-то не надо. У меня банально времени нет. Работы часа на два.
amateur писал(а):
Но меня останавливают две вещи:
1) отсутствие документации на стек от Objective Systems и его фактическая смерть;
Про "смерть" добавлю только один вопрос - от того, что он не развивается, существующие функции в нем стали хуже работать или нет?
amateur писал(а):
2) на мой взгляд бесперспективность дальнейшего развития chan_ooh323 в силу вышеописанных причин.
Поддерживая chan_ooh323, мы просто распыляем усилия.
Я уже написал о причинах по которым у меня пока диаметрально противоположное мнение.
amateur писал(а):
Я слежу за изменениями в H323Plus и GNU Gatekeeper (эти проекты тесно связаны). Мое мнение: нужно сконцентрировать усилия на развитии H323Plus, и создать канальный драйвер на основе этой библиотеки. Только в этом случае можно рассчитывать, что когда-то поддержка H.323 в Asterisk будет соответствовать текущему уровню развития технологии - поддерживать динамическую регистрацию оконечных устройств, ВКС, NAT и другие расширения по H.450, H.460 и т.п.
Вы что думаете?
И тут добавлю. Уже в 2009ом, когда я начинал разработку chan_ooh323, на уровне endpoint устройств H.323 был довольно редко используем. Тем более сейчас,
за последние 2 года я не встречал новых устройств, которые основывались на h.323, даже самые модные и сложные конференц станции в текущее время используют SIP.
H.323 с моей точки был и останется удобным протоколом взаимодействия бордер-контроллеров, телефонных станций и прочих свичей.
И в этом ключе мне как раз и интересно развивать его.
Из таких больших проектов, это реализация Q.sig внутри H.323 (он даже начат этот проект и многое там уже сделано) и реализация поддержки
video внутри chan_ooh323 (к этому второй год приступить не могу)
Ну и еще добавлю, chan_ooh323 далеко не единственный и пожалуй в настоящее время и не главный проект, который мне интересен в рамках моей работы.
Хотя, надеюсь, что и на него будет оставаться необходимое для поддержки и развития время.