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

    VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen

    Scheduled Pinned Locked Moved Deutsch
    21 Posts 3 Posters 2.9k 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.
    • T
      tpf
      last edited by tpf

      Ich habe dieses Problem mit meiner FritzBox und Telekom SIP (kein Trunk) ebenfalls: ganz oft ist nach 15 Minuten Ende und ich finde keine wirkliche Erklärung für dieses Verhalten. Im Log der Firewall ist folgendes zu sehen:

      Ich habe schon mit Timeouts rumgespielt und keine Verbesserung erreicht. Ganz, ganz selten gehen auch mal mehr als 15 Minuten. Der NAT-keep-alive in der Fritte steht auf 30 Sekunden.

      pfs-gespräch-getrennt.png

      10 years pfSense! 2006 - 2016

      1 Reply Last reply Reply Quote 0
      • JeGrJ
        JeGr LAYER 8 Moderator
        last edited by

        @tpf könnte aber ein anderes Problem sein. Aber der Screen sieht so aus als würdest du SIP von der Telekom blocken. 7078 ist m.W. bei denen ein RTP Port. Die mögen wohl incoming doch SIP/udp reden, nicht nur outgoing TCP/5061.

        Gruß

        Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

        If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

        1 Reply Last reply Reply Quote 0
        • T
          tpf
          last edited by tpf

          Servus JeGr,

          nach meinem Verständnis und allen Installationen, die ich bisher so gemacht habe, muss bei einer SPI-Firewall nicht mehr gemacht werden, als ausgehend eine Verbindung zu den SIP-Servern aufzubauen. Außer natürlich static port im outgoing NAT. Sonst hörst nix.

          Klar, es gibt keine eigenen Firewallregeln für eingehenden Verkehr. Da ist einfach zu. Es funzt ja auch. Ganze 15 Minuten. Hin und wieder auch länger. Aber in 99 % der Fällen ist nach 15 Minuten die Verbindung weg.

          Aus irgendwelchen Gründen kappt mir die Firewall das Gespräch und mir ist nicht klar, weshalb. Was ich via pftop so sehe, sieht alles gut aus. Sitzungen werden verlängert und keine geht auf 0.

          10 years pfSense! 2006 - 2016

          1 Reply Last reply Reply Quote 0
          • JeGrJ
            JeGr LAYER 8 Moderator
            last edited by

            @tpf said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:

            nach meinem Verständnis und allen Installationen, die ich bisher so gemacht habe, muss bei einer SPI-Firewall nicht mehr gemacht werden, als ausgehend eine Verbindung zu den SIP-Servern aufzubauen. Außer natürlich static port im outgoing NAT. Sonst hörst nix.

            Und ich möchte auch nichts gegen dein Verständnis oder deine Erfahrung anführen, aber wir hatten das hier schon mehrfach, dass es zwar "solala" ging, aber ließ man den Service Provider auch inbound rein, gings plötzlich richtig. Nicht immer sind leider die technisch affinen Mädels und Jungs an den Stellen, die die Infos weitergeben. Und dann halten sich ggf. hartnäckig andere Fakten. Wenn ich aber von Telekom Seite solche Streams inbound sehe, würde ich die mit deinen Problemen einfach testweise für ne Woche aufmachen. Ggf. mit deren Source Restriction, dass es nur TCom Adressen sein dürfen und nicht jedermann.

            @tpf said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:

            Aus irgendwelchen Gründen kappt mir die Firewall das Gespräch und mir ist nicht klar, weshalb. Was ich via pftop so sehe, sieht alles gut aus. Sitzungen werden verlängert und keine geht auf 0.

            Das kann auch (siehe andere Threads) wie bei einem unserer Kunden einfach Implementationssache sein. SIP ist da leider wie IPSEC. Jeder bastelt seinen eigenen S.....cheibenkleister und wir dürfens ausbaden. Daher: testet es doch einfach und schaut, was bei rauskommt. Wenns nichts ändert ist auch nichts kaputt(er als vorher) und man kann ggf. bei deren Support weiter eskalieren.

            Grüße

            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

            1 Reply Last reply Reply Quote 0
            • R
              ramup
              last edited by ramup

              @JeGr

              Danke. Ich denke du meinst eine solche Regel? Wäre diese richig konfiguriert?

              alt text

              Zur Info: 10.21.33.2/24 ist die Anlage als einzige IP in dem Subnet, mit Ausnahme von pfSense als 10.21.30.1/24.

              Grundsätzlich sollte meiner Auffassung nach (abweichend vom Bild) TCP für 5060 bzw. 5061 reichen, da laut technischem Dokument von SIP-Trunk folgende Ports verwendet werden:

              5.8 Benutzte Ports und ÜbertragungsProtokolle

              • UDP (out): Ports 53, 123, 30000-31000, 40000-41000, 3478, 3479
              • UDP (in): Ports 5070, 5080, 30000-31000, 40000-41000
              • TCP (out): Port 53, 80, 443, 5060, 5061

              in/out ist immer aus Sicht der TK-Anlage gemeint
              Plattformseitiger RTP Portrange ist 9000-18000

              Ich könnte auch für alle Ports eine statische Regelzuweisung machen, sowohl UDP wie TCP.
              Wie konfiguriert man in der pfsense bei einer Regel mehrere Ports? Soweit ich sehe wird ein Portrange mit "XX:XX+1" angegeben, aber z.B. "Y,XX:XX+1" für mehrere Ports einschließlich einer Portrange wird nicht akzeptiert.

              Soweit ich sehe hat sich das Problem derzeit wahrscheinlich durch die Deaktivierung des Session Timers in der Anlage gelöst, auch ohne statische Portzuweisungen. Zumindest ist es mir bei den letzten Gesprächen nicht mehr aufgefallen, wobei es eben auch nicht immer aufgetreten ist. Ich würde allerdings eine Löung mit Session Timer aus Sicherheitsgründen bevorzugen.

              JeGrJ 1 Reply Last reply Reply Quote 0
              • T
                tpf
                last edited by

                @JeGr
                Ja, ich versuche es mal. Allerdings war ich eben an einem quasi identischen Anschluss. Ebenfalls pfS, ebenfalls Fritte 7390 als TK-Anlage, ebenfalls Telekom. Alles identisch, sogar die Hardware. Bis auf: ADSL2+ vs VDSL und auf der anderen pfS gibts kein pfBlockerNG.

                Gespräche beliebiger Länger kein Problem. Es ist zum Auswachsen.

                10 years pfSense! 2006 - 2016

                T 1 Reply Last reply Reply Quote 0
                • JeGrJ
                  JeGr LAYER 8 Moderator @ramup
                  last edited by

                  @ramup said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:

                  aber z.B. "Y,XX:XX+1" für mehrere Ports einschließlich einer Portrange wird nicht akzeptiert.

                  Einfach ein Portalias erstellen. Den müsste man an der Stelle verwenden können.

                  Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                  If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                  1 Reply Last reply Reply Quote 0
                  • R
                    ramup
                    last edited by

                    @JeGr said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:

                    Einfach ein Portalias erstellen. Den müsste man an der Stelle verwenden können.

                    Danke, das mit dem Port Alias funktioniert.

                    EIne Frage habe ich noch. Grundsätzlich werden die statischen Portzuweisungen ja im Outbound NAT gemacht, also für die Verbindung z.B. der TK-Anlage zu der Telekom im WAN.
                    Ist eine Regelung des Inbound NAT nicht nötig oder wo ergeben sich dort die Unterschiede? Also eine Verbindung die vom WAN kommt zu der z.B. TK-Anlage.

                    Oder ist aufgrund der Nutzung der Telekom der TCP/UDP Verbindung, die von der TK-Anlage kommt und für Gespräche etc. genutzt werden nur das outbpund NAT nötig, da dies auch für den "Rückkanal" gilt?

                    1 Reply Last reply Reply Quote 0
                    • JeGrJ
                      JeGr LAYER 8 Moderator
                      last edited by

                      @ramup said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:

                      Ist eine Regelung des Inbound NAT nicht nötig oder wo ergeben sich dort die Unterschiede? Also eine Verbindung die vom WAN kommt zu der z.B. TK-Anlage.

                      Nein warum? Dort muss die sendende Seite ja darauf achten, dass ihre Source Port Zuweisung gleich bleibt. Das ist als Empfänger ja nicht dein Problem. Du NATtest es ggf. höchstens nach hinten ins LAN rein, aber dabei bleibt der Port im Normalfall gleich. Es geht um Source Port Scrambling, was die pfSense abgehend im NAT per default macht um Zielservern/Diensten zu erschweren zu raten, ob die Verbindungen vom gleichen Gerät stammen und um MITM Angriffe mit Portsequenzen zu unterbinden. Gerade OS mit schwachem oder keinem Port Scrambling waren da früher für anfällig, dass man wusste "Oha da kommt ein Windoof, der spricht jetzt die nächsten 20 Requests von Port 5917+1, +2, +3, etc." - damit waren diverse Angriffe denkbar. Daher wird beim Outbound NAT die Zuweisung nochmals wild randomisiert, so weiß außen niemand, ob das 1, 2 oder 10 PCs sind und tut sich daher schwerer, eine vorhandene Verbindung zu kapern/erraten.

                      Was ansonsten für SIP/Telekom wirklich nötig ist, weiß nur die Telekom. Ich würde bei ankommenden Anfragen beim Klingeln aber sicherheitshalber das aufmachen und reinlassen was anklopft, vor allem wenns Probleme gibt ;)

                      Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                      1 Reply Last reply Reply Quote 0
                      • T
                        tpf @tpf
                        last edited by

                        @tpf said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:

                        @JeGr
                        Ja, ich versuche es mal. Allerdings war ich eben an einem quasi identischen Anschluss. Ebenfalls pfS, ebenfalls Fritte 7390 als TK-Anlage, ebenfalls Telekom. Alles identisch, sogar die Hardware. Bis auf: ADSL2+ vs VDSL und auf der anderen pfS gibts kein pfBlockerNG.

                        Gespräche beliebiger Länger kein Problem. Es ist zum Auswachsen.

                        Falls es jemanden interessiert, ich habe die Lösung für das Gesprächsproblem gefunden. Es lag am Netzteil der Fritte. Anscheinend läuft alle 15 Minuten auf der Fritte irgendein leistungshungriger Prozess, der einen Aussetzer im Verkehr erzeugt. Dieser genügt für den Gesprächsabbruch. Seit ich das Netzteil ausgetauscht habe, läuft alles einwandfrei.

                        Unglaublich...

                        10 years pfSense! 2006 - 2016

                        1 Reply Last reply Reply Quote 1
                        • JeGrJ
                          JeGr LAYER 8 Moderator
                          last edited by

                          @tpf said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:

                          Es lag am Netzteil der Fritte

                          😳

                          @tpf said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:

                          Unglaublich...

                          Mehr fällt mir dazu auch nicht ein. Wirklich unglaublich.

                          Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                          If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

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