Early media что это
Early media или музыка вместо гудков в Asterisk
Иногда хочется, чтобы во время звонка вместо длинных гудков проигрывалась мелодия. Как в рекламе говорится, “надоели гудки”? Такое возможно сделать с помощью Asterisk. Эта технология называется Early Media описанное в RFC3960.
В официальных источниках по Asterisk есть две статьи (один, два) описывающих одну и ту же ситуацию: на поступивший звонок играет мелодия, вызов отбивается. В этот момент вызов не считается отвеченным.
Нам же необходимо сделать именно вызов абонента с мелодией. Для этого создаем свой MoH класс, в котором прописываем необходимую мелодию. В директории mymusic находится один файл, поэтому проигрываться всегда будет он. Пример musiconhold.conf :
Не забыть перезапустить(!) Asterisk, т.к. он не умеет “на лету” считывать новые мелодии в директории, указанной в классе.
Далее в extensions.conf создаем макрос (но можно просто в диалплан на каждого, кому эту мелодию на вызов ставить):
И наконец ставим абоненту/пользователю на вызов эту мелодию всё в том же extensions.conf :
Теперь при звонке на номер 444 будет проигрываться мелодия, которая указана для MoH класса mymusic. Проще простого.
UPD(27.10.2015): Коллега столкнулся с похожей задачей, но была необходимость не в мелодии вместо гудка, а в проигрывании сообщения-уведомления. Полученный результат более гибок в сравнении с установкой проигрываемого файла через MoH и позволяет воспроизводить любые файлы без перезагрузки сервера Asterisk PBX. И теперь само решение:
А далее в extensions.conf такие строки, чтобы вызвать соответствующего SIP-пира:
В целом можно оформить этот диалплан в макрос, но пример приводить не буду.
Lync и SIP. Объявление медиа-возможностей и ошибка КПВ
Вместо предисловия
Во время Teched Russia 2011 самым задаваемым мне вопросом оказался вопрос про отсутствие длинного гудка при вызове абонента Lync из ТфОП. При этом, все спрашивающие являлись читателями ITBand.RU. Так что, первым делом по возвращении домой с MVP Open Days, я решил перенести уже готовую статью по данной теме из собственного блога (являющегося для меня чем-то вроде инкубатора) сюда. Надеюсь будет полезно.
Урок номер 3
Продолжаем разговор про использование SIP в Lync Server 2010. На этот раз мы разберем SDP пакет, генерируемый Lync при видео-вызове в части предлагаемых способов аудио/видео взаимодействия и ответим на пару вопросов из предыдущей статьи, включая наиболее популярный: про отсутствие гудков при звонке на Lync.
Домашнее задание
Для начала, проверим домашнее задание – посмотрим, какие кодеки использует Lync.
Как и в прошлый раз, я выложил разбор в отдельный PDF.
Разбор ошибки с отсутствие гудков
Во второй части статьи опишу причину наиболее часто возникающей ошибки при настройке Lync Server в качестве АТС. А именно, отсутствие контроля посылки вызовов (КПВ) при поступающих на Lync звонках. Проще говоря, отсутствие гудков.
Идеальная ситуация
Упрощенно, процесс телефонного вызова из ТфОП в IP-телефонию выглядит так:
Сигнал КПВ генерирует голосовой шлюз, непосредственно подключенный к аналоговым/цифровым телефонным линиям. При IP-to-IP вызовах сеть передачей КПВ вообще не нагружается, так как КПВ генерирует сам вызывающий клиент, получив 180 Ringing.
Но это в идеале. Почему же при работе с решением от MS генерация КПВ в некоторых случаях не происходит?Ноги у этой проблемы растут довольно далеко. Все началось в далеком 2007-ом году… (театральная пауза).
Истоки проблемы
В OCS 2007 в Microsoft внедрили поддержку протокола ICE (Interactive Connectivity Establishment), позволяющего обходить «двойной NAT» для голосового трафика. Это обеспечило возможность приема/передачи голоса и видео для пользователей OCS, подключаемых из сети Интернет. Однако, технология предусматривала последовательный опрос нескольких точек подключения, что требует
некоторого времени. Источник вызова не мог начать опрос возможных вариантов соединения до получения сообщения 200 ОК, содержащий вложение SDP со списком возможных способов связи. Как результат, какое-то время в трубке была слышна тишина, а первые сказанные фразы могли потеряться. Исключение составляли вызовы на голосовой шлюз.
Приблизительная схема выглядит так: 
Имеем стандартную схему. Внутренний пользователь, сервер с ролью Front End, Сервер с ролью Edge (условно его можно разделить на Access Edge и Audio/Video Edge), внешний пользователь. 
Попытки соединения для передачи RTP трафика и сам трафик от вызываемого абонента не рассматриваю, так как его можно стартовать сразу после сообщения INVITE, потому что оно уже содержит описание возможностей вызывающего.
В OCS 2007 R2, чтоб избежать такой ситуации была использована одна хитрость, заложенная в RFC 3960, и связанная с обработкой ответов 183 Session in progress.
Ответ 183 Session Progress и RFC
Тут нужно сделать паузу и немного рассказать про ответ 183 Session in progress.
Из RFC 3621, описывающему протокол SIP:
The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress
Никакой конкретики. В реальности, ответ 183 Session progress обычно используется для передачи голоса до установления соединения, Early Media (Например, чтоб проиграть голосовое сообщение или музыку, пока абонент не возьмет трубку). Так вот, если ответ получен, но голосовые пакеты еще не пошли,
то согласно RFC 3960 IP-АТС / голосовому шлюзу рекомендуется передавать КПВ.
Из RFC 3960
With this in mind, a UAC should develop its local policy regarding local ringing generation. For example, a POTS («Plain Old Telephone Service»)-like SIP User Agent (UA) could implement the following local policy:
Как видно, в примере используется ответ 180. Многие понимают эту фразу буквально и не учитывают в настройках другие ответы класса 1XX. Отсюда и ошибки. Но об этом чуть позже.
Реализация Early Media от MS
MS использует ответ 183 Session progress дважды. Первый раз после отправки 100 Trying, просто чтоб показать, что работа в разгаре. Сам не знаю, зачем. Второй раз, когда запрос дошел до конечной точки маршрута. На этот раз уже ответ cодержит SDP. Покажу на примере. На этот раз разберем обмен сообщениями чуть подробнее.
Получаем, что сессия устанавливается еще до того, как абонент поднял трубку. Если одновременно запущен только один клиент Lync, то он и ответит на вызов и в ответе 200 ОК будут те же данные, что и в 183
Session progress. Сессия установлена заранее. Как только получен ответ – голосовой/видео трафик пошел. PROFIT!
Что имеем
Основой для статьи (в части разбора ошибки с КПВ) является серия статей в блоге Криса Нормана, ака voipnorm. Там же вы можете много подробностей сопряжения Lync/OCS с Cisco/Avaya.
Early media или музыка вместо гудков в Asterisk
Иногда хочется, чтобы во время звонка вместо длинных гудков проигрывалась мелодия. Как в рекламе говорится, “надоели гудки”? Такое возможно сделать с помощью Asterisk. Эта технология называется Early Media описанное в RFC3960.
В официальных источниках по Asterisk есть две статьи (один, два) описывающих одну и ту же ситуацию: на поступивший звонок играет мелодия, вызов отбивается. В этот момент вызов не считается отвеченным.
Нам же необходимо сделать именно вызов абонента с мелодией. Для этого создаем свой MoH класс, в котором прописываем необходимую мелодию. В директории mymusic находится один файл, поэтому проигрываться всегда будет он. Пример musiconhold.conf :
Не забыть перезапустить(!) Asterisk, т.к. он не умеет “на лету” считывать новые мелодии в директории, указанной в классе.
Далее в extensions.conf создаем макрос (но можно просто в диалплан на каждого, кому эту мелодию на вызов ставить):
И наконец ставим абоненту/пользователю на вызов эту мелодию всё в том же extensions.conf :
Теперь при звонке на номер 444 будет проигрываться мелодия, которая указана для MoH класса mymusic. Проще простого.
UPD(27.10.2015): Коллега столкнулся с похожей задачей, но была необходимость не в мелодии вместо гудка, а в проигрывании сообщения-уведомления. Полученный результат более гибок в сравнении с установкой проигрываемого файла через MoH и позволяет воспроизводить любые файлы без перезагрузки сервера Asterisk PBX. И теперь само решение:
А далее в extensions.conf такие строки, чтобы вызвать соответствующего SIP-пира:
Many dialplan applications within Asterisk support a common VOIP feature known as early media. Early Media is most frequently associated with the SIP channel, but it is also a feature of other channel drivers such as H323. In simple situations, any call in Asterisk that is going to involve audio should invoke either Progress() or Answer().
By making use of the progress application, a phone call can be made to play audio before answering a call or even without ever even intending to answer the full call.
Early media что это
Full ownership after 8 months
Long term service fee 0 %
Total purchase price 800
Use the domain shortly after payment
After the first payment, our system automatically transfers the domain to our own holding registrar to keep it safe and available for you. Once the transfer is done (this can vary per domain since some registrars approve transfers only after 5 days) you can manage the DNS of the domain via your Buyer Control Panel.
Domain transfer after the final installment is paid
When the final installment is paid for, we will assist you with transferring the domain to a registrar of your choice and changing the ownership records of the domain.
Stop at any time
You can cancel an installment transaction whenever you want. This is only available for buyers. Sellers can’t cancel the contract, as long as you do not miss any final monthly payment deadline(s). When you opt to cancel a transaction, the received installments will be kept by the seller. You won’t receive the ownership of the domain and the domain will be returned to the original seller.
Long term service fee
Long term service fee is a fee percentage added when you pick a period longer than 1 year. The fee is included in the price you see in the Lease to Own dialog.
The service fee covers the transfer & renewal expenses of the domain, hosting DNS, providing support for years, and the recurring monthly payment processing expenses that Dan makes to facilitate this type of transaction.
Estimate in RUB
Conversion
This amount is an estimate based on the most recent currency conversion rate.
freeswitchforum.com
FreeSWITCH is a registered trademark of Anthony Minessale. Official FreeSWITCH site.
Часовой пояс: UTC + 4 часа
Определение Early Media
Совсем недавно приступил к освоению FreeSwitch.
Цель ознакомления:
1. Call traking
2. Detect Early Media
Решил начать со второго пункта. Для этого настроил соединение с PRI гейт и настроил исходящую маршрутизацию.
Предварительно ознакомился,что есть несколько вариантов применения early media при исходящем звонке. На данный момент самый интересный случай когда вызываемый абонент Недоступен или Занят.
В консоли fs видно, что определение Early media происходит, не могу пока разобраться как применить условие в случаи если?
Есть ли вариант реализации подобного?
Спасибо.
Положить трубку и не дожидаться 12-16 сек анонсирования со стороны оператора.
что интересного, поподробней
«Early Media» в том или ином случае в PRI это выходит либо Progress либо Alert
если вам надо чтобы в PRI вышло Alert как вариант (перед bridge в pri) через export пнуть nolocal:ignore_early_media=true
хотят тут спорная ситуация и не факт что ваш PRI гейт исполнит свой «супружеский долг» в соответствии
Пришел cause 31, в сторону fs какой нибудь sip пакет приходит или sip пакет приходит когда disconnect?
В любом случае если «балалайка» удерживает канал как вы собираетесь определять где канал висит а где тупо ждет alert?
«теорию в разнице» вам озвучил ранее, осталось проверить как «балалайка» отработает
Название у вашего pri гейт есть?
нет ли способа сделать предусловие в случаи если канал в статусе DOWN и на канале EARLY?
eltex sgm страница 159 «inband_signal_with_183_and_sdp»
Часовой пояс: UTC + 4 часа
Кто сейчас на конференции
Сейчас этот форум просматривают: Google [Bot] и гости: 5