Проброс RTP на две АТС
-
@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 )
Не используя алиасы -
@konstanti
в pf/Diagnostics/Tables оба альянса получают 109.69.176.249
Пока не могу пустить весь трафик на asterisk, позже оба аккаунта будут перенесы. -
@layman
Как перенесете все на freepbx\asterisk - отпишите, получилось ли.
Спасибо.
