Подскажите пожалуйста, вызываю бридж с лимитом из loopback экстеншена. Как только бриджуется, лупбэк каналы временные хэнгапятся и инкремент лимита откатывается обратно, хотя звонок в процессе. Есть не костыльные варивнты?

Лупбек сам по себе очень костыльный вариант, вызовы все 4хногие получаются, не думаю что получится с лимитом вопрос решить адекватно

в хэш писать?

через mod_hash

в хэш писать?

Дык дроп ноги и обнуление

оно не в канале

freeswitch@internal> hash -ERR Usage: hash insert|insert_ifempty|select|delete|delete_ifmatch/realm/key[/value]

тащить уид звонка экспортами и писать через него

Хэш попробую, спасибо.

Всем привет. Столкнулся с проблемой записи трансферного звонка. А набирает В, разговаривают . Затем А ставит на удержание и на бирает С, А разговаривает с С. Затем А трансферит звонок и В говорит с С. Для записи я использую record_session на а-леге. Соответственно разговор В и С не пишется. Вопрос, можно ли как-нибудь выцепить REFER на фс и заставить писать разговор B и С? Пока только в голову приходит вариант со сбором ивентов на стороннем скрипте, и передачей команды в фс на запись, но для меня это сложноватый вариант.

Всем привет. Столкнулся с проблемой записи трансферного звонка. А набирает В, разговаривают . Затем А ставит на удержание и на бирает С, А разговаривает с С. Затем А трансферит звонок и В говорит с С. Для записи я использую record_session на а-леге. Соответственно разговор В и С не пишется. Вопрос, можно ли как-нибудь выцепить REFER на фс и заставить писать разговор B и С? Пока только в голову приходит вариант со сбором ивентов на стороннем скрипте, и передачей команды в фс на запись, но для меня это сложноватый вариант.

record_follow_attxfer ?

Что-то не могу найти описание этой переменной. Недавно появилась?

в 1.4 уже есть

switch_bool_t follow_recording = switch_true(switch_channel_get_variable(channel, "recording_follow_attxfer"));

Спасибо, попробую)

freeswitch@internal> hash -ERR Usage: hash insert|insert_ifempty|select|delete|delete_ifmatch/realm/key[/value]

а я думал ты про бэкенд хешовый

Лупбек сам по себе очень костыльный вариант, вызовы все 4хногие получаются, не думаю что получится с лимитом вопрос решить адекватно

А что с ним не так, какие ещё подводные камни, кроме как с cdr? Встречал комментарии, что использовать loopback нужно только в крайнем случае.

А что с ним не так, какие ещё подводные камни, кроме как с cdr? Встречал комментарии, что использовать loopback нужно только в крайнем случае.

там куча приколов

жопа с set, export и тп

так-то оно работает, но надо на каждой "особенности" споткнуться )

жопа с set, export и тп

экспорт работает )

надо бы список составить

штатно пробрасывает крайне куцый набор переменных, надо всё нужное экспортировать создаёт 2 ноги просто вызов через loopback - канал считается отвеченным независимо от успеха вызова при трансфере через луп нужно отключать схлопывание (no_bow), иначе рвет звонок

вот сходу

экспорт работает )

дык я не говорюю что не работает

работает

но через жопу)

кодеки пробрось попробую в loopback)

велик соблазн использовать схему при звонке на несколько эндпоинтов: "bridge" data="loopback/context/gw1|loopback/context/gw2"

а луп зачем?

бридж так же умеет

может в дп выставляет переменные

в контекстах некая подготовительная работа перед бриджем, в зависимости от гейтвея.

удобно и наглядно, по идее. хотя по-началу я слегка опешил от четырёх cdr записей.

потом оказалось, что лимиты не работают как надо.

удобно и наглядно, по идее. хотя по-началу я слегка опешил от четырёх cdr записей.

ты еще время разговоров проверь

ооочень любит ломать

ты еще время разговоров проверь

я глянул, да. ну, медию саму вроде верно считает.

ну хз, у меня по жесткачу на А ноге ломало, вообще какое то левое значение прилетало

может мы просто считаем его по разному

ты еще время разговоров проверь

в сдр хз, а в record_stop всё чётко

это да, это всё четко, писать перестает вовремя

запись вся и тд и тп

а вот в cdr start_epoch, answered_epoch и тп ломает

прокиывать надо скорее всего

ага

новый канал - новые значения же

ну а там получается в итоге бридж между первой и последней ногой

att_xfer нормально с loopback работает? последний раз когда тестил не соединяло, на А леге музыка ожидания, на С тишина.

Нормально, мы используем

loopback почти всегда можно заменить на transfer либо execute_exten

Здравствуйте! Сильно ли тут ногами пинают за глупые вопросы?

нет

но в доку послать могут )

loopback почти всегда можно заменить на transfer либо execute_exten

увы, не всегда.

уточнить хотел. можно ведь авторизовывать клиентов через радиус. То есть все учетный данные там хранить + аккаунтинг?

А то нихера я никак понять не могу...

можно, "Но есть нюансы"

можно, "Но есть нюансы"

Например какие?

В трёх словах

если можно...

У меня кейс какой. В радиусе хранится логин, пароль, номер. Человек пытается авторизоваться, фрисвич лезет в радивус, если данные совпадают, то авторизовывает человека, присваивая ему номер. Если так можно, то пойду торговаться с дьяволом и искать инфу ))))

тут была пара человек с радиусом, но чего-то они молчат

так-то я только знаю, что такое есть

у нас этим кама рулит

у нас этим кама рулит

Кто?)))

ERROR: S client not available

я крутил срадиус :))

Добавлял вот так вот параметр <param name="Acct-Session-Id" variable="uuid" format="%s"/>

Но использовал исходники с гугл группс.

Но лучше этим гемороем не заниматься с UTM5

http://sclif.pro/?p=544

http://sclif.pro/?p=138

заметки страдальца? ))

Ага

Ребята не делайте жизнь себе сложнее, не используйте utm5 как биллинг для телефонии.

Примерно ясно, чего же в интернетах так мало рецептов ))

в общем, надо тогда быть готовым допиливать

Значит будем)))) Спасбо за инфу

Кто?)))

подозреваю kamailio

подозреваю kamailio

А оно нормально работает с радиусом?

В принципе можно на аккаунтинг и авторизацию и его повесить, а маршрутизацией пусть фрисвич рулит. Знать бы наверняка))

У нас не получилось сделать хорошо. Написали прокладку между ФС и бэком которая делает диалплан под конкретный вызов и директори при авторизации через mod_xml_curl

Ну или так, да

Ребят, напомните, почему кама дропает options с cseq=0? и где - это в loose_route?

понять не могу почему

по rfc все ок

В инвайте?

нет, OPTIONS

Че-то голову поломал ... Как ограничить время звонка (макс 15 сек) при дозвоне на такой бридж: [leg_timeout=10]sofia/internal/100|[leg_timeout=10]sofia/internal/101 Тоесть нужно чтобы через 5 сек после того как второй зазвонит, звонок завершился

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

Че-то голову поломал ... Как ограничить время звонка (макс 15 сек) при дозвоне на такой бридж: [leg_timeout=10]sofia/internal/100|[leg_timeout=10]sofia/internal/101 Тоесть нужно чтобы через 5 сек после того как второй зазвонит, звонок завершился

не оч понял, можно логику подробнее?

Sched_hangup

нет, там нужно привязывать к execute_on_preanswer

как я понял

Входящий звонок на группу (последовательная) из двух пользователей, тайм-аут на каждом пользователе 10 сек Нужно переадресовать звонкок например наружу, если группа не ответила в течении 15 сек. Хотелось бы узнать можно ли с помощью какой-нить переменной заставить работать конструкцию [leg_timeout=10]sofia/internal/100|[leg_timeout=10]sofia/internal/101?

тоесть по задумке, сначала звонит 100 10 сек, потом звонит 101 10 сек?

да

так зачем на втором leg_timeout тоже 10 секунд?