-
Die
Erfindung betrifft ein Verfahren zur Bereitstellung einer Echtzeitkommunikationsverbindung mithilfe
des Internet-Protokolls
(IP) und eine Sende- und Empfangsvorrichtung zur Ausführung dieses Verfahrens.
-
Das
RFC-Dokument („Request
for Comments") 1889
beschreibt das RTP-Protokoll und das RTCP-Protokoll (RTP = "Real-Time Transport
Protocol", Echtzeit-Transportprotokoll;
RTCP = "Real-Time Transport
Control Protocol",
Echtzeit-Transportsteuerungsprotokoll). RTP bietet Netzwerk-Transportfunktionen
von Ende zu Ende, die geeignet sind für Anwendungen zur Übertragung
von Echtzeitdaten wie beispielsweise Audio-, Video- oder Simulationsdaten über Multicast-
oder Unicast-Netzwerkdienste (Mehrfach- oder Einfachübertragungssysteme).
-
Das
Senden über
und innerhalb von Paketvermittlungsnetzwerken ist gekennzeichnet
durch einen stark variierenden und manchmal sehr intensiven Datenverkehr,
d. h. Burst-Datenverkehr. Daher sind Echtzeitübertragungen mit IP anfällig gegen eine
Reihe ernsthafter Probleme, insbesondere bei Heimvorrichtungen und
Zugangsvorrichtungen mit begrenzter Bandbreite. Das Burst-Verhalten des Signal-
und Steuerungsdatenverkehrs beeinträchtigt den Echtzeitdatenverkehr,
was nur teilweise durch vorhandene einfache Multiplexing-Mechanismen
angefangen wird. Die Signalinformationen müssen nicht unbedingt in Echtzeit übertragen
werden, aber eine Mindestübertragungsgarantie
ist erforderlich, um die Konnektivität mit der Signaleinheit auf
der fernen Seite sicherzustellen.
-
Das
Burst-Verhalten der Signalverarbeitung erlaubt keine Behandlung
der Signalisierung mit der gleichen Priorität wie bei Echtzeitdatenströmen. Andererseits
kann die Behandlung der Signalisierung mit einer niedrigeren Priorität zu Störungen bei
der Signalkonnektivität
führen.
Bei einer begrenzten Bandbreite kann es vorkommen, dass beispielsweise eine
vorhandene Echtzeitverbindung mit hoher Priorität verhindert, dass der Signaldatenverkehr
den Anruf freigibt.
-
Firewalls
mit NAT/NAPT, die in Privatumgebungen eingesetzt werden, erschweren
es den Ende-zu-Ende-Signalprotokollen wie beispielsweise SIP, die
richtigen medienrelevanten Datenströme aneinander zu binden. (NAT
= „Network
Address Translation",
Netzwerkadressumsetzung; NAPT = „Network Address Port Translation", Netzwerkadressport-Umsetzung,
SIP = „Session
Initiation Protocol",
Session-Einrichtungsprotokoll). Eine allgemeine Lösung, die
mit allen Arten von NAT/NAPT-Vorrichtungen funktioniert, gibt es
bisher nicht. Darüber
hinaus umfasst SIP auch Transportadressen, die korrigiert werden
müssen,
wenn ein Firewall-Übergang stattgefunden
hat. Ein RTP-Abschluss tritt normalerweise auf einem anderen System
als die SIP-Behandlung auf. Somit sind zum Senden der für die Änderung
der SIP-Nachrichten erforderlichen Informationen zusätzliche
Steuererweiterungen erforderlich. Darüber hinaus muss ein Benutzer
bei Verwendung einer Firewall mit NAT/NAPT zahlreiche Ports für VoIP öffnen (VoIP
= „Voice
over Internet Protocol").
-
Die
Patentschrift
US
2002/0150092 A1 beschreibt ein Verfahren zum Einrichten
einer Eins-zu-Eins-Sprachkommunikation im Paketmodus innerhalb eines
Kommunikationssystems. Ein Anruf wird eingeleitet durch ein Anrufeinrichtungssignal, das
in einen Datenverkehr auf der Benutzerebene eingebettet ist, wobei
dieser Datenverkehr von einem anrufenden Teilnehmer an eine logische
Einheit auf der Benutzerebene des Kommunikationssystems gesendet
wird. Als Antwort auf diese eingebettete Signalisierung der Anrufeinleitung
wird ein logischer Pfad eingerichtet, und nachfolgender Datenverkehr auf
der Benutzerebene wird an den angerufenen Teilnehmer weitergeleitet.
Somit ist keine explizite Signalisierung erforderlich, die Zeit
und Bandbreite verbraucht. Es sind spezifische Pakete definiert,
z. B. RTP-Pakete mit relativen Nutzlasttypen. In diesen Paketen
mit ihrer spezifischen Aufgabe wird der Inhalt der Nutzlasten und/oder
der Werte im Feld „Nutzlasttyp" im RTP-Datenkopf
als eingebettete Signalisierung verwendet. Zu Beginn einer Kommunikation folgt
beispielsweise auf ein spezifisches führendes RTP-Paket der tatsächliche
Audio-Datenstrom (RTP-Datenverkehr,
VoIP-Pakete).
-
A.
Argyriou und V. Madisetti schlugen in „Streaming H.264/AVC Video
over the Internet",
Consumer Communications and Networking Conference (CCNC), Las Vegas,
5.–8.
Januar 2004, IEEE 2004, Seite 169–174, eine Ende-zu-Ende-Architektur
vor zum Streaming von Einfachübertragungs-Videodaten über das
Internet auf der Basis einer geänderten Version
des Stream Control Transmission Protocol (SCTP). RTCP-Berichte werden
in einer Medien-SCTP-Session gemultiplext, wobei der RTCP-Datenverkehr
einen bestimmten Anteil der gesamten Session-Bandbreite nicht überschreiten
darf. Diese Art von Multiplexing erlaubt das Splitten des Video-Streaming-Prozesses
in einen „Daten"-Teil und einen „Steuerungs"-Teil.
-
US 6657997 B1 beschreibt
die Übertragung der
vier CAS-Signal-Bits
(ABCD) mithilfe von RTP (CAS = Channel-Associated Signaling). Die
ABCD-Bits sind im RTP-Datenkopf eines VoIP-Pakets eingebettet. Eine
Fragmentierung ist nicht erforderlich.
-
Aufgabe
dieser Erfindung ist es, die Bereitstellung einer Echtzeitkommunikationsverbindung über ein
IP-Kommunikationsnetzwerk zu verbessern.
-
Die
Aufgabe der vorliegenden Erfindung wird durch ein Verfahren gemäß Anspruch
1 erreicht. Die Aufgabe der vorliegenden Erfindung wird des Weiteren
durch eine Sendevorrichtung gemäß Anspruch
9 erreicht. Die Aufgabe der vorliegenden Erfindung wird des Weiteren
durch eine Empfangsvorrichtung gemäß Anspruch 10 erreicht.
-
Der
Begriff Multiplexing, auch als MUXing bezeichnet, bezieht sich auf
die Kombination von zwei oder mehr Informationskanälen auf
einem gemeinsamen Übertragungsmedium.
Der Begriff Interleaving kennzeichnet eine spezielle Art von Multiplexing
mit einem erneuten Sortieren und Verschachteln von Bits. Interleaving
ist eine Möglichkeit,
Daten in einer nicht-zusammenhängenden
Weise anzuordnen, um die Leistung zu steigern. Wenn daher in dieser Beschreibung
der Begriff Multiplexing verwendet wird, umfasst er gleichzeitig
auch den Prozess des Interleaving.
-
Durch
das Multiplexing des Nicht-Echtzeitdatenstroms auf dem Echtzeitdatenstrom
wird dem Nicht-Echtzeitdatenstrom eine Mindestbandbreite eingeräumt; die
Konnektivität
der Signalisierung ist daher auch in Verbindungen mit stark begrenzter Bandbreite
garantiert. Das Multiplexing/Interleaving gemäß der Erfindung spart Bandbreite,
insbesondere für
die Zugriffsvorrichtungen. Darüber
hinaus tritt hinsichtlich der Medien-Session wegen der dem Signal-/Steuerungs-Datenverkehr
zugeordneten begrenzten Bandbreite kein Burst-Steuerungsdatenverkehr
oder -Signaldatenverkehr auf.
-
Die
Erfindung erlaubt einen einfachen NAT/NAPT-Übergang, der mit allen Arten
von Firewalls funktioniert. Darüber
hinaus braucht nur ein winziges Loch in der Firewall geöffnet zu
werden, da der gesamte Datenverkehr auf den Echtzeitkanal begrenzt
ist. Der kontinuierliche RTP-Datenverkehr hält die Firewall offen und damit
auch für
den Nicht-Echtzeitdatenverkehr,
d. h. den Signal- und den Steuerungs-Datenverkehr. Darüber hinaus kann sehr einfach
ein Erregungsmechanismus („Keepalive-Mechanismus") hinzugefügt werden.
-
Darüber hinaus
ermöglicht
es die Erfindung, dass eine vollständige Medien-Session über eine einfache
IP-Weiterleitung problemlos an einen neuen Zugangspunkt weitergeleitet
werden kann. Der Mechanismus gemäß der Erfindung
ist für
weitere Merkmale offen wie beispielsweise für vom Netzwerk bereitgestellte
Antwortfunktionen, Ankündigungen
etc. So können
beispielsweise für
einen Benutzer Audio-Ankündigungen
abgespielt werden, wenn dieser das Telefon abnimmt.
-
Die
Erfindung bietet einen sehr guten Ansatz zur Implementierung eines
einfachen IP-Telefons. Es genügt,
die IP-Adresse des Zugangspunkts einzuprogrammieren, wie es mit
jeder normalen Telefontastatur möglich
ist. Anschließend
kann eine einfache Einrichtung über
ein Leichtgewichtsprotokoll implementiert werden, um ein „sehr dummes" Endgerät zu erhalten.
-
Gemäß der Erfindung
kann die Datenverkehrsverwaltung für den allgemeinen Echtzeitdatenverkehr
und die Summe des gesamten Nicht-Echtzeitdatenverkehrs sehr einfach
durchgeführt
werden. Der gesamte Datenverkehr – Echtzeit und Nicht-Echtzeit – kann zusammen
verschlüsselt
werden und braucht nicht jeweils separat verschlüsselt zu werden. Und der Interleaving-Mechanismus
gemäß der Erfindung
ist auf jede Art und jeden Umfang von Nicht-Echtzeitsignalprotokoll
für ein
Interleaving mit Echtzeitdatenströmen anwendbar.
-
Weitere
Vorteile werden über
die in den abhängigen
Patentansprüche
angegebenen Ausführungsformen
der Erfindung erzielt.
-
Alle
Verzögerungen
bei der Echtzeitdatenübertragung
führen
zu einer erheblichen Reduzierung hinsichtlich der Audio-/Videoqualität auf der
Empfängerseite.
Gemäß einer
bevorzugten Ausführungsform
der Erfindung wird daher den Echtzeit-Datenstrompaketen die höchste Übertragungspriorität über die
Echtzeitverbindung eingeräumt.
Auf diese Weise wird sicherge stellt, dass – bei einem Engpass – die Echtzeitdaten
immer mit der höchsten
Priorität übertragen
werden und die Signal- und Steuerungsdaten, die für die Übertragungsqualität weniger
kritisch sind, die für
die Übertragung
verbleibende Bandbreite gemeinsam nutzen. Entsprechend wird der
Multiplexing-Prozess so angepasst, dass er die höchste Übertragungspriorität den Echtzeit-Datenstrompaketen
zuweist. Bei einer nur sehr geringen verbleibenden Bandbreite – die die
parallele Übertragung
mehrerer Nicht-Echtzeitdatenströme
nicht zulässt – kann es
vorkommen, dass nur Fragmente von einem der Nicht-Echtzeitdatenströme mit Bezug
zu einem Echtzeitpaket übertragen
werden.
-
Die
Nicht-Echtzeitinformationen wie beispielsweise der Signal- und der Steuerungs-Datenverkehr
kann in freien, nicht genutzten Platz der Datenpakete des Echtzeitdatenverkehrs
eingefügt
werden. Es ist außerdem
möglich,
dass die Nicht-Echtzeitinformationen und die Echtzeitdaten aus den
ursprünglichen
Datenpaketen extrahiert und in neue Datenpakete gepackt werden,
möglicherweise
unter einem anderen Protokoll. Darüber hinaus ist es auch möglich, dass
die Nicht-Echtzeitdaten in anderen Datenpaketen übertragen werden als die Echtzeitdaten, d.
h. dass der Signaldatenverkehr und/oder der Steuerungs-Datenverkehr
und der Echtzeitdatenverkehr separate Datenpakete für die Übertragung
verwenden. Gemäß einer
weiteren Ausführungsform
der Erfindung werden die Signal- und die Steuerungsnachrichten über ein
beliebiges gängiges
und geeignetes Übertragungsprotokoll
mit den Echtzeitdaten gemultiplext/interleaved.
-
Bevorzugte
Protokolle für
die Übertragung des
gemultiplexten Datenstroms sind RTP, UDP, UDP Lite, IP.
-
Gemäß einer
bevorzugten Ausführungsform der
Erfindung werden die Fragmente des Signal- und/oder Steuerungsdatenverkehrs
in den Echtzeitdatenverkehrsstrom der Kommunikationsverbindung gemultiplext
durch Erzeugen separater Datenstrompakete für den Signal- und/oder Steuerungsdatenverkehr
und den Echtzeitdatenverkehr, wobei jedes Datenstrompaket einen
IP-Datenkopf, einen UDP-Datenkopf, Informationen über die
Art der Nutzlast, insbesondere den Signaldatenverkehr, den Steuerungsdatenverkehr
oder den Echtzeitdatenverkehr umfasst sowie eine Datenstromkennung,
eine Sequenznummer, Informationen über die Länge der Nutzlast und die Nutzlast
des Signaldatenverkehrs oder Steuerungsdatenverkehrs oder Echtzeitdatenverkehrs.
-
Gemäß einer
weiteren bevorzugten Ausführungsform
der Erfindung werden die Fragmente des Signaldatenverkehrs und/oder
Steuerungsdatenverkehrs in den Echtzeit-Datenverkehrsstrom der Kommunikationsverbindung
gemultiplext durch Erzeugen separater Datenstrompakete für den Signal- und/oder
Steuerungsdatenverkehr und den Echtzeitdatenverkehr, wobei jedes
Datenstrompaket einen IP-Datenkopf, einen UDP-Datenkopf und einen RTP-Datenkopf
umfasst und wobei die Datenstrompakete für den Signal- und/oder Steuerungsdatenverkehr
eine RTP-Datenkopferweiterung umfassen mit einem zusätzlichen
UDP-Pseudodatenkopf und mit der Nutzlast des Signaldatenverkehrs
oder Steuerungsdatenverkehrs.
-
Es
ist auch möglich,
dass die Fragmente des Signaldatenverkehrs und/oder Steuerungsdatenverkehrs
in den Echtzeit-Datenverkehrsstrom
der Kommunikationsverbindung gemultiplext werden durch Erzeugen
separater Datenstrompakete für
den Signal- und/oder Steuerungsdatenverkehr und den Echtzeitdatenverkehr,
wobei jedes Datenstrompaket einen IP-Datenkopf, einen UDP-Datenkopf
und einen RTP-Datenkopf umfasst und wobei die Datenstrompakete für den Signal-
und/oder Steuerungsdatenverkehr eine RTP-Datenkopferweiterung mit
zusätzlichen
Rahmeninformationen und mit der Nutzlast des Signaldatenverkehrs
oder Steuerungsdatenverkehrs umfassen. Die zusätzlichen Rahmeninformationen können Informationen
umfassen wie beispielsweise eine Segmentnummer, eine Gesamtanzahl
von Segmenten und eine Prüfsumme.
-
Es
ist des Weiteren möglich,
dass die Fragmente des Signaldatenverkehrs und/oder Steuerungsdatenverkehrs
in den Echtzeit-Datenverkehrsstrom
der Kommunikationsverbindung gemultiplext werden durch Erzeugen
separater Datenstrompakete für
den Signal- und/oder Steuerungsdatenverkehr und den Echtzeitdatenverkehr,
wobei jedes Datenstrompaket einen IP-Datenkopf mit einer neuen Internet-Protokollnummer
umfasst und wobei das Datenstrompaket für den Signal- und/oder Steuerungsdatenverkehr
einen zusätzlichen
UDP-Pseudodatenkopf mit der Nutzlast des Signaldatenverkehrs oder Steuerungsdatenverkehrs
umfasst, und wobei das Datenstrompaket für den Echtzeitdatenverkehr
einen zusätzlichen
RTP- und UDP-Pseudodatenkopf mit der Nutzlast des Echtzeitdatenverkehrs
umfasst.
-
Es
ist aber auch möglich,
dass gemäß einer weiteren
bevorzugten Ausführungsform
der vorliegenden Erfindung die Fragmente des Signaldatenverkehrs
und/oder Steuerungsdatenverkehrs in den Echtzeit-Datenverkehrsstrom
der Kommunikationsverbindung gemultiplext werden durch Erzeugen
eines Datenstrompakets, das einen IP-Datenkopf, einen UDP Lite-Datenkopf
und einen RTP-Datenkopf umfasst.
Der Signaldatenverkehr oder der Steuerungsdatenverkehr werden dann
zusammen mit zusätzlichen
Rahmeninformationen, die eine Segmentnummer, eine Gesamtzahl von
Segmenten und eine Prüfsumme
umfassen, in den zusätzlichen
Nutzlastabschnitt des UDP Lite-Pakets eingefügt.
-
Bevorzugt
werden die Fragmente des Signaldatenverkehrs und/oder des Steuerungsdatenverkehrs
in den Echtzeit-Datenverkehrsstrom
der Kommunikationsverbindung gemultiplext durch Erzeugen eines Datenstrompakets,
das einen IP-Datenkopf, einen UDP-Datenkopf und einen RTP-Datenkopf
gemäß dem redundanten
RTP umfasst. Der Signaldatenverkehr oder der Steue rungsdatenverkehr
werden dann zusammen mit einem UDP-Pseudodatenkopf in den redundanten
Abschnitt des redundanten RTP-Pakets
eingefügt.
-
Diese
und weitere Merkmale und Vorteile der Erfindung werden besser verständlich durch
die Lektüre
der folgenden ausführlichen
Beschreibung der bevorzugten exemplarischen Ausführungsformen der vorliegenden
Erfindung in Verbindung mit den beigefügten Zeichnungen, wobei gilt:
-
1 ist
ein schematisches Blockdiagramm eines Telekommunikationssystems,
das das Verfahren gemäß einer
ersten Ausführungsform
der Erfindung nutzt.
-
2 ist
ein Ablaufdiagramm des Verfahrens gemäß einer ersten Ausführungsform
der Erfindung.
-
3 ist
ein Blockdiagramm, das eine Teilstufe des Verfahrens gemäß einer
weiteren Ausführungsform
der Erfindung zeigt.
-
4 ist
ein Diagramm eines zugeordneten gemultiplexten Echtzeitpakets gemäß einer
weiteren Ausführungsform
der Erfindung.
-
5 ist
ein Diagramm eines zugeordneten gemultiplexten Echtzeitpakets gemäß einer
weiteren Ausführungsform
der Erfindung.
-
6 ist
ein Diagramm eines zugeordneten gemultiplexten Echtzeitpakets gemäß einer
weiteren Ausführungsform
der Erfindung.
-
7 ist
ein Diagramm eines zugeordneten gemultiplexten Echtzeitpakets gemäß einer
weiteren Ausführungsform
der Erfindung.
-
8 ist
ein Diagramm eines zugeordneten gemultiplexten Echtzeitpakets gemäß einer
weiteren Ausführungsform
der Erfindung.
-
9 ist
ein Diagramm eines zugeordneten gemultiplexten Echtzeitpakets gemäß einer
weiteren Ausführungsform
der Erfindung.
-
1 zeigt
ein Übertragungssystem,
das die an ein Übertragungsmedium 30 angeschlossenen Endgeräte 10, 20, 90 mit
den Netzwerkknoten 41, 42, 43 und den
Firewalls 11, 21 umfasst.
-
Es
ist möglich,
dass es sich bei dem Übertragungssystem
um ein Telekommunikationssystem mit einem Paketvermittlungsnetzwerk 30 handelt.
Bei dem Paketvermittlungsnetzwerk 30 kann es sich um das öffentliche
Internet oder um ein anderes Paketvermittlungsnetzwerk auf der Basis
eines IP-Protokolls handeln. Das Paketvermittlungsnetzwerk 30 kann
auch mehrere physische Teilnetzwerke umfassen wie beispielsweise
Ethernet, ATM-Netzwerke und Wireless Access Netzwerke (WLAN), die über eine
gemeinsame IP-Kommunikationsschicht gemäß Schicht Drei miteinander
verbunden sind (ATM = „Asynchronous
Transfer Mode";
WLAN = Wireless Local Area Network").
-
Ein
einem Anrufer zugeordnetes erstes Telekommunikationsendgerät 10 und
ein einem Angerufenen zugeordnetes zweites Telekommunikationsendgerät 20 sind
mit dem Paketvermittlungsnetzwerk 30 verbunden und können zum
Einleiten und zum Empfangen von VoIP-Telekommunikationsanrufen über das
Paketvermittlungsnetzwerk 30 verwendet werden. Bei den
Telekommunikationsendgeräten 10, 20 kann
es sich um VoIP-Festtelefone oder VoIP-Softphones oder einen mit
einem Mikrofon, Lautsprechern und einer Soundkarte ausgestatteten PC
handeln, der mithilfe einer dedizierten VoIP-Telefonsoftware als
Softphone arbeitet.
-
Die
Erfindung ist nicht auf ein Ende-zu-Ende-Szenario begrenzt. Sie
kann auch zwischen einem Endgerät 10, 20 und
einen Netzwerkknoten 41, 42 oder zwischen den
Netzwerkknoten 41, 42, 43 verwendet werden.
Und sie erlaubt die Kommunikation mit einem Endgerät 90,
das nicht gemäß dieser Erfindung
aufgebaut ist. Im folgenden Text ist nur der Fall von Endgerät zu Endgerät beschrieben
als Darstellung aller weiterer möglichen
Szenarien.
-
Jede
der Verbindungen, die das erste Telekommunikations-Endgerät 10 und
das zweite Telekommunikations-Endgerät 20 mit dem Paketvermittlungsnetzwerk 30 verbinden,
kann eine Firewall-Anwendung
oder eine Firewall-Hardware 11, 21 umfassen, um
bestimmte Anwendungen zu den Telekommunikations-Endgeräten 10, 20 zuzulassen
oder davon auszuschließen.
-
Ein
Benutzer des ersten Telekommunikations-Endgeräts 10 möchte über VoIP
einen Benutzer des zweiten Telekommunikations-Endgeräts 20 anrufen.
Zum Einleiten des VoIP-Anrufs ist das erste Telekommunikations-Endgerät so angepasst,
dass es Signaldaten wie beispielsweise SIP-Pakete über das Paketvermittlungsnetzwerk 30 an
das zweite Telekommunikations-Endgerät 20 schickt. Nach
dem Einrichten einer VoIP-Verbindung zwischen dem ersten Telekommunikations-Endgerät 10 und
dem zweiten Telekommunikations-Endgerät 20 kann der Benutzer des
ersten Telekommunikations-Endgeräts 10 mit dem
Benutzer des zweiten Telekommunikations-Endgeräts 20 sprechen. Es
werden also Sprachdaten übertragen,
beispielsweise als RTP-Pakete vom ersten Telekommunikations-Endgerät 10 an
das zweite Telekommunikations-Endgerät 20.
-
In
der Echtzeit-VoIP-Verbindung des vorliegenden Beispiels darf die Übertragung
der Echtzeitdatenpakete, die die Sprachdaten transportieren, keine
deutliche Verzögerung
aufweisen, da jede Verzögerung
zu einer unerwünschten
Verschlechterung der Sprachqualität am zweiten, dem empfangenden Telekommunikations-Endgerät 20 führt. Bei
einem aktiven Gespräch
wird eine Latenz der Echtzeitdatenpakete über 200 ms von Menschen wahrgenommen.
Die zuverlässige
und kontinuierliche Übertragung
der Echtzeitdatenpakete wird ermöglicht
mithilfe eines Steuerungs-Datenverkehrs,
der dem Echtzeitdatenverkehr zugeordnet ist. Wenn der Echtzeitdatenverkehr über RTP übertragen
wird, kann der Steuerungs-Datenverkehr über RTCP („Real Time Control Protocol", Echtzeitsteuerungsprotokoll)
umgesetzt werden. Der RTCP-Datenverkehr sorgt für die Aushandlung und Einhaltung
der QoS-Parameter („Quality
of Service", Dienstgüte) über den
periodischen Austausch von Steuernachrichten zwischen dem Sender
und dem Empfänger.
-
Für die VoIP-Kommunikationsverbindung zwischen
dem ersten Telekommunikations-Endgerät 10 und dem zweiten
Telekommunikations-Endgerät 20 müssen sowohl
Echtzeitdaten, d. h. Sprachdaten, als auch Nicht-Echtzeitsignaldaten
und den Echtzeitdaten zugeordnete Steuerungsdaten übertragen werden.
-
Der
gemultiplexte Datenstrom aus den Echtzeitdaten und den Nicht-Echtzeitdaten
der Verbindung kann über
eine NAT/NAPT-Einheit
wie beispielsweise die in 1 dargestellte
Firewall-Implementierung 11, 21 übertragen
werden. Das Verfahren gemäß der Erfindung
ermöglicht
den NAT/NAPT-Übergang
von Nicht-Echtzeitdatenpaketen, da die Echtzeitdatenpakete (nur
für den
verwendeten UDP-Port) die Tür
einer Firewall-Einheit für
die Nicht-Echtzeitdatenpakete „öffnen".
-
Es
ist des Weiteren möglich,
dem Verfahren einen Offenhaltemechanismus, eventuell mit einer Erweiterung,
hinzuzufügen,
um eine solche Firewall-Tür
offen zu halten.
-
Das
Verfahren gemäß der vorliegenden
Erfindung kann für
die Verwaltung und Steuerung eines integrierten funktionserweiterten
IP-Telefons verwendet werden. Die Übertragung der Nicht-Echtzeitdatenpakete
in Verbindung mit den Echtzeitdatenpaketen kann jedoch auch für die Verwaltung
und Steuerung der im Netzwerk implementierten Funktionen für ein „dummes" IP-Telefon verwendet
werden. Es können
beispielsweise einem Benutzer beim Abnehmen des Telefons Audio-Ansagen
abgespielt werden.
-
2 zeigt
ein Ablaufdiagramm mit einer Beschreibung der operativen Schritte,
die zur Ausführung
des Verfahrens gemäß einer
ersten Ausführungsform
der vorliegenden Erfindung im Telekommunikationssystem aus 1 ausgeführt werden müssen. Nicht-Echtzeitdatenströme wie die
Signaldatenströme 110,
die Steuerungs-Datenverkehrsströme 111 und
andere Nicht-Echtzeitdatenströme 112 müssen über das
Paketvermittlungsnetzwerk 30 vom ersten Telekommunikations-Endgerät 10 an
das zweite Telekommunikations-Endgerät 20 übertragen werden.
Die Signaldatenströme 110 können beispielsweise
SIP-Datenströme
umfassen, die Steuerungs-Datenverkehrsströme 111 können beispielsweise
RTCD-Datenströme sein,
und die anderen Nicht-Echtzeitdatenströme 112 können beispielsweise
SNMP- oder H.248-Datenströme
sein (SNMP = „Simple
Network Management Protocol").
-
Die
Nicht-Echtzeitdatenströme
sind einem oder mehreren Echtzeitdatenströmen 113, 114 zugeordnet,
die Echtzeitdaten wie beispielsweise VoIP-Sprachdatenpakete oder
Sprach/Video-Datenpakete
zu Videokonferenzen umfassen, die gegenüber Übertragungsverzögerungen
sehr empfindlich sind. Verschiedene Übertragungsprotokolle wie z.
B. UDP oder RTP eignen sich zum Senden der Echtzeitdatenpakete (UDP
= „User
Datagram Protocol").
-
Die
Erfindung ist mit allen Arten möglicher Stacks
anwendbar. Die in der Beschreibung angegebenen Stacks dienen daher
nur als Darstellung aller möglichen
Echtzeit- und Nicht-Echtzeitprotokolltypen einer Kommunikationsverbindung.
-
Die
Nutzlast der Signal- und Steuerungs-Datenpakete kann eine sehr unterschiedliche
Größe haben,
je nach der momentanen Menge des für die Signalisierung und Steuerung
erforderlichen Datenverkehrs. Andererseits zeigen die kontinuierlich übertragenen
Echtzeitdatenpakete kein so intensives Burst-Datenverhalten wie
der Signal- und Steuerungsdatenverkehr.
-
In
den Schritten 120, 121, 122 werden die Nicht-Echtzeit
SIP-Datenpakete 110,
die Nicht-Echtzeit RTCP-Datenpakete 111 und die Nicht-Echtzeit SNMP-Datenpakete 112 in
kleinere Fragmente aufgebrochen. Alle SIP-, RTCP- und SNMP-Fragmente werden
mit Informationen über
ihren Inhalt und zusätzlichen
Rahmeninformationen versorgt, wie beispielsweise der Gesamtanzahl
der Fragmente, in die ein ursprüngliches
SIP/RTCP/SNMP-Paket aufgebrochen wurde, einer Segmentnummer, die
die Position des aktuellen Fragments in Relation auf die anderen
Fragmente definiert, und einer Prüfsumme.
-
Jedes
der SIP/RTCP/SNMP-Fragmente kann mit Kopfdaten, Abschlussdaten und
anderen erforderlichen Paketbestandteilen versorgt werden, sodass
ein unabhängiges
neues Datenpaket erzeugt wird, das unabhängig über die Echtzeitverbindung gesendet
werden kann. Es kann jedoch auch sein, dass jedes der SIP/RTCP/SNMP-Fragmente
in ein vorhandenes RTP-Paket integriert wird, beispielsweise durch
Anhängen
der SIP/RTCP/SNMP-Nutzlast
in eine zusätzlich
eingefügte
Kopfdatenerweiterung oder durch Einfügen der SIP/RTCP/SNMP-Nutzlast in
den Nutz lastbereich des RTP-Pakets, der den RTP-Daten zwar zugeordnet,
aber nicht verbraucht wurde. Diese und andere Ausführungsformen
werden in der nachfolgenden Beschreibung ausführlich erläutert.
-
Die
Fragmente werden in eine Warteschlange eingereiht und im Multiplexing-Schritt 130 über Interleaving
oder Multiplexing in einem oder mehreren der RTP-Datenströme 113, 114 angeordnet.
In Schritt 140 werden die gemultiplexten Datenströme vom ersten
Telekommunikations-Endgerät 10 über eine oder
mehrere den ersten RTP-Paketen zugeordnete Echtzeitverbindungen
an das zweite Telekommunikations-Endgerät 20 übertragen.
-
Falls
eine Signalzuordnung mehrere RTP-Datenströme steuert, kann der Signal-
oder Steuerungsdatenverkehr exklusiv einem RTP-Datenstrom zugeordnet
oder auf mehrere RTP-Datenströme
verteilt werden.
-
Falls
eine Firewall an der Verbindung installiert ist, hält der kontinuierliche
RTP-Datenverkehr die Firewall auch für den Nicht-Echtzeitdatenverkehr
geöffnet,
d. h. für
Signal-, Steuerungs- und andere Nicht-Echtzeit-Datenverkehrsarten,
die am RTP-Datenverkehr gemultiplext werden. An dem zweiten Telekommunikations-Endgerät 20 werden
die gemultiplexten Datenströme
in Schritt 150 demultiplext, und die Signal- und Steuerfragmente
werden zum Defragmentieren in eine Warteschlange eingereiht.
-
Es
ist beispielsweise möglich,
dass die unabhängigen
SIP/RTCP/SNMP-Datenpakete in die richtige Reihenfolge gebracht werden,
d. h. entsprechend ihrer Segmentnummer werden die Informationen
zu Datenrahmen, die nur zur Übertragung
erforderlich waren, aus der SIP/RTCP/SNMP-Nutzlast entfernt, und
die SIP/RTCP/SNMP-Daten werden nacheinander wieder miteinander verbunden,
um das ursprüngliche
Datenpaket wiederherzustellen. Es ist auch möglich, dass die in den RTP-Paketen enthaltenen
SIP/RTCP/SNMP-Daten aus den eingehenden RTP-Datenpaketen extrahiert
und zum Wiederherstellen des ursprünglichen Datenpakets verwendet
werden.
-
Der
Prozess der Defragmentierung und des Wiederzusammensetzens der SIP/RTCP/SNMP-Fragmente
ist in 2 anhand der Schritte 160, 161 und 162 dargestellt.
Als Ergebnis werden die ursprünglichen
SIP/RTCP/SNMP-Datenpakete 170, 171, 172 wiederhergestellt.
Aus dem Schritt 150 zum Demultiplexen wurden die Echtzeit-RTP-Datenpakete 173, 174 erhalten,
die nicht wieder zusammengesetzt werden müssen.
-
Einige
Vorteile lassen sich erzielen, wenn eine zusätzliche Identifikation (=ID)
und/oder Referenzinformationen zu den Nicht-Echtzeitdatenströmen über die
gemultiplexten Echtzeitdatenströme gesendet
werden.
-
3 zeigt
Details zu den Schritten 110 bis 130 zu Fragmentierung
und Multiplexing gemäß der Beschreibung
aus 2.
-
Echtzeitdaten
werden als kontinuierliches isochrones Paket gesendet. In diesem
Beispiel werden die kleinen Pakete als RTP-Pakete gesendet. RTP
ist ein Protokoll, das auf verschiedene Arten für die Zustellung von Echtzeitdaten
optimiert wurde, beispielsweise für aktive und/oder interaktive
Audio- und Videodaten über IP-Paketvermittlungsnetzwerke.
RTP läuft über UDP
und verwendet dessen Multiplexing- und Fehlerprüfungsfunktionen. Gemäß der üblichen
Aufgabe des RTP-Protokolls umfasst der RTP-Datenverkehr 213, 214 in 3 kontinuierliche isochrone
Datenströme
von Echtzeitpaketen.
-
Das
RTCP-Protokoll liefert Rückmeldungen zur
Qualität
der Datenverteilung. RTCP basiert auf der periodischen Übertragung
von Steuerpaketen an alle Teilnehmer in der Session mithilfe der
gleichen Verteilungsmechanismen wie bei den Datenpaketen. 3 zeigt
die RTCP-Pakete 212 und weitere Nicht-Echtzeitpakete 211,
die den RTP-Paketdatenströmen 213, 214 zugeordnet
sind.
-
3 zeigt
außerdem
SIP-Pakete 210 als Darstellung eines Nicht-Echtzeitsignalprotokolls
zur Einrichtung der RTP/RTCP-Verbindung.
Zum Einrichten einer solchen RTP/RTCP-Verbindung muss die Signalverarbeitung
Informationen mit dem anderen Ende (dem fernen Endgerät oder Netzwerkknoten)
austauschen. Solange die Echtzeitdatenströme noch nicht eingerichtet
sind, kann sie die gesamte zulässige
Bandbreite für
Echtzeitdatenströme
verwenden.
-
3 zeigt
nur eine Richtung, normalerweise gilt das Prinzip jedoch für beide
Richtungen.
-
Wegen
des Burst-Verhaltens des Signal- und Steuerungsdatenverkehrs sowie
des sonstigen Nicht-Echtzeitdatenverkehrs ist jedes Datenpaket des
SIP-Datenverkehrs 210, des RTCP-Datenverkehrs 212 und
des weiteren Nicht-Echtzeitdatenverkehrs 211 anders, und
die Pakete können
erheblich größer sein
als typische RTP-Pakete des RTP-Datenverkehrsstroms 213, 214.
-
In
einem ersten Schritt des Prozesses 220 werden die Datenpakete
des SIP-Datenverkehrs 210, des RTCP-Datenverkehrs 212 und
des weiteren Nicht-Echtzeitdatenverkehrs 211 zu kleineren
Paketen fragmentiert. In einem zweiten Schritt des Prozesses 220 werden
die fragmentierten kleineren SIP-, RTCP- und andere Nicht-Echtzeitdatenpakete zu
einheitlich großen
RTP-Paketdatenströmen 213, 214 gemultiplext
und/oder interleaved. Zur Sicherstellung des Echtzeitcharakters
der gesendeten RTP-Datenströme 213, 214 wird
den RTP-Paketen absolute Sendepriorität eingeräumt. Alle SIP-, RTCP- und andere
Nicht-Echtzeitdatenpakete, die in der Warteschlange auf die Übertragung
war ten, werden in Fragmenten gesendet; hierzu wird der verfügbare Sendebereich
genutzt, ohne die für
RTP-Pakete verfügbare
Bandbreite einzuschränken.
Zum Abschluss werden die gemultiplexten RTP-Datenströme 230, 231 gesendet.
-
Das
Multiplexing kann auf unterschiedliche Weise und mit unterschiedlichen
Protokollen durchgeführt
werden. Einige Beispiele sind in der folgenden Beschreibung mit
Blick auf die 4 bis 9 dargestellt.
-
In
allen Ausführungsformen
gemäß den 4 bis 9 werden
die Datenpakete, die den Echtzeitdatenverkehr und den Nicht-Echtzeitdatenverkehr
enthalten, unter dem IP-Protokoll transportiert. Das bedeutet, alle
Pakete umfassen einen IP-Datenkopf auf der Netzwerkebene und einen UDP-Datenkopf
auf der Transportschicht. Es ist jedoch auch möglich, dass Datenpakete mit
dem Signal- und/oder Steuerungsdatenverkehr einen TCP-Datenkopf auf der
Transportschicht umfassen.
-
4 zeigt
ein dem Echtzeitdatenverkehr zugeordnetes gemultiplextes Paket zusätzlich zu UDP.
Es gibt drei Pakettypen: Echtzeit-RTP, Nicht-Echtzeit-RTP und Nicht-Echtzeit-SIP.
Der Typ des Datenpakets ist in den ersten vier Oktetten des Pakets
angegeben, ebenso die Datenstrom-ID, eine Sequenznummer und ein
Längenfeld.
Der verbleibende Teil des Pakets umfasst die Nutzlast des entsprechenden
Datenstroms. Die Nutzlast kann mit Leerdaten aufgefüllt werden,
wenn das letzte Fragment nicht auf die übliche 4-Byte-Begrenzung abgestimmt
ist.
-
5 zeigt
ein dem Echtzeitdatenverkehr zugeordnetes gemultiplextes Paket zusätzlich zu RTP.
Das Datenpaket transportiert einen RTP-Datenkopf. Die SIP- oder
RTCP-Nutzlast ist in der RTP-Datenkopferweiterung enthalten, bei
der es sich um einen UDP-Pseudo-Datenkopf handeln kann.
-
6 zeigt
ein dem Echtzeitdatenverkehr zugeordnetes gemultiplextes Paket zusätzlich zu
einem anwendungsspezifischen RTP-Protokoll. Das Paket ähnelt dem
in 5 dargestellten Paket mit dem Unterschied, dass
im SIP- bzw. RTCP-Nutzlastabschnitt kein UDP-Pseudo-Datenkopf verwendet wird.
Statt dessen sind zusätzliche
Rahmeninformationen wie beispielsweise die Segmentnummer, die Gesamtzahl
der Segmente und eine Prüfsumme
enthalten.
-
7 zeigt
ein dem Echtzeitdatenverkehr zugeordnetes gemultiplextes Paket,
das eine neue Internet-Protokollnummer verwendet. Das Datenpaket
transportiert einen IP-Datenkopf, wobei das Protokoll als „rt-mux", d. h. als gemultiplextes
RTP-Protokoll gekennzeichnet ist. Der Nutzlastabschnitt des IP-Pakets
transportiert entweder die RTP-Daten, die SIP-Nachricht oder die
RTCP-Daten. Die RTP-Daten sind als RTP-Typ formatiert, die SIP-
und RTCP-Daten sind als UDP-Typ formatiert.
-
8 zeigt
ein dem Echtzeitdatenverkehr zugeordnetes gemultiplextes Paket zusätzlich zu UDP-Lite
gemäß RFC 3828.
Das Paket transportiert einen IP-Datenkopf. Im Optionsabschnitt
des IP-Datenkopfs ist ein UDP-Lite-Datenkopf eingefügt. Auf den
UDP-Lite-Datenkopf folgt das Abdeckungs-RTP-Paket, auf das der Abschnitt
der Signal- oder Steuerinformationen folgt. Dieser Abschnitt umfasst
die SIP-Nachricht oder die RTCP-Informationen sowie
zusätzliche
Rahmeninformationen wie beispielsweise die Segmentnummer, die Gesamtzahl der
Segmente und eine Prüfsumme.
Die Informationen in den einzelnen Segmenten werden unter ihrem spezifischen
Typ gespeichert, d. h. SIP bzw. RTCP.
-
9 zeigt
ein dem Echtzeitdatenverkehr zugeordnetes redundantes RTP-Paket
gemäß RFC 2198.
Zur Kompensation der Möglichkeit
des Verlusts von Paketen kann jedes RTP-Paket zusätzlich zur
oder statt der primären
Datennutzlast redundante Informa tionen umfassen. Diese redundanten
Daten können
als Reaktion auf eine Anforderung zur erneuten Übertragung verlorene Nutzlastdaten
exakt ersetzen. Alternativ dazu können sie auch einen konstanten
verzögerten
sekundären
Datenstrom mit Daten niedrigerer Qualität und niedrigerer Bandbreite
darstellen, die ein Empfänger
als Ersatz für
verlorene primäre
Daten verwenden kann.
-
Die
Ausführungsform
gemäß 9 ähnelt der
in 8 und verwendet lediglich einen anderen Nutzlasttyp.
-
3
-
- Nicht-Echtzeit
- Signaldatenverkehr, z. B. SIP
- ...
- andere
- RCTP
- Echtzeit
- RTP
- ...
- RTP
- A) Fragmentierung des Nicht-Echtzeitdatenverkehrs S + O + C
- B) Multiplexing von S + O + C + R + Echtzeitdatenverkehr
-
4
-
- Typ = RTP E P Stream-ID Sequenznummer Länge
- RTP-Nutzlast – Auffüllen
- Typ = RTCP E P Stream-ID Sequenznummer Länge
- RTCP-Nutzlast (Segment) – Auffüllen
- Typ = SIP E P Stream-ID Sequenznummer Länge
- SIP-Nutzlast (Segment) – Auffüllen
-
5
-
- Ver P X CSRC M Nutzlasttyp Sequenznummer
- Zeitstempel
- Synchronisationsquellen-ID (SSRC)
- Zuführungsquellen-ID
(RSRC)
- (Durch Profil definiert) (Länge
der Erweiterung)
- Kopfdatenerweiterung
- RTP-Nutzlast
- Profil = n – mux
Länge
- Typ = UDP E P Subtyp-Länge
- Nutzlast = SIP/UDP Pseudo-Datenkopf – Auffüllen
- Typ = UDP E P Subtyp-Länge
- Nutzlast = RTCP/UDP Pseudo-Datenkopf – Auffüllen
-
6
-
- Ver P X CSRC M Nutzlasttyp Sequenznummer
- Zeitstempel
- Synchronisationsquellen-ID (SSRC)
- Zuführungsquellen-ID
(RSRC)
- (Durch Profil definiert) (Länge
der Erweiterung)
- Kopfdatenerweiterung
- RTP-Nutzlast
- Profil = n – mux
Länge
- Typ = SIP E P Subtyp-Länge
- Nutzlast = SIP-Nachricht + zusätzliche Rahmeninformationen – Auffüllen
- Typ = RTCP E P Subtyp-Länge
- Nutzlast = RTCP-Info + zusätzliche
Rahmeninformationen – Auffüllen
-
7
-
- Version IP-Kopfdatenlänge
Diensttyp Gesamtlänge (in
Byte)
- Identifikation D F Fragmentversatz
- TTL Protokoll = n – mux
Kopfdaten-Prüfsumme
- Quelladresse
- Zieladresse
- Option (0–40
Byte)
- Nutzlast
- Typ = RTP E P Subtyp-Länge
- Nutzlast = RTP/Pseudo-UDP – Auffüllen
- Typ = UDP E P Subtyp-Länge
- Nutzlast = SIP-Nachricht/Pseudo-UDP – Auffüllen
- Typ = RTCP E P Subtyp-Länge
- Nutzlast = RTCP/Pseudo-UDP – Auffüllen
-
8
-
- Version IP-Kopfdatenlänge
Diensttyp Gesamtlänge (in
Byte)
- Identifikation D F Fragmentversatz
- TTL Protokoll Kopfdaten-Prüfsumme
- Quelladresse
- Zieladresse
- Option (0–40
Byte)
- Ausgangs-Port Ziel-Port
- Prüfsummen-Abdeckung
Prüfsumme
- Abdeckungs-RTP-Paket
- Profil = n – mux
Länge
- Typ = SIP E P Subtyp-Länge
- Nutzlast = SIP-Nachricht + zusätzliche Rahmeninformationen – Auffüllen
- Typ = RTCP E P Subtyp-Länge
- Nutzlast = RTCP-Info + zusätzliche
Rahmeninformationen – Auffüllen
-
9
-
- Ver P X CSRC M Nutzlasttyp Sequenznummer
- Zeitstempel
- Synchronisationsquellen-ID (SSRC)
- Zuführungsquellen-ID
(RSRC)
- F Block PT = n – mux
Zeitstempelversatz (14b) Blocklänge (10b)
- F Block PT Zeitstempelversatz (14b) Blocklänge (10b)
- 0 Block PT
- RTP-Nutzlast
- Typ = UDP E P Subtyp-Länge
- Nutzlast = SIP/UDP Pseudo-Kopfdaten – Auffüllen
- Typ = UDP E P Subtyp-Länge
- Nutzlast = RTCP/UDP Pseudo-Kopfdaten – Auffüllen