LINUX.ORG.RU
ФорумAdmin

sip клиенты за натом

 ,


0

2

доброго дня друзья, помогите разобраться.

Есть freeswitch сервер в интернте, есть локальная сетка за натом, включаю в этой сетки 4 ip телефона, все нормально регестрируются, делаю 2 звонка одновременно парами, звонок проходит, голос слышен в обоих направлениях, все норм, вешаю трубки, один телефон отваливается, регистрация не проходит, странно еще, что когда на него звонишь, нет сообщения number busy, просто тишина и никаких реакций, пытался снифферить трафик, при первом включении вроде все норммально натится, при повторном звонке пакеты идут от клиента через нат на сервер, от сервера возвращаются по тем же портам, но от ната к клиенту (причем к какому-то конкретному) уже пакеты не идут. в качестве ната обычный zyxel keenetic

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

по логике ведь все должно работать или я чего-то не втыкаю?

★★

Ответ на: комментарий от IvanR

Нет, на самом деле. Как работает NAT? Он форвардит ответы на запросы клиента. В данном случае соединения не происходит, а происходит, грубо говоря, отсечение пакетов NAT'ом - эквивалентно 100% потерь в одну сторону. Например, ухитрившись с маршрутизацией можно симулировать проблему на стенде. Иногда мне встречались проблемы с NAT в прошивках всяких кинетиков. Правда, укроп и дилинк грешат этим значительно чаще. Можно попробовать использовать dd-wrt - там все управляется легче (если гарантия на девайс не нужна и есть запасной такой же на случай убийства). По дефолту в кинетиках частенько встречается раннее ПО и обновления Must be done.

Deleted ()
Ответ на: комментарий от IvanR

Если «туда» уходит правильный пакет (см. транспортный уровень) - обратно возвращается ответ именно на этот пакет (т.е. соединение не закрыто) - пакет _должен_ сроутиться клиенту. В противном случае это означает, что сессия не была установлена, т.е. нужно смотреть вывод wireshark более подробно, чтобы выяснить - а есть ли установка сессии и какие конкретно пакеты высылаются. Либо фон (маловероятно, раз пакеты не идут от кинетика), либо сам кинетик.

Deleted ()
Ответ на: комментарий от Deleted

в общем стоит 1 телефон d-link, 1 linphone, 1 ekiga.

ekiga registration failed, а когда звонишь с linphone на ekiga, то звонок приходит на d-link

вот такая фигня

IvanR ★★ ()
Ответ на: комментарий от IvanR

Ёёёё... Такое ощущение, что они авторизуются одинаково, как один телефон на сервере в таком случае. Если звонок проходит - значит... Значит NAT нипричем. Смотрите содержимое пакетов при авторизации в первый и второй раз. И все же на всякий обновите прошивку кинетика.

Deleted ()
Ответ на: комментарий от Deleted

обновил уже, у меня тоже такое ощущение возникло, я позвонил с d-link на linphone и вызов принял d-link же :) может с freeswitch что-то не так, ладно, буду отлаживать

IvanR ★★ ()
Ответ на: комментарий от IvanR

Прошивки на dlink свежей/более старой нет? ИМХО, если он сам на себя звонит - варианта два: либо сервер хреново сконфигурен, либо дилинк отвечает в наглую. Есть мнение, что может помочь отделение трафика на Dlink через отдельный VLAN.

Deleted ()
Ответ на: комментарий от IvanR

Я так и понял, что телефон. Я счас не вспомню, но таковой баг уже решался с каким-то оператором SIP. Вот только с каким и где - не помню, читал об этом месяца 3 назад. Проблема в том, что протокола SIP я толком не знаю и насколько понял ту ситуацию - проблемный телефон подхватывал чужой ID и таким образом блокировал работу чужого телефона. Решалось это поддержкой от производителя. Но за точность передаваемой информации не ручаюсь.

Deleted ()
Ответ на: комментарий от Deleted

спасибо большое, протокола сип тоже не очень знаю, если это действительно так, то можно хотя бы надеяться, что сервер нормально настроен.

IvanR ★★ ()
Ответ на: комментарий от IvanR

Тьфу, про порты хрень сморозил. Еще мысль отключить всякие брандмауэры в кинетик. Больше идеи кончились, нужно видеть конфигурацию сервера, (а я с freeswitch не работал, не помогу) и знать как настроены сами телефоны.

Deleted ()

нет сообщения number busy

Я для этого в диалплан limit добавлял.

Сигнал занято, если есть исходящий.

<extension name="limit_out" continue="true">
   <condition field="source" expression="mod_sofia" >
       <action application="limit" data="hash ${domain_name} ${sip_auth_username} 1 !USER_BUSY" />
   </condition>
</extension>

Сигнал занято, если есть входящий

<extension name="local_extension" continue="true">
   <condition field="destination_number" expression="(^\d{3}$)" >
       <action application="limit" data="hash ${domain_name}  $1 1 !USER_BUSY" />
       <action application="set" data="hangup_after_bridge=true" />
       <action application="set" data="continue_on_fail=true" />
       <action application="bridge" data="user/${user_data(${destination_number}@${domain_name} attr id)}@${domain_name}" />
       <action application="answer" />
       <action application="sleep" data="1000" />
   </condition>
</extension>

nat

Попробуй указать stun сервер.

просто тишина и никаких реакций

До звонка запусти fs_cli на сервере и смотри логи.

getup ()
Последнее исправление: getup (всего исправлений: 1)
Ответ на: комментарий от Deleted

Если «туда» уходит правильный пакет (см. транспортный уровень) - обратно возвращается ответ именно на этот пакет (т.е. соединение не закрыто) - пакет _должен_ сроутиться клиенту.

В случае если в качестве транспорта выступает UDP это не совсем так. Т.к. для UDP нет понятия сессии, то NAT просто помнит в течение некоторого конфигурируемого таймаута о UDP пакете улетевшем наружу и, если прилетает ответ, форвардит его обратно.

Соответственно, если таймаут перерегистрации SIP-клиента (назовём его Ts) больше таймаута NAT-а (Tn), то дозвониться до клиента можно будет только периодами.

               Если здесь будет входящий звонок, NAT уже не
               пропустит запрос от сервера
|------------|-----------------------------------------------|
|<--- Tn --->|
|<-------------------------- Ts ---------------------------->|

Лечится настройкой таумаутов или NAT Keep Alive на клиенте.

unterwulf ()
Ответ на: комментарий от unterwulf

да это понятно, развернутый ответ, спасибо, думаю, что и tcp нат держит сесию не бесконечно долго и тоже может возникнуть проблема недоступности.

мне бы понять, почему d-link подхватил чужой аккаунт или где я допустил ошибку в настройке freeswitch

это вы в виме так нарисовали, можно поинтересоваться, чем именно рисовали?

IvanR ★★ ()
Ответ на: комментарий от IvanR

мне бы понять, почему d-link подхватил чужой аккаунт или где я допустил ошибку в настройке freeswitch

Не знаком с freeswitch. В asterisk есть команда, которая выводит информацию по всем зарегистрированным SIP peer-ам включая IP и порты. Найти бы подобное во freeswitch и там поглядеть текущие данные аккаунтов d-link и linphone, будут ли у них одинаковые порты.

это вы в виме так нарисовали, можно поинтересоваться, чем именно рисовали?

Жаль разочаровывать, но рисовал руками непосредственно в поле ввода :)

unterwulf ()
Ответ на: комментарий от unterwulf

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

Жаль разочаровывать, но рисовал руками непосредственно в поле ввода :)

эх

В asterisk есть команда, которая выводит информацию по всем зарегистрированным SIP peer-ам включая IP и порты.

как она называется в asterisk?

IvanR ★★ ()
Последнее исправление: IvanR (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.