Да

cdr_csv отлючен

Я бы включил на время отладки и сравнивал с ним.

точнее так, если он по дефолту стоит, то не трогал

Он есть по-умолчанию.

тогда значит он просто sqlite пишет

Он Master.csv пишет

да, тогда работает он

SQLite - это что-то другое

SQLite - это что-то другое

да немного не туда

Вот, алгоритм такой: находим в Master.csv интересующий вызов, берём его UUID и ищем по нему запись в БД. Если её нет, значит xml её туда не передал или её там не приняли по каким-то причинам.

понял, спасибо

мегафон продолжает жечь, на одном из номеров нет КПВ при входящем

через мультифон

МеГафно

мегафон продолжает жечь, на одном из номеров нет КПВ при входящем

К тебе на мультифон входящий?

К тебе на мультифон входящий?

да

МеГафно

эй, это моё слово!

на 1 из трех номеров

да

Это не Мегафон. Это ты отдаешь 183 а кпв не играешь.

на 1 из 3 номеров?

Проверь.

да, 183, потом 180

Оно вроде так не могло

йопт, теперь на обоих нет основных

я сегодня звонил - было!!

где-то что-то сковырнул что-ли

<action application="set" data="ringback=%(2000,4000,440.0,480.0)"/> всё, пусть так будет

хотя через него нормально работает remote app 1c, почта, другой части кадров телефон по туннелю

без QoS...

без QoS...

без

тоже крякнутый?

csipsimple бесплатный

csipsimple бесплатный

729

без

ну вот возможный вариант. Ваши 1с-почта канал забили.

ну вот возможный вариант. Ваши 1с-почта канал забили.

ЛТЕ))

им-то латенси не нужно

отдельный канал уже

729

оно уже бесплатно должно быть, а вообще 729 не нужен

722 возьми...

посмотрю

Добрый день.устанавливая фс для видео конференций на центоз 7.возникла проблема с mod_av i mod_vlc.при установке выдает fatal error: libavresample/avreample.h Mod_av_la-avformat.lo error Не подскажите как решить эту проблему?

А кусок лога в этом месте можно?

722 возьми...

g722 wideband, он полосу жрёт мощно

g722 wideband, он полосу жрёт мощно

зато звук норм. А настроив в outbound_codecs при звонке в мир можно pcm|gsm, а внутри 722 с хорошим качеством.

722 жрет <= относительно 711 и это при лучшем качестве

Вот, алгоритм такой: находим в Master.csv интересующий вызов, берём его UUID и ищем по нему запись в БД. Если её нет, значит xml её туда не передал или её там не приняли по каким-то причинам.

в master.csv есть такая запись, а файла записи нет. Billsec показывает 12 сек.

Т.е. механизм сохранения вызовов через xml работает некорректно.

Осталось найти, где сбой.

И ещё вариант работы системы - доставлять в БД CDR двумя путями: 1. оперативно - через перехват событий на стадии CS_REPORTING 2. периодически из Master.csv - гарантированное уточнение оперативной информации.

может этот billsec как-то некорректно отрабатывает

Тут нужно уже детально разбираться на всех стадиях передачи информации от FreeSwitch в вашу БД.

подскажите, какие по-вашему есть варианты кейса: на всех звонках стоит process_cdr=b_only проблема в том, что если звонок прерывается от limit_exeute cdr-ину мы не получаем у меня в голове только одно решение - давать от limit_execute специальный отлуп и ловить его на transfer_of_fail и там менять значение process_cdr, но может есть изящнее?

тьфу

можно же просто поставить кондишен с continue_on_fail..

хлопци

дает замечательный отлуп hangup(-ERR) возвращает 480 подробностей никаких нет

чяднт?

Тайм-аут

одинаковая ошибка на дебиане 8 с пакетами из реп и на центоси с пакетами из гита

Тайм-аут

неа...

он даже не посылает ничего

он даже не посылает ничего

Откуда явствует?

ээээээ

я это, быдло, не очень понял смысл фразы

Поподробнее происходящее опиши, пожалуйста. :-)

так

Поподробнее происходящее опиши, пожалуйста. :-)

https://pastebin.com/AJG8S5Yx

и это точно не сетевые проблемы

По сути - опрашивается редис, потом через limit_execute вызывается bridge

тьфу

тоесть и редис через limit_execute опрашивается

но с редисом то проблем нет

и это случается не постоянно, но на одних и тех же позициях

bridge {^^:absolute_codec_string=CORE_PCM_MODULE.PCMA@8000h@20i@64000b,mod_g729.G729@8000h@20i@8000b:leg_time_out=5:process_cdr=b_only}[SupplierPrefix=,CustID=292,CustServID=2,SuppID=392,SuppServID=2,DestID=12791,CustIP=SWITCH_IP_ADDRESS,CustPrefix=a30]sofia/fstest/61470326848@DESTINATION_IP)

Этот bridge?

да

Вопрос, тут данные как есть или реальные адреса заменены в целях конфиденциальности?

ну, очевидно что DESTINATION_IP/SWITCH_IP_ADDRESS не реальные адреса :)

так, апдейт

и это случается не постоянно, но на одних и тех же позициях

это не так

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

сейчас я отключу редис и посмотрим

Вопрос, тут данные как есть или реальные адреса заменены в целях конфиденциальности?

у меня нет доменов никаких, только IP-адреса если что

А sofia profile fstest siptrace on ?

Есть исх INVITE?

с инвайтом все хорошо

С исходящим от FreeSwitch(b-leg) ?

а - его нет

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

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

выключил hiredis... но даже не знаю

сейчас посмотрим результат

Плпробуй тотже самый bridge захардкодить в dialplan.

это продакшен :(

В LUA есть приколюха одна: если не выставить на сессию определённый флаг, то при завершении скрипта сессия херится. Тут подобное может быть?

дык сессия то валидно закрывается, тут проблема еще до бриджа тоесть channel b тупо не создается

0b3838cc-323b-4788-aafe-56d17f56dbf6 EXECUTE sofia/fstest1/DESTINATION_NUMBER@SWITCH_IP_ADDRESS hangup(-ERR)

Это?

дап