VoIP mit Gigaset N510 IP Pro an eigenem Router: keine Anrufe

1. Firewall auf meinem Router komplett deaktivierern.
2. Die O2 DNS-Server statt meines eigenen verwenden.

# block corrupt or dangerous packets
block in log quick from any to any with ipopts
block in log quick proto tcp from any to any with short
block in log quick from any to any with frag
block in log quick from any to any with opt lsrr
block in log quick from any to any with opt ssrr

# allow IPSec
pass in quick proto 4 from any to any
pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto udp from any to any
pass out quick proto 4 from any to any
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto udp from any to any

# allow loopback
pass out quick on lo0 from any to any
pass in  quick on lo0 from any to any

# allow LAN
pass out quick on re0 from any to any
pass in  quick on re0 from any to any

# block packets from reserved addresses
block in log body quick on pppoe0 from 192.168.0.0/16 to any
block in log body quick on pppoe0 from 172.16.0.0/12 to any
block in log body quick on pppoe0 from 10.0.0.0/8 to any
block in log body quick on pppoe0 from 127.0.0.0/8 to any
block in log body quick on pppoe0 from 0.0.0.0/8 to any
block in log body quick on pppoe0 from 169.254.0.0/16 to any
block in log body quick on pppoe0 from 192.0.2.0/24 to any
block in log body quick on pppoe0 from 204.152.64.0/23 to any
block in log body quick on pppoe0 from 224.0.0.0/3 to any
block out log body quick on pppoe0 from any to 192.168.0.0/16
block out log body quick on pppoe0 from any to 172.16.0.0/12
block out log body quick on pppoe0 from any to 10.0.0.0/8
block out log body quick on pppoe0 from any to 127.0.0.0/8
block out log body quick on pppoe0 from any to 0.0.0.0/8
block out log body quick on pppoe0 from any to 169.254.0.0/16
block out log body quick on pppoe0 from any to 192.0.2.0/24
block out log body quick on pppoe0 from any to 204.152.64.0/23
block out log body quick on pppoe0 from any to 224.0.0.0/3

(Hier folgt Microsoft, Facebook - viele Netze!)

zone "alice-voip.de." IN {
        type forward;
        forward only;
        forwarders { 62.109.121.1; 62.109.121.2; };
};

• RTP-Bereich liegt bei 50.000 (nicht 5000 !!!)

Und STUN kann man auch von anderen Anbietern testen.

Ja ich kann zwar auch die Abfrage auf einen DNSServer legen habe ich aber nicht,
Dann müsstest Du ja nur die FW für die eine IP öffnen...

Seit einigen Monaten (ca. Anfang des Jahres) sind die Probleme wieder da: Anrufe kommen zum größten Teil nicht an. Ich war lange Zeit zu müde den Fehler zu suchen und hoffte daß er wieder verschwindet, aber die letzten Tage mußte ich das dann doch analysieren (zunehmende Proteste von Anrufern).

Ich habe die Ursache gefunden, und will sie hier dokumentieren da sie für andere Besitzer von Gigaset N510 IP Pro und ähnlichen Basisstationen interessant sein dürfte. Vielleicht auch für O2, denn die Lösung gehört möglicherweise in die Dokumentation zur Einrichtung von VoIP.

Ich habe lange Zeit kein Muster gefunden. Die Ausfälle waren ca. 80% und gefühlt mehr von Mobiltelefonen. Beim Tracen der eingehenden SIP-Pakete (im Gegensatz zum Fehler von vor 2 Jahren gingen welche ein!) kamen scheinbar ganz normale INVITE Requests an der Basisstation an, die aber meistens ignoriert wurden. Nur manchmal nicht.

Schließlich fiel mir auf daß diese UDP SIP-INVITE Pakete oft von einem weiteren winzigen UDP-Paket gefolgt werden, dessen Bedeutung unklar war. Beim Anschauen des Inhalts bemerkte ich einige abgeschnittene Zeichen eines Wortes, wie “ication”. Mir wurde klar was passiert ist als ich auf das Ende des vorausgegangen INVITE-Pakets blickte, das mit “Appl” endete und eine Größe von 1506 Bytes hat. Die MTU wurde überschritten und das INVITE Paket ist fragmentiert!

Die Basisstation scheint nicht in der Lage zu sein fragmentierte UDP SIP Pakete wieder zusammenzusetzen. Und laut RFC 3261 (SIP) muß sie das auch nicht. Siehe Paragraph 18.1.1 RFC3261 :

18.1.1 Sending Requests

   The client side of the transport layer is responsible for sending the
   request and receiving responses.  The user of the transport layer
   passes the client transport the request, an IP address, port,
   transport, and possibly TTL for multicast destinations.

   If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP.

Ich weiß jetzt nicht ob der Fehler im Ausgangsnetz liegt, wo die Anfrage entsteht, oder bei O2, die so ein großes UDP-Paket erzeugen oder weiterleiten. Oder an mir, weil ich so dumm war SIP über UDP zu konfigurieren. Meine Einstellung an der Basisstation war schließlich “nur UDP verwenden” (siehe erstes Posting), was hier fatal ist!

Da die Paketgrößen sich ziemlich nahe an der MTU bewegen erklärt das auch warum es manchmal funktioniert. Manchmal sind Telefonnummer kürzer, oder andere Texte im INVITE, so daß es gerade noch durchging.

Also die Lösung ist: bei O2 funktioniert SIP nur noch über TCP - nicht mehr über UDP!

Als Vergleich sind die INVITE Pakete bei der Telekom nur halb so groß, und machen generell keine Probleme...

Hallo @phx_hf,

herzlich willkommen zurück und vielen Dank für den wertvollen Hinweis. Das erklärt natürlich auch, warum es manchmal geklappt hat und dann wieder nicht.

Falls noch Fragen offen sein sollten, lass es uns gerne wissen.

Viele Grüße

Giulia