DE102012013336B4 - Aushandeln einer kontinuierlichen multi-stream-präsenz - Google Patents

Aushandeln einer kontinuierlichen multi-stream-präsenz Download PDF

Info

Publication number
DE102012013336B4
DE102012013336B4 DE102012013336.7A DE102012013336A DE102012013336B4 DE 102012013336 B4 DE102012013336 B4 DE 102012013336B4 DE 102012013336 A DE102012013336 A DE 102012013336A DE 102012013336 B4 DE102012013336 B4 DE 102012013336B4
Authority
DE
Germany
Prior art keywords
window
windows
identifier
group
offer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE102012013336.7A
Other languages
English (en)
Other versions
DE102012013336A1 (de
Inventor
Adel Mostafa
Trung Tran
William Janning
Patrick Ma
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Avaya Inc
Original Assignee
Avaya Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Avaya Inc filed Critical Avaya Inc
Publication of DE102012013336A1 publication Critical patent/DE102012013336A1/de
Application granted granted Critical
Publication of DE102012013336B4 publication Critical patent/DE102012013336B4/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1827Network arrangements for conference optimisation or adaptation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/478Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/485End-user interface for client configuration
    • H04N21/4858End-user interface for client configuration for modifying screen layout parameters, e.g. fonts, size of the windows
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/141Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/147Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Verfahren, das Folgendes umfasst: Generieren eines Angebots durch mindestens einen Prozessor einer Client-Einrichtung für eine Multimediakommunikationssitzung, wobei das Angebot eine Fensterinhaltsspezifikation für mindestens ein Fenster umfasst; Liefern des Angebots durch den mindestens einen Prozessor an ein Netzwerk zur Übertragung durch den mindestens einen Prozessor; Erhalten einer Antwort auf das Angebot und Erhalten eines Videoinhalts durch den mindestens einen Prozessor zum Anzeigen des mindestens einen Fensters, wobei die Fensterinhaltsspezifikation eine Gruppenkennung höherer Priorität umfasst, der eine höhere Priorität zugewiesen ist als einer Gruppenkennung mit niedrigerer Priorität, wobei die höhere Priorität anzeigt, dass Auflösungsreduktionen auf einen Inhalt zur Anzeige in Fenstern der Gruppe mit niedrigerer Priorität angewendet werden sollten, bevor Auflösungsreduktionen auf einen Inhalt zur Anzeige in Fenstern der Gruppe mit höherer Priorität angewendet werden, und wobei die Inhaltsspezifikation eine erste Bandbreitengrenzenkennung umfasst, die eine Grenze zum Reduzieren der Auflösung von Videoinhalt zur Anzeige in Fenstern der Gruppe mit niedrigerer Priorität umfasst.

Description

  • QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
  • Die vorliegende Anmeldung beansprucht die Priorität der am 8. Juli 2011 eingereichten vorläufigen US-Patentanmeldung Nr. 61/505,911 mit dem Titel MECHANISM TO NEGOTIATE MULTI-STREAM BASED CONTINUOUS PRESENCE (CP) VIDEO IN SIP FOR A REQUIRED USER EXPERIENCE (UX).
  • ALLGEMEINER STAND DER TECHNIK
  • Videoconferencing ist ein sehr mächtiger Kommunikationsmodus, der gestattet, dass sich Menschen an entfernten Orten befinden, einander in Echtzeit sehen und miteinander sprechen können. In der Regel wird eine Videokonferenzsitzung durch eine Client-Einrichtung hergestellt (die sich an einem Endpunkt befindet, wo ein Teilnehmer dazukommt), die eine Sitzung mit einem Konferenzserver herstellt. Das Herstellen einer Sitzung zwischen dem Client und dem Konferenzserver kann unter Einsatz einer Anzahl verschiedener Protokolle erfolgen, einschließlich dem Session Description Protocol (SDP), Session Initiation Protocol (SIP) und Real-Time Transport Protocol (RTP).
  • Nachdem eine Sitzung zwischen dem Client und dem Konferenzserver hergestellt ist, werden Video und Audio von jedem der an der Konferenz beteiligten Client zu dem Konferenzserver übertragen. Der Konferenzserver kombiniert dann die Videoströme und überträgt sie an den Client zur Ausgabe bei dem Client. Der Server steuert in der Regel die Auflösung des von dem Client empfangenen Videos und ändert die Auflösung auf der Basis von Bandbreitenbeschränkungen ohne jegliche Eingabe von dem Client oder Berücksichtigung der Benutzererfahrung mit dem Client. Entsprechende Verfahren und Systeme sind dem Fachmann aus der EP 1 578 129 A1 , der US 2009/0 040 289 A1 , der DE 603 02 561 T2 , der WO 2007/067 236 A1 und der US 5 880 728 A bekannt. Es ist Aufgabe der Erfindung, die dort beschriebenen Verfahren und Systeme hinsichtlich der Bandbreitenbeschränkungen zu verbessern.
  • Wenngleich in diesem Abschnitt über den allgemeinen Stand der Technik spezifische Probleme und Fragen identifiziert worden sind, sind die hierin beschriebenen Ausführungsformen nicht darauf beschränkt, diese bestimmten Probleme oder Fragen zu lösen. Die Ausführungsformen können darauf angewendet werden, Probleme zu lösen, die nicht in diesem Abschnitt über den allgemeinen Stand der Technik beschrieben sind.
  • KURZE DARSTELLUNG DER ERFINDUNG
  • Es ist bezüglich der obigen Fragen und anderer Probleme, dass die hierin vorgelegten Ausführungsformen in Betracht gezogen wurden. In der vorliegenden Anmeldung beschriebene Ausführungsformen sorgen dafür, dass ein Client Attribute aushandelt, die eine Benutzererfahrung während einer Multimediasitzung wie etwa einer Videokonferenz beeinflussen. Der Client kann Attribute aushandeln, die beispielsweise das Layout von Continuous-Presence-Informationen, die einem Benutzer angezeigt werden, die Videoauflösung von angezeigten Informationen, das Umgruppieren von Fenstern während der Videokonferenz und dergleichen beeinflussen.
  • Bei einer Ausführungsform wird ein Verfahren bereitgestellt, das Folgendes beinhaltet: Genieren eines Angebots und Anzeigen einer Fensterinhaltsspezifikation, zum Beispiel einer ersten Fensterkennung für ein erstes und zweites Fenster, einer Bandbreitengrenzenkennung für das erste und zweite Fenster und einer Gruppenkennung für das erste und zweite Fenster in dem Angebot anzeigt. Das Angebot wird dann zum Beispiel zu einem Konferenzserver übertragen. Dann wird eine Antwort auf das Angebot empfangen. Bei einigen Ausführungsformen werden das Angebot und die Antwort gemäß einem Session Description Protocol (SDP) formatiert. Nach dem Erhalt der Antwort wird Videoinhalt zur Anzeige in dem ersten Fenster und dem zweiten Fenster empfangen.
  • Die eingangs genannte Aufgabe wird hierbei wie folgt gelöst: Die Fensterinhaltsspezifikation enthält eine erste Gruppenkennung, der eine höhere Priorität zugewiesen ist als einer zweiten Gruppenkennung. Die höhere Priorität zeigt an, dass Auflösungsreduktionen auf Inhalt zur Anzeige in Fenstern der zweiten Gruppe angewendet werden sollten, bevor Auflösungsreduktionen auf Inhalt zur Anzeige in Fenstern in der ersten Gruppe angewendet wird. Die erste Bandbreitengrenzenkennung zeigt eine Grenze zum Reduzieren der Auflösung von Videoinhalt zur Anzeige in Fenstern der ersten Gruppe an. Die erste Bandbreitengrenzenkennung kann einen Prozentsatz einer ursprünglichen Auflösung für das Fenster anzeigen.
  • Bei einigen Ausführungsformen enthält das Angebot zusätzlich zu den anderen Kennungen eine erste Rangkennung für das erste Fenster und/oder eine zweite Rangkennung für das zweite Fenster. Die Rangkennungen werden verwendet, um das Umgruppieren von Fenstern zu steuern, die einem Benutzer Continuous-Presence-Informationen anzeigen. Wenn beispielsweise ein Benutzer an einer Videokonferenz teilnimmt, kann der Rang die Anzeige von aktiven Sprechern innerhalb verschiedener Fenster steuern. Bei Ausführungsformen weist das erste Fenster einen Rang derart auf, dass der letzte aktive Sprecher in dem ersten Fenster angezeigt wird. Analog kann das zweite Fenster so eingestuft werden, dass der vorletzte aktive Sprecher angezeigt wird. Bei einigen Ausführungsformen kann ein Fenster so eingestuft werden, dass sie festgelegt sind, was bedeutet, dass derselbe Teilnehmer immer in dem Fenster angezeigt wird. Bei noch weiteren Ausführungsformen wird das Umgruppieren der Fenster, das sich daraus ergibt, dass Sprecher ankommen und weggehen, minimiert.
  • Eine weitere Ausführungsform betrifft eine Kommunikationseinrichtung, zum Beispiel einen Konferenzserver, der Folgendes enthält: ein übergangsloses computerlesbares Medium, einen Prozessor und eine Anwendung, die in dem computerlesbaren Medium gespeichert ist und auf dem Prozessor läuft. Die Anwendung enthält ein Angebot für eine Multimediakommunikationssitzung, wobei das Angebot bei Ausführungsformen Folgendes beinhaltet: eine erste Fensterkennung für ein erstes Fenster, eine Bandbreitengrenzenkennung für das erste Fenster, eine erste Gruppenkennung für das erste Fenster, eine zweite Fensterkennung für ein zweites Fenster, eine zweite Bandbreitengrenzenkennung für das zweite Fenster und eine zweite Gruppenkennung für das zweite Fenster. Bei Ausführungsformen überträgt die Anwendung eine Antwort als Reaktion auf das Erhalten des Angebots. Die Antwort in dem Angebot ist bei einigen Ausführungsformen gemäß SDP formatiert. Die Anwendung überträgt dann Videoinhalt zur Anzeige in dem ersten Fenster und dem zweiten Fenster. Bei einigen Ausführungsformen reduziert die Anwendung die Auflösung von Videoinhalt als Reaktion auf eine Bandbreitenbeschränkung. Die Auflösungsreduktion basiert auf der Gruppenkennung sowie der in dem Angebot erhaltenen Bandbreitengrenzenkennung. Beispielsweise kann die erste Gruppenkennung bei Ausführungsformen eine niedrigere Priorität als die zweite Gruppenkennung aufweisen, wobei dann die Videoauflösung zur Anzeige auf mit der ersten Gruppenkennung assoziierten Fenstern reduziert wird bis zu der ersten Bandbreitengrenze, bevor die Videoauflösung zur Anzeige auf mit der zweiten Gruppenkennung assoziierten Fenstern reduziert wird.
  • Andere Ausführungsformen betreffen ein computerlesbares Medium mit auf dem computerlesbaren Medium gespeicherten computerausführbaren Anweisungen, die bei Ausführung durch einen oder mehrere Prozessoren eines Computers bewirken, dass der Computer ein Verfahren zum Aushandeln einer Multimediasitzung durchführt. Das Verfahren beinhaltet das Generieren eines Angebots für eine Multimediakommunikationssitzung. Das Angebot enthält bei Ausführungsformen mehrere Fensterkennungen für mehrere Fenster, eine Bandbreitengrenzenkennung für jedes der mehreren Fenster und eine Gruppenkennung für jedes der mehreren Fenster, wobei eine erste Gruppenkennung für einen ersten Abschnitt der mehreren Fenster von einer zweiten Gruppenkennung für einen zweiten Abschnitt der mehreren Fenster verschieden ist. Das Angebot wird dann zu einem Server übertragen. Eine Antwort auf das Angebot wird von dem Server erhalten und Videoinhalt zur Anzeige in den mehreren Fenstern wird von dem Server erhalten.
  • Die Ausdrücke „mindestens ein”, „ein oder mehrere” und „und/oder” sind offene Ausdrücke, die von der Funktion her sowohl verbinden als auch trennen. Beispielsweise bedeutet jeder der Ausdrücke „mindestens einer von A, B und C”, „mindestens einer von A, B oder C”, „einer oder mehrere von A, B und C”, „einer oder mehrere von A, B oder C” und „A, B und/oder C” A alleine, B alleine, C alleine, A und B zusammen, A und C zusammen, B und C zusammen oder A, B und C zusammen.
  • Der Ausdruck „in Kommunikation mit”, wie er hierin verwendet wird, bezieht sich auf jede Kopplung, Verbindung oder Interaktion unter Einsatz elektrischer Signale zum Austauschen von Informationen oder Daten unter Verwendung eines beliebigen Systems, einer beliebigen Hardware oder Software, eines beliebigen Protokolls oder Formats.
  • Der Ausdruck „eine” Entität bezieht sich auf eine oder mehrere dieser Entitäten. Die Ausdrücke „ein” (oder „eine”), „ein/e oder mehrere” und „mindestens ein/e” können als solche hierin vertauschbar verwendet werden. Es wird auch angemerkt, dass die Ausdrücke „umfassend”, „beinhaltend” und „mit” vertauschbar verwendet werden können.
  • Der Ausdruck „automatisch” und Variationen davon, wie hier verwendet, bezieht sich auf einen beliebigen Prozess oder eine beliebige Operation, der oder die ohne wesentliche menschliche Eingabe erfolgt, wenn der Prozess oder die Operation ausgeführt wird. Ein Prozess oder eine Operation kann jedoch auch dann automatisch sein, wenn die Ausführung des Prozesses oder der Operation eine menschliche Eingabe verwendet, ob wesentlich oder nicht wesentlich, falls die Eingabe vor der Ausführung des Prozesses oder der Operation empfangen wird. Eine menschliche Eingabe wird als wesentlich angesehen, wenn eine derartige Eingabe beeinflusst, wie der Prozess oder die Operation ausgeführt wird. Eine menschliche Eingabe, die der Ausführung des Prozesses oder der Operation zustimmt, wird nicht als „wesentlich” angesehen.
  • Der Ausdruck „computerlesbares Medium”, wie er hierin verwendet wird, bezieht sich auf jede dinghafte Speicherung, die Teil hat an der Lieferung von Anweisungen an einen Prozessor zur Ausführung. Ein derartiges Medium kann viele Formen annehmen, unter anderem nichtflüchtige Medien, flüchtige Medien und Übertragungsmedien. Zu nichtflüchtigen Medien zählen beispielsweise NVRAM oder magnetische oder optische Platten. Zu flüchtigen Medien zählt ein dynamischer Speicher wie etwa ein Hauptspeicher. Zu gewöhnlichen Formen von computerlesbaren Medien zählen beispielsweise eine Diskette, eine flexible Platte, eine Festplatte, ein Magnetband oder ein beliebiges anderes magnetisches Medium, magneto-optisches Medium, eine CD-ROM, ein beliebiges anderes optisches Medium, Lochkarten, Papierband, ein beliebiges anderes physisches Medium mit Lochmustern, ein RAM, ein PROM und EPROM, ein FLASH-EPROM, ein Festkörpermedium wie eine Speicherkarte, ein beliebiger anderer Speicherchip oder eine beliebige andere Speicherkarte oder ein beliebiges anderes Medium, aus dem ein Computer lesen kann. Wenn das computerlesbare Medium als eine Datenbank konfiguriert ist, ist zu verstehen, dass es sich bei der Datenbank um eine beliebige Art von Datenbank handeln kann, wie etwa eine relationale, hierarchische, objektorientierte und/oder dergleichen. Dementsprechend werden die Ausführungsformen so angesehen, dass sie ein dinghaftes Speicherungsmedium und im Stand der Technik anerkannte Äquivalente und Nachfolgermedien beinhalten, in denen die Softwareimplementierungen der Ausführungsformen gespeichert sind.
  • Die Ausdrücke „bestimmen”, „kalkulieren” und „berechnen” und Variationen davon, wie sie hierin verwendet werden, werden vertauschbar verwendet und beinhalten eine beliebige Art von Methodik, Prozess, mathematischer Operation oder Technik.
  • Der Ausdruck „Modul”, wie er hierin verwendet wird, bezieht sich auf jede bekannte oder später entwickelte Hardware, Software, Firmware, Künstliche Intelligenz, Fuzzy-Logik oder eine Kombination aus Hardware und Software, die die mit diesem Element assoziierte Funktionalität durchführen kann. Während Ausführungsbeispiele beschrieben werden, ist außerdem zu verstehen, dass individuelle Aspekte der Ausführungsformen separat beansprucht werden können.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Offenbarung wird in Verbindung mit den beigefügten Figuren beschrieben:
  • 1 ist ein Blockdiagramm eines Systems, das eine Kommunikationseinrichtung gemäß einer Ausführungsform enthält, die eine Multimediasitzung aushandeln kann;
  • 2 ist ein Blockdiagramm, das eine erste Kommunikationseinrichtung gemäß einer Ausführungsform zeigt, die Nachrichten mit einer zweiten Kommunikationseinrichtung austauscht, um eine Multimediasitzung herzustellen;
  • 3 zeigt eine Ausführungsform eines Angebots gemäß einer Ausführungsform;
  • 4 zeigt eine Ausführungsform einer Antwort gemäß einer Ausführungsform;
  • 5 zeigt ein Layout mit einer Gruppe von Fenstern zum Anzeigen von Continuous-Presence-Informationen für einen Benutzer gemäß einer Ausführungsform;
  • 6 zeigt ein Layout mit zwei Gruppen von Fenstern zum Anzeigen von Continuous-Presence-Informationen für einen Benutzer gemäß einer Ausführungsform;
  • 7A und 7B zeigen Fenster, die Continuous-Presence-Informationen anzeigen, und wie sie als Reaktion auf Änderungen bei aktiven Sprechern umgruppieren, gemäß einer Ausführungsform;
  • 8A und 8B zeigen Fenster, die Continuous-Presence-Informationen und das Umgruppieren der Fenster als Reaktion auf Änderungen bei aktiven Sprechern gemäß einer zweiten Ausführungsform anzeigen;
  • 9A und 9B zeigen Fenster, die Continuous-Presence-Informationen und das Umgruppieren der Fenster als Reaktion auf Änderungen bei aktiven Sprechern gemäß einer dritten Ausführungsform anzeigen;
  • 10A und 10B zeigen Fenster, die Continuous-Presence-Informationen und das Umgruppieren der Fenster als Reaktion auf Änderungen bei aktiven Sprechern gemäß einer vierten Ausführungsform anzeigen;
  • 11 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zum Aushandeln einer Multimediasitzung und Erhalten von Audio- und/oder visuellen Daten für die Multimediasitzung;
  • 12 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zum Aushandeln einer Multimediasitzung und Senden von Audio- und/oder visuellen Daten für die Multimediasitzung;
  • 13 ist ein Blockdiagramm einer Ausführungsform einer Computer- oder EDV-Umgebung, die dahingehend betätigt werden kann, als die eine oder mehreren hierin beschriebenen Einrichtungen zu arbeiten.
  • Bei den beigefügten Figuren können ähnliche Komponenten und/oder Merkmale die gleiche Referenzbezeichnung aufweisen. Weiterhin können sich verschiedene Komponenten vom gleichen Typ dadurch unterscheiden, dass auf die Referenzbezeichnung ein Buchstabe folgt, der zwischen den ähnlichen Komponenten unterscheidet. Falls in der Patentschrift nur die erste Referenzbezeichnung verwendet wird, lässt sich die Beschreibung auf eine beliebige der ähnlichen Komponenten mit der gleichen ersten Referenzbezeichnung anwenden, ungeachtet von der zweiten Referenzbezeichnung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die folgende Beschreibung liefert nur Ausführungsformen und soll nicht den Schutzbereich, die Anwendbarkeit oder die Konfiguration der Ansprüche beschränken. Vielmehr versorgt die folgende Beschreibung den Fachmann mit einer Beschreibung, die das Implementieren der Ausführungsformen ermöglicht. Es versteht sich, dass an der Funktion und der Anordnung von Elementen verschiedene Änderungen vorgenommen werden können, ohne von dem Gedanken und Schutzbereich der beigefügten Ansprüche abzuweichen.
  • In der vorliegenden Anmeldung beschriebene Ausführungsformen sorgen dafür, dass ein Client Attribute ausgehandelt, die eine Benutzererfahrung während einer Multimediasitzung wie etwa einer Videokonferenz beeinflussen. Der Client ist in der Lage, etwas Kontrolle darüber zu haben, wie Audio-/Videodaten an einen Benutzer ausgegeben werden, insbesondere über die Videoauflösung angezeigter Informationen, das Umgruppieren von Fenstern auf der Basis aktiver Sprecher, die an einer Videokonferenz teilnehmen, und das Layout, wie die Fenster einem Benutzer angezeigt werden. Beispielsweise kann die Sitzung als Teil der Videokonferenz ein Multistream Continuous Presence-(CP)Video beinhalten.
  • 1 zeigt ein System 100, das Kommunikationseinrichtungen 102A102N umfasst, z. B. Mobiltelefone, Smartphones, Funkkommunikationseinrichtungen, Telefone, Softphones, Videodisplays, Fernsehgeräte, Monitore, Arbeitsplatzrechner, Laptops und dergleichen. Wie in 1 dargestellt, sind die Kommunikationseinrichtungen 102A102N mit einem Netzwerk 104 verbunden, durch das die Kommunikationseinrichtungen 102A102N miteinander kommunizieren können. An das Netzwerk 104 ist auch ein Server 108 angeschlossen, der bei Ausführungsformen ein Konferenzserver mit Videokonferenz- und/oder Multimediafähigkeiten ist.
  • Die Kommunikationseinrichtung 102A enthält unter anderen Merkmalen einen Speicher 112, der Dateien speichern kann, und eine oder mehrere ausführende Anwendungen und/oder Module wie etwa ein SIP/SDP-Modul 116 und Videokonferenzmodul 120. Wie unten ausführlicher beschrieben, werden das SIP/SDP-Modul 116 und das Videokonferenzmodul 120 zum Aushandeln über und Teilnehmen an Multimediasitzungen zwischen der Kommunikationseinrichtung 102A und anderen Kommunikationseinrichtungen (z. B. 102B102N) oder Servern (z. B. 108) verwendet.
  • Die Kommunikationseinrichtung 102A enthält zusätzlich zum Speicher 112 auch zusätzliche Hardware wie etwa einen Prozessor 124 und Kommunikationssysteme 128. Der Prozessor 124 wird zum Ausführen des Codes von Anwendungen und Modulen wie etwa des SIP/SDP-Moduls 116 und Videokonferenzmoduls 120 und anderer im Speicher 108 gespeicherter Anwendungen verwendet. Ein Bus 132 liefert eine Verbindung zum Übertragen von Signalen zwischen dem Speicher 112, dem Prozessor 124 und den Kommunikationssystemen 128. Die Kommunikationseinrichtung 102A enthält auch ein Display 136, das zum Anzeigen von audiovisuellen Daten konfiguriert. ist, die von der Kommunikationseinrichtung 102A als Teil einer Multimediasitzung empfangen werden. Bei der in 1 gezeigten Ausführungsform zeigt das Display 136 Fenster 140, 144 und 148, in denen Continuous-Presence-Informationen von Teilnehmern einer Videokonferenz angezeigt werden. Außerdem kann die Kommunikationseinrichtung 102A auch andere Eingabe-/Ausgabeeinrichtungen enthalten, insbesondere ein oder mehrere Displays, z. B. Lautsprecher, Licht, Tastaturen und Mikrofone.
  • Es wird angemerkt, dass in 1 zwar das SIP/SDP-Modul 116 und das Videokonferenzmodul 120 als im Speicher 112 der Kommunikationseinrichtung 102A gespeichert gezeigt sind, bei anderen Ausführungsformen mindestens Teile der Module auf einem oder mehreren Servern gespeichert sind, d. h., sie können einen verteilten Code nutzen. Falls, als ein Beispiel, das Videokonferenzmodul 120 mindestens teilweise auf einem Server gespeichert ist, kommuniziert die Kommunikationseinrichtung 102A unter Verwendung von Kommunikationssystemen 128 mit dem Server zum Zugreifen auf Informationen von dem Videokonferenzmodul 120 wie etwa Routinen, Subroutinen oder anderen Codes, die auf dem Server gespeichert sein können.
  • Der Server 108 enthält unter anderen Merkmalen einen Speicher 152, wo Dateien und Module gespeichert sind, wie etwa das Multimediamodul 156, das Konferenzmodul 160 und das SIP/SDP-Modul 164. Der Server 108 enthält auch zusätzliche Hardware wie etwa einen Prozessor 124 und Kommunikationssysteme 172. Der Prozessor 124 wird zum Ausführen des Codes von Anwendungen und Modulen wie etwa des Multimediamoduls 156, des Konferenzmoduls 160 und des SIP/SDP-Moduls 164 und anderer im Speicher 152 gespeicherter Anwendungen verwendet. Ein Bus 176 liefert eine Verbindung zum Übertragen von Signalen zwischen dem Speicher 152, dem Prozessor 168 und Kommunikationssystemen 172. Außerdem kann die Kommunikationseinrichtung 102A auch andere Eingabe-/Ausgabeeinrichtungen enthalten, insbesondere ein oder mehrere Displays, z. B. Lautsprecher, Licht, Tastaturen und Mikrofone.
  • Bei Ausführungsformen nimmt die Kommunikationseinrichtung 102 an einer Anzahl verschiedener Typen von Multimediasitzungen mit dem Server 108 teil. Ein spezifischer Typ von Multimediasitzung ist eine Videokonferenz, bei der eine Anzahl von Teilnehmern an verschiedenen Punkten Kommunikationseinrichtungen, z. B. 102B102N, nutzen, um sowohl unter Verwendung von Audio- als auch Videodaten in Echtzeit zu kommunizieren. Der Server 108 dient als ein zentraler Punkt zum Sammeln von Audio- und Videodaten von den Kommunikationseinrichtungen. Der Server 108 überträgt dann die Audio-Videodaten an die Kommunikationseinrichtungen zur Ausgabe. Wenngleich sich die nachstehende Beschreibung auf das Videoconferencing konzentriert, sind Ausführungsformen nicht notwendigerweise auf diese Anwendung beschränkt. Bei anderen Ausführungsformen können die Mediasitzungen zuvor aufgezeichnete (oder Fast-Echtzeit-)Audio-Video-Daten beinhalten, die einen Benutzer zur Unterhaltung, zur Sicherheit, zur Information oder aus anderen Gründen angezeigt werden. Wenngleich die nachstehende Beschreibung das spezifische Beispiel des Videoconferencing liefert, sind Ausführungsformen deshalb nicht darauf beschränkt.
  • 2 zeigt eine Ausführungsform der Kommunikationseinrichtung 102A, die eine Multimediasitzung, insbesondere eine Videokonferenzsitzung, mit dem Server 108, der als der Konferenzserver für die Videokonferenz dient, behandelt und herstellt. Zusätzlich zu der Kommunikationseinrichtung 102A nehmen auch mindestens drei andere Kommunikationseinrichtungen und Teilnehmer an der Videokonferenz teil. Aus Gründen der Einfachheit sind die mehreren Nachrichten 200, die während des Aushandelns zwischen der Kommunikationseinrichtung 102A und dem Server 108 ausgetauscht werden, als direkt zwischen der Kommunikationseinrichtung 102A und dem Server 108 ausgetauscht gezeigt.
  • Wie jedoch zu verstehen ist, werden die mehreren Nachrichten 200 im tatsächlichen Betrieb durch ein oder mehrere Netzwerke übertragen, bei denen es sich um ein LAN, ein WAN oder irgendeinen anderen Typ von Netzwerk handeln kann. Außerdem wird angemerkt, dass zwar spezifische Nachrichten als zwischen der Kommunikationseinrichtung 102A und dem Server 108 ausgetauscht gezeigt sind, bei anderen Ausführungsformen zusätzliche Nachrichten zwischen der Einrichtung 102A und dem Server 108 ausgetauscht werden. Beispielsweise werden bei einigen Ausführungsformen auch Nachrichten für Sicherheitsprotokolle, Transportprotokolle und/oder Sitzungsinitiierungsprotokolle ausgetauscht. Diese zusätzlichen Nachrichten können vor oder nach den mehreren in 2 gezeigten Nachrichten 200 ausgetauscht werden.
  • Wie in 2 gezeigt, sendet die Kommunikationseinrichtung 102A anfänglich ein Angebot 204 an den Server 108. Das Angebot 204 kann gemäß einem beliebigen angemessenen, zum Aushandeln von Multimediasitzungen verwendeten Protokoll formatiert sein. Bei einer spezifischen Ausführungsform ist das Angebot gemäß einem Session Description Protocol (SDP) formatiert, das ein Format zum Beschreiben von Initialisierungsparametern für Streaming-Medien liefert. Ausführungsformen sind nicht auf SDP beschränkt und das Angebot 204 kann in einem beliebigen geeigneten Format vorliegen. Außerdem können andere Protokolle wie etwa Sicherheitsprotokolle, Transportprotokolle und/oder Multimediaprotokolle beim Generieren und Übertragen des Angebots 204 verwendet werden. Bei einer Ausführungsform wird das Security Initiation Protocol (SIP) als ein Transportprotokoll verwendet, wenn das Angebot 204 übertragen wird. Bei dieser Ausführungsform werden zum Generieren des Angebots 204 ein oder mehrere des SIP/SDP-Moduls 116 und des Videokonferenzmoduls 120 verwendet.
  • Als Reaktion auf das Angebot 204 überträgt der Server 108 eine Antwort 208, gefolgt von Videodaten 212, wobei es sich um ein Multi-Stream-Continuous-Presence-(CP)-Video handelt (z. B. Multi Scalable Video Coding-(SVC)- oder Advanced Video Coding(AVC)-Videoströme), von Teilnehmern an der Videokonferenz. Die Kommunikationseinrichtung 102A decodiert die Videodaten 212 und rendert das CP-Video zur Anzeige auf verschiedenen Fenstern auf der Kommunikationseinrichtung 102A. Bei Ausführungsformen, wo SDP beim Formatieren des Angebots 204 verwendet wird, werden die Multi-Stream-Videoströme unter Verwendung von n Video (z. B. „m Leitungen”) in einem SDP-Angebot ausgehandelt, wobei n > 1. Beispielsweise zeigt n = 4 an, dass das CP-Video 4 Teilnehmer/Fenster enthalten wird. Ein einzelnes Video, das in einer SDP-Anfrage als eine m-Leitung mit n = 1 bezeichnet wird, bedeutet kein CP und zeigt in der Regel den letzten aktiven Sprecher.
  • Beim herkömmlichen Aushandeln unter Verwendung von SDP werden nur der verwendete Codec, die Bitrate (AVC und SVC), die Anzahl der verwendeten Lagen (SVC) und die Richtung (z. B. nur Empfangen (recvonly), Senden und Empfangen (sendrev), nur Senden (sendonly)) ausgehandelt. Diese behandeln jedoch nicht die Benutzererfahrungsaspekte des CP-Layouts (z. B. ob Fenster in einem 2 × 2-, 1 + 3-Format) angezeigt werden, die Gruppierung von CP-Fenstern, die Handhabung von Bandbreitenreduktion-/-optimierungs- und Fensterumgruppierungsalgorithmen. Das Angebot 204 enthält deshalb gemäß Ausführungsformen zusätzliche Attribute, die das Aushandeln von Benutzererfahrungsaspekten gestatten. 3 zeigt eine Ausführungsform des Angebots 204, das in Übereinstimmung mit einer Ausführungsform gemäß SDP formatiert ist. 4 zeigt eine Ausführungsform einer Antwort 208, die in Übereinstimmung mit einer Ausführungsform gemäß SDP formatiert ist.
  • Wie in 3 gezeigt, enthält das Angebot 204 eine Anzahl verschiedener Attribute, die als Fensterinhaltsspezifikationen bezeichnet werden können. Bei Zeile 216 befindet sich eine Kette von Attributen, die in Übereinstimmung mit Ausführungsformen Benutzererfahrungsaspekte des Videos behandeln, das als Teil der von der Kommunikationseinrichtung 102A ausgehandelten Videokonferenz übertragen wird. Die Attribute enthalten eine erste Fensterkennung 220, eine erste Gruppenkennung 224, eine erste Bandbreitengrenzenkennung 228 und eine erste Rangkennung 232. Jedes dieser Attribute liefert Informationen darüber, wie der Client mindestens einen Abschnitt des Videos, als Teil der Videokonferenz übertragen, in einem ersten Fenster ausgeben wird. Zeile 236 enthält auch Attribute einschließlich einer zweiten Fensterkennung 240, einer zweiten Gruppenkennung 244, einer zweiten Bandbreitengrenzenkennung 248 und einer zweiten Rangkennung 252. Diese Attribute liefern Informationen darüber, wie der Client mindestens einen zweiten Abschnitt des Videos in einem zweiten Fenster ausgeben wird. Wie oben angemerkt, können diese Parameter (Fensterkennungen, Bandbreitengrenzenkennungen, Gruppenkennungen und Rangkennungen) in einem Angebot enthalten sein und können als Fensterinhaltsspezifikation bezeichnet werden.
  • Bei einigen Ausführungsformen werden die Attribute von einem Benutzer oder einem Administrator ausgewählt. Die Attribute können so ausgewählt werden, dass sie die Benutzererfahrung auf die Multimediasitzung zuschneiden, oder gemäß einer bestimmten Präferenz. Bei anderen Ausführungsformen kann es Standardwerte geben, die gesetzt werden, falls keine Eingaben für die Attribute erhalten werden. Die Standardwerte können beispielsweise Gruppenkennung = 1, Bandbreitenreduktionsgrenzenkennung = 100, VAS-Rang = 1 sein. Diese Werte werden unten ausführlicher beschrieben.
  • Außerdem enthält Zeile 218 eine Anzeige darüber, ob die Attribute, die der Zeile 218 vorausgehen, auf Videoinhalt, der gesendet und/oder empfangen wird, anwendbar sind oder nicht. Wie in 3 angezeigt, gibt Zeile 218 an, dass die darüber erwähnten Attribute, einschließlich in Zeile 216, für ein bidirektionales Video bestimmt sind, d. h. Video, das von der Kommunikationseinrichtung 102A sowohl gesendet als auch empfangen wird. Zeile 238 zeigt an, dass die darüber erwähnten Attribute nur für Video bestimmt sind, das empfangen wird. Der Client kann deshalb flexibel sein, wenn die Sitzung mit dem Server 108 ausgehandelt wird, wie etwa durch Anzeigen, dass er Video in hoher Auflösung senden wird, aber Video nur in niedrigerer Auflösung empfangen wird oder umgekehrt.
  • 4 zeigt eine Ausführungsform einer Antwort 208, die gemäß SDP formatiert ist. Die Antwort 208 quittiert die Attribute, die in dem Angebot 204 gesendet wurden. Bei einigen Ausführungsformen kann die Antwort 208 Zählerangebote bereitstellen oder anzeigen, dass sie die Attribute, die von der Kommunikationseinrichtung 102A angefordert worden sind, nicht berücksichtigen kann. Bei diesen Ausführungsformen würde die Kommunikationseinrichtung 102A dann ein anderes Angebot mit unterschiedlichen Attributen in einem Versuch senden, Attribute auszuhandeln, die für den Server 108 akzeptabel sind.
  • Wieder unter Bezugnahme auf 3 werden Fensterkennungen 220 und 240 zum Identifizieren der Fenster an dem Client verwendet, die zum Anzeigen der Videoströme verwendet werden. Wenngleich in dem Angebot 204 nur zwei Fensterkennungen gezeigt sind, kann das Angebot 204 bei anderen Ausführungsformen mehr als zwei Fensterkennungen enthalten. Jede Kennung ist mit einem einzelnen Fenster assoziiert, das zum Anzeigen von Video aus einem Videostrom verwendet wird. Bei Ausführungsformen kommt jeder Videostrom von einem der Teilnehmer an der Konferenz. Wie zu verstehen ist, kann jeder Typ von Kennung als Fensterkennungen 220 und 240 verwendet werden, einschließlich einem beliebigen alphanumerischen Wert. Bei einer Ausführungsform sind Gruppenkennungen ein- oder zweistellige Zahlen, die von 1–99 reichen, wobei die niedrigere Zahl von höherer Priorität ist.
  • Gruppenkennungen 224 und 244 sind jeweils mit einem oder mehreren Fenstern assoziiert. Die Gruppenkennungen 224 und 244 werden zum Zusammengruppieren von Fenstern verwendet. Fenster werden aus einer beliebigen Anzahl von Gründen zusammengruppiert, um beispielsweise Gruppen von Fenstern mit ähnlichen Eigenschaften zu identifizieren, d. h. Fenster mit der gleichen Größe und Auflösung, um die Eigenschaften von mehr als einem Fenster gleichzeitig zu ändern, oder aus einem beliebigen anderen Grund. Bei einer Ausführungsform werden Gruppenkennungen 224 und 244 in Kombination mit Bandbreitengrenzenkennungen 228 und 248 wie unten ausführlicher beschrieben verwendet. Wenngleich die Gruppenkennungen 224 und 244 in dem Angebot 204 als numerische Werte gezeigt sind, kann es sich bei anderen Ausführungsformen bei ihnen um eine beliebige Kennung, die einen alphanumerischen Wert enthält, handeln.
  • Bei Ausführungsformen werden Fenster gemäß ihrem Layout, wie auf der Kommunikationseinrichtung 102A angezeigt, gruppiert. Die 5 und 6 zeigen vier Fenster (304, 308, 312 und 316), die gemäß ihren angezeigten Layouts auf der Kommunikationseinrichtung 102A unterschiedlich gruppiert sind. 5 zeigt, dass die vier Fenster jeweils innerhalb einer einzelnen Gruppe gruppiert sind, nämlich Gruppe 1. Wie zu sehen ist, weisen die vier Fenster (304, 308, 312 und 316) beim Anzeigen auf dem Display 136 die gleiche Größe auf.
  • 6 zeigt eine zweite Ausführungsform, bei der die vier Fenster (304, 308, 312 und 316) in zwei verschiedenen Gruppen gruppiert sind. In 6 enthält Gruppe 1 ein einzelnes Fenster 304, und Gruppe 2 enthält drei Fenster 308, 312 und 316. Das in 6 gezeigte Layout kann zum Hervorheben des Teilnehmers, der gerade aktiv spricht, verwendet werden, indem das Video des aktiven Sprechers auf Fenster 304 angezeigt wird. Die übrigen Fenster 308, 312 und 316 werden zum Anzeigen von Video von anderen Teilnehmern an der Videokonferenz verwendet.
  • Es wird angemerkt, dass 5 und 6 vorgelegt werden, um ein Beispiel von Fenstergruppierungen gemäß Ausführungsformen darzustellen. Bei anderen Ausführungsformen jedoch können die Gruppierungen und spezifischen Layouts von Fenstern variieren. Beispielsweise können die Fenster 308, 312 und 316 in Gruppe 2 in einem anderen Layout angezeigt werden, wie etwa über dem Fenster 304, unter dem Fenster 304 oder links vom Fenster 304. Bei einer anderen Ausführungsform kann jedes Fenster von Gruppe 2 nahe einer anderen Ecke von Fenster 304 angezeigt werden. Dies sind lediglich einige Beispiele und andere Gruppierungen und/oder Layouts sind möglich.
  • Wie sich versteht, können der Moderator und die Teilnehmer an der Videokonferenz verschiedene Layouts verwenden, und jeder kann sein Layout im Laufe des Anrufs ändern, jeder kann auch ein einzelnes aktives Sprecherfenster oder lediglich Audio haben bzw. dazu wechseln. Diese Flexibilität steht aktuell nicht zur Verfügung.
  • Wieder unter Bezugnahme auf 3 werden Bandbreitengrenzenkennungen 228 und 248 zum Setzen einer Grenze über das Ausmaß, in dem die Auflösung eines Videostroms reduziert werden kann, verwendet. Wie zu verstehen ist, unterliegen Konferenzserver Bandbreitenbeschränkungen. Deshalb können sie ihren Bandbreitenverbrauch jederzeit durch Reduzieren der Auflösung des gestreamten Videos reduzieren. In der Regel reduziert der Server die Auflösung von Streaming-Video auf der Basis seiner eigenen vorprogrammierten Algorithmen, ohne notwendigerweise die Benutzererfahrung mit dem Client zu berücksichtigen. Die Bandbreitengrenzenkennungen 228 und 248 gestatten dem Client, bei seinem Aushandeln der Multimediasitzung das Ausmaß zu begrenzen, in dem die Auflösung bestimmter Videoströme reduziert werden kann. Dadurch kann der Client die Benutzererfahrung steuern. Falls der Client beispielsweise bestimmt, dass das in einem bestimmten Fenster angezeigte Video hinsichtlich Qualität zu stark leiden wird, wenn es unter eine vorbestimmte Auflösung reduziert wird, wird er eine Bandbreitengrenzenkennung liefern, die nicht gestattet, dass die Auflösung unter die vorbestimmte Auflösung abfällt. Andererseits kann es ein bestimmtes, in einem anderen Fenster angezeigtes Video geben, dessen Qualität um mehr als die vorbestimmte Auflösung reduziert werden kann und das immer noch eine geeignete Benutzererfahrung liefert. Der Client kann deshalb eine niedrigere Bandbreitenauflösungsgrenze liefern.
  • Bei den Bandbreitengrenzenkennungen 228 und 248 kann es sich um eine beliebige geeignete Kennung handeln, die von dem Server als eine Bandbreitengrenze verstanden wird. In dem in 3 gezeigten Angebot 204 gibt die Bandbreitengrenzenkennung 228 einen Prozentsatz einer ursprünglichen Auflösung an, nämlich 25% einer ursprünglichen Auflösung. Bei dieser Ausführungsform versteht der Server, dass der Client angefordert hat, dass der mit Fenster 1 assoziierte Videostrom um nicht mehr als 25% der ursprünglichen Auflösung reduziert werden sollte. Der Client hat bei dieser Ausführungsform bestimmt, dass das Reduzieren der Auflösung von Fenster 1 um mehr als 25% die Qualität der Benutzererfahrung zu stark beeinflusst, und deshalb wird 25% als die Bandbreitengrenzenkennung 228 verwendet. Andererseits liefert die Bandbreitengrenzenkennung 248 eine Grenze von 50% einer ursprünglichen Auflösung. Somit kann der mit Fenster 2 assoziierte Videostrom um bis zu 50% seiner ursprünglichen Auflösung reduziert werden. Der Client hat deshalb beschlossen, dass das in Fenster 2 abgespielte Video um bis zu 50% seiner ursprünglichen Auflösung reduziert werden kann und immer noch eine adäquate Benutzererfahrung liefert.
  • Als ein Beispiel kann das Displaylayout wie in 6 gezeigt sein, wobei Fenster 1 Fenster 304 entspricht und Fenster 2 einem der Fenster 308, 312 oder 316 entspricht. Weil Fenster 2 ein kleineres Fenster ist, beeinflusst das Reduzieren der Auflösung die Benutzererfahrung nicht so stark wie das Reduzieren der Auflösung des in Fenster 1 angezeigten Inhalts. Das Reduzieren der Auflösung um bis zu 50% der ursprünglichen Auflösung kann deshalb akzeptabel sein. Im Gegensatz dazu wird Fenster 1, das größer ist, ein körniges Aussehen aufweisen, falls die Auflösung zu stark reduziert wird.
  • Die Bandbreitengrerzenkennungen 228 und 248 werden als ein Prozentsatz der ursprünglichen Auflösung eines Videos definiert. Bei anderen Ausführungsformen jedoch können die Bandbreitengrenzenkennungen unterschiedlich definiert werden. Beispielsweise kann sich Angebot 204 auf eine spezifische Auflösung beziehen. Bei anderen Ausführungsformen kann es sich bei den Bandbreitengrenzenkennungen um einen alphanumerischen Wert handeln, der von dem Server so verstanden wird, dass er Auflösungsgrenzen darstellt. Wie zu verstehen ist, sind dies lediglich einige Beispiele, und die Bandbreitengrenzenkennungen sind nicht notwendigerweise darauf beschränkt.
  • Wie oben angegeben, können Gruppenkennungen 224 und 244 in Kombination mit den Bandbreitengrenzenkennungen 228 und 248 verwendet werden, um die Benutzererfahrung bei der Kommunikationseinrichtung 102A zu steuern. Bei einigen Ausführungsformen weisen die Gruppenkennungen 224 und 228 eine vorbestimmte Priorität auf. Beispielsweise kann die durch die Gruppenkennung 224 identifizierte Gruppe („Gruppe 1”) eine höhere Priorität besitzen als die durch die Gruppenkennung 228 definierte Gruppe („Gruppe 2”). Bei Verwendung in Kombination mit den Bandbreitengrenzenkennungen 228 und 248 versteht der Server 108, dass, falls eine Notwendigkeit besteht, die Auflösung von von dem Server 108 zur Kommunikationseinrichtung 102A gestreamten Video aufgrund von Bandbreitenbeschränkungen zu reduzieren, der mit Fenstern in der mit der Gruppenkennung 228 assoziierten Gruppe (nämlich „Gruppe 2”) assoziierte Videoinhalt zuerst bis zu der durch die Bandbreitengrenzenkennung 228 identifizierten Auflösungsgrenze reduziert werden sollte. Nach der Auflösungsreduktion des mit dem Fenster in Gruppe 2 assoziierten Videoinhalts kann, falls notwendig, der mit den Fenstern in Gruppe 1 assoziierte Videoinhalt hinsichtlich seiner Auflösung bis zu der durch die Bandbreitengrenzenkennung 248 angegebenen Auflösung reduziert werden. Die Gruppenkennungen und die Bandbreitenkennungen werden zusammen verwendet, um die Benutzererfahrung bei der Kommunikationseinrichtung 102A zu steuern, was mit den verfügbaren Versionen von SDP gegenwärtig nicht möglich ist.
  • Wieder unter Bezugnahme auf 3 werden Rangkennungen 232 und 252 im Angebot 204 vorgesehen, damit sich Fenster auf der Basis der Sprechaktivität von Teilnehmern ändern können. Diese Kennungen können als Sprache-aktiv-Rangkennungen bezeichnet werden. Die Rangkennungen geben die gewünschte Zuweisung von aktiven Sprechern zu einem Fenster an. Der Server weist das Fenster auf der Basis der aktiven Sprechervorgeschichte und der von dem Client gelieferten Rangkennung zu. Die Kennung mit dem höchsten Rang, z. B. Kennung 232 („Rang 1”), erhält den letzten aktiven Sprecher. Mit anderen Worten wird derjenige Teilnehmer, der gegenwärtig spricht oder zuletzt gesprochen hat, in dem Fenster mit dem höchsten Rang, das bei Angebot 204 Fenster 1 ist, angezeigt. Die Kennung mit dem nächsthöchsten Rang, z. B. Kennung 252 („Rang 2”), erhält den vorletzten aktiven Sprecher und so weiter.
  • Die 7A10B zeigen verschiedene Ausführungsformen des Verwendens verschiedener Rangkennungen für vier Fenster (304, 308, 312 und 316) und ihr Verhalten als Reaktion auf ihre Rangkennungen und Sprechaktivität. Diese werden nur zu veranschaulichenden Zwecken vorgelegt und Ausführungsformen sind nicht notwendigerweise darauf beschränkt. Der Einfachheit halber ist in den 7A10B nur das Display 136 der Kommunikationseinrichtung 102A gezeigt.
  • In 7A hat die Kommunikationseinrichtung 102A ein Angebot wie etwa Angebot 204 gesendet, das vier Fenster (304, 308, 312 und 316) anzeigt, von denen jedes andere Continuous-Presence-Informationen für Teilnehmer an der Videokonferenz anzeigt. Das Fenster 304 war mit einer Rangkennung „Rang 1” assoziiert, Fenster 308 war mit einer Rangkennung „Rang 2” assoziiert, Fenster 312 war mit einer Rangkennung „Rang 3” assoziiert, und Fenster 316 war mit einer Rangkennung „Rang 4” identifiziert. In Übereinstimmung mit der obigen Beschreibung zeigt bei dieser Ausführungsform das Fenster mit Rang 1 den letzten aktiven Sprecher, das Fenster mit Rang 2 zeigt den vorletzten aktiven Sprecher, das Fenster mit Rang 3 zeigt den drittletzten Sprecher und das Fenster mit Rang 4 zeigt den viertletzten Sprecher. Wie in 7A gezeigt, ist Teilnehmer 1 der letzte aktive Sprecher, Teilnehmer 2 der vorletzte Sprecher, Teilnehmer 3 der drittletzte Sprecher und Teilnehmer 4 der viertletzte Sprecher.
  • Wenn Teilnehmer 5 zu sprechen beginnt, werden die Fenster 304, 308, 312 und 316 als Reaktion und in Übereinstimmung mit ihrem Rang umgruppiert. 7B zeigt die Fenster (304, 308, 312 und 316), nachdem sie als Reaktion auf das Sprechen von Teilnehmer 5 umgruppiert worden sind. Die Teilnehmerin 5 wird in Fenster 304 gezeigt, weil sie die letzte Sprecherin ist und das Fenster 304 die Rangkennung Rang 1 aufweist. Die Fenster 308, 312 und 316 werden so umgruppiert, dass Teilnehmer 1 in Fenster 308 gezeigt wird, Teilnehmer 2 in Fenster 312 und Teilnehmer 3 in Fenster 316.
  • Die 8A und 8B zeigen Fenster 304, 308, 312 und 316 mit der gleichen Rangkennung, nämlich Rang 1. Dies veranschaulicht die Ausführungsform, wo mehrere Fenster den gleichen Rang aufweisen, was zu einer minimalen Umgruppierung führt. Wie in 8A gezeigt, wird Teilnehmer 1 in Fenster 304 angezeigt, Teilnehmer 2 in Fenster 308, Teilnehmer 3 in Fenster 312 und Teilnehmer 4 in Fenster 316. Wenn der Teilnehmer 5 zu sprechen beginnt, ersetzt Teilnehmer 5 den Teilnehmer 4, anstatt Teilnehmer 1 in Fenster 304 zu ersetzen, und wird in Fenster 316 angezeigt, wie in 8B gezeigt. Keines der anderen Fenster wird verändert. Das heißt, die Umgruppierung wird minimiert, so dass nur ein Fenster geändert wird, dass es den letzten Sprecher anzeigt. Bei dieser Ausführungsform entscheidet der Server 108, welches Fenster verändert wird, um das Umgruppieren der Fenster 304, 308, 312 und 316 zu minimieren. Bei anderen Ausführungsformen kann der Server 108 entscheiden, einen beliebigen der anderen Teilnehmer in den anderen Fenstern zu ersetzen, solange das Umgruppieren minimiert wird. Durch dieses Merkmal kann die Kommunikationseinrichtung 102A die Benutzererfahrung steuern, indem die gleiche Rangkennung jedem der Fenster zugewiesen wird, was dazu führt, dass der Server das Umgruppieren von Fenstern minimieren muss, wenn sich Sprecher hereinschalten und herausschalten.
  • Einige Ausführungsformen sorgen für das Auswählen von Rangkennungen, so dass das Verhalten eine Kombination daraus ist, den letzten aktiven Sprecher hervorgehoben zu haben, aber das Umgruppieren der anderen Teilnehmer zu minimieren. 9A und 9B zeigen die Fenster 304, 308, 312 und 316, wobei Fenster 304 eine Rangkennung von Rang 1 aufweist und die Fenster 308, 312 und 316 die gleiche Rangkennung, nämlich Rang 2, aufweisen. Fenster 304 zeigt den letzten aktiven Sprecher an. Die anderen Fenster 308, 312 und 316 zeigen die nächsten 3 letzten aktiven Sprecher an. Weil die Fenster 308, 312 und 316 alle die gleiche Rangkennung besitzen, wird die Reihenfolge für diese Fenster von dem Server 108 bestimmt, um das Umgruppieren zu minimieren. Wie in 9B gezeigt, wird Fenster 304 geändert, um Teilnehmer 5 anzuzeigen, wenn Teilnehmer 5 zu sprechen beginnt. Um das Umgruppieren zu minimieren, hat der Server 108 das Fenster 316 so geändert, dass es Teilnehmer 1 anzeigt. Dies minimiert das Umgruppieren unter den Fenstern 308, 312 und 316, weil 308 und 312 unverändert bleiben.
  • Bei einigen Ausführungsformen können Rangkennungen zum Festlegen eines bestimmten Fensters verwendet werden. Unter „Festlegen” wird verstanden, dass der in einem Fenster angezeigte Teilnehmer niemals verändert wird, selbst wenn es eine Sprechaktivität durch andere Teilnehmer gibt. Die 10A und 10B zeigen die Fenster 304, 308, 312 und 316, wobei Fenster 304 eine Rangkennung von Rang 1, Fenster 308 eine Rangkennung von Rang 2, Fenster 312 eine Rangkennung von Rang 3 und Fenster 316 eine Rangkennung von Rang 0 aufweist. Bei dieser Ausführungsform gibt Rang 0 an, dass ein Fenster verankert ist; deshalb wird der (in Fenster 316 gezeigte) Teilnehmer 4 immer im Fenster 316 angezeigt. Wenn der Teilnehmer 5 zu sprechen beginnt, wie in 10B gezeigt, ersetzt Teilnehmer 5 in Fenster 304 den Teilnehmer 1. Teilnehmer 1 wird dann in Fenster 308 angezeigt und Teilnehmer 2 wird in Fenster 312 angezeigt. Weil das Fenster 316 mit der Rangkennung Rang 0 assoziiert ist, zeigt es weiter den Teilnehmer 4 an, selbst nachdem der Teilnehmer 5 zu sprechen beginnt. Diese Ausführungsform kann in einer Anzahl von Situationen nützlich sein. In Videokonferenzen beispielsweise, wo es hauptsächlich einen Sprecher gibt, kann die Rangkennung so gewählt werden, dass der primäre Sprecher immer in einem Fenster angezeigt wird, auch wenn er nicht spricht. Diese Ausführungsform ist auch in Situationen nützlich, wo es einen wichtigen Teilnehmer an der Videokonferenz gibt, weshalb der Teilnehmer, auch wenn er nicht spricht, in einem der Fenster angezeigt werden sollte.
  • Falls bei einigen Ausführungsformen kein Rang spezifiziert ist, wird in einem Angebot eine Standardrangkennung zugewiesen. Beispielsweise kann ein Rang von 1 der Standardwert für alle Fenster sein, um das Umgruppieren zu minimieren. Wie sich versteht, kann der Standardwert bei anderen Ausführungsformen ein beliebiger Wert sein, der durch einen Algorithmus in der Kommunikationseinrichtung 102A vorbestimmt wird, von einem Benutzer der Kommunikationseinrichtung 102A ausgewählt wird oder von einem Administrator vorprogrammiert wird.
  • Es wird angemerkt, dass oben zwar spezifische Beispiele von Angeboten und Attributen in den Angeboten beschrieben sind, eine beliebige Kombination von Attributen zum Beschreiben von Layouts für das Anzeigen von Videodaten, wie etwa Continuous-Presence-Informationen für eine Videokonferenz, verwendet werden können. Zusätzliche Beispiele einer Kombination von Attributen, die verschiedene Layouts beschreiben (von denen einige in 510B gezeigt sind), sind unten zu Veranschaulichungszwecken vorgelegt.
  • Beispiel 1: 1 × 4/2 × 2 Layout:
    • a=content: window1,1,100, 1 (dieses Fenster [window] erhält den letzten Sprecher)
    • a=content: window2,1,100, 2 (vor- oder drittletzter Sprecher)
    • a=content: window3,1,100, 2 (vor- oder drittletzter Sprecher)
    • a=content: window4,1,100, 0 (festgelegtes Video/nicht umgeschaltet auf der Basis von Sprecheraktivität)
  • Beispiel 2: 1 + 3 Layout:
    • a=content: window1,1,100, 1
    • a=content: window2,2,100, 2
    • a=content: window3,2,100, 2
    • a=content: window4,2,100, 2
  • In Beispiel 2 wird Fenster1 [window1] den letzten aktiven Sprecher anzeigen. Die 3 anderen Fenster werden die nächsten 3 letzten aktiven Sprecher erhalten, eine minimale Umgruppierung wird auf die Fenster 2, 3, 4 angewendet.
  • Beispiel 3: 1 × 4/2 × 2 Layout:
    • a=content: window1,1,100, 1
    • a=content: window2,1,100, 1
    • a=content: window3,1,100, 1
    • a=content: window4,1,100, 1
  • In Beispiel 3 werden alle vier Fenster mit aktiven Sprecherströmen geschaltet, eine minimale Umgruppierung wird auf alle angewendet.
  • Nunmehr unter Bezugnahme auf 11 wird ein Flussdiagramm 500 zum Aushandeln einer Multimediasitzung, z. B. einer Videokonferenz, gezeigt. Fluss 500 wird in Ausführungsformen durch eine Recheneinrichtung wie etwa eine Kommunikationseinrichtung 102A (12) oder eine andere Client-Recheneinrichtung durchgeführt. Insbesondere können an der Durchführung von Fluss 500 eine oder mehrere Hardware- oder Softwarekomponenten beteiligt sein. Beispielsweise können Abschnitte des Flusses 500 durch ein SIP/SDP-Modul 116 und/oder die Videokonferenz 120 durchgeführt werden.
  • Fluss 500 beginnt mit Schritt 504, wo ein Angebot zum Aushandeln einer Multimediasitzung generiert wird. Das Angebot wird in Ausführungsformen gemäß SDP formatiert, wie etwa das oben beschriebene Angebot 204. Das Angebot kann bei anderen Ausführungsformen gemäß unterschiedlicher Protokolle formatiert werden. Der Fluss geht von Schritt 504 zu Schritt 508, wo eine Anzeige einer Anzahl verschiedener Attribute, einschließlich einer ersten Fensterkennung, einer ersten Bandbreitengrenzenkennung und/oder einer ersten Gruppenkennung, in dem Angebot angegeben ist. Bei dem optionalen Schritt 512 kann in dem bei Schritt 504 generierten Angebot auch eine Rangkennung enthalten sein. Wie oben angedeutet, kann die Rangkennung beim Steuern des Verhaltens angezeigter Fenster als Reaktion auf Sprechaktivität verwendet werden.
  • Bei Schritt 516 wird eine zweite Gruppe von Attributen, einschließlich einer zweiten Fensterkennung, einer zweiten Bandbreitengrenzenkennung und/oder einer zweiten Gruppenkennung, in dem Angebot angezeigt. Bei dem optionalen Schritt 520 kann in dem bei Schritt 504 generierten Angebot auch eine zweite Rangkennung enthalten sein. Wie zu verstehen ist, ist der Fluss 500 auf ein Angebot begrenzt, das zwei Fenster und mit den beiden Fenstern assoziierte Attribute identifiziert. Bei einigen Ausführungsformen kann das Angebot Attribute von mehr als zwei Fenstern enthalten, wobei dann der Fluss 500 zusätzliche Schritte zum Anzeigen von Attributen der zusätzlichen Fenster enthält.
  • Nachdem die Anzeigen von Fensterattributen in dem Angebot für alle Fenster vorgenommen worden sind, geht Fluss 500 zu Schritt 524, wo das Angebot an ein Netzwerk zur Übertragung geliefert wird. Bei Ausführungsformen beinhaltet der Schritt 524 bei Ausführungsformen das Liefern des Angebots an einen Multimedia-Server und/oder einen Videokonferenz-Server. Schritt 524 kann auch die Verwendung einer Anzahl verschiedener Protokolle wie etwa Transportprotokolle, Sicherheitsprotokolle und anderer Multimediaprotokolle mit sich bringen. Schritt 524 beinhaltet die erforderlichen Teilschritte (z. B. Generieren von Kopfteilen, Paketen usw.) zum Liefern des Angebots zur Übertragung zu dem Server. Und Antworten, die bei Schritt 528 empfangen wurden.
  • Der Fluss geht von Schritt 528 zu Schritt 532, wo Videoinhalt zur Anzeige empfangen wird. Der Videoinhalt wird dann bei Schritt 536 angezeigt. Schritt 536 kann eine Anzahl von Teilschritten beinhalten, einschließlich Decodieren des bei Schritt 532 empfangenen Videoinhalts, bevor er angezeigt wird. Die Anzeige des Videoinhalts bei Schritt 532 beinhaltet das Anzeigen des Videoinhalts auf einer Anzahl von unterschiedlichen Fenstern. Das Fenster kann auf jede gewünschte Weise ausgelegt sein, einige Beispiele sind in 5 und 6 gezeigt und oben beschrieben.
  • Bei Schritt 540 wird der niedriger aufgelöste Videoinhalt empfangen und bei Schritt 544 wird der niedriger aufgelöste Videoinhalt angezeigt. Schritt 540 kann ein Ergebnis dessen sein, dass der Server die Bandbreitenbeschränkungen erreicht hat. Damit der Server die Bandbreitenbeschränkungen einhalten kann, muss er die Auflösung des Videoinhalts reduzieren. Wie jedoch oben angedeutet, enthielt das bei Schritt 524 gelieferte Angebot Attribute wie etwa Gruppenkennungen und Bandbreitengrenzenkennungen. Der bei Schritt 540 empfangene und bei Schritt 544 angezeigte Inhalt mit reduzierter Auflösung entspricht somit den in dem Angebot gesendeten Bandbreitengrenzenkennungen. Als ein Beispiel wird zuerst die Auflösung des Videoinhalts zur Anzeige in durch eine Gruppenkennung mit niedrigerem Rang identifizierten Fenstern bis zu einer beliebigen, mit der Gruppe assoziierten Bandbreitengrenzenkennung reduziert. Videoinhalt zur Anzeige in durch eine zweite Gruppenkennung identifizierten Fenstern mit einem höheren Rang wird dann bis zu einer beliebigen, mit der zweiten Gruppe assoziierten Bandbreitengrenzenkennung reduziert.
  • Wie oben angemerkt, können optionale Rangkennungen in dem Angebot bei den optionalen Schritten 512 und 520 angegeben werden. Die Rangkennungen werden zum Steuern der Anzeige von Videoinhalt in Fenstern als Ergebnis von Sprechaktivität verwendet. Bei jenen Ausführungsformen enthält der Fluss 500 den optionalen Schritt 548, wo modifizierte Daten auf der Basis des Rands und der Sprechaktivität während der Multimediasitzung empfangen werden. Auf Schritt 548 folgt dann Schritt 552, wo der modifizierte Videoinhalt angezeigt wird. Der Fluss 500 endet dann bei 556.
  • 5 zeigt ein Flussdiagramm 600 zum Aushandeln einer Multimediasitzung wie etwa eine Videokonferenz. Der Fluss 600 wird bei Ausführungsformen durch eine Recheneinrichtung wie etwa einen Server 108 (13) oder einen anderen Multimedia- und/oder Konferenz-Server durchgeführt. Insbesondere können bei dem Durchführen des Flusses 600 eine oder mehrere Hardware- oder Softwarekomponenten beteiligt sein. Beispielsweise können Teile des Flusses 500 von dem Multimediamodul 156, vom Videokonferenzmodul 160 und/oder dem SIP/SDP-Modul 164 durchgeführt werden, wie oben beschrieben.
  • Der Fluss 600 beginnt mit Schritt 604, wo ein Angebot für eine Multimediasitzung empfangen wird. Das Angebot enthält Angaben von Attributen einschließlich einer oder mehrerer Fensterkennungen, einer oder mehrerer Bandbreitengrenzenkennungen, einer oder mehrerer Gruppenzahlenkennungen und/oder einem oder mehreren Rängen. Bei Ausführungsformen wird das Angebot von einer Client-Einrichtung wie etwa einer Kommunikationseinrichtung 102A empfangen. Der Fluss geht von Schritt 604 zu Schritt 608, wo als Reaktion auf das bei Schritt 604 empfangene Angebot eine Antwort übertragen wird. Bei Ausführungsformen kann die Antwort gemäß SDP formatiert sein. Die Antwort kann die Attribute des bei Schritt 604 empfangenen Angebots quittieren, was anzeigt, dass die Attribute akzeptabel sind. Bei anderen Ausführungsformen kann die Antwort ein Gegenangebot bereitstellen, das andere Attribute als jene enthält, die in dem bei Schritt 604 empfangenen Angebot enthalten sind. Bei diesen Ausführungsformen sind das Angebot und die Antwort eine von mehreren Nachrichten, die während des Aushandelns der Multimediasitzung gesendet und übertragen werden.
  • Der Fluss 600 geht von Schritt 608 zu Schritt 612, wo Videoinhalt übertragen wird. Es wird angemerkt, dass es für das Übertragen des Videoinhalts zusätzliche Schritte geben kann, die parallel zu und/oder vor Schritt 612 ausgeführt werden. Beispielsweise kann Videoinhalt von verschiedenen Quellen empfangen werden, d. h. Client-Einrichtungen, die von Teilnehmern einer Videokonferenz genutzt werden. Der Videoinhalt kann kombinierte Video-/Audioströme enthalten, die dann codiert werden, bevor sie bei Schritt 612 übertragen werden.
  • Nach Schritt 612 wird bei Schritt 616 die Auflösung des Videoinhalts reduziert. Schritt 616 kann als Ergebnis von Bandbreitenbeschränkungen durchgeführt werden. Beispielsweise kann ein den Fluss 600 durchführender Server Bandbreite zum Durchführen anderer Operationen nutzen. Als Ergebnis muss der Server etwas tun, um seinen Bandbreitenverbrauch zu reduzieren. Durch Reduzieren der Auflösung des Videoinhalts bei Schritt 616 kann der Server die Bandbreitenbeschränkungen einhalten. Ihre Auflösungsreduktion wird gemäß dem in dem bei Schritt 604 empfangenen Angebot durchgeführt. Falls beispielsweise Prioritäten bezüglich Gruppenkennungen gesetzt sind, wird dann zuerst die Auflösung des Videoinhalts zur Anzeige auf jenen Fenstern mit einer niedrigeren Prioritätsgruppe reduziert. Falls es eine Bandbreitengrenzenkennung gibt, die das Ausmaß begrenzt, um das die Auflösung reduziert werden kann, wird dann der Server außerdem jene Bandbreitengrenzenkennungen einhalten. Bei Schritt 620 wird der Videoinhalt mit reduzierter Auflösung übertragen.
  • Bei jenen Ausführungsformen, bei denen das Angebot eine Rangkennung enthält, enthält der Fluss 600 zusätzliche optionale Schritte 624 und 628. Wie oben beschrieben, werden die Rangkennungen beim Umgruppieren von Fenstern auf der den bei Schritten 612 und 620 übertragenen Videoinhalt anzeigenden Kommunikationseinrichtung als Reaktion auf Sprecheraktivität verwendet. Deshalb kann ein Server bei Schritt 624 den Videoinhalt gemäß den in einem beliebigen Angebot empfangenen Rängen und der Sprechaktivität modifizieren. Der modifizierte Videoinhalt wird dann bei Schritt 628 übertragen. Der Fluss endet dann bei 632.
  • Es wird angemerkt, dass die Flüsse 500 und 600 zwar Schritte in einer Reihenfolge darstellen, andere Ausführungsformen nicht notwendigerweise darauf beschränkt sind. Die in 11 und 12 gezeigten Schritte können in einer beliebigen Reihenfolge oder parallel ausgeführt werden. Außerdem kann es andere Schritte geben, die durchgeführt werden, die in 11 und 12 nicht gezeigt oder oben beschrieben sind. Wenngleich die Flüsse 500 und 600 oben so beschrieben sind, als wenn sie bei einigen Ausführungsformen durch bestimmte Hardware- und/oder Softwarekomponenten ausgeführt werden, sind außerdem andere Ausführungsformen nicht notwendigerweise auf die obige Beschreibung beschränkt. Wie zu verstehen ist, können die Schritte 500 und 600 durch andere Hardware oder Software ausgeführt werden, die nicht oben beschrieben oder in 11 und 12 gezeigt ist.
  • 13 zeigt eine Ausführungsform eines Computersystems 700, auf dem Server oder andere hierin beschriebene Systeme eingesetzt oder ausgeführt werden können. Das Computersystem 700 ist so gezeigt, dass es Hardware-Elemente umfasst, die über einen Bus 755 elektrisch gekoppelt sein können. Zu den Hardware-Elementen können eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) 705; eine oder mehrere Eingabeeinrichtungen 710 (z. B. eine Maus, eine Tastatur usw.); und eine oder mehrere Ausgabeeinrichtungen 715 (z. B. eine Displayeinrichtung, ein Drucker usw.) zählen. Das Computersystem 700 kann auch eine oder mehrere Speichereinrichtungen 720 enthalten. Beispielsweise kann es sich bei der oder den Speichereinrichtungen 720 um Plattenlaufwerke, optische Speichereinrichtungen, Halbleiterspeichereinrichtungen wie etwa einen Direktzugriffsspeicher („RAM” – Random Access Memory) und/oder einen Festwertspeicher („ROM” – Read-only Memory) handeln, die programmierbar, flash-aktualisierbar und/oder dergleichen sein können.
  • Das Computersystem 700 kann außerdem ein Lesegerät 725 für computerlesbare Medien; ein Kommunikationssystem 730 (z. B. ein Modem, eine Netzwerkkarte (drahtlos oder verdrahtet), eine Infrarotkommunikationseinrichtung usw.); und einen Arbeitsspeicher 740 enthalten, der RAM- und ROM-Einrichtungen wie oben beschrieben enthalten kann. Das Computersystem 700 kann bei einigen Ausführungsformen auch eine Verarbeitungsbeschleunigungseinheit 735 enthalten, die einen DSP, einen Spezialprozessor und/oder dergleichen enthalten kann.
  • Das Lesegerät 725 für computerlesbare Medien kann weiterhin mit einem computerlesbaren Medium verbunden sein, wobei sie zusammen (und optional in Kombination mit einer oder mehreren Speichereinrichtungen 720) abgesetzte, lokale, feste und/oder entfernbare Speichereinrichtungen plus ein computerlesbares Medium zum vorübergehenden und/oder permanenteren Aufnehmen von computerlesbaren Informationen umfassend darstellen. Das Kommunikationssystem 730 kann den Austausch von Daten mit dem Netzwerk 520 und/oder einem beliebigen anderen, oben bezüglich des Systems 700 beschriebenen Computer gestatten.
  • Das Computersystem 700 kann auch Softwareelemente umfassen, die so gezeigt sind, dass sie gegenwärtig innerhalb eines Arbeitsspeichers 740 angeordnet sind, einschließlich eines Betriebssystems 745 und/oder eines anderen Codes 750, wie etwa eines Anwendungscodes, der die hier beschriebenen Server oder Einrichtungen implementiert. Es versteht sich, dass alternative Ausführungsformen eines Computersystems 700 zahlreiche Abweichungen von den oben beschriebenen aufweisen können. Beispielsweise könnte auch kundenspezifische Hardware benutzt werden und/oder bestimmte Elemente könnten in Hardware, Software (einschließlich tragbarer Software wie etwa Applets) oder beidem implementiert werden. Zudem kann eine Verbindung zu anderen Recheneinrichtungen wie etwa Netzwerkeingabe-/-ausgabeeinrichtungen verwendet werden.
  • Bei der vorausgegangenen Beschreibung wurden zu Zwecken der Darstellung Verfahren in einer bestimmten Reihenfolge beschrieben. Es versteht sich, dass die Verfahren bei alternativen Ausführungsformen in einer anderen Reihenfolge als der beschriebenen ausgeführt werden können. Es versteht sich außerdem, dass die oben beschriebenen Verfahren durch Hardwarekomponenten ausgeführt oder in Sequenzen von maschinenausführbaren Anweisungen verkörpert sein können, die dazu verwendet werden können zu bewirken, dass eine Maschine wie etwa ein Allzweck- oder Spezialprozessor oder Logikschaltungen, die mit den Anweisungen programmiert sind, die Verfahren ausführen. Diese maschinenausführbaren Anweisungen können auf einem oder mehreren maschinenlesbaren Medien gespeichert sein, wie etwa CD-ROMs oder anderen Arten von optischen Platten, Disketten, ROMs, RAMs, EPROMs, EEPROMs, magnetischen oder optischen Karten, Flash-Speicher oder anderen Arten von maschinenlesbaren Medien, die sich für das Speichern elektronischer Anweisungen eignen. Alternativ können die Verfahren durch eine Kombination aus Hardware und Software durchgeführt werden.
  • In der Beschreibung wurden spezifische Details angegeben, um ein eingehendes Verständnis der Ausführungsformen zu vermitteln. Der Durchschnittsfachmann versteht jedoch, dass die Ausführungsformen ohne diese spezifischen Details praktiziert werden können. Beispielsweise können Schaltungen in Blockdiagrammen gezeigt sein, um die Ausführungsformen nicht mit unnötigem Detail zu verdunkeln. In anderen Fällen können wohlbekannte Schaltungen, Prozesse, Algorithmen, Strukturen und Techniken ohne unnötiges Detail gezeigt sein, um ein Verdunkeln der Ausführungsformen zu vermeiden.
  • Außerdem wird angemerkt, dass die Ausführungsformen als ein Prozess beschrieben wurden, der als ein Flussbild, ein Flussdiagramm, ein Datenflussdiagramm, ein Strukturdiagramm oder ein Blockdiagramm dargestellt ist. Wenngleich ein Flussbild die Operationen als einen sequenziellen Prozess beschreiben kann, können viele der Operationen parallel oder gleichzeitig durchgeführt werden. Außerdem kann die Reihenfolge der Operationen umgeordnet werden. Ein Prozess ist abgeschlossen, wenn seine Operationen beendet sind, er könnte aber nicht in der Figur enthaltene zusätzliche Schritte aufweisen. Ein Prozess kann einem Verfahren, einer Funktion, einer Prozedur, einer Teilroutine, einem Teilprogramm usw. entsprechen. Wenn ein Prozess einer Funktion entspricht, entspricht seine Beendigung einer Rückkehr der Funktion zu der aufrufenden Funktion oder der Hauptfunktion.
  • Zudem können Ausführungsformen durch Hardware, Software, Firmware, Middleware, Mikrocode, Hardwarebeschreibungssprachen oder eine beliebige Kombination davon implementiert werden. Bei Implementierung in Software, Firmware, Middleware oder Mikrocode können der Programmcode oder Codesegmente zum Durchführen der erforderlichen Aufgaben in einem maschinenlesbaren Medium wie etwa einem Speichermedium gespeichert werden. Ein oder mehrere Prozessoren können die erforderlichen Aufgaben ausführen. Ein Codesegment kann eine Prozedur, eine Funktion, ein Teilprogramm, eine Anwendung, eine Routine, eine Teilroutine, ein Modul, ein Softwarepaket, eine Klasse oder irgendeine Kombination von Anweisungen, Datenstrukturen oder Anwendungsanweisungen darstellen. Ein Codesegment kann durch das Weiterleiten und/oder Empfangen von Informationen, Daten, Argumenten, Parametern oder Speicherinhalten an ein anderes Codesegment oder eine andere Hardwareschaltung gekoppelt sein. Informationen, Argumente, Parameter, Daten usw. können über beliebige geeignete Mittel weitergegeben, weitergeleitet oder übertragen werden, einschließlich gemeinsame Speichernutzung, Nachrichtenweiterleitung, Token-Weiterleitung, Netzwerkübertragung usw.
  • Wenngleich veranschaulichende Ausführungsformen hier ausführlich beschrieben worden sind, ist zu verstehen, dass die erfindungsgemäßen Konzepte ansonsten unterschiedlich verkörpert und verwendet werden können und dass die beigefügten Ansprüche so ausgelegt werden sollen, dass sie solche Variationen enthalten, außer wie durch den Stand der Technik begrenzt.

Claims (9)

  1. Verfahren, das Folgendes umfasst: Generieren eines Angebots durch mindestens einen Prozessor einer Client-Einrichtung für eine Multimediakommunikationssitzung, wobei das Angebot eine Fensterinhaltsspezifikation für mindestens ein Fenster umfasst; Liefern des Angebots durch den mindestens einen Prozessor an ein Netzwerk zur Übertragung durch den mindestens einen Prozessor; Erhalten einer Antwort auf das Angebot und Erhalten eines Videoinhalts durch den mindestens einen Prozessor zum Anzeigen des mindestens einen Fensters, wobei die Fensterinhaltsspezifikation eine Gruppenkennung höherer Priorität umfasst, der eine höhere Priorität zugewiesen ist als einer Gruppenkennung mit niedrigerer Priorität, wobei die höhere Priorität anzeigt, dass Auflösungsreduktionen auf einen Inhalt zur Anzeige in Fenstern der Gruppe mit niedrigerer Priorität angewendet werden sollten, bevor Auflösungsreduktionen auf einen Inhalt zur Anzeige in Fenstern der Gruppe mit höherer Priorität angewendet werden, und wobei die Inhaltsspezifikation eine erste Bandbreitengrenzenkennung umfasst, die eine Grenze zum Reduzieren der Auflösung von Videoinhalt zur Anzeige in Fenstern der Gruppe mit niedrigerer Priorität umfasst.
  2. Verfahren nach Anspruch 1, wobei das Angebot gemäß einem Session Description Protocol (SDP) formatiert wird.
  3. Verfahren nach Anspruch 1, wobei die erste Bandbreitengrenzenkennung einen Prozentsatz einer ursprünglichen Auflösung für die Gruppe mit niedrigerer Priorität anzeigt und wobei die Fensterinhaltsspezifikation eine zweite Bandbreitengrenzenkennung umfasst, die eine Grenze zum Reduzieren der Auflösung von Videoinhalt zur Anzeige in Fenstern der Gruppe mit höherer Priorität anzeigt, wobei die zweite Bandbreitengrenzenkennung einen Prozentsatz einer ursprünglichen Auflösung für die Gruppe mit höherer Priorität anzeigt.
  4. Verfahren nach Anspruch 1, wobei das Angebot weiterhin eine erste Rangkennung umfasst, die mit dem mindestens einen Fenster assoziiert ist, wobei die Multimediakommunikationssitzung eine Videokonferenz ist und die erste Rangkennung anzeigt, dass das mindestens eine Fenster einen Teilnehmer anzeigt, der ein letzter aktiver Sprecher ist, und wobei die erste Rangkennung anzeigt, dass das zweite Fenster immer denselben Teilnehmer anzeigt.
  5. Verfahren nach Anspruch 3, wobei eine zweite Rangkennung anzeigt, dass das mindestens eine Fenster einen zweiten Teilnehmer anzeigt, der ein vorletzter aktiver Sprecher ist, und wobei die zweite Rangkennung anzeigt, dass das mindestens eine Fenster immer denselben Teilnehmer anzeigt.
  6. Kommunikationseinrichtung, die Folgendes umfasst: ein nicht-flüchtiges computerlesbares Medium; einen Prozessor und eine Anwendung, die in dem computerlesbaren Medien gespeichert ist und auf dem Prozessor läuft, wobei die Anwendung: ein Angebot von einer Client-Einrichtung erhält für eine Multimediakommunikationssitzung, wobei das Angebot Folgendes umfasst: eine erste Fensterkennung für ein erstes Fenster, eine Bandbreitengrenzenkennung für das erste Fenster und eine erste Gruppenkennung für das erste Fenster; eine zweite Fensterkennung für ein zweites Fenster, eine zweite Bandbreitengrenzenkennung für das zweite Fenster und eine zweite Gruppenkennung für das zweite Fenster; als Reaktion auf das Erhalten des Angebots eine Antwort an ein Netzwerk zur Übertragung liefert und Videoinhalt an ein Netzwerk zur Übertragung und zur Anzeige in dem ersten Fenster und dem zweiten Fenster liefert, wobei der ersten Gruppenkennung eine höhere Priorität zugewiesen ist als der zweiten Gruppenkennung mit niedrigerer Priorität, wobei die höhere Priorität anzeigt, dass Auflösungsreduktionen auf einen Inhalt zur Anzeige in Fenstern der Gruppe mit niedrigerer Priorität angewendet werden sollten, bevor Auflösungsreduktionen auf einen Inhalt zur Anzeige in Fenstern der Gruppe mit höherer Priorität angewendet werden, und wobei die erste Bandbreitengrenzenkennung eine Grenze zum Reduzieren der Auflösung von Videoinhalt zur Anzeige in Fenstern der Gruppe mit niedrigerer Priorität umfasst.
  7. Kommunikationseinrichtung nach Anspruch 6, wobei der ersten Gruppenkennung eine höhere Priorität zugewiesen ist als der zweiten Gruppenkennung, wobei die höhere Priorität anzeigt, dass Auflösungsreduktionen auf Inhalt zur Anzeige in Fenstern der zweiten Gruppe angewendet werden sollten, bevor Auflösungsreduktionen auf Inhalt zur Anzeige in Fenstern in der ersten Gruppe angewendet werden, wobei die Anwendung weiterhin: als Reaktion auf eine Bandbreitenbeschränkung die Auflösung von Inhalt zur Anzeige in Fenstern mit der zweiten Gruppenkennung bis zu der zweiten Bandbreitengrenze reduziert und als Reaktion auf eine Bandbreitenbeschränkung die Auflösung von Inhalt zur Anzeige in Fenstern mit der ersten Gruppenkennung bis zu der ersten Bandbreitengrenze reduziert.
  8. Computerlesbares Medium mit auf dem computerlesbaren Medium gespeicherten computerausführbaren Anweisungen, die bei Ausführung durch einen oder mehrere Prozessoren eines Computers bewirken, dass der Computer ein Verfahren zum Aushandeln einer Multimediasitzung durchführt, wobei das Verfahren Folgendes umfasst: Generieren, durch eine Client-Einrichtung, eines Angebots für eine Multimediakommunikationssitzung, wobei das Angebot mehrere Fensterkennungen für mehrere Fenster, eine Bandbreitengrenzenkennung für jedes der mehreren Fenster und eine Gruppenkennung für jedes der mehreren Fenster umfasst, wobei eine erste Gruppenkennung für einen ersten Abschnitt der mehreren Fenster von einer zweiten Gruppenkennung für einen zweiten Abschnitt der mehreren Fenster verschieden ist; Liefern des Angebots an ein Netzwerk zur Übertragung zu einem Server; Erhalten einer Antwort auf das Angebot von dem Server und Erhalten von Videoinhalt zur Anzeige in den mehreren Fenstern; wobei der ersten Gruppenkennung eine höhere Priorität zugewiesen ist als der zweiten Gruppenkennung mit niedrigerer Priorität, wobei die höhere Priorität anzeigt, dass Auflösungsreduktionen auf einen Inhalt zur Anzeige in Fenstern der Gruppe mit niedrigerer Priorität angewendet werden sollten, bevor Auflösungsreduktionen auf einen Inhalt zur Anzeige in Fenstern der Gruppe mit höherer Priorität angewendet werden, und wobei eine der ersten Gruppenkennung zugeordnete erste Bandbreitengrenzenkennung eine Grenze zum Reduzieren der Auflösung von Videoinhalt zur Anzeige in Fenstern der Gruppe mit niedrigerer Priorität umfasst.
  9. Computerlesbares Medium nach Anspruch 8, wobei der ersten Gruppenkennung eine höhere Priorität zugewiesen ist als der zweiten Gruppenkennung, wobei die höhere Priorität anzeigt, dass Auflösungsreduktionen auf Inhalt zur Anzeige in Fenstern der zweiten Gruppe angewendet werden sollten, bevor Auflösungsreduktionen auf Inhalt zur Anzeige in Fenstern in der ersten Gruppe angewendet werden.
DE102012013336.7A 2011-07-08 2012-07-06 Aushandeln einer kontinuierlichen multi-stream-präsenz Expired - Fee Related DE102012013336B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161505911P 2011-07-08 2011-07-08
US61/505,911 2011-07-08

Publications (2)

Publication Number Publication Date
DE102012013336A1 DE102012013336A1 (de) 2013-01-10
DE102012013336B4 true DE102012013336B4 (de) 2015-04-09

Family

ID=46766244

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102012013336.7A Expired - Fee Related DE102012013336B4 (de) 2011-07-08 2012-07-06 Aushandeln einer kontinuierlichen multi-stream-präsenz

Country Status (3)

Country Link
US (1) US8966095B2 (de)
DE (1) DE102012013336B4 (de)
GB (1) GB2494745B (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013153414A (ja) * 2011-12-28 2013-08-08 Ricoh Co Ltd コミュニケーション端末装置、コミュニケーションシステム、コミュニケーション通信状態表示方法及びプログラム
US9516079B2 (en) 2012-07-16 2016-12-06 Ricoh Company, Ltd. Media stream modification based on channel limitations
RU2580396C2 (ru) * 2014-04-04 2016-04-10 Александр Львович Шведов Способ проведения виртуальных совещаний, система для проведения виртуальных совещаний, интерфейс участника виртуального совещания
US9660926B2 (en) 2014-05-30 2017-05-23 Apple Inc. Multi-stream scheduling and requests
CN105376515B (zh) * 2014-09-02 2019-03-19 华为技术有限公司 用于视频通讯的通讯信息的呈现方法、装置及系统
FR3034608A1 (fr) * 2015-03-31 2016-10-07 Orange Procede de priorisation de flux medias dans un reseau de communications
US10075482B2 (en) * 2015-09-25 2018-09-11 International Business Machines Corporation Multiplexed, multimodal conferencing
US10126999B1 (en) 2016-09-23 2018-11-13 Apple Inc. Display scaling
US10038877B1 (en) * 2017-03-13 2018-07-31 Microsoft Technology Licensing, Llc Event conditioned views for teleconferencing sessions
CN107682752B (zh) * 2017-10-12 2020-07-28 广州视源电子科技股份有限公司 视频画面显示的方法、装置、系统、终端设备及存储介质
CN107948578B (zh) * 2017-12-28 2019-01-04 深圳华望技术有限公司 视频会议系统传送带宽及分辨率的调整方法及调整装置
CN111212261B (zh) * 2018-11-22 2021-07-20 浙江宇视科技有限公司 场景切换方法及装置
US11765213B2 (en) * 2019-06-11 2023-09-19 Nextiva, Inc. Mixing and transmitting multiplex audiovisual information
US11683356B2 (en) * 2020-07-27 2023-06-20 Microsoft Technology Licensing, Llc Intelligently identifying and promoting a meeting participant in an online meeting
CN117044191A (zh) * 2021-05-08 2023-11-10 聚好看科技股份有限公司 保存会议记录的方法、终端及服务器

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5880728A (en) * 1993-03-16 1999-03-09 Hitachi, Ltd. Video display controlling method for differentiating display quality between moving pictures
EP1578129A1 (de) * 2004-03-19 2005-09-21 Marconi Intellectual Property (Ringfence) Inc. Verfahren und Gerät für Konferenzen mit Selektion eines Datenstromes
DE60302561T2 (de) * 2002-03-27 2006-06-14 Marconi Intellectual Pty Telekommunikations system
WO2007067236A1 (en) * 2005-12-05 2007-06-14 Cisco Technology, Inc. Dynamically switched and static multiple video streams for a multimedia conference
US20090040289A1 (en) * 2007-08-08 2009-02-12 Qnx Software Systems (Wavemakers), Inc. Video phone system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60203779T2 (de) * 2002-01-23 2006-03-09 Sony International (Europe) Gmbh Ein Verfahren zur Übertragung von End-to-End QoS durch Anwendung des end-to-end negotiation protocols (E2ENP)
EP1414211A1 (de) * 2002-10-23 2004-04-28 Sony International (Europe) GmbH Software-Architektur für Verhandlung von Dienstqualität und Fähigkeit und für Sitzungsaufbau für verteilte Multimedia Anwendungen
BRPI0418942B1 (pt) * 2004-07-09 2018-05-29 Telefonaktiebolaget Lm Ericsson Método para prover serviços diferentes em um sistema de comunicação de multimídia, e, servidor de aplicativo em um sistema de comunicação de multimídia
US7475112B2 (en) 2005-03-04 2009-01-06 Microsoft Corporation Method and system for presenting a video conference using a three-dimensional object
US20060215630A1 (en) * 2005-03-25 2006-09-28 Cherng-Daw Hwang Feature scalability in a multimedia communication system
DE102005050587A1 (de) * 2005-10-21 2007-05-03 Siemens Ag Verfahren zum Weiterleiten von Signalisierungsdaten in einer Netzübergangseinheit und in einer Steuereinheit sowie zugehörige Einheiten
DE102005050586B3 (de) * 2005-10-21 2006-11-02 Siemens Ag Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
DE102005050588B4 (de) * 2005-10-21 2010-07-08 Siemens Ag Signalisierung bezüglich des Aufbaus von H.324 Videotelefonie zwischen einer Mediagateway und einem Controller
JP2011082867A (ja) * 2009-10-08 2011-04-21 Sharp Corp 通信装置及び通信会議システム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5880728A (en) * 1993-03-16 1999-03-09 Hitachi, Ltd. Video display controlling method for differentiating display quality between moving pictures
DE60302561T2 (de) * 2002-03-27 2006-06-14 Marconi Intellectual Pty Telekommunikations system
EP1578129A1 (de) * 2004-03-19 2005-09-21 Marconi Intellectual Property (Ringfence) Inc. Verfahren und Gerät für Konferenzen mit Selektion eines Datenstromes
WO2007067236A1 (en) * 2005-12-05 2007-06-14 Cisco Technology, Inc. Dynamically switched and static multiple video streams for a multimedia conference
US20090040289A1 (en) * 2007-08-08 2009-02-12 Qnx Software Systems (Wavemakers), Inc. Video phone system

Also Published As

Publication number Publication date
US20130010049A1 (en) 2013-01-10
GB2494745B (en) 2015-11-11
GB2494745A (en) 2013-03-20
DE102012013336A1 (de) 2013-01-10
GB201212036D0 (en) 2012-08-22
US8966095B2 (en) 2015-02-24

Similar Documents

Publication Publication Date Title
DE102012013336B4 (de) Aushandeln einer kontinuierlichen multi-stream-präsenz
DE60038516T2 (de) Verfahren und System zum Bandbreitenreduktion von Multimedien-Konferenzen
EP2837154B1 (de) Verfahren zur steuerung von datenströmen einer virtuellen sitzung mit mehreren teilnehmern, kollaborationsserver, computerprogramm, computerprogrammprodukt und digitales speichermedium
DE60130665T2 (de) Audiodatenverarbeitung
DE602004004852T2 (de) Audio-Videokonferenz unter Verwendung inhaltsbasierten Berichtübertragung
DE10191806B4 (de) Medien-Rollenverwaltung in einem Videokonferenznetz
DE69927713T2 (de) Angekündigte Sitzungsbeschreibung
DE60320181T2 (de) Vorrichtung und Verfahren zur Projektion von Daten
DE112006001922T5 (de) Verfahren und Vorrichtung zur Vergabe von Zugangsberechtigungen ("Floor-Control") in einem Kommunikationssystem
DE102020125616A1 (de) Datenschutz beim screen sharing während einer webkonferenz
DE112015002650B4 (de) Systeme und Verfahren zur prädiktiven Auslieferung von Inhalten mit hohen Bitraten zur Wiedergabe
DE102012001394A1 (de) Gemeinsamer Medienzugang für Echtzeit-Erst- und Drittparteisteuerung
DE102011114277B4 (de) Globaler Konferenzplan für verteilte Brücken
EP2930926A1 (de) Verfahren, Softwareprodukt und Vorrichtung zur Steuerung einer Konferenz
EP1855437A1 (de) Verfahren zum Aufbau einer Push-to-talk-Kommunikationsverbindung
DE102013110614B4 (de) Skalierbares Mehrteilnehmervideokonferenzsystem
DE69912456T2 (de) Verfahren und Vorrichtung zur Steuerung einer Fernmeldekonferenz
EP2938047A1 (de) Verfahren, vorrichtung, computerprogramm, softwareprodukt und digitales speichermedium zur übermittlung und adaption von daten
DE60320099T2 (de) Vorrichtung und verfahren zum verteilen von gestreamten echtzeit-informationen zwischen clients
WO2016059257A1 (de) Verfahren zur anpassung eines zu übertragenden datenstroms an eine ressourcenauslastung
DE102021213661A1 (de) Systeme und verfahren zur anzeidge von benutzern, die an einer kommunikationssitzung teilnehmen
DE10146347A1 (de) Verfahren zum Übertragen eines Datenstroms von einem Produzenten an eine Mehrzahl von Zuschauern
DE102018121566B4 (de) Computer-implementiertes Verfahren zum Durchführen einer Konferenz in einem virtuellen Konferenzraum und Kollaborations- und Konversationsplattform
DE102017110431A1 (de) Verfahren zum Übertragen von Informationen
AT511151A1 (de) Verfahren und vorrichtung zur audio- und videobasierten echtzeit-kommunikation

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee