https://habrahabr.ru/post/209446/ > Есть ли какое-нибудь движение, или процесс совсем завис?

ps -e -o pid,comm,wchan=WIDE-WCHAN-COLUMN | grep freeswitch 23594 freeswitch poll_schedule_timeout # strace -p 23594 Process 23594 attached select(0, NULL, NULL, NULL, {0, 836422}) = 0 (Timeout) select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) ...

и если цепануться к случайному треду # strace -p 8064 Process 8064 attached futex(0x7f860a81f89c, FUTEX_WAIT_PRIVATE, 212, NULL

А что за скрипт и кто инициирует звонок?

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

Насколько я знаю, единственный способ сохранять, что там вообще происходит - только через есл. Можно попробовать запускать fs_cli и все в файл сохранять. Либо написать скрипт который работает через esl и пишет все события куда-то.

https://github.com/moteus/lua-lluv-esl/blob/master/examples/originate.lua

Получилось как-то сложновато :)

Borik блин, я со своей проблемой ACK Timeout просто в отчаянии. Я уже столько всего перепробовал, и ext-sip-ip менять, и advertised_address в камаилио указывать, настраивать outbound-proxy во фри-свитче. https://pastebin.com/x0CL3TEZ - конфиг камаилио https://pastebin.com/wyT3cBbD - дамп сообщений на сервере с камаилио https://pastebin.com/zPysfQkV - логи с консоли фрисвитча. Вот тут я вижу какой-то треш вообще происходит: nta.c:7188 _nta_incoming_timer() nta_incoming_timer: 1/1 resent, 0/1 tout, 0/0 term, 0/1 free nta.c:1296 agent_timer() nta: timer set next to 493 ms nta.c:7105 _nta_incoming_timer() nta: timer H fired, timeout and terminate 200 response nua_session.c:2569 process_ack_or_cancel() nua: process_ack_or_cancel: entering nua_stack.c:271 nua_stack_event() nua(0x7f2f48004c80): event i_error 408 ACK Timeout nua_params.c:480 nua_stack_set_params() nua: nua_stack_set_params: entering soa.c:1784 soa_terminate() soa_terminate(static::0x7f2f48005530) called soa.c:1302 soa_init_offer_answer() soa_init_offer_answer(static::0x7f2f48005530) called nta.c:2665 nta_tpn_by_url() nta: selecting scheme sip tport.c:3257 tport_tsend() tport_tsend(0x7f2f480086c0) tpn = */138.197.49.44:5060 tport.c:4046 tport_resolve() tport_resolve addrinfo = 138.197.49.44:5060 tport.c:4680 tport_by_addrinfo() tport_by_addrinfo(0x7f2f480086c0): not found by name */138.197.49.44:5060 tport.c:3594 tport_vsend() tport_vsend(0x7f2f480086c0): 763 bytes of 763 to udp/138.197.49.44:5060 tport.c:3492 tport_send_msg() tport_vsend returned 763 send 763 bytes to udp/[138.197.49.44]:5060 at 14:15:33.607775 not found by name */138.197.49.44:5060 - я уже и пропинговывал удп порт через nping, он доступен.

Лучше б снял на пограничной машине дамп и посмотрел, приходят пакеты реально или нет.

Не могу понять, от кого к чему не доходит ACK, от камаилио к фрисвитчу или от фрисвитчу к камаилио

сними дампы на каждом и посмотри, где они есть, а где нету

Тот кто шлет 200 OK должен получить ACK

Там у меня есть дампы на пастебине выше ссылки

дамп сетевого трафика в формате .pcap туда не положишь, это бинарный файл

...по-моему не положишь

снимите дамп в .pcap и посмотрите wireshark`ом

Если оба плеча через камаилио то K: send invite (inbound) F: send trying (inbound) F: send invite (outbound) K: send trying (outbound) далее несколько 1хх K: send 200 OK (outbound) - сняли трубку F: send ACK ( outbound) F: send 200 OK (inbound) K: send ACK (inbound)

там все сильно понятнее

А что это за странный айпишник 10.17.0.9:5060 берется у камалио и он еще с ним шлет какие-то сообщения? Причем на фрисвитче он появляется в заголовке Record-Route: <sip:10.17.0.9;lr=on>.

Это внутренний, "серый" адрес.

Блин, чувак сразу прохавал мою проблему - https://lists.kamailio.org/pipermail/sr-users/2017-September/098450.html Работает!!

что странно, чувак сказал тебе то, что ты якобы уже делал ;)

Та я понятия не имел про айпишник 10.17.0.9:5060 :) Я и сейчас не представляю откуда он и зачем он нужен. Я просто в администрировании и сетях такое, не очень, никогда ними особенно не занимался, а сейчас пилю проект и приходится во все это параллельно вникать.

Блин, а еще я даже хз как ответить на письмо в рассылке, впервые в жизни писал в почтовую рассылку, мне всегда это казалось какой-то архаикой канувшей в лету)

Ответить как на обычное письмо, тока кажется гмыл по-дефолту отвечает одному вместо всех. Надо убедиться, что пишешь на адрес списка рассылки. В Thunderbird прямо кнопичка специальная есть для ответа в рассылку. Рассылки дуже полезная штука, кладезь всяких интересностей и полезностей :)

@nevian та да, взялся за этот сип, фрисвитч, камаилио, информации просто катастрофически мало, все приходится по таким крупинкам собирать.

Опыт

Мне в своё время казалось, что у FS довольно подробная документация

У меня противоположное впечатление - столько всего, не понятно за что хвататься :) И опыт решает конечно.

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

Мне, кстати, так и непонятно. Откуда камаилио берет такой айпишник 10.17.0.9 и почему ему надо слушать именно его? Где об этом можно почитать?

А никто не знает нормальный софтфон? Дело в том, что при попытке звонить через XLite, провайдер обрывает звонок по причине того, что в CallerID XLite пихает просто четыре ноля, тогда как провайдеру нужен полноценный номер и я не могу найти, как заставить XLite использовать нужный мне номер для CLI. Линфон - вообще поехавший, у меня юзернейм от сип провайдера в формате namе@domain.com, который линфон категорически не принимает.

3CX

А точно xlite поставляет 0000 ? Обычно такое значение по умолчанию поставляет как раз таки FreeSWITCH при originate

@kvishnivetsky сейчас попробую, спасибо

Ну и Bria купленный тоже хорош.

Borik да, точно, я им звонил в техподдержку, они мне отвечали, что неправильный cli. Во фрисвитче при оригинации я устанавливаю переменную origination_caller_id_number

Пользую eyebeam, который ныне bria старой версии, на неё ключик можно найти на ru-board

А в шлюзе проставлено "не экранировать"?

А где это можно посмотреть?

Это в параметрах самого шлюза. <param name="caller-id-in-from" value="true"/>

А, я подумал за икслайт. Да, в гейтвее у меня есть этот параметр. С фрисвитчем все пока вроде ок

Т.е. 100% на сам FreeSwitch приходит неправильный callerId? Прям, в трафике видно?

Если в фрисвитче не указывать caller id number, оно тоже подсовывает 0000, а сервер отвечает 4хх какой-то ошибкой с Forbidden CLI

И тогда вопрос: если FreeSwitch между софтофоном и провайдером, то он должен переписывать, а он этого не делает?

Не, не, у меня есть терминирующий сервер, на него зароучены некоторые номера. Я просто через воип-провайдера звоню на эти номера.

Попунктно опиши прохождение вызова с указанием задействованных узлов, пожалуйста.

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

Одну сек

Итак, у меня есть саплаер номеров, при звонке на этот номер, они роутят траффик на мой ip. Я могу звонить на эти номера любым доступным мне образом, например сейчас хочу через voip-провайдера. А voip провайдер просто требует, чтобы CLI был полноценным номером телефона, причем неважно каким. И XLite просто подсовывает четыре ноля вместо номера, из-за чего провайдер обрывает звонок. Мой терминирующий сервер вообще к этому не имеет никакого отношеия.

Теперь ясно. Проблема в связке: xlite --- TISP

Да :)

Нужен софтфон, любой, который не будет умничать и вместо меня захардкоженный caller id выставлять

Тогда нужно досконально настройки поофиля изучить. Или сменить софт-фон.

Попробуйте phonerlite простой как 2 копейки

В конфигурации поиграетесь с настройкой caller id

@levtrunov спасибо большое, эта штука заработала, только в caller id пропихивает слово anonymous, но мой провайдер схавывает это. Только другая проблема - нет звука. Прошу коллегу с настоящего телефона позвонить - звук есть, файл проигрывается.

В настройках можно выбрать устройство вывода

Вместо anonymous можно прописать номер

NAT

как еа kinksys pap включить ожидание вызова я инструкцию потерял

так я это я нашел и включил

Даже не знал о его сузествовании до сеоо момента)

А кому вы собираетесь раздавать zrtp? И кто будет нажимать эти кнопочки с кодом в начале беседы с новым собеседником? Ставьте уж sip over tls, srtp и пользуйтесь, оно по крайней мере работает

По всей видимости вы используете астериск)

Мамонты вымрут)

И будет счастие)

По всей видимости вы используете астериск)

Я не понял смысла вами сказанного. Вы zrtp вообще пользовались? Тут проблема с клиентами, и особенно с теми, что на мобильниках

Эм

Я использую фс

Все срвременные устройста и софт умеют из коробки

Странный выбор на фс tls +srtp

Зачем велосипедить

Когда можно использовать современные решения

Как минимум экспертами zrtp признается более надежным решением в области безопасности

Когда можно использовать современные решения

Вам zrtp по всей видимости нужен для некоей как бы конфиденциальности. При этом, думаю вы в курсе, что он закрывает только RTP, а обмен по SIP остаётся открытым для всех. То есть, TLS и сертификаты нужны

Эм, обязательно перечитаю, но как бы фишка zrtp что не нужно дополнительно tls для sip

Не нужно.

Так

В чем спор то?)

То что zrtp нет где юзать, боюсь уже не так

Подслушать, что сказал Вася Пете не получится. А установить факт звонка именно между ними - получится

Не

Это srtp

Без tls

Zrtp же он и транспорт и системные мессаки шифрует

Zrtp более продвинутая ветка srtp + tls

Продвинутая в том что включается 2мя строками конфига

Нет, zrtp закроет только медиапоток

Invite и прочее пойдёт открыто

Уже не сегодня, обязательно перечитаю

всем привет, доставляющий массу счастья и удовольствия глюк словили Вобщем карячили мы тут параметры профиля по части tls, покарячили и забыли вобщем то, tls отключили, в профиле ничего не биндится на tlsный порт, вроде бы по логике вещей все должно быть хорошо и мирно. Так было до тех пор пока мы не начали прозванивать внутрянку и тихо приходить в ужас от происходящего. Абонент А вызовает абонента Б, от А к ФС приходит трафик, от ФС к Б трафик не приходит, вызов отбивается с 503 ошибкой. Трафика нет от слова совсем, повключали все дебаги начали всё это дело анализировать, первое что смутило что после перевода на TCP всё взлетело. В дебаге полезла вот такая хрень: tport.c:4160 tport_pend() tport_pend(0x7f619c023620): pending 0x7f619c023270 for tcp/192.168.хх.хх:5066 (already 0) Казалось бы ничего необычного, но клиент зареган по UDP и соответственно ждет трафик на UDP порту 5066. Дальше начали выпиливать по очереди TLSные параметры и перезапукать профиль, при всём при этом в профиле параметр tls=false. До тех пор пока не убрали tls-certs-dir трафик генерировался в TCP. Это грустная история о потерянном времени, решил поделиться, мало ли кому пригодится

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

проверено debian 8, 9 FS - 1.6, 1.8, 1.9, глюк везде присутствует

господа есть ли номер 8800 где никто трубку не возьмёт?нужно для тестов мегафона он неадекватно себя ведет . это прямо засада только дебаг логи выключаешь сразу проблема

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

Rfc не требует использовать один протокол для регистрации и звонка. Если клиент хочет специальный протокол он должен добавить transport параметр в запросе на регистрацию В фс можно настроить какой протокол использовать по умолчанию если такого параметра нет. Но связывать протокол регтстрации и протокол звонка это не по rfc

Это понятно, но в транспорте стоит только udp, в том то и дело

В багрепорт напишите