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