Проброс RTP на две АТС
-
Нужна помочь, есть две АТС допустим 10.3.1.10/32 и 10.3.1.47/32, два номера у одного провайдера сервера номер1.enforta.ru и номер2.enforta.ru, порты одинаковые (30000-65535). В NAT проброшены порты. В итоге на 10.3.1.10/32 все отлично. На 10.3.1.47/32 при входящем все ок, при исходящем не слышно адресата (звонящего слышно). Что не так???
-
@layman
Здр
Проблема односторонней слышимости , как правило , связана с неверной настройкой или АТС или оконечного устройства за NAT-ом. Предположу , что у Вас неправильно настроена АТС 10.3.1.47 ( в частности , ее настройки касающиеся передачи внешнего IP адреса при обмене SIP пакетами ( в той части обмена , где стороны выбирают порт RDP для обмена трафиком ). -
Добрый
@layman-
https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html
https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html -
У вас же одни и теже порты пробрасываются для ДВУХ АТС. Как пф поймет-то кому куда форвардить? И зачем вам 30000+ портов открывать для АТС? Расчет - 3 порта на одного абонента + разбить по АТС (пример):
АТС1 - 30001-31001, АТС2 - 32001-33001
Настройки на АТС для RTP-портов при этом, ес-но, подправить.
Зы. Ideco - гадость ) Freepbx (asterisk) - наше всё.
-
-
@KONSTANTI
Чтобы исключить возможные проблемы в asterisk'е, завел аккаунт на IP телефоне. Завел сразу 2 аккаунта для двух номеров, первый совпадает с аккаунтом на Ideco, второй совпадает с FreePBX. Проверяю первый все отлично, второй опять не слышит входящий звук.
@werter- Сделал как в инструкции nat-voip-pbx
- в nat источник разный. порты сменил у альянса АТСyealink (11780:12780), у АТСIdeco (20000:29999). Ничего не поменялось, также Ideco работает, IP телефон не слышит входящий.
Вот таблица соединений во время звонка
IdecoLAN udp 10.3.1.10:28854 -> 109.69.176.148:21422 WAN udp 88.234.40.237:6009 (10.3.1.10:28854) -> 109.69.176.148:21422 LAN udp 10.3.1.10:28855 -> 109.69.176.148:21423 WAN udp 88.234.40.237:6746 (10.3.1.10:28855) -> 109.69.176.148:21423IP телефон
LAN udp 10.3.1.47:12108 -> 109.69.176.130:52194 WAN udp 88.234.40.237:16234 (10.3.1.47:12108) -> 109.69.176.130:52194 LAN udp 10.3.1.47:12109 -> 109.69.176.130:52195 WAN udp 88.234.40.237:38147 (10.3.1.47:12109) -> 109.69.176.130:52195 -
@layman
Надо смотреть SIP трафик на этапе установления соединения (SIP -invite пакет поля SDP ) с обеих сторон . Именно там для второй стороны указывается порт и ip адрес , на который надо слать голосовой трафик .- если там все в порядке - надо смотреть входящий RDP трафик на WAN интерфейсе - есть ли он ?
-
У провайдера есть своя программа sip-клиент (в настройках стоят RTP 50000:50099):. Туда занёс данные sip аккаунта, никакие порты не пробрасывал, все работает. Выходит без проброса все должно работать.
LAN udp 10.3.1.51:50003 -> 109.69.176.148:48941 WAN udp 88.234.40.237:54928 (10.3.1.51:50003) -> 109.69.176.148:48941 LAN udp 10.3.1.51:50002 -> 109.69.176.148:48940 WAN udp 88.234.40.237:15518 (10.3.1.51:50002) -> 109.69.176.148:48940 -
@layman
я Вам пишу одно , Вы мне про другое . Тут проблема , похоже , не в пробросе портов .
Проблема ( скорее всего )в передаче некорректной информации об внешнем IP адресе при установлении соединения с Вашей стороны .От Вас требуется - с помощью tcpdump ( packet Capture в PF) перехватить данные на порту 5060 при установлении соединения ( вызова ) с внешним абонентом на WAN интерфейсе. Посмотреть эти данные , например , через Wireshark и найти пакет SIP invite . И посмотреть - какой IP адрес передается от Вашей АТС/ телефона из сети 10.3.1.0/24 в параметрах SDP . И дальше уже станет понятно - все ли тут верно или нет и как действовать дальше.
-
@konstanti
10.3.1.47 и 10.3.1.10 соответственно.
-
что меня смущает в этих картинках ( не понимаю пока, как в одном случае все работает )
- в обоих случаях в sdp передается внутренний ip адрес АТС ( по уму , должен передаваться xx.xxx.40.237 )
- вы пишите про порты 30000- 65535 - а у Вас в обоих случаях предлагаются порты не из этого диапазона
Можете выложить SIP invite от sip- клиента провайдера (для сравнения ) ?
-
@konstanti
Софтфон MIcroSIP все работает
- не знаю, но если все аккаунты завести в ideco все работает. На телефоне работает аккаунт ХХХХХ29, а у ХХХХХ01 не слышно человека которому позвонил.
- Поменял, чтобы были разные. На телефон (11780:12780), на Ideco (20000:29999).
-
@layman
Раз так работает по какой-то причине , попробуйте сделать так
на WAN интерфейсе посмотрите UDP трафик от абонента , которому звоните . Принципиально , есть ли он ? Не 5060 порт , а RTP диапазон . Если трафик есть , то смотрите тоже самое на LAN интерфейсе - отрабатывает ли нормально проброс портов . -
@konstanti
Если я правильно понял что смотреть, вот трафик по Wan у телефона
По lan у телефона пусто.
Wan у Ideco пусто
Lan у Ideco
У правил Firewall/NAT/Port Forward стоит источник альянс номер01.enforta.ru (109.69.176.146) и номер29.enforta.ru (109.69.176.143) ip адреса у этих доменов динамические, при каждом звонке разные. RTP как раз идет с них, а вот sip всегда одинаковый 109.69.176.249. Может в этом дело?
-
@layman
а в журнале файрвола нет заблокированных UDP пакетов на нужных портах ?
Если ip адреса АТС постоянно меняются , то в этом может быть проблема . -
@konstanti
Вот UDP по Wan в телефоне активирован аккаунт как в Ideco все работает
По lan
-
@layman
Посмотрите журнал файрволаЯ немного путаюсь
У Вас на картинках просто разные IP адреса внешние (для WAN и LAN) и порты разные .
Нужны данные по одному вызову - чтобы все совпадало -
В журнале файрвола
WAN Default deny rule IPv4 (1000000103) 109.69.176.249:5060 88.234.40.237:63084 UDP109.69.176.0/24 - это подсеть SIP провайдера
Вот данные регистрации в личном кабинете у провайдера
Это номер у которого не слышно
URI регистрации: sip:user1@10.3.1.47:5060
Path: sip:udp-88.234.40.237-5060S109.69.176.249-5060.nat.cgatepro;lr
Клиент: Yealink SIP-T43U 108.85.14.1
Активна до: 28.09.2021, 11:57:57Это у которого все хорошо
URI регистрации: sip:user3@10.3.1.10:5160
Path: sip:udp-88.234.40.237-63084S109.69.176.249-5060.nat.cgatepro;lr
Клиент: YATE/5.5.0
Активна до: 28.09.2021, 11:05:59А это когда активировал этот аккаунт в телефоне
URI регистрации: sip:user3@10.3.1.47:5060
Path: sip:udp-88.234.40.237-5060S109.69.176.249-5060.nat.cgatepro;lr
Клиент: Yealink SIP-T43U 108.85.14.1
Активна до: 28.09.2021, 11:50:26 -
@layman
Подскажите , а нельзя 2 Sip аккаунта завести на одну внутреннюю АТС ? И машрутизировать вызовы уже в нейМне очень интересно увидеть весь обмен трафиком RTP при вызове с проблемной АТС ( на WAN и LAN интерфейсах одновременно )
чтобы совпадали исходящие и входящие ip адреса и порты
Ваша задача понять - приходит ли при вызове RTP трафик от абонента на WAN интерфейс - и , если да , то понять ,куда он потом девается на LAN интерфейсепосмотрите , что выдает команда
nslookup номер29.enforta.ru -
@konstanti said in Проброс RTP на две АТС:
nslookup номер29.enforta.ru
Оба номера выдают
109.69.176.249 -
@konstanti said in Проброс RTP на две АТС:
Подскажите , а нельзя 2 Sip аккаунта завести на одну внутреннюю АТС ? И машрутизировать вызовы уже в ней
Так и было в Ideco, но сейчас надо избавить от неё и сделать все на asterisk. Сразу всех перевести проблематично, поэтому решено сначала взять малоиспользуемый номер, на нем потестить, а потом все остальных перевести.
Может это от неправильной обработки альянса
В описание написано: If multiple IPs are returned by a DNS query, all are used. В итоге, он вместо одного IP возвращает список или всю сеть. -
@layman
проблема в том , что DNS ответ может быть разным
и какой ip адрес вернётся пока неизвестно
можно посмотреть содержимое таблицы в pf
/Diagnostics/Tablesпопробуйте , ради интереса , весь UDP трафик (5060 SIP и весь диапазон RTP трафика ) от 109.69.176.0/24 пробрасывать на новую АТС ( Asterisk )
Не используя алиасы
