SIP-Registrierung künftig nur per SRV-Record möglich

[michael4]

Die Schuld ist hier einzig und allein beim Hersteller zu suchen. Wenn der das Protokoll unvollständig implementiert, ist dies als mangelhaft anzusehen. Ich würde mir von diesem Hersteller kein einziges Produkt mehr kaufen.
Was anderes wäre, wenn das ein Feature wäre, was nach Launch des Produkts gekommen ist. Aber hier handelt es sich um ein Feature, was bereits in den Anfängen (2002), spezifiziert wurde. Details siehe die genannten RFC in #2

[talk]

Hallo zusammen,

Zitat von eifelman

Wundert mich, dass es hier noch kein Thema dazu gibt. Die Telekom migriert derzeit die IP-Telefonie auf eine neue Plattform.

Die Berichte in den üblichen Online-Branchenmagazinen sind - soweit ich das bislang sehen kann - alle ähnlich und basieren wohl in erster Linie auf der Pressemeldung der Telekom zum Thema: Sprachtelefonie aus der Cloud.

Dort heißt es unter anderem:

Die Telekom nutzt ab sofort eine neue Plattform für IP-basierte Sprachtelefonie im Festnetz. Mit der neuen Plattform „NIMS“ (Next Generation IP Multimedia Subsystem) startet das Unternehmen die Cloudifizierung der Sprachtelefonie. Ziel ist es, dass die Steuerung für bis zu 18 Millionen Anschlüsse von Kunden der Deutschen Telekom zukünftig zentral aus in Deutschland aufgebauten Cloud Rechenzentren kommt.

Klingt erst mal spektakulär, aber auch die bisherige VoIP-Plattform war schon deutlich zentraler als das gute, alte ISDN-Netz. Ich vermute mal, daß es da nun zu keiner weiteren Reduktion der Standorte (ca. 10-12?) kommen wird.

Und auch die Nutzung der SRV-Lookups, mit denen jedem Kunden gleich drei SIP-Server mitgeteilt werden (regional unterschiedlich in Abhängigkeit von der Dialin-IP des Kunden), ist nichts neues - hier im Forum gab es schon vor über 6 Jahren Diskussionen hierüber - siehe z.B. diesen Thread.

Auf der bestehenden Plattform wurden die Kunden auch schon auf verschiedene Server an unterschiedlichen Standorten verteilt. Da war es durchaus möglich, daß ein Nutzer aus Stuttgart an einem SIP-Server in Frankfurt, Nürnberg oder Hamburg angemeldet war (falls der Server in Stuttgart nicht erreichbar war oder die Dialin-IP des Nutzers nach einem Umzug eines IP-Adresspools zu einem anderen POP noch falsch zugeordnet wurde).

Spürbar für den Kunden dürfte am ehesten die Tatsache sein, daß die bislang ebenfalls mögliche Nutzung des A-Records von tel.t-online.de zukünftig nicht mehr möglich sein wird. Dort gab es bislang wohl keine "Regionalisierung" wie bei den SRV-Records, aber auch da wurden offenbar Server-IPs von unterschiedlichen Standorten ausgeliefert (ich hatte da schon IPs für Server in Dortmund und Hannover gesehen, aber pro Kunde nur jeweils ein Standort).

Technisch gesehen bedeutet die Virtualisierung nun wohl (z.B. bei den SBCs) im wesentlichen, daß die entsprechenden Netzfunktionen statt auf spezieller Hardware zukünftig softwarebasiert auf "normalen" Servern laufen. Metaswitch wird dabei offenbar Lieferant für virtuelle SBCs sein, vgl. die separate Meldung von dort.

Im Grunde läuft der Weg von Hardware- zu Software-seitiger Vermittlung schon länger. Die Idee des "Softswitches" ist schon rund 20 Jahre alt und unter anderem von Level3 (später CenturyLink, heute Lumen) vorangebracht worden, siehe dazu diese alte Pressemeldung aus dem Jahr 2000(!). Asterisk, Kamailio und Co. zeigen, daß auch die Open-Source-Gemeinde erfolgreiche Projekte in dieser Richtung entwickeln kann und man im Markt da nicht mehr auf die klassischen Technikhersteller angewiesen ist (die beiden genannten sind zwar eher SIP-Server und keine echten SBCs, aber mit OpenSBC gibt es auch da schon Entwicklungen).

Ein weiterer Auszug der Pressemeldung:

Durch die virtualisierten Netzfunktionen arbeitet das Festnetz schneller und effizienter. Das greift zum Beispiel beim Einspielen von Updates oder neuen Funktionen fürs Netz. Auch die Verwaltung und Zuteilung der Sprachkapazitäten im Netz erfolgt so schneller und ist immer auf den aktuellen Bedarf abgestimmt.

Zudem nutzt die neue Plattform der Telekom offene Standards und Schnittstellen. Damit sind Hardware und Software unabhängig voneinander. So können Infrastruktur und Anwendungen von ganz unterschiedlichen Herstellern kombiniert und einzelne Blöcke besser ausgetauscht werden.

Das sind viele "Buzz-Words" drin - mal sehen, ob sich diese Hoffnungen auch erfüllen. SIP und Co. sind ja schon seit jeher offene Standards, die aber im Markt halt teilweise auch unterschiedlich interpretiert werden. So hat alles seine Vor- und seine Nachteile...

Zitat von eifelman

Einige IP-Telefone oder Telefonanlagen werden bald nicht mehr nutzbar sein, wenn sie die DNS-Auflösung mittels SRV nicht unterstützen. Habe noch einen Kunden, der eine Auerswald COMpact 3000 VoIP nutzt - die wird auch kein Update mehr erhalten:

Daß Auerswald da kein Update o.ä. nachliefern will, ist enttäuschend.

Hast Du mal probiert, bei der Server-Konfiguration in der Auerswald einfach den Port 5060 wegzulassen? In RFC 3263 heißt es unter 4.2 (Determining Port and IP Address) unter anderem:

If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the specific port from the URI and transport protocol determined previously. [...]

If the TARGET was not a numeric IP address, and no port was present in the URI, the client performs an SRV query on the record returned from the NAPTR processing of Section 4.1, if such processing was performed.

Vielleicht ist das ja für manchen Router / Endgerät ohne explizite SRV-Option in der Benutzeroberfläche ein möglicher Ausweg.

Zitat von Mettwurscht

Edit: Ah, Moment. Vielleicht haben das nur Kunden bekommen, die ihren Router von der Telekom gekauft haben? Diese einen haben von der Telekom Lancomrouter gekauft, worauf in dem Schreiben auch explizit Bezug genommen wird.

Werden in dem genannten Schreiben die von der Telekom gekauften Router explizit genannt? In den von Dir geposteten Screenshots sieht das nicht so aus (auf der zweiten Seite stehen vermutlich halt Telefonnummern und Adressen oder werden dort auch noch die Router aufgelistet?).

Mal sehen, wie sich das Ganze entwickelt. Im Telekom-Hilft-Forum gab es bereits ein paar Rückmeldungen von betroffenen Kunden, aber eine wirklich große Welle ist das noch nicht. Die meisten Kunden dürften gängige Router wie Fritzbox, Speedport oder die Digitalisierungsbox verwenden, die bereits das SRV-Verfahren nutzen (auch schon bei ganz alten Modellen?).

Relevant dürfte das Thema vermutlich am ehesten für Nutzer von Softphones, IP-Phones, etc. sein, die direkt an der VoIP-Plattform angemeldet sind. Mal sehen, ob viele dieser Kunden das Infoschreiben einfach vergessen oder wegwerfen... immerhin wird das Problem (A-/SRV-Record) kurz beschrieben und nicht nur allgemein von Updates gesprochen. Falls die Telekom aber in allen Fällen nur von Updates des Routers spricht, sorgt sie unter Umständen gerade bei den Nutzern von Softphones / IP-Phones für Verwirrung (dort muß ja das "Endgerät" umgestellt werden, nicht der Router, sofern der Router nicht als lokaler SIP-Server dient).

Mein persönlicher Wunsch wäre ja, daß im Rahmen einer neuen Plattform auch mal Themen wie z.B. das fehlerhafte Routing der 0310/0311-Testnummern bei der Verwendung von CbC-Vorwahlen angegangen werden (010xy-031x wird auf der bisherigen VoIP-Plattform immer über die Telekom bzw. den pre-selecteten Carrier geroutet, nicht über den Carrier der 010xy-Vorwahl), siehe dazu auch diese Diskussion.

Oder nehmen wir den Fall mit den nicht funktionierenden Faxverbindungen, wenn der Router einen kleinen Fehler im Aufbau einer 488-Meldung hat, siehe dazu diesen Thread. SBCs dienen ja unter anderem auch dazu, die Interoperatibilität bei SIP zu verbessern, da verstehe ich nicht, warum man einen kleinen Fehler als Anlaß nimmt, eine Faxverbindung einfach ohne RTP-Stream weiterlaufen zu lassen (im Thread dazu hatte ich auch geschrieben, daß meiner Meinung nach die SIP-Standards eine entsprechende "Toleranz" nahelegen).

Vermutlich werden solche Spezialthemen aber auch jetzt wieder untergehen...

cu talk

[Wisi]

Zitat von michael4

Die Schuld ist hier einzig und allein beim Hersteller zu suchen. Wenn der das Protokoll unvollständig implementiert, ist dies als mangelhaft anzusehen. Ich würde mir von diesem Hersteller kein einziges Produkt mehr kaufen.
Was anderes wäre, wenn das ein Feature wäre, was nach Launch des Produkts gekommen ist. Aber hier handelt es sich um ein Feature, was bereits in den Anfängen (2002), spezifiziert wurde. Details siehe die genannten RFC in #2

Mag sein, ändert aber nichts an meiner Aussage im Kern.

Bin mal gespannt wie viele Clients das (noch) nicht können. Ich habe da ehrlich gesagt bisher auch nicht drauf geachtet beim Einrichten, obwohl mir das mit dem SRV Record durchaus geläufig war.

[eifelman]

Zitat von talk

Daß Auerswald da kein Update o.ä. nachliefern will, ist enttäuschend.

Hast Du mal probiert, bei der Server-Konfiguration in der Auerswald einfach den Port 5060 wegzulassen? In RFC 3263 heißt es unter 4.2 (Determining Port and IP Address) unter anderem:

Hab ich gerade getestet - leer lassen geht nicht und 0 eintragen ebenfalls nicht.



Ist echt ein Armutszeugnis, dass ein renommierter Anbieter ältere Telefonanlagen einfach so Schrott werden lässt. Ein Update ist sicherlich möglich, wenn der Wille da wäre. Zuletzt wurde Ende 2018 das Update auf Version 4.0S rausgebraucht - schon da hätte man das bestimmt implentieren können.

[mistry7]

Welche Fritzbox aus 2008 läuft denn noch?
Bekommt die noch Firmware Updates?

Eine TK ist heute halt nicht mehr für 20 oder mehr Jahre..
Die Compact 3000 wurde 2008 vorgestellt wenn ich mich richtig erinnere.
Somit dürfte die Hardware Plattform 1-2 Jahre älter sein.

[michael4]

Und das RFC ist von 2002. Mit Hardware hat das auch nichts zu tun, es geht um Software.
Wenn man die Kiste trotzdem weiter betreiben will, braucht man halt nen eigenen DNS, löst den SRV record periodisch auf und generiert A Records daraus, die dann intern von der TK Anlage aufgelöst werden.

[eifelman]

Die 3000 VoIP wurde bis vor ca. 3 Jahren verkauft. Ein Kunde muss IMHO nicht damit rechnen, dass eine Telefonanlage nach 3-4 Jahren Schrott ist. Zumal es im Gegensatz zu moderneren xDSL-Technologien, die meist neue Hardware erfordern, um eine Softwaregeschichte geht.

Die Gigaset IP-Basen (N510 IP, GO Box 100 sowie die vorherigen aus Bundles wie C610 IP oder C430 IP) sind von der Hardwareplattform auch schon älter, haben damit aber keine Probleme.

[hans46]

Also ich habe den Startvorgang meiner konfigurierten COMpact3000VoIP mal über einem Paketmitschnitt an der FritzBox aufgezeichnet und muss feststellen das diese die dreistufige DNS Auflösung (NAPTR->SRV->A) von tel.t-online.de ohne weiteres macht. Installierte Firmware ist die Version 4.0S - Build 000. Als Providerprofil kommt die letzte CSIP.FT zum Einsatz. Somit ist mir die Aussage von Auerswald auf deren Webseite nicht ganz klar. "Diese Systeme unterstützen das dynamische Verfahren nicht und können damit nach Plattformumstellung nicht mehr an dem jeweiligen VoIP-Account betrieben werden. Das ITK-System muss in diesen Fällen durch ein kompatibles System ersetzt werden."
Hier soll scheinbar der Verkauf neuer ITK Systeme angekurbelt werden.

[Wisi]

Zitat von hans46

Also ich habe den Startvorgang meiner konfigurierten COMpact3000VoIP mal über einem Paketmitschnitt an der FritzBox aufgezeichnet und muss feststellen das diese die dreistufige DNS Auflösung (NAPTR->SRV->A) von tel.t-online.de ohne weiteres macht. Installierte Firmware ist die Version 4.0S - Build 000. Als Providerprofil kommt die letzte CSIP.FT zum Einsatz. Somit ist mir die Aussage von Auerswald auf deren Webseite nicht ganz klar. "Diese Systeme unterstützen das dynamische Verfahren nicht und können damit nach Plattformumstellung nicht mehr an dem jeweiligen VoIP-Account betrieben werden. Das ITK-System muss in diesen Fällen durch ein kompatibles System ersetzt werden."
Hier soll scheinbar der Verkauf neuer ITK Systeme angekurbelt werden.

Danke für deine Mühe, das wollte ich bei passender Gelegenheit auch mal machen. Interessante Sache, dann wird die wohl noch weiter laufen...

[strupp3003]

Hallo Zusammen,

kann das mit der SRV-Faehigkeit der Auerswald COMpact 3000 VoIP bestaetigen! Habe auch das Schreiben der Telekom erhalten (Abschaltung A records Ende Februar) und daraufhin Wireshark angeworfen, siehe Screenshot anbei (151.1 ist mein DNS Server, 151.10 die Auerswald).

Fuer mich sieht das so aus als wuerde es funktionieren - bin gespannt was dann Anfang Maerz passiert...

Waere schon Aergerlich die Anlage wegen einer solchen Kleinigkeit austauschen zu muessen.

VG
Stephan