-
ALLGEMEINER STAND DER TECHNIK
-
Gebiet der Offenbarung
-
Die Technologie der Offenbarung betrifft allgemein interaktive Web-Real-Time-Communications(WebRTC)-Sitzungen.
-
Technischer Hintergrund
-
Web Real-Time Communications (WebRTC) verkörpert eine laufende Bemühung um die Entwicklung von Industriestandards zum Integrieren von Echtzeitkommunikationsfunktionalität in Webclients, etwa Webbrowsern, um direkte Interaktion mit anderen Webclients zu ermöglichen. Diese Echtzeitkommunikationsfunktionalität ist für Webentwickler über Standardauszeichnungs-Tags zugänglich, etwa diejenigen, die durch Version 5 der Hypertext Markup Language (HTML5) bereitgestellt werden, und über clientseitige Skript-Anwendungsprogrammierschnittstellen (APIs) wie JavaScript-APIs. Weitere Informationen zu WebRTC finden sich in „WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web" von Alan B. Johnston und Daniel C. Burnett (2012 Digital Codex LLC), das durch Bezugnahme in seinem vollen Umfang hierin aufgenommen wird.
-
WebRTC stellt integrierte Fähigkeiten zum Herstellen von Echtzeitvideo-, -audio- und/oder -datenströmen sowohl bei interaktiven Punkt-zu-Punkt-Sitzungen als auch bei interaktiven Mehr-Teilnehmer-Sitzungen bereit. Die WebRTC-Standards werden derzeit vom World Wide Web Consortium (W3C) und von der Internet Engineering Task Force (IETF) gemeinsam entwickelt. Informationen zum derzeitigen Stand der WebRTC-Standards finden sich z. B. unter http://www.w3c.org und http://www.ietf.org.
-
Bestehende Protokolle zum Bereitstellen interaktiver Flüsse wie das Session Initiation Protocol (SIP), H.323 und Jingle sind aufgrund von neuen Funktionen und Medienerweiterungen, die von WebRTC bereitgestellt werden, nicht mit WebRTC kompatibel. Folglich wurde ein Nachrüsten von Gateway-Anwendungen, die diese bestehenden Protokolle verwenden, um WebRTC-Fähigkeiten hinzuzufügen, nicht unerhebliche Entwicklungsbemühungenerfordern. Ferner können die variierenden Stufen des WebRTC-Supports, die derzeit von unterschiedlichen WebRTC-Clients bereitgestellt werden, weitere Kompatibilitäts- und Supportprobleme für Gateway-Anwendungen mit sich bringen.
-
KURZE DARSTELLUNG DER DETAILLIERTEN BESCHREIBUNG
-
In der detaillierten Beschreibung offenbarte Ausführungsformel stellen virtuelle Web-Real-Time-Communications(WebRTC)-Gateways bereit. Verwandte Verfahren, Systeme und computerlesbare Medien werden ebenfalls offenbart. In einigen Ausführungsformen instanziiert ein Server für interaktive Flüsse, durch den ein WebRTC-Client und ein Nicht-WebRTC-Client eine interaktive Sitzung herzustellen versuchen, einen virtuellen WebRTC-Agenten und einen virtuellen Nicht-WebRTC-Agenten. Der Server für interaktive Flüsse kann bewirken, dass der WebRTC-Client einen interaktiven WebRTC-Fluss zum virtuellen WebRTC-Agenten herstellt, und kann bewirken, dass der Nicht-WebRTC-Client einen interaktiven Nicht-WebRTC-Fluss zum virtuellen Nicht-WebRTC-Agenten herstellt. Der Server für interaktive Flüsse kann den virtuellen WebRTC-Agenten und den virtuellen Nicht-WebRTC-Agenten dann aufeinanderfolgend („Back-to-Back”) verbinden, indem er Ausgaben aus virtuellen WebRTC-Agenten als Eingaben in den virtuellen Nicht-WebRTC-Agenten und umgekehrt leitet. Auf diese Weise kann der Server für interaktive Flüsse ein virtuelles WebRTC-Gateway zwischen dem WebRTC-Client und dem Nicht-WebRTC-Client bereitstellen, während er auch zusätzliche Medienverarbeitungs- und -behandlungsfunktionalität bereitstellt. Als nicht einschränkende Beispiele beinhaltet die Medienverarbeitungs- und -behandlungsfunktionalität möglicherweise Aufzeichnen und/oder Überwachen der interaktiven WebRTC- und/oder Nicht-WebRTC-Flüsse und/oder Extrahieren von Inhalt aus oder Einfügen von Inhalt in die interaktiven WebRTC- und/oder Nicht-WebRTC-Flüsse.
-
In diesem Zusammenhang ist in einer Ausführungsform ein Verfahren zum Bereitstellen eines virtuellen WebRTC-Gateways bereitgestellt. Das Verfahren umfasst Instanziieren eines virtuellen WebRTC-Agenten, der einem WebRTC-Client entspricht, durch ein virtuelles WebRTC-Gateway, das auf einer Computereinrichtung ausgeführt wird. Das Verfahren umfasst weiter Instanziieren eines virtuellen Nicht-WebRTC-Agenten, der einem Nicht-WebRTC-Client entspricht. Das Verfahren umfasst auch Herstellen eines interaktiven WebRTC-Flusses zwischen dem virtuellen WebRTC-Agenten und dem WebRTC-Client. Das Verfahren umfasst zusätzlich Herstellen eines interaktiven Nicht-WebRTC-Flusses zwischen dem virtuellen Nicht-WebRTC-Agenten und dem Nicht-WebRTC-Client. Das Verfahren umfasst weiter Leiten eines Inhalts des interaktiven WebRTC-Flusses an den interaktiven Nicht-WebRTC-Fluss und eines Inhalts des interaktiven Nicht-WebRTC-Flusses an den interaktiven WebRTC-Fluss über den virtuellen WebRTC-Agenten und den virtuellen Nicht-WebRTC-Agenten.
-
In einer anderen Ausführungsform ist ein System zum Bereitstellen eines virtuellen WebRTC-Gateways bereitgestellt. Das System umfasst mindestens eine Kommunikationsschnittstelle und einen Server für interaktive Flüsse, der mit der mindestens einen Kommunikationsschnittstelle assoziiert ist. Der Server für interaktive Flüsse umfasst ein virtuelles WebRTC-Gateway, das konfiguriert ist, um einen virtuellen WebRTC-Agenten, der einem WebRTC-Client entspricht, zu instanziieren und einen virtuellen Nicht-WebRTC-Agenten, der einem Nicht-WebRTC-Client entspricht, zu instanziieren. Das virtuelle WebRTC-Gateway ist weiter konfiguriert, um einen interaktiven WebRTC-Fluss zwischen dem virtuellen WebRTC-Agenten und dem WebRTC-Client herzustellen. Das virtuelle WebRTC-Gateway ist auch konfiguriert, um einen interaktiven Nicht-WebRTC-Fluss zwischen dem virtuellen Nicht-WebRTC-Agenten und dem Nicht-WebRTC-Client herzustellen. Das virtuelle WebRTC-Gateway ist zusätzlich konfiguriert, um einen Inhalt des interaktiven WebRTC-Flusses an den interaktiven Nicht-WebRTC-Fluss und einen Inhalt des interaktiven Nicht-WebRTC-Flusses an den interaktiven WebRTC-Fluss über den virtuellen WebRTC-Agenten und den virtuellen Nicht-WebRTC-Agenten zu leiten.
-
In einer anderen Ausführungsform ist ein nicht transientes computerlesbares Medium bereitgestellt. Auf dem nicht transienten computerlesbaren Medium sind computerausführbare Befehle abgelegt, um zu bewirken, dass ein Prozessor ein Verfahren implementiert, das Instanziieren eines virtuellen WebRTC-Agenten, der einem WebRTC-Client entspricht, umfasst. Das durch die computerausführbaren Befehle implementierte Verfahren umfasst weiter Instanziieren eines virtuellen Nicht-WebRTC-Agenten, der einem Nicht-WebRTC-Client entspricht. Das durch die computerausführbaren Befehle implementierte Verfahren umfasst auch Herstellen eines interaktiven WebRTC-Flusses zwischen dem virtuellen WebRTC-Agenten und dem WebRTC-Client. Das durch die computerausführbaren Befehle implementierte Verfahren umfasst zusätzlich Herstellen eines interaktiven Nicht-WebRTC-Flusses zwischen dem virtuellen Nicht-WebRTC-Agenten und dem Nicht-WebRTC-Client. Das durch die computerausführbaren Befehle implementierte Verfahren umfasst weiter Leiten eines Inhalts des interaktiven WebRTC-Flusses an den interaktiven Nicht-WebRTC-Fluss und eines Inhalts des interaktiven Nicht-WebRTC-Flusses an den interaktiven WebRTC-Fluss über den virtuellen WebRTC-Agenten und den virtuellen Nicht-WebRTC-Agenten.
-
KURZE BESCHREIBUNG DER FIGUREN
-
Die beiliegenden Zeichnungsfiguren, die in diese Patentschrift aufgenommen sind und einen Bestandteil von ihr bilden, veranschaulichen diverse Ausgestaltungen der Offenbarung und dienen zusammen mit der Beschreibung dazu, die Prinzipien der Offenbarung zu erläutern.
-
1 ist ein Begriffsschema, das eine interaktive Sitzung zwischen einem Web-Real-Time-Communications(WebRTC)-Client und einem Nicht-WebRTC-Client über einen Server für interaktive Flüsse, der ein virtuelles WebRTC-Gateway beinhaltet, veranschaulicht;
-
2 ist ein Flussdiagramm, das beispielhafte Abläufe des virtuellen WebRTC-Gateways von 1 zum Ermöglichen von Interoperabilität zwischen einem WebRTC-Client und einem Nicht-WebRTC-Client veranschaulicht;
-
3 ist ein Schema, das beispielhafte Kommunikationsflüsse für eine ausgehende Interaktionsanforderung von einem WebRTC-Client an einen Nicht-WebRTC-Client innerhalb eines beispielhaften Systems, welches das virtuelle WebRTC-Gateway von 1 beinhaltet, veranschaulicht;
-
4 ist ein Schema, das beispielhafte Kommunikationsflüsse für eine eingehende Interaktionsanforderung von einem Nicht-WebRTC-Client all einen WebRTC-Client innerhalb eines beispielhaften Systems, welches das virtuelle WebRTC-Gateway von 1 beinhaltet, veranschaulicht;
-
die 5A und 5B sind Flussdiagramme, die detailliertere beispielhafte Abläufe zum Bereitstellen eines virtuellen WebRTC-Gateways, das ausgehende und/oder eingehende Interaktionsanforderungen von einem WebRTC-Client an einen Nicht-WebRTC-Client ermöglicht, und zusätzliche Medienverarbeitungs- und -behandlungsfunktionalität veranschaulichen; und
-
6 ist ein Blockschema eines beispielhaften prozessorbasierten Systems, welches das virtuelle WebRTC-Gateway von 1 beinhalten kann.
-
DETAILLIERTE BESCHREIBUNG
-
Nunmehr werden mit Bezug auf die Zeichnungsfiguren diverse beispielhafte Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Wort „beispielhaft” wird hierin in der Bedeutung „als ein Beispiel, ein Beispielsfall oder zur Veranschaulichung dienend” genutzt. Jede hierin als „beispielhaft” beschriebene Ausführungsform ist nicht zwangsläufig als gegenüber anderen Ausführungsformen bevorzugt oder vorteilhaft auszulegen.
-
In der detaillierten Beschreibung offenbarte Ausführungsformen stellen virtuelle Web-Real-Time-Communications(WebRTC)-Gateways bereit. Verwandte Verfahren, Systeme und computerlesbare Medien werden ebenfalls offenbart. In einigen Ausführungsformen instanziiert ein Server für interaktive Flüsse, durch den ein WebRTC-Client und ein Nicht-WebRTC-Client eine interaktive Sitzung herzustellen versuchen, einen virtuellen WebRTC-Agenten und einen virtuellen Nicht-WebRTC-Agenten. Der Server für interaktive Flüsse kann bewirken, dass der WebRTC-Client einen interaktiven WebRTC-Fluss zum virtuellen WebRTC-Agenten herstellt, und kann bewirken, dass der Nicht-WebRTC-Client einen interaktiven Nicht-WebRTC-Fluss zum virtuellen Nicht-WebRTC-Agenten herstellt. Der Server für interaktive Flüsse kann den virtuellen WebRTC-Agenten und den virtuellen Nicht-WebRTC-Agenten dann aufeinanderfolgend („Back-to-Back”) verbinden, indem er Ausgaben aus dem virtuellen WebRTC-Agenten als Eingaben in den virtuellen Nicht-WebRTC-Agenten und umgekehrt leitet. Auf diese Weise kann der Server für interaktive Flüsse ein virtuelles WebRTC-Gateway zwischen dem WebRTC-Client und dem Nicht-WebRTC-Client bereitstellen, während er auch zusätzliche Medienverarbeitungs- und -behandlungsfunktionalität bereitstellt. Als nicht einschränkende Beispiele beinhaltet die Medienverarbeitungs- und -behandlungsfunktionalität möglicherweise Aufzeichnen und/oder Überwachen der interaktiven WebRTC- und/oder Nicht-WebRTC-Flüsse und/oder Extrahieren von Inhalt aus oder Einfügen von Inhalt in die interaktiven WebRTC- und/oder Nicht-WebRTC-Flüsse.
-
In diesem Zusammenhang ist in einer Ausführungsform ein Verfahren zum Bereitstellen eines virtuellen WebRTC-Gateways bereitgestellt. Das Verfahren umfasst Instanziieren eines virtuellen WebRTC-Agenten, der einem WebRTC-Client entspricht, durch ein virtuelles WebRTC-Gateway, das auf einer Computereinrichtung ausgeführt wird. Das Verfahren umfasst weiter Instanziieren eines virtuellen Nicht-WebRTC-Agenten, der einem Nicht-WebRTC-Client entspricht. Das Verfahren umfasst auch Herstellen eines interaktiven WebRTC-Flusses zwischen dem virtuellen WebRTC-Agenten und dem WebRTC-Client. Das Verfahren umfasst zusätzlich Herstellen eines interaktiven Nicht-WebRTC-Flusses zwischen dem virtuellen Nicht-WebRTC-Agenten und dem Nicht-WebRTC-Client. Das Verfahren umfasst weiter Leiten eines Inhalts des interaktiven WebRTC-Flusses an den interaktiven Nicht-WebRTC-Fluss und eines Inhalts des interaktiven Nicht-WebRTC-Flusses an den interaktiven WebRTC-Fluss über den virtuellen WebRTC-Agenten und den virtuellen Nicht-WebRTC-Agenten.
-
1 veranschaulicht ein beispielhaftes interaktives Kommunikationssystem 10, das virtuelle WebRTC-Gateways, wie hierin offenbart, bereitstellt. Insbesondere stellt das beispielhafte interaktive Kommunikationssystem 10 einen Server für interaktive Flüsse, 12, bereit, der auf einer Computereinrichtung 14 ausgeführt wird und der ein virtuelles WebRTC-Gateway 16 beinhaltet. Das virtuelle WebRTC-Gateway 16 behandelt die Instanziierung virtueller WebRTC-Agenten und virtueller Nicht-WebRTC-Agenten und koordiniert die Herstellung und die Leitung von Inhalt von interaktiven Flüssen, um Interoperabilität zwischen einem WebRTC-Endpunkt und einen Nicht-WebRTC-Endpunkt bereitzustellen. Wie hierin genutzt, bezieht sich ein „virtueller WebRTC-Agent” auf eine Instanz eines WebRTC-fähigen Browsers oder einer anderen WebRTC-fähigen Clientanwendung, die gesteuert vom virtuellen WebRTC-Gateway 16 auf der Computereinrichtung 14 ausgeführt wird. Ein „virtueller Nicht-WebRTC-Agent” bezieht sich auf eine Instanz einer Clientanwendung, die gesteuert vom virtuellen WebRTC-Gateway 16 auf der Computereinrichtung 14 ausgeführt wird und die Echtzeitkommunikationsfähigkeiten gemäß einem anderen Protokoll als WebRTC bereitstellt. Als nicht einschränkende Beispiele beinhalten solche Nicht-WebRTC-Protokolle möglicherweise das Session Initiation Protocol (SIP), H.323, Jingle oder andere Protokolle, die sitzungszentrierte interaktive Flüsse bereitstellen. Ein „interaktiver WebRTC-Fluss”, wie hierin offenbart, bezieht sich auf einen interaktiven Medienfluss und/oder einen interaktiven Datenfluss, der/die zwischen oder unter zwei oder mehr Endpunkten gemäß WebRTC läuft/laufen, während ein „interaktiver Nicht-WebRTC-Fluss” sich auf einen interaktiven Medienfluss und/oder einen interaktiven Datenfluss gemäß einem anderen Protokoll als WebRTC bezieht. Als nicht einschränkende Beispiele umfasst ein interaktiver Medienfluss, der einen interaktiven WebRTC- oder Nicht-WebRTC-Fluss bildet, möglicherweise einen Echtzeitaudiostream und/oder einen Echtzeitvideostream oder andere Echtzeitmedien- oder -datenstreams. Daten und/oder Medien, die einen interaktiven Fluss umfassen, können hierin gemeinsam als „Inhalt” bezeichnet werden.
-
Zu Zwecken der Veranschaulichung ist ein interaktiver WebRTC-Fluss 18 in 1 als zwischen der Computereinrichtung 14 und einer Computereinrichtung 20 laufend gezeigt, und ein interaktiver Nicht-WebRTC-Fluss 22 ist als zwischen der Computereinrichtung 14 und einer Computereinrichtung 24 laufend gezeigt. Es versteht sich, dass die Computereinrichtungen 14, 20 und 24 sich alle innerhalb desselben öffentlichen oder privaten Netzes befinden können oder sich innerhalb separater, kommunikativ gekoppelter öffentlicher oder privater Netze befinden können. Einige Ausführungsformen des interaktiven Kommunikationssystems 10 von 1 können vorsehen, dass jede der Computereinrichtungen 14, 20 und 24 eine beliebige Computereinrichtung mit Netzkommunikationsfähigkeiten sein kann, etwa ein Smartphone, ein Tabletcomputer, eine dedizierte Web-Appliance, ein Medienserver, ein Desktop- oder ein Server-Computer oder eine speziell angefertigte Kommunikationseinrichtung, wobei es sich um nicht einschränkende Beispiele handelt. Die Computereinrichtungen 14, 20 und 24 beinhalten Kommunikationsschnittstellen 26, 28 bzw. 30 zum Verbinden der Computereinrichtungen 14, 20 und 24 mit einem oder mehreren öffentlichen und/oder privaten Netzen. In einigen Ausführungsformen können die Elemente der Computereinrichtungen 14, 20 und 24 über mehr als eine Computereinrichtung 14, 20, 24 verteilt sein.
-
Die Computereinrichtung 20 von 1 beinhaltet einen WebRTC-Client 32. Der WebRTC-Client 32 ist möglicherweise eine WebRTC-fähige Webbrowseranwendung, eine dedizierte Kommunikationsanwendung, eine mobile Anwendung oder eine schnittstellenlose Anwendung wie eine Daemon- oder Dienstanwendung, wobei es sich um nicht einschränkende Beispiele handelt. Der WebRTC-Client 32 implementiert die Protokolle, die Codecs und die Anwendungsprogrammierschnittstellen (APIs), die zum Bereitstellen des interaktiven WebRTC-Flusses 18 zwischen der Computereinrichtung 20 und der Computereinrichtung 14 nötig sind. Die Computereinrichtung 24 von 1 beinhaltet einen Nicht-WebRTC-Client 34, der Echtzeitkommunikationsfähigkeiten basierend auf einem anderen Protokoll als WebRTC bereitstellt. Der Nicht-WebRTC-Client 34 ist möglicherweise eine Webbrowseranwendung, eine dedizierte Kommunikationsanwendung, eine mobile Anwendung oder eine schnittstellenlose Anwendung wie eine Daemon- oder Dienstanwendung, wobei es sich um nicht einschränkende Beispiele handelt. Als nicht einschränkendes Beispiel ist der Nicht-WebRTC-Client 34 möglicherweise ein SIP-Benutzeragent-Client, der einen SIP-Signalisierungsstapel und einen mit einem SIP-Netz oder -Dienst kompatiblen Real-Time-Transport-Protocol(RTP)-Medienstapel bereitstellt. In einigen Ausführungsformen können nicht einschränkende Beispiele für andere Nicht-WebRTC-Clients 34 eine H.323-Clientanwendung oder eine Jingle-Clientanwendung sein. Der Nicht-WebRTC-Client 34 implementiert die Protokolle, die Codecs und die APIs, die zum Bereitstellen des interaktiven Nicht-WebRTC-Flusses 22 zwischen der Computereinrichtung 24 und der Computereinrichtung 14 nötig sind.
-
Wie in 1 ersichtlich, ist die Computereinrichtung 20 kommunikativ an eine Audioeingabeeinrichtung 36 (z. B. ein Mikrofon) zum Empfangen von Audioeingaben und an eine Audioausgabeeinrichtung 38 (zum Beispiel Lautsprecher oder Kopfhörer) zum Generieren von Audioausgaben gekoppelt. Die Computereinrichtung 20 ist weiter kommunikativ an eine Videoeingabeeinrichtung 40 (etwa eine Kamera, eine Webcam oder eine andere Videoquelle) zum Empfangen von Videoeingaben und eine Videoausgabeeinrichtung 42 (z. B. eine Anzeige) zum Anzeigen von Videoausgaben gekoppelt. Desgleichen ist die Computereinrichtung 24 kommunikativ an eine Audioeingabeeinrichtung 44, eine Audioausgabeeinrichtung 46, eine Videoeingabeeinrichtung 48 und eine Videoausgabeeinrichtung 50 gekoppelt. Die Audioeingabeeinrichtungen 36 und 44, die Audioausgabeeinrichtungen 38 und 46, die Videoeingabeeinrichtungen 40 und 48 und/oder die Videoausgabeeinrichtungen 42 und 50 können in die jeweiligen Computereinrichtungen 20 und 24 integriert sein, und/oder sie können Peripheriegeräte und/oder virtuelle Einrichtungen sein, die kommunikativ an die jeweiligen Computereinrichtungen 20 und 24 gekoppelt sind. In einigen Ausführungsformen können die Computereinrichtungen 20 und/oder 24 kommunikativ an mehr oder weniger Einrichtungen gekoppelt sein als in 1 veranschaulicht.
-
Da WebRTC- und Nicht-WebRTC-Protokolle grundsätzlich inkompatibel sind, können der WebRTC-Client 32 und der Nicht-WebRTC-Client 34 keinen interaktiven Fluss direkt zueinander über eine Peerverbindung herstellen. Um Interoperabilität zwischen dem WebRTC-Client 32 und dem Nicht-WebRTC-Client 34 zu ermöglichen, stellt das virtuelle WebRTC-Gateway 16 einen virtuellen WebRTC-Agenten 52 und einen virtuellen Nicht-WebRTC-Agenten 54 bereit. Im Beispiel von 1 lädt der WebRTC-Client 32 eine WebRTC-Webanwendung (nicht gezeigt) von einem WebRTC-Anwendungsanbieter 56 des Servers für interaktive Flüsse, 12, über eine Hyper-Text-Transfer-Protocol(HTTP)/Hyper-Text-Transfer-Protocol-Secure(HTTPS)-Verbindung 58 herunter. In einigen Ausführungsformen umfasst die WebRTC-Webanwendung möglicherweise eine HTML5/JavaScript-Webanwendung, die unter Nutzung von HTML5 ein Rich User Interface bereitstellt, und nutzt JavaScript zum Behandeln von Benutzereingaben und zum Kommunizieren mit dem WebRTC-Webanwendungsanbieter 56. Das virtuelle WebRTC-Gateway 16 instanziiert dann den virtuellen WebRTC-Agenten 52, der dem WebRTC-Client 32 entspricht. In einigen Ausführungsformen kann das virtuelle WebRTC-Gateway 16 den virtuellen WebRTC-Agenten 52 instanziieren, indem es eine Instanz eines WebRTC-Clients, etwa einen Webbrowser, auf der Computereinrichtung 14 startet. Einige Ausführungsformen können vorsehen, dass der virtuelle WebRTC-Agent 52 innerhalb einer virtuellen Instanz eines Betriebssystems ausgeführt wird.
-
Nach der Instanziierung wird der virtuelle WebRTC-Agent 52 vom virtuellen WebRTC-Gateway 16 dazu angewiesen, eine virtuelle WebRTC-Anwendung (nicht gezeigt) von einem Anbieter virtueller WebRTC-Anwendungen, 60, herunterzuladen. Einige Ausführungsformen können vorsehen, dass der Anbieter virtueller WebRTC-Anwendungen, 60, kommunikativ an das virtuelle WebRTC-Gateway 16 gekoppelt ist. In einigen Ausführungsformen kann der Anbieter virtueller WebRTC-Anwendungen, 60, in das virtuelle WebRTC-Gateway 16 und/oder den WebRTC-Anwendungsanbieter 56 integriert sein oder ansonsten ein Element des virtuellen WebRTC-Gateways und/oder des WebRTC-Anwendungsanbieters 56 bilden. Die virtuelle WebRTC-Anwendung beinhaltet Spezialbefehle zum Kommunizieren über eine Schnittstelle mit den WebRTC-APIs des virtuellen WebRTC-Agenten 52. Der virtuelle WebRTC-Agent 52 kann über die virtuelle WebRTC-Anwendung mit dem WebRTC-Client 32 und mit dem virtuellen WebRTC-Gateway 16 kommunizieren.
-
Das virtuelle WebRTC-Gateway 16 instanziiert auch den virtuellen Nicht-WebRTC-Agenten 54, der dem Nicht-WebRTC-Client 34 entspricht. In einigen Ausführungsformen kann das virtuelle WebRTC-Gateway 16 den virtuellen Nicht-WebRTC-Agenten 54 instanziieren, indem es eine oder mehrere Instanzen eines Nicht-WebRTC-Clients, etwa eines SIP-Benutzeragent-Clients, eines H.323-Clients oder eines Jingle-Clients, auf der Computereinrichtung 14 startet. Einige Ausführungsformen können vorsehen, dass der virtuelle Nicht-WebRTC-Agent 54 innerhalb einer virtuellen Instanz eines Betriebssystems ausgeführt wird.
-
Das virtuelle WebRTC-Gateway 16 bewirkt, dass der virtuelle WebRTC-Agent 52 den interaktiven WebRTC-Fluss 18 zum WebRTC-Client 32 herstellt, und bewirkt auch, dass der virtuelle Nicht-WebRTC-Agent 54 den interaktiven Nicht-WebRTC-Fluss 22 zum Nicht-WebRTC-Client 34 herstellt. Das virtuelle WebRTC-Gateway 16 verbindet dann den virtuellen WebRTC-Agenten 52 und den virtuellen Nicht-WebRTC-Agenten 54 aufeinanderfolgend („Back-to-Back”) (d. h. der durch den interaktiven WebRTC-Fluss 18 des virtuellen WebRTC-Agenten 52 ausgegebene Inhalt wird als Eingabe in den interaktiven Nicht-WebRTC-Fluss 22 des virtuellen Nicht-WebRTC-Agenten 54 geleitet und umgekehrt). Um eine „Back-to-Back”-Verbindung zu realisieren, stellt das virtuelle WebRTC-Gateway 16 einen virtuellen Audioempfänger (Rx) 62, einen virtuellen Audiosender (Tx) 64, einen virtuellen Videoempfänger 66, einen virtuellen Videosender 68, einen virtuellen Datenempfänger 70 und einen virtuellen Datensender 72 bereit, an die der virtuelle WebRTC-Agent 52 kommunikativ gekoppelt ist. Desgleichen ist der virtuelle Nicht-WebRTC-Agent 54 kommunikativ an einen virtuellen Audioempfänger 74, einen virtuellen Audiosender 76, einen virtuellen Videoempfänger 78, einen virtuellen Videosender 80, einen virtuellen Datenempfänger 82 und einen virtuellen Datensender 84 gekoppelt, die vom virtuellen WebRTC-Gateway 16 bereitgestellt werden.
-
Wenn der interaktive WebRTC-Fluss 18 und der interaktive Nicht-WebRTC-Fluss 22 anfangen, leiten der virtuelle WebRTC-Agent 52 und der virtuelle Nicht-WebRTC-Agent 54 Audiosignale, die aus dem entsprechenden interaktiven WebRTC-Fluss 18 und dem entsprechenden interaktiven Nicht-WebRTC-Fluss 22 empfangen werden, weiter an die virtuellen Audioempfänger 62 und 74. Der virtuelle WebRTC-Agent 52 und der virtuelle Nicht-WebRTC-Agent 54 leiten auch Videosignale, die aus dem entsprechenden interaktiven WebRTC-Fluss 18 und dem entsprechenden interaktiven Nicht-WebRTC-Fluss 22 empfangen werden, weiter an die virtuellen Videoempfänger 66 und 78 und leiten Daten, die aus dem entsprechenden interaktiven WebRTC-Fluss 18 und dem entsprechenden interaktiven Nicht-WebRTC-Fluss 22 empfangen werden, weiter an die virtuellen Datenempfänger 70 und 82.
-
Der virtuelle Audioempfänger 62, der kommunikativ an den virtuellen WebRTC-Agenten 52 gekoppelt ist, ist konfiguriert zum Leiten von Audiosignalen, die aus dem virtuellen WebRTC-Agenten 52 empfangen werden, an den virtuellen Audiosender 76, der kommunikativ an den virtuellen Nicht-WebRTC-Agenten 54 gekoppelt ist. Der virtuelle Videoempfänger 66, der kommunikativ an den virtuellen WebRTC-Agenten 52 gekoppelt ist, ist konfiguriert zum Leiten von Videosignalen, die aus dem virtuellen WebRTC-Agenten 52 empfangen werden, an den virtuellen Videosender 80, der kommunikativ an den virtuellen Nicht-WebRTC-Agenten 54 gekoppelt ist. Der virtuelle Datenempfänger 70, der kommunikativ an den virtuellen WebRTC-Agenten 52 gekoppelt ist, ist konfiguriert zum Leiten von Daten, die aus dem virtuellen WebRTC-Agenten 52 empfangen werden, an den virtuellen Datensender 84, der kommunikativ an den virtuellen Nicht-WebRTC-Agenten 54 gekoppelt ist.
-
Ähnlich ist der virtuelle Audioempfänger 74, der kommunikativ an den virtuellen Nicht-WebRTC-Agenten 54 gekoppelt ist, konfiguriert zum Leiten von Audiosignalen, die aus dem virtuellen Nicht-WebRTC-Agenten 54 empfangen werden, an den virtuellen Audiosender 64, der kommunikativ an den virtuellen WebRTC-Agenten 52 gekoppelt ist. Der virtuelle Videoempfänger 78, der kommunikativ an den virtuellen Nicht-WebRTC-Agenten 54 gekoppelt ist, ist konfiguriert zum Leiten von Videosignalen, die aus dem virtuellen Nicht-WebRTC-Agenten 54 empfangen werden, an den virtuellen Videosender 68, der kommunikativ an den virtuellen WebRTC-Agenten 52 gekoppelt ist. Der virtuelle Datenempfänger 82, der kommunikativ an den virtuellen Nicht-WebRTC-Agenten 54 gekoppelt ist, ist konfiguriert zum Leiten von Daten, die aus dem virtuellen Nicht-WebRTC-Agenten 54 empfangen werden, an den virtuellen Datensender 72, der kommunikativ an den virtuellen WebRTC-Agenten 52 gekoppelt ist.
-
Es versteht sich, dass in einigen Ausführungsformen abhängig von den Fähigkeiten und der Funktionalität, die vom virtuellen Nicht-WebRTC-Agenten 54 und/oder vom Nicht-WebRTC-Client 34 bereitgestellt werden, auf eines oder mehrere der Audiosignale, der Videosignale und/oder der Daten des interaktiven Nicht-WebRTC-Flusses 22 möglicherweise nicht zugegriffen werden kann. Beispielsweise können einige Ausführungsformen des virtuellen Nicht-WebRTC-Agenten 54 und/oder des Nicht-WebRTC-Clients 34 ein Audiosignal und ein Videosignal bereitstellen, sind jedoch möglicherweise nicht fähig, einen Datenfluss bereitzustellen, und/oder stellen möglicherweise nur einen Datenfluss unter Nutzung proprietärer Standards bereit. In solchen Ausführungsformen können die virtuellen Audioempfänger 62 und/oder 74, die virtuellen Videoempfänger 66 und/oder 78 und/oder die virtuellen Datenempfänger 70 und/oder 82 weggelassen sein.
-
Aus der Perspektive des WebRTC-Clients 32 und des Nicht-WebRTC-Clients 34 scheint die resultierende interaktive Sitzung, die den interaktiven WebRTC-Fluss 18 und den interaktiven Nicht-WebRTC-Fluss 22 beinhaltet, sich nicht zu unterscheiden von einer interaktiven Sitzung, die über eine direkte Peerverbindung transportiert wird. Während der resultierenden interaktiven Sitzung kann das virtuelle WebRTC-Gateway 16 Inhalt aus dem interaktiven WebRTC-Fluss 18 und/oder dem interaktiven Nicht-WebRTC-Fluss 22 extrahieren, indem es auf eine Eingabe aus den virtuellen Audioempfängern 62 und/oder 74, den virtuellen Videoempfängern 66 und/oder 78 und/oder den virtuellen Datenempfängern 70 und/oder 82 zugreift. Das virtuelle WebRTC-Gateway 16 kann auch Inhalt in den interaktiven WebRTC-Fluss 18 und/oder den interaktiven Nicht-WebRTC-Fluss 22 einfügen, indem es eine Ausgabe von den virtuellen Audiosendern 64 und/oder 76, den virtuellen Videosendern 68 und/oder 80 und/oder den virtuellen Datensendern 72 und 84 modifiziert. Daher können einige Ausführungsformen vorsehen, dass Inhalt aus dem interaktiven WebRTC-Fluss 18 und/oder dem interaktiven Nicht-WebRTC-Fluss 22 extrahiert oder in den interaktiven WebRTC-Fluss 18 und/oder den interaktiven Nicht-WebRTC-Fluss 22 eingefügt werden kann. In einigen Ausführungsformen kann Inhalt aus dem interaktiven WebRTC-Fluss 18 und/oder dem interaktiven Nicht-WebRTC-Fluss 22 vom virtuellen WebRTC-Gateway 16 aufgezeichnet oder umgewandelt werden.
-
In einigen Ausführungsformen kann Inhalt aus dem interaktiven WebRTC-Fluss 18 und/oder dem interaktiven Nicht-WebRTC-Fluss 22 optional an einen Funktionalitätsanbieter 86 geleitet oder von einem Funktionalitätsanbieter 86 empfangen werden, wie durch den bidirektionalen Videofeed 88, den bidirektionalen Audiofeed 90 und den bidirektionalen Datenfeed 92 angegeben. Der Funktionalitätsanbieter 86 kann zusätzliche Medienverarbeitungs- und -behandlungsfunktionalität bereitstellen, etwa Aufzeichnen oder Umwandeln von Inhalt des interaktiven WebRTC-Flusses 18 und/oder des interaktiven Nicht-WebRTC-Flusses 22. In einigen Ausführungsformen kann der Funktionalitätsanbieter 86 Inhalt, etwa Audio- oder Videoankündigungen, zur Einfügung in den interaktiven WebRTC-Fluss 18 und/oder den interaktiven Nicht-WebRTC-Fluss 22 bereitstellen.
-
Im Beispiel von 1 können das virtuelle WebRTC-Gateway 16 und/oder der WebRTC-Anwendungsanbieter 56 den spezifischen Clienttyp und/oder die spezifische Clientversion des WebRTC-Clients 32 vor dem Instanziieren des virtuellen WebRTC-Agenten 52 bestimmen. In einigen Ausführungsformen lassen sich der Clienttyp und/oder die Clientversion des WebRTC-Clients 32 basierend auf Daten, die als Teil eines WebRTC-Angebot-Antwort-Austausches, eines Abfrage-Rückmeldung-Austausches zwischen dem virtuellen WebRTC-Gateway 16 und dem WebRTC-Client 32 empfangen werden, oder HTTP-Kopfdaten oder anderen vom WebRTC-Client 32 bereitgestellten Daten bestimmen. Das virtuelle WebRTC-Gateway 16 kann dann den virtuellen WebRTC-Agenten 52 mit einem Clienttyp und/oder einer Clientversion instanziieren, die dem Clienttyp und/oder der Clientversion des WebRTC-Clients 32 entsprechen. Da der WebRTC-Client 32 mit einem virtuellen WebRTC-Agenten 52 desselben Typs und derselben Version direkt kommuniziert, lassen sich Inkompatibilitäten aufgrund variierender Stufen des Supports für WebRTC durch den WebRTC-Client 32 beseitigen.
-
In einigen Ausführungsformen kann ein Anrufsteuerungsanwendungsanbieter 94 bereitgestellt sein, um die Verwaltung einer interaktiven Sitzung zwischen dem WebRTC-Client 32 und dem Nicht-WebRTC-Client 34 weiter zu erleichtern. Als nicht einschränkendes Beispiel kann der Anrufsteuerungsanwendungsanbieter 94 eine Anrufsteuerungsanwendung (nicht gezeigt) bereitstellen, die über eine HTTP/HTTPS-Verbindung 96 in den WebRTC-Client 32 heruntergeladen werden kann. Der Anrufsteuerungsanwendungsanbieter 94 kann zusätzliche Funktionalität zum Generieren und Senden zweckmäßiger Kommandos zur Verwaltung interaktiver Flüsse über den Anrufsteuerungsanwendungsanbieter 94 für den virtuellen Nicht-WebRTC-Agenten 54 bereitstellen. Falls der Nicht-WebRTC-Client 34 beispielsweise ein SIP-Client ist, kann der Anrufsteuerungsanwendungsanbieter 94 den WebRTC-Client 32 mit einer Anrufsteuerungsanwendung ausstatten, die eine HTML5-Schnittstelle aufweist, um eine interaktive SIP-Sitzung einzuleiten, zu beenden, als Konferenz zu schalten und/oder zu übertragen. Der Anrufsteuerungsanwendungsanbieter 94 kann Eingaben aus dem WebRTC-Client 32 dann in die entsprechenden SIP-Kommandos übersetzen und kann die entsprechenden SIP-Kommandos an den virtuellen Nicht-WebRTC-Agenten 54 weitersenden.
-
Um beispielhafte Abläufe des virtuellen WebRTC-Gateways 16 von 1 zum Bereitstellen des virtuellen WebRTC-Agenten 52 und des virtuellen Nicht-WebRTC-Agenten 54 allgemein zu beschreiben, ist 2 bereitgestellt. Der Klarheit halber wird beim Beschreiben von 2 auf Elemente von 1 Bezug genommen. Im Beispiel von 2 beginnen die Abläufe damit, dass der WebRTC-Anwendungsanbieter 56 einen virtuellen WebRTC-Agenten 52, der einem WebRTC-Client 32 entspricht, instanziiert (Block 98). Als nicht einschränkendes Beispiel kann das virtuelle WebRTC-Gateway 16 den virtuellen WebRTC-Agenten 52 instanziieren, indem es eine Instanz eines WebRTC-Clients, etwa einen Webbrowser, auf der Computereinrichtung 14 startet. Das virtuelle WebRTC-Gateway 16 instanziiert dann einen virtuellen Nicht-WebRTC-Agenten 54, der einem Nicht-WebRTC-Client 34 entspricht (Block 100). In einigen Ausführungsformen kann das virtuelle WebRTC-Gateway 16 den virtuellen Nicht-WebRTC-Agenten 54 instanziieren, indem es eine Instanz eines Nicht-WebRTC-Clients, etwa eines SIP-Benutzeragent-Clients, eines H.323-Clients oder eines Jingle-Clients, auf der Computereinrichtung 14 startet.
-
Das virtuelle WebRTC-Gateway 16 stellt dann einen interaktiven WebRTC-Fluss 18 zwischen dem virtuellen WebRTC-Agenten 52 und dem WebRTC-Client 32 her (Block 102). Das virtuelle WebRTC-Gateway 16 stellt auch einen interaktiven Nicht-WebRTC-Fluss 22 zwischen dem virtuellen Nicht-WebRTC-Agenten 54 und dem Nicht-WebRTC-Client 34 her (Block 104). Das virtuelle WebRTC-Gateway 16 leitet als Nächstes einen Inhalt des interaktiven WebRTC-Flusses 18 an den interaktiven Nicht-WebRTC-Fluss 22 und einen Inhalt des interaktiven Nicht-WebRTC-Flusses 22 an den interaktiven WebRTC-Fluss 18 über den virtuellen WebRTC-Agenten 52 und den virtuellen Nicht-WebRTC-Agenten 54 (Block 106). Daraus resultiert eine „Back-to-Back”-Verbindung zwischen dem virtuellen WebRTC-Agenten 52 und dem virtuellen Nicht-WebRTC-Agenten 54. In einigen Ausführungsformen ist dies realisierbar durch die Nutzung virtueller Audioempfänger 62, 74 und -sender 64, 76, virtueller Videoempfänger 66, 78 und -sender 68, 80 und virtueller Datenempfänger 70, 82 und -sender 72, 84, die vom virtuellen WebRTC-Gateway 16 bereitgestellt werden, wie in 1 veranschaulicht.
-
Um beispielhafte Kommunikationsflüsse für eine ausgehende Interaktionsanforderung von einem WebRTC-Client 32 an einen Nicht-WebRTC-Client 34 unter Nutzung des virtuellen WebRTC-Agenten 52 und des virtuellen Nicht-WebRTC-Agenten 54 von 1 zu veranschaulichen, ist 3 bereitgestellt. In 3 sind der WebRTC-Client 32, der virtuelle WebRTC-Agent 52, das virtuelle WebRTC-Gateway 16, der virtuelle Nicht-WebRTC-Agent 54 und der Nicht-WebRTC-Client 34 von 1 je durch vertikale gestrichelte Linien dargestellt. Es versteht sich für dieses Beispiel, dass der WebRTC-C1ient 32 eine WebRTC-fähige Webanwendung, etwa eine HTML5/JavaScript-WebRTC-Anwendung, vom Server für interaktive Flüsse, 12, heruntergeladen hat. In einigen Ausführungsformen ist der Nicht-WebRTC-Client 34 möglicherweise ein SIP-Benutzeragent-Client, ein H.323-Client oder ein Jingle-Client, wobei es sich um nicht einschränkende Beispiele handelt.
-
Wie in 3 ersichtlich, beginnt die Herstellung einer interaktiven Sitzung über den virtuellen WebRTC-Agenten 52 und den virtuellen Nicht-WebRTC-Agenten 54 damit, dass der WebRTC-Client 32 eine ausgehende Interaktionsanforderung, dargestellt vom Pfeil 108, an das virtuelle WebRTC-Gateway 16 sendet. Einige Ausführungsformen können vorsehen, dass die ausgehende Interaktionsanforderung eine Auswahl eines Nicht-WebRTC-Protokolls durch den WebRTC-Client 32 aus einer Vielzahl von Nicht-WebRTC-Protokollen, die vom virtuellen WebRTC-Gateway 16 unterstützt werden, beinhaltet. In einigen Ausführungsformen beinhaltet die ausgehende Interaktionsanforderung möglicherweise einen SIP Uniform Resource Identifier (URI) oder eine SIP-Adresse für den Nicht-WebRTC-Client 34. Als Rückmeldung auf das Empfangen der ausgehenden Interaktionsanforderung instanziiert das virtuelle WebRTC-Gateway 16 den virtuellen WebRTC-Agenten 52, der dem WebRTC-Client 32 entspricht, wie vom Pfeil 110 angegeben. Der virtuelle WebRTC-Agent 52 kann mit einem Clienttyp und/oder einer Clientversion, die bekanntermaßen mit dem WebRTC-Client 32 kompatibel ist/sind, basierend auf einem WebRTC-Angebot-Antwort-Austausch, einem Abfrage-Rückmeldung-Austausch zwischen dem virtuellen WebRTC-Gateway 16 und dem WebRTC-Client 32 oder HTTP-Kopfdaten oder anderen vom WebRTC-Client 32 bereitgestellten Daten instanziiert werden.
-
Weiter mit Bezug auf 3 beginnen der WebRTC-Client 32 und der virtuelle WebRTC-Agent 52 dann mit „Hole Punching”, angegeben vom bidirektionalen Pfeil 112, um den besten Weg zur Herstellung direkter Kommunikationen zu bestimmen. Hole Punching ist eine Technik, die oft Protokolle wie Interactive Connectivity Establishment (ICE) nutzt, über die der WebRTC-Client 32 und/oder der virtuelle WebRTC-Agent 52 eine Verbindung zu einem keinen Einschränkungen unterliegenden Drittanbieterserver (nicht gezeigt) herstellen, der externe und interne Adressinformationen zur Nutzung bei direkten Kommunikationen erkennt. Falls das vom Pfeil 112 angegebene ICE Hole Punching erfolgreich ist, beginnen der WebRTC-Client 32 und der virtuelle WebRTC-Agent 52 mit Schlüsselaushandlungen, um eine sichere Peerverbindung herzustellen, wie vom bidirektionalen Pfeil 114 angegeben. Falls die Schlüsselaushandlungen erfolgreich abgeschlossen werden, wird zwischen dem WebRTC-Client 32 und dem virtuellen WebRTC-Agenten 52 eine Peerverbindung hergestellt, wie vom bidirektionalen Pfeil 116 angegeben.
-
Nach dem Herstellen einer Peerverbindung zwischen dem WebRTC-Client 32 und dem virtuellen WebRTC-Agenten 52 instanziiert das virtuelle WebRTC-Gateway 16 dann den virtuellen Nicht-WebRTC-Agenten 54, der dem Nicht-WebRTC-Client 34 entspricht, wie vom Pfeil 118 angegeben. Einige Ausführungsformen können vorsehen, dass der virtuelle Nicht-WebRTC-Agent 54 instanziiert wird, um dem ausgewählten Nicht-WebRTC-Protokoll zu entsprechen, das von der ausgehenden Interaktionsanforderung angegeben wird. Sobald der virtuelle Nicht-WebRTC-Agent 54 instanziiert ist, sendet er eine INVITE-Anforderung, dargestellt vom Pfeil 120, an den Nicht-WebRTC-Client 34. In einigen Ausführungsformen ist die INVITE-Anforderung eine protokollspezifische Nachricht zum Anfordern der Initiierung einer interaktiven Sitzung. Die INVITE-Anforderung für einen SIP-Client ist zum Beispiel möglicherweise eine SIP-INVITE-Anforderung, die an den SIP URI oder die SIP-Adresse gesendet wird, der bzw. die vom WebRTC-Client 32 in der ausgehenden Interaktionsanforderung anfänglich festgelegt wird. Falls der Nicht-WebRTC-Client 34 der ausgehenden Interaktionsanforderung zustimmt, meldet sich der Nicht-WebRTC-Client 34 mit einer OK-Nachricht an den virtuellen Nicht-WebRTC-Agenten 54 zurück, wie vom Pfeil 122 angegeben. In Ausführungsformen, in denen der Nicht-WebRTC-Client 34 ein SIP-Client ist, kann die OK-Nachricht eine SIP-„200 OK”-Rückmeldungsnachricht sein.
-
Der WebRTC-Client 32 und der Nicht-WebRTC-Client 34 beginnen dann, Medien- und/oder Datenflüsse auszutauschen. Wie in 3 ersichtlich, läuft Inhalt des interaktiven WebRTC-Flusses 18 vom WebRTC-Client 32 zum virtuellen WebRTC-Agenten 52, wie vom bidirektionalen Pfeil 124 angegeben. Ähnlich läuft Inhalt des interaktiven Nicht-WebRTC-Flusses 22 vom Nicht-WebRTC-Client 34 zum virtuellen Nicht-WebRTC-Agenten 54, wie vom bidirektionalen Pfeil 126 angegeben. Der virtuelle WebRTC-Agent 52 und der virtuelle Nicht-WebRTC-Agent 54 senden dann den Inhalt des interaktiven WebRTC-Flusses 18 und des interaktiven Nicht-WebRTC-Flusses 22 durch das virtuelle WebRTC-Gateway 16, wie von den bidirektionalen Pfeilen 128 und 130 gezeigt. Auf diese Weise kann das virtuelle WebRTC-Gateway 16 den Inhalt des interaktiven WebRTC-Flusses 18 und/oder des interaktiven Nicht-WebRTC-Flusses 22 zwischen dem WebRTC-Client 32 und dem Nicht-WebRTC-Client 34 selektiv steuern, überwachen und/oder modifizieren.
-
Als Ergänzung der ausgehenden Interaktionsanforderung, die in 3 veranschaulicht ist, veranschaulicht 4 beispielhafte Kommunikationsflüsse für eine eingehende Interaktionsanforderung an den WebRTC-Client 32 vom Nicht-WebRTC-Client 34 unter Nutzung des virtuellen WebRTC-Agenten 52 und des virtuellen Nicht-WebRTC-Agenten 54 von 1. In 4 sind der WebRTC-Client 32, der virtuelle WebRTC-Agent 52, das virtuelle WebRTC-Gateway 16, der virtuelle Nicht-WebRTC-Agent 54 und der Nicht-WebRTC-Client 34 von 1 je durch vertikale gestrichelte Linien dargestellt. Es versteht sich für dieses Beispiel, dass der WebRTC-Client 32 eine WebRTC-fähige Webanwendung, etwa eine HTML5/JavaScript-WebRTC-Anwendung, vom Server für interaktive Flüsse, 12, heruntergeladen hat. In einigen Ausführungsformen ist der Nicht-WebRTC-Client 34 möglicherweise ein SIP-Benutzeragent-Client, ein H.323-Client oder ein Jingle-Client, wobei es sich um nicht einschränkende Beispiele handelt.
-
In einigen Ausführungsformen erfordert das Empfangen einer eingehenden Interaktionsanforderung an den WebRTC-Client 32 vom Nicht-WebRTC-Client 34, dass der virtuelle Nicht-WebRTC-Agent 54 instanziiert wird, wenn der WebRTC-Client 32 aktiv ist. Demgemäß empfängt das virtuelle WebRTC-Gateway 16 in 4 eine Angabe, dass der WebRTC-Client 32 aktiv ist, wie vom Pfeil 132 angegeben. Nach dem Bestimmen, dass der WebRTC-Client 32 aktiv ist, instanziiert das virtuelle WebRTC-Gateway 16 den virtuellen Nicht-WebRTC-Agenten 54, wie vom Pfeil 134 angegeben. Sobald der virtuelle Nicht-WebRTC-Agent 54 instanziiert ist, erwartet er eine eingehende Anforderung von Interaktion.
-
Um eine interaktive Sitzung mit dem WebRTC-Client 32 zu initiieren, sendet der Nicht-WebRTC-Client 34 eine INVITE-Anforderung, dargestellt vom Pfeil 136, an den virtuellen Nicht-WebRTC-Agenten 54. In einigen Ausführungsformen ist die INVITE-Anforderung eine protokollspezifische Nachricht zum Anfordern der Initiierung einer interaktiven Sitzung. Falls der Nicht-WebRTC-Client 34 zum Beispiel ein SIP-Benutzeragent-Client ist, kann die INVITE-Anforderung eine SIP-INVITE-Anforderung sein, die an einen SIP URI oder eine SIP-Adresse gesendet wird, der bzw. die dem WebRTC-Client 32 zugewiesen und beim virtuellen Nicht-WebRTC-Agenten 54 registriert ist.
-
Als Rückmeldung auf das Empfangen der eingehenden Interaktionsanforderung instanziiert das virtuelle WebRTC-Gateway 16 den virtuellen WebRTC-Agenten 52, der dem WebRTC-Client 32 entspricht, wie vom Pfeil 138 angegeben. Der virtuelle WebRTC-Agent 52 kann mit einem Clienttyp und/oder einer Clientversion, der bzw. die bekanntermaßen mit dem WebRTC-Client 32 kompatibel ist, basierend auf einem WebRTC-Angebot-Antwort-Austausch, einem Abfrage-Rückmeldung-Austausch zwischen dem virtuellen WebRTC-Gateway 16 und dem WebRTC-Client 32 oder HTTP-Kopfdaten oder anderen vom WebRTC-Client 32 bereitgestellten Daten instanziiert werden. Der WebRTC-Client 32 und der virtuelle WebRTC-Agent 52 beginnen dann mit Hole Punching, wie vom bidirektionalen Pfeil 140 angegeben, um den besten Weg zur Herstellung direkter Kommunikationen zu bestimmen. Falls das vom Pfeil 140 angegebene ICE Hole Punching erfolgreich ist, beginnen der WebRTC-Client 32 und der virtuelle WebRTC-Agent 52 mit Schlüsselaushandlungen, um eine sichere Peerverbindung herzustellen, wie vom bidirektionalen Pfeil 142 angegeben. Sobald die Schlüsselaushandlungen erfolgreich abgeschlossen werden, wird zwischen dem WebRTC-Client 32 und dem virtuellen WebRTC-Agenten 52 eine Peerverbindung hergestellt, wie vom bidirektionalen Pfeil 144 angegeben.
-
Nach dem Herstellen einer Peerverbindung zwischen dem WebRTC-Client 32 und dem virtuellen WebRTC-Agenten 52 meldet sich der virtuelle Nicht-WebRTC-Agent 54 mit einer OK-Nachricht an den Nicht-WebRTC-Client 34 zurück, wie vom Pfeil 146 angegeben. In Ausführungsformen, in denen der Nicht-WebRTC-Client 34 ein SIP-Client ist, kann die OK-Nachricht eine SIP-„200 OK”-Rückmeldungsnachricht sein. Der WebRTC-Client 32 und der Nicht-WebRTC-Client 34 beginnen dann, Medien- und/oder Datenflüsse auszutauschen. Wie in 4 ersichtlich, läuft Inhalt des interaktiven WebRTC-Flusses 18 vom WebRTC-Client 32 zum virtuellen WebRTC-Agenten 52, wie vom bidirektionalen Pfeil 148 angegeben. Ähnlich läuft Inhalt des interaktiven Nicht-WebRTC-Flusses 22 vom Nicht-WebRTC-Client 34 zum virtuellen Nicht-WebRTC-Agenten 54, wie vom bidirektionalen Pfeil 150 angegeben. Der virtuelle WebRTC-Agent 52 und der virtuelle Nicht-WebRTC-Agent 54 senden dann den Inhalt des interaktiven WebRTC-Flusses 18 und des interaktiven Nicht-WebRTC-Flusses 22 durch das virtuelle WebRTC-Gateway 16, wie von den bidirektionalen Pfeilen 152 und 154 gezeigt. Auf diese Weise kann das virtuelle WebRTC-Gateway 16 den Inhalt des interaktiven WebRTC-Flusses 18 und des interaktiven Nicht-WebRTC-Flusses 22 zwischen dem WebRTC-Client 32 und dem Nicht-WebRTC-Client 34 selektiv steuern, überwachen und/oder modifizieren.
-
Die 5A und 5B sind bereitgestellt, um einen beispielhaften verallgemeinerten Prozess, bei dem das virtuelle WebRTC-Gateway 16 von 1 Interoperabilität zwischen einen WebRTC-Client 32 und einem Nicht-WebRTC-Client 34 bereitstellt, detaillierter zu veranschaulichen. Zu Veranschaulichungszwecken beziehen sich die 5A und 5B auf Elemente des beispielhaften interaktiven Kommunikationssystems 10 von 1. 5A zeigt detailliert Abläufe zum Herstellen einer interaktiven Sitzung als Rückmeldung auf eine eingehende Interaktionsanforderung und/oder eine ausgehende Interaktionsanforderung. 5B veranschaulicht Abläufe zum Bereitstellen von zusätzlicher Funktionalität, die Extrahieren von Inhalt aus, Einfügen von Inhalt in, Aufzeichnen und/oder Umwandeln des Inhalts des interaktiven WebRTC-Flusses 18 und/oder des interaktiven Nicht-WebRTC-Flusses 22 beinhalten.
-
In 5A beginnt die Verarbeitung damit, dass das virtuelle WebRTC-Gateway 16 optional bestimmt, ob der WebRTC-Client 32 aktiv ist (Block 156). Wie oben hinsichtlich 4 angemerkt, kann Empfangen einer eingehenden Interaktionsanforderung an den WebRTC-Client 32 vom Nicht-WebRTC-Client 34 erfordern, dass der virtuelle Nicht-WebRTC-Agent 54 instanziiert wird, wenn der WebRTC-Client 32 aktiv ist. Falls bestimmt wird, dass der WebRTC-Client 32 aktiv ist, kann das virtuelle WebRTC-Gateway 16 demgemäß einen virtuellen Nicht-WebRTC-Agenten 54, der dem Nicht-WebRTC-Client 34 entspricht, instanziieren (Block 158). Die Verarbeitung wird dann bei Block 160 wieder aufgenommen. Falls bei Block 156 hingegen bestimmt wird, dass der WebRTC-Client 32 nicht aktiv ist, wird bei der Verarbeitung zu Block 156 zurückgekehrt. Es versteht sich, dass einige Ausführungsformen des virtuellen WebRTC-Gateways 16 so konfiguriert sein können, dass sie nur ausgehende Interaktionsanforderungen vom WebRTC-Client 32 an den Nicht-WebRTC-Client 34 behandeln. Für solche Ausführungsformen kann die Funktionalität der Blöcke 156 und 158 weggelassen werden.
-
Das virtuelle WebRTC-Gateway 16 bestimmt dann, ob eine Anforderung von ausgehender oder eingehender Interaktion empfangen wurde (Block 160). In einigen Ausführungsformen beinhaltet eine ausgehende Interaktionsanforderung möglicherweise einen SIP URI oder eine SIP-Adresse für den Nicht-WebRTC-Client 34. Einige Ausführungsformen können vorsehen, dass eine eingehende Interaktionsanforderung einen SIP URI oder eine SIP-Adresse, der bzw. die dem WebRTC-Client 32 zugewiesen ist, beinhaltet. Falls keine ausgehende oder eingehende Interaktionsanforderung durch das virtuelle WebRTC-Gateway 16 empfangen wurde, wird bei der Verarbeitung zu Block 160 zurückgekehrt.
-
Falls das virtuelle WebRTC-Gateway 16 bei Block 160 bestimmt, dass eine ausgehende Interaktionsanforderung vom WebRTC-Client 32 empfangen wurde, instanziiert das virtuelle WebRTC-Gateway 16 einen virtuellen Nicht-WebRTC-Agenten 54, der dem Nicht-WebRTC-Client 34 entspricht (Block 162). Die Verarbeitung wird dann bei Block 164 wieder aufgenommen. Falls das virtuelle WebRTC-Gateway 16 bei Block 160 bestimmt, dass eine eingehende Interaktionsanforderung empfangen wurde, wird bei der Verarbeitung direkt zu Block 164 übergegangen.
-
Das virtuelle WebRTC-Gateway 16 kann optional einen Clienttyp und/oder eine Clientversion des WebRTC-Clients 32 basierend auf einem WebRTC-Angebot-Antwort-Austausch, einem Abfrage-Rückmeldung-Austausch zwischen dem virtuellen WebRTC-Gateway 16 und dem WebRTC-Client 32 oder HTTP-Kopfdaten oder anderen vom WebRTC-Client 32 bereitgestellten Daten bestimmen (Block 164). Dadurch lässt sich ermöglichen, dass das virtuelle WebRTC-Gateway 16 einen virtuellen WebRTC-Agenten 52 mit einem Clienttyp und/oder einer Clientversion instanziiert, der bzw. die dem Clienttyp und/oder der Clientversion des WebRTC-Clients 32 entspricht. Da der WebRTC-Client 32 mit einem virtuellen WebRTC-Agenten 52 desselben Typs und derselben Version direkt kommuniziert, lassen sich Inkompatibilitäten aufgrund variierender Stufen des Supports für WebRTC durch den WebRTC-Client 32 beseitigen.
-
Das virtuelle WebRTC-Gateway 16 instanziiert dann einen virtuellen WebRTC-Agenten 52, der dem WebRTC-Client 32 entspricht (Block 166). In einigen Ausführungsformen kann das virtuelle WebRTC-Gateway 16 den virtuellen WebRTC-Agenten 52 instanziieren, indem es eine Instanz eines WebRTC-Clients, etwa einen Webbrowser, auf der Computereinrichtung 14 startet. Einige Ausführungsformen können vorsehen, dass der virtuelle WebRTC-Agent 52 innerhalb einer virtuellen Instanz eines Betriebssystems ausgeführt wird.
-
Das virtuelle WebRTC-Gateway 16 stellt dann einen interaktiven WebRTC-Fluss 18 zwischen dem virtuellen WebRTC-Agenten 52 und dem WebRTC-Client 32 her (Block 168). Das virtuelle WebRTC-Gateway 16 stellt auch einen interaktiven Nicht-WebRTC-Fluss 22 zwischen dem virtuellen Nicht-WebRTC-Agenten 54 und dem Nicht-WebRTC-Client 34 her (Block 170). Das virtuelle WebRTC-Gateway 16 leitet als Nächstes einen Inhalt des interaktiven WebRTC-Flusses 18 an den interaktiven Nicht-WebRTC-Fluss 22 und einen Inhalt des interaktiven Nicht-WebRTC-Flusses 22 an den interaktiven WebRTC-Fluss 18 über den virtuellen WebRTC-Agenten 52 und den virtuellen Nicht-WebRTC-Agenten 54 (Block 172). Daraus resultiert eine „Back-to-Back”-Verbindung zwischen dem virtuellen WebRTC-Agenten 52 und dem virtuellen Nicht-WebRTC-Agenten 54. In einigen Ausführungsformen ist dies realisierbar durch die Nutzung virtueller Audioempfänger 62, 74 und -sender 64, 76, virtueller Videoempfänger 66, 78 und -sender 68, 80 und virtueller Datenempfänger 70, 82 und -sender 72, 84, die vom virtuellen WebRTC-Gateway 16 bereitgestellt werden, wie in 1 veranschaulicht. Die Verarbeitung wird dann bei Block 174 von 5B wieder aufgenommen.
-
Unter jetziger Bezugnahme auf 5B kann das virtuelle WebRTC-Gateway 16 an dieser Stelle auf die Inhalte des interaktiven WebRTC-Flusses 18 und des interaktiven Nicht-WebRTC-Flusses 22 zugreifen und kann zusätzliche Medienverarbeitungs- und -behandlungsfunktionalität bereitstellen. Zum Beispiel kann das virtuelle WebRTC-Gateway 16 in einigen Ausführungsformen Inhalt aus dem interaktiven WebRTC-Fluss 18, dem interaktiven Nicht-WebRTC-Fluss 22 oder einer Kombination davon extrahieren (Block 174). Einige Ausführungsformen können vorsehen, dass das virtuelle WebRTC-Gateway 16 Inhalt in den interaktiven WebRTC-Fluss 18, den interaktiven Nicht-WebRTC-Fluss 22 oder eine Kombination davon einfügen kann (Block 176). Zum Beispiel kann das virtuelle WebRTC-Gateway 16 zusätzliches Audio, zusätzliches Video und/oder zusätzliche Daten in den interaktiven WebRTC-Fluss 18 und/oder den interaktiven Nicht-WebRTC-Fluss 22 einfügen. Gemäß einigen Ausführungsformen kann das virtuelle WebRTC-Gateway 16 einen Inhalt des interaktiven WebRTC-Flusses 18, einen Inhalt des interaktiven Nicht-WebRTC-Flusses 22 oder eine Kombination davon aufzeichnen (Block 178). In einigen Ausführungsformen kann das virtuelle WebRTC-Gateway 16 einen Inhalt des interaktiven WebRTC-Flusses 18, einen Inhalt des interaktiven Nicht-WebRTC-Flusses 22 oder eine Kombination davon umwandeln (Block 180).
-
Das virtuelle WebRTC-Gateway 16 bestimmt dann, ob einer vom interaktiven WebRTC-Fluss 18 oder vom interaktiven Nicht-WebRTC-Fluss 22 beendet wurde (Block 182). Falls sowohl der interaktive WebRTC-Fluss 18 als auch der interaktive Nicht-WebRTC-Fluss 22 noch aktiv sind, wird bei der Verarbeitung zu Block 174 von 5B zurückgekehrt. Ansonsten beendet das virtuelle WebRTC-Gateway 16 gegebenenfalls den verbleibenden aktiven interaktiven WebRTC-Fluss 18 oder interaktiven Nicht-WebRTC-Fluss 22 (Block 184).
-
6 stellt eine schematische Diagrammdarstellung eines Verarbeitungssystems 186 in der beispielhaften Form eines beispielhaften Computersystems 188 bereit, das angepasst ist, um Befehle zum Durchführen der hierin beschriebenen Funktionen auszuführen. In einigen Ausführungsformen kann das Verarbeitungssystem 186 Befehle zum Durchführen der Funktionen des WebRTC-Anwendungsanbieters 56 und des virtuellen WebRTC-Gateways 16 von 1 ausführen. In diesem Zusammenhang kann das Verarbeitungssystem 186 das Computersystem 188 umfassen, innerhalb dessen ein Satz von Befehlen zum Bewirken, dass das Verarbeitungssystem 186 eine beliebige oder beliebige mehrere der hierin erörterten Methodiken durchführt, ausgeführt werden kann. Das Verarbeitungssystem 186 ist möglicherweise mit anderen Maschinen in einem Local Area Network (LAN), einem Intranet, einem Extranet oder dem Internet verbunden (etwa vernetzt, wobei es sich um ein nicht einschränkendes Beispiel handelt). Das Verarbeitungssystem 186 wird möglicherweise in einer Client-Server-Netzumgebung oder als gleichrangige Maschine in der Umgebung eines Peer-to-Peer-(oder dezentralisierten)Netzes betrieben. Auch wenn nur ein einziges Verarbeitungssystem 186 veranschaulicht wird, können die Begriffe „Controller” und „Server” auch so aufgefasst werden, dass sie eine beliebige Gruppe von Maschinen beinhalten, die individuell oder gemeinsam einen Satz (oder mehrere Sätze) von Befehlen zum Durchführen einer beliebigen oder beliebiger mehrerer der hierin erörterten Methodiken ausführen. Das Verarbeitungssystem 186 ist möglicherweise ein Server, ein Personal Computer, ein Desktop-Computer, ein Laptop-Computer, ein Personal Digital Assistant (PDA), ein Computerpad, eine mobile Einrichtung oder eine beliebige andere Einrichtung und verkörpert möglicherweise, wobei es sich um nicht einschränkende Beispiele handelt, einen Server oder einen Computer eines Benutzers.
-
Das beispielhafte Computersystem 188 beinhaltet eine Verarbeitungseinrichtung oder einen Prozessor 190, einen Hauptspeicher 192 (ein Read Only Memory (ROM), einen Flashspeicher, einen dynamischen Schreib-Lese-Speicher (DRAM) wie ein synchrones DRAM (SDRAM) etc. als nicht einschränkende Beispiele) und einen statischen Speicher 194 (einen Flashspeicher, einen statischen Schreib-Lese-Speicher (SRAM) etc. als nicht einschränkende Beispiele), die möglicherweise über einen Bus 196 miteinander kommunizieren. Alternativ ist die Verarbeitungseinrichtung 190 möglicherweise direkt oder über irgendein anderes Konnektivitätsmittel mit dem Hauptspeicher 192 und/oder dem statischen Speicher 194 verbunden.
-
Die Verarbeitungseinrichtung 190 verkörpert eine oder mehrere Verarbeitungseinrichtungen wie einen Mikroprozessor, eine Zentralverarbeitungseinheit (CPU) oder dergleichen. Insbesondere ist die Verarbeitungseinrichtung 190 möglicherweise ein Mikroprozessor für Rechenvorgänge mit komplexem Befehlssatz (CISC), ein Mikroprozessor für Rechenvorgänge mit reduziertem Befehlssatz (RISC), ein Mikroprozessor für überlange Befehlswörter (VLIW), ein Prozessor, der andere Befehlssätze implementiert, oder ein Prozessor, der eine Kombination von Befehlssätzen implementiert. Die Verarbeitungseinrichtung 190 ist konfiguriert, um Verarbeitungslogik in Befehlen 198 und/oder gecachten Befehlen 200 zum Durchführen der hierin erörterten Abläufe und Schritte auszuführen.
-
Das Computersystem 188 beinhaltet weiter möglicherweise eine Kommunikationsschnittstelle in Form einer Netzschnittstelleneinrichtung 202. Es kann auch einen Eingang 204 zum Empfangen von Eingaben und Auswahloptionen, die bei der Ausführung der Befehle 198, 200 an das Computersystem 188 zu kommunizieren sind, beinhalten oder nicht. Es kann auch einen Ausgang 206, der unter anderem (eine) Anzeige(n) 208 beinhaltet, beinhalten oder nicht. Die Anzeige(n) 208 ist/sind möglicherweise eine Videoanzeigeeinheit (eine Flüssigkristallanzeige (LCD) oder eine Kathodenstrahlröhre (CRT) als nicht einschränkende Beispiele), eine Einrichtung für alphanumerische Eingaben (eine Tastatur als nicht einschränkendes Beispiel), eine Cursorsteuereinrichtung (eine Maus als nicht einschränkendes Beispiel) und/oder eine Touchscreen-Einrichtung (eine Tablet-Eingabeeinrichtung oder ein Bildschirm als nicht einschränkende Beispiele).
-
Das Computersystem 188 beinhaltet möglicherweise eine oder auch keine Datenablageeinrichtung 210, welche die Nutzung eines Laufwerks/von Laufwerken 212 beinhaltet, um die hierin beschriebenen Funktionen in einem computerlesbaren Medium 214 abzulegen, auf dem ein oder mehrere Sätze von Befehlen 216 (z. B. Software) abgelegt sind, die eine beliebige oder beliebige mehrere der hierin beschriebenen Methodiken oder Funktionen verkörpern. Die Funktionen können die Verfahren und/oder andere Funktionen des Verarbeitungssystems 186, eine Teilnehmerbenutzereinrichtung und/oder einen Lizenzierungsserver beinhalten, wobei es sich um nicht einschränkende Beispiele handelt. Der eine oder die mehreren Sätze von Befehlen 216 können während ihrer Ausführung durch das Computersystem 188 auch vollständig oder mindestens teilweise innerhalb des Hauptspeichers 192 und/oder innerhalb der Verarbeitungseinrichtung 190 liegen. Der Hauptspeicher 192 und die Verarbeitungseinrichtung 190 bilden ebenfalls für Maschinen zugängliche Ablagemedien. Die Befehle 198, 200 und/oder 216 können weiter über ein Netz 218 über die Netzschnittstelleneinrichtung 202 gesendet oder empfangen werden. Das Netz 218 kann ein Intra-Netz oder ein Inter-Netz sein.
-
Wenngleich das computerlesbare Medium 214 in einer beispielhaften Ausführungsform als einzelnes Medium gezeigt ist, ist der Begriff „für Maschinen zugängliches Ablagemedium” so aufzufassen, dass er ein einzelnes Medium oder mehrere Medien beinhaltet (eine zentrale oder eine dezentralisierte Datenbank und/oder assoziierte Cache-Speicher und Server als nicht einschränkende Beispiele), die den einen oder die mehreren Sätze von Befehlen 216 ablegen. Der Begriff „für Maschinen zugängliches Ablagemedium” ist auch so aufzufassen, dass er beliebige Medien beinhaltet, die fähig sind, einen Satz von Befehlen 198, 200 und/oder 216 zur Ausführung durch die Maschine abzulegen, zu codieren oder zu übermitteln, und die bewirken, dass die Maschine eine beliebige oder beliebige mehrere der hierin offenbarten Methodiken durchführt. Der Begriff „für Maschinen zugängliches Ablagemedium” ist demgemäß so aufzufassen, dass er Halbleiterspeicher, optische lind magnetische Medien und Trägerwellensignale beinhaltet, jedoch nicht darauf eingeschränkt ist.
-
Die hierin offenbarten Ausführungsformen können in Hardware und in Befehlen, die in Hardware abgelegt sind, verkörpert sein und liegen möglicherweise, wobei es sich um nicht einschränkende Beispiele handelt, in einem Random Access Memory (RAM), einem Flashspeicher, einem Read Only Memory (ROM), einem Electrically Programmable ROM (EPROM), einem Electrically Erasable Programmable ROM (EEPROM), in Registern, auf einer Festplatte, einer Wechselfestplatte, einer CD-ROM oder einem computerlesbaren Medium in irgendeiner anderen aus dem Stand der Technik bekannten Form vor. Ein beispielhaftes Ablagemedium ist an den Prozessor gekoppelt, sodass der Prozessor Informationen auf dem Ablagemedium lesen und das Ablagemedium mit Informationen beschreiben kann. Alternativ kann das Ablagemedium fest in den Prozessor integriert sein. Der Prozessor und das Ablagemedium können sich in einer anwendungsspezifischen integrierten Schaltung (ASIC) befinden. Die ASIC kann sich in einem Remote-Endgerät befinden. Alternativ können sich der Prozessor und das Ablagemedium als separate Komponenten in einem Remote-Endgerät, in einer Basisstation oder auf einem Server befinden.
-
Es wird auch angemerkt, dass die in beliebigen der beispielhaften Ausführungsformen hierin beschriebenen Ablaufschritte beschrieben werden, um Beispiele bereitzustellen und eine Erörterung zu ermöglichen. Die beschriebenen Abläufe sind auch in zahlreichen anderen statt nur in den veranschaulichten Reihenfolgen durchführbar. Des Weiteren können Abläufe, die als einzelner Ablaufschritt beschrieben werden, in der Praxis auch in etlichen unterschiedlichen Schritten durchgeführt werden. Zusätzlich können ein oder mehrere in den beispielhaften Ausffürungsformen erörterte Ablaufschritte kombiniert werden. Es versteht sich, dass die in den Flussdiagrammen veranschaulichten Ablaufschritte auf zahlreiche unterschiedliche Arten modifiziert werden können, die sich für den Fachmann ohne Weiteres ergeben. Es verstünde sich für den Fachmann auch, dass Informationen und Signale unter Nutzung beliebiger einer Vielzahl unterschiedlicher Technologien und Techniken dargestellt werden können. Daten, Befehle, Kommandos, Informationen, Signale, Bits, Symbole und Chips, auf die in der obigen Beschreibung gegebenenfalls Bezug genommen wird, können durch Spannungen, Ströme, elektromagnetische Wellen, Magnetfelder oder -partikel, optische Felder oder Partikel oder beliebige Kombinationen davon dargestellt sein, wobei es sich um nicht einschränkende Beispiele handelt.
-
Die vorangehende Beschreibung der Offenbarung wird bereitgestellt, um den Fachmann zu einer Anfertigung gemäß der Offenbarung oder zu ihrer Nutzung zu befähigen. Verschiedene Modifikationen der Offenbarung werden sich für den Fachmann ohne Weiteres ergeben, und die allgemeinen, hierin definierten Prinzipien können auf andere Variationen angewendet werden, ohne vom Gedanken oder vom Schutzbereich der Offenbarung abzuweichen. Daher soll die Offenbarung nicht auf die hierin beschriebenen Beispiele und Ausführungen beschränkt sein, sondern ihr soll der weitestmögliche Schutzbereich zukommen, der mit den Prinzipien und den Neuheitsmerkmalen, die hierin offenbart werden, vereinbar ist.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- „WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web” von Alan B. Johnston und Daniel C. Burnett (2012 Digital Codex LLC) [0002]
- http://www.w3c.org [0003]
- http://www.ietf.org [0003]
