Client Die vorliegende Erfindung betrifft ein computerimplementiertes Verfahren zum sicheren und dynamischen Nachladen von zusätzlicher Software von einem WebRTC-Server in einen WebRTC-Client sowie eine entsprechende Computeranordnung.

WebRTC-Browser Hersteller wie Google oder Mozilla liefern ihre Browser in der Regel mit bestimmten Codecs aus. Zu diesen Codecs gehören beispielsweise Audio-Codecs, beispielsweise G.711 und OPUS, sowie Video-Codecs, wofür VP8 als Beispiel zu nennen ist. Derartige Codecs sind somit integraler Bestandteil dieser webRTC-fähigen Browser.

Für Hersteller von Applikationen für WebRTC ist es jedoch nicht ohne Weiteres möglich, in ihren Projekten zusätzliche Codecs, die in der ursprünglichen Browser-Version noch nicht enthalten waren, auf eine sichere Art und Weise zu integrieren, um damit einen zusätzlichen Nutzen für ihre Kunden zu generieren. Ein Teil des Problems liegt darin, dass derartige zusätzliche Codecs häufig durch ein gewerbliches Schutzrecht geschützt sind und somit nur gegen Zahlung einer entsprechenden Lizenzgebühr erworben und installiert werden können.

Zur Nachinstallation derartiger Codecs wird in der Regel so vorgegangen, dass diese über sogenannte Browser-Plug-ins geladen und anschließend installiert werden können. Bei WebRTC-Browsern bestehen jedoch folgende Nachteile:

- Die Charta von WebRTC bei IETF/W3C sieht vor, dass WebRTC ohne Plug-ins auskommen soll. Dies bedeutet, dass die betreffenden Codecs inhärent im Browser integriert sein sollen, d. h. bereits durch die Browserhersteller fest eingebaut sein sollen.

- Das spezifische Problem von Browserherstellern bei der Erfüllung der obigen Anforderung besteht darin, dass Codecs, für die ein gewerbliches Schutzrecht (oft auch kurz als Intellectual Property Right bzw. IPR bezeichnet) besteht und die deshalb mit Lizenzkosten behaftet sind, nicht mit den kostenlosen Browsern der Hersteller ausgeliefert werden können. - Browser-Plug-Ins stellen ein Sicherheitsrisiko dar, da die Quelle der hierdurch nachinstallierten Codecs nicht sicher kontrolliert werden kann, und sie sind damit auch ein zusätzliches Hindernis hinsichtlich der Akzeptanz von WebRTC- Applikationslösungen bei vielen Kunden.

Das vorstehend am Beispiel von Audio- und Video-Codecs beschriebene Problem der sicheren Nachinstallation von Codecs besteht ganz allgemein auch bei anderer Software, die in einem WebRTC-Client wie z.B. einem Browser - insbesondere WebRTC-Browser - nachinstalliert werden soll.

Der Erfindung liegt somit die Aufgabe zugrunde, diese Nachteile zu beseitigen und ein Verfahren zum sicheren und dynamischen Nachladen von zusätzlicher Software von einem WebRTC-Server in einen WebRTC-Client sowie eine entsprechende Computeranordnung anzugeben.

Diese Aufgabe wird mittels eines Verfahrens gemäß Anspruch 1 sowie mittels einer Computeranordnung gemäß Anspruch 9 gelöst. Zur Lösung dieses Problems tragen außerdem ein entsprechendes Computerprogramm bzw. Computerprogrammprodukt gemäß Anspruch 7 sowie ein maschinenlesbarer Datenträger, auf dem ein entsprechendes Com- puterprogramm gespeichert ist, gemäß Anspruch 8 bei, die ebenfalls als zur Erfindung gehörig anzusehen sind.

Vorteilhafte Weiterbildungen der Erfindung sind Gegenstand der abhängigen Ansprüche. Erfindungsgemäß läuft ein computerimplementiertes Verfahren zum sicheren und dynamischen Nachladen von zusätzlicher Software von einem WebRTC-Server in einen WebRTC-Client in folgenden Schritten ab: Im Zuge des Aufbaus der WebRTC- Verbindung zwischen dem WebRTC-Client und dem WebRTC-Server wird die benötigte Software übertragen, indem hierfür ein WebRTC-Datenkanal verwendet wird. Auf diese Weise ist es möglich, die benötigte Software in sicherer und dynamischer Art und Weise nachzuladen und nachzuinstallieren, ohne auf ein Browser-Plug-In zurückgreifen zu müssen. Der WebRTC-Datenkanal wird übrigens auch als WebRTC-Datachannel bezeichnet. Dieser WebRTC-Datenkanal an sich ist durch IETF W3C standardisiert und setzt auf einer sicheren Übertragung auf Basis von IP/UDP/DTLS/SCTP auf. Gemäß einer vorteilhaften Ausführungsform des erfindungsgemäßen Verfahrens ist die Software für eine Real-Time-Anwendung bestimmt. Insbesondere ist diese Software ein Codec wie beispielsweise ein Audio- oder Video-Codec. Es kann von Vorteil sein, wenn der WebRTC-Datenkanal nach der Übertragung der Software aufrechterhalten und nicht sofort wieder abgebaut wird, um dadurch beispielsweise ein schnelles Nachladen von weiterer benötigter Software ohne Zeitverzug zu ermöglichen. Es kann außerdem vorteilhaft sein, die Software automatisch zum Zeitpunkt des Aufbaus der WebRTC-Verbindung zwischen dem WebRTC-Client und dem WebRTC-Server zu übertragen, so dass ein Benutzer sich um diesen Aspekt nicht eigens kümmern muss. Für das Beispiel eines Telefonanrufs bzw. einer Konferenz kann dies bedeuten, dass der Download eines Audio-Codecs automatisch zum Zeitpunkt des getätigten Telefonanrufs bzw. der getätigten Konferenz erfolgt. Alternativ kann aber auch ein durch einen Benutzer spezifisch getriggerter Download eines Codecs vorgesehen sein. Hierfür wäre dann vorzugsweise ein Installierungsfeld (install button) vorgesehen. Als Bezahlmodell käme hierfür beispielsweise das so genannte "pay as you use" in Frage. Weitere Vorteile kann es bringen, wenn die Software im WebRTC-Client nur temporär geladen und nur während eines vorbestimmten Zeitraums benutzbar bleibt. Dies bedeutet im Fall des vorgenannten Beispiels, dass ein nachgeladener Codec nur für die Nutzung während eines Telefonanrufs bzw. während einer Konferenz zur Verfügung steht und nur so lange genutzt werden kann, bis der WebRTC-Client (insbesondere ein WebRTC- Browser) neu gestartet wird. Diese Vorgehensweise unterstützt ebenfalls das Vergütungsmodell des "pay as you use". Alternativ kann der nachgeladene Codec selbstverständlich auch permanent installiert und benutzbar bleiben, wodurch er auch nach einem Neustart des WebRTC-Clients bzw. des WebRTC-Browsers für die Benutzer zur Verfügung steht. Das erfindungsgemäße Verfahren ist mit Vorteil als Computerprogramm bzw. Computerprogrammprodukt implementiert und kann auf einem maschinenlesbaren Datenträger gespeichert sein. Somit sind diese beiden Ausgestaltungen ebenfalls als zur vorliegenden Erfindung gehörig anzusehen. Eine erfindungsgemäße Computeranordnung enthält einen ersten Computer, auf dem ein WebRTC-Client läuft, der zur Durchführung des vorstehend beschriebenen Verfahrens zum sicheren und dynamischen Nachladen von zusätzlicher Software von einem WebRTC-Server in einen WebRTC-Client geeignet ist. Ferner umfasst die erfindungsgemäße Computeranordnung einen zweiten Computer, der als WebRTC-Server dient und mittels dem die zu übertragende Software so bereitgehalten ist oder zugänglich gemacht wird, dass sie auf Anfrage durch einen WebRTC-Client abgerufen bzw. an diesen über- tragen werden kann. Zur Verbindung dieser beiden Computer ist ein entsprechendes Netzwerk vorgesehen, das notwendigerweise so beschaffen sein muss, dass es einen WebRTC-Datenkanal (zusammen mit der WebRTC-Verbindung zwischen dem RTC- Client und dem WebRTC-Server) bereitstellen kann. Es liegt auf der Hand, dass mit einer erfindungsgemäßen Computeranordnung die gleichen Vorteile erzielt werden können, wie sie im Zusammenhang mit dem erfindungs- gemäßen Verfahren beschrieben wurden.

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 eine schematische Übersicht über eine Ausführungsform eine erfindungsgemäße Computeranordnung, und

Fig. 2 eine schematische Darstellung, wie das erfindungsgemäße Verfahren auf der Grundlage des standardisierten WebRTC-Protocol-Stacks ausgeführt wird.

Die Computeranordnung 10 wiederum umfasst einen ersten Computer 12, einen als WebRTC-Server dienenden zweiten Computer 14 sowie ein Netzwerk 16, das den ersten Computer 12 und den zweiten Computer 14 verbindet und überdies so gestaltet ist, dass es WebRTC-Verbindungen - zu denen auch WebRTC-Datenkanäle gehören - bereitstellen kann. Sobald dies ausgehandelt ist, kann die Software SW von einem Server 14 an den Client im ersten Computer 12 übertragen werden, was durch einen entsprechenden Pfeil symbolisch dargestellt ist. Beim ersten Computer 12 ist schematisch eine CD-ROM 90 als Beispiel für einen Datenträger dargestellt, auf dem ein Computerprogramm bzw. Computerprogrammprodukt 92 gespeichert werden kann, welches wiederum schematisch als Blatt mit Programmcode dargestellt ist. Nach der Installation des Computerprogramms 90 in dem ersten Computer 12 kann ein auf diesem Computer 12 laufender WebRTC-Client in der erfindungsgemä- ßen Weise weiterentwickelt werden, um das erfindungsgemäße Verfahren auszuführen. Zur Erläuterung des erfindungsgemäßen Verfahrens wird nachfolgend davon ausgegangen, dass der WebRTC-Client als WebRTC-Browser (nachfolgend kurz mit "Browser" bezeichnet) vorliegt, der für einen Telefonanruf (kurz "Ruf) einen Audio-Codec von dem WebRTC-Server (nachfolgend kurz "Server") 14 laden möchte, da der standardmäßig im Browser integrierte Audio-Codec (beispielsweise G.711 oder OPUS) als nicht ausreichend angesehen wird. Ein derartiger Audio-Codec mit erweitertem Funktionsumfang basiert beispielsweise auf einem H.264 oder H.265.

Für die Anwendung der vorliegenden Erfindung sind natürlich auch Downloads von Sprach-Codecs wie G.729 zu erwähnen. Gemäß dem folgenden Beispiel wird dem Benutzer auf seiner Benutzeroberfläche (z. B. über den Menüpunkt "Einstellungen") in seinem installierten bzw. benutzten Browser die Option angeboten, zusätzliche Codecs zu laden. Alternativ kann dies auch automatisch erfolgen, wofür als Beispiele die Installation des WebRTC-Clients bzw. -Browsers, der Zeitpunkt des ersten Telefonanrufs, etc. zu nennen sind.

Erfindungsgemäß wird zunächst eine Signalisierung für den Verbindungsaufbau und für den Aufbau der entsprechenden Fähigkeiten des Browsers durchgeführt. Dies ist in der linken Säule von Fig. 2 dargestellt. Da die hier verwendeten Bezeichnungen und Abkürzungen an sich bekannt sind, wird auf eine detaillierte Beschreibung verzichtet. Diese linke Säule sowie die rechts daneben dargestellte rechte Säule sind Teil eines so genannten WebRTC-Protokoll-Stacks. Nach der Signalisierung wird eine WebRTC- Nutzdatenverbindung von einem Browser zu einer vordefinierten Serveradresse aufgebaut, wobei hier das WebRTC-Session-Signalling verwendet wird. Der Aufbau des WebRTC-Datenkanals und die Aushandlung der Eigenschaften dieses Datenkanals zwi- sehen dem Browser und der Server-Applikation wird dabei beispielsweise via SDP (Session Description Protokoll) Offer/Answer-Methode durchgeführt. Beim Standard-WebRTC wird ein SCTP (Stream Control Transmission Protocol)-Kanal verwendet, der über die DTLS (Datagramm Transport Layer Security) gesichert ist, das ein Verschlüsselungsprotokoll darstellt. Über diesen sicheren, dynamisch zwischen dem Browser und dem Server ausgehandelten Datenkanal wird das Codec-File sicher an den Browser übertragen. Auf der Seite des Browsers erfolgt die Installation des Codecs über das Browser-API (API = Application Programming Interface). Dabei kann das Browser-API spezifisch für den Browser-Hersteller oder aber auch standardisiert sein. Diese Etablierung des WebRTC- Datenkanals und die Verwendung für die Übertragung des Codecs stellt im Grundsatz das erfindungsgemäße Verfahren dar und ist in der rechten Säule von Fig. 2 durch einen in gestrichelten Linien dargestellten Kasten bezeichnet. Es ist aus dem gestrichelten Kasten ersichtlich, dass der Datenkanal SCTP nutzt, welches wiederum durch DTLS gesichert wird. Diese Protokolle gehören zum standardisierten WebRTC, weshalb sie nicht ausführlich beschrieben und erläutert zu werden brauchen. Die eigentliche Kommunikation unter Verwendung der nachgeladenen Software bzw. des nachgeladenen Codecs erfolgt dann über den linken Teil der rechten Säule in Fig. 2, nämlich über die RTC-Peer-Connection und SRTP (Secure Real-Time Transport Protocol), also den "eigentlichen" Nutzkanal für die Übertragung der Daten, insbesondere in Mediendaten wie Audio- und/oder Videodaten, die über eine eigene WebRTC-Verbindung übertragen werden.

Nach erfolgreichem Download und lokaler Installation dieses zusätzlichen Codecs kann die Datenverbindung zwischen dem Endpunkt bzw. dem Browser und dem Server abgebaut werden. Alternativ kann der WebRTC-Datenkanal auch aufrechterhalten bleiben, um beispielsweise weitere Codecs oder andere Software schneller nachladen zu können. Ab diesem Zeitpunkt kann der Browser für WebRTC-Audioanwendungen und/oder WebRTC- Videoanwendungen wie Telefonanrufe oder Konferenzen sowohl die im Browser bereits integrierten, nicht mit Schutzrechten behafteten Codecs (z. B. G.711 , OPUS, VP8) als auch die wie eben beschriebenen zusätzlich nachgeladenen Codecs (die der Browserhersteller bei der Erstellung des Browsers nicht in den Browser integrieren konnte, weil sie mit gewerblichen Schutzrechten und entsprechenden Lizenzkosten behaftet sind) nutzen. Je nach Anwendung kann vorgesehen sein, dass der Codec-Download automatisch zum Zeitpunkt eines getätigten Rufes bzw. einer eingeleiteten Konferenz erfolgt. Es kann jedoch auch vorgesehen sein, den Codec-Download auf ausdrückliche Anforderung durch den Benutzer einzuleiten und durchzuführen. Falls der nachgeladene Codec permanent installiert wird, steht er auch nach einem Neustart des Browsers weiterhin zur Verfügung. Für diese Verwendungsweise kann es beispielsweise zu relativ hohen Lizenzzahlungen für den betreffenden Codec kommen. Somit könne es einen Vorteil bringen, wenn der nachgeladene Codec nur temporär geladen (d. h. im RAM gehalten) wird und für die Nutzung nur während eines Rufes bzw. während einer Konferenz zur Verfügung steht oder nur so lange benutzbar bleibt, bis der Browser neu gestartet wird. Hiermit ist beispielsweise ein anderes Gebührenmodell möglich, bei dem nur die konkrete Nutzung zu bezahlen ist. Bei seltenem Einsatz von Codecs kann dies einen großen Vorteil für Kunden darstellen. Zusammengefasst ist festzuhalten, dass erfindungsgemäß eine Erweiterung eines WebRTC-Clients wie beispielsweise eines Browsers mittels nachgeladener Software (z. B. ein Codec) möglich ist, mit der eine Konfigurierung dieses WebRTC-Clients möglich wird. Mittels des erfindungsgemäßen Verfahrens wird diese nachgeladene Software nicht nur aus einer sicheren Quelle - d. h. dem WebRTC-Server - geholt, sondern auch über einen sicheren Weg in Form eines WebRTC-Datenkanals übertragen. Somit ist die Erweiterung der Funktionalität des WebRTC-Clients auf sehr sichere Weise möglich. Da diese Erweiterung jederzeit zur Verfügung steht und auch beliebig änderbar ist, ist die Erweiterung auch sehr dynamisch.

Die vorliegende Erfindung kann auch bei weiteren Anwendungen wie Instant Messaging oder E-Mail-Verkehr eingesetzt werden.

Es ist festzuhalten, dass die unter Bezug auf die dargestellten Ausführungsformen beschriebenen Merkmale der Erfindung, wie beispielsweise die Art und Ausgestaltung einzelner Komponenten der Computeranordnung oder die Reihenfolge einzelner Schritte des Verfahrens, 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 = Computeranordnung

12 = erster Computer

14 = zweiter Computer/WebRTC-Server

16 = Netzwerk

90 = Datenträger

92 = Computerprogramm

SW = Software