не работат? )

неисключено)

Протестил uuid_displace, отрабатыват как надо.

мод_колцентр пользуете?

Да, используем, если вопрос ко мне

Вот там по-моему и были с дисплейсом проблемы

При входящем вызове на Б ногу не вешалось по-моему

С колцентром ничего не вешается на ногу агента, надо прокидывать через сс- и в диал строку

С колцентром ничего не вешается на ногу агента, надо прокидывать через сс- и в диал строку

не, там можно, на это очень сильное колдунство

но вот конкретно с uuid_dispace там какая то дичь была

там или member_uuid поялялся как то не в то время когда надо, или чот такое

не помню, врать не буду

там или member_uuid поялялся как то не в то время когда надо, или чот такое

наврал, agent_uuid

execute_on_media_timeout

никто не юзал?

Кто все эти люди? Ещё и молчат )

они следят за нами)

хотя в ру_сисадминс они бы гораздо больше всякого интересного увидели ?

хотя в ру_сисадминс они бы гораздо больше всякого интересного увидели ?

В ру-сисадминс, если имеется в вижу ЖЖ, куда веселее, чем у нас тут. В смысле, срачей больше.

имеется ввиду чатик в телеге https://t.me/ru_sysadmin )

у нас тут срачей почти не бывает

у нас тут тихо, мирно и адекватно всё в целом)

чат узкотематический

а там болталка

неее, там не болталка) там срачельник)

Мы просто ламеры, нам нечего вам рассказать. Продолжайте общение пожалуйста

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

а там болталка

У нас срач начинается, когда кто-то фрисвитч из исходников собирает

А не пользуется мегакрутыми сборками для своей системы

У нас срач начинается, когда кто-то фрисвитч из исходников собирает

забыл уточнение "в продакшене"

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

имеется ввиду чатик в телеге https://t.me/ru_sysadmin )

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

вроде и пишут что то хз что но ничего толком Ж(

там флеймилка, особо нечего делать

Не подскажете решение. Есть профайл external на который приходят запросы с других серверов, контроль доступа осуществляется с помощью ACL, одноко пользователи авторизующиеся по паролю не могут делать вызовы, поисходит отказ всё по тем же спискам доступа. Как сделать что бы прямые запросы без авторизации проходили валидацию через ACL, а пользователи с паролями - нет? Или как правильно организовать подобное взаимодеййствие?

Разными профилями с разными ацл?

Предполагается что юзер может придти с любого адреса, т.е. ему вообще ацл не нужен по идее. А в одном профиле такое можно провернуть? Этот момент довольно плохо описан в доках, но как я понял такое поведение возможно, и должно работать. Ощущение что я просто что то не так делаю.

Там параметр auth-calls

По умолчанию в external он равен false

А в интернал тру

Если стоит false, то он только по acl проверяет и не посылает 407

Если стоит false, то он только по acl проверяет и не посылает 407

Спасибо, похоже оно. Доки читал, но видимо не внимательно.

Я не помню там написано это вообще или нет)

auth-calls Users in the directory can have "auth-acl" parameters applied to them so as to restrict users access to a predefined ACL or a CIDR. <param name="auth-calls" value="$${internal_auth_calls}"/> Value can be "false" to disable authentication on this profile, meaning that when calls come in the profile will *not* send an auth challenge to the caller.

А значит есть, все таки

Меня выбило первое предложение, и я видимо не стал дочитывать

А external по умолчанию похоже любые конекшены допускает, ни acl не указан, ни auth-calls

Там контекст указан, это главное)

https://geektimes.ru/post/288548/

что думаете по этому поводу, господа?

Начало так себе. Не встречал таких систем на советских атс

мой дед такие ставил

так что это не миф

так что это не миф

То есть некая система подключается ко всему коммутационном у полю и мониторит? Она аналоговая/цифровая? В какие года ставили?

Да ерунда какая-то. Деда приплели зачем-то. Как-то слабо верится что бы во времена электромеханических атс что-то могло прослушивать все разговоры... Да еще и анализировать...

Пусть дед хоть одну атс назовет...

Где ставил

Я подозреваю, что со времён "вокодера" конца 40х годов (см. "В круге первом" известного автора) наши инженеры вольерного содержания (которые за миску макарон по-флотски ядерный щит ковали) сильно продвинулись вперёд. АТС и "Дед" - вероятно речь о 70х годах.

70-80

мне 23)

ERROR: S client not available

Пусть дед хоть одну атс назовет...

дед в телеграме не сидит, я особо не спрашиваю

Ну это на самом деле больше похоже на городскую легенду, потому что и сейчас распознавание принадлежности голоса это непростая задача. Для этого требуется дофига ресурсов, и точность мягко говоря не очень. Я довольно много общался с телефонистами и все только слышали про подобное оборудование, но ни разу не видели. Да и за 30-40 лет какая то информация наверняка была бы доступна. Если дадите чуть конкретики, желательно про принцип действия, будет вообще отлично.

Всем, привет Столкнулся с проблемой. FS форкает процессы. Выявил, что во время форка залипают вызовы (show calls), а так же в /tmp появляются файлы mail.xxxxx (на фс я рассылаю письма при пропущенных звонках). Из диалплана вызывается луа скрипт через api_hangup_hook. В этом луа скрипте, в частности, вызываю freeswitch.email. Кто-нибудь сталкивался с подобной проблемой? Что подскажите/посоветуете?

БД внутренняя какая?

внутренняя, мускул

Надолго залипает?

6 дней как уже висят форкнутые процессы, 7 дней аптайма самого фс

сегодня еще один форкнутый появился

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

Можно и стрейсом

А версия какая

1.6.15 Благодарю за подсказки, буду смотреть

вы бы логи показали

Добрый день, заметил странное поведение https://freeswitch.org/jira/browse/FS-4232

Блин, не дописал

В общем при вот таком диалплане <extension name="extension1"> <condition field="caller_id_number" expression="^7[0-8]\d{9}$"/> <condition field="destination_number" expression="^\+?(7\d{10})$"> <action application="set" data="continue_on_fail=OUTGOING_CALL_BARRED"/> <action application="set" data="gateway_name=gw1"/> <action application="bridge" data="sofia/gateway/gw1/$1"/> <action application="set" data="gateway_name=gw2"/> <action application="bridge" data="sofia/gateway/gw2/$1"/> </condition> </extension> перевод на второй гейт случается не только на указанную ошибку, но и каким то случайным образом. Т.е. в ряде случаев, при завершении успешного вызова через первый гейт, начинается вызов через второй, но т.к. звонящий уже положил трубку самого вызова не происходит, условно улетает только инвайт. Я нашёл похожий баг (по ссылке выше), но он старый и закрытый, а фрисвитч у меня свежий? Кто нибудь сталкивался с подобной проблемой?

где-нибудь вылезает continue_on_fail?

надо смотреть дебаг лог фс

нужно добавить <action application="set" data="hangup_after_bridge=true"/>

собственно, оно есть в указанном выше тикете jira

нужно добавить <action application="set" data="hangup_after_bridge=true"/>

А можете объяснить почему одного continue_on_fail, ведь даже само название говорит о том что продолжение будет в случае неудачи?

вот именно что название говорит что делать при ошибке

где-нибудь вылезает continue_on_fail?

Нет, в логах просто завершается вызоов, и тут же начинается новый. Причём это не стабильное поведение, раз на раз не приходится..

а про удачу ничего не сказано

hangup_after_bridge говорить что если бридж состоялся никуда не бежать

А можете объяснить почему одного continue_on_fail, ведь даже само название говорит о том что продолжение будет в случае неудачи?

Это в случае если барред, он дальше будет бриджеваться, а не отправит барред на ногу А

Т.е. если не сетить hangup_after_bridge и continue_on_fail, а просто подряд указать два бриджа, в случае удачного вызова через первый, звонок сразу по звершению пойдёт на второй? А если первый бридж зафэйлится, то ошибка вернётся звонящему и второй бридж выполняться не будет?

Вроде да

угу