вторая строка вряд ли

А а каком это языке?

python

оно вообще работать не должно

Почему?

там только 2 аргумента же

Мне нужно чтобы до соединения шла озвучка (wav)

типа "соединяю вас..."

Мне нужно чтобы до соединения шла озвучка (wav)

а что в логе?

ну и вероятно надо с той же логикой тогда, uuid в конце..

если так работает

А проигрывать до ответа в a-leg нужно?

после

answer и потом уже играть

то есть предлагаете anwser сначала?

Да.

One-way audio не поддерживается подавляющим большинством операторов связи.

con.execute("answer", uuid) con.execute("playback", "/etc/freeswitch/sounds/connect_you.wav", uuid) con.execute("set", "ringback=$${us-ring}", uuid) con.execute("bridge", "sofia/external/exten", uuid) Также не проигрывает

если бридж убрать проигрывает

может из-за этого? 2017-07-05 12:17:16.118874 [DEBUG] switch_core_file.c:216 File /etc/freeswitch/sounds/greeting_say_name.wav sample rate 44100 doesn't match requested rate 8000 2017-07-05 12:17:16.118874 [DEBUG] switch_ivr_play_say.c:1314 Codec Activated L16@8000hz 1 channels 20ms 2017-07-05 12:17:16.178834 [DEBUG] switch_rtp.c:5928 Correct ip/port confirmed. 2017-07-05 12:17:16.178834 [DEBUG] switch_core_io.c:528 Setting BUG Codec PCMU:0

а нет

это ж другой файл

ну и проверь с файлом, который проигрывает

он ж ведь работает без бриджа

я так думаю что он просто не успевает играть и сразу делать бридж

тогда наверное нужно какой-нить тайм аут сделать

Он должен последовательно выполнять.

логически да

А в обычном xml диалплане такое работает?

не помню, ща проверю

в обычном последовательно

там как раз сложнее сделать фоновое проигрывание

А нужно фоновое?

да, в обычном xml работает!

на питоне почему-то не хочет

вы используете ESL?

да

именно

асинхронно?

Я думаю, что проблема в асинхронности.

Нужно на событие окончания проигрываеия bridge вешать.

В синхронном режиме выполнение один за одним

в асинхронном режиме нужно ловить событие оканчания выполнения

а этого не знаю

Поставь паузу до бриджа и проверь.

pause?

Да.

щас

кто тестил ESL на производительность?

что-то sendmsg у нас уже на 4 запросах при 50 cps глохнет

время обработки до 30+с растёт

50 cps могут очень по разному быть.

засылается на ансвере

con.execute("answer", uuid) con.execute("playback", "/etc/freeswitch/sounds/connect_you.wav", uuid) con.execute("pause", uuid) 2017-07-05 12:45:54.197267 [DEBUG] switch_ivr.c:616 sofia/public-profile/1007@10.1.1.246:5060 Command Execute pause(b96dbfea-6166-11e7-8aaf-39949b7ecaa1) 2017-07-05 12:45:54.197267 [ERR] switch_core_session.c:2574 Invalid Application pause

Паузу с т.з. python

Не фрисвитчёвую.

Oubound connection?

на питоне что ль

Да

сделал так con.execute("answer", uuid) con.execute("playback", "/etc/freeswitch/sounds/connect_you.wav", uuid) time.sleep(5) while True: print("This prints once a minute.") time.sleep(60) False con.execute("set", "ringback=$${us-ring}", uuid)

вроде прогаваривает

Ну вот. Асинхронность -> события.

Event driven design. И вперёд.

Там не все так просто :)

немножко нужно доработать, чтобы по истечению времени таймаута срабатывал бридж

сейчас до бриджа не доходит

ERROR: S client not available

Может попробывать синхронно?

Потому и нужно событие отлавливать.

Ладно, всем спасиб ребят. Вернемся попозже к этой теме!

PLAYBACK_STOP event нужно ловить.

CHANNEL_EXECUTE_COMPLETE более универсально

ну и CHANNEL_HANGUP потому что CHANNEL_EXECUTE_COMPLETE может не прийти :)

CHANNEL_EXECUTE_COMPLETE более универсально

а пульнул uuid_broadcast в канал и хана

не, лучше специфик ивентс

ну и CHANNEL_HANGUP потому что CHANNEL_EXECUTE_COMPLETE может не прийти :)

if channel:ready же (это в луа так)

Не все так просто. playback может быть вызван из обрабочика в канале. например execute_on, Не увереен что есть способ узнать для какого execute пришло это событие

CHANNEL_EXECUTE_COMPLITE имеет uuid команды

PLAYBACK_STOP тоже

но мы такое не применяем, так что молчу )

Все равно мне больше нравится подписыватся на минимальное кол-во событий

Я тоже не использую ESL :)

поигрался и бросил за ненадобностью

мы используем активно, но только на получение в основном

а диалпланы формируем отдельно и в xml_curl

Пременную в playback можно запихать. Она в событии будет.

созрел вопрос, контекст указаный в external.xml имеет меньший приоритет по сравнению с тем что указан для каждого отдельного профиля в external/*.xml ?

Если вы имеете ввиду контекст в шлюзе - то да

Правда этот контекст будет работать только если удаленная сторона пришлет корректный формат сообщения

имя шлюза из заголовка contact

Далеко не все операторы это делают

Ну и шлюз необходимо регистрировать

а в случае если шлюз без регистрации по факту работает через invite?

а в случае если шлюз без регистрации по факту работает через invite?

регистрация нужна только для звонка на шлюз, при звонке наружу оно необязательно

Да и для входа оно не обязательно

таки не нужна регистрация port,invite же

регистрация нужна только для звонка на шлюз, при звонке наружу оно необязательно

не для всех провайдеров)

Не уверен правда может ли FS опознать шлюз без регистрации

не для всех провайдеров)

только как защита. По стандартам - рега и инвайт не связаны никак