freeswitchforum.com

Добрый день.

Есть FreeSWITCH 1.6.9 на CentOS 7.
Включён режим обхода речевого трафика по умолчанию для входящих вызовов параметром SIP-профиля:
<param name="inbound-bypass-media" value="true"/>
Обычные звонки устанавливаются нормально, речевой трафик идёт напрямую между абонентами.
DTMF-сигналы поступают на FS методом SIP INFO.

Но при переводе звонка с консультацией с помощью приложения att_xfer, речевой трафик между абонентами Б и В, а впоследствии А и В, начинает пропускаться через FreeSWITCH.
Сценарий следующий:
А звонит Б, речевой трафик идёт напрямую между их терминалами.
Б набирает последовательность цифр (например, *2), запускающую перевод звонка.
Обе ноги переключаются на FS (правильно), А слышит музыку, Б - ответ станции для донабора номера В.
Б набирает номер В.
В отвечает. Речевой трафик между Б и В при этом идёт уже через FS.
Б даёт отбой и В соединяется с А. Трафик между А и В также остаётся через FreeSWITCH.

Цель - пропускать трафик между Б и В и А и В напрямую между ними, не через FS.
Установка переменных bypass_media=true, bypass_media_after_bridge=true до вызова att_xfer не влияет на ситуацию.
Поддерживается ли вообще bypass media для att_xfer? Возможно, я что-то недонастроил.

Есть, конечно, один вариант, который ещё попробую - завязаться на события и, например, по CHANNEL_BRIDGE выполнять команду API uuid_media off, чтобы вручную исключить FS из речевого канала. Но это какой-то искусственный путь...

есть ещё опция

_________________
ЛС: @rostel
Сообщество: @ru_freeswitch

Включена.
Но, судя по коду, она используется только при переводе с терминала методом SIP REFER. Она только в sofia.c встречается, в функции sofia_handle_sip_i_refer.

при использовании трехсторонних зачем вы вообще мимо сервака медиа гоняете?
все сидят на белых или за нормальными NAT, односторонки никогда не возникает?

_________________
ЛС: @rostel
Сообщество: @ru_freeswitch

А зачем голос через сервак именно в данном случае?
В конференции понятно, но это же перевод звонка, здесь обе сессии точка-точка между двумя абонентами.
Если они решат собрать конференцию, то там уже пусть через FS идёт, никуда не деться...

Хотел по-максимуму разгрузить сервер от медиа-трафика, где это возможно.
В этих звонках ещё и видео может быть, не только голос...

обычно такой метод актуально для dect-трубок. чтобы перевести звонок (средствами терминала) надо в менюшке копаться
что мешает использовать цивилизованный метод т.е. перевод звонка средствами аппарата или софтовые клавиши hold и trans отсутствуют?

_________________
Пути IP-пакета неисповедимы

Есть SIP-шлюзы с аналоговыми телефонами, где ДВО только через DTMF возможны...

Да и вообще уже просто интересно стало, можно ли сделать bypass с этим приложением, или нет.
Попробую ещё несколько идей и, наверное, открою тикет на Jira...

Кстати, работоспособна ли следующая конструкция? Или я её как-то не так записал?
Почему-то во время выполнения вместо ${uuid} подставляется пустое значение.

еще не попадались мне в руки АТА-ки у которых нет параметров "Hook Flash Timer Min" и "Hook Flash Timer Max"

можно озвучить вашу модель для интереса?

_________________
Пути IP-пакета неисповедимы

D-Link DVG-7022S в основном.
Судя по доке, он поддерживает Hold и Transfer через Flash, можно, конечно, попробовать настроить на нём, но вообще изначально планировал сделать все ДВО средствами коммутатора...

Для соединения А-В получилось сделать с помощью bridge_pre_execute_app и lua-скрипта с условным uuid_media off внутри, а для Б-В пока нет, попытка убрать FS из media path для этого соединения расценивается как отбой в нём, и сразу происходит переключение абонента В на А.
В принципе, можно остановиться и на этом...
Тикет всё-таки заведу для интереса, вдруг я просто что-то не так настроил.

Ещё заметил странную вещь, что вывод приложения info в журнале почему-то обрезается примерно до 9300 байт. Часть переменных из-за этого в журнал не попадает...

по факту вы пытаетесь "объять необъятное"
заставьте FS принудительно отправить UPDATE всторону терминала где меняются источники RTP-потока

_________________
Пути IP-пакета неисповедимы