[devel] Ядра для ип-телефонии

[Eugene Prokopiev]

16.12.08, Денис Смирнов написал(а):

> On Tue, Dec 16, 2008 at 09:13:49AM +0300, Eugene Prokopiev wrote:
>
>  EP> 1) Мне бывает нужно ипользовать его в VE - и в этом случае ztdummy
>  EP> является приличным извращением. Хотя по сути я меняю шило на мыло,
>  EP> т.к. есть подозрение, что CallWeaver без CONFIG_HZ=1000 - примерно то
>  EP> же самое, что и Asterisk без zaptel/dandi. Впрочем, на практике это
>  EP> оказывается приемлемым - см. выше
>
>  Именно так -- CallWeaver'у нужен HZ=1000 для той же цели для которой
>  астериску ztdummy.
>
>  Однако для меня странно что из него _вырезали_ поддержку таймера от
>  zaptel. Потому как если мы используем zaptel-оборудование, то таки таймер
>  _надо_ брать от него. Особенно если речь о E1.

может я и ошибаюсь - надо проверить

>  EP> 2) Мне нужен Т.38 - хотя стабильность его работы сильно зависит от
>  EP> очередного китайского патча на другом конце
>
>  Увы. Правда в астериске все пока с T.38 сильно хуже. Спасибо хоть Стив
>  отдал libspandsp под LGPL -- хоть теперь дигиоиды пошевелятся.

плохо еще то, что многие проекты таскают spandsp в пузе - хотя при
частой смене API так действительно проще жить

>  EP> 3) Мне не нравится, как у нас упакован Asterisk - пожалуй, это самая
>  EP> серьезная причина :) О том, как сделать правильно (ну или удобно мне -
>  EP> это будет более точная формулировка), мы уже не раз говорили ;)
>
>  Повесь на меня что-нибудь тяжелое :)
>
>  А конкретно? Кроме того что у нас пакет asterisk1.4 зависит от h323 (увы,
>  с этим ничего не сделать), что еще тебе не нравится? Если ты помнишь
>  большинство твоих патчей я всегда принимал, и тебе кстати большое спасибо
>  за разбиение на подпакеты ;)

Постараюсь расписать подробнее. Я так понимаю, что тебе удобнее будет
много мелких багов чем один большой?

>  >>  А астериск у меня с std-smp и на больших нагрузках нормально работает.
>  >>  Если, конечно, 4xE1 считать большой нагрузкой :)
>
> EP> Думаю, что считать :)
>
>  :)
>
>  EP> Просто мне интересна формализованная методика тестирования. Никаких
>  EP> идей кроме софтфона специального вида, которым можно установить N
>  EP> соединений и гнать туда какую-нибудь пургу, и обычного контрольного
>  EP> соединения для проверки качества на слух, у меня нет ... Ну можно
>  EP> также считать задержки RTP (анализировать дамп?) того же контрольного
>  EP> соединения.
>  EP> А экпериментировать на единственной нагруженной инсталляции у меня нет
>  EP> ни возможности, ни желания ...
>
>  Да, собрать стенд я давно хочу. Увы все никак до этого руки не доходят.

Стенд я б собрал, но главное - как раз разработать методику
тестирования и реализовать ее. Если вдруг возьмешься - посмотри на
pjsip как на реализацию sip-стека для такого софтфона.

>  EP> Короче, вопрос еще требует изучения ... Хотя, это чисто академический
>  EP> интерес. С практической стороны я не вижу проблем держать
>  EP> слабонагруженные инсталляций в VE и высоконагруженные на выделенной
>  EP> машине с соответствующим ядром.
>
>  Ты не поверишь, но у меня была всего одна (!) SIP-only инсталляция. Везде
>  нужна хоть одна городская линия, к которой как раз обычно подцеплен факс.
>  Или еще что-нибудь такое. Так что для меня сейчас ztdummy нужен разве что
>  у себя дома при тестировании :)
>
>  Поэтому VE для меня неактуально :(

В нашей деревне получить городскую нумерацию по sip - не проблема

-- 
С уважением,
Прокопьев Евгений