Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Проброс RTP на две АТС

    Scheduled Pinned Locked Moved Russian
    22 Posts 3 Posters 2.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • werterW
      werter @layman
      last edited by werter

      Добрый
      @layman

      1. https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html
        https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html

      2. У вас же одни и теже порты пробрасываются для ДВУХ АТС. Как пф поймет-то кому куда форвардить? И зачем вам 30000+ портов открывать для АТС? Расчет - 3 порта на одного абонента + разбить по АТС (пример):
        АТС1 - 30001-31001, АТС2 - 32001-33001
        Настройки на АТС для RTP-портов при этом, ес-но, подправить.

      Зы. Ideco - гадость ) Freepbx (asterisk) - наше всё.

      L 1 Reply Last reply Reply Quote 0
      • L
        layman @werter
        last edited by layman

        @KONSTANTI
        Чтобы исключить возможные проблемы в asterisk'е, завел аккаунт на IP телефоне. Завел сразу 2 аккаунта для двух номеров, первый совпадает с аккаунтом на Ideco, второй совпадает с FreePBX. Проверяю первый все отлично, второй опять не слышит входящий звук.
        @werter

        1. Сделал как в инструкции nat-voip-pbx
        2. в nat источник разный. порты сменил у альянса АТСyealink (11780:12780), у АТСIdeco (20000:29999). Ничего не поменялось, также Ideco работает, IP телефон не слышит входящий.
          alt text

        Вот таблица соединений во время звонка
        Ideco

        LAN	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:21423
        

        IP телефон

        
        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
        K 1 Reply Last reply Reply Quote 0
        • K
          Konstanti @layman
          last edited by

          @layman
          Надо смотреть SIP трафик на этапе установления соединения (SIP -invite пакет поля SDP ) с обеих сторон . Именно там для второй стороны указывается порт и ip адрес , на который надо слать голосовой трафик .

          • если там все в порядке - надо смотреть входящий RDP трафик на WAN интерфейсе - есть ли он ?
          L 1 Reply Last reply Reply Quote 0
          • L
            layman @Konstanti
            last edited by layman

            У провайдера есть своя программа 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
            
            K 1 Reply Last reply Reply Quote 0
            • K
              Konstanti @layman
              last edited by Konstanti

              @layman
              я Вам пишу одно , Вы мне про другое . Тут проблема , похоже , не в пробросе портов .
              Проблема ( скорее всего )в передаче некорректной информации об внешнем IP адресе при установлении соединения с Вашей стороны .

              От Вас требуется - с помощью tcpdump ( packet Capture в PF) перехватить данные на порту 5060 при установлении соединения ( вызова ) с внешним абонентом на WAN интерфейсе. Посмотреть эти данные , например , через Wireshark и найти пакет SIP invite . И посмотреть - какой IP адрес передается от Вашей АТС/ телефона из сети 10.3.1.0/24 в параметрах SDP . И дальше уже станет понятно - все ли тут верно или нет и как действовать дальше.

              L 1 Reply Last reply Reply Quote 0
              • L
                layman @Konstanti
                last edited by layman

                @konstanti
                10.3.1.47 и 10.3.1.10 соответственно.
                alt text

                K 1 Reply Last reply Reply Quote 0
                • K
                  Konstanti @layman
                  last edited by Konstanti

                  @layman

                  что меня смущает в этих картинках ( не понимаю пока, как в одном случае все работает )

                  1. в обоих случаях в sdp передается внутренний ip адрес АТС ( по уму , должен передаваться xx.xxx.40.237 )
                  2. вы пишите про порты 30000- 65535 - а у Вас в обоих случаях предлагаются порты не из этого диапазона

                  Можете выложить SIP invite от sip- клиента провайдера (для сравнения ) ?

                  L 1 Reply Last reply Reply Quote 0
                  • L
                    layman @Konstanti
                    last edited by

                    @konstanti
                    Софтфон MIcroSIP все работает
                    alt text

                    1. не знаю, но если все аккаунты завести в ideco все работает. На телефоне работает аккаунт ХХХХХ29, а у ХХХХХ01 не слышно человека которому позвонил.
                    2. Поменял, чтобы были разные. На телефон (11780:12780), на Ideco (20000:29999).
                    K 1 Reply Last reply Reply Quote 0
                    • K
                      Konstanti @layman
                      last edited by Konstanti

                      @layman
                      Раз так работает по какой-то причине , попробуйте сделать так
                      на WAN интерфейсе посмотрите UDP трафик от абонента , которому звоните . Принципиально , есть ли он ? Не 5060 порт , а RTP диапазон . Если трафик есть , то смотрите тоже самое на LAN интерфейсе - отрабатывает ли нормально проброс портов .

                      L 1 Reply Last reply Reply Quote 0
                      • L
                        layman @Konstanti
                        last edited by layman

                        @konstanti
                        Если я правильно понял что смотреть, вот трафик по Wan у телефона
                        alt text
                        По lan у телефона пусто.
                        Wan у Ideco пусто
                        Lan у Ideco
                        alt text

                        У правил 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. Может в этом дело?

                        K 1 Reply Last reply Reply Quote 0
                        • K
                          Konstanti @layman
                          last edited by

                          @layman
                          а в журнале файрвола нет заблокированных UDP пакетов на нужных портах ?
                          Если ip адреса АТС постоянно меняются , то в этом может быть проблема .

                          L 1 Reply Last reply Reply Quote 0
                          • L
                            layman @Konstanti
                            last edited by layman

                            @konstanti
                            Вот UDP по Wan в телефоне активирован аккаунт как в Ideco все работает
                            alt text
                            По lan
                            alt text

                            K 1 Reply Last reply Reply Quote 0
                            • K
                              Konstanti @layman
                              last edited by Konstanti

                              @layman
                              Посмотрите журнал файрвола

                              Я немного путаюсь
                              У Вас на картинках просто разные IP адреса внешние (для WAN и LAN) и порты разные .
                              Нужны данные по одному вызову - чтобы все совпадало

                              L 1 Reply Last reply Reply Quote 0
                              • L
                                layman @Konstanti
                                last edited by

                                @konstanti

                                В журнале файрвола
                                WAN Default deny rule IPv4 (1000000103) 109.69.176.249:5060 88.234.40.237:63084 UDP

                                109.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

                                K 1 Reply Last reply Reply Quote 0
                                • K
                                  Konstanti @layman
                                  last edited by Konstanti

                                  @layman
                                  Подскажите , а нельзя 2 Sip аккаунта завести на одну внутреннюю АТС ? И машрутизировать вызовы уже в ней

                                  Мне очень интересно увидеть весь обмен трафиком RTP при вызове с проблемной АТС ( на WAN и LAN интерфейсах одновременно )
                                  чтобы совпадали исходящие и входящие ip адреса и порты
                                  Ваша задача понять - приходит ли при вызове RTP трафик от абонента на WAN интерфейс - и , если да , то понять ,куда он потом девается на LAN интерфейсе

                                  посмотрите , что выдает команда
                                  nslookup номер29.enforta.ru

                                  L 2 Replies Last reply Reply Quote 0
                                  • L
                                    layman @Konstanti
                                    last edited by

                                    @konstanti said in Проброс RTP на две АТС:

                                    nslookup номер29.enforta.ru
                                    Оба номера выдают
                                    109.69.176.249

                                    1 Reply Last reply Reply Quote 0
                                    • L
                                      layman @Konstanti
                                      last edited by layman

                                      @konstanti said in Проброс RTP на две АТС:

                                      Подскажите , а нельзя 2 Sip аккаунта завести на одну внутреннюю АТС ? И машрутизировать вызовы уже в ней

                                      Так и было в Ideco, но сейчас надо избавить от неё и сделать все на asterisk. Сразу всех перевести проблематично, поэтому решено сначала взять малоиспользуемый номер, на нем потестить, а потом все остальных перевести.

                                      Может это от неправильной обработки альянса
                                      alt text
                                      В описание написано: If multiple IPs are returned by a DNS query, all are used. В итоге, он вместо одного IP возвращает список или всю сеть.

                                      K 1 Reply Last reply Reply Quote 0
                                      • K
                                        Konstanti @layman
                                        last edited by Konstanti

                                        @layman
                                        проблема в том , что DNS ответ может быть разным
                                        и какой ip адрес вернётся пока неизвестно
                                        можно посмотреть содержимое таблицы в pf
                                        /Diagnostics/Tables

                                        попробуйте , ради интереса , весь UDP трафик (5060 SIP и весь диапазон RTP трафика ) от 109.69.176.0/24 пробрасывать на новую АТС ( Asterisk )
                                        Не используя алиасы

                                        L 1 Reply Last reply Reply Quote 0
                                        • L
                                          layman @Konstanti
                                          last edited by

                                          @konstanti
                                          в pf/Diagnostics/Tables оба альянса получают 109.69.176.249
                                          Пока не могу пустить весь трафик на asterisk, позже оба аккаунта будут перенесы.

                                          werterW 1 Reply Last reply Reply Quote 0
                                          • werterW
                                            werter @layman
                                            last edited by

                                            @layman
                                            Как перенесете все на freepbx\asterisk - отпишите, получилось ли.
                                            Спасибо.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.