[Frage] Wie läuft genau das RTP durch Internet?

Zentronix

Mitglied
Mitglied seit
24 Jan 2010
Beiträge
631
Punkte für Reaktionen
31
Punkte
28
Hallo,

ich bin auf der Suche nach grundlegenden Erklärungen, wie die Audiodaten bei VoIP genau durch das Internet geleitet werden. Hat hierzu vielleicht jemand fundierte Erkenntnisse oder Fundstellen im Netz? Im folgenden Prosatext habe ich zwei Fragen versteckt. Mit mehr Geheimwissen möchte ich die gefürchtete Latenz minimieren und technische Entscheidungen (z.B. Provider- und Geräteauswahl) optimieren können.


Bekanntlich steuert SIP den Aufbau und Abbau der Verbindung. Der Schall selbst wird per RTP transportiert.


1. Der lange Weg des RTP

Ich habe mal testweise eine VoIP-Verbindung zu einem Teilnehmer aufgebaut, der am selben Provider angemeldet ist und mit der Fritzbox-Netzprotokollierung + Wireshark angesehen. Die RTP-Gegenstelle war identisch mit dem SIP-Server des VoIP-Providers. Dasselbe sieht man auch in der Fritzbox-Maske "Sprachübertragung".

Die RTP-Verbindung wird also nicht direkt zwischen den Internetzugängen der beiden Teilnehmer aufgebaut, sondern immer über den VoIP-Provider. Das ist im Prinzip auch logisch, da der Provider sonst die vorgeschriebene Abhörschnittstelle nicht bereitstellen könnte und Gespräche auch nicht nach Dauer abgerechnet werden müßten (es sei denn, man verläßt das Internet ins analoge Telefonnetz, ISDN oder Mobilfunk).

[Frage 1] Werden die RTP-Pakete schnellstmöglich weitergereicht (abgesehen von kleineren Anpassungen wie Adressmapping), oder werden sie unterwegs irgendwo aufgeschnürt und neu verpackt? Letzteres würde zu weiteren Stoßstellen bei der Übertragung führen und die Latenz erhöhen.

Dasselbe gilt natürlich, wenn ich mein VoIP-Telefon an meiner Fritzbox anmelde und diese sich wieder beim VoIP-Provider anmeldet. Auch hier könnte eine Stoßstelle entstehen, die vermeidbar wäre, wenn ich mein VoIP-Telefon direkt beim VoIP-Provider anmelde und die Telefonfunktion der Fritzbox nicht nutze.


2. Die Codec-Aushandlung

Beim reinen Durchreichen der RTP-Pakete hätten die Teilnehmer zwar keine direkte IP-Verbindung, aber sie müßten sich auf einen gemeinsamen VoIP-Codec einigen.

[Frage 2] Was passiert, wenn es keinen gemeinsamen Codec gibt? Zum Beispiel wenn ich nur den üblichen G.711 anbieten kann, und mein Gegenüber aufgrund seiner langsamen Internetanbindung nur ultrasparsame Codecs wie G.729 erlaubt? Dann müßte automatisch ein Umkodierer eingeschoben werden.


Danke für alle Hinweise, und Grüße.
 
Die RTP-Gegenstelle war identisch mit dem SIP-Server des VoIP-Providers.
Du hast wahrscheinlich die selbe IP-Adresse gesehen, dies bedeutet nicht mal, dass es im gleichen Serverschrank läuft, da es auch Load-Balancing und Co. auf IP-Ebene gibt und dies nur eine Art Firewall (professionell Border Gateway) ist.

Das ist im Prinzip auch logisch, da der Provider sonst die vorgeschriebene Abhörschnittstelle nicht bereitstellen könnte und Gespräche auch nicht nach Dauer abgerechnet werden müßten
Letzters ist kein Argument, da auch während der Verbindung SIP-Pakete übertragen werden.
Die Provider machen das, weil die meisten möglichst wenig übers Internet gehen wollen. Auch zwischen den Telefonieprovidern in Deutschland wird nie das Internet verwendet, sondern immer nur physikalische Zusammenkünfte mit dedizierten Leitungen auf denen nur VoIP stattfindet.

Werden die RTP-Pakete schnellstmöglich weitergereicht (abgesehen von kleineren Anpassungen wie Adressmapping), oder werden sie unterwegs irgendwo aufgeschnürt
Kommt auf den Provider an und bei providerübergreifenden Gesprächen auch auf die Zusammenschaltung.

Was passiert, wenn es keinen gemeinsamen Codec gibt? Zum Beispiel wenn ich nur den üblichen G.711 anbieten kann, und mein Gegenüber aufgrund seiner langsamen Internetanbindung nur ultrasparsame Codecs wie G.729 erlaubt? Dann müßte automatisch ein Umkodierer eingeschoben werden.
Bei reinem SIP würde das Gespräch nicht zustanden kommen. Kommt auf den Provider an. Es gibt Provider, da kann man immer sowas wie G.729 benutzen, die konvertieren das dann immer. Es gibt auch Provider, die schmeißen alle Codecinformationen deines Clients weg außer G.711 und G.722, dort würde der Benutzer von G.729 immer ein Problem haben.
 
Zuletzt bearbeitet:
Du hast wahrscheinlich die selbe IP-Adresse gesehen, dies bedeutet nicht mal, dass es im gleichen Serverschrank läuft, da es auch Load-Balancing und Co. auf IP-Ebene gibt und dies nur eine Art Firewall (professionell Border Gateway) ist.

Mag sein, daß die Hardware dort komplexer ist. Es ging mir nur darum, daß das RTP über den Provider läuft.

Kommt auf den Provider an und bei providerübergreifenden Gesprächen auch auf die Zusammenschaltung.

Das gibt es wohl keine öffentlichen Erkenntnisse, wer im Allgemeinen besser angebunden ist?

Bezüglich Latenz habe ich habe mal ein paar Versuche mit dem Echo-Server von BlueSIP gemacht. Dort angerufen, auf den Tisch geklopft, mit dem PC aufgenommen und dann mit einem Audio-Editor den Abstand gemessen. Da kam Folgendes raus:

TelekomISDN 30 ms
TelekomVoIP 90 ms
EasybellVoIP110 ms
Dus.netVoIP120 ms
SipgateVoIP130 ms

(jeweils einfache Latenz, also halber gemessener Abstand, auf 10 ms gerundet)

Da stellt sich mir die Frage, ob die Telekom die bessere Technik hat, oder ob sie einfach nur die besseren Verbindungen hat. Es kann ja nicht jeder mit jedem direkt verbunden sein. Abe sicherlich wird sich jeder möglichst gut mit der Telekom verbinden wollen.

Bei reinem SIP würde das Gespräch nicht zustanden kommen. Kommt auf den Provider an. Es gibt Provider, da kann man immer sowas wie G.729 benutzen, die konvertieren das dann immer. Es gibt auch Provider, die schmeißen alle Codecinformationen deines Clients weg außer G.711 und G.722, dort würde der Benutzer von G.729 immer ein Problem haben.

Also auch unvorhersehbar. Ich gehe mal davon aus, daß man mit G.711 immer zurechtkommt.

Grüße.
 
Wenn der, den du anrufen willst, auf der Internet-Seite seines Anschlusses einen SIP-Registrar anbietet, kannst du diesen natürlich auch ohne zusätzlichen SIP-Provider anrufen.

die gibt es "nur", weil man sich nicht die ganzen Daten 'merken' kann, um die Leute, die man anrufen will, auch anrufen zu können.


Um so etwas umzusetzen, hatten sich die Leute ENUM ausgedacht
https://de.wikipedia.org/wiki/Telephone_Number_Mapping
Nur hat sich das nicht wirklich durchgesetzt.
 
Moins

thtomate12 schrieb:
Ein Registar ist nicht notwendig
Richtig, nur ein SIP Port (normal: 5060 udp/tcp) für eingehende Anrufe.
...darüber ist jede Rufnummer einer z.B. Fritz!Box anrufbar.
...und auch darüber werden die RTP Ports ausgehandelt.
Allerdings funktioniert das übers Internet nur mit aktivierten STUN im (unregistrierten) SIP-Klienten (Anrufer).
 
Gibt es ernsthaft jemanden, der über diese Technik Personen anruft, die nicht zu seinem engsten Bekanntenkreis gehören?

Grüße.
 
Zuletzt bearbeitet:
Hey, das geht sogar. Ich habe die "200@..." ins Telefonbuch der Fritzbox eingetragen konnte nun über die Kurzwahl anrufen. Da ertönt Musik mit Band und Klavier.

Seltsamerweise wird der Eintrag in der Maske "Telefonbuch" nicht aufgelistet. Er ist aber da, denn die Kurzwahl funktioniert ja. Zu sehen ist ein Standardeintrag "AVM Ansage (HD)" nach "[email protected]". Ein Bug in Web-Interface?

Grüße.
 
Nö, bewusstes Verstecken seitens AVM.
Abspeichern mit der IPv4 des Mediaservers verhindert das aber. ;)
Siehe: Telefonie->Eigene Rufnummern-reiter->Sprachübertragung
 
Zuletzt bearbeitet:
Und das Wichtigste: Das klappt gratis ohne VoIP-Anbieter
(Über Fakenummer oder nichtregistrierten SIP-Klienten mit STUN-Server)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.