У стороннего SIP-провайдера дозвон работает, а входящие вызовы не проходят.

У стороннего SIP-провайдера дозвон работает, а входящие вызовы не проходят., UniFi Talk

Alanbaker

Guest

27.02.2025 22:02:00

Настраиваю впервые. Пока можем только звонить. Схема настройки на скриншоте. Попробовал TCPDUMP, показывает: 21:41:09.976757 ppp0 In IP providers.ip.5060 > my.wan.ip.5060: SIP: INVITE sip:external.phone.number@my.wan.ip:5060 SIP/2.0. Перенаправление портов направлено на IP DMP на 5060 UDP. Использовал fs_cli для просмотра логов, но там нет никаких сообщений о входящем звонке. Какие есть идеи или нужна дополнительная информация?

rozhasi

Guest

14.03.2025 02:37:00

Попробовали ли вы спросить своего SIP-провайдера, чтобы он разрешил вам использовать порт 5061 на вашей стороне? Они, наверное, смогут это сделать. Если они позволят, система заработает. И ещё, спрашивали ли вы у Ubiquiti, почему они не разрешают назначать порт 5060 сторонним SIP-провайдерам? Конфликта с Twilio нет, потому что порт может быть одинаковым для приема SIP-трафика от нескольких провайдеров.

Alanbaker

Guest

13.03.2025 18:00:00

Я обратился в Unifi насчет изменения исходящего порта обратно на 5060 и получил такой ответ:-

Поэтому я сейчас строю систему FreePBX, и она продвигается неплохо, но требует много настроек! Что касается моего телефона Unifi Touch, то он подключается к FreePBX как расширение, и я настроил стороннее расширение, как мы обсуждали в этой записи.

В итоге, если ваш SIP-провайдер аутентифицируется по вашему IP-адресу и требует отправку и прием на порту 5060, и вы используете PPPoE, Unifi Talk вам не подойдет на данный момент.

Alanbaker Guest	#4 07.03.2025 18:22:00 Пытаюсь, но пока не выходит… Реально ли вообще можно изменить номер исходящего порта?

rozhasi Guest	#5 07.03.2025 12:17:00 SNAT

Alanbaker

Guest

07.03.2025 09:49:00

Я перепробовал несколько конфигураций, безрезультатно. Было бы гораздо проще, если бы мы могли использовать 5060 в качестве SSP, кажется, он зарезервирован для Twillio, но мы должны иметь возможность его переопределить! Теперь нужна переадресация портов из локальной сети в WAN, кажется, что-то в DNAT должно это решить?

rozhasi

Guest

05.03.2025 14:56:00

Вот что я получаю, когда выполняю команду: fs_cli -x "sofia status"
=================================================================================================
Имя Тип Данные Состояние
=================================================================================================
external_talk::54.172.60.3 sip:FreeSWITCH@54.172.60.3:5060 NOREG 80.76 0/0 0/0
external_talk::54.172.60.2 sip:FreeSWITCH@54.172.60.2:5060 NOREG 67.57 0/0 0/0
external_talk::54.172.60.1 sip:FreeSWITCH@54.172.60.1:5060 NOREG 71.91 0/0 0/0
external_talk::54.172.60.0 sip:FreeSWITCH@54.172.60.0:5060 NOREG 66.53 0/0 0/0
external_talk::CallCentricext.141 sip:17771234567@callcentric.com REGISTER 0.00 0/0 0/0
external_talk::Talk sip:wwWLdSg1sKvS@982b5c7677b1a1d6f3201eed.pstn.us1.twilio.com NOREG 69.31 0/0 0/0
=================================================================================================
6 шлюзов: Входящие (Неуспешные/Всего): 0/0, Исходящие (Неуспешные/Всего): 0/0
Обратите внимание на эту строку: external_talk::CallCentricext.141 sip:17771234567@callcentric.com REGISTER 0.00 0/0 0/0
Опять же, это показывает, что UniFi Talk зарегистрирован у моего SIP-провайдера, CallCentric
Из вашего вывода очевидно, что UniFi Talk не зарегистрирован у вашего SIP-провайдера, EnReach
Вам следует устранять неполадки с регистрацией между UniFi Talk и вашим SIP-провайдером. Что-то, что вы настроили в полях конфигурации сторонних приложений для вашего SIP-провайдера, неверно. Запустите SIP-трейс из FreeSwitch CLI или из графического интерфейса UniFi Talk и просмотрите SIP Register сообщения и ответы вашего SIP-провайдера. Обратитесь в службу технической поддержки вашего SIP-провайдера, чтобы помочь вам правильно зарегистрировать UniFi Talk в их сервисе.

rozhasi

Guest

06.03.2025 17:07:00

Итак, правило переадресации порта должно переводить номер порта источника исходящего трафика с 5061 на 5060. Проблема в том, что UniFi Talk генерирует SIP ACK для SIP-провайдера на SIP-прокси, используя IP-адрес порта WAN, но ваше правило переадресации порта не перехватывает этот трафик (чтобы перевести порт источника с 5061 на 5060), потому что оно ищет трафик, исходящий из вашего сетевого интерфейса по умолчанию (ваш LAN). SIP-прокси вашего SIP-провайдера ожидает SIP ACK с вашего WAN IP на порту 5060, но получает его с вашего WAN IP на порту 5061. Поэтому SIP-прокси вашего SIP-провайдера игнорирует ACK, приходящий с вашего WAN IP. Попробуйте изменить правило переадресации порта, чтобы сохранить IP-адрес назначения (от WAN к WAN IP) и переводить только порт назначения (с 5060 на 5061). Ваша существующая политика брандмауэра, которую вы создали, должна уже работать, так как вы указали IP-адрес назначения как Any. Тем не менее, я бы сузил ее, указав IP-адрес назначения в политике брандмауэра как ваш WAN-интерфейс.

Alanbaker

Guest

06.03.2025 15:26:00

Я начал строить систему и тестировать. Думаю, ваши опасения уже подтвердились. Входящие вызовы обрываются через 30 секунд. ACK, отправляемые на PBX, как будто отвечают на порту 5061, а не на 5060. Вот TCPDUMP15:01:31.131446 ppp0 In IP 151.provider.5060 > 80.my.wan.5061: SIP: ACK sip:01phone number@80.my wan:5061;transport=udp SIP/2.015:01:31.131517 ppp0 Out IP 80.my.wan > 151.provider: ICMP 80.my.wan udp port 5061 unreachable, length 373

rozhasi

Guest

#10

06.03.2025 13:43:00

Так, в твоем правиле переадресации портов ты использовал IP-адрес, назначенный сети по умолчанию твоего UDMP, что по сути является интерфейсом LAN на твоем UDMP. Я собирался предложить сделать именно так, но потом подумал дважды и решил предложить другое.

Мои сомнения были связаны с тем, что когда ты совершаешь исходящий звонок с твоего телефона Talk, приложение UniFi Talk использует IP-адрес, привязанный к твоему интерфейсу WAN, чтобы общаться с твоим SIP-провайдером. Однако, когда твое приложение UniFi Talk получает входящий звонок от твоего SIP-провайдера, твое правило переадресации портов отправляет звонок на IP-адрес, назначенный твоей сети по умолчанию (это внутренняя сеть).

Я думаю, что если ты сохранишь текущую конфигурацию, у тебя могут возникнуть проблемы с более сложными сценариями звонков, такими как переадресация вызовов, передача вызовов, ответы на звонки автоответчиком, очереди вызовов и т.д. из-за путаницы между IP-адресами источника сообщений SIP, полученных от внешнего SIP-прокси и сообщений SIP, полученных от телефонов Talk. Например, если ты совершаешь исходящий звонок на PSTN, ждешь ответа пользователя, а затем пытаешься включить этого пользователя в конференц-связь с другим пользователем PSTN, UniFi Talk может не смочь подключить второго пользователя к звонку, но это нужно проверить, чтобы наверняка знать. Теперь, если бы мы могли изменить привязку IP-адреса для процесса FreeSwitch и привязать процесс только к одному IP-адресу, это бы не стало проблемой. Например, если ты запускаешь приложение UniFi Talk на автономной консоли, такой как UCK-G2-Plus, процесс FreeSwitch привязан только к одному IP-адресу.

Решать тебе, хочешь ли ты сохранить текущую конфигурацию или попробовать использовать мое предложение с правилом переадресации портов, настроенным таким образом, чтобы сохранить тот же IP-адрес назначения (IP-адрес, назначенный интерфейсу WAN) и только перевести номер порта с 5060 на 5061.

Удачи с тестированием. Рад, что мои предложения способствовали твоему успеху в этом проекте.

Alanbaker

Guest

#11

06.03.2025 12:26:00

Рожаси, я тебе просто не знаю, как отблагодарить, это было так расстраивающе, но наконец-то работает, входящие звонки теперь проходят успешно. Моя конфигурация ниже. Публикую её для будущих справок. Настрой переадресацию порта, как показано ниже.

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

Буду продолжать тестировать и дорабатывать правила брандмауэра.

rozhasi

Guest

#12

06.03.2025 02:08:00

Назначьте статический порт источника (как я показывал вам раньше) в UniFi Talk на 5061. Затем создайте правило перенаправления портов в приложении UniFi Network. Правило перенаправления портов должно выглядеть как на скриншоте ниже (убедитесь, что вы выбрали правильный интерфейс WAN и убедитесь, что вы заполнили поле «Адрес перенаправления» IP-адресом, назначенным вашему интерфейсу WAN. Этот IP-адрес должен быть статическим публичным IP. Надеюсь, ваш провайдер присвоил вам статический IP (судя по тому, что вы упомянули, что ваш SIP-провайдер идентифицирует вас по вашему публичному IP-адресу).

Затем создайте политику брандмауэра как на скриншоте ниже. Зона источника установлена на External, а IP-адрес установлен на Any. Вы можете позже изменить IP-адрес источника на IP-адрес SIP-прокси вашего SIP-провайдера, но вначале просто оставьте Any. Порт источника установлен на Custom 5060 (после сохранения этой политики брандмауэра он изменится на SIP 5060). Это порт источника сообщений SIP, которые ваш SIP-провайдер отправляет вам. Из ваших предыдущих сообщений стало ясно, что ваш SIP-провайдер использует порт 5060 на своей стороне, а также ожидает, что вы будете использовать порт 5060 на своей стороне. Однако, эта политика брандмауэра указывает порт 5061 (вместо порта 5060) в качестве порта назначения для входящего трафика. Это связано с тем, что с IPTables, DNAT (destination NAT, aka Port Forwarding) выполняется на трафике, соответствующем правилу DNAT, прежде чем применятся политики брандмауэра. Таким образом, к моменту, когда входящий трафик соответствует этой политике брандмауэра, порт назначения в входящих сообщениях SIP уже был преобразован правилом перенаправления портов (созданным ранее) с 5060 на 5061.

Добавьте эту политику брандмауэра и убедитесь, что она указана первой в ячейке External to Gateway. Если в вашем случае она не указана первой, то переместите ее вверх, чтобы она была указана первой. В этот момент вы должны быть в состоянии совершить входящий звонок и ответить на него на своем телефоне UniFi Talk.

rozhasi

Guest

#13

06.03.2025 01:38:00

Только что попробовал, и вижу, что порт 5060 не разрешен, но порт 5061 работает. Когда это сделано, UniFi Talk связывается с публичным IP на порту 5061:fs_cli -x "sofia status profile external_talk"
=================================================================================================
Имя          external_talk
Доменное имя      N/A
Авто-NAT        false
DBName         sofia_reg_external_talk
Pres Hosts
Dialplan        XML
Context        public
Challenge Realm    auto_to
RTP-IP         192.168.1.1
Ext-RTP-IP       162.191.XXX.YYY
SIP-IP         192.168.1.1
Ext-SIP-IP       162.191.XXX.YYY
URL          sip:mod_sofia@162.191.XXX.YYY:5061
BIND-URL        sip:mod_sofia@162.191.XXX.YYY:5061;maddr=192.168.1.1;transport=udp,tcp
TLS-URL        sip:mod_sofia@162.191.XXX.YYY:5061
TLS-BIND-URL      sips:mod_sofia@162.191.XXX.YYY:5061;maddr=192.168.1.1;transport=tls
HOLD-MUSIC       N/A
OUTBOUND-PROXY     N/A
CODECS IN       PCMU,PCMA,VP8
CODECS OUT       PCMU,PCMA,VP8
TEL-EVENT       101
DTMF-MODE       rfc2833
CNG          13
SESSION-TO       0
MAX-DIALOG       0
MAX-RECV-RPS      1000
NOMEDIA        false
LATE-NEG        false
PROXY-MEDIA      false
AGGRESSIVENAT     false
CALLS-IN        0
FAILED-CALLS-IN    0
CALLS-OUT       0
FAILED-CALLS-OUT    0
REGISTRATIONS     0
Прочитайте мой следующий пост для получения дальнейших инструкций.

Alanbaker Guest	#14 05.03.2025 20:57:00 Завтра внимательно изучу твой пост, но использовать порт 5060 как SSP не получится, он не разрешает.

rozhasi

Guest

#15

05.03.2025 20:21:00

Если твой SIP-провайдер может отправлять SIP INVITE только на порт 5060, то в поле "Static Signaling Port" введи 5060 — смотри скриншот ниже:

Затем перезапусти службу UniFi Talk. Далее, если ты перешёл на Zone-Based Firewall, создай политику брандмауэра в ячейке External-to-Gateway (найди строку External в первом столбце, затем найди столбец Gateway и найди ячейку, где они пересекаются). Иначе, если ты не перешёл на Zone-Based Firewall, зайди в External (или как оно там называлось). Создай новую политику брандмауэра и разреши трафик с любого IP на твой WAN IP по TCP/UDP 5060. Входящие вызовы должны начать работать. (Необязательно) Как только входящие вызовы начнут работать, ты можешь изменить политику брандмауэра, чтобы указать диапазон IP-адресов твоего SIP-провайдера в качестве исходного IP. Назначением по-прежнему должно быть WAN-интерфейс UDMP, а портом — TCP/UDP-порт 5060.

В скриншоте выше, Static Signaling Port означает исходящий порт UniFi Talk. Это порт, на котором UniFi Talk привязывает свою службу к WAN-адресу UDMP, то есть это номер исходящего порта, который UniFi Talk использует при отправке SIP-трафика (включая SIP INVITE) твоему SIP-провайдеру. Это также порт, который твой SIP-провайдер использует в качестве целевого порта; то есть, порт, к которому твой SIP-провайдер должен отправлять сообщения SIP INVITE.

С другой стороны, пользовательские поля, доступные в разделе (конфигурация стороннего SIP-провайдера), указывают целевой порт, на котором UniFi Talk должен отправлять свои INVITE (и другие сообщения SIP), когда UniFi Talk отправляет SIP-трафик своему SIP-провайдеру. То есть, это порт, на котором твой SIP-провайдер привязывает свои SIP-услуги для получения трафика от тебя, и это также исходящий порт, который твой SIP-провайдер использует при отправке сообщений SIP (включая INVITE) UniFi Talk.

Alanbaker

Guest

#16

05.03.2025 20:12:00

Мой провайдер SIP сообщил, что могут отправлять INVITE только на порту 5060. SSP не может подключиться к 5060. Я перечитывал твой пост много раз, все логично, но никак не могу заставить это работать. А пользовательские поля связаны только с исходящими вызовами, а поля диапазона IP и номера телефона — с входящими?

rozhasi

Guest

#17

05.03.2025 16:55:00

Переадресация портов нужна, чтобы перенаправлять трафик с устройства, где работает брандмауэр, на другое устройство за ним. У вас UniFi Talk работает на том же устройстве, что и брандмауэр. Куда же перенаправлять трафик? Переадресация портов не требуется. UniFi Talk использует процесс, который открывает порт напрямую с публичным IP-адресом, назначенным порту WAN вашего UDMP. Используйте команду, чтобы проверить это: fs_cli -x "sofia status profile external_talk".

Единственная причина, по которой вам нужно открывать брандмауэр для трафика от вашего SIP-провайдера, заключается в том, что ваш UniFi Talk не регистрируется в SIP-прокси вашего SIP-провайдера. В противном случае исходящий трафик, генерируемый SIP REGISTER сообщениями, поддерживал бы открытыми нужные "дырки" (на соответствующих UDP-портах) для трафика от вашего SIP-провайдера. Поскольку ваш SIP-провайдер не использует процесс SIP REGISTER, вам приходится вручную настраивать соответствующие политики брандмауэра, чтобы разрешить SIP-трафик от вашего SIP-провайдера. Остальное подробно объяснено в моем предыдущем сообщении, поэтому я не буду повторять здесь.

Alanbaker Guest	#18 05.03.2025 15:42:00 Спасибо, полезная информация. Просто чтобы уточнить, вы предлагаете открывать порты на брандмауэре, а не в переадресации портов?

rozhasi

Guest

#19

05.03.2025 15:38:00

В таком случае, тебе нужно открыть брандмауэр для SIP-трафика, идущего от твоего SIP-провайдера. Убедись, что твой SIP-провайдер отправляет SIP-трафик на твой IP-адрес на те порты, которые слушает UniFi Talk. Используй эту команду в CLI для проверки портов: `fs_cli -x "sofia status profile external_talk"`

=================================================================================================
Имя          external_talk
Доменное имя      N/A
Auto-NAT        false
DBName         sofia_reg_external_talk
Pres Hosts
Dialplan        XML
Context        public
Challenge Realm    auto_to
RTP-IP         162.191.XXX.YYY
Ext-RTP-IP       stun:global.stun.twilio.com
SIP-IP         162.191.XXX.YYY
Ext-SIP-IP       162.191.XXX.YYY
URL          sip:mod_sofia@162.191.XXX.YYY:56391
BIND-URL        sip:mod_sofia@162.191.XXX.YYY:56391;maddr=162.191.XXX.YYY;transport=udp,tcp
TLS-URL        sip:mod_sofia@162.191.XXX.YYY:5061
TLS-BIND-URL      sips:mod_sofia@162.191.XXX.YYY:5061;maddr=162.191.XXX.YYY;transport=tls
HOLD-MUSIC       N/A
OUTBOUND-PROXY     N/A
CODECS IN       PCMU,PCMA,VP8
CODECS OUT       PCMU,PCMA,VP8
TEL-EVENT       101
DTMF-MODE       rfc2833
CNG          13
SESSION-TO       0
MAX-DIALOG       0
MAX-RECV-RPS      1000
NOMEDIA        false
LATE-NEG        false
PROXY-MEDIA      false
AGGRESSIVENAT     false
CALLS-IN        0
FAILED-CALLS-IN    0
CALLS-OUT       0
FAILED-CALLS-OUT    0
REGISTRATIONS     0
Ты можешь видеть, что в моем случае, используемый UniFi Talk порт 56391. Значит, CallCentric будет отправлять SIP INVITE сообщения мне на порт 56391. Это одна из точек регистрации у твоего SIP-провайдера, чтобы его прокси знал исходящий адрес твоего SIP-UA. Ниже приведен пример SIP REGISTER сообщения, которое мой экземпляр UniFi Talk отправляет моему SIP-провайдеру: `REGISTER sip:callcentric.com;transport=udp SIP/2.0`
`v:SIP/2.0/UDP 162.191.XXX.YYY:56391;rport;branch=z9hG4bK56rSrSrSHtgDS`
`Max-Forwards:70`
`f:<sip:177712345671@callcentric.com>;tag=3Q1Z0HFXHZaKp`
`t:<sip:17771234567@callcentric.com>`
`i:3d13f130-187d-4ff4-8eb0-3abea8bb704a`
`CSeq:96008541 REGISTER`
`m:<sip:gw+CallCentricext.141@162.191.XXX.YYY:56391;transport=udp;gw=CallCentricext.141>`
`Expires:30`
`User-Agent:UT-3.5.4`
`Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REGISTER,REFER,NOTIFY`
`k:timer,path,replaces`
`Proxy-Authorization:Digest username="17771234567",realm="callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com",nonce="ABCDEFGHIJKLMNOPQRSTUVWXYZ",algorithm=MD5,uri="sip:callcentric.com"`
`Content-Length: 0`
Ты ожидаешь получать SIP INVITE сообщения на порту 5060, но если ты не настроишь свой исходящий порт как 5060 в UniFi Talk / FreeSwitch, то исходящий порт для твоих SIP сообщений (тот же, что и порт назначения для SIP сообщений от твоего провайдера, которые он отправляет тебе) — это эфемерный порт (номер порта между 1024 и 65535). Если ты не можешь сузить диапазон портов для входящих SIP сообщений от твоего SIP провайдера, открой весь диапазон IP адресов твоего SIP провайдера в брандмауэре с внешней стороны в сторону шлюза. Ты можешь задать порт, который использует UniFi Talk для SIP сигнализации, используя опцию "Static Signaling Port" в UniFi Talk, как показано на скриншоте ниже:

Это поможет тебе не открывать брандмауэр для всех портов IP адресов SIP провайдера, а только для определенного порта. Если ты хочешь пойти этим путем, убедись, что ты получил информацию от своего SIP провайдера о том, какие порты он использует для отправки SIP INVITE сообщений тебе при входящем звонке. Затем установи свой "Static Signaling Port" в значение, которое ты получил от своего SIP провайдера. Затем перезапусти UniFi Talk и создай правило брандмауэра с внешней стороны в сторону шлюза, чтобы разрешить трафик на этот номер порта. Тебе не нужно настраивать никаких правил NAT, потому что UniFi Talk автоматически привязан к публичному IP адресу твоего UDMP, который ты можешь увидеть, используя команду: `fs_cli -x "sofia status profile external_talk"`
Поэтому тебе нужен только правило брандмауэра, которое разрешает трафик от IP адреса SIP провайдера на порт, который он использует для отправки тебе SIP INVITE сообщений (или, альтернативно, для всех портов от IP адреса SIP провайдера).

Alanbaker Guest	#20 05.03.2025 15:18:00 Этот sip-провайдер не требует регистрации, аутентификация происходит по моему WAN IP. Провайдер это четко сказал. Нет никакого логина и пароля. Исходящие вызовы я делаю без проблем, а вот входящие не могу. Можешь показать какую-нибудь отладку входящего вызова?

Читают тему (гостей: 1)