DNS-SRV-Eintrag für SIP über TCP fehlt

Servus,

interessanter Punkt. Eine (sehr) schnelle Recherche zeigte dass Control Plane (also SIP) über TCP und Data Plane (also Voice) über UDP wäre die elegante Lösung. Ich werde diese aber mal interessenshalber vertiefen, bevor man zu schnell urteilt.

Deine DNS auflösungen zeigen aber einen Control Plane (also SIP) über UDP.

Ich denke aber auch generell dass das Thema VoIP für Festnetzprodukte überarbeitet gehört (unabhängig vom TCP/UDP thema)… die Frage ist allerdings eben wieviel Geld Telefonica hierfür bereitstellen möchte, wenn es “so ja auch geht”.

Eventuell ist aber auch die DNS konfiguration von Telefonica korrekt.

Dazu kommt, der zu auflösende Endpunkt für die Registrierung ist ja sip.alice-voip.de, und diesen wird wohl so wie ich dich verstehe über TCP angesprochen.

(und sei es ein simpler CNAME auf die UDP-Version)

Die Firewall interessiert sich ja auch nicht wirklich für den DNS namen, das würde in deinem Vorschlag aber bedeuten dass weiterhin UDP transportiert wird, denn das Ziel (hinter dem CNAME) möchte ja UDP haben. Aber das geht dann gegen dein Ziel

aus Gründen der Firewall-Vereinfachung

Moin,

ich meine natürlich nur den reinen SIP-Verkehr – RTP, also Audio, fließt in jedem Fall weiterhin über UDP.

Der Vorteil der SIP-Registrierung per TCP gegenüber UDP ist:
Wenn ich mich per UDP registriere, sende ich die SIP-Daten per UDP zu Server A und halte diese Verbindung durch Keepalives auch offen, aber eingehende Anrufe werden eventuell von Server B signalisiert. Der perlt aber natürlich an der Firewall ab, weil das von B kommende INVITE-Paket nicht zu einer bekannten Verbindung gehört, also “unsolicited” ist.
Bei TCP kann das prinzipbedingt nicht passieren, da in dem Fall nur über den bereits geöffneten TCP-Kanal kommuniziert werden darf. Dadurch eignet sich SIP über TCP besser für Szenarien, wo der SIP-Port der Telefonanlage nicht ins Internet exponiert sein soll.

Dazu kommt, der zu auflösende Endpunkt für die Registrierung ist ja sip.alice-voip.de, und diesen wird wohl so wie ich dich verstehe über TCP angesprochen.

DNS-SRV funktioniert so, dass man einen “Basis-Namen” nimmt, in diesem Fall “sip.alice-voip.de” und diesen in die Telefonanlage als Registrar-Server einträgt und einstellt, ob man sich per UDP, TCP oder TLS verbinden will. Die Telefonanlage stellt automatisch einen Präfix voran, der aus Dienst- und Transport-Protokoll besteht – bei SIP über UDP entsprechend “_sip._udp.” und fragt dazu dann den Typ SRV ab. Bei TCP funktioniert das natürlich genauso, nur halt mit “_tcp” im Präfix. Das passiert normalerweise komplett im Hintergrund und “funktioniert einfach”.

Wenn kein SRV-Eintrag mit den entsprechenden Präfixen gefunden wird, fällt die Telefonanlage auf den reinen A-Record auf dem Basisnamen zurück. Da ich bei mir explizit die Verwendung von TCP angewiesen habe, fragt die Telefonanlage auch entsprechend nach “_sip._tcp.sip.alice-voip.de SRV”, findet aber nichts, fragt dann nach “sip.alice-voip.de A” und nutzt die IP, die dann zurückkommt.
Ich habe aber getestet: Die Server, die bei der Frage nach UDP geliefert werden reagieren auch auf TCP und lassen Registrierungen per TCP zu.

Es wäre daher – als schnelle/einfache/wartungsarme Lösung – vollkommen OK, wenn ein CNAME von “_sip._tcp” auf “_sip._udp” zeigen würde. Ein CNAME selbst ist ja nichts weiter als die Anweisung, einen anderen Namen anzufragen und die darüber erhaltene Antwort so zu nehmen, als hätte man sie als Antwort auf die ursprüngliche Anfrage enthalten. Für die Telefonanlage wäre es daher vollkommen unerheblich, ob die gelisteten Server aus dem SRV-Record durch einen “echten” SRV-Eintrag oder einen CNAME-Verweis ermittelt wurden.

Verstehe. Ich komme sicherlich erst in eine Weile dazu, mich da überhaupt genauer in dem Thema einzulesen (dann eben Interessenshalber), aber das hört bzw. liest sich schlüssig an.

Es wäre daher – als schnelle/einfache/wartungsarme Lösung – vollkommen OK, wenn ein CNAME von “_sip._tcp” auf “_sip._udp” zeigen würde. Ein CNAME selbst ist ja nichts weiter als die Anweisung, einen anderen Namen anzufragen und die darüber erhaltene Antwort so zu nehmen, als hätte man sie als Antwort auf die ursprüngliche Anfrage enthalten.

Das war mir schon klar, daher schrieb ich ja auch meine Passage dazu :)

Allerdings fehlte mir eben die Information, dass wohl

Die Server, die bei der Frage nach UDP geliefert werden reagieren auch auf TCP und lassen Registrierungen per TCP zu

In diesem Fall macht das dann auch Sinn. Ich hatte erwartet, dass sie explizit nur UDP möchten und da wäre es natürlich nicht möglich die dann per TCP anzusprechen.

Nach wie vor spannendes Thema, mal sehen was Telefonica hier macht.

Jedenfalls danke für deine Erläuterungen

Hallo ​@LordGurke,

schön, dass du hier bei uns in unserer o2 Community fragst 🙂

Ich habe mal begonnen, nach einem Ansprechpartner bei uns zu schauen, damit wir mehr herausbekommen und nach der Möglichkeit einer Lösung suchen können 🙂

Viele Grüße,

Gerrit

​@LordGurke  Vielleicht besteht auch noch ein Denkfehler bei der Geschichte

Wenn ich mich per UDP registriere, sende ich die SIP-Daten per UDP zu Server A und halte diese Verbindung durch Keepalives auch offen, aber eingehende Anrufe werden eventuell von Server B signalisiert. Der perlt aber natürlich an der Firewall ab, weil das von B kommende INVITE-Paket nicht zu einer bekannten Verbindung gehört, also “unsolicited” ist.

Nach meinen früheren Erfahrungen ist SIP nur für den Rufaufbau verantwortlich. Der Audio-Kanal des Gespräches läuft dann über RTP/SRTP.  Somit wäre SIP über Port 506x frei. Der RTP-Port liegt auch weit weg. 

Es hat wegen DNS-SRV auch schon die Umgehungsmöglichkeit gegeben die IP direkt einzutragen - allerdings mit dem Risiko der IP-Änderung. Vielleicht ist das ein Ansatzpunkt?

​@Klaus_VoIP Genau, nur der Signalisierungspfad (also SIP) wird über TCP geführt, der RTP-Stream bleibt UDP. Letzteres ist aber auch nicht das Problem, das funktioniert bei Stateful Firewalls einfach so.

Problematisch ist nur die SIP-Registrierung per UDP, weil es zum einen aufwendiger ist, diesen Kanal durch die Firewall offenzuhalten, aber auch, weil ich von unerwarteten IP-Adressen INVITE-Pakete für eingehende Anrufe bekommen habe – die dann von der Firewall aufgegessen wurden (siehe erster Absatz hier).

Ich will einfach vermeiden, meinen SIP-Port ins Internet zu exponieren. Oder IP-Whitelists dafür zu pflegen. Deshalb registriere ich mich einfach per TCP, da habe ich all diese Probleme einfach nicht :-)

Ich wollte einen kurzen Zwischenstand geben, @LordGurke, unsere Anfrage läuft weiter 🙂

Viele Grüße,

Gerrit

Wir haben inzwischen Rückmeldung erhalten, ​@LordGurke: Bei uns wird in der Tat kein SIP über TCP unterstützt und es ist vor allem zum jetzigen Zeitpunkt auch kein Support über TCP in Planung.

Viele Grüße,

Gerrit

Hallo ​@LordGurke,

du schreibst, dass du den sip.alice-voip.de per tcp/5060 erreichen kannst. Bist du dir sicher, dass das geht?

Ich bin o2-DSL-Kunde und kann sip.alice-voip.de ausschließlich per udp/5060 erreichen, was mir die gleichen Bauchschmerzen bereitet, wie du oben beschrieben hast.

Könntest du das deswegen bitte nochmal verifizieren, ob sip.alice-voip.de bei dir immernoch via tcp/5060 erreichbar ist? Und falls ja: bist du DSL- oder Kabel-Kunde?

Ich habe das gerade zur Sicherheit nochmal mit Wireshark verifiziert: Ich kann mich über `sip.alice-voip.de` per TCP registrieren. Zugang ist DSL.

Hey zusammen :) 

Ich kann zwar, ähnlich wie Gerrit, leider nicht helfen, find’s aber trotzdem sehr spannend, wie ihr euch mit der Materie beschäftigt. Bitte weiter so 💙

Viele Grüße,
Flo

Hallo ​@LordGurke,

vielen lieben Dank, dass du es extra für mich nochmals getestet und sogar einen Wireshark-Screenshot beigefügt hast. Das ist wirklich sehr lieb von dir, dass du dir extra die Mühe gemacht hast.

Ich habe mich deswegen nochmals damit beschäftigt und konnte herausfinden, dass meine Fritzbox der Übeltäter war. Diese hatte 5060/tcp geblockt. Nun geht es also auch bei mir per TCP. Vielen Dank, du hast mir damit wirklich sehr geholfen. ♥️

Ok, zurück zu deinem Thema: auch ich finde es schade, dass o2 nicht bereit ist, passende SRV-Records für TCP zu hinterlegen. Du hast ja erklärt, warum dies sinnvoll ist, und sogar bis ins Detail aufgezeigt, was nötig ist.

Ich habe deswegen die Konsequenz gezogen und werde in den kommenden Tagen meinen Vertrag bei o2 kündigen und zur Telekom wechseln - dort wird TCP für SIP unterstützt und auch die SRV-Records sind korrekt gesetzt.

Liebe Grüße,

Luca

Hey ​@LucaKarotte,

tut mir Leid, dass wir dir bei deinem Anliegen bzw. deinem technischen Wunsch nicht weiterhelfen konnten :/ Vielleicht ergibt sich der Umstand ja irgendwann in Zukunft nochmal und du kehrst zu uns zurück. Weiterhin alles Gute!

Viele Grüße,
Flo