Echtzeitkommunikation für VolP (Voice over Internet Protocol) oder Video over IP bildet ein Netzwerk-Overlay über bestehende IP-Netzinfrastrukturen. Echtzeitkommunikation ist sensitiv für Paketverluste und Paketübermittlungsverzögerungen (insbesondere Packet Loss, Delay, Jitter) und kann deshalb die Benutzererfahrung (Quality-of-Experience - QoE) beeinträchtigen. In IP-Netzen mit "klassischer L2/L3-QoS-Unterstützung" werden Verkehrsklassen (QoS, Quality of Service) unterschieden und auf den Übermittlungsschichten 2 (Layer 2, L2) und 3 (Layer 3, L3) markiert. Diese Markierung ermöglicht es den Netzkomponenten in L2/L3- QoS-unterstützenden Netzwerken, in der Erfindung als dienstgütesensitive Netzwerke genannt, unterschiedliche Prioritäten bei der Weiterleitung anzuwenden (Per-hop

Behaviour - PHB) (IEEE802.1 p / DiffServ). Die Anwendung des PHB erfolgt paketweise auf Basis der genannten Markierungen. Die Vergabe dieser Markierungen kann entweder im Medienendpunkt selbst (intern) erfolgen oder extern mittels erkanntem (Medien- )Datenfluss durch ein Netzelement vorgenommen werden. Jedem solcher (Medien- )Datenflüsse (Flows) wurde bisher je eine eigene Portnummer zugeteilt, weshalb hier Eindeutigkeit geherrscht hat. Der Begriff "dienstgütesensitiv" bedeutet dabei, dass ein PHB pro Paket und in jedem Knoten ausgeführt wird, und ist auch als "QoS-aware" bekannt. Die Datenflüsse für Audio- und Videodaten bestehen typischerweise aus einer Folge von IP/UDP-Paketen, die eine Folge von Real-Time Protokoll (RTP)- Protokollelementen als Nutzdaten beinhalten.

Eine Mischung von Verkehrsarten wie Audio, Video, Screen-Sharing, Daten oder auch Gaming über denselben Port oder gar innerhalb desselben Flows ist zwar protokolltechnisch möglich, wurde aber bislang nicht verwendet und wird folglich von den Switches (L2) und Routern (L3) bis dato nicht unterstützt.

Hierbei gilt es zwei Fälle zu unterscheiden:

1. Verschiedene Flows gleichen Medientyps teilen sich dieselbe Portnummer (Port- Multiplexing);

Vorteile: Verwaltungsaufwand in den Servern und an den Netzübergängen bzgl. der Ports wird reduziert. 2. Verschiedene Medientypen als Servicekomponenten werden in ein und demselben IP- Paket übertragen (Service-Multiplexing innerhalb der IP-Pakete, zusätzlich zu Port- Multiplexing);

Vorteile: Zusätzlich zu 1. ergibt sich eine weitere Reduzierung des Portverwaltungsauf- wandes und ein reduzierter Bandbreitenbedarf, da nur ein IP-Header für mehrere RTP- Protokollelemente benötigt wird (geringerer Protokoll-Overhead).

In beiden Fällen geht die eingangs erwähnte Eindeutigkeit der Zuordenbarkeit von Port zu Servicekomponente bzw. Medientyp verloren.

Im 1. Fall funktioniert zwar der beschriebene Weg der internen Markierung und Auswer- tung auf den Ebenen L2 und L3 noch, die Möglichkeit der externen Markierung auf Grund der Portnummer entfällt jedoch.

Im 2. Fall greift auch die klassische Technik mit den Markierungen nicht mehr, da ein IP- Paket nur eine Markierung tragen kann, sich innerhalb eines IP-Pakets aber Anteile ver- schiedener Flows und unterschiedlicher Medientypen befinden (können), die meist verschiedene Markierungswerte benötigen.

Die Übermittlung von Mediendaten (real time und non-real time) z.B. direkt aus dem Internet/Web-Browsern heraus wie beispielsweise im aktuellen WebRTC (auch als RTCWeb bekannt)-Standardisierungsansatz (z.B. für Firefox, Google Chrome ...) ist eine neue, gerade in der Definition befindliche Technologie.

Die bei der eingangs beschriebenen "klassischen QoS-Unterstützung" gewählte Zuordnung von Port zu Flow führt bei Multimedia-Anwendungen zu einem erhöhten Verwal- tungs- und Implementierungsaufwand und stellt gerade bei der Überwindung von NATs (Network Address Translation) und Firewalls und hier speziell im angestrebten Massenmarkt (z.B. Google Cloud Services) eine nicht zu vernachlässigende Hürde dar. Deshalb soll WebRTC von der Verwaltung der individuellen Verbindungen und damit der verschiedenen Portassoziationen entlastet werden, was durch "Port Multiplexing" und/oder "Ser- vice-Multiplexing" erreicht werden soll.

Es ist anzunehmen, dass, nachdem die WebRTC-Technologie standardisiert wurde und breite Anwendung findet, auch die L2/L3-Netzwerkelemente mit einer WebRTC- konformen QoS-Behandlung ausgerüstet werden sollen. Dieser Übergang (Migration) wird sich aber erwartungsgemäß über einen sehr langen Zeitraum hinweg erstrecken und nur sukzessive erfolgen. Die Einführung und Durchsetzung der klassischen QoS- Unterstützung war ebenfalls ein Prozess, der sich über viele Jahre hin erstreckt hat und flächendeckend noch längst nicht abgeschlossen ist.

Mit der Einführung von WebRTC (Real-Time Communication (RTC) über das Web) wird sich daher der dringende Bedarf ergeben, eine Übergangs-/Migrationslösung für die bestehende Netzinfrastruktur bereitzustellen.

Derzeit ist dieses Problem bei WebRTC nicht gelöst. Es gibt zwar Arbeiten zu SCTP (Stream Control Transmission Protocol), doch tragen diese Lösungen nicht im hier be- trachteten UDP/RTP-Umfeld.

Man kann WebRTC ohne Port-Multiplexing anwenden (wie z.B. bei SIP). Dadurch können jedoch die grundsätzlichen Multiplexing-Vorteile (s.o.) weder serverseitig (z.B. bei cloud- basierten Anordnungen), noch an den Netzübergängen (Firewall/NAT) genutzt werden.

Der vorliegenden Erfindung liegt die Aufgabe zugrunde, in einer RTC-Umgebung (derzeit insbesondere WebRTC-Umgebung) Mediendaten mit unterschiedlichen Medientypen effizient und auch über vorhandene dienstgütesensitive Netzwerke übertragen zu können. Diese Aufgabe wird mit einem computerimplementierten Verfahren gemäß Anspruch 1 sowie einer Telekommunikationsanordnung gemäß Anspruch 9 gelöst. Das erfindungsgemäße Verfahren kann mittels eines ebenfalls zur Erfindung gehörigen Computerprogramms bzw. Computerprogrammprodukts gemäß Anspruch 7 implementiert werden. Auch ein maschinenlesbarer Datenträger mit einem darauf gespeicherten Computerpro- grammprodukt gemäß Anspruch 7 ist Gegenstand der vorliegenden Erfindung.

Vorteilhafte Weiterbildungen der Erfindung sind Gegenstand der abhängigen Ansprüche.

Im Folgenden wird für die Beschreibung der Erfindung ohne Beschränkung der Allge- meinheit davon ausgegangen, dass die RTC-Clients als WebRTC-Clients ausgebildet sind. Es können aber auch modifizierte SIP-Clients sein. Erfindungsgemäß kann beim Übertragen von Mediendaten von einem (beispielsweise in einem Netzwerk befindlichen) ersten WebRTC-Client über ein das Real-Time-Protokoll (RTP) verwendendes, dienstgü- tesensitives Netzwerk zu einem (im gleichen oder in einem zweiten Netzwerk befindli- chen) zweiten WebRTC-Client in folgender Weise vorgegangen werden, wobei darauf hinzuweisen ist, dass die Dienstgüte auf unterschiedlichen Verkehrsklassen beruht und die Mediendaten (zumindest) einen ersten Medientyp mit einer ersten Verkehrsklasse und einen zweiten Typ mit einer zweiten Verkehrsklasse beinhalten: Mediendaten mit unterschiedlichen Medientypen einer hier beispielhaft angenommenen ersten Verkehrsklasse und zweiten Verkehrsklasse werden zunächst von dem ersten WebRTC-Client zu sogenannten "zweiten" Paketen gebündelt. Diese Bündelung ist auch als "Service-Multiplexen" bekannt. In anderen Worten können somit UDP/RTP-Pakete (UDP = User Datagram Protocol) mit Inhalten gemischter Serviceklassen (beispielsweise Voice bzw. Sprache einerseits und Video andererseits) in einem IP-Paket vorhanden sein. In jedem dieser zweiten Pakete wird dabei die Verkehrsklasse jedes Medientyps auf Schicht 4 und/oder auf Schicht 5 des RTP-Protokolls markiert. Dies ist eine sogenannte QoS-Markierung. Dadurch können die RTP-Audio- bzw. -Video-Paketinhalte eines einzigen UDP/RTP-

Paketes mit jeweils unterschiedlichen QoS-Werten markiert werden. Diese Pakete können dann in Richtung zum zweiten WebRTC-Client hin übertragen werden. Damit die Mediendaten aber über ein dienstgütesensitives erstes Netzwerk, welches die erfindungsgemäßen neuen Markierungen auf Schicht 4 und/oder Schicht 5 des RTP-Protokolls nicht be- rücksichtigt und auch nicht "versteht", übertragen werden können, müssen diese zweiten Pakete zuvor umgestaltet werden. Das heißt in anderen Worten, dass entweder vor dem Übergang von dem zweiten Netzwerk in das erste Netzwerk oder im Zuge dieses Übergangs die zweiten Pakete unter Verwendung der Markierungen in Schicht 4 und/oder in Schicht 5 des RTP-Protokolls zuerst entbündelt (Entbündelung = Demultiplexen) und neu zu sogenannten "ersten" Paketen gebündelt werden, von denen jedes nur eine einzige der Verkehrsklassen aufweist. Das heißt, dass erste Pakete gebildet werden, die beispielsweise (ggf. abwechselnd) entweder nur Sprachdaten oder nur Videodaten enthalten. Dieses Sortieren oder erneute Multiplexen bzw. Bündeln muss dabei schon erfolgt sein, bevor die ersten Pakete im ersten dienstgütesensitiven Netzwerk übertragen werden können. In anderen Worten bedeutet dies, dass dieser Vorgang noch nach ggf. einem zweiten, nicht dienstgütesensitiven Netzwerk sofort beim Eintritt in das erste Netzwerk oder ggf. in einem dritten dienstgütesensitiven Netzwerk in Senderichtung vor dessen erstem Router erfolgen muss. Anschließend können dann die ersten Pakete über das erste Netzwerk und ggf. weitere Transitnetzwerke zum zweiten WebRTC-Client (der sich beispielsweise in einem dritten Netzwerk befindet) übertragen werden.

Erfindungsgemäß ermöglicht es die Fähigkeit von Routern, die Markierungen in Schicht 4 und/oder Schicht 5 zu verstehen (beispielsweise durch (Deep) Packet Inspection), jedes empfangene UDP/RTP-Paket zu entbündeln, das heißt, mit den jeweiligen Sprachdaten, Videodaten, etc. aufzuteilen und den dafür vorgesehenen separaten Router- Warteschlangen (Queues) zuzuführen. Bevor der Router die Daten dann zum angestrebten Ziel weiterleitet, erfolgt ein erneutes Bündeln bzw. Multiplexen. Zusammenfassend ist zum erfindungsgemäßen Verfahren festzuhalten, dass durch ein WebRTC-Port-Multiplexen die bekannten Prinzipien von VolP/Video-over-IP und QoS beibehalten werden können (d. h. es gibt Router-Warteschlangen mit Behandlung der verschiedenen Dienste mit unterschiedlicher Priorität), selbst wenn vom RTC-Client in den gebündelten bzw. gemultiplexten lP/UDP-Paketen Nutzdaten unterschiedlicher Service- Arten (beispielsweise Voice, Video) enthalten sind. Hiermit wird vermieden, dass Sprach- Router-Warteschlangen beispielsweise mit Videodaten verstopft werden. Daher werden andere Sprachverbindungen in der Router-Warteschlange nicht mehr negativ beeinflusst.

Es ist zu betonen, dass das vorstehend beschriebene Verfahren prinzipiell z.B. unter IPv4, IPv6 (Internet Protocol version 4 bzw. Version 6) eingesetzt werden kann.

Eine Variante des vorstehend beschriebenen Verfahrens besteht darin, dass ein Router das Entbündeln übernimmt. Gemäß einer anderen Variante kann anstatt eines Routers ein dem Router vorgeschalteter Proxy die Aufgabe des Entbündelns übernehmen.

Eine weitere Variante des vorstehend beschriebenen Verfahrens besteht darin, dass das Entbündeln der zweiten Pakete und das Bündeln zu ersten Paketen in einer Netzüber- gangseinrichtung (Gateway) von einem nicht-dienstgütesensitiven Netzwerk zu einem dienstgütesensitiven Netzwerk vor oder hinter der Netzwerkgrenze ausgeführt werden kann.

Gemäß einer vorteilhaften Ausführungsform der Erfindung werden die L4/L5- Markierungen bei zweiten Paketen im IPv4-Format mittels einer standardkonformen, ge- nerischen Erweiterung des Kopfes des RTP-Protokollelements vorgenommen.

Gemäß einer vorteilhaften Weiterbildung der Erfindung werden die Markierungen bei IPv6 mittels Erweiterung des Kopfes der zweiten Pakete vorgenommen, wobei die Erweiterung insbesondere eine Liste der vorkommenden Markierungen umfasst. So bietet sich beispielsweise insbesondere für IPv6 die Definition eines eigenen IPv6-Extension-Headers an, der eine zusammenfassende Liste der QoS-Werte der beinhalteten RTP- Protokollelemente und deren Offset (Inhalt des IP-Paketes) enthält. Für Geräte, die mit den L4/L5-Markierungen arbeiten müssen, bringt das den dynamischen Vorteil, dass diese Werte nicht irgendwo im IP-Paket verstreut (als Bestandteil der darin enthaltenen RTP-Protokollelemente) gesucht werden müssen, sondern dass auf diese Werte in einem besonders dafür ausgezeichneten Teil auf IP-Ebene zugegriffen werden kann. Diese Variante bietet sich somit besonders für eine sehr effiziente und schnelle, beispielsweise auch in Hardware realisierte L4/L5-QoS-Behandlung an. Das Vorsehen eines derartigen Extension-Headers bietet überdies den Vorteil, dass es mithilfe eines ohnehin schon vorhandenen bzw. bekannten Verfahrens der Erweiterung des Kopfes eines Pakets ausge- führt werden kann.

Es kann vorteilhaft sein, Wenn Markierungen in den zweiten Paketen, die in Schicht 2 (Verbindungssicherungsschicht, z.B. Ethernet) und/oder in Schicht 3 (Vermittlungsschicht, IP-Header) vorhanden sind und sich auf die jeweilige Verkehrsklasse der in den RTP- Protokollelementen enthaltenen Medientypen beziehen, zu einem Hinweis auf vorhandenen Markierungen in Schicht 4 und/oder in Schicht 5 des RTP-Protokolls geändert werden. Auf dieser Basis können dann die gemultiplexten Mischpakete an einen Proxy gesendet werden, der die Aufteilung in Einzelverbindungen (beispielsweise Voice, Video) übernimmt. Der Proxy leitet dann die ersten Pakete an eine Peer-Entität in der Zieldomä- ne weiter (z. B. Proxy B). Dazwischenliegende Router sehen damit lediglich einzelne, normale Voice- oder Video-Pakete (oder homogene Flows) innerhalb der virtuellen Verbindungen, die entsprechend ihrer Verkehrsklasse (Voice, Video,...) behandelt bzw. weitergeleitet werden können. Gemäß einer weiteren vorteilhaften Ausführungsform des erfindungsgemäßen Verfahrens wird bei der Signalisierung ausgehandelt, ob ein Port-Multiplexen und/oder Service- Multiplexen ausgeführt wird. Grundsätzlich erzwingt nämlich z.B. das im Rahmen des WebRTC erweiterte SDP-Offer/Answer-Protokoll nicht das Verwenden von Port- Multiplexen und/oder Service-Multiplexen, was in anderen Worten bedeutet, dass das Port-Multiplexen und/oder Service-Multiplexen auch bei WebRTC optional ist. Eine alternative Lösung der Erfindung besteht somit darin, dass die beiden WebRTC-Endpunkte als Teil der Signalisierung aushandeln, ob ein Port-Multiplexen und/oder Service-Multiplexen ausgeführt werden soll oder nicht. Wenn beispielsweise in einem Netz bekannt ist, dass WebRTC und QoS für das Port-Multiplexen und/oder Service-Multiplexen nicht geeignet sind, kann durch eine solche Signalisierungsaushandlung das Port-Multiplexen unterdrückt werden.

Es kann weiterhin vorteilhaft sein, dass die zweiten Pakete, die erfindungsgemäß in Schicht 4 und/oder Schicht 5 markiert sind, mit einem DSCP-Wert (DSCP = Differentiated Services Codepoint) markiert werden, der dem "schlechtesten" Wert der enthaltenen

RTP-Protokollelemente entspricht. Im Beispiel von AudioA/ideo wäre dies einer von sogenannten Assured Forwarding (AFxx) Codepoints, damit diese Pakete keinesfalls in Kon- flikt mit reinen Sprachverbindungen geraten können, die standardmäßig dem sogenannten Expedited Forwarding (EF) DSCP-Codepoint zugeordnet sind. Damit können derartige IP-Pakete auch in Netzen mit klassischer QoS-Behandlung mit zumindest minimalen QoS-Eigenschaften transportiert werden, aber trotzdem zumindest nicht die sehr kriti- sehen Sprachverbindungen negativ beeinflussen.

Auch ein das erfindungsgemäße, vorstehend beschriebene Verfahren implementierende Computerprogramm bzw. das Computerprogrammprodukt ist als zur vorliegenden Erfindung gehörig anzusehen, ebenso wie ein maschinenlesbarer Datenträger, auf dem ein derartiges Computerprogramm gespeichert ist.

Die der vorliegenden Erfindung zugrunde liegende Aufgabe wird auch gelöst mit einer Telekommunikationsanordnung gemäß Anspruch 9, die einen (beispielsweise in einem zweiten nicht-dienstgütesensitiven Netzwerk befindlichen) ersten WebRTC-Client, einen zweiten WebRTC-Client (z.B. in einem dritten dienstgütesensitiven Netzwerk) und ein (ggf. mit dem zweiten und dritten Netzwerk verbundenes) dienstgütesensitives erstes Netzwerk (und evtl. weitere Transitnetzwerke) enthält, welches das Real-Time-Protokoll verwendet. In einer einfachen Anordnung können sich beide WebRTC-Clients auch innerhalb eines, zumindest in Teilen dienstgütesensitiven, Netzwerk befinden. Erfindungsge- mäß ist eine Markierungseinheit vorgesehen, welche das Verfahren gemäß einem der vorgenannten Ansprüche 1 bis 7 ausführt. Diese Markierungseinheit kann beispielsweise einen Prozessor umfassen, auf dem das o.g. Verfahren ablaufen kann, oder sie kann auch in Hardware gegossen sein. Mit Vorteil ist die Markierungseinheit einer Netzübergangseinrichtung, mit der ein Übergang vom zweiten Netzwerk zum ersten Netzwerk ermöglicht wird, einem Proxy oder aber einem Router/L3-Switch zugeordnet bzw. in einem derartigen Gerät integriert.

Da das erfindungsgemäße Verfahren und die erfindungsgemäße Telekommunikationsan- Ordnung in engem Zusammenhang zueinander stehen, gelten die in Verbindung mit dem Verfahren beschriebenen Merkmale und Vorteile in analoger Weise auch bei der Telekommunikationsanordnung und umgekehrt, auch wenn dies nicht ausdrücklich angegeben ist. Weitere Vorteile, Merkmale und Besonderheiten der vorliegenden Erfindung ergeben sich aus der nachfolgenden Beschreibung vorteilhafter Ausführungsformen unter Bezugnahme auf die Zeichnung. Es zeigen: Fig. 1 schematisch eine erfindungsgemäße Telekommunikationsanordnung gemäß der vorliegenden Erfindung, die zum Ausführen des erfindungsgemäßen Verfahrens geeignet ist und anhand der das erfindungsgemäße Verfahren nachstehend beschrieben werden soll; und

Fig. 2 die Struktur eines MAC-Frames mit IP- und UDP-Paketen sowie den RTP- Protokollelementen. Fig. 2 zeigt einen MAC-Frame 50 (z. B. Ethernet) mit darin eingebettetem IP-Paket 51 und UDP-Paket 52. Der MAC-Frame 50 enthält in seinem MAC-Header die L2-QoS- Markierung. Das IP-Paket 51 enthält in seinem IP-Header die L3-QoS-Markierung. Die UDP-Nutzdaten 53 enthalten mittels Service-Multiplexing die RTP-Protokollelemente 54 und 55 (wie beispielhaft an den Services "Video" 54 und "Audio" 55 dargestellt). Der Hea- der jedes der RTP-Protokollelemente trägt erfindungsgemäß die L4/L5-QoS-Markierung, wie später ausführlich erläutert wird.

Fig. 1 zeigt schematisch eine erfindungsgemäße Telekommunikationsanordnung gemäß der vorliegenden Erfindung, die zum Ausführen des erfindungsgemäßen Verfahrens ge- eignet ist und anhand der das erfindungsgemäße Verfahren nachstehend beschrieben werden soll.

Die erfindungsgemäße, schematisch dargestellte Telekommunikationsanordnung 0 um- fasst - verallgemeinert, jedoch nicht beschränkend -drei Netzwerke. In einem ersten Netzwerk N1 sind hier als Beispiel ein WebRTC-Server 25 und zwei Router 23 dargestellt, die über dienstgütesensitive (auf unterschiedlichen Verkehrsklassen beruhende) Verbindungen untereinander in Kontakt stehen. Somit ist das gesamte Netzwerk N1 ein dienst- gütesensitives Netzwerk. Außerdem ist ein Netzwerk N2 vorgesehen, bei dem ein Access-Router 32, ein "normaler" Router 33, ein Switch 34, ein WebRTC-Server 35, ein Notebook, auf dem ein WebRTC-Browser 36 läuft, und ein Notepad, auf dem ein

WebRTC-Browser 30 läuft, vorgesehen sind. Der WebRTC-Browser 30 soll hier als Beispiel für einen WebRTC-Client dienen, der Mediendaten mit unterschiedlichen Verkehrsklassen QoS1 und QoS2 verschicken möchte. Der WebRTC-Client 30 ist über WLAN mit dem Router 33 verbunden, der wiederum mit dem Access-Router 32 verbunden ist. Alle diese Verbindungen sollen in beispielhafter Weise nicht dienstgütesensitiv sein. Dem Access-Router 32 ist eine Markierungseinheit QMP zugeordnet, deren Funktion später beschrieben wird. Die erfindungsgemäße Telekommunikationsanordnung 10 umfasst außerdem in diesem Beispiel ein drittes Netzwerk N3, das umfasst: einen Access-Router 42 (der als Netzübergangseinrichtung dient), einen Router 43, einen Switch 44, einen WebRTC-Server 45, ein Notebook, auf dem ein WebRTC-Browser 46 läuft, und ein Notepad, auf dem ein

WebRTC-Browser 40 läuft. Der WebRTC-Browser 40 soll hier als Beispiel für einen zweiten WebRTC-Client dienen. Anders als beim Netzwerk N2 ist im Netzwerk N3 eine Markierungseinheit QMP dem Router 43 zugeordnet. Während die Verbindungen zwischen dem Router 43 und dem Access-Router 42 sowie zum WebRTC-Server 45 "klassische" dienstgütersensitive Verbindungen sind, sind die übrigen Verbindungen solche mit Port- /Service-Multiplexing (wie die Verbindungen im Netzwerk N2).

Es soll nun angenommen werden, dass der erste WebRTC-Client 30 Sprachdaten mit einem QoS-Wert QoS1 sowie Videodaten mit einem QoS-Wert QoS2 an den zweiten WebRTC-Client 40 übermitteln will und hierfür die Dienste des dienstgütesensitiven Netzwerks N1 in Anspruch nehmen möchte. Hierzu packt der erste WebRTC-Client 30 die unterschiedlichen Daten je nach Anfall in mehrere zweite Pakete P2, was auch als Bündeln oder Multiplexen bezeichnet werden kann. Für jede verwendete Verkehrsklasse (wobei auch mehr als die zwei vorgenannten Verkehrsklassen vorhanden sein können) setzt der erste WebRTC-Client 30 eine entsprechende Markierung in Schicht 4 und/oder in Schicht 5 des Real-Time-Protokolls. Diese Pakete P2 werden an den Router 33 übermittelt und von diesem an den Access-Router 32 weitergeleitet. Dem Access-Router 32, von dem angenommen werden kann, dass er die Hinweise im Paketkopf und/oder die Markierungen in der Erweiterung eines IPv6-Paket.es oder die Erweiterungen der

Schicht4/Schicht5-Markierungen innerhalb der Köpfe der RTP-Protokollelemente interpretieren kann, ist eine Markierungseinheit QMP zugeordnet, welche die gemischten Datenpakete P2 entbündelt bzw. demultiplext und neue erste Pakete P1 bildet, die "sortenrein" sind, also nur RTP-Protokollelemente einer einzigen QoS-Verkehrsklasse aufweisen. Derartige erste Pakete P1 können dann vom Netzwerk N1 , sobald sie vom Access-Router 32 an dieses übergeben und beispielsweise an die Router 23 weitergeleitet worden sind, übertragen werden. An den jeweiligen Verbindungen zwischen einzelnen Geräten ist angegeben, welche Art von Paketen - Pakete P1 oder Pakete P2 - transportiert werden. Die Pakete P1 werden dann an den Access-Router 42 im Netzwerk N3 übermittelt, und vom Access-Router 42 an den Router 43. Dem Router 43 ist ebenfalls eine Markierungs- einheit QMP zugeordnet, die die Datenpakete P1 entbündelt und die ursprünglich vorhandenen Datenpakete 2 wieder rekonstruiert, indem sie das Eintreffen einer bestimmten Anzahl an Paketen P1 abwartet und aus diesen die entsprechenden Mediendaten mit unterschiedlichen Medientypen wieder zu einem neuen zweiten Datenpaket P2 kombiniert bzw. bündelt. Diese neuen Datenpakete P2 werden dann an den zweiten WebRTC-Client 40 übertragen. In dem erfindungsgemäß ausgebildeten Zielrouter 43 erwartet dieser somit die sortierten UDP/IP-Pakete P1 entsprechend einem vordefinierten gleitenden Fenster entsprechend einem IP-Paketzähler, da es durch die im Netzwerk N1 für den Transit der Pakete P1 unterschiedlich angewendeten PHBs durchaus zu Paketüberholungen gekommen sein kann. Innerhalb der Fenster empfangene UDP/IP-Pakete werden entsprechend dem RTP- Segmentzähler wie ursprünglich empfangen rekonstruiert, und der standardisierte oder im Netzwerk N3 gültige DSCP-Codepoint für Dienste-gebündelte RTP/UDP/IP-Pakete wird besetzt, bevor diese zum WebRTC-Client 40 weitergeleitet werden.

In einem heute aktuellen bzw. bekannten dienstgütesensitiven Netzwerk müssen die erfindungsgemäßen Schritte vor dem Routing im Netz erfolgen: Typischerweise geschieht dies in Verbindung mit einem Router, der den Distribution Layer eines Gesamtnetzes verbindet. Ist dagegen nur das Netzwerk N1 dienstgütesensitiv, würde dies in Verbindung mit einem entsprechenden Access-Router erfolgen. Dabei kann die erfindungsgemäße Funktionalität der Markierung in den Schichten 4 und/oder 5 an einer der beiden Seiten des Netzwerkübergangs erbracht werden.

RTP-Protokollelemente gemäß RFC3550 erlauben die Verwendung einer RTP-Header Extension. Das Vorhandensein wird im RTP-Header angezeigt. Die RTP-Header Extension beinhaltet eine Profilkennzeichnung, die erfindungsgemäß festgelegt werden muss. Die Längenangabe sollte mit mindestens eins das Vorhandensein eines DSCP-Code- points (8 Bits) des jeweiligen Mediatyps und optional eines kombinierten IP-Paket-/RTP- Protokollelementzählers im folgenden 32-Bit-Wort anzeigen. In den verbleibenden 24 Bit können die IP-Paketzähler und RTP-Protokollelementzähler (mit Überlauf) codiert werden, die eine optionale Wiederherstellung der ursprünglichen zweiten Pakete vor der Lieferung an den zweiten WebRTC-Client ermöglichen. Eine erfindungsgemäße Markierungseinheit (die beispielsweise einem Router oder Proxy zugeordnet ist), die das Ursprungs- Distributionsnetzsegment terminiert und einen RTP/UDP/IP-Datenfluss mit Service- Multiplexing identifiziert hat, segmentiert nun die einzelnen RTP-Segmente, zählt und überschreibt die laufende IP-Paketnummer und die Position des RTP-Protokollelementes innerhalb des UPD/IP-Paketes in der RTP-Header Extension. Vorteilhaft sammelt der Router die RTP-Protokollelemente mit gleichem DSCP-Codepoint in ein rekombiniertes RTP/UDP/IP-Paket auf und überschreibt den DSCP-Codepoint des UDP/IP-Headers entsprechend der RTP Header-Extension, bevor das Paket weitergeleitet wird.

Bei der vorstehenden Beschreibung einer beispielhaften Ausführungsform der Erfindung wurde davon ausgegangen, dass nur ein dienstgütesensitives Netzwerk N1 zur Verfügung steht, um die Mediendaten vom ersten WebRTC-Client (eines nicht-dienstgütesensitiven Netzwerkes N2) zum zweiten WebRTC-Client (eines dienstgütesensitiven Netzwerkes N3) zu übermitteln. Dies entspricht einer für die Beschreibung gewählten, schematischen Netzkonfiguration. Auch das Netz N3 in der in Fig. 1 gezeigten Konfiguration ist für die Ausführung des erfindungsgemäßen Verfahrens geeignet.

Es ist festzuhalten, dass die unter Bezug auf die dargestellten Ausführungsformen beschriebenen Merkmale der Erfindung, wie beispielsweise die Art und Ausgestaltung der einzelnen Geräte bzw. Einrichtungen sowie der einzelnen Verfahrensschritte und deren Reihenfolge, auch bei anderen Ausführungsformen vorhanden sein können, außer wenn es anders angegeben ist oder sich aus technischen Gründen von selbst verbietet.

Bezugszeichenliste

10 = Telekommunikationsanordnung

23 = Router

25 = WebRTC-Server

30 = erster WebRTC-Client

32 = Access-Router/Netzübergangseinrichtung

33 = Router

34 = Switch

35 = WebRTC-Server

36 = WebRTC-Browser

40 = zweiter WebRTC-Client

42 = Access-Router/Netzübergangseinrichtung

43 = Router

44 = Switch

45 = WebRTC-Server

46 = WebRTC-Browser

50 = MAC-Frame

51 = IP-Paket

52 = UDP-Paket

53 = Nutzdaten

54 = Videodaten

55 = Audiodaten

90 = Datenträger

92 = Compterprogrammprodukt

N1 = dienstgütesensitives Netzwerk für Übertragung

N2 = zweites Netzwerk

N3 = drittes Netzwerk

QMP = Markierungseinheit

QoS = Verkehrsklasse (Quality of Service)