asterisk.ru

Всем привет,

Есть три FreeSWITCH.
К двум из них клиенты цепляются через TLS, через третий ходят в город по чистому SIP.
Обозначения: FreeSWITCH с TLS -1 и 3, FreeSWITCH без TLS -2.
Между всеми серверами трафик идет в чистом SIP.
На серверах 1 и 3 есть по три SIP-профиля. internal - с TLS и server1, server2 - только SIP.

Проблема в том, что при одинаковых настройках вызовы с 2 на 3 проходит, а на 1 - получаем "Crypto not negotiated but required" и 488 c INCOMPATIBLE_DESTINATION.
Тоже самое происходит при вызове с 3 на 1.
Оба без проблем могут звонить в город через 2.
Внутри серверов 1 и 3 по TLS клиенты общаются без проблем.
С сервера 1 на 3 - тоже.
Если отключить шифрование - вызов проходит.
Если отключить транскодинг, ругается на несовпадения кодеков. Причем вызываемый телефон даже звонит, но вызов сбрасывается с ошибкой 415 и руганью в логе на несовпадение кодеков.

Вопрос для начала - в каких случаях возникает "Crypto not negotiated but required" и 488 c INCOMPATIBLE_DESTINATION?

P.S. Отличия конечно есть - на сервер 1 я водрузил FusionPBX, долго плевался и по факту отключил все, кроме управления экстеншинами.
SIP-профили идентичные, диалпланы упрощены до минимума и совпадают.
Логи абсолютно неинформативные... Типа нижеприведенного.
Такое впечатление, что 488 возвращает сам FreeSWITCH сразу после поступления звонка еще до маршрутизации.
Если отключить транскодинг (disable-transcoding в true), то вызов маршрутизируется, но не проходит из-за несовпадения кодеков (которые по факту совпадают!).

Лог:

Код: Выделить всё

2016-05-04 23:49:48.052537 [DEBUG] sofia.c:6760 Channel sofia/server/NUMBER@1.2.3.4 entering state [received][100]
2016-05-04 23:49:48.052537 [DEBUG] sofia.c:6770 Remote SDP:
v=0
o=pbx 1462385059 1462385060 IN IP4 1.2.3.4
s=pbx
c=IN IP4 1.2.3.4
t=0 0
m=audio 20712 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

2016-05-04 23:49:48.052537 [DEBUG] switch_core_media.c:4161 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1]
2016-05-04 23:49:48.052537 [DEBUG] switch_core_media.c:4216 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match
2016-05-04 23:49:48.052537 [DEBUG] switch_core_media.c:4161 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMU:0:8000:20:64000:1]
2016-05-04 23:49:48.052537 [DEBUG] switch_core_media.c:4161 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[G722:9:8000:20:64000:1]
2016-05-04 23:49:48.052537 [DEBUG] switch_core_media.c:4161 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[GSM:3:8000:20:13200:1]
2016-05-04 23:49:48.052537 [DEBUG] switch_core_media.c:4077 Set telephone-event payload to 101@8000
2016-05-04 23:49:48.052537 [WARNING] switch_core_media.c:4234 Crypto not negotiated but required.
2016-05-04 23:49:48.052537 [DEBUG] switch_core_media.c:4485 sofia/server/NUMBER@1.2.3.4 Set 2833 dtmf send payload to 101 recv payload to 101
2016-05-04 23:49:48.052537 [NOTICE] sofia.c:7204 Hangup sofia/server/NUMBER@1.2.3.4 [CS_NEW] [INCOMPATIBLE_DESTINATION]

копайте в сторону переменной rtp_secure_media

Да, так пишут, только она вообще никак не влияет в данном случае.
Пробовал с ней играться и на оригинирующем, и на терминирующем серверах - с нулевым эффектом.

играться надо там где идет переход SIP > TLS

Переход SIP > TLS идет на серверах 1 и 3.
Вызов получаю, но такое впечатление, что дальше SIP-профиля он не уходит - в контекст он попросту не попадает и не маршрутизируется.
Делал фейковый экстеншин с эхотестом - получаю ту же 488, хотя если звонить внутри серверов 1 и 3 на эхотест все работает с шифрованием.
Пока не въехал как нормально отдебажить данную ситуацию.
В SIP trace на FS вижу получение INVITE, ответ Trying и сразу 488.
Игрался rtp_secure_media внутри профиля - никакого толку нет.

Есть мысль грохнуть сервер 1 (снести нафиг FusionPBX) и поставить голый FreeSWITCH. Может FusionPBX куда-нибудь что-нибудь понатыкало, что я найти глазами не могу.

Диагностика проблем на FS не очень хорошая. По крайней мере я в нее еще не до конца въехал...

выставляется в случае когда нужно SRTP на определенной ноге

вот так в User Directory

Код: Выделить всё

<param name="dial-string" value="{rtp_secure_media=${regex(${sofia_contact(*/${dialed_user})}|transport=tls)},presence_id=*/${dialed_user}@${dialed_domain}}${sofia_contact(*/${dialed_user})}"/>

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

есть вариации rtp_secure_media_inbound и rtp_secure_media_outbound

отменить на определенной ноге в bridge

If you would like to have variables in [] override the same variables set in {}, you may set 'local_var_clobber=true' inside {}. For example:
{local_var_clobber=true,rtp_secure_media=true}sofia/default/blah1@baz.com|sofia/default/johndoe@example.com|[rtp_secure_media=false]sofia/default/janedoe@acme.com

С dial-string игрался, не помогает.
Дело в том, что я делал на экстеншине эхо-тест и до него даже не доходит, т.е. до User Directory просто не доходит дело.
Хотя если dial-string убрать, то ругается, что его нет (при вызове пользователя).
Отладка в данном случае совсем никакая.
За переменные по отдельным легам - спасибо, не знал, в документации чего-то и не видел даже (или проглядел).

Но главное - почему на сервере 3 с теми же настройками все работает, а на сервере 1 - нет?!!
Диалпланы идентичны, но есть различия в User Directory - на сервере 1 они формируются с помощью lua и я даже не знаю какие они - на диск они не сбрасываются, поэтому и хочу снести нафиг FusionPBX и оставить голый FS.

Вопрос закрыт, проблема решена.
Решение простое - снес нафиг FusionPBX и настроил все с нуля руками - все заработало тут же.
Рекомендую - не ставьте это убожество FusionPBX!!!!!

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

Диалплан у меня был выключен - я ж писал, что в FusionPBX у меня был включена работа только с экстеншинами.
Вероятно в directory он не то что-то формировал, а на диск ничего не сбрасывал.
Голый FreeSWITCH мне проще настраивать, как и asterisk. Все эти морды имеют часто странную логику.

asterisk.ru

FreeSWITCH + TLS

FreeSWITCH + TLS

Re: FreeSWITCH + TLS

Re: FreeSWITCH + TLS

Re: FreeSWITCH + TLS

Re: FreeSWITCH + TLS

Re: FreeSWITCH + TLS

Re: FreeSWITCH + TLS

Re: FreeSWITCH + TLS

Re: FreeSWITCH + TLS

Re: FreeSWITCH + TLS