частота дескретизации?

кодек который поддерживает только passthru

кодирую в моно, 8000 Hz 8bit, wav

А ответ был до playback?

а голос точно проходит?

Многие операторы не пропускают 183 Progress от абонентов.

может вы не даете callstart

И если не ответить, то локально всё будет хорошо, а оператор голосовой трафик не пропустит.

И если не ответить, то локально всё будет хорошо, а оператор голосовой трафик не пропустит.

вот это имеете в виду? <action application="answer"/>

Да.

так работает, спасибо большое за помошь.

?

чуваки, кароч есть один фрисвитч и там делается fs_cli -x 'originate blahblah'. иногда это дело перестаёт отдавать UUID звонка и отраёт -ERR RECOVERY_ON_TIMER_EXPIRE` или -ERR NORMAL_TEMPORARY_FAILURE, хотя по факту вызов делается, в списке звонков он есть. что происходит, куда копать?

Самосбор?

originate завершается когда FS получает ответ от удаленной стороны

По событиям можно посмотреть, что происходит.

не уверен на счет 100 Trying

А также, завершается, когда тайм-ауты наступают.

События и tcpdump

А также, включить в логгировании запись uuid для звонков и смотреть, что в логах относительно этих "странных" звонков.

ога, уже включил, спасибо

Самосбор?

а вот этого не понял

Сравнить хорошие с плохими и понять разницу.

Из пакетов или make && make install ?

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

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

Тогда может быть очень разное.

А также, завершается, когда тайм-ауты наступают.

ставлю на таймаут.

у fs_cli есть параметр -t можно с ним поиграться.

или T большое

может originate_timeout

я не понимаю, что это за таймаут если вызов по факту совершается

я не понимаю, что это за таймаут если вызов по факту совершается

таймаут api

а, ок. спасибо

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

Привет всем. У меня тут набор очень странных проблем и я понятия не имею, как понять почему такое происходит. В общем. Есть сервер на диджитал оушене, у него есть плавающий айпишник и на этот плавающий айпишник зароучен траффик. Дальше на этом сервере стоит прокси - камаилио, который балансирует между двумя фрисвитчами. И я столкнулся с такими проблемами: 1. Звонки обрываются на 32 секунде с сип-ошибкой ACK Timeout. Обрыв не происходит, если я в sip_profiles/inbound.xml меняю значение <param name="timer-T1X64" value="32000" /> с 32000 на что-то гораздо большее. 2. Не работают никакие хенгапы. Если звонить с обычного телефона - хенгап до терминирующего сервера не доходит. Если хенгапить через команды фрисвитча - тоже до терминатора не доходит, что звонок оборван. Когда траффик был зароучен напрямую к фрисвитчу без камаилио, все работало. 3. И самое странное. Ребят, чей я траффик терминирую, вообще вынуждены были меня забанить. Суть в том, что с моего сервера им приходит МИЛЛИОНЫ сообщений sip 200 ok, причем с айдишниками звонков, которые давно закончены. Причем это все счастье камаилио успешно логирован и в один день у меня сервер отвалился, потому, что логи камаилио сожрали все 30 гб на сервере. Эти три вещи как-то связаны между собой и моих знаний в voip не хватает, как это все связать вместе. Честно говоря, я в отчаянии. Понятия не имею, куда копать дальше.

копайте в сторону NAT, если он у вас есть

Думаю есть, раз я использую плавающий айпишник диджитал оушена.

ноги всех трех проблем растут из одного и того же места. 1. До вас не доходит ACK пакет. По стандарту, после установления сессии (отправки 200 ОК) вторая сторона должна Вам отправить ACK пакет. Только приняв его сессия считается полностью установленной, но звук начинает работать в обе стороны раньше. Таймаут получения этого пакета по стандарту должен составлять 30 секунд. Во фрисвиче это значение установлено в 32 000 миллисекунд. Если вы его меняете на другое, то у вас все якобы работает (на самом деле, нет, работает неправильно)

По той же причине невозможно положить трубку: к Вам не доходит BYE пакет.

И по той же самой причине вас и забанили. Ваш фрисвич отправляет 200 ОК, в ответ ему сервера отправляют АСК пакет. Но поскольку эти пакеты не добираются до васшего сервера, фрисвич делает ретрансмит. Вот и миллионы ваших пакетов 200 ОК. Правда, не очень понятно, почему продолжаются ретрансмиты для давно умерших сессий, там таймаут тоже маленький, вроде как. С другой тсороны, может Ваше изменение <param name="timer-T1X64" value="32000" /> увеличило и эти таймауты тоже.

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

обратно = снаружи

с большой вероятностью все полечится

Вот я смотрю на содержимое сип-сообщений. К примеру, пусть плавающий айпишник моего сервера 138.0.0.0, айпишник самого сервера 165.0.0.0 К примеру, такое есть на терминирующем сервере. Via: SIP/2.0/UDP 165.0.0.0:5060;branch=z9hG4bKa027.959bc313df869f55fcdb103c4356aea8.0;received=138.0.0.0 Значит ли это, что он получая пакет от камаилио от плавающего айпи, пытается отправить его обратно по серверу фактическому айпи?

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

...если ему не сказать что-то другое.

На стадии установления сессии пакеты идут через прокси, но после её установления оба B2BUA общаются друг с другом в соответствии с содержимым поля contact

ща попробую картинку найти....

Честно, просто знаний не хватает, как это фиксить? Какие параметры в конфигах смотреть?

https://wiki.freeswitch.org/wiki/NAT_Traversal - копать с эту сторону?

Укажите исходящий прокси фрисвичу для начала

Параметр не помню, если честно

Ну это я найду, мне главное направление, спасибо)

А если не поможет, тогда да, tcpdump, Wireshark и указанная ссылка вам в помощь

А еще такой вопрос. У меня в диджитал оушене между серверами есть приватная сеть и траффик в ней бесплатен. Не хотелось бы гнать воип траффик через весь интернет, когда есть приватная сеть. В начале я игрался, пробывал камаилио в мод-диспатчере подсовывать приватные айпишники, но траффик до терминаторов даже не доходил, я бросил пробывать на тот момент. Что надо настроить, чтобы камаилио и фрисвитчи между собой гнали траффик через приватную сеть, какие примерно параметры?

Для начала, стоит осилить что-нибудь по теории TCP/IP Например, Олифера и Олифера. Правда, это очень поможет Вам

Не обязательно оставить всю книгу, но разделы по маршрутизацию, уровни модели OSI и принципы функционирования протоколов очень рекомендую

Кек

@stent0r , да ладно...

@stent0r , да ладно...

да. В рассылке пролетела ссыль на канал ;)

Ты уже в Испании?

Ты уже в Испании?

Я в Доминикану собирался ;) Пока в России, в Доминикане последний раз в апреле был.

Ничего, что мы тут оффтопим?

#мажорывчате

#ниразуниатвлёкси

да. В рассылке пролетела ссыль на канал ;)

какой?

какой?

freeswitch-ru@googlegroups.com

ребят кто может подсказать disconnecti time log

Иначе сформулируй вопрос, пожалуйста.

мне нужно в лог вывести connect/disconnecti time

В Master.csv это итак есть уже.

Для какого плеча нужно, если это вообще играет роль?

точно, спасибо)

app info после завершения звонка. найти нужный и использоать его

app info после завершения звонка. найти нужный и использоать его

Есть хэнгап хук, есть что-то after bridge. Но если нужна инфа с ноги которая положила трубку, то хук/бинд на хэнгап

таймаут api

дефолт - 60 секунд, как я понял, а ошибку выдаёт другую: $ fs_cli -t 1 -x 'show calls' Request timed out. $ fs_cli -T 1 -x 'show calls' [ERROR] fs_cli.c:1610 main() Error Connecting [Connection Error]

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

для теста воткни 5000

А лучше bgapi, тогда ждать не нужно будет.

А лучше bgapi, тогда ждать не нужно будет.

то есть? оно асинхронное?

Да bg = background

ну, оно асинхронное, но только в одну сторону.

что оно ответило вы никогда не узнаете

или я ошибаюсь?

Job uuid отдаёт

да, но это не uuid созданного звонка

Ждать ответа для этого задания

ответ можно получить в событии?

а тип события?

Можно получить ответ.

Да BACKGROUND_JOB

На самом деле лучше через esl делать

так а там та же история, fs_cli по сути почти чистый esl

а вот про BACKGROUND_JOB буду знать, спасиб

ну, оно асинхронное, но только в одну сторону.

Можно узнавать, но тут надо чуток изловчиться. При оригинации надо задавать значение переменной origination_uuid bgapi originate {origination_uuid=<UUID>}sofia/gateway/<gateway>/<number> &echo() И тогда в заголовках в событиях будет Caller-Unique-Id, который и примет это значение. Причем звонком можно управлять через команды uuid_*

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