Не приходят звонки с транка при смене Bind Port-a

[dimm-dimm]

Добрый день.
Имеется достаточно глупая, но тем не менее непонятная проблема.

Был изменен Bind port для регистрации клиентов с 5060 на условный 9999, который виден снаружи. После этого, с одного из множества транков прекратили поступать звонки. Сам транк в sip-show-peers отображается в статусе OK.

При смене значения порта на стандартный 5060, звонки начинают идти исправно. Не могу понять, как влияет порт sip регистраций на его работу, учитывая, что порт 5060 закрыт для доступа извне.
Другие транки при этом работают и принимают звонки.

Настройки транка:

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

username=12345
type=peer
qualify=yes
сanreinvite=no
insecure=port,invite
host=адрес оператора
fromuser=12345
dtmfmode=rfc2833
disallow=all
context=from-trunk
allow=alaw,ulaw

[ded]

У вас указано:
host=адрес оператора

Вопрос: каким образом хост оператора узнает о том, что вы сменили порт с 5060 на 9999?

Когда своим телефонам вы говорите - логинимся на ИП = 10.11.12.13 и на порт 9999 (вместо 5060) они вас слушаются.
А провайдер на транке как узнает?

Есть варианты: регистрация вашего транка у провайдера - имеется? Есть строка
register=12345:superpassword@адрес оператора
то это один сценарий, Как правило - с какого адреса:порта прибежал пакет REGISTER - то на тот же порт поступают инвайты.
А если статический пир - то другой сценарий, провайдеру нужно сообщать человеческим образом "просим сменить наш порт.

[Zavr2008]

Был изменен Bind port для регистрации клиентов с 5060 на условный 9999, который виден снаружи

Вообще на астере можно было ничего и не менять. Просто указать верный внешний externip/externaddr, в их состав можно и порт добавить что пробросили через NAT.
insecure=port,invite это авторизация по IP, вторая сторона должна знать что Вы вытворяете. Это точно..

Но сейчас проще мир стал - 2 канальных драйвера, один на одном порту может сидеть, второй на другом.
Можно было на PJSIP настроить удаленщиков, а транки оставить на chan_sip как были.

[dimm-dimm]

отредактивано модератором

Я бы с радостью перенес клиентов на pjsip, но у меня астериск 1.8, который не может в pjsip. А обновить его возможности нет, из-за костылей интеграции со сторонними сервисами.

Вопрос: каким образом хост оператора узнает о том, что вы сменили порт с 5060 на 9999?

Я не совсем понимаю, зачем оператору знать порт для регистрации клиентов. Я всегда видел это так:
Моя АТС инициирует соединение с провайдером через регистрацию у него, и входящие идут уже через этот коннект. Причем здесь порт 5060 я ума не приложу.

Есть варианты: регистрация вашего транка у провайдера - имеется? Есть строка
register=12345:superpassword@адрес оператора
то это один сценарий, Как правило - с какого адреса:порта прибежал пакет REGISTER - то на тот же порт поступают инвайты.
А если статический пир - то другой сценарий, провайдеру нужно сообщать человеческим образом "просим сменить наш порт.

Регистрация у провайдера идет без secret-a, он знает адрес нашей АТС. Я бы мог допустить, что на 5060 что-либо приходит от оператора, но порт этот закрыт фаерволлом, и до него не достучаться. При этом при смене в самом астериске порта на стандартный вызовы проходят.

Оператору я данные передал. Посмотрим, может это действительно решит вопрос.

[ded]

Регистрация у провайдера идет без secret-a, он знает адрес нашей АТС.

Эта фраза выдаёт непонимание, поэтому

Причем здесь порт 5060 я ума не приложу.

Ваш Астериск не имеет никакой регистрации у провайдера в понимании протокола SIP.
В такой концепции нет пакета REGISTER от вашего Астериск к провайдеру. У него ваш Астериск заведён как статический пир. У статических SIP пиров по дефолту порт сигнализации = 5060, если не указано иное.
А ваши телефоны на вашем Астериске заведены как динамические пиры, и посылают пакет REGISTER на указанный им адрес:порт, после чего Астериск сообщается с ними на тот адрес:порт, который они указали в пакете REGISTER.

[dimm-dimm]

отредактивано модератором

Понял. Большое спасибо за ответ.

[ded]

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