в исходниках есть функция switch_pgsql_available(). она возвращает true/false в записимости от того есть константа SWITCH_HAVE_PGSQL. в switch_core_sqldb.c дёргается эта функция. и если она возвращает false, то fs выводи ошибку switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_CRIT, "Failure! PGSQL NOT AVAILABLE! Can't connect to DSN %s\n", connection_options->pgsql_options.dsn);

в 1.8.0 и 1.8.1 поддержки postgres в core нет, будет в 1.8.2

Oleg будет жить. Поприветствуем!

Добрый день. Подскажите, а как прокинуть домен при ответе на 401 в username? Сейчас от fs уходит вот так Digest username="user" А нужно Digest username="user@domain"

в 1.8.0 и 1.8.1 поддержки postgres в core нет, будет в 1.8.2

кстати а когда ждать его?

в 1.8.0 и 1.8.1 поддержки postgres в core нет, будет в 1.8.2

спасибо

кстати а когда ждать его?

не знаю. думаю, не оч долго

спасибо

нзчт

Кстати с postgres в core одна бага неприятная есть https://freeswitch.org/jira/browse/FS-11395

Не так, чтобы критично, но иногда полезно

а приходится какие то танцы с бубном

Потому что главный по FS - итальянец.

Кстати с postgres в core одна бага неприятная есть https://freeswitch.org/jira/browse/FS-11395

А можно спросить в чем смысл искать по куску UUID?

Вопрос по видео звонкам, они только через браузер или через клиентские по работает?

через телефоны тоже работает

кодеки надо включить

h263 h264

например

Коллеги, приветствую. Столкнулся с проблемой: есть FS в режиме проксирования (inbound_proxy_media=true) входящий легА вызывает бридж в сторону Б. В очень редких случаях, как только от Б начинается early media, в лог пишется AUDIO RTP REPORTS ERROR: [Missing local host] и звонок разрушается с причиной incompatible destination. Звонки, которые в это время активны, не разрушаются и завершаются нормально. Кто нибудь с таким сталкивался? FS v1.8.1, Centos 7.5.1804 x86_64

А можно спросить в чем смысл искать по куску UUID?

Этот вопрос стоит задать разработчикам FS

Коллеги, приветствую. Столкнулся с проблемой: есть FS в режиме проксирования (inbound_proxy_media=true) входящий легА вызывает бридж в сторону Б. В очень редких случаях, как только от Б начинается early media, в лог пишется AUDIO RTP REPORTS ERROR: [Missing local host] и звонок разрушается с причиной incompatible destination. Звонки, которые в это время активны, не разрушаются и завершаются нормально. Кто нибудь с таким сталкивался? FS v1.8.1, Centos 7.5.1804 x86_64

SDP от 183 ответа смотреть нужно.

Коллеги, приветствую. Столкнулся с проблемой: есть FS в режиме проксирования (inbound_proxy_media=true) входящий легА вызывает бридж в сторону Б. В очень редких случаях, как только от Б начинается early media, в лог пишется AUDIO RTP REPORTS ERROR: [Missing local host] и звонок разрушается с причиной incompatible destination. Звонки, которые в это время активны, не разрушаются и завершаются нормально. Кто нибудь с таким сталкивался? FS v1.8.1, Centos 7.5.1804 x86_64

Нужен SIP дамп такого вызова.

Сигнализация у встречных узлов не всегда правильная/совместимая с локальными настройками.

SDP от 183 ответа смотреть нужно.

9cef6f26-cca0-4f84-a40d-0606ae531505 2018-09-25 16:54:17.913680 [DEBUG] sofia.c:7301 Remote SDP: 9cef6f26-cca0-4f84-a40d-0606ae531505 v=0 9cef6f26-cca0-4f84-a40d-0606ae531505 o=1111111 1537894457 1 IN IP4 b.b.b.b 9cef6f26-cca0-4f84-a40d-0606ae531505 s=SIP Call 9cef6f26-cca0-4f84-a40d-0606ae531505 c=IN IP4 b.b.b.b 9cef6f26-cca0-4f84-a40d-0606ae531505 t=0 0 9cef6f26-cca0-4f84-a40d-0606ae531505 m=audio 59354 RTP/AVP 8 101 9cef6f26-cca0-4f84-a40d-0606ae531505 a=rtpmap:8 PCMA/8000 9cef6f26-cca0-4f84-a40d-0606ae531505 a=rtpmap:101 telephone-event/8000 9cef6f26-cca0-4f84-a40d-0606ae531505 a=fmtp:101 0-15 9cef6f26-cca0-4f84-a40d-0606ae531505 a=ptime:20

А RTP точно идет в PCMA?

Сигнализация у встречных узлов не всегда правильная/совместимая с локальными настройками.

с какими например?

А RTP точно идет в PCMA?

9cef6f26-cca0-4f84-a40d-0606ae531505 m=audio 28990 RTP/AVP 8 0 18 4 101 9cef6f26-cca0-4f84-a40d-0606ae531505 a=rtpmap:8 PCMA/8000 9cef6f26-cca0-4f84-a40d-0606ae531505 a=rtpmap:0 PCMU/8000 9cef6f26-cca0-4f84-a40d-0606ae531505 a=rtpmap:18 G729/8000 9cef6f26-cca0-4f84-a40d-0606ae531505 a=fmtp:18 annexb=no 9cef6f26-cca0-4f84-a40d-0606ae531505 a=rtpmap:101 telephone-event/8000 9cef6f26-cca0-4f84-a40d-0606ae531505 a=fmtp:101 0-15

в смысле Б может игнорить список и слать что-то своё?

По SDP я не пойму этого ? Это нужно смотреть на сам поток

По SDP я не пойму этого ? Это нужно смотреть на сам поток

Я уже понял, что дампа не избежать) Но разве такая ситуация вообще возможна?

Я уже понял, что дампа не избежать) Но разве такая ситуация вообще возможна?

а почему нет? )

А протокол?

а почему нет? )

Или я слишком наивен и срать все на него хотели? Прошу 711 и 729, а мне летит 723)

Или я слишком наивен и срать все на него хотели? Прошу 711 и 729, а мне летит 723)

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

OK, дампу быть

Ребят, кто использует fusion, вы логотипы своих компаний вешали на него?

da

это типа разрешено?)

у нас для внутреннего использования.

ну а так, в принципе думаю что да, там же наверняка гнугпл

так сказать,свой болдженос

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

На ютубе есть видео где у людей вообще все изменено, лого, шапка, цвета...

ну и опять же, если вы в России то точно пофиг

Владимир будет жить. Поприветствуем!

Всем привет! поймал интересную проблему. REGISTER: <client> ---> <proxy (add PATH)> ---> <fs PBX> tls 1.1 tcp 1.2 INVITE: <proxy> <-x- <fs PBX> <--- client2 2.2 2.1 На этапе 2.2 фрисвич ругается, что профиль не поддерживает TLS (хотя по логике здесь должен использоваться транспорт TCP)

Пояснения: регистер прилетает поверх TLS на прокси, где в него добавляется PATH, после чего он отправляется на фрисвич.

>(хотя по логике здесь должен использоваться транспорт TCP) зависит от того что было в REGISTER запросе

почему??? есть же PATH, в котором указан протокол

и он конкретный: TCP

ну мы только телепатически можем узнать, вы же не показали сигнализацию)

простите, не успел. В общем, у меня есть вот такая строчка в БД регистраций фрисвича: sofia/internal/sip:1.1001@87.250.248.204:49845;transport=TLS;ob;fs_path=sip:[2A02:6B8:0:2012:92E2:BAFF:FEC1:1124]:5600;transport=tcp;lr

и фрисвич при попытке набрать на эитого пользователя говорит, что у него не порддерживается TLS в профиле (хотя он должен идти по tcp)

я смотрю на строчку и понимаю, что видимо это баг БД регистрации и понимаю, как это исправить, но... может кто-то уже решал такую проблему и она фиксится без исправления исходников?

нужно еще проверить что в register не было схемы sips

в контакте

нет, не было

потому что когда UA использует схему sips, он желает чтобы всё что по дороге было с tls

нет, не было

тогда похоже на багу или какое то хитрое поведение

похоже на багу, да :( вот и вопрос, как обойти...

точнее: сталкивался ли многоуважаемый All и обходил ли данную проблему?

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

не исключено что он просто смотрит на URI 1001@87.250.248.204:49845;transport=TLS и решает что без tls никак не обойтись

так все и началось с того, что tls был включен и я не видел части пакетов в звонке

причем эти пакеты шли на адрес и порт из fs_path но с использованием протокола tls, указанного в Contact

какой-то трэш

причем эти пакеты шли на адрес и порт из fs_path но с использованием протокола tls, указанного в Contact

Это баг. Видимо обработка контакта в коде происходит раньше чем обработка path

русский язык для fusion так и остался в мастер ветке?

русский язык для fusion так и остался в мастер ветке?

хз не отслеживал. зарелизилось хоть раз за почти полтора года?

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

в описании версии 4.4 есть Added more language translations. Russian, Italian, German, Austrian, Turkish. Интересно, куда added)

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

а то показывает активного

стоит профиль default

дописал в него <param name="video-mode" value="mux"/> <param name="video-layout-name" value="2x2"/>

Никто не подскажет?

Там другие прсмотрите профили как примеры

Добрый день! Кто может настроить регистрацию FS <=> Asterisk и звонки ?

FS у провайдера регистрируется а на Asterisk нет

... если сможете, напишите "сколько будет стоить"

... если сможете, напишите "сколько будет стоить"

50 евро за час кратно 15 минут. Займет от 15 минут до часа. Но сначала надо поглядеть

FreeSWITCH 1.8.2 is out!

тут кто-то интересовался прост

тут кто-то интересовался прост

Я) спасибо. Буду тестить

Приветствую товарищей Voip'еров. Описание: FS запущен в docker контейнере, подключены GSM шлюз подключеный к АТС через тунель и SIP trunk с провайдером настроеный Peer to Peer на прямую без регистрации по белым ip. Операторы обрабатывают звонки по WebRTC, трафик зашифрованный, подключены по белому ip к АТС. Проблема: Про входящей/исходящей связи через GSM все работает нормально. При вхоядей связи через SIP trunk тоже все хорошо, но как только я делаю исходящую через SIP trunk на мобильные номера оператора у которого беру транк, начинаются проблемы со слышимостью. А именно только операторы на короткие промежутки времени 2-4 секунды перестают слышать тому кому звонят. Проблема не постоянна, 1 из трех звонков проблемный. Проблемы со слышимостью происходят от 1 до 3 раз во время разговора. Что проверял: Пытался снять дамп трафика, но не удачно так как я не могу увидить что происходит в разговоре из за шифрованного трафика Смотрел сеть внутри офиса оператров, грешил на их сеть локальную, но тут вопрос почему тогда у шлюза не происходит этих проблем. Кодек используется везде один uLaw. Тестировал звонки у себя локально в офисе отличном от операторов, проблемы не нашел, но возможно из за того что я не могу постоянно звонить не факт что звонок у меня будет проблемный. Подскажите что я мог упустить, и какие еще есть варианты для выявления причины проблемы?

Приветствую товарищей Voip'еров. Описание: FS запущен в docker контейнере, подключены GSM шлюз подключеный к АТС через тунель и SIP trunk с провайдером настроеный Peer to Peer на прямую без регистрации по белым ip. Операторы обрабатывают звонки по WebRTC, трафик зашифрованный, подключены по белому ip к АТС. Проблема: Про входящей/исходящей связи через GSM все работает нормально. При вхоядей связи через SIP trunk тоже все хорошо, но как только я делаю исходящую через SIP trunk на мобильные номера оператора у которого беру транк, начинаются проблемы со слышимостью. А именно только операторы на короткие промежутки времени 2-4 секунды перестают слышать тому кому звонят. Проблема не постоянна, 1 из трех звонков проблемный. Проблемы со слышимостью происходят от 1 до 3 раз во время разговора. Что проверял: Пытался снять дамп трафика, но не удачно так как я не могу увидить что происходит в разговоре из за шифрованного трафика Смотрел сеть внутри офиса оператров, грешил на их сеть локальную, но тут вопрос почему тогда у шлюза не происходит этих проблем. Кодек используется везде один uLaw. Тестировал звонки у себя локально в офисе отличном от операторов, проблемы не нашел, но возможно из за того что я не могу постоянно звонить не факт что звонок у меня будет проблемный. Подскажите что я мог упустить, и какие еще есть варианты для выявления причины проблемы?

Ptp кратковременно отваливается или загружен под завязку периодически, причем в сторону к вам, или вы попадаете в промежутки, когда загружается локалка в сторону операторов. Обычно, при загрузке канала бывает как полное пропадание голоса, на секунду, две, но не 3-4, так и искажение с заиканием.

Этот момент я исключил настроив QoS для трафика с АТС, сейчас еще думаю сделать тунель от компа оператора до АТС на примере GSM шлюза.

ptp только у GSM шлюза

и еще проблема наблюдается только при исходящих звонках только через trunk с провайдером

и SIP trunk с провайдером настроеный PtP. вот же вы написали)

Понял, ввел в заблуждение имел ввиду peer to peer без регистрации на сторне провайдера

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

с провом через Публичную сеть работаете? В качестве nat что используете?

FreeSWITCH 1.8.2 is out!

Там в основном пакетами интересовались, чтобы без лишних танцев с odbc Fusion подтянуть.

пакеты в репе

Котаны, а не знаете, в последних версиях фрисвича как дела обстоят с луа в плане нагрузки? Починили что фс морозится целиком когда луа думает?