В Oracle Linux 7 есть. Велика вероятность, что в CentOS есть.

Проверить можно.

и меня несколько смущает watch... какой функционал этих опций? И MakeDirectory - булевый

PathExists=

Выставляется директория, требуемая для запуска сервиса.

надо попробовать короче, у нас и у фс сделано через tmpfiles

Я и говорю - пробуйте.

я уже нашёл - кто-то удаляет run директорию и оно не запускается

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

Оно не создаётся изначально.

/var/run это ж tmpfs

Как я понял, оно удалялось после рестарта фс

ТЕЛЕФОННАЯ КНИГА FREESWITCH https://habrahabr.ru/post/330360/ Tags: Системное программирование, Разработка систем связи, Asterisk, Блог компании Business Infinity Group, freeswitch, ip-телефония, ip-pbx, ip-атс, voip Author binfini on #habrahabr

@igor_dm_p все, кама теперь не тренд? :)

?

сейчас же лето, не сезон, вот везде и глухо

Да не

Меня наоборот угребли все эти чатики

отвернешься уже 1000 сообщений

поудалял всё

в каме всё равно не волоку особо)

ну главное отсюда не уходи :D

нее) отсюда никуда)

SВсем доброго времени суток Есть такая проблема Телефон -> NAT -> прокси -> FS Телефон шлет INVITE на прокси. Прокси фиксит контакт хэдер. Инвайт попадает на FS. Далее все ок Когда FS отправляет BYE - он по каким то (пока что неведанным мне причинам ) отправляется на локальный IP Телефона. При этом что в INVITE, что ACK он встречается толкьо в VIA хедере, и то в параметре received указан внешний IP. То есть по всем RFC FS е должен вообще никак воспринимать этот IP

Попробуйте rport выключить на телефоне, если там можно это, а прокси пусть фиксит и via тоже

И было бы хорошо увидеть pcap обмена сообщениями.

В invite/sdp в поле connection ip что?

В invite/sdp в поле connection ip что?

В SDP все норм. Там внешний IP телефона

Попробуйте rport выключить на телефоне, если там можно это, а прокси пусть фиксит и via тоже

Прокси и так фикстит VIA)) То есть до FS долетает уже пофиксенный. Только FS это не помагает. Я конечно могу пофиксить RURI в BYE, но с точки зрения SIP - это костыль rport попробую

Т.е. в FS нигде и не в каком виде информация о "сером" IP телефона не попадает?

Ну только в вот таком: SIP/2.0/UDP 192.168.100.55:5060;received=104.192.200.101;rport=8662;branch=z9hG4bK3922007576

Это VIA

Это VIA до фиксации на прокси?

В FS Via после прокси летит уже без внутреннего IP?

в FS VIA летит вот в таком виде как я показал выше

С параметром received

Ясно. Попробуйте отключить rport на телефоне и каким-то иным способом ему передавайте его внешние координаты.

Также вопрос: телефон до этого вызова регистрируется на FS через REGISTER?

Он не регистрироуется на FS

Тогда, рекомендация про rport остаётся.

Аха. Я попробую - отпишусь сразу

Тогда, рекомендация про rport остаётся.

имеется ввиду этот параметр? <param name="NDLB-force-rport" value="safe"/>

Я имею в виду, в настройках IP телефона отключить использование rport, и задать информацию о пробросе вручную, либо понадеяться на корректную работу NAT и фиксера на стороне прокси.

Так телефон то нормально отрабатывает)) Он все шлет как нужно. С его стороны каких то проблем нет. Ест ьпроблема со стороны FS получается. Как оклчение rptort на телефоне поможет этой пролеме если FS в итоге в BYE request URI шлет на локальный IP который светится 1 раз в VIA и все?

Суть в том, чтобы исключить попадание локаьного IP адреса в FS. Если rport не будет, то прокси пофиксит все места, где увидит локальный IP и до FS везде долетит только внешний IP.

Не. Это явно не решение. Задача заставить FS обрабатывать как есть. Ведь это RFC compatable. понятно что если я везде исключу попадание локального IP то FS gпошлет пакет в нужную сторону. Это называется не решить проблему а заставить ее не появляться)) но это не продакшн. Я не смогу сказать нескльким тысачам пользователям -ребят, пробросьте как у себя порты там а то у нас FS не понимает как это обрабатывать...

И, если мне память не изменяет, то по RFC каждый прокси своё VIA добавляет вверх стэка.

Ну так он так и делает

Т.е. FS игнорирует VIA, по которому он должен отослать ответ в прокси и пытается слать его в телефон.

дампы в конце-то концов покажите до прокси и после прокси

Он игнорирует параметр received в via

+1

Прокси - это который 172.31.13.191 В INVITE будет виден его внешний IP

34.195.96.78 - FS

Call-ID: 0_2481879256@192.168.100.55 Этот?

Аха

Самое интересное что после hold/unhold (то есть после реинвайта, абсолютно идентичного инвайту кроме того что у него есть to_tag) BYE работает...

Обратите внимание на пакеты номер 79 и 80

А конкретно, заголовок Contact:

Прокси не пофиксил заголовок. Я подозреваю, что прокси это Kam в том или ином виде, а значит, что наверняка, nat helper задействуется в блоке, где условием срабатывания стоит наличие SDP. А т.к. в этом 200 OK нет SDP, то nat helper не срабатывает для этого сообщения.

Пардон, SDP есть. Но тем не менее, проблема в том, что не пофиксил прокси IP в заголовках.

Хм.. резонно. Не. Кам фиксит не по признаку SDP. но в Reply не правит .все верно

Спасибо. Я естно говоря не видел пакетов update со стороны FS

Правьте, пробуйте.

Правьте, пробуйте.

Все отлично. пасибо за исправление слепоты))

ERROR: S client not available

Обращайтесь.

Приветствую, коллеги. А кто-то задумывался/делал распределенный КЦ на FS? Который active-active?

Понимаю, что на mod_callcenter этого не сделать, просто может кто-то думал в этом направлении )

лучше реализовать всю логику своими скриптами

Приветствую, коллеги. А кто-то задумывался/делал распределенный КЦ на FS? Который active-active?

Извините, не совсем понял мысль, можете описать как Вы видите структуру "распределенный КЦ"?

Это когда стоит 2-3 железных сервера, на них крутится 1 КЦ. Однин сервер сдох по какой-то причине - остальные подхватили его звонки и состояние

Ну и нагрузка распределяется равномерно

Но это уже не задача КЦ, а какой-нить прокси перед ним

DNS - round?

Это не важно )

разпределять нагрузку можно kamailio или opensips

Давно помышляю.

подхватить звонки не получится

Нагрузку я знаю как распределить ? А вот с какой стороны кушать слона - не совсем понимаю

А задача распределения нагрузки даано решена.

подхватить звонки не получится

согласен, тут нужен явно "Round robin DNS", ну и общую базу данных для всех серверов FS

состояние, мнэ-э, надо наверное еще некая часть, которая его будет отслеживать/хранить

В смысле то ли отдельно стоящий сервер на чем-нить типа ноды или фласка, к которому по event-socket ходят фрисвичи

Почему это подхватить не получится? А 3p-cc

Получиться подхватить

Уже работает )))

+1

Уже работает )))

а как если не секрет?

sofia recover

т.е. все равно где-то надо хранить звонок?

А база на что во Фрисвиче?

Просто обмазаться скриптами - мысль, но вот все-таки без какого-то центрального места принятия решений не вижу системы

В которую будет вся информация о состоянии стекаться.

может репликацию баз сделать

Плюс, надо всякие сообщения проговаривать типа "Вы 100500й в очереди, ждите"

А база на что во Фрисвиче?

не знаю ))) я ее еще ни разу не использовал

База и так на все свичи общая будет