WO2016037677A1 - Verfahren zur steuerung einer multimedia-anwendung, softwareprodukt und vorrichtung - Google Patents

Verfahren zur steuerung einer multimedia-anwendung, softwareprodukt und vorrichtung Download PDF

Info

Publication number
WO2016037677A1
WO2016037677A1 PCT/EP2015/001639 EP2015001639W WO2016037677A1 WO 2016037677 A1 WO2016037677 A1 WO 2016037677A1 EP 2015001639 W EP2015001639 W EP 2015001639W WO 2016037677 A1 WO2016037677 A1 WO 2016037677A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
multimedia
terminal
application
operating state
Prior art date
Application number
PCT/EP2015/001639
Other languages
English (en)
French (fr)
Inventor
Jürgen Totzke
Karl Klug
Viktor Ransmayr
Original Assignee
Unify Gmbh & Co. Kg
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 Unify Gmbh & Co. Kg filed Critical Unify Gmbh & Co. Kg
Priority to US15/505,183 priority Critical patent/US10581946B2/en
Priority to EP15756555.7A priority patent/EP3186971A1/de
Priority to CN201580045624.8A priority patent/CN106576185A/zh
Publication of WO2016037677A1 publication Critical patent/WO2016037677A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing 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/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/4424—Monitoring of the internal components or processes of the client device, e.g. CPU or memory load, processing speed, timer, counter or percentage of the hard disk space used
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server

Definitions

  • the invention relates to methods for controlling a multimedia application, a method for adapting and transmitting multimedia data, a related software product and a related device.
  • Multi-media collaboration, (business) social networks, online games and the like are increasingly using multiple communication and data channels simultaneously.
  • a related, emerging technology is WebRTC (RTC stands for Real Time Communication).
  • RTC Real Time Communication
  • bandwidth may be limited or fluctuated by the shared medium and interference.
  • the mobile devices used often have only a limited display area (small display), which can not represent the simultaneously offered communication and data channels with reasonable resolution.
  • a first aspect of the present invention relates to a method for controlling a multimedia application on a particular mobile terminal, wherein multimedia data is received from a remote source and processed for display on a display of the terminal, comprising the steps of: a) detecting an operating state of at least one service component of the multimedia application relating to the representation of the data of the multimedia application
  • an information characterizing the status information which characterizes the maximum processable data density predetermined by the operating state of the service component for the presentation of the multimedia data, and / or
  • the present invention assumes that a multimedia application will provide two pages, namely a source domain from which multimedia content will be provided (and transmitted) to the application, and a
  • the terminal may be the sink and, for example, a server (download server, game server, conference server) may be the source.
  • a server download server, game server, conference server
  • switching centers can also be provided both as (intermediate) sink and (intermediate) source.
  • the method of the present aspect relates to the sink side, in particular the side of the terminal.
  • the transmitter side (the remote source) is enabled to adjust the generation, conditioning and transmission of the data based on the state of the service component.
  • resources can be optimally utilized on the side of the terminal (but also the source).
  • the terminal may preferably be mobile, but there are also stationary applications conceivable.
  • mobile means that the terminal can communicate by means of mobile radio methods. Examples of mobile devices are for example smartphone, tablet, laptop.
  • a stationary terminal such as a personal computer or the like means that the transmission or reception of all or part of the data may additionally or alternatively be via a stationary network.
  • the multimedia data may be processed for presentation on any display of the terminal connected to the terminal and / or permanently installed in the terminal.
  • known operating status may be the mere fact of activating or deactivating the component, but may also include details such as a battery level, attached or active displays, or the like.
  • Service components may include, but are not limited to, those for audio playback, video playback, screen sharing, joint editing, gaming, etc., in hardware and / or software.
  • the service component may be permanently installed and / or installed on the terminal.
  • the message may include the status information and / or information characterizing the status information, which characterizes the maximum processable data density predefined by the operating state of the service component for displaying the multimedia data.
  • a data density can be understood in particular to be a data rate.
  • a data rate may be defined as a data amount per unit of time.
  • the processing intelligence and decision-making competence on the data source side is assumed and exploited, which can save resources on the terminal side.
  • the transmission of the message can for example be transmitted or received via RTC, in particular via a mobile radio standard, to the remote source.
  • the processing intelligence and decision-making competence on the side of the terminal is assumed, which can make the terminal more independent.
  • the message comprising the status information identifying information indicating the maximum processable data density given by the operating state of the service component for displaying the multimedia data
  • a processing intelligence is assumed at least in high proportion on the side of the terminal to the maximum processable data density while the decision on the action to be taken to adapt data delivery and transmission to the maximum workable data density is made on the source side.
  • the remote source is also caused, on the basis of the recognized operating state, to transmit the data (at most) with the maximum data density that can be processed by the terminal.
  • the terminal receives the data (at most) with the maximum data density that can be processed by the terminal.
  • a development of the method of this aspect of the invention can provide that the operating state is detected by a first application programming interface (API, in particular device API) and the state information is processed by a second application programming interface (API, in particular control API), wherein the application, to which the second application programming interface is assigned, preferably implemented in a WebRTC-capable web browser of the terminal, and wherein preferably the second application programming interface generates the message or causes a particular RTC-capable server to generate the message.
  • a server in particular an RTC-enabled communication server can be used.
  • the method may be configured to address the message to a remote application programming interface (API, particularly control API) of the remote source.
  • a preferred embodiment of the method of this aspect of the invention may provide for presenting the data according to a design pattern (MVC) with a model containing the data (M), a view (V) as a presentation layer representing the data, and a controller (C) as a control layer is implemented for managing the presentation layer, wherein the state information is generated by the controller (C), wherein preferably the operating state is implemented in the model (M).
  • MVC design pattern utilized in accordance with the present invention a view is a presentation layer that is also responsible for receiving user interactions. She knows both her controller and the model whose data she presents, but she is not responsible for the further processing of the user-supplied data.
  • a controller in the sense of the MVC design pattern used in the present invention is a controller that manages one or more presentations, and which also possibly from accept user actions, evaluate them and act accordingly. Each presentation can have its own control.
  • the controller may also cause user actions to take effect, e.g. By modifying the presentation (eg, moving the window) or by passing it to the model (eg, taking input data or triggering processing).
  • the controller may also include mechanisms to limit the user interactions of the presentation.
  • the controller may also become an "observer” of the model in some implementations to directly manipulate the view as the data changes.)
  • the above explanation of the MVC design pattern follows the Wikipedia entry "Model_View_Controller”, which is for further understanding According to the present invention, since the state information is generated by the controller (C), the existing MVC pattern can be exploited, and the control layer undergoes extension.
  • a further development of the method of this embodiment can provide for the second application programming interface to be registered in the design pattern as an additional view for the service components it controls, wherein the operating state is preferably fed to the model via the first application control interface.
  • a development of the method of this aspect of the invention may provide that the instruction regarding the adaptation of the data and / or transmission of the data to the terminal concerns at least one of the following measures:
  • a second aspect of the present invention relates to a method for controlling an adaptation and transmission of multimedia data to a remote sink, in particular to a preferably mobile terminal, with the steps:
  • a remote sink may be a terminal, in particular the terminal of the first aspect of the invention, or an intermediate station (eg router, telecommunications system, server). It is preferably provided that the message is transmitted or received via RTC, in particular via a mobile radio standard, to the remote source.
  • an instruction included in the message may be recognized and may be executed according to the content of the instruction
  • the decision intelligence may be at least partially adopted on the sink side.
  • a further development of the method of this aspect of the invention can provide for the message to be received by an application programming interface (API, in particular control API), wherein an application associated with the application programming interface is preferably implemented in a WebRTC-enabled web browser.
  • API application programming interface
  • the multimedia data are transmitted via one of the application Programming interface for receiving the message various interface, in particular a media engine for encoding or decoding of Rule Scheme streams the Web browser, transmitted.
  • a third aspect of the present invention relates to a method for controlling a multimedia application on a particular mobile terminal, wherein multimedia data of the multimedia application is transmitted from a source domain to a sink domain through which sinking domain is received and processed for display on a display of the terminal the multimedia data are adapted and / or transmitted as a function of an operating state of at least one service component of the multimedia application, the method preferably comprising the method steps of the above described method according to the first aspect of the invention and / or of the above-described method according to the second aspect of the invention.
  • this aspect of the invention relates to a system comprising the source and sink sides. In this aspect of the invention, it can also be ensured that the data is transmitted from the source to the sink (at most) with the maximum data density that can be processed by the terminal (sink).
  • a fourth aspect of the present invention relates to a software product stored on a computer-readable medium and which preferably can be loaded directly into the internal memory of a computer and the program codes of a computer program comprising a computer for carrying out the method steps of at least one of the above described method according to the first, second or third aspect of the invention enabled when the computer program is executed on the computer has.
  • a fifth aspect of the present invention relates to an apparatus for carrying out at least one of the above-described methods according to the first, second or third aspect of the invention, wherein the apparatus Preferably, in particular a mobile terminal, and / or a server, in particular gaming server or conference server, and / or a conference unit comprises, and wherein the device is in particular capable of implementing the method by implementing the software product according to the fourth aspect of the invention.
  • the invention may also be embodied by a computer program comprising program instructions that cause a computer to perform the method steps of at least one of the above-described methods according to the first, second or third aspect of the invention when the computer program is loaded on or executed by the computer, and / or or a digital storage medium having electrically readable control signals that can operate with a programmable computer to manage communications, wherein the control signals are adapted and adapted to cause the computer to perform the method steps of at least one of the above-described first, second, or third methods Embodiment of the invention to be embodied.
  • FIG. 1 a source and sink domain generic reference architecture is shown as an embodiment of an apparatus according to the present invention.
  • a source domain (Domain 1) 100 includes a media source (Client Media Source) 110, an HTTP / Web server 120, a Real-Time Collaboration Server 130, a Session Border Controller (SBC) 140 and a STUN & TURN server 150 (STUN / TURN: Session Traversal Utilities for NAT (Network Address Translation) / Traversal Using Relays around NAT).
  • the media source 110 is considerably implemented by a device 111.
  • the device 111 includes a web browser 112 in which a WebRTC-enabled application (WebRTC App) 113 is implemented with an MVC (Model View Controller) design pattern 114.
  • WebRTC App WebRTC-enabled application
  • MVC Model View Controller
  • the application 113 is connected to the HTTP / Web server 120 via a connection 121 with a suitable protocol, such as HTML 5 / JS, and communicates with peripheral devices of the device 111 via a Device Application Programming Interface (Device API) 115. Further, a control application programming interface (Control API) 116 of the application 113 communicates with the communication server 130 via a connection 131 with a proprietary protocol such as "RESTfuI over Websockets" (REST: Representational State Transfer).
  • the web browser 112 further includes a media interface 117 in communication with the STUN & TURN server 150.
  • the term collaboration includes, but is not limited to, communication.
  • a Domain 2 Domain 200 is essentially the same as Source Domain 200 in terms of the features pertaining to the present invention.
  • the destination domain 200 includes a media sink (client media sink) 210, an HTTP / web server 220, a real-time collaboration server 230, a session border controller 240, and a STUN & TURN server 250.
  • the media sink 210 is essentially implemented by a device 211.
  • the device 211 includes a web browser 212 in which a WebRTC-enabled application (WebRTC App) 213 having an MVC (Model View Controller) design pattern 214 is implemented.
  • the application 213 is connected to the HTTP / Web server 220 via a connection 221 with a suitable protocol and communicates with peripheral devices of the device 211 via a Device Application Programming Interface (Device API) 215.
  • a control API Device Application Programming Interface
  • Control API Application programming interface
  • the web browser 212 further includes a media interface 217 that communicates with the
  • STUN & TURN server 250 communicates.
  • the protocols used may correspond to the protocols used in the source domain 100.
  • the collaboration servers 130, 230 serve in the context of the present invention primarily as a communication server, but can also realize other collaboration functions.
  • Source domain 100 and destination domain 200 are interconnected over multiple data links.
  • the communication servers 130, 230 of the source domain 100 and the destination domain 200 are interconnected by a data link 400, with the session border controllers 140, 240 of the source domain 100 and the destination domain 200 each acting as an interface to the outside.
  • the data connection 400 uses, for example, Session Protocol SIP-T or XMPP with SDP Offer / Answer for connecting further domains (federation).
  • the STUN & TURN servers 150, 250 of the source domain 100 and the destination domain 200 for realizing an RTP connection 500 are interconnected between the media interfaces 117, 217 of the source domain 100 and the destination domain 200 and are the media interfaces 117, 217 of the source domain 100 and the Target domain 200 is also directly interconnected via a SCTP (Stream Control Transmission Protocol) connection 700.
  • SCTP Stream Control Transmission Protocol
  • the destination domain 200 or its device level 211 corresponds to a (mobile) terminal.
  • the source domain 100 or its device level 111 can be, for example, a media server. It should be understood that in the generic architecture of FIG. 1, individual elements of the respective domain 100, 200 may be located in the respective physical device 111, 211 or outside.
  • FIGS. 2A and 2B illustrate the structure of the WebRTC browsers 112, 214 of the source domain 100 and the destination domain 200 in more detail, respectively.
  • 2A is a schematic representation of a possible integration into a source-side implementation of the WebRTC application 113 of this embodiment
  • FIG. 2B is a schematic representation of a possible integration into a sink-side implementation of the WebRTC application 213 of this Embodiment.
  • FIGS. FIGS. 2A and 2B may be understood as details of FIG.
  • the media interface 117 of the web browser 112 of the source domain 100 comprises a WebRTC-enabled application programming interface (WebRTC API) 117a and a media engine 117b.
  • WebRTC API WebRTC-enabled application programming interface
  • the media engine 117b on the source domain 100 side may act as an encoder for transmitted media data streams.
  • a camera / microphone unit (camera / microphone) 160 is connected to the device application programming interface 115.
  • the media interface 217 of the web browser 212 of the destination domain 200 includes a WebRTC-enabled application programming interface (WebRTC API) 217a and a media engine 217b.
  • WebRTC API application programming interface
  • the media engine 217b on the side of the destination domain 200 can operate as a decoder for received media data streams.
  • a camera / microphone unit (Camera / Microphone) 260, a human interaction device 270 for detecting interactions of an operator 900, and other hardware sensors 280 are connected to the device application programming interface 215.
  • the MVC design pattern 214 has a model M, a view V, and a controller C, as explained above.
  • Model “M” receives input data from Device API 215 and WebRTC Media Engine 217b.
  • the view “V” controls the display of a view on a screen-sound 290.
  • the controller “C” also receives input data from the device API 215 and provides output data for the control API 216.
  • the control API 216 is also connected to the WebRTC API 217a and the Device API 215. As shown in Figs.
  • the RTP connection 500 and the SCTP connection 700 are established between the media interface 117 of the WebRTC browser 112 of the source domain 100 and the media interface 217 of the WebRTC browser 212 of the destination domain 200.
  • the unidirectional RTP connection 500 runs at the source and sink sides via a STUN & TURN server 150, 250, respectively, while the bidirectional SCTP connection 700 runs directly between the media interfaces 117, 217.
  • the STUN & TURN servers 150, 250 may be omitted in design variants or be limited to STUN or TURN functions.
  • the RTP connection 500 and the SCTP connection 700 may optionally be used, and in embodiments, only one of them may be present.
  • a specific WebRTC application 213 on the (mobile) terminal 210 is started by selecting a corresponding URL in an HTML5 / JavaScript (JS) -enabled browser 212, and then the application server (HTTP / Web server) 220 becomes the actual application logic loaded via JS in the browser 212. Then, first a Websocket connection 231 to the respective RTC server 130, 230 is established and the proprietary protocol - usually designed as RESTFUI protocol - started.
  • JS JavaScript
  • the addresses of the remote device 110 to be communicated with are transmitted via the proprietary and the session protocol (which is optionally guided via one or more session border controllers).
  • the participating devices that transmit media as a source ie, in the illustrated embodiment, the device 111 of the source domain 100, build by means of the Web RTC API 117, the respective uni-directional RTP connections 500 for the transmission of voice, video and screen sharing example as streamed video in the forward direction.
  • the bi-directional SCTP connection 700 can be established.
  • respective STUN & TURN servers 150, 250 are involved in the connection setup in the RTP channel 500.
  • the media received by the device of the source domain, moving image of the camera and the screen are encoded according to the negotiated in the session protocol encoding method by the source-side media engine 117b and via the respective one RTP connection 500 (again here on the
  • the receiving device ie, the lower-end media engine 217b, decodes the media streams and presents them via the application logic to the corresponding local device output resources, here the speaker and screen as the picture-sound playback unit 290, according to the user-selected representation.
  • the application logic typically implements the view as a Model View Controller (MVC) design pattern.
  • MVC controller "C” or the MVC model "M” receives the knowledge of the current view "V.
  • the video display and the display screen The user will therefore, for example, switch to a desktop sharing view through interaction (Human Interaction Device 270), which is detected by the MVC 214 and determined that the camera motion picture is no longer displayed informs, for example via a callback function, a remote media (suspend) message 219 for this video connection to the local (sink) WebRTC server 230.
  • the latter forwards this information via the selected and according to the invention extended session protocol 400 to the remote (source) WebRTC server 30 w
  • the remote WebRTC server 130 forwards this message to the control API 116 of its locally connected browser 112.
  • the application logic of the local WebRTC app 13 then switches off the media stream from the camera 160 via the local DeviceAPI 111 by means of a getUserMedia instruction 119, but receives the associated RTP connection 500 upright. Possibly. the associated encoder (source-side media engine 117b) generates a replacement medium, such as a still image, with significantly reduced bandwidth requirements.
  • the application logic of the local WebRTC app 113 then switches on the media flow from the camera 190 again via the local DeviceAPI 115 using getUserMedia 119.
  • the encoder then delivers the accustomed media stream.
  • the screen sharing transmitted as a moving picture can be suspended by analog method, and so on.
  • the resources used and the RTP (SCTP) connections are released or cleared regardless of the suspension status.
  • FIG. 2B shows a possible integration into a client-side implementation of a WebRTC application 213 by the inventive extension of the MVC 214.
  • the control API 216 according to the invention is triggered by the controller "V” if the view “V” is triggered. has changed so that there is a change in the use of media streams established through the WebRTC API 217a.
  • the controller "C” can also propagate signals from the device environment such as display off, low battery status, etc.
  • the control API 216 transmits this to the WebRTC server 230, which in turn transmits this to the remote WebRTC server 130 forwards (not shown).
  • the received media streams can still be switched off locally, the Part of the model "M" are.
  • the control system then removes the media streams to be sent or modifies them in a resource-saving manner.
  • the local device API 216 detects this, and if not already explicitly processed locally, the local model "M" is updated accordingly.
  • the application logic may also be at least partially disposed on the source 100 side.
  • a message containing the state information itself can also be generated, and the specifications for adapting the data and / or transmitting the data to the maximum processable data density predetermined by the operating state of the service component to display the multimedia data can be determined by the WebRTC application 113 of the source 100 and then - via getUserMedia - implemented.
  • the generated message may have information characterizing the status information, which characterizes the maximum processable data density prescribed by the operating state of the service component for displaying the multimedia data.
  • a multi-media application for example a collaboration session
  • the associated communication components are also started simultaneously.
  • connections for audio A / video components, application-sharing components and possibly other communication channels are established bi-directionally.
  • the data sources begin to encode the data and communication streams, regardless of whether they are processed by the data sink and their decoding is presented.
  • network bandwidths are unnecessarily used and, in addition, unnecessary energy is consumed at the transmitting and receiving device, which shortens battery runtimes in mobile terminals.
  • a video conference and a remote screen with reasonable resolution can not be displayed simultaneously on a smartphone or tablet PC with a smaller screen size.
  • delivery control over a (mobile) data network of multi-media service components is provided by feedback of user views and interactions to the (mobile) destination device
  • the conferencing systems are used according to the invention in terms of the source domain 100 and implement adequate functionality in a proprietary manner.
  • connection protocols and user connections of the service components which are extended according to the invention can also be implemented via gateway or proxy systems.
  • the inventively extended session protocol can optionally be performed via an SBC 140, 240.
  • Representations on devices are often implemented using the Model-View-Controller (MVC) design pattern.
  • MVC Model-View-Controller
  • the view via the controller controls which data is displayed from the model according to user interaction, and vice versa, the view can be updated if the controller observes the data.
  • the MVC implementation pattern can be used for both web applications, native clients, and gadgets. The controller thus has the knowledge of which section of the model is actually being used.
  • the model includes, among other things, the service components such as audio, video, screen sharing, joint editing, and gaming.
  • the model has the knowledge of which components are active and required from the perspective of the view.
  • the controller also has an overview of which service components are active and can thus provide meaningful combinations according to the invention.
  • the controller may cause the video connection to be shut down while continuing to use the audio connection.
  • inventively extended model with knowledge of active and inactive service components can inform according to the invention for the respective service component, for example via an inventively extended control API 216 of the WebRTC App 213 in the client 210, which in turn the inventive call-back function "RemoteMedia ⁇ Suspend
  • the control API 216 may register as an additional "view" of the service components it controls.
  • the sink WebRTC server 230 may, in accordance with the present invention, signal to the source WebRTC server 130 via a suitable implicitly or explicitly extended connection protocol 400 that supports the function "RemoteMedia ⁇ suspend
  • the Source WebRTC Server 130 may then in turn, via its local control API 116, control the corresponding data source 110 (eg, via the Device API: getUserMedia 119) to stop, suspend, resume, resume, increase, or increase the transmission of data to mask the data stream through a replacement medium or replace a mask with the original data stream, etc. That is, the medium may be provided in lesser quality or a replacement medium to avoid possible disconnections due to inactivity.
  • An explicit extension of the protocols used according to the invention has the advantage that affected components can only be suspended or quickly reactivated without having to set up the connection again (for example, today as planned via SDP: Offer / Answer), and thus the associated latency can be reduced.
  • the inventive controller "C” e.g.
  • the MVC 214 has an overview of which service components are active and can thus provide useful combinations according to the invention.
  • the controller "C” can thus further optimize useful combinations of service components, for example by switching off the video component or, for example, by transmitting a (last) still image to the view "V" which was previously additionally generated and stored at regular intervals in the model "M", and only the audio component is used.
  • the components of the extended client-side MVC 214 according to the invention can also be distributed via a back-end server, for example via the http / Web server 220, with the exception of the controller "C".
  • the application logic can be implemented on the client side in the browser by the JavaScript download. Alternatively, it provides the application server and interacts with the client-side implementation of the MVC.
  • the features of the invention described with reference to the illustrated embodiments, eg the inventive extension of the MVC model 214 on the side of the low side WebRTC app 213, may also be used in other embodiments and / or modifications of the invention, for example, in addition to or as an alternative to an extension of the MVC model 114 on the side of the source-side WebRTC app 113 for, for example, source-side determination of the maximum data content that can be processed on the lower side, unless it is specified otherwise or bans itself for technical reasons.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Ein erster Gesichtspunkt der vorliegenden Erfindung betrifft ein Verfahren zur Steuerung einer Multimedia-Anwendung auf einem insbesondere mobilen Endgerät, wobei multimediale Daten von einer entfernten Quelle empfangen werden und zur Darstellung auf einer Anzeige des Endgeräts verarbeitet werden, mit den Schritten: a) Erkennen eines Betriebszustands wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente des Endgeräts; b) Erzeugen einer den Betriebszustand der wenigstens einen Servicekomponente kennzeichnenden Zustandsinformation; c) Erzeugen einer Nachricht, umfassend: die Zustandsinformation, und/oder eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, und/oder eine Anweisung an die entfernte Quelle bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät, um die Daten und/oder die Übertragung der Daten an die durch den Betriebszuständ der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten anzupassen; d) Übertragen der Nachricht an die entfernte Quelle; e) Empfangen der multimedialen Daten; und f) Verarbeiten der multimedialen Daten zur Darstellung auf der Anzeige des Endgeräts. Die Erfindung betrifft auch ein Verfahren zur Anpassung und Übertragung von multimedialen Daten, ein Softwareprodukt und eine Vorrichtung.

Description

Verfahren zur Steuerung einer Multimedia-Anwendung,
Softwareprodukt und Vorrichtung
Die Erfindung betrifft Verfahren zur Steuerung einer Multimedia-Anwendung, ein Verfahren zur Anpassung und Übertragung von multimedialen Daten, ein diesbezügliches Softwareprodukt und eine diesbezügliche Vorrichtung.
Multi-mediale Kollaboration, (geschäftliche) Soziale Netzwerke, Online- Spiele und dergleichen nutzen zunehmend mehrere Kommunikations- und Datenkanäle gleichzeitig. Eine dazugehörige, neu entstehende Technologie ist WebRTC (RTC steht für Real Time Communication, also Echtzeitkommunikation). Solange genügend Bandbreite, z.B. über Festnetz, zur Verfügung steht, ist dies auch problemlos möglich. Im mobilen Internet oder WLAN (Wireless LAN) kann die Bandbreite durch das geteilte Medium und Empfangsstörungen jedoch begrenzt sein oder schwanken. Zudem haben die eingesetzten mobilen Geräte oft nur eine begrenzte Darstellungsfläche (kleines Display), die die gleichzeitig angebotenen Kommunikations- und Datenkanäle nicht mit sinnvoller Auflösung darstellen kann.
Derzeit stehen die Ressourcenverwaltung und Dienstgütebetrachtungen für derar- tig gebündelte multi-mediale Kommunikationsformen erst am Anfang und es gibt für das oben beschriebene Problem noch keine technische Lösung. Daher muss eine schlechte Nutzererfahrung und eine Vergeudung von Netzressourcen, deren übermittelte Inhalte gar nicht sinnvoll nutzbar sind oder genutzt werden, meist hingenommen werden.
Von Betriebssystemen wie iOS von Apple oder Android ist bekannt, dass Applikationen im Hintergrund gestoppt werden, wenn das System an Grenzen stößt. Dies ist aber eine rigorose Notlösung, die zu unerwünschtem Verhalten des Geräts führen kann.
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren, ein Softwareprodukt und eine Vorrichtung anzugeben, die in der Lage sind, die vorstehenden Nachteile im Stand der Technik wenigstens teilweise zu überwinden. Insbesonde- re besteht eine Aufgabe der vorliegenden Erfindung darin, ein Verfahren, ein Softwareprodukt und eine Vorrichtung anzugeben, die in der Lage sind, verfügbare Netzbandbreiten ohne Beeinträchtigung der Nutzererfahrung optimiert zu nutzen.
Die Aufgabe wird erfindungsgemäß wenigstens in Teilaspekten durch die Merkmale der unabhängigen Ansprüche, welche Verfahren zur Steuerung einer Multimedia-Anwendung, ein Verfahren zur Anpassung und Übertragung von multimedialen Daten, ein diesbezügliches Softwareprodukt und eine diesbezügliche Vorrichtung betreffen, gelöst. Vorteilhafte Ausführungsformen und Weiterentwicklungen der Erfindung sind in den Unteransprüchen angegeben.
Ein erster Gesichtspunkt der vorliegenden Erfindung betrifft ein Verfahren zur Steuerung einer Multimedia-Anwendung auf einem insbesondere mobilen Endge- rät, wobei multimediale Daten von einer entfernten Quelle empfangen werden und zur Darstellung auf einer Anzeige des Endgeräts verarbeitet werden, mit den Schritten: a) Erkennen eines Betriebszustands wenigstens einer die Darstellung der Da- ten der multimedialen Anwendung betreffenden Servicekomponente des
Endgeräts; b) Erzeugen einer den Betriebszustand der wenigstens einen Servicekomponente kennzeichnenden Zustandsinformation; c) Erzeugen einer Nachricht, umfassend:
die Zustandsinformation, und/oder
eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, und/oder
eine Anweisung an die entfernte Quelle bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät, um die Daten und/oder die Übertragung der Daten an die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten anzupassen; d) Übertragen der Nachricht an die entfernte Quelle; e) Empfangen der multimedialen Daten; und f) Verarbeiten der multimedialen Daten zur Darstellung auf der Anzeige des Endgeräts.
Die vorliegende Erfindung geht davon aus, dass eine Multimedia-Anwendung zwei Seiten, nämlich eine Quellenseite bzw. Quellendomäne, von der aus Multimedia- Inhalte für die Anwendung bereitgestellt (und übermittelt) werden, und eine
Senkenseite bzw. Senkendomäne, an der die Multimedia-Inhalte weiterverwendet werden, umfasst. Im Wesentlichen kann das Endgerät die Senke sein und kann beispielsweise ein Server (Download-Server, Spieleserver, Konferenzserver) die Quelle sein. Es können aber auch Vermittlungsstellen sowohl als (Zwischen- )Senke und (Zwischen-)Quelle vorgesehen sein. Das Verfahren des vorliegenden Gesichtspunkts betrifft die Senkenseite, insbesondere die Seite des Endgeräts.
Mit dem erfindungsgemäßen Verfahren dieses Gesichtspunkts wird die Senderseite (die entfernte Quelle) in die Lage versetzt, die Erzeugung, Aufbereitung und Übertragung der Daten auf der Grundlage des Zustands der Servicekomponente anzupassen. Dadurch können wiederum Ressourcen auf der Seite des Endgeräts (aber auch der Quelle) optimal ausgenutzt werden. Das Endgerät kann vorzugsweise mobil sein, es sind aber auch stationäre Anwendungen denkbar. Mobil heißt insbesondere, dass das Endgerät mittels Mobilfunkverfahren kommunizieren kann. Beispiele für mobile Endgeräte sind beispielsweise Smartphone, Tablet, Laptop. Ein stationäres Endgerät wie etwa ein PC oder dergleichen bedeutet, dass die Übertragung bzw. der Empfang aller oder von Teilen der Daten zusätzlich oder alternativ über ein stationäres Netz erfolgen kann. Die multimedialen Daten können zur Darstellung auf jeder Anzeige des Endgeräts verarbeitet werden, die mit dem Endgerät verbunden und/oder in dem Endgerät fest eingebaut ist. Der er- kannte Betriebszustand kann beispielsweise die bloße Tatsache der Aktivierung oder Deaktivierung der Komponente sein, kann aber auch Details wie etwa einen Batterieladestand, angeschlossene bzw. aktive Displays oder dergleichen umfassen. Servicekomponenten können beispielsweise, aber nicht nur, solche zur Audiowiedergabe, Videowiedergabe, Screen-Sharing, Joint Editing, Gaming etc. in Hardware und/oder Software sein. Die Servicekomponente kann auf dem Endgerät fest eingebaut und/oder installiert sein. Erfindungsgemäß kann die Nachricht die Zustandsinformation und/oder eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vor- gegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, umfassen. Unter einer Datendichte kann im Sinne der Erfindung insbesondere eine Datenrate verstanden werden. Eine Datenrate kann insbesondere als eine Datenmenge je Zeiteinheit definiert sein. Wenn die Nachricht die Zustandsinformation enthält, wird die Verarbeitungsintelligenz und Ent- Scheidungskompetenz auf der Seite der Datenquelle unterstellt und ausgenutzt, was Ressourcen auf der Endgeräteseite einsparen kann. Die Übertragung der Nachricht kann beispielsweise über RTC, insbesondere über einen Mobilfunkstandard, an die entfernte Quelle übertragen bzw. empfangen werden. Wenn die Nachricht die Anweisung enthält, wird die Verarbeitungsintelligenz und Entschei- dungskompetenz auf der Seite des Endgeräts vorausgesetzt, was das Endgerät unabhängiger machen kann. Wenn die Nachricht, die die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, aufweist, wird eine Verarbeitungsintelligenz wenigstens in hohem Anteil auf der Seite des Endgeräts vorausgesetzt, um die maximal verarbeitbare Datendichte zu ermitteln, während die Entscheidung über die zu treffenden Maßnahmen, um die Datenbereitstellung und -Übertragung an die maximal verarbeitbare Datendichte anzupassen, auf der Seite der Quelle getroffen wird.
Bei diesem Erfindungsgesichtspunkt wird mit anderen Worten auch die entfernte Quelle aufgrund des erkannten Betriebszustands veranlasst, die Daten (höchstens) mit der durch das Endgerät maximal verarbeitbaren Datendichte zu übertra- gen. D.h., das Endgerät empfängt die Daten (höchstens) mit der durch das Endgerät maximal verarbeitbaren Datendichte.
Eine Weiterbildung des Verfahren dieses Erfindungsgesichtspunkts kann vorse- hen, dass der Betriebszustand durch eine erste Anwendungsprogrammierschnittstelle (API, insbesondere Device-API) erfasst wird und die Zustandsinformation durch eine zweite Anwendungsprogrammierschnittstelle (API, insbesondere Control-API) verarbeitet wird, wobei die Anwendung, welcher die zweite Anwendungsprogrammierschnittstelle zugeordnet ist, vorzugsweise in einem WebRTC- fähigen Web-Browser des Endgeräts implementiert ist, und wobei vorzugsweise die zweite Anwendungsprogrammierschnittstelle die Nachricht erzeugt oder einen insbesondere RTC-fähigen Server veranlasst, die Nachricht zu erzeugen. Als Server kann insbesondere ein RTC-fähiger Kommunikationsserver eingesetzt werden. Ferner kann das Verfahren so ausgestaltet sein, dass die Nachricht an eine entfernte Anwendungsprogrammierschnittstelle (API, insbesondere Control- API) der entfernten Quelle adressiert wird.
Eine bevorzugte Ausführungsform des Verfahren dieses Erfindungsgesichtspunkts kann vorsehen, dass die Darstellung der Daten nach einem Entwurfsmuster (MVC) mit einem die Daten enthaltenden Modell (M), einer View (V) als Präsentationsschicht zur Darstellung der Daten und einem Controller (C) als Steuerungsschicht zur Verwaltung der Präsentationsschicht implementiert wird, wobei die Zustandsinformation durch den Controller (C) erzeugt wird, wobei vorzugsweise der Betriebszustand in dem Modell (M) implementiert wird. Im Sinne des gemäß der vorliegenden Erfindung genutzten MVC-Entwurfsmusters ist eine View eine Präsentationsschicht, die auch für die Entgegennahme von Benutzerinteraktionen zuständig ist. Sie kennt sowohl ihre Steuerung als auch das Modell, dessen Daten sie präsentiert, ist aber nicht für die Weiterverarbeitung der vom Benutzer überge- benen Daten zuständig. Die Präsentation kann über Änderungen von Daten im Modell mithilfe des Entwurfsmusters„Beobachter" unterrichtet werden und daraufhin die aktualisierten Daten abrufen. Ferner ist ein Controller im Sinne des gemäß der vorliegenden Erfindung genutzten MVC-Entwurfsmusters eine Steuerung, die eine oder mehrere Präsentationen verwaltet, und die auch gegebenenfalls von ihnen Benutzeraktionen entgegennimmt, diese auswertet und entsprechend agiert. Jede Präsentation kann eine eigene Steuerung aufweisen. Die Steuerung kann auch dafür sorgen, dass Benutzeraktionen wirksam werden, z. B. durch Änderung der Präsentation (z. B. Verschieben des Fensters) oder durch Weiterleiten an das Modell (z. B. Übernahme von Eingabedaten oder Auslösen von Verarbeitungen). Die Steuerung kann auch Mechanismen enthalten, um die Benutzerinteraktionen der Präsentation einzuschränken. Die Steuerung kann in manchen Implementierungen ebenfalls zu einem„Beobachter" des Modells werden, um bei Änderungen der Daten die View direkt zu manipulieren. Die vorstehenden Erläuterungen zum MVC-Entwurfsmuster folgen dem Wikipedia-Eintrag "Model_View_Controller", der für das weitere Verständnis in Bezug genommen wird. Da erfindungsgemäß die Zustandsinformation durch den Controller (C) erzeugt wird, kann das bestehende MVC-Muster ausgenutzt werden, wobei die Steuerungsschicht eine Erweiterung erfährt.
Eine Weiterbildung des Verfahren dieser Ausführungsform kann vorsehen, dass die zweite Anwendungsprogrammierschnittstelle in dem Entwurfsmuster als zusätzliche View für die von ihr gesteuerten Servicekomponenten registriert wird, wobei vorzugsweise der Betriebszustand über die erste Anwendungs- Steuerschnittstelle dem Modell zugeführt wird.
Eine Weiterbildung des Verfahrens dieses Erfindungsgesichtspunkts kann vorsehen, dass die Anweisung bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät wenigstens eine der nachstehenden Maßnahmen betrifft:
- Abschalten oder Suspendieren oder Wiederaufnehmen oder Einschalten eines Datenstroms;
- Verringern oder Erhöhen einer Datendichte eines Datenstroms;
- Ändern des Übertragungswegs zum Senden des Datenstroms;
- Senden eines Ersatzmediums anstelle des Datenstroms oder eines Teils des Datenstroms.
In dieser Weiterbildung liegt die Kontrolle über die Datenadaption und - Übertragung bei der Anwendung bzw. beim Anwender auf Endgeräteseite. So ist es beispielsweise möglich, die Bilddarstellung auszuschalten, den Ton aber weiterlaufen zu lassen, wenn z. B. in einer Suchmaschine kurz etwas gesucht wird.
Ein zweiter Gesichtspunkt der vorliegenden Erfindung betrifft ein Verfahren zur Steuerung einer Adaption und Übertragung von multimedialen Daten an eine entfernte Senke, insbesondere an ein vorzugsweise mobiles Endgerät, mit den Schritten:
A) Empfangen und Dekodieren einer Nachricht von der entfernten Senke;
B) Auswerten der Nachricht, um einen Betriebszustand wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente auf der Seite der entfernten Senke oder eine durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten in der entfernten Senke zu erkennen;
C) Ändern der Adaption und/oder Übertragung der multimedialen Daten, durch Auswerten des erkannten Betriebszustands oder der maximal verarbeitba- ren Datendichte zur Darstellung der multimedialen Daten, durch wenigstens eine der nachstehenden Maßnahmen:
- Abschalten oder Suspendieren oder Wiederaufnehmen oder Einschalten eines Datenstroms der multimedialen Daten;
- Verringern oder Erhöhen einer Datendichte des Datenstroms;
- Ändern des Übertragungswegs zum Senden des Datenstroms;
- Senden eines Ersatzmediums anstelle des Datenstroms oder eines Teils des Datenstroms,
um die an die entfernte Senke zu übermittelnde Datendichte an die maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten in der entfernten Senke anzupassen.
Dieser Erfindungsgesichtspunkt betrifft die Sender- bzw. Quellenseite und geht von der Voraussetzung aus, dass die Entscheidungsintelligenz auf der Sendersei- te liegt. Das Verfahren dieses Erfindungsgesichtspunkts wird also insbesondere durch die entfernte Quelle im Sinne des ersten Erfindungsgesichtspunkts durchgeführt. Eine entfernte Senke kann im Sinne dieses zweiten Erfindungsgesichtspunkts ein Endgerät, insbesondere das Endgerät des ersten Erfindungsgesichts- punkts, oder eine Zwischenstation (z. B. Router, TK-Anlage, Server) sein. Vorzugsweise ist vorgesehen, dass die Nachricht über RTC, insbesondere über einen Mobilfunkstandard, an die entfernte Quelle übertragen bzw. empfangen wird.
Alternativ kann anstelle der Schritte B und C in dem Verfahren dieses Erfindungs- gesichtspunkts eine in der Nachricht enthaltene Anweisung erkannt und kann gemäß dem Inhalt der Anweisung
- eine Suspendierung einer Übertragung der multimedialen Daten unter Aufrechterhaltung des Übertragungskanals, oder
- eine Verringerung einer Datendichte der multimedialen Daten, oder
- eine Maskierung eines Datenstroms der multimedialen Daten durch ein Ersatzmedium, oder
- eine Wiederaufnahme einer zuvor suspendierten Übertragung oder Wiederherstellen einer zuvor verringerten Datendichte der multimedialen Daten, oder
- eine Wiederherstellung eines zuvor maskierten Datenstroms der multimedialen Daten
vorgenommen werden, um die an die entfernte Senke zu übermittelnde Datendichte an die maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten in der entfernten Senke anzupassen. Bei dieser Alternative kann die Entscheidungsintelligenz wenigstens teilweise auf der Senkenseite angenommen werden.
Eine Weiterbildung des Verfahrens dieses Erfindungsgesichtspunkts kann vorsehen, dass die Nachricht durch eine Anwendungsprogrammierschnittstelle (API, insbesondere Control-API) empfangen wird, wobei eine Anwendung, welcher die Anwendungsprogrammierschnittstelle zugeordnet ist, vorzugsweise in einem WebRTC-fähigen Web-Browser implementiert ist. Vorzugsweise kann zusätzlich vorgesehen sein, dass die multimedialen Daten über eine von der Anwendungs- Programmierschnittstelle zum Empfang der Nachricht verschiedene Schnittstelle, insbesondere eine Media Engine zur Codierung oder Decodierung von Medienda- tenströmen des Web-Browsers, übertragen werden. Ein dritter Gesichtspunkt der vorliegenden Erfindung betrifft ein Verfahren zur Steuerung einer Multimedia-Anwendung auf einem insbesondere mobilen Endgerät, wobei multimediale Daten der Multimedia-Anwendung von einer Quellendomäne an eine Senkendomäne übertragen werden, durch die Senkendomäne empfangen und zur Darstellung auf einer Anzeige des Endgerät verarbeitet wer- den, wobei die multimedialen Daten in Abhängigkeit von einem Betriebszustand wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente des Endgeräts adaptiert und/oder übertragen werden, wobei das Verfahren vorzugsweise die Verfahrensschritte des vorstehend beschriebenen Verfahrens gemäß dem ersten Erfindungsgesichtspunkt und/oder des vorstehend beschriebenen Verfahrens gemäß dem zweiten Erfindungsgesichtspunkt aufweist. Mit anderen Worten, dieser Erfindungsgesichtspunkt betrifft ein System, welches die Quellen- und die Senkenseite umfasst. Bei diesem Erfindungsgesichtspunkt kann auch sichergestellt werden, dass die Daten von der Quelle zur Senke (höchstens) mit der durch das Endgerät (Senke) maximal verar- beitbaren Datendichte übertragen werden.
Ein vierter Gesichtspunkt der vorliegenden Erfindung betrifft ein Softwareprodukt, das auf einem durch einen Computer lesbaren Medium gespeichert ist und das vorzugsweise direkt in den internen Speicher eines Computer geladen werden kann und das Programmcodes eines Computerprogramms, das einen Computer zur Durchführung der Verfahrensschritte wenigstens eines der vorstehend beschriebenen Verfahren gemäß dem ersten, zweiten oder dritten Erfindungsgesichtspunkts befähigt, wenn das Computerprogramm auf dem Computer ausgeführt wird, aufweist.
Ein fünfter Gesichtspunkt der vorliegenden Erfindung betrifft ein Vorrichtung zur Ausführung wenigstens eines der vorstehend beschriebenen Verfahren gemäß dem ersten, zweiten oder dritten Erfindungsgesichtspunkts, wobei die Vorrichtung vorzugsweise ein insbesondere mobiles Endgerät, und/oder einen Server, insbesondere Gaming-Server oder Konferenzserver, und/oder eine Konferenzeinheit umfasst, und wobei die Vorrichtung insbesondere durch Implementierung des Softwareprodukts gemäß dem vierten Erfindungsgesichtspunkts zur Ausführung des Verfahrens befähigt ist.
Die Erfindung kann auch durch ein Computerprogramm, umfassend Programmbefehle, die einen Computer dazu veranlassen, die Verfahrensschritte wenigstens eines der vorstehend beschriebenen Verfahren gemäß dem ersten, zweiten oder dritten Erfindungsgesichtspunkts auszuführen, wenn das Computerprogramm auf den Computer geladen oder von diesem ausgeführt wird, und/oder ein digitales Speichermedium mit elektrisch lesbaren Steuersignalen, welche mit einem programmierbaren Computer arbeiten können, um Kommunikationsvorgänge zu verwalten, wobei die Steuersignale ausgelegt und angepasst sind, den Computer zu veranlassen, die Verfahrensschritte wenigstens eines der vorstehend beschriebenen Verfahren gemäß dem ersten, zweiten oder dritten Erfindungsgesichtspunkts auszuführen, verkörpert sein.
Weitere Merkmale, Aufgaben, Vorteile und Einzelheiten der vorliegenden Erfin- dung werden aus der nachstehenden Beschreibung konkreter Ausführungsbeispiele und ihrer zeichnerischen Darstellung in den beigefügten Figuren noch deutlicher werden. Es versteht sich, dass Merkmale, Aufgaben, Vorteile und Einzelheiten einzelner Ausführungsbeispiele auf andere Ausführungsbeispiele übertragbar sind und auch im Zusammenhang mit den anderen Ausführungsbei- spielen als offenbart gelten sollen, soweit dies nicht aus technischen oder naturgesetzlichen Gründen offensichtlich abwegig ist. In diesem Sinne können Merkmale verschiedener Ausführungsbeispiele grundsätzlich stets miteinander kombiniert werden, und die Kombination kann ebenfalls als Ausführungsbeispiel der Erfindung verstanden werden.
Im Folgenden wird die Erfindung anhand bevorzugter Ausführungsbeispiele und mit Hilfe von Figuren näher beschrieben. Dabei ist bzw. sind eine schematische Darstellung einer generischen Referenzarchi tektur mit Quellen- und Senkendomäne gemäß einem Ausführungsbeispiel der vorliegenden Erfindung; eine schematische Darstellung einer möglichen Integration in eine quellenseitige Implementierung einer WebRTC Applikation des Ausführungsbeispiels; eine schematische Darstellung einer möglichen Integration in eine senkenseitige Implementierung einer WebRTC Applikation des Ausführungsbeispiels; ein Ablaufdiagramm eines Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Die Figuren sind rein schematisch und nicht notwendigerweise maßstabsgetreu. Die zeichnerischen Darstellungen und Beschreibungen hiervon sind zur beispielhaften Veranschaulichung des Prinzips der Erfindung gedacht und sollen diese in keiner Weise einschränken. Begriffe und Konzepte, die der Fachmann aus dem Stand der Technik verstehen und anwenden kann, werden nachstehend nicht im Einzelnen erläutert, um den Erfindungsgegenstand nicht zu verwässern.
In Fig. 1 ist eine generische Referenzarchitektur mit Quellen- und Senkendomäne als ein Ausführungsbeispiel einer Vorrichtung gemäß der vorliegenden Erfindung dargestellt.
Eine Ursprungs- bzw. Quellendomäne (Domain 1) 100 weist eine Medienquelle (Client Media Source) 110, einen HTTP/Web-Server 120, einen Echtzeit- Kollaborations- bzw. -Kommunikationsserver (Real-Time Collaboration Server) 130, einen Session Border Controller (SBC) 140 und einen STUN&TURN-Server 150 (STUN / TURN: Session Traversal Utilities for NAT (Network Address Translation) / Traversal Using Relays around NAT) auf. Die Medienquelle 110 wird we- sentlich durch ein Gerät (Device) 111 implementiert. Das Gerät 111 weist einen Web-Browser 112, in dem eine WebRTC-fähige Anwendung (WebRTC App) 113 mit einem MVC-(Model-View-Controller)-Entwurfsmuster 114 implementiert ist, auf. Die Anwendung 113 ist über eine Verbindung 121 mit einem geeigneten Protokoll wie etwa HTML 5/JS mit dem HTTP/Web-Server 120 verbunden und steht über eine Geräte-Anwendungsprogrammierschnittstelle (Device API) 115 mit Peripheriegeräten des Geräts 111 in Verbindung. Ferner steht eine Steuerungs- Anwendungsprogrammierschnittstelle (Control API) 116 der Anwendung 113 über eine Verbindung 131 mit einem proprietären Protokoll wie etwa "RESTfuI over Websockets" (REST: Representational State Transfer) mit dem Kommunikationsserver 130 in Verbindung. Der Web Browser 112 weist ferner eine Medienschnittstelle 117 auf, die mit dem STUN&TURN-Server 150 in Verbindung steht. Im Sinne der vorliegenden Anmeldung schließt der Begriff der Kollaboration die Kommunikation ein, ist aber nicht darauf beschränkt.
Eine Ziel- bzw. Senkendomäne (Domain 2) 200 ist in Bezug auf die die vorliegende Erfindung betreffende Merkmale im Wesentlichen wie die Quellendomäne 200 aufgebaut. Namentlich weist die Zieldomäne 200 eine Mediensenke (Client Media Sink) 210, einen HTTP/Web-Server 220, einen Echtzeit-Kommunikationsserver (Real-Time Collaboration Server) 230, einen Session Border Controller 240 und einen STUN&TURN-Server 250 auf. Die Mediensenke 210 wird wesentlich durch ein Gerät (Device) 211 implementiert. Das Gerät 211 weist einen Web-Browser 212, in dem eine WebRTC-fähige Anwendung (WebRTC App) 213 mit einem MVC-(Model-View-Controller)-Entwurfsmuster 214 implementiert ist, auf. Die Anwendung 213 ist über eine Verbindung 221 mit einem geeigneten Protokoll mit dem HTTP/Web-Server 220 verbunden und steht über eine Geräte- Anwendungsprogrammierschnittstelle (Device API) 215 mit Peripheriegeräten des Geräts 211 in Verbindung. Ferner ist eine Steuerungs-
Anwendungsprogrammierschnittstelle (Control API) 216 der Anwendung 213 über eine Verbindung 231 mit dem Kommunikationsserver 230 verbunden. Der Web Browser 212 weist ferner eine Medienschnittstelle 217 auf, die mit dem
STUN&TURN-Server 250 in Verbindung steht. Die verwendeten Protokolle können den in der Quellendomäne 100 verwendeten Protokollen entsprechen. Die Kollaborationsserver 130, 230 dienen im Zusammenhang mit der vorliegenden Erfindung in erster Linie als Kommunikationsserver, können aber auch weitere Kollaborationsfunktionen verwirklichen.
Die Quellendomäne 100 und die Zieldomäne 200 sind über mehrere Datenverbindungen miteinander verbunden. Zum einen sind die Kommunikationsserver 130, 230 der Quellendomäne 100 und der Zieldomäne 200 durch eine Datenverbindung 400 miteinander verbunden, wobei die Session Border Controller 140, 240 der Quellendomäne 100 und der Zieldomäne 200 jeweils als Schnittstelle nach außen fungieren. Die Datenverbindung 400 nutzt beispielsweise Session Protocol SIP-T oder XMPP mit SDP Offer/Answer zur Anbindung weiterer Domänen (Federation) anbieten. Weiters sind die STUN&TURN-Server 150, 250 der Quellendomäne 100 und der Zieldomäne 200 zur Realisierung einer RTP-Verbindung 500 zwischen den Medienschnittstellen 117, 217 der Quellendomäne 100 und der Zieldomäne 200 miteinander verbunden und sind die Medienschnittstellen 117, 217 der Quellendomäne 100 und der Zieldomäne 200 über eine SCTP-(Stream Control Transmission Protocol)-Verbindung 700 auch direkt miteinander verbunden.
Im vorliegenden Ausführungsbeispiel entspricht die Zieldomäne 200 bzw. deren Geräteebene 211 einem (mobilen) Endgerät. Die Quellendomäne 100 bzw. deren Geräteebene 111 kann beispielsweise ein Medienserver sein. Es ist zu verstehen, dass in der generischen Architektur von Fig. 1 einzelne Elemente der jeweiligen Domäne 100, 200 in dem jeweiligen physikalischen Gerät 111 , 211 oder außerhalb angeordnet sein können.
Fign. 2A und 2B verdeutlichen den Aufbau der WebRTC-Browser 112, 214 der Quellendomäne 100 bzw. der Zieldomäne 200 in weiteren Einzelheiten. Dabei ist Fig. 2A eine schematische Darstellung einer möglichen Integration in eine quel- lenseitige Implementierung der WebRTC-Applikation 113 dieses Ausführungsbeispiels, und Fig. 2B ist eine schematische Darstellung einer möglichen Integration in eine senkenseitige Implementierung der WebRTC-Applikation 213 dieses Ausführungsbeispiels. Fign. 2A und 2B können als Einzelheiten von Fig. 1 verstanden werden.
Gemäß der Darstellung in Fig. 2A weist die Medienschnittstelle 117 des Web- Browsers 112 der Quellendomäne 100 eine WebRTC-fähige Anwendungsprogrammierschnittstelle (WebRTC API) 117a und eine Medienmaschine (Media Engine) 117b auf. Die Media Engine 117b auf der Seite der Quellendomäne 100 kann als Encoder für gesendete Mediendatenströme arbeiten. Eine Kamera- Mikrofon-Einheit (Camera/Microphone) 160 ist mit der Geräte- Anwendungsprogrammierschnittstelle 115 verbunden.
Gleichermaßen weist gemäß der Darstellung in Fig. 2B weist die Medienschnittstelle 217 des Web-Browsers 212 der Zieldomäne 200 eine WebRTC-fähige Anwendungsprogrammierschnittstelle (WebRTC API) 217a und eine Medienma- schine (Media Engine) 217b auf. Die Media Engine 217b auf der Seite der Zieldomäne 200 kann als Decoder für empfangene Mediendatenströme arbeiten. Eine Kamera-Mikrofon-Einheit (Camera/Microphone) 260, eine Mensch-Maschine- Schnittstelle (Human Interaction Device) 270 zur Erfassung von Interaktionen eines Bedieners 900 sowie andere Hardware-Sensoren 280 sind mit der Geräte- Anwendungsprogrammierschnittstelle 215 verbunden.
In Fig. 2B ist auch das erweiterte MVC-Entwurfsmuster 214 der Web-RTC- Anwendung 213 der Senkendomäne 200 und seine Implementierung schematisch dargestellt. Das MVC-Entwurfsmuster 214 weist ein Modell (Model) "M", eine Ansicht (View) "V" und eine Steuerung (Controller) "C" auf, wie bereits oben näher erläutert. Das Modell "M" erhält Eingabedaten von der Device API 215 und der WebRTC Media Engine 217b. Die View "V" steuert die Anzeige einer Ansicht auf einer Bild-Ton-Wiedergabeeinheit (Screen Speaker) 290. Der Controller "C" erhält ebenfalls Eingabedaten von der Device API 215 und liefert Ausgabedaten für die Control API 216. Die Control API 216 ist ferner mit der WebRTC API 217a und der Device API 215 verbunden. Wie in Fign. 2A und 2B gezeigt, sind die RTP-Verbindung 500 und die SCTP- Verbindung 700 zwischen der Medienschnittstelle 117 des WebRTC-Browsers 112 der Quellendomäne 100 und der Medienschnittstelle 217 des WebRTC- Browsers 212 der Zieldomäne 200 errichtet. Dabei läuft die unidirektionale RTP- Verbindung 500, wie in Fig. 1 gezeigt, auf Quellen- und Senkenseite jeweils über einen STUN&TURN-Server 150, 250, während die bidirektionale SCTP- Verbindung 700 direkt zwischen den Medienschnittstellen 117, 217 verläuft. Die STUN&TURN-Server 150, 250 können in Ausführungsvarianten weggelassen werden oder auf STUN- oder TURN- Funktion beschränkt sein. Die RTP- Verbindung 500 und die SCTP-Verbindung 700 können wahlweise genutzt werden, und es kann in Ausführungsvarianten nur eine von diesen vorhanden sein.
Die Funktionsweise der in Fign. 1 , 2A und 2B dargestellten Gerätetechnik wird nachstehend auch anhand des Ablaufschemas von Fig. 3 als ein Ausführungsbei- spiel eines Verfahrens gemäß der vorliegenden Erfindung beschrieben.
Eine spezifische WebRTC Applikation 213 auf dem (mobilen) Endgerät 210 wird durch Auswahl einer entsprechenden URL in einem HTML5/JavaScript (JS)- fähigen Browser 212 gestartet, und vom Applikations-Server (HTTP/Web-Server) 220 wird dann die eigentliche Applikationslogik über JS in den Browser 212 geladen. Daraufhin wird zunächst eine Websocket-Verbindung 231 zum jeweiligen RTC-Server 130, 230 aufgebaut und das proprietäre Protokoll - meist als RESTfuI gestaltetes Protokoll - gestartet. Bei einer beispielhaften Videotelefonie-mit- Screen-Sharing-Anwendung werden lokal die Geräte-Empfangsressourcen für den Zugriff auf Mikrofon, Kamera, und Graphikkarte über das Device
API:getUserMedia gestartet. Über das proprietäre und das Session-Protokoll (das optional über einen oder mehrere Session Border Controller geführt wird) werden die Adressen des entfernten Gerätes 110, mit dem kommuniziert werden soll, übermittelt. Die beteiligten Geräte, die Medien als Quelle übermitteln, d.h., im dargestellten Ausführungsbeispiel das Gerät 111 der Quellendomäne 100, bauen mittels des Web-RTC API 117 die jeweils uni-direktionalen RTP Verbindungen 500 zur Übermittlung von Sprache, Video und Screen-Sharing beispielhaft als gestreamtes Video in Vorwärtsrichtung auf. Wie erwähnt, kann für bestimmte andere Medien die bi-direktionale SCTP-Verbindung 700 aufgebaut werden. Im vorliegenden Ausführungsbeispiel werden in den Verbindungsaufbau jeweilige STUN&TURN-Server 150, 250 in den RTP-Kanal 500 involviert. Die vom Gerät der Quellendomäne empfangenen Medien Sprache, Bewegtbild der Kamera und des Bildschirms werden entsprechend dem im Session-Protokoll ausgehandelten Kodierungsverfahren durch die quellenseitige Media Engine 117b codiert und über die jeweils eine RTP-Verbindung 500 (hier ebenfalls wieder über die
STUN&TURN-Server 150, 250) übermittelt. Das empfangende Gerät, d.h., die senkenseitige Media Engine 217b, decodiert die Medienströme und präsentiert diese über die Applikationslogik auf den entsprechenden lokalen Geräte- Ausgaberessourcen, hier Lautsprecher und Bildschirm als Bild-Ton- Wiedergabeeinheit 290, entsprechend der aktuell vom Benutzer gewählten Darstellung. Die Applikationslogik implementiert die Ansicht typischerweise als Model-View- Controller (MVC)-Entwurfsmuster. Dabei erhält der MVC-Controller "C" oder das MVC-Model "M" das Wissen über die aktuelle Ansicht "V. Bei der Nutzung der beispielhaften Anwendung - beispielhaft auf einem Smartphone - kann nicht sinnvoll auf der Bildschirmfläche die Videodarstellung und der gesharte Bildschirm gleichzeitig mit geeigneter Auflösung dargestellt werden. Der Benutzer wird deshalb durch Interaktion (Human Interaction Device 270) beispielsweise in eine Ansicht Desktop-Sharing wechseln. Dies wird vom MVC 214 erfasst und festgestellt, dass das Kamera-Bewegtbild nicht mehr angezeigt wird. Daraufhin wird das lokale, erfindungsgemäß erweiterte Control-API 216 informiert, welches beispiels- weise über eine Callback-Funktion eine erfindungsgemäße RemoteMe- dia(Suspend) Meldung 219 für diese Videoverbindung an den lokalen (Sink) WebRTC-Server 230 übermittelt. Dieser leitet diese Information über das gewählte und erfindungsgemäß erweiterte Session Protokoll 400 zum entfernten (Source) WebRTC-Server 30 weiter. Der entfernte WebRTC-Server 130 wiederum leitet diese Meldung zum Control-API 116 seines lokal verbundenen Browsers 112 weiter. Die Applikationslogik der lokalen WebRTC-App 13 schaltet daraufhin über das lokale DeviceAPI 111 mittels einer getUserMedia-Anweisung 119 den Medienstrom von der Kamera 160 ab, erhält aber die zugehörige RTP-Verbindung 500 aufrecht. Ggf. generiert der zugehörige Encoder (quellenseitige Media Engine 117b) ein Ersatzmedium, beispielsweise ein Standbild, mit deutlich reduziertem Bandbreitenbedarf. Wechselt der Benutzer am Empfangsgerät 210 nun kurzfristig in die Videotelefonie-Ansicht, um die Mimik des Gesprächspartners zu einem kritischen Aspekt in der gesharten Präsentation zu sehen, wird dies über den MVC 214 erfasst und daraufhin über das erfindungsgemäß erweiterte lokale Control-API 216 über eine Callback-Funktion angeregt, eine erfindungsgemäße RemoteMe- dia(Resume)-Meldung 219 für diese Videoverbindung an den lokalen (Sink) WebRTC-Server 230 zu übermittelt. Dieser leitet diese Information 219 über das gewählte und erfindungsgemäß erweiterte Session Protokoll 400 zum entfernten (Source) WebRTC-Server 130 weiter. Der entfernte WebRTC-Server 130 wiederum leitet diese Meldung zum Control-API 116 seines lokal verbundenen Browsers 112 weiter. Die Applikationslogik der lokalen WebRTC-App 113 schaltet daraufhin über das lokale DeviceAPI 115 mittels getUserMedia 119 den Medienstrom von der Kamera 190 wieder ein. Der Encoder liefert daraufhin den gewöhnten Medienstrom. Nach einer Karenzzeit, wenn der Benutzer in der Screen-Sharing-Ansicht verbleibt, kann auf analogem Verfahren das als Bewegtbild übermittelte Screen- Sharing suspendiert werden, und so weiter. Beim Abmelden oder Verlassen der WebRTC-Anwendung 213 werden die verwendeten Ressourcen und die RTP (SCTP)-Verbindungen unabhängig von Sus- pendierungsstatus freigegeben bzw. abgebaut.
Wie erwähnt, zeigt Fig. 2B eine mögliche Integration in eine Client-seitige Imple- mentierung einer WebRTC Applikation 213 durch die erfindungsgemäße Erweiterung des MVC 214. Das erfindungsgemäße Control-API 216 wird vom Controller "V" getriggert, wenn die View "V" sich so verändert hat, dass eine veränderte Nutzung der Medienströme vorliegt, die über das WebRTC-API 217a etabliert wurden. Alternativ zur View "V" kann der Controller "C" auch Signale aus dem Geräteumfeld propagieren wie Display ausgeschaltet, niedriger Batteriezustand, etc. Das Control-API 216 übermittelt dies zum WebRTC-Server 230, der wiederum dies an den entfernten WebRTC-Server 130 weiterleitet (nicht dargestellt). Optional können die empfangenen Medienströme noch lokal abgeschaltet werden, die Bestandteil des Models "M" sind. Entfernt werden vom Control-API 130 dann die zu sendenden Medienströme abgeschaltet oder ressourcenschonend modifiziert. Das lokale Device-API 216 detektiert dies, und falls nicht bereits lokal explizit verarbeitet, wird das lokale Model "M" entsprechend aktualisiert.
Prinzipiell könnte eine ähnliche Wirkung auch durch SDP:Offer/Answer abgebildet werden. Dies erfordert allerdings einen erheblicher höheren Signalisierungsauf- wand, insbesondere zum Aufbau der RTP-Verbindungen und das Allokieren und De-allokieren der damit verbundenen Geräteressourcen. Das erfindungsgemäße Verfahren erlaubt demgegenüber eine erhöhte Agilität bei der Benutzerinteraktion und damit eine verbesserte Benutzererfahrung.
Wie oben beschrieben, wird durch die RemoteMedia{suspend|resume}-Meldung 219 eine Anweisung an die entfernte Quelle 100 bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät 200, um die Daten und/oder die Übertragung der Daten an die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten anzupassen, verwirklicht. Dies setzt voraus, dass die Anwendungslogik und damit die zur Durchführung des erfindungsgemäßen Verfahrens erforderliche Entscheidungsintelligenz und -kompentenz auf der Seite des Endgeräts
(Senkendomäne) 200 liegt.
In einer Abwandlung des vorstehend beschriebenen Ausführungsbeispiels kann die Anwendungslogik auch wenigstens teilweise auf der Seite der Quelle 100 angeordnet sein. So kann anstelle der RemoteMedia{suspend|resume}-Meldung 219 auch eine Nachricht erzeugt werden, welche die Zustandsinformation selbst enthält, und die Vorgaben zur Anpassung der Daten und/oder der Übertragung der Daten an die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten können durch die WebRTC-Anwendung 113 der Quelle 100 ermittelt und dann - via getUserMedia - umgesetzt werden. In einer weiteren Abwandlung kann die erzeugte Nachricht eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, aufweisen.
Wird, nach dem Stand der Technik eine multi-mediale Anwendung, beispielsweise eine Kollaborationssitzung, gestartet, werden die zugehörigen Kommunikationskomponenten ebenfalls gleichzeitig gestartet. Dazu werden Verbindungen für Audio-A/ideo-Komponenten, Application-Sharing Komponenten und ggf. weitere Kommunikationskanäle bi-direktional aufgebaut. Sobald diese aufgebaut sind, beginnen die Datenquellen mit der Codierung der Daten- und Kommunikationsströme unabhängig davon, ob diese von der Datensenke verarbeitet und deren Decodierung dargestellt wird. Werden diese nun aber nicht dargestellt, werden unnötig Netzbandbreiten genutzt und zusätzlich am sendenden und empfangenen Gerät unnötig Energie verbraucht, was bei mobilen Endgeräten die Batterielaufzeiten verkürzt. Typischerweise ist auf einem Smartphone oder Tablet-PC mit kleinerer Bildschirmdiagonale nicht gleichzeitig eine Videokonferenz und ein entfernter Bildschirm mit vernünftiger Auflösung darstellbar. Gemäß der vorliegenden Erfindung wird die Übermittlungssteuerung über ein (mobiles) Datennetz von multi-medialen Servicekomponenten durch Rückkopplung von Benutzeransichten und -Interaktionen am (mobilen) Zielgerät
(Senkendomäne 200) zum Ursprungsgerät (Quellendomäne 100) verbessert.
Dadurch werden sowohl Bandbreiten im Datennetz und Energie in den beteiligten End- und Übermittlungsgeräten gespart und bei mobilen Endgeräten damit die Batterielaufzeiten verlängert.
Wenn die Endgeräte über Konferenzsysteme verbunden sind, werden die Konferenzsysteme erfindungsgemäß im Sinne der Quellendomäne 100 verwendet und implementieren eine adäquate Funktionalität in proprietärer Weise.
Die erfindungsgemäß erweiterten Verbindungsprotokolle und Nutzverbindungen der Servicekomponenten können auch über Netzübergangs- oder Proxyeinrich- tungen wie die STUN/TURN Server 150, 250 geführt werden. Das erfindungsgemäß erweiterte Session Protokoll kann optional über einen SBC 140, 240 geführt werden. Darstellungen auf Geräten werden oft mit dem Entwurfsmuster Model-View- Controller (MVC) implementiert. Dabei steuert die View über den Controller, welche Daten gemäß Nutzerinteraktion aus dem Model dargestellt werden, und umgekehrt kann bei Änderung vom Controller beobachteter Daten die View aktualisiert werden. Das MVC-lmplementierungsmuster kann sowohl für Web- Applikationen, native Clients, und Gadgets verwendet werden. Der Controller hat damit das Wissen, welcher Ausschnitt des Models tatsächlich aktuell verwendet wird. Für multi-mediale Anwendungen wie beispielsweise WebRTC beinhaltet das Model u.a. die Servicekomponenten wie Audio, Video, Screen-sharing, Joint Editing, und Gaming. Das Model hat erfindungsgemäß das Wissen, welche Kom- ponenten aus Sicht der View aktiv sind und benötigt werden. Der Controller verfügt außerdem über die Übersicht, welche Servicekomponenten aktiv sind und kann damit erfindungsgemäß sinnvolle Kombinationen bereitstellen.
Ist zum Beispiel eine Screen-sharing Applikation aktiv und die Videokonferenz- komponente - da nicht darstellbar - inaktiv, kann der Controller die Abschaltung der Videoverbindung bei gleichwohl fortdauernder Nutzung der Audioverbindung veranlassen. Das erfindungsgemäß erweiterte Model mit Wissen über aktive und inaktive Servicekomponenten kann erfindungsgemäß für die jeweilige Servicekomponente beispielsweise über ein erfindungsgemäß erweitertes Control-API 216 der WebRTC App 213 im Client 210 informieren, welches wiederum die erfindungsgemäße call-back Funktion„RemoteMedia {suspend | resume}" 219 im Senke-Echtzeitkommunikationsserver (WebRTC-Server) 230 auslöst. Dazu könnte sich das Control-API 216 beispielsweise als zusätzliche„View" für die von ihr gesteuerten Servicekomponenten registrieren. Der Senken-WebRTC-Server 230 kann erfindungsgemäß zum Quellen-WebRTC-Server 130 über ein geeignetes implizit oder explizit erweitertes Verbindungsprotokoll 400 signalisieren, welches die Funktion„RemoteMedia {suspend | resume}" 219 adäquat abbildet, die Verwendung einzelner Servicekomponenten rückkoppeln. Der Quellen-WebRTC Server 130 kann dann wiederum über sein lokales Control-API 116 die korrespondierende Datenquelle 110 ansteuern (z.B. über das Device API: getUserMedia 119), die Übermittlung von Daten einzustellen, zu suspendieren, fortzusetzten bzw. wieder aufzunehmen, die Datendichte zu verringern oder zu erhöhen, den Datenstrom durch ein Ersatzmedium zu maskieren oder eine Maskierung wieder durch den ursprünglichen Datenstrom zu ersetzen, etc. D. h., gegebenenfalls wird das Medium in geringerer Güte oder ein Ersatzmedium bereitgestellt, um mögliche Verbindungsabbrüche wegen Inaktivität zu vermeiden. Dabei hat eine erfindungsgemäße explizite Erweiterung der verwendeten Protokolle den Vorteil, dass betrof- fene Komponenten nur suspendiert bzw. schnell wieder reaktiviert werden können, ohne die Verbindung (beispielsweise heute wie geplant über SDP:Offer/Answer) erneut einrichten zu müssen, und somit die damit verbundene Latenzzeit reduziert werden kann.
Der erfindungsgemäße Controller "C" z.B. des MVC 214 verfügt über die Übersicht, welche Servicekomponenten aktiv sind und kann damit erfindungsgemäß sinnvolle Kombinationen bereitstellen. Durch eine ergänzende Anbindung an Hard- und/oder Soft-Sensoren (260, 270, 280) im Endgerät oder Monitoring- Verbindungen zur Infrastruktur können Informationen über die tatsächlich verfügbare Bandbreiten und Dienstgüte bereitgestellt werden. Der Controller "C" kann damit sinnvolle Kombinationen von Servicekomponenten weiter optimieren, indem beispielsweise die Videokomponente abgeschaltet oder beispielsweise ein (letztes) Standbild der View "V" übermittelt wird, das zuvor in regelmäßigen Abständen im Model "M" zusätzlich erzeugt und gespeichert wurde, und nur die Audiokomponente verwendet wird.
Die Komponenten des erfindungsgemäß erweiterten client-seitigen MVC 214 können auch mit Ausnahme vom Controller "C" über einen Backend-Server, beispielsweise über den http/WebServer 220, verteilt werden.
Wie beschrieben, kann die Applicationslogik client-seitig im Browser durch das JavaScript download realisiert werden. Alternativ stellt diese der Applikationsserver bereit und interagiert mit der client-seitigen Implementierung des MVCs. Die unter Bezug auf die dargestellten Ausführungsformen beschriebenen Merkmale der Erfindung, z.B. die erfindungsgemäße Erweiterung des MVC-Modells 214 auf der Seite der senkenseitigen WebRTC-App 213, können auch bei anderen Ausführungsformen und/oder Abwandlungen der Erfindung, beispielsweise zusätzlich oder alternativ zu einer Erweiterung des MVC-Modells 114 auf der Seite der quellenseitigen WebRTC-App 113 zur beispielsweise quellenseitigen Ermittlung der senkenseitig maximal verarbeitbaren Datendichte, vorhanden sein, außer wenn es anders angegeben ist oder sich aus technischen Gründen von selbst verbietet.

Claims

Patentansprüche
1. Verfahren zur Steuerung einer Multimedia-Anwendung (213) auf einem
insbesondere mobilen Endgerät (200), wobei multimediale Daten von einer entfernten Quelle (100) empfangen werden und zur Darstellung auf einer Anzeige (290) des Endgeräts (200) verarbeitet werden, mit den Schritten: a) Erkennen eines Betriebszustands wenigstens einer die Darstellung der Daten der multimedialen Anwendung (213) betreffenden Servicekomponente des Endgeräts (200); b) Erzeugen einer den Betriebszustand der wenigstens einen Servicekomponente kennzeichnenden Zustandsinformation; c) Erzeugen einer Nachricht, umfassend:
- die Zustandsinformation, und/oder
- eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, und/oder
- eine Anweisung an die entfernte Quelle bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät, um die Daten und/oder die Übertragung der Daten an die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten anzupassen; d) Übertragen der Nachricht an die entfernte Quelle (100); e) Empfangen der multimedialen Daten; und f) Verarbeiten der multimedialen Daten zur Darstellung auf der Anzeige (290) des Endgeräts. Verfahren gemäß Anspruch 1 , dadurch gekennzeichnet, dass der Betriebszustand durch eine erste Anwendungsprogrammierschnittstelle (API, insbesondere Device-API) erfasst wird und die Zustandsinformation durch eine zweite Anwendungsprogrammierschnittstelle (API, insbesondere Control- API) verarbeitet wird, wobei die Anwendung, welcher die zweite Anwendungsprogrammierschnittstelle zugeordnet ist, vorzugsweise in einem WebRTC-fähigen Web-Browser des Endgeräts implementiert ist, und wobei vorzugsweise die zweite Anwendungsprogrammierschnittstelle die Nachricht erzeugt oder einen insbesondere RTC-fähigen Server veranlasst, die Nachricht zu erzeugen.
Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Darstellung der Daten nach einem Entwurfsmuster (MVC) mit einem die Daten enthaltenden Modell (M), einer View (V) als Präsentationsschicht zur Darstellung der Daten und einem Controller (C) als Steuerungsschicht zur Verwaltung der Präsentationsschicht implementiert wird, wobei die Zustandsinformation durch den Controller (C) erzeugt wird, wobei vorzugsweise der Betriebszustand in dem Modell (M) implementiert wird.
Verfahren gemäß Anspruch 3, soweit auf Anspruch 2 rückbezogen, dadurch gekennzeichnet, dass die zweite Anwendungsprogrammierschnittstelle in dem Entwurfsmuster als zusätzliche View für die von ihr gesteuerten Servicekomponenten registriert wird, wobei vorzugsweise der Betriebszustand über die erste Anwendungs-Steuerschnittstelle dem Modell zugeführt wird.
Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Nachricht eine Anweisung an die entfernte Quelle bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät umfasst, wobei die Anweisung wenigstens eine der nachstehenden Maßnahmen betrifft:
- Abschalten oder Suspendieren oder Wiederaufnehmen oder Einschalten eines Datenstroms; - Verringern oder Erhöhen einer Datendichte eines Datenstroms;
- Ändern des Übertragungswegs zum Senden des Datenstroms;
- Senden eines Ersatzmediums anstelle des Datenstroms oder eines Teils des Datenstroms.
Verfahren zur Steuerung einer Adaption und Übertragung von multimedialen Daten an eine entfernte Senke, insbesondere an ein vorzugsweise mobiles Endgerät, mit den Schritten:
A) Empfangen und Dekodieren einer Nachricht von der entfernten Senke;
B) Auswerten der Nachricht, um einen Betriebszustand wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente auf der Seite der entfernten Senke oder eine durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten in der entfernten Senke zu erkennen;
C) Ändern der Adaption und/oder Übertragung der multimedialen Daten, durch Auswerten des erkannten Betriebszustands oder der maximal verarbeitbaren Datendichte zur Darstellung der multimedialen Daten, durch wenigstens eine der nachstehenden Maßnahmen:
- Abschalten oder Suspendieren oder Wiederaufnehmen oder Einschalten eines Datenstroms der multimedialen Daten;
- Verringern oder Erhöhen einer Datendichte des Datenstroms;
- Ändern des Übertragungswegs zum Senden des Datenstroms;
- Senden eines Ersatzmediums anstelle des Datenstroms oder eines Teils des Datenstroms,
um die an die entfernte Senke zu übermittelnde Datendichte an die maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten in der entfernten Senke anzupassen.
Verfahren gemäß Anspruch 6, dadurch gekennzeichnet, dass die Nachricht durch eine Anwendungsprogrammierschnittstelle (API, insbesondere Control-API) empfangen wird, wobei eine Anwendung, welcher die Anwen- dungsprogrammierschnittstelle zugeordnet ist, vorzugsweise in einem WebRTC-fähigen Web-Browser implementiert ist.
Verfahren zur Steuerung einer Multimedia-Anwendung auf einem insbesondere mobilen Endgerät, wobei multimediale Daten der Multimedia- Anwendung von einer Quellendomäne an eine Senkendomäne übertragen werden, durch die Senkendomäne empfangen und zur Darstellung auf einer Anzeige des Endgerät verarbeitet werden, wobei die multimedialen Daten in Abhängigkeit von einem Betriebszustand wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente des Endgeräts adaptiert und/oder übertragen werden, wobei das Verfahren vorzugsweise die Verfahrensschritte eines Verfahrens gemäß einem der Ansprüche 1 bis 5 und/oder eines Verfahrens gemäß Anspruch 6 oder 7 aufweist.
Softwareprodukt, das auf einem durch einen Computer lesbaren Medium gespeichert ist und das vorzugsweise direkt in den internen Speicher eines Computer geladen werden kann und das Programmcodes eines Computerprogramms, das einen Computer zur Durchführung der Verfahrensschritte eines Verfahrens nach einem der vorstehenden Ansprüche befähigt, wenn das Computerprogramm auf dem Computer ausgeführt wird, aufweist.
Vorrichtung zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 8, wobei die Vorrichtung vorzugsweise ein insbesondere mobiles Endgerät, und/oder einen Server, insbesondere Gaming-Server oder Konferenzserver, und/oder eine Konferenzeinheit umfasst, und wobei die Vorrichtung insbesondere durch Implementierung von Programmcodes eines Computerprogramms eines Softwareprodukts nach Anspruch 9 zur Ausführung des Verfahrens befähigt ist.
PCT/EP2015/001639 2014-08-25 2015-08-07 Verfahren zur steuerung einer multimedia-anwendung, softwareprodukt und vorrichtung WO2016037677A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US15/505,183 US10581946B2 (en) 2014-08-25 2015-08-07 Method for controlling a multimedia application, software product and device
EP15756555.7A EP3186971A1 (de) 2014-08-25 2015-08-07 Verfahren zur steuerung einer multimedia-anwendung, softwareprodukt und vorrichtung
CN201580045624.8A CN106576185A (zh) 2014-08-25 2015-08-07 用于控制多媒体应用的方法、软件产品和设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014012355.3A DE102014012355A1 (de) 2014-08-25 2014-08-25 Verfahren zur Steuerung einer Multimedia-Anwendung, Softwareprodukt und Vorrichtung
DEDE102014012355.3 2014-08-25

Publications (1)

Publication Number Publication Date
WO2016037677A1 true WO2016037677A1 (de) 2016-03-17

Family

ID=54012149

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/001639 WO2016037677A1 (de) 2014-08-25 2015-08-07 Verfahren zur steuerung einer multimedia-anwendung, softwareprodukt und vorrichtung

Country Status (5)

Country Link
US (1) US10581946B2 (de)
EP (1) EP3186971A1 (de)
CN (1) CN106576185A (de)
DE (1) DE102014012355A1 (de)
WO (1) WO2016037677A1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10917186B2 (en) * 2015-07-21 2021-02-09 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcasting signal receiving apparatus, broadcasting signal transmitting method, and broadcasting signal receiving method
CN106506632A (zh) * 2016-10-27 2017-03-15 上海幻电信息科技有限公司 一种基于html5浏览器的音视频直播方法
DE102016125345A1 (de) * 2016-12-22 2018-06-28 Unify Patente Gmbh & Co. Kg Verfahren zum Betreiben einer Kollaborations- und Kommunikations-Plattform und Kollaborations- und Kommunikations-Plattform
DE102017108017A1 (de) * 2017-04-13 2018-10-18 Unify Patente Gmbh & Co. Kg Verfahren zum Führen einer Audio- und/oder Videokonferenz
DE102017131420A1 (de) * 2017-12-29 2019-07-04 Unify Patente Gmbh & Co. Kg Echtzeit-Kollaborations-Plattform und Verfahren zum Ausgeben von Mediaströmen über ein Echtzeit-Ansagesystem
CN109660764A (zh) * 2018-12-24 2019-04-19 武汉长江通信智联技术有限公司 基于html5的车辆实时视频的监控方法、装置及系统
US11463739B2 (en) 2020-06-29 2022-10-04 Seagate Technology Llc Parameter based load balancing in a distributed surveillance system
US11503381B2 (en) 2020-06-29 2022-11-15 Seagate Technology Llc Distributed surveillance system with abstracted functional layers
CN112153140B (zh) * 2020-09-23 2022-12-06 Oppo广东移动通信有限公司 远程控制方法、装置、设备、存储介质及系统
CN112383803B (zh) * 2020-11-16 2023-04-11 Oppo广东移动通信有限公司 信息处理方法及相关装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1187485A1 (de) * 2000-09-11 2002-03-13 Mediabricks Ab Verfahren zur Bereitstellung von Medieninhalt über ein digitales Netzwerk
US20090161755A1 (en) * 2007-12-21 2009-06-25 Broadcom Corporation Device adaptive video transmission system for use with layered video coding and methods for use therewith
US20100235520A1 (en) * 2009-03-11 2010-09-16 International Business Machines Corporation Dynamically optimizing delivery of multimedia content over a network
WO2013127459A1 (en) * 2012-03-01 2013-09-06 Telefonaktiebolaget L M Ericsson (Publ) Mixer for providing media streams towards a plurality of endpoints whereby the media streams originating from one or more media source and method therefore
DE102013110613A1 (de) * 2012-09-28 2014-04-03 Avaya Inc. Verteilte Anwendung von Unternehmensrichtlinien auf interaktive Web-Real-Time-Communications(WebRTC)-Sitzungen und verwandte Verfahren, Systeme und computerlesbare Medien

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6442699B1 (en) * 1998-09-18 2002-08-27 Matsushita Electric Industrial Co., Ltd. Power control method and apparatus therefor
DE19934787B4 (de) * 1999-07-27 2004-08-05 T-Mobile Deutschland Gmbh Verfahren zur automatischen Anpassung der von einer datenbereitstellenden Einrichtung zu einer datenabrufenden Einrichtung zu übertragenden Daten an die Fähigkeiten dieses Endgerätes
US20040196849A1 (en) * 2003-02-13 2004-10-07 Nokia Corporation Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming
KR100604585B1 (ko) * 2004-12-15 2006-07-25 주식회사 팬택앤큐리텔 멀티 미디어 데이터 관리 방법과 그를 이용한 이동통신단말기
CN100566401C (zh) * 2006-09-12 2009-12-02 腾讯科技（深圳）有限公司 即时通信视频质量调节方法及装置
US20100281042A1 (en) * 2007-02-09 2010-11-04 Novarra, Inc. Method and System for Transforming and Delivering Video File Content for Mobile Devices
KR20100122518A (ko) * 2008-04-18 2010-11-22 닛본 덴끼 가부시끼가이샤 게이트웨이 장치, 방법 및 컴퓨터 판독가능 기록 매체
US8302145B2 (en) * 2008-11-20 2012-10-30 At&T Intellectual Property I, Lp System and method to manage a content stream
CN101552913B (zh) * 2009-05-12 2011-07-06 腾讯科技（深圳）有限公司 多路视频通讯系统及处理方法
US20130031485A1 (en) * 2011-07-29 2013-01-31 Pin Zhou Chen Mobile business intelligence dynamic adaptor
US9271055B2 (en) * 2011-08-23 2016-02-23 Avaya Inc. System and method for variable video degradation counter-measures
US8966370B2 (en) * 2012-08-31 2015-02-24 Google Inc. Dynamic adjustment of video quality
CN103841085B (zh) * 2012-11-23 2017-03-08 华为技术有限公司 基于万维网的实时通信的实现方法及装置
EP2738721A1 (de) * 2012-11-28 2014-06-04 Deutsche Telekom AG Verfahren und System zur Präsentation bei kollaborativer Zusammenarbeit
CN103414835A (zh) * 2013-07-24 2013-11-27 佳都新太科技股份有限公司 一种使用WebRTC技术实现呼叫中心视频坐席的方法
US20180144368A1 (en) * 2013-08-26 2018-05-24 Google Inc. Isolating advertising identifiers from applications
CN104427296B (zh) * 2013-09-05 2019-03-01 华为终端（东莞）有限公司 视频会议中媒体流的传输方法与装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1187485A1 (de) * 2000-09-11 2002-03-13 Mediabricks Ab Verfahren zur Bereitstellung von Medieninhalt über ein digitales Netzwerk
US20090161755A1 (en) * 2007-12-21 2009-06-25 Broadcom Corporation Device adaptive video transmission system for use with layered video coding and methods for use therewith
US20100235520A1 (en) * 2009-03-11 2010-09-16 International Business Machines Corporation Dynamically optimizing delivery of multimedia content over a network
WO2013127459A1 (en) * 2012-03-01 2013-09-06 Telefonaktiebolaget L M Ericsson (Publ) Mixer for providing media streams towards a plurality of endpoints whereby the media streams originating from one or more media source and method therefore
DE102013110613A1 (de) * 2012-09-28 2014-04-03 Avaya Inc. Verteilte Anwendung von Unternehmensrichtlinien auf interaktive Web-Real-Time-Communications(WebRTC)-Sitzungen und verwandte Verfahren, Systeme und computerlesbare Medien

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3186971A1 *

Also Published As

Publication number Publication date
US20170272488A1 (en) 2017-09-21
DE102014012355A1 (de) 2016-02-25
CN106576185A (zh) 2017-04-19
US10581946B2 (en) 2020-03-03
EP3186971A1 (de) 2017-07-05

Similar Documents

Publication Publication Date Title
WO2016037677A1 (de) Verfahren zur steuerung einer multimedia-anwendung, softwareprodukt und vorrichtung
DE60309201T2 (de) Verfahren und system zur übertragung von ereignissen, einschliesslich multimedia daten
DE102014108888B4 (de) Virtuelle Back-to-Back-Web-Real-Time-Communications(WebRTC)-Agenten und verwandte Verfahren, Systeme und computerlesbare Medien
DE102012013336B4 (de) Aushandeln einer kontinuierlichen multi-stream-präsenz
DE102013114633B4 (de) Netzwerk-adaptive Latenzzeit-Verringerung durch Framerate-Steuerung
EP3357218B1 (de) Verfahren zur industriellen kommunikation über tsn
DE112012002224B4 (de) Qualität von VoIP-Sitzungen
WO2014127787A1 (de) Verfahren zur steuerung von datenströmen einer virtuellen sitzung mit mehreren teilnehmern, kollaborationsserver, computerprogramm, computerprogrammprodukt und digitales speichermedium
EP2036293B1 (de) Erweiterung des CSTA Protokolls zum vollständigen VoIP Protokoll
WO2017016568A1 (de) Verfahren und telekommunikationsnetz zum streamen und zur wiedergabe von anwendungen
EP1855437A1 (de) Verfahren zum Aufbau einer Push-to-talk-Kommunikationsverbindung
EP3162018B1 (de) Verfahren zum aufbau einer für die übermittlung von medienströmen geeigneten kommunikationsverbindung von einem ersten rtc-client zu einem zweiten rtc-client
DE102014100183A1 (de) Verfahren und Vorrichtung zum Verwenden eines separaten Rückwärtskanals für Benutzereingaben bei der Replizierung der Anzeige eines mobilen Geräts
EP2938047A1 (de) Verfahren, vorrichtung, computerprogramm, softwareprodukt und digitales speichermedium zur übermittlung und adaption von daten
EP2938085A1 (de) Verfahren und vorrichtung zur übermittlung von kodierten mediendaten
EP2340641B1 (de) Übertragen von ticker-information im multimediabereich
EP1438658A2 (de) Verfahren zum aktuellhalten von software auf verschiedenen endgeräten
DE102005052207A1 (de) Verfahren zum Übertragen von einem Datenstrom von einer Datenquelle zu einer Datensenke sowie Datensenkengerät, Datenquellgerät und Gerät zur Durchführung des Verfahrens
DE102017110431A1 (de) Verfahren zum Übertragen von Informationen
WO2016055375A1 (de) Einstellen von datenraten in einem videokamerasystem
DE102017108017A1 (de) Verfahren zum Führen einer Audio- und/oder Videokonferenz
EP3016344B1 (de) Intelligenter media-gateway switch für transparentes routen und verketten von medienströmen
EP3518470A1 (de) Verfahren zur daten-kommunikation in einem insbesondere industriellen netzwerk, vorrichtung zur durchführung des verfahrens, computerprogramm sowie computerlesbares medium
EP3507958B1 (de) Verfahren zum streamen und zur wiedergabe von anwendungen über ein bestimmtes telekommunikationssystem und verwendung
DE102022205604A1 (de) Optimieren einer medienerfahrung bei einer konferenz mit diversen teilnehmern

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15756555

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15505183

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2015756555

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015756555

Country of ref document: EP