Übersicht der ip-Adressen (Gateways & Co.) für VoIP

Die Frage wurde schon gestellt, aber nie beantwortet. Stattdessen gab es Gegenfragen der Art "Wieso-weshalb-warum?"

 

Ich betreibe eine Linux-VM mit Asterisk für die Telefonie. Da ich zwei Internet-Provider habe (bitte nicht fragen warum), gibt es natürlich auch zwei Anbindungen für VoIP.

 

Leider verhindern beide Provider (einer davon ist die Telekom), dass ich deren VoIP-Infrastruktur über den Internet-Zugang des jeweils anderen Providers nutze. Das verhindert einen redundanten Zugang zur Telefonie, falls eine der beiden DSL/VDSL-Verbindungen wegbricht. "Weschens de Sischerheit" vermute ich mal, aber ich will hier nicht losranten.

 

Aus dieser Designentscheidung der Carrier muss ich in meinem Netz die ip-Adressen zu den VoIP-Gateways von Provider X über den Zugang von Provider X routen und die ip-Adressen zu den VoIP-Gateways der Telekom über den Telekom-Zugang.

 

Experimentell habe ich herausgefunden, dass es nicht reicht,  das Netz zu routen, in dem tel.t-online.de wohnt (217.0.128.0/24). Es kommen zwar Calls zustande, aber Sprachdaten fließen erst, wenn ich auch  217.0.7.0/24 route.

 

Ich würde mich sehr freuen über eine Übersicht, welche Netze genutzt werden. Es kann ja sein, dass redundante Geräte in anderen Netzen stehen, auf die bei Bedarf umgeschaltet wird.

 

Dass diese Information nicht auf ewig gültig sein wird, ist mir schon klar.

 

Ein Hinweis, wie ich mir diese Adressen periodisch beschaffen kann, z.B. durch DNS-Lookups, wäre auch schick.

 

Was ich bitte nicht mehr lesen möchte, sind gut gemeinte Hinweise auf Ports, Portweiterleitungen, Paketfilterregeln und böse Leute, die über meinen Asterisk nach Russland oder China telefonieren wollen. Erstens kann man das gut wegkonfigurieren, indem ip-Adressen von außen nur zu Endgeräten nach innen telefonieren dürfen, zweitens ist mein Asterisk von außen gar nicht erreichbar. Man braucht keinen Port manuell zu öffnen und keine Portweiterleitung. Das funktioniert alles wunderbar per NAT.


@bluebell  schrieb:

Leider verhindern beide Provider (einer davon ist die Telekom), dass ich deren VoIP-Infrastruktur über den Internet-Zugang des jeweils anderen Providers nutze. Das verhindert einen redundanten Zugang zur Telefonie, falls eine der beiden DSL/VDSL-Verbindungen wegbricht. "Weschens de Sischerheit" vermute ich mal, aber ich will hier nicht losranten.


Das dürfte eher wegen der Notrufproblematik sein. "Röchelanrufe" gehen halt nur wenn man als Provider die IP-Adresse auf eine geographische Adresse Ort/Straße/Hausnummer/ggf. Stockwerk auflösen kann.

 

Ansonsten drücke ich Dir die Daumen, die gewünschte Info zu erhalten.

 

Dein Forenprofil solltest Du zuallermindest ergänzen.


@muc80337_2  schrieb:

@bluebell  schrieb:

Leider verhindern beide Provider (einer davon ist die Telekom), dass ich deren VoIP-Infrastruktur über den Internet-Zugang des jeweils anderen Providers nutze. Das verhindert einen redundanten Zugang zur Telefonie, falls eine der beiden DSL/VDSL-Verbindungen wegbricht. "Weschens de Sischerheit" vermute ich mal, aber ich will hier nicht losranten.


Das dürfte eher wegen der Notrufproblematik sein. "Röchelanrufe" gehen halt nur wenn man als Provider die IP-Adresse auf eine geographische Adresse Ort/Straße/Hausnummer/ggf. Stockwerk auflösen kann.

Kann man ja nicht. Woher soll ein Angerufener wissen, dass auch Endgeräte in meiner Zweitwohnung per VPN-Tunnel angeschlossen sind und ich dasselbe per VPN und Telefon-App übers Mobiltelefon tue?

 

Auf jeden Fall ist so sichergestellt, dass bei Ausfall meiner Internet-Anbindung zur Telekom auch die Telekom-Telefonie gestört ist. Tolle Wurst. Aber ich wollte ja nicht ranten.

 

Vielleicht kriege ich ja wenigstens die ip-Adressen der Gateways. Das ist immerhin eine ganz einfache technische Frage.


@muc80337_2  schrieb:

Dein Forenprofil solltest Du zuallermindest ergänzen

 

Funktioniert nicht. Beim Betätigen der E-Mail-Adresse kriege ich ein "Seite nicht gefunden", bei der Eintragung von Kunden- und Rückrufnummer tut sich überhaupt nichts. Und ja, ich habe sogar meinen Adblocker ausgeschaltet.


 

@bluebell 

 

Du scheinst doch über ein gutes Netzwerkwissen zu verfügen, da sollte die Ermittlung der notwendigen Daten doch kein Problem sein.


@bluebell  schrieb:

Kann man ja nicht. Woher soll ein Angerufener wissen, dass auch Endgeräte in meiner Zweitwohnung per VPN-Tunnel angeschlossen sind und ich dasselbe per VPN und Telefon-App übers Mobiltelefon tue?


Dass man so etwas auch aushebeln kann bestreitet niemand.

 

Gut zu wissen für andere Leser (Dich interessiert das ja nicht):

Mit einem Hybridanschluss - so verfügbar - und einem Speedport Hybrid hat man nicht nur Redundanz für den Internetzugang sondern auch für die Telefonie.


@muc80337_2  schrieb:

@bluebell  schrieb:

Kann man ja nicht. Woher soll ein Angerufener wissen, dass auch Endgeräte in meiner Zweitwohnung per VPN-Tunnel angeschlossen sind und ich dasselbe per VPN und Telefon-App übers Mobiltelefon tue?


Dass man so etwas auch aushebeln kann bestreitet niemand.

 

Gut zu wissen für andere Leser (Dich interessiert das ja nicht):

Mit einem Hybridanschluss - so verfügbar - und einem Speedport Hybrid hat man nicht nur Redundanz für den Internetzugang sondern auch für die Telefonie.


Das hat nichts mit aushebeln zu tun, das ist die neue Welt. Ich habe ohne Notstromversorgung keine Telefonie mehr, wenn der Strom ausfällt (auch Telekom-Mobilfunk ist sofort tot bei Stromausfall im Ortsteil), dafür aber zusätzliche Möglichkeiten, wenn er da ist.

 

Ich kann auch in jedem Router einen Asterisk installieren, der die Anbindung an den Provider über die Defaultroute macht. Es wäre aber einfacher, ein paar Daten bereitgestellt zu bekommen.

 

Es gibt nun mal Leute, die es vermeiden, wo es geht, Software mit verheimlichtem Quellcode laufen zu lassen. Das zuschaltbare LTE ist m.W. undokumentiert und gibt es nur zusammen mit einer Black Box. Solche Lösungen missfallen mir, weil sie mich 1. einschränken und ich 2. schon mal nach

 

        Router Backdoor

 

gegoogelt hab.

 

Aber es wäre doch schön, wenn ich die technischen Daten bekommen würde, um meinen Anschluss vollumfänglich zu nutzen.

Du siehst doch, dass die paar Netze eine Dokumentationslücke zu sein scheinen.

@bluebell  schrieb:

Das hat nichts mit aushebeln zu tun, das ist die neue Welt.


Das ist nicht so trivial. Es gibt diesbezüglich eine Technische Richtlinie Notrufverbindungen, herausgegeben von der Bundesnetzagentur. Und über die darf sich eine Telekom nicht hinwegsetzen.

 

Insofern ist das durchaus ein Aushebeln dessen, was für Notrufe vorgesehen ist.

Wenn Du das für Dich alleine machst, dann sei's drum. Aber wenn davon auch andere betroffen sind oder sein können, dann würde ich mir genau überlegen, was ich da mache.

Ich tippe mal darauf dass du die Informationen nicht bekommst, einfach weil die Provider die entsprechende Dokumentation dann jedes mal aktualisieren müssten wenn sie an ihrem VoIP-Netz etwas ändern möchten. Warum sollte ich mir als Provider so eine Pflicht ans Bein binden?

Irgendwo in einer CMDB muss man es sowieso pflegen, dann kann man es auch automatisch in den DNS schieben, damit sich Kunden die Information holen können. Es kann ganz einfach sein.


@bluebell  schrieb:

Es kann ganz einfach sein.


Ich habe da eine private längere Liste von Dingen, die ganz einfach sein können für die Telekom, die die Telekom aber trotzdem nicht macht.

Da habe ich da jetzt mal mit draufgeschrieben.

Hallo zusammen,

 

die VoIP-Plattform der Telekom besteht aus diversen Servern an verschiedenen Standorten. Dabei kommt eine Art "Regionalisierung" zum Einsatz, bei der den Kunden im Idealfall ein SIP- bzw. RTP-Server aus der jeweiligen Region zugewiesen wird (mit ein bzw. zwei "Ersatz"-Servern in anderen Regionen).

 

Dies setzt voraus, daß die vom Kunden genutzte VoIP-Technik für die Auflösung von tel.t-online.de zunächst keine allgemeinen A-Lookups, sondern die etwas exotischeren SRV-Lookups nutzt: Es wird also für tel.t-online.de der dazugehörige SRV-Lookup für SIP abgefragt. Die dann zurückgelieferten Server können wiederum mit einem A-Lookup aufgelöst werden.

 

Die hauseigenen DNS-Server der Telekom melden dann offenbar je nach IP-Adresse des "abfragenden" Telekom-Nutzers regional angepaßte SIP-Server zurück. Für einen Standort in Baden-Württemberg bekomme ich aktuell z.B. folgende Ergebnisse:

 

 

_sip._udp.tel.t-online.de       SRV service location:
          priority       = 20
          weight         = 0
          port           = 5060
          svr hostname   = h2-epp-100.edns.t-ipnet.de
_sip._udp.tel.t-online.de       SRV service location:
          priority       = 30
          weight         = 0
          port           = 5060
          svr hostname   = d-epp-100.edns.t-ipnet.de
_sip._udp.tel.t-online.de       SRV service location:
          priority       = 10
          weight         = 0
          port           = 5060
          svr hostname   = s-epp-100.edns.t-ipnet.de

 

 

Die "priority" gibt die Reihenfolge an, in der die SIP-Server "durchprobiert" werden sollen (niedrigster priority-Wert zuerst, danach entsprechend aufsteigend).

 

Das sind also in meinem Beispiel-Fall SIP-Server in folgenden Städten (erkennbar an den Autokennzeichen am Anfang des Hostnamens):

 

1.) Stuttgart (s-epp-100, IP-Adresse 217.0.20.192)

2.) Hannover (h2-epp-100, IP-Adresse 217.0.29.32)

3.) Düsseldorf (d-epp-100, IP-Adresse 217.0.28.32)

 

Antwortet also z.B. der Server in Stuttgart nicht, stehen die Server in Hannover und Düsseldorf als Ersatz zur Verfügung. Welche Server aktuell angegeben werden, kann sich täglich ändern. Es ist auch denkbar, daß man mal eine IP-Adresse als Nutzer zugeteilt bekommt, die ursprünglich in einer anderen Region zur Einwahl genutzt wurde - dann können auch mal regional "falsche" SIP-Server zurückgeliefert werden. Das ändert an der Funktionsfähigkeit des Anschlußes aber nix - lediglich die Paketlaufzeiten können durch einen Umweg evtl. erhöht sein.

 

Der für einen Anruf genutzte SIP-Server dient ja nur zur Signalisierung. Für den eigentlichen Telefonieverkehr (also den Austausch der Sprachdaten) verweist dieser dann auf einen von mehreren RTP-Servern, die am jeweiligen Standort zur Verfügung stehen. Diese kommen - nach meinen Erfahrungen - aus anderen IP-Subnetzen. Ich habe bislang Server aus den Netzen 217.0.5.0/24, 217.0.6.0/24 und 217.0.7.0/24 gesehen - das müssen aber noch nicht alle gewesen sein.

 

Da Du anhand der hier zusammengestellten Angaben schon sehen kannst, daß diverse IP-Bereiche zum Einsatz kommen, wäre es evtl. sinnvoll, (falls man eine solche Spezial-Lösung möchte, wie Du sie beschrieben hast) einfach das ganze Netz 217.0.0.0/8 über den Telekom-Anschluß zu routen. Das ist aber auch noch keine Garantie für eine jederzeit bzw. dauerhaft funktionierende Lösung!

 

Für Dich (und evtl. andere Nutzer, die mal für ähnliche Anfragen auf meinen Beitrag hier stoßen) aber noch der große Warnhinweis: Alle Daten und Angaben in diesem Text nach bestem Wissen und Gewissen - aber ohne jegliche Garantie! Jeder Nutzer, die eine eigene VoIP-Lösung einsetzt, handelt auf eigenes Risiko und auf eigene Gefahr! Ich bin kein Telekom-Mitarbeiter, sondern auch nur Nutzer, ähnlich wie Du. Dies hier sind also keine offiziellen Angaben der Telekom, sondern reine Erfahrungswerte!

 

cu talk

Dass die Telekom DNS-Antworten abhängig von der ip-Adresse des Anfragenden gibt, ist eine weitere schlechte Idee. Sie kann nicht davon ausgehen, dass die Anfrage vom Kunden direkt an ihren DNS geht.

 

So mancher (ich z.B.) verlässt sich aus gutem Grund nicht auf die Antworten des Provider-DNS, da die Antworten teilweise von Wünschen der Marketing-Abteilung oder des Hamburger Landgerichts abhängen.

 

Wenn die Telekom schon mal so weit ist und Backuplösungen des Kunden verhindert (Notrufregelung zählt nicht, weil man sich ja von einem anderen Telekom-Zugang durchaus zum SIP-.Gateway kommt), dann wäre eine regionale Zuteilung via Anycast technisch sinnvoller.

 

Ich bin aber auch so weit wie Du, dass ich derzeit 217.0.0.0/8 nehme in der Hoffnung, dass die Admins und Netzdesigner nicht das tun, was Anwendungsentwickler am liebsten tun: Änderungen um der Änderungen willen.