VoIP - Quizfrage zu tel2.congstar.de sowie Fake News und Zensur

Zur Frage 2 ein kleiner Hinweis zu tel2.congstar.de :

- tel2.congstar.de ist lediglich ein Alias für tel2.congstar.qsc.de.
- die QSC nutzt im DNS-Server sogenannte Service Records SRV RR für den SIP-Service

Unter Linux lässt sich damit wie folgt die Serviceinformation abrufen:

dig SRV _sip._udp.tel2.congstar.qsc.de

Das Ergebnis sieht dann so aus:

; <<>> DiG 9.13.7 <<>> SRV _sip._udp.tel2.congstar.qsc.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55496
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_sip._udp.tel2.congstar.qsc.de. IN SRV

;; ANSWER SECTION:
_sip._udp.tel2.congstar.qsc.de. 10800 IN SRV 10 5 5060 farm3.tel2.congstar.qsc.de.
_sip._udp.tel2.congstar.qsc.de. 10800 IN SRV 20 5 5060 farm2.tel2.congstar.qsc.de.
_sip._udp.tel2.congstar.qsc.de. 10800 IN SRV 20 5 5060 farm1.tel2.congstar.qsc.de.
_sip._udp.tel2.congstar.qsc.de. 10800 IN SRV 10 5 5060 farm4.tel2.congstar.qsc.de.

;; AUTHORITY SECTION:
tel2.congstar.qsc.de. 10800 IN NS ns02.qsc.de.
tel2.congstar.qsc.de. 10800 IN NS ns01.qsc.de.

;; ADDITIONAL SECTION:
farm3.tel2.congstar.qsc.de. 10800 IN A 213.148.137.5
farm4.tel2.congstar.qsc.de. 10800 IN A 213.148.137.21
farm1.tel2.congstar.qsc.de. 10800 IN A 213.148.136.3
farm2.tel2.congstar.qsc.de. 3483 IN A 213.148.136.11

Damit spart sich die QSC einen Loadbalancer, da hier mehrere Hosts (IP's) im SRV Record
mit unterschiedlichen Prioriäten 10/20 für den SIP-Service sowie Portnummern hinterlegt sind.

Somit können aus der Kundensicht folgende Server für VoIP benutzt werden:

farm1.tel2.congstar.qsc.de
farm2.tel2.congstar.qsc.de
farm3.tel2.congstar.qsc.de
farm4.tel2.congstar.qsc.de

Hallo Marco, Hallo Sebastian,

vielen Dank für die Info. Es freut mich, dass auf meine Fragen eingegangen wurde.
Der Teufel steckt jedoch im Detail, daher möchte ich noch ein paar Ergänzungen
zu den Statements hinzufügen, damit das Gesamtbild ein wenig klarer wird.

Zitat von sebastian

1. Wie lautet die offizielle IP-Adresse für die Subdomain tel2.congstar.de ?
2. Warum ist die Namensauflösung bei der QSC (neuer Telefon-Registrar) für die Subdomain tel2.congstar.de nach wie vor nicht möglich ?
Der fully qualified domain name tel2.congstar.de löst auf tel2.congstar.qsc.de auf und ein SRV Lookup auf tel2.congstar.qsc.de gibt die Ziele farm1.tel2.congstar.qsc.de sowie farm2.tel2.congstar.qsc.de zurück. Diese letztgenannten Ergebnisse sind via PING erreichbar und auflösbar. Die Namensauflösung funktioniert also, aber nur als SRV Lookup.

Auch wenn ich es ungern zugeben möchte, die Telekom/Congstar macht hier einiges richtig. Im Gegensatz zur QSC,
meiner Meinung nach. Ich werde das einmal kurz erläutern.

Vorneweg noch ein paar Fakten.
Ein SRV-lookup für tel2.congstar.qsc.de liefert 4 hosts zurück, wie ich in meinem 2. Post weiter oben erläutert
habe. Diese 4 hosts (farm1-4) sind ausdrücklich nicht mittels ping (icmp) erreichbar.
Der QSC Firewall-Admin wird das aus Sicherheitsgründen abgestellt haben, also bitte bei der Wahrheit bleiben.

Problem Namensauflösung:
Die Namensauflösung für tel2.congstar.de funktioniert nicht wie erwartet. Unter Namensauflösung ist die Beziehung
zwischen der Subdomain tel2.congstar.de und einer IP-Adresse gemeint. Der Name tel2.congstar.de liefert keinen
gültigen A-Record zurück, weil es lediglich ein Alias (CNAME) für tel2.congstar.qsc.de beinhaltet.
Kurz, der Name tel2.congstar.de liefert dem Client keine IP-Adresse zurück. Vereinfacht dargestellt,
keine IP-Adresse bedeutet auf Netzwerkebene, keine Verbindung zum neuen Gateway!

Hinter der Subdomain tel2.congstar.qsc.de ist ebenfalls kein A-Record hinterlegt, somit erhält der Resolver (client)
ebenfalls keine gültige IP-Adresse zurück. Die QSC hat in ihrem DNS-Server ns01.qsc.de/ns02.qsc.de keinen A-Record
für die Subdomain tel2.congstar.qsc.de hinterlegt.

Jetzt fragt Du Dich wahrscheinlich, was hat das denn für Implikationen bei einem VoIP-Anbieterwechsel von
der Telekom/Congstar zur QSC ?

Das ist ganz einfach am Beispiel von der Asterisk Telefonanlage zu erklären, wobei Asterisk ist hier nur
stellvertretend für viele VoIP-Clients aufgeführt wird:

Die Standardeinstellung für Asterisk beinhaltet keinen SRV-lookup, demnach versucht Asterisk über die
reguläre Namensauflösung eine Verbindung zu tel2.congstar.de aufzubauen und schlägt fehl,
weil keine gültige IP-Adresse vom DNS-Server zurückgeworfen wird.

Gut - jetzt kommt der Einwand, das Problem liegt dann wohl bei der Asterisk Anlage auf Kundenseite, weil die halt in der Standardkonfiguration keinen SRV-lookup durchführt. Ja Pustekuchen, selbst wenn die Einstellung in der Konfiguration
unter [general] mit srvlookup=yes konfiguriert wird, ist bei dem Wechsel von Congstar zur QSC trotzdem keine
Verbindung zum neuen VoIP-Gateway möglich, da für tel2.congstar.de keine SRV Einträge im DNS vorhanden sind. Hat da
jemand geschlafen oder ist es ein Designfehler.

Als Fallback versucht Asterisk immer eine gültige IP-Adresse für tel2.congstar.de zu ermitteln, und schlägt fehl. Demnach kann auch keine Verbindung mit dem neuen Telefon-Registrar (tel2.congstar.de) hergestellt werden, welcher per Post und Mail an den Kunden kommuniziert wurde.

Ich hoffe, dass das Dilemma mit tel2.congstar.de einigermaßen deutlich geworden ist. Mit dieser Erkenntnis lässt sich
das Dilemma aber auch recht simpel auflösen.

Lösung 1: Der hostmaster von der QSC entfernt den CNAME für tel2.congstar.qsc.de und hinterlegt für tel2.congstar.de
die entsprechenden SRV Einträge, demnach quasi copy und paste von tel2.congstar.qsc.de zu tel2.congstar.de.

Die Asterisk-Telefonanlage führt dann einen SRV-lookup für tel2.congstar.de durch, erhält die benötigten Information
für die 4 hosts (farm1-4) und gut ist.

Lösung 2: Das ist für Congstar recht schnell und einfach machbar. Statt dem Kunden mitzuteilen, er solle für den Telefon-Registar tel2.congstar.de benutzen, würde es vollkommen ausreichen, auf die Subdomain tel2.congstar.qsc.de hinzuweisen. Dann wird alles schnell wieder gut.

Die Asterisk-Telefonanlage führt dann ebenfalls einen SRV-lookup für tel2.congstar.qsc.de durch, erhält die benötigten Information für die 4 hosts (farm1-4) und ebenfalls gut ist.

Bsp. Kundenkommunikation (Mail,Post):
"Bei der Einstellung Ihrer Telefonie-Zugangsdaten muss, sofern Sie mehrere Rufnummern nutzen, für jede Rufnummer einzeln eine Anpassung vorgenommen werden:

Ihre relevanten Daten:

Rufnummer: 123456
SIP-Benutzername der Rufnummer: 123456
Telefoniepasswort: neues pw
SIP-Registrar (Host): tel2.congstar.qsc.de
"

Lösung 3: Die QSC lernt von der Telekom/Congstar und verändert ihre IT-Infrastruktur wie folgt:

In dem Loadbalancer wird nur 1 offizielle NAT-IP (IPv4) für das VoIP-Gateway definiert, im DNS Server
nur 1 SRV Eintrag hinterlegt sowie ein A-Record für tel2.congstar.qsc.de (offizielle NAT-IP-Adresse).

Die 4 hosts in der DMZ (farm1-4) wandern in den Pool für das VoIP-Gateway und werden dann über den Loadbalancer
angesprochen.

Das hätte nebenbei auch den Vorteil, das die VoIP-Clients, welche kein srvlookup durchführen, als Fallback immer eine gültige IP-Adresse erhalten (siehe A-Record). Ein reibungsloser Wechsel von Congstar zur QSC ist damit, sofern keine anderen Probleme (PW-Synchronisation) vorhanden sind, jedenfalls immer gewährleistet.

Ein weiterer Vorteil ist auch, dass nur 1 offizielle NAT-IPv4 Adresse benutzt wird, und die restlichen 3 IPv4 Adressen für andere Services genutzt werden können. Meiner Meinung nach ist auch der - mit Verlaub - verschwenderische Umgang mit offiziellen IPv4 Adressen wie im Falle der QSC keine gute Idee.

Zitat von sebastian

3. Ist die Begründung für die VoIP Umstellung nicht richtigerweise: Die QSC übernimmt nun die techn. VoIP Abwicklung für sämtliche Congstar Kunden ?!
Ja, aber das hätte in der Detailtiefe vermutlich viele Kunden verwirrt. QSC hat auch vorher schon einen Teil der congstar Kunden mit VoIP bedient und es gibt sogar Kunden die auch das Internet über QSC realisiert bekommen => Ist also auch nichts sooo neues.

Warum nicht einfach mal bei der Wahrheit bleiben - dem Kunden interessiert doch letztendlich nur, ob er seine IP-Telefonie
nach der Umstellung in gewohnter Qualität weiternutzen kann. Wie ich bereits weiter oben beschrieben habe, ist der Umgang mit VoIP seitens der QSC im Detail nun mal anders, wie es bsp. die Telekom/Congstar macht. Das ist für mich als ehemaliger Kunde der Telekom schon relevant und wie sich herausgestellt hat, hatte ich mit einem Telefonie-Ausfall von knapp 2 Monaten! zu kämpfen. Gelinde formuliert ist das in der heutigen Zeit inakzeptabel.

Zitat von sebastian

4. Warum reagiert der Kundenservice nicht auf mein Anliegen ?
Es wurde bereits umfassend probiert dir zu helfen, wobei es im Endeffekt nur mehr um eine Gutschrift ging und nicht mehr um die Hilfe bei diesen Fragen. Support können wir in erster Linie für alle Router bieten, die wir auch selber anbieten.

Von Woche zu Woche vom SupportChat/Mail vertröstet zu werden ohne eine Verbesserung der aktuellen Lage ist nicht ok.
Ursache dafür war ganz klar die VoIP-Umstellung zur QSC. Das ist wie ich weiter oben erläutert habe, kein Problem
auf der Kundenseite. Dabei spielt es auch keine Rolle, welcher Router benutzt wird. Daher auch mein Eindruck,
der Congstar-Support hätte die Ursache des Problems im Detail nicht verstanden oder ernst genommen. Ich habe daraufhin selbst das Problem analysiert und dem Supportchat die Thematik wie weiter oben beschrieben mitgeteilt.

Mir wurde eine Gutschrift für den Telefonie-Ausfall für die 2 Monate von Frau Franke in Aussicht gestellt, welche in meinem Fall auch angemessen ist. Ich sollte lediglich meine Rechnungen für die 2 Monate an den Congstar Support per mail schicken. Das habe ich auch umgehend im November 2018 gemacht. Heute haben wir den April 2019, immer noch ohne die versprochene Gutschrift.

Zitat von sebastian

6. Das neue Passwort war in meinem Fall auch nicht korrekt. Sind hier unterschiedliche Datenbanken im Einsatz oder unterstützt es meine These in der Frage 3 ?
Hier ist erstmal kein Fehler zu erkennen. Im Zuge der Migration an die QSC wurde dein PW korrekt bei QSC gesetzt. Warum die Einrichtung deinerseits nicht Funktioniert hat, kann so nicht nachvollzogen werden.

Gut das meine These bestätigt wurde, das schafft Klarheit.
Eine Verbindung zu dem neuen VoIP-Gateway der QSC konnte nun nach längerer Zeit und mit viel Aufwand auf der Netzwerkebene wieder hergestellt werden, dennoch wurde das neue Passwort nicht akzeptiert.
Nochmal - das neue Passwort wurde seitens QSC nicht akzeptiert !
In dem SupportChat habe ich deshalb darum gebeten, man möge mir bitte das neue Passwort einmal resetten. Siehe da, auf einmal funktionierte die Telefonie wieder, nach knapp 2 Monaten Telefonieausfall! Jetzt finde mal den Fehler.

Zusammenfassend nochmal in Kürze:

a) Die Verbindung zum neuen VoIP Gateway der QSC konnte aufgrund des Dilemmas mit tel2.congstar.de auf Netzwerkebene nicht hergestellt werden.
b) Das neue VoIP Gateway der QSC akzeptierte das neue Passwort nicht.
c) Die Gutschrift für den Telefonie-Ausfall ist noch nicht erfolgt.
d) Für geplante bzw. zukünftige VoIP-Umstellungen habe ich Euch nun 3 Lösungsvorschläge unterbereitet, wobei die ersten 2 Lösungsvorschläge wirklich einfach umzusetzen sind. Für den 3. Lösungsvorschlag habt Ihr doch als Vertragspartner der QSC sicherlich auch ein gewisses Mitspracherecht. Für welche Lösung ihr Euch letztendlich entscheidet, bleibt natürlich Euch überlassen.

Fakt ist jedoch, da besteht nach wie vor akuter Handlungsbedarf. What say you ?

Asche auf mein Haupt Mario, das war keine Absicht.

Bei dem Lösungsvorschlag 1 ist mir auch ein kleiner Fehler passiert:

Anstelle von "Der hostmaster von der QSC" müsste es richtigerweise lauten,
der hostmaster der Telekom, da die Telekom für die Zone zuständig ist.