Besehreibung

Die Erfindung betrifft ein Verfahren zum Führen einer Audio- und/oder Videokonferenz, bei der eine Mehrzahl von Endgeräten über ein Datennetz mit einer zentralen Konfe ^¬ renzsteuereinrichtung gekoppelt ist. Zumindest ein vorbestimmtes Endgerät der Endgeräte umfasst eine Datenverarbeitungseinrichtung, welche durch Betrieb einer Anwendung (Applikation) , insbesondere einer Browser- Anwendung (Browser-Applikation) das Endgerät in die Lage versetzt, an der Konferenz teilzunehmen. Typischerweise ist ein solches vorbestimmtes Endgerät ein Personalcomputer mit einer eingebauten Kamera und einem eingebauten Mikrofon (oder Kamera und Mikrofon angekoppelt) und einem Bildschirm sowie einem Lautsprecher (oder angekoppelt) . Die Datenverarbeitungseinrichtung kann genauso ein entsprechend ausgerichtetes Tablet-Computergerät , ein Smartphone oder dergleichen tragbares Endgerät sein. Mithilfe des Browsers ist der Personalcomputer (oder das sonstige Gerät) konferenzfähig: unter Einsatz der Kamera werden Bilder aufgenommen, unter Einsatz des Mikrofons Sprachäußerungen erfasst. Auf dem Bildschirm wird das eigene Bild angezeigt und/oder werden die Bilder von anderen Teilnehmern angezeigt, über das Mikrofon erfolgt eine Sprachausgabe.

Bisher ist es üblich, dass mehrere Teilnehmer (Clients) mithilfe ihres Browsers an der zentralen Konferenz Steuereinrichtung anmelden, die sich typischerweise in einer Cloud befindet. Dies wird hier exemplarisch anhand der FIG. 1 erläutert.

Die FIG. 1 zeigt ein Unternehmensnetz 10, in dem einzelne Clients EP 1, EP 2 und EP 3 (Webrtc-Browser, Net z-Echt zeit ^¬ gesteuerte Browser) gemeinsam eine Konferenzschaltung wünschen und sich hierbei in einer öffentlichen Cloud (Public Cloud) 12 an der zentralen

Konferenzsteuereinrichtung K-A anmelden, wo eine Konferenz- Applikation (Konferenz-Anwendung) unter Webrtc läuft. Die Anmeldung erfolgt über Signalisierungspfade 14, die in FIG. 1 mit durchgezogenen Linien gezeigt sind. Die Signalisierung erfolgt also von den einzelnen Clients bzw. der Browser EP 1, EP 2, EP 3 zur Konferenz-Applikation K-A. Die Konferenz-Applikation K-A stellt nun eine Ressource zur Verfügung, über die die Audio- und/oder Videokonferenz verlaufen kann. Diese Ressource wird als MediaServer bezeichnet, teilweise auch als MediaNode, und ist in FIG. 1 mit „MS", für MediaServer, abgekürzt. Die einzelnen Audio- und Videodatenpakete werden über die strichliert gezeichneten Datenleitungen 16 an den MediaServer MS übermittelt, von diesem gemischt und zur Bereitstellung der Audio- und/oder Videokonferenzdaten an die einzelnen Clients wieder zurückgesandt. Anstelle eines Mischens kann auch eine „Selektion" erfolgen (also eine Auswahl aus den empfangenen Audio- oder Videodatenkanälen mit Weiterleitung der empfangenen Datenströme and die einzelnen Clients, zwecks Aufbereitung der Datenströme in den Clients selbst, die dann als Selective Forwarding Unit (SFU) bezeichnet werden) . Beispielsweise kann eine jeweils sprechende Person angezeigt werden, und die stumm bleibenden Personen werden nicht ausgewählt, sondern herausgefiltert. Nachteilig an einem Vorgehen wie gemäß FIG. 1 ist, dass die Audio- und Videodaten zum Zwecke der Konferenzschaltung das Unternehmensnetz 10 verlassen. Dadurch kann der sichere Datenaustausch durchaus gefährdet sein. Überdies sind für die Datenübertragung mehr Ressourcen notwendig, als wenn sie innerhalb eines Netzes erfolgen würde.

Aus der US 2014/0122600 AI ist ein Konferenzserver bekannt, der die Aufgabe eines Mischens der Audio- bzw. Videodaten übernimmt. Die einzelnen Browser, welche unter JavaScript laufen, verfügen über eine entsprechende Fähigkeit, an der Konferenz teilzunehmen, nicht aber über einen eigenen Mischer . Die EP 1 014 666 AI offenbart ein Verfahren zum Realisieren von Multipunktverbindungen (also Konferenzschaltungen) zwischen mehreren Endgeräten eines H.323-

Datenkommunikationsnetzes, bei dem die Konferenzeinheit das Öffnen von Nutzdatenkanälen (also von Audio- und Videodatenkanälen) zwischen den Endgeräten über die Konferenzeinheit veranlasst.

Die EP 1 001 596 A2 beschreibt ein Multimedia-Endgerät für die Telefonie, das selbst Multipunktverbindungen ermöglicht.

In der US 2004/0210637 AI ist das Vorsehen externer Konferenzbrücken ergänzend zu anderen Pfaden beschrieben. Unter dem Computerlink https://Webrtchacks.com/web-audio- conference/ war am 03. April 2017 ein Artikel erhältlich, aus dem das Prinzip zu erfahren war, dass ein Browser die Rolle einer zentralen Konferenzsteuereinrichtung übernimmt, um lokale Audio-Konferenzen zu führen. Der Artikel nennt dies eine „Poor-Man' s-Konferenz-Lösung" , da kein Server verwendet wird. Aus dem Artikel ist nicht bekannt, wie eine solche Audio-Konferenz zustande kommen kann.

Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren zum Führen einer Audio- und/oder Videokonferenz bereitzustellen, welches vorzugsweise mittels Clients erfolgt, die über eine Anwendung, insbesondere Browser- Anwendung verfügen, und wobei bei dem Verfahren eine möglichst effiziente Nutzung der Datennetze und/oder eine möglichst optimale Sicherheit beim Austausch von Audio- und/oder Videodaten (Nutzdaten) gegeben ist.

Die Aufgabe wird in einem Aspekt durch ein Verfahren nach Anspruch 1 gelöst, in anderen Aspekten durch ein Computerprogrammprodukt nach Anspruch 8, nach Anspruch 9 und nach Anspruch 10.

Das erfindungsgemäße Verfahren zum Führen einer Audio- und/oder einer Videokonferenz, bei der eine Mehrzahl von Endgeräten über ein Datennetz mit einer zentralen Konfe ^¬ renzsteuereinrichtung gekoppelt ist, und wobei zumindest ein erstes Endgerät eine Datenverarbeitungseinrichtung umfasst, welche durch Betrieb einer Anwendung, insbesondere einer Browser-Anwendung, das Endgerät in die Lage versetzt, an der Konferenz teilzunehmen, hat die erfindungsgemäße Eigenschaft, dass ein vorbestimmtes Endgerät des zumindest einen ersten Endgeräts aufgrund von Steuerbefehlen (Signalisierung) durch die zentrale

Konferenzsteuereinrichtung zumindest bei Erfülltsein eines vorbestimmten Kriteriums Audio- und/oder Videodatenströme (also Nutzdatenströme) von anderen Endgeräten empfängt und a) mittels der Anwendung, insbesondere Browseranwendung mischt (insbesondere auch mit von an dem ersten Endgerät selbst generierten Audio- und/oder Videodatenströmen) und in gemischter Form an die anderen Endgeräte zurückgibt und/oder

b) eine Auswahl der empfangenen Audio- und/oder Videodaten und von den von dem zumindest einen ersten Endgerät generierten Audio- und/oder Videodaten an die anderen Endgeräte weitergibt.

Die Erfindung geht somit von dem Prinzip ab, einen (zentra ^¬ len oder verteilten) MediaServer außerhalb der Clients zu verwenden, was üblicherweise bei zentralen Konferenzen der Fall ist; vielmehr fungiert einer der Clients (also das vorbestimmte Endgerät des zumindest einen ersten Endgeräts) selbst als MediaServer oder MediaNode, was normalerweise nur in konferenzserverlosen Konferenzmethoden der Fall ist. Dadurch kann der Datenaustausch zwischen den einzelnen Browsern bzw. den zugehörigen Endgeräten erfolgen, ohne je ^¬ doch auf die Vorteile einer zentralen Konferenzsteuerein ^¬ richtung (mit entsprechender Konferenzraum User Experience, User Authenticat ion, etc.) verzichten zu müssen. Befinden sich beispielsweise sämtliche Endgeräte innerhalb desselben Unternehmensnetzes, müssen daher die sicherheitsempfindlichen Audio- und/oder Videodaten das Unternehmensnetz nicht verlassen. Wenn nämlich sonst im Webrtc Standard die Audio- und Videodaten zwischen Clients und einem zentralem Webrtc Konferenzserver verschlüsselt übertragen werden, so müssen beispielsweise die Audiopakete vom Konferenzserver (in der Cloud) entschlüsselt werden, um gemischt werden zu können, um anschließend wieder ver ^¬ schlüsselt an die Clients gesendet werden zu können. D.h. volle „Ende zu Ende Vertraulichkeit" ist oft nicht gegeben. Dadurch ist es ersichtlich, dass es aus Gründen der Ver ^¬ traulichkeit vorteilhaft sein kann, die Mediendaten lokal im LAN zu halten. Weitere Vorteile sind die signifikante Reduzierung der benötigten WAN Bandbreite, also der Band ^¬ breite zwischen Standort/Unternehmensnetz/Clients und dem Datacenter des Cloud Diensteanbieters der Webrtc Konfe ^¬ renzlösung .

Die Anwendung ist vorzugsweise eine Webrtc (Web Real-Time Control ) -Browseranwendung, also eine net zecht zeitgesteuerte Browseranwendung. Es kann somit auf dem Vorhandensein der Webrtc-Technologie aufgebaut werden. Das eine vorbestimmte Endgerät des zumindest einen Endgeräts muss lediglich mit einem geeigneten Anwendungs-Plug-In ausgestattet werden. Ein Anwendungs-Plug-In ist hier nicht mit Browser-Plug-In zu verwechseln, denn Webrtc Browser (z.B. Google Chrome®, oder Mozilla Firefox®, etc.) benötigen per Definition in der W3C Webrtc Standardisierung (World Wide Web Consortium) keine Browser-Plug-ins, zumindest nicht für die Basis Webrtc Funktionalität.

In einer Variante empfängt das eine des zumindest einen ersten Endgeräts Audio- und/oder Videodatenströme von allen anderen Endgeräten und mischt diese oder unterzieht diese einer Auswahl. Es wird somit die gesamte Konferenz prinzipiell von dem vorbestimmten einen ersten Endgerät im Hinblick auf Nutzdatenströme unterstützt. Weiter vorzugsweise ist hierbei vorgesehen, dass alle Audio- und/oder Videodatenströme ausschließlich über das vorbestimmte erste Endgerät laufen, dass also keine parallelen Nutzdatenströme mehr vorgesehen sind. Auf diese Weise kann die Sicherheit bei geeigneter Lage der Clients bzw. deren Browser in einem geschlossenen Netz (beispielsweise dem Unternehmensnetz) gewährleistet werden.

Bei der zweiten Variante empfängt das eine des zumindest einen ersten Endgeräts Audio- und/oder Videodatenströme von nur einer Teilgruppe der anderen Endgeräte und mischt diese oder unterzieht diese einer Auswahl. In diesem Falle kann beispielsweise eine Nebenkonferenz geführt werden: Diejenigen Teilnehmer, die an Endgeräten innerhalb eines Unternehmensnetzes sitzen, können gesondert kommunizieren, um sich beispielsweise im Hinblick auf ihr Verhalten gegenüber einem Teilnehmer außerhalb des

Unternehmensnetzes, mit dem verhandelt wird, abzusprechen. Auch hier bleiben dann die sicherheitsrelevanten Daten innerhalb des geschlossenen Netzes, also des Unternehmensnetzes .

Somit ist bevorzugt vorgesehen, dass das vorbestimmte Kriterium, bei dessen Erfülltsein die zentrale Konferenz ^¬ steuereinrichtung überhaupt erst das vorbestimmte Endgerät des zumindest einen ersten Endgeräts zum Empfangen und Mischen/Auswahltreffen bringt, beinhaltet, dass diejenigen anderen Endgeräte, von denen Audio- und/oder Videodatenströme empfangen werden, in einem gemeinsamen Lokalbereichsnetzwerk, LAN, Local Area Network, miteinander gekoppelt sind.

Bei einer bevorzugten Ausführungsform der Erfindung muss sich jedes Endgerät zur Teilnahme an der Konferenz bei der zentralen Konferenzsteuereinrichtung anmelden. Das vorbestimmte Endgerät übermittelt (bei einer solchen Anmeldung) oder übermittelte (bei einer früheren Erstanmeldung) an die zentrale Konferenzsteuereinrichtung die Information, dass es in der Lage ist, Audio- und/oder Videodatenströme zu empfangen und a) zu mischen und b) einer Auswahl zu unterziehen, und dass das vorbestimmte Kriterium beinhaltet, dass eine solche Information übermittelt wurde. Auf diese Weise kann die zentrale Konferenzsteuereinrichtung generell ausgelegt sein, ihrerseits die Nutzdatenströme zu mischen oder einer Selektion zu unterziehen. Nur, wenn das eine Endgerät mit dem entsprechend eingerichteten Browser meldet, dass es über eine geeignete Browsererweiterung verfügt, um selbst die Konferenz zu führen, wird diese Aufgabe an den entsprechenden Browser übertragen.

In einem anderen Aspekt der Erfindung wird ein Computerprogrammprodukt zum Bereitstellen oder Erweitern (letzteres in Form eines Plug-ins) einer Anwendung, insbesondere Browseranwendung auf einer ersten Datenverarbeitungseinrichtung bereitgestellt. Dieses

Computerprogrammprodukt ist ausgelegt, der ersten Datenverarbeitungseinrichtung die Fähigkeit zu verleihen, Audio- und/oder Videodaten von zumindest einer zweiten Datenverarbeitungseinrichtung zu empfangen und einerseits von der zweiten empfangene und andererseits von der ersten Datenverarbeitungseinrichtung bereitgestellte und/oder einer anderen zweiten Datenverarbeitungseinrichtung empfangene Audio- und/oder Videodaten zu mischen und/oder einer Auswahl zu unterziehen und die gemischten und/oder ausgewählten Audio- und/oder Videodaten an die zumindest eine zweite Datenverarbeitungseinrichtung weiterzuleiten. Dieses Computerprogrammprodukt sorgt somit für das Laufen eines Browsers, welcher die oben beschriebenen Eigenschaften aufweist, d. h. der zentralen

Konferenzsteuereinrichtung die Aufgabe des Mischens und/oder Vornehmens einer Auswahl aus den Audio- und/oder Videodaten abzunehmen. Insbesondere kann die

Browseranwendung durch das Computerprodukt in die Lage versetzt werden, die eingängliche Meldung an die zentrale Konferenzsteuereinrichtung zu geben, dass die Konferenzfähigkeit des Browsers gegeben ist.

In einem weiteren Aspekt der Erfindung wird ein Computerprogrammprodukt zum Bereitstellen oder Erweitern (in Form eines Plug-in) einer Anwendung, insbesondere Browseranwendung, auf einer zweiten

Datenverarbeitungseinrichtung bereitgestellt, das ausgelegt ist, der zweiten Datenverarbeitungseinrichtung die Fähigkeit zu verleihen, Steuersignale mit einer zentralen Datenverarbeitungseinrichtung auszutauschen und Audio- und/oder Videosignale an eine erste

Datenverarbeitungseinrichtung außerhalb der zentralen Datenverarbeitungseinrichtung zu übermitteln. Dieses Computerprogrammprodukt erlaubt es den selbst nicht konferenzfähigen Browseranwendungen, die konferenzfähige Browseranwendung unter Steuerung der zentralen Datenverarbeitungseinrichtung zu nutzen.

Die Erfindung stellt in noch einem weiteren Aspekt ein Computerprogrammprodukt bereit, welches zum Bereitstellen oder Erweitern (in Form eines Plug-in) eine Anwendung, insbesondere Konferenzschaltungsanwendung, auf einer dritten Datenverarbeitungseinrichtung dient, das ausgelegt ist, der dritten Datenverarbeitungseinrichtung die Fähigkeit zu verleihen, eine Information von einer ersten Datenverarbeitungseinrichtung zu erhalten, welche aussagt, dass diese erste Datenverarbeitungseinrichtung in der Lage ist Audio- und/oder Videodaten von zweiten

Datenverarbeitungseinrichtungen zu empfangen und zu mischen und/oder einer Auswahl zu unterziehen und die gemischten und/oder ausgewählten Audio- und/oder Videodaten an weitere Datenverarbeitungseinrichtungen weiterzuleiten, wobei die dritte Datenverarbeitungseinrichtung bei Erhalt einer solchen Information die Aufgabe eines solchen Mischens und/oder einer Auswahl Unterziehens an die erste Datenverarbeitungseinrichtung, welche die Information übersandt hat, überträgt.

Nachfolgend werden bevorzugte Ausführungsformen der Erfindung unter Bezug auf die Zeichnung näher beschrieben, in der

FIG. 1 eine Anordnung zum Führen einer Konferenz veranschaulicht, die ein Verfahren gemäß dem Stand der Technik umsetzt,

FIG. 2 eine Anordnung zum Führen einer Konferenz veranschaulicht, die das erfindungsgemäße Verfahren umsetzt,

FIG. 3 Details zu dem bei dem erfindungsgemäßen

Verfahren verwendeten konferenzfähigen Webrtc- Browser und dem Datenfluss von und zu diesem Browser veranschaulicht, FIG. 4 einen Flussablauf des Austausche von Nachrichten gemäß dem erfindungsgemäßen Verfahren zeigt.

Bei dem anhand von FIG. 2 veranschaulichten erfindungsgemäßen Verfahren wird anstelle eines normalen Webrtc-Browsers ein solcher Webrtc-Browser EP 1K mit einer Konferenzfähigkeit (Konferenz-Ressource) bereitgestellt. Diese Konferenz-Ressource wird durch eine zentrale Anwendung (Konferenzsteuer-Applikation) gesteuert, die sich auf das Cloud-Webrtc bezieht. Im Unternehmensnetz 10 befinden sich weitere Browser EP 2 und EP 3. In einer Cloud (Datacenter) 12 befindet sich die Konferenzsteuer- Applikation K-A. Wie auch im Stand der Technik gibt es Signalisierungspfade 14 zwischen den einzelnen Browsern EP 1K, EP 2 und EP 3 zu der Konferenz-Applikation K-A. Diese Signalisierungspfade werden jedoch nicht durch entsprechende Nutzdatenpfade außerhalb des

Unternehmensnetzes ergänzt. Insbesondere gibt es keinen MediaServer MS bzw. wird für das beschriebene Szenario kein zentraler MediaServer benötigt. Stattdessen übernimmt der Browser EP 1K die Rolle eines MediaServers oder MediaNodes, und die Nutzdatenströme (Audio- und/oder Videodaten) werden über Signalpfade 20 von den einzelnen weiteren Browsern EP 2 und EP 3 an den konferenzfähigen Browser EP 1K übermittelt, dort gemischt und über dieselben Pfade in gemischter Form wieder zurückgesandt. Alternativ zum Mischen oder zusätzlich kann vorgesehen sein, dass seitens des konferenzfähigen Browsers EP 1K eine Selektion erfolgt, dass beispielsweise immer dann, wenn ein Teilnehmer gerade spricht, dessen Bild auf den Browsern dargestellt wird, und sonst nicht. Der Vorteil des Vorgehens gemäß FIG. 2 besteht darin, dass die Nutzdatenströme innerhalb des Unternehmensnetzes 10 bleiben. Es ist daher für eine höhere Datensicherheit gesorgt. Des Weiteren wird weniger Band ^¬ breite zwischen Unternehmensnetz 10 und Cloud-Datacenter 12 benötigt . Der Aufbau des konferenzfähigen Browsers EP 1K ist nachfolgend unter Bezug auf FIG. 3 näher erläutert.

Zunächst verfügt er über eine Client-Applikation, zum Beispiel eine JavaScript-Client-Applikation 22, die ihm die Fähigkeit zur Kommunikation mit der zentralen Konferenz ^¬ steuer-Applikation K-A verleiht. Er kann daher die Rolle eines Clients einnehmen. Als Plug-in oder eingebaut in die Client-Applikation ist eine Konferenz-Client-Applikation 24 vorgesehen, etwa auch in JavaScript, die dem Client die Fähigkeit verleiht zu signalisieren, dass er konferenzfähig ist. Während die Client-Applikation 22 generell ein Webrtc- Client-Signaling mit der Konferenz-Applikation K-A verantwortet (siehe Bezugszeichen „SC" „Signaling Client") , verantwortet die weitere Applikation 24, dass eine zusätzliche Signalisierung des Konferenz-Clients erfolgt („Signalisierung Konferenz-Client", SKC) , welche beispiels ^¬ weise auch die Konferenzschaltbefehle der zentralen Konfe ^¬ renzsteuereinrichtung entgegennimmt (Rolle MediaServer im EPIK) .

Der Browser 25 umfasst eine Webschnittstelle, insbesondere eine net zecht zeitgesteuerte Schnittstelle 26, auf Englisch: Webrtc API, Web Real-Time Control Application Programming Interface. Er umfasst eine Einheit zum Verwalten der Sitzung und der Konferenz („Session Management and Conference Management") 28. Ferner benötigt er zum Kodieren und Dekodieren eine entsprechende Stimmeinheit 30 („Voice Engine" mit entsprechenden Codecs) und dasselbe für Videodaten in der Einheit 32 („Video Engine" mit entsprechenden Codecs) . Beispielhafte Codecs sind G.711, Opus, H.264, VP8 etc. Außerdem gibt es eine Einheit 34 zum Mischen bzw. zum Schalten (Auswählen, Weiterleiten) . Die Übertragungsschnittstelle (Transportschnittstelle) 36 sorgt für die Weiterleitung der Daten, und zu den weiteren Browsern EP 2 und EP 3 hin gibt es eine Client /Browser OS- Schnittstelle .

Die Browser EP 2 und EP 3, wobei EP für „end point" also Telekommunikationsteilnehmer, steht, tauschen mit der Konferenz-Applikation K-A ebenfalls entsprechende Signale SC aus. Durch die Signalisierung SKC entscheidet die Konferenz-Applikation, dass der Browser EP 1K die Konferenz medienmäßig führen soll. In Reaktion darauf übersenden die Browser EP 2 und EP 3 ihre Nutzdaten N2 und N3 an die Einheit 34, wo diese Nutzdaten N2 und N3 mit entsprechenden, von den Einheiten 30 und 32 erzeugten Nutzdaten Nl gemischt werden oder einer Auswahl unterzogen werden, wobei die gemischten Daten als Daten M2 und M3 zurückgesendet werden bzw. die ausgewählten („geswitchten" ) Daten als SW2 und SW3 zurückgesendet werden. Der in FIG. 2 gezeigte Signalpfad 20 ist hier in die beiden Pfade 20a für die Richtung zur Einheit 34 hin und 20b für die Richtung von der Einheit 34 zu den Browsern EP 2 und EP 3 weg aufgeteilt .

Im Einzelnen kann der Austausch von Daten wie nachfolgend erläutert durchgeführt werden:

Die FIG. 4 zeigt die entsprechenden Signale: Zunächst wird in einem Schritt S 10 durch den Browser EP 1K die Anfrage an die Konferenzsteuerapplikation K-A gesendet, dem Konferenzraum beizutreten bzw. diesen zu starten (siehe „EP 1K JoinRequest") in FIG. 4. Teil des Inhalts der Signa- lisierung in Schritt S10 ist beispielsweise die Client EP 1 IP Adresse und Port, die unterstützten Codecs sowie weitere konferenzbezogene Fähigkeiten des Clients 1 (engl. „Con- fCaps" = Konference Capabilit ies ) . Die Konferenzapplikat ion K-A erkennt aufgrund der Signalisierung, dass der Cli- ent/Browser EP 1K die Fähigkeit besitzt, lokale Browserkon ^¬ ferenzen zu unterstützen, inklusive Konferenz- Detailfähigkeiten. Zu den signalisierten Konferenz- Detailfähigkeiten (engl. ConfCaps) gehören beispielsweise: 1) Konferenzart (Audiokonferenz, Videokonferenz, Screen Share Konferenz (meist Video), 2) Konferenztyp (Konferenz Mischen, Selective Forwarding Unit, ..), Unterstütze Codecs (G.711, OPUS, H.264, VP 8 , VP 9 , .. ) , Conference Credentials (zur Authent icat ion) .

In dem nächsten Schritt S 12 fragt die Konferenz- Applikation K-A beim Browser EP 1K (in dessen Rolle als „MediaNode") an, eine entsprechende Media Resource im EP 1K zur Verfügung zu stellen (siehe „Conf Create Request" in FIG. 4) . Die IP Adresse und Port des Clients 1 werden in Schritt S12 an die Browser Media Resource mit signalisiert . Der Browser EP 1K antwortet (in seiner Rolle als „MediaSer- ver") in Schritt S 14 mit der Bestätigung, dass er die ge ^¬ wünschte (n) Media Resource (n) zur Verfügung gestellt hat und signalisiert im Rahmen von Schritt S14 die IP Adresse / Port der Webrtc Browser Konferenz Resource. Siehe hierzu in FIG. 4 den Befehl „Conf Create Confirm", der beinhaltet, dass eine Information an die Konferenz-Applikation K-A gesandt wird, dass der Browser EP 1K die Media Resource ge- startet hat bzw. die Konferenz-Ressourcen vorzuhalten. Im Schritt S 16 bestätigt sodann die Konferenzsteuer- Applikation K-A dem Browser EP 1K (in seiner Rolle als „Client / Webrtc Browser") , dass eine Media Resource erzeugt wurde und der Client EP 1K an diese Media Resource senden kann („EP 1K Join Confirm") . Damit ist wie in Schritt S 18 dargestellt, der Anwendungskonferenzraum aktiv, mit einem Teilnehmer (EP 1K) in der Konferenz und der Möglichkeit des Beitritts durch weitere Webrtc-Browser geschaffen.

Im Schritt S 20 fragt der Browser EP 2 an, ob er der Konferenz beitreten kann („EP 2 Join Request") . Der Browser EP Kl (in seiner Rolle als „MediaServer" ) erhält dann in Schritt S 22 den Auftrag von der Konferenzsteuereinrich ^¬ tung, den EP2 in die Konferenz zu schalten (Conf Add Requ ^¬ est) und bestätigt dies seinerseits in Schritt S 24 („Conf Add Confirm") . Daraufhin sendet die Konferenzapplikat ion K- A in Schritt S 26 die Bestätigung an den Browser EP 2, dass der Konferenz mit EP 1K beigetreten wurde. In Analogie zu den Schritten S10, S12, S14, S16 hinsichtlich Austausch der IP und Port Empfangsadressen zwischen Client EP 1K und der Konferenz-Resource (in Client EP 1K) , werden die Empfangs IP-Adressen und -Ports in den Schritten S20, S22, S24 und S26 auch zwischen EP2 und der Conference-Resource (im EP 1K) ausgetauscht.

Entsprechende Schritte S 28, S 30, S 32 und S 34 erfolgen auch beim dritten Browser EP 3. Nach Abschluss der Schritte S 26 bzw. S 34 senden sodann die Browser EP 2 und EP 3 ihre Audio- und Videodaten in den Schritten S 36 und S 38 an die Konferenz-Resource des Browsers EP 1K. Durch den Pfeil S 40 ist veranschaulicht, dass der Browser EP 1K intern (in sei- ner Rolle als Client) selbst seine eigenen Audio- und Videodaten, die mit dem zugeordneten Mikrofon bzw. der zugeordneten Kamera aufgenommen wurden, zum Mischen beiträgt. Der Client EP 1K muss dabei seine lokal erzeigten Mediendaten nicht über das LAN Interface (IP Adresse) an die Medien-Resource des selbigen EP 1K senden, sondern kann dies Browser-intern durchführen. Im Schritt des Mischens S 42 werden die erhaltenen Nutzdaten so gemischt, dass dann entsprechende Daten in den Schritten S 44 am Browser EP 1K selbst ausgegeben werden kann bzw. in den Schritten S 46 und S 48 an die Browser EP 2 und EP 3 übermittelt werden können und dort ausgegeben werden können.

Die in den Figuren bisher gezeigten Browser sind allesamt Konferenzteilnehmer. Die Erfindung ist auch dann anwendbar, wenn bereits eine Konferenz besteht und nur eine Untergruppe in einem Unternehmensnetz eine Nebenkonferenz führen möchte. In diesem Fall benötigt der beantragende U- ser entsprechende Berechtigung und (GUI) Bedienungselemente an seinem Browser Client (z.B. „Split local Conference"), verbunden mit entsprechenden Payload Re- konfigurat ionsaufträgen gesendet über die zentrale Konfe ^¬ renzsteuer-Applikation .