Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Документация и статьи по Asterisk PBX Asterisk: новости


Вступление

Здравствуйте дорогие читатели.

Прошу прощения, что эта рассылка долго не выходила, и хочу обрадовать что я ещё живой, и время на следующие выпуски найду.

С радостью или сожалением (как вам угодно) могу констатировать, что Digium сорвала свой же roadmap по выпуску версий, и пока не спешит выполнить обещание. В связи с этим несмотря на уже состоявшийся фриз, многие сделанные ранее вещи были или будут интегрированы в транк, и мой прогноз по не включению в 1.4 3-х ключевых компонентов, добавление которых и оправдывало с моей точки зрения выпуск новой версии, был выполнен всего на треть.

А именно -- T.38 транзит и RTP jitter buffer добавлены были. Изменения в codec negotiation логике добавлены не были.

Да, я хотел бы провести среди вас опрос. Я сейчас планирую выпустить дистрибутив с Asterisk, в том числе в связи с тем, что ни Asterisk Business Edition, ни астериск open-source версии не очень-то приспособлены для использования во многих реально имеющихся в нашей практике ситуациях. Первый не совместим с GPL, а на второй надо сначала десяток патчей накладывать, а потом ещё десяток модулей собирать. Я планирую выпустить решение, где все это просто будет, для облегчения жизни нашим коллегам, также предоставляющим услуги по установке/поддержке/обслуживанию Asterisk.

Соответственно главных вопрос -- чего из имеющегося в штатной поставке (asterisk + asterisk-addons) вам обычно не хватает?

Второй вопрос -- считаете ли вы имеющим смысл выпуск нами диска с исходниками Asterisk, сразу с наложенными некоторыми патчами и лежащей рядом коллекцией модулей, а также некоторым объемом документации на русском языке по сборке/установке?

И третий вопрос -- чего вам не хватает в системах уровня Asterisk@Home (я понимаю что надежности и безопасности, о которых там вообще не думали, а чего из функционала)?

Обдумав ситуацию на рынке и наши способности, мы решили ограничиться работой по прямому предоставлению наших услуг только Москвой, и, возможно, областью. Для остальных же регионов и стран ближнего зарубежья выступать в роли техологических доноров, сосредоточив основные силы на выпуске дистрибутивов и сборок Asterisk.

Поэтому я буду крайне рад услышать ваши пожелания, как специалистов уже работающих с этим чудесным продуктом, какую именно часть своей работы вы бы с удовольствием свалили на нас, сосредоточив свои силы на деятельности, которая сделает выписки с ваших банковских счетов более приятными для вас :)

T.38

Да! Свершилось таки это чудо. T.38 транзит работает. Увы, часть предложений от Steve Underwood по улучшению этого кода была просто проигнорирована, однако более-мене это работает. Оно несовместимо с железом от Cisco, например.

Проблема в том, что T.38 стек некоторых, не желающих соблюдать стандарты производителей, вместо того чтобы использовать для UDPTL отдельное соединение, использует то же, что использовалось для RTP. А так как в астериске стеки RTP и UDPTL раздельны, мы имеем, как обычно, грабли. Решены они могут быть только выделением отдельного модуля, обслуживающего произвольные UDP-соединения для передачи данных, которым будет пользоваться как UDPTL-стек, так и RTP-стек.

Часть необходимой для этого работы -- вынесение всей логики по прямой передаче RTP данных прямо внутрь RTP-стека, без передачи каждого фрейма через ядро Asterisk, только сегодня была проделана. Это и на производительности сказаться хорошо должно, и даст в будущем возможности по использования различных методик увеличения производительности (вплоть до модуля ядра, обслуживающего RTP, чтобы исключить переключения контекста на передачу каждого фрейма, что, мягко говоря, создает слишком много проблем с производительностью).

Так что про нормальный T.38 пока можем забыть, кое-как оно работает и уже хорошо. Зато в 1.8 можно будет, в теории, ожидать существенного увеличения производительности.

Вообще я сильно надеюсь что в ближайшее время откажутся от совершенно уродливой модели одна нить -- одно соединение, которая на x86 железе работать приемлемо не будет никогда, и придут к использованию пула тредов, который обслуживает все.

До тех пор, увы, байтики гонять со скоростью поросячьего визга всякие MERA MVTS да SIP Express Router'ы будут куда лучше астериска, который как сервер приложений для IP телефонии хорошо, а вот как VoIP свич что-то среднее между тормозом и якорем, увы. То бишь только для малого и среднего бизнеса.

Jitter buffer

- Добавлена поддержка Jitter Buffer для всех протоколов, использующих RTP; - Добавлен новый алогоритм jitter buffer'а с фиксированым размером буфера;

Ну по поводу первого я распространяться особо не буду -- все уже сказано, все ждали и радовались. А вот о втором скажу чуть подробнее. Увы, динамический jitter buffer иногда создает сам по себе проблемы, и его неестественный интеллект пока хромает. Если мы организовываем соединение между узлами, среднее отклонение значения задержки передачи данных между которыми нам известно, то лучше использовать фиксированный jitter buffer.

Разное

MusicOnHold файлы теперь распространяются в поддерживаемых астериском форматах, и уродливый метод проигрывания музыки с использованием mpg123 больше не нужен.

Вообще использование mpg формата для MusicOnHold само по себе было глупой идеей -- дисковое пространство стоит копейки, а вот проблем с mpg123 было слишком уж много. Правда я из этого всегда выкручивался использованием format_mp3, который куда менее проблемный, однако лишнюю нагрузку на процессор давать не зачем.

Аналогично asterisk-sounds теперь поставляется не в виде gsm, а в нескольких поддерживаемых Asterisk форматах (в том числе G.729!). Меньше транскодинга, выше качество и холоднее в серверной :) Это важно ещё в том контексте, что мы можем не выполнять транскодинг для G.729 даже в том случае, если нам нужно воспроизводить что-либо пользователю. Таким образом можно построить АТС, в которой и аплинки и аппараты используют G.729 даже в том случае, если G.729 кодека на АТС нет вообще.

Поддерживается новый вариант расположения локализованных записей -- теперь код языка может являться не префиксом, а суффиксом, что гораздо удобнее. Правда в первую очередь это полезно для систем, требующих многоязыковую поддержку одновременно, а системы для столь требовательных пользователей в России на астериске пока мало кто ставит.

Добавлена поддержка zaptel transcoders -- ещё не вышедшей платы Digium для аппаратного транскодинга. Это будет 120-и канальный аппаратный кодек для G.729 и G.723.

Добавлено приложение NacroExclusive, которое выполняет макрос гарантируя, что этот код не будет выполнен параллельно;

Voicemail

- добавлена поддержка IMAP storage. Увы, она требует очччень неприятной библиотеки c-client, которая отличается великой странностью своих авторов;

- Старый формат ODBC-storage отменен, вместо него используется ODBC extended (отличие только в двух добавленных полях), по сути это было избавление кода от использующегося только ленивыми кода;

- Теперь приложение не завершается при необходимости проиграть несуществующие сообщения (в случае недоделанной локализации, например);

- К создаваемым сообщениям добавляются заголовки с callerid для большего удобства поиска и работы автоматически фильтров -- те кто пользуются почтовыми клиентами с поддержкой scoring'а и/или виртуальными папками оценят по достоинству;

Поддержка видео

- добавлена поддержка видео в chan_agent;

Добавленые приложения

- app_followme

В избранное