Много ресурсов уходит на изменение состояний вызова, выделение/освобождение памяти и прочее. Знакомая история.

Ну это раз

Второе - дп на луа это хорошо

Но мне нужно централизованное хранилище

Астерик риалтайм это говно

Ну вот сразу с порога говорю

mongo и сценарии доступа

Ari ami порой избыточно

Я вообще не использую BD на проектах напрямую с астериском

чрез API

Вертятся микросервисы

туда запросами уходят данные по http

да и с FS такая же петрушка

В Kazoo эти задачи решены, там на MQ вся синхронизация и распределённые БД.

Казу отдельная история

ну да. А тут что на FS что на *надо писать сво реализацию

Что касается большого кол-ва коротких вызовов, то можно сделать "финт ушами" и просто не посылать их сразу на FS/Aster, а использовать 3pcc и перетаскивать в определённый момент эти вызовы на media-сервер.

Одни парни так делали для PDS(упреждающий набор), писали специальный скрипт, который только "отвеченные" вызовы направлял на Aster, а до ответа они на "заглушке" вертелись.

Получается такая статистика: делается 100 вызовов, из которых реально будут отвечены только 1-5. Соответственно 99-95% нагрузки идёт на заглушку и только 1-5% на Aster(в их случае)

ну вообще на астере можно драйвер поменять. На pjsip. тогда проблема уйдет тоже. pjsip многопоточен

Может стоит и потрогать астер... Не имел с ним дел очень давно, уж точно до нормального pjsip

Лично мое мнение - надо работать с тем, с чем удобно. Я перешел на FS только из за того что один из проектов в ТЗ требовал FS А не Asterisk

Сейчас у меня очень двояое впечатление и от первого и от второго))

Господа, доброго дня. Подскажите, пожалуйста, возможно ли реализовать такую схему: Есть 3 бокса freeswitch. На каждом организуется своя видеоконференция. В какой-то момент времени нужно объеденить эти конференции в одну, так, чтобы это выглядело, как одна общая конфа.

хм

а настройки конфы какие

стандартная конфа из комплекта freeswitch-meta-all, та что по 3500. <extension name="cdquality_stereo_conferences"> <condition field="destination_number" expression="^(35\d{2}).*?-screen$"> <action application="answer"/> <action application="send_display" data="FreeSWITCH Conference|$1"/> <action application="set" data="conference_member_flags=join-vid-floor"/> <action application="conference" data="$1-${domain_name}@video-mcu-stereo"/> </condition> </extension>

можно из какой либо конференции через донабор например или ESL послать originate через bgapi на другой сервер и зацепиться вызываемом сервере за конференцию

Интересно, а чем "вызвон" из этой конфы в сторону другой конфы будет принципиально отличаться от присоединения ко второй конфе ещё одного пользователя?

ни чем. Поэтому так и написал

И уточняющий вопрос: FreeSwitch в конфе видео смешивает?

Я помню, что были попытки "пробрасывать" видео-потоки, не смешивая их, но не помню, к чему это пришло в итоге.

смешивает. и канал между фрисвитчами очень узкий (1мбит), потому нельзя просто пользователей одного перенаправлять на другого.

хотя, если без этого никак - прщай кач-во видео)

Если смешивает, то как и обсуждается - делается мост.

Пробросить управление конференцией, пожалуй, не получится, т.к. для второй конференции все участники первой это один участник.

если нужно управление - то через transfer просто переподключить участников к новой

Тут весь смысл в распределениии, как я понял. Так-что transfer не вариант.

да, смысл в распределении, экономия канале меж боксов и автономность в случае отказа на своих абонентах. и в случае bridge и в случае transfer объем траффика между боксами будет равный?

transfer - это внутренняя операция, вопрос некорректный

или bridge будет гонять "микшированый" поток?

мост будет микшированные потоки гонять

уже неплохо

Управление останется раздельным. В части слышимости/видимости будет всё работать.

А допилить "проксирование управления" - интересная идея, кстати.

и еще вопрос, если не надоел. есть ли стандартный способ на клиенте получить список зарегистрированых пользователей? клиент - JsSIP со своим интерфейсом, в распоряжении соединение с FS по веб-сокету и весь арсенал http/ajax и т.п.

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

именно зарегистрированных по SIP или состояние регистраций/вызовов по некому списку?

Есть такая штука как PRESENCE - как раз решает задачу слежения за списком контактов.

Но сам список контактов никак "стандартно" не получается - это произвольно.

список - это все, что есть в directory.xml, плюс их статусы (онлайн/офлайн). можно ли средствами FS эту инфу раздать клиентам.

http://www.voiceoperatorpanel.com/

т.е. парсить directory.xml, смотреть на presence и все это раздавать своим tcp сервером?

Это хочется?

конечно хочется) но это оверкилл. достаточно скайп-подобного списка контактов)

Как правило, "список" получают любым удобным для себя методом, а слежение организуется стандартным PRESENCE

понял. спасибо огромное!

Завернул все в бд храню там комнаты, пользователей, настройки конфы) через websocket клиентом подписываюсь на обновления списка участников - получаю реалтайм

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

добрый день. кто нибудь использовал в практике оповещение на почту когда сип транк отваливался?

И на почту и по СМС через систему мониторинга, в частности Zabbix

в Zabbix - е есть имено чтобы сип транк когда отваливался или он сервер только мониторит?

скриптами можно сделать но я думал что то есть родное на фс

Вроде ФС через СНМП отдает в т.ч. статус реги

ERROR: S client not available

смешивает. и канал между фрисвитчами очень узкий (1мбит), потому нельзя просто пользователей одного перенаправлять на другого.

https://habrahabr.ru/post/268773/

Да. Делали "вещание". Было дело.

Клиенты на rpi и gstreamer и sipp, конечно.

https://habrahabr.ru/post/268773/

да, эта статья и стала отправной точкой. но там видимо, не все показано. иначе зачем столько JS

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

Как правило, статьи "по памяти" прсле проекта пишут уже.

К ним стоит относиться по принципу: "помню, что примерно так делал"

Приветствую! Господа,подскажите как правильно сделать донабор dtmf при исходящем вызове. Т.е. при наборе через шлюз на определенный номер отвечает disa, в ней нужно донабрать комбинацию, а затем вызываемый номер. Заранее спасибо за ответы

Приветствую! Господа,подскажите как правильно сделать донабор dtmf при исходящем вызове. Т.е. при наборе через шлюз на определенный номер отвечает disa, в ней нужно донабрать комбинацию, а затем вызываемый номер. Заранее спасибо за ответы

2833 или inbound?

Нужно после ответа сгенерировать звуки тонового набора.

inband получается

execute_on_answer spandsp_send_dtmf

просто send_dtmf*

и dtmf_type не забыть

но по сути все вертится вокруг execute_on_answer

никто не пробовал переписать hangup_cause переменную после поднятия трубки? Задача такая: после поднятия трубки на отвечающем плече должны донабрать 1 скажем - это будет говорить о том тчто трукбу взял действительно человек. Есл же нет, то положить трукбу и звонок считать неотвеченным В общем и целомя могу конечно сделать специальную переменную и отдать ее куда хочу, но как по мне, было бы здорово управлять этим через hangup_cause попробовал переписать переменную через session:setVariable("bridge_hangup_cause"," CALL_REJECTED") Результат нулевой

у приложения hangup есть параметр

туда можно вписать hangup_cause

никто не пробовал переписать hangup_cause переменную после поднятия трубки? Задача такая: после поднятия трубки на отвечающем плече должны донабрать 1 скажем - это будет говорить о том тчто трукбу взял действительно человек. Есл же нет, то положить трукбу и звонок считать неотвеченным В общем и целомя могу конечно сделать специальную переменную и отдать ее куда хочу, но как по мне, было бы здорово управлять этим через hangup_cause попробовал переписать переменную через session:setVariable("bridge_hangup_cause"," CALL_REJECTED") Результат нулевой

session:hangup("...");

то что нужно

Работает

execute_on_answer spandsp_send_dtmf

Подскажите что не так

все не так

<condition field="destination_number" expression="^([45]\d{2})$"> <action application="set" data="dtmf_type=inband"/> <action application="set" data="execute_on_answer="send_dtmf *4719110852@500"/> <action application="bridge" data="sofia/external/1144@192.168.11.1:35060"/> <action application="answer" />

?

answer зачем

или это я натупил... вроде там send_dtmf_generate нужно

хотя не факт

атака продолжается session:setVariable("continue_on_fail","true") session:setVariable("hangup_after_bridge","false") session:execute("bridge",processingData.dialString) session:consoleLog("notice",session:getVariable("bridge_hangup_cause")) — тут пусто... Звонок отбиваю сам на вызываемой стороне

атака продолжается session:setVariable("continue_on_fail","true") session:setVariable("hangup_after_bridge","false") session:execute("bridge",processingData.dialString) session:consoleLog("notice",session:getVariable("bridge_hangup_cause")) — тут пусто... Звонок отбиваю сам на вызываемой стороне

а loglevel какой?

При поднятии трубки вижу норм А если например не поднимаю а просто отбиваю (USER_BUSY) То ничего переменная пустая Хотя в логах вот так Hangup sofia/external/92Av96hW50q9 [CS_CONSUME_MEDIA] [USER_BUSY]