Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N7/00—Television systems
  • H04N7/14—Systems for two-way working
  • H04N7/15—Conference systems
  • H04N7/152—Multipoint control units therefor
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/16—Arrangements for providing special services to substations
  • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
  • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/16—Arrangements for providing special services to substations
  • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
  • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
  • H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
• • 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/40—Support for services or applications
  • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
• • 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
• • 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
  • 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
• • 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/752—Media network packet handling adapting media to network capabilities
• • 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/765—Media network packet handling intermediate
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N7/00—Television systems
  • H04N7/14—Systems for two-way working
  • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
  • H04N7/147—Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals

Definitions

• the invention relates to a method for guiding an audio and / or video conference, in which a plurality of terminals is coupled via a data network with a central Konfe ⁇ renzêt issued.
• At least one predetermined terminal of the terminals comprises a data processing device which by operation of an application (application), in particular a browser application (browser application) enables the terminal to participate in the conference.
• an application application
• browser application browser application
• a predetermined terminal is a personal computer with a built-in camera and built-in microphone (or camera and microphone docked) and a screen and speaker (or docked).
• the data processing device can just as well be a suitably oriented tablet computing device, a smartphone or the like portable terminal.
• the personal computer (or other device) is capable of conferencing: taking pictures with the camera, acquiring voice utterances using the microphone. On the screen the own picture is displayed and / or the pictures of other participants are displayed, over the microphone a speech output takes place.
• FIG. 1 illustrates an enterprise network 10, in which individual clients EP 1, EP 2 and EP 3 (WebRTC browser Net z-real-time ⁇ controlled browser) together require a conference call and in this case (Public Cloud) 12 in a public cloud at the central
• Conference control device KA where a conference application (conference application) runs under Webrtc.
• the registration takes place via signaling paths 14, which are shown in FIG. 1 are shown by solid lines.
• the signaling thus takes place from the individual clients or the browsers EP 1, EP 2, EP 3 to the conference application KA.
• the conference application KA now provides a resource over which the audio and / or video conference can run.
• This resource is referred to as MediaServer, sometimes as MediaNode, and is shown in FIG. 1 with "MS", abbreviated for MediaServer.
• the individual audio and video data packets are transmitted via the dashed lines of data lines 16 to the MediaServer MS, mixed by this and sent back to the individual clients to provide the audio and / or video conferencing data.
• a selection ie a selection from the received audio or video data channels with forwarding of the received data streams to the individual clients, for the purpose of processing the data streams in the clients themselves, which then referred to as a selective forwarding unit (SFU) become) .
• SFU selective forwarding unit
• a person speaking each can be displayed, and the persons who remain silent are not selected, but filtered out.
• a disadvantage of a procedure as shown in FIG. 1 is that the audio and video data leave the corporate network 10 for the purpose of conferencing. As a result, the secure data exchange may well be at risk. Moreover, data transfer requires more resources than if it were within a network.
• EP 1 014 666 A1 discloses a method for realizing multipoint connections (ie conference circuits) between several terminals of an H.323
• the conference unit causes the opening of user data channels (ie of audio and video data channels) between the terminals via the conference unit.
• EP 1 001 596 A2 describes a multimedia terminal for telephony, which allows itself multipoint connections.
• the object is solved in one aspect by a method according to claim 1, in other aspects by a computer program product according to claim 8, according to claim 9 and according to claim 10.
• the inventive method for guiding an audio and / or a video conference in which a plurality of terminals is coupled via a data network with a central Konfe ⁇ renz Kunststoffe issued, and wherein at least a first terminal comprises a data processing device, which by operation of an application, in particular a Browser application, which enables the terminal to participate in the conference, has the property according to the invention that a predetermined terminal of the at least one first terminal due to control commands (signaling) by the central
• Conference control device at least when fulfilled a predetermined criterion audio and / or video data streams (ie user data streams) receives from other terminals and a) by means of the application, in particular browser application mixes (in particular with of the first terminal itself generated audio and / or video data streams) and in mixed form to the returns to other terminals and / or
• the invention thus starts from the principle to use a (ZENTRA ⁇ len or distributed) Media server outside of the clients, which is usually at the central conferencing the case; rather, one of the clients (ie, the predetermined terminal of the at least one first terminal) itself acts as a MediaServer or MediaNode, which is normally the case only in conference serverless conferencing methods.
• a central conference control device with corresponding conference room user experience, user authentication, etc.
• the security-sensitive audio and / or video data need not leave the corporate network.
• the audio and video data between clients and a central Webrtc conference server are transmitted encrypted, so for example, the audio packets from the conference server (in the cloud) must be decrypted, to be mixed then ver ⁇ down again may be sent to the clients.
• Ie full "end to end confidentiality" is often not given. This makes it apparent that it may be advantageous for reasons of Ver ⁇ confidentiality to keep the media data locally on the LAN.
• Other benefits include significantly reducing the required WAN bandwidth, so the band ⁇ wide between location / corporate networks / clients and the Data Center of the cloud service provider of the WebRTC Konfe ⁇ ence solution.
• the application is preferably a Webrtc (Web Real-Time Control) browser application, that is, a net timed browser application. It can thus be built on the presence of Webrtc technology.
• the one predetermined terminal of the at least one terminal only has to be equipped with a suitable application plug-in.
• An application plug-in should not be confused with a browser plug-in, because Webrtc browsers (eg Google Chrome®, or Mozilla Firefox®, etc.) by definition do not need any in the W3C Webrtc standardization (World Wide Web Consortium) Browser plug-ins, at least not for the base Webrtc functionality.
• one of the at least one first terminal receives audio and / or video data streams from all other terminals and mixes or subjects them to selection.
• the entire conference is in principle supported by the predetermined first terminal in terms of user data streams.
• one of the at least one first terminal receives audio and / or video data streams from only a subset of the other terminals and mixes or subjects them to selection.
• a side conference can be conducted: those participants who sit at terminals within a corporate network can communicate separately to, for example, in terms of their behavior towards a participant outside the
• the predetermined criterion in the fulfillment of which the central conference ⁇ control device in the first ever brings the predetermined terminal of the at least one first terminal for receiving and mixing / selection meetings, that those other terminals, of which audio and / or Video data streams are received in a common local area network, LAN, Local Area Network, coupled together.
• each terminal must register for attending the conference at the central conference control facility.
• the predetermined terminal transmits (in such an application) or communicated (in an earlier initial login) to the central conference control device the information that it is capable of receiving audio and / or video data streams and a) mixing and b) a selection and that the predetermined criterion includes that such information has been transmitted.
• the central conference control device can generally be designed, in turn, to mix or to subject the user data streams to a selection. Only when the one terminal with the appropriately configured browser reports that it has a suitable browser extension to run the conference itself will this task be transferred to the appropriate browser.
• a computer program product for providing or extending (the latter in the form of a plug-in) an application, in particular a browser application, to a first data processing device is provided.
• Computer program product is designed to give the first data processing device the ability to receive audio and / or video data from at least one second data processing device and on the one hand from the second received and on the other hand provided by the first data processing device and / or another second data processing device received audio and / / or to mix and / or select a video data and to forward the mixed and / or selected audio and / or video data to the at least one second data processing device.
• This computer program product thus provides for the running of a browser which has the characteristics described above, ie the central one
• Conference control device to remove the task of mixing and / or making a selection of the audio and / or video data.
• the conference control device to remove the task of mixing and / or making a selection of the audio and / or video data.
• Browser application by the computer product to be able to give the input message to the central conference control device that the conferencing ability of the browser is given.
• a computer program product for providing or expanding (in the form of a plug-in) an application, in particular a browser application, on a second
• a data processing device is provided, which is designed to give the second data processing device the ability to exchange control signals with a central data processing device and audio and / or video signals to a first
• This computer program product allows the non-conferencing browser applications to use the conferencing-enabled browser application under the control of the central computing device.
• the invention provides, in yet another aspect, a computer program product adapted for providing or expanding (in the form of a plug-in) an application, in particular a conference circuit application, on a third data processing device is to give the third data processing device the ability to obtain information from a first data processing device, which states that this first data processing device is capable of audio and / or video data from the second
• FIG. Fig. 1 illustrates an arrangement for conducting a conference implementing a method according to the prior art
• FIG. Figure 2 illustrates an arrangement for conducting a conference implementing the method according to the invention
• FIG. 3 details of the invention in the
• FIG. Figure 4 shows a flow of exchanges of messages according to the method of the invention.
• FIG. 2 of the present invention instead of a standard Webrtc browser, such a Webrtc browser EP 1K with conferencing capability is provided.
• This conference resource is controlled by a central application (conference control application), which refers to the Cloud Webrtc.
• conference control application which refers to the Cloud Webrtc.
• the enterprise network 10 there are further browsers EP 2 and EP 3.
• the conference control application K-A In a cloud (data center) 12 there is the conference control application K-A.
• signaling paths 14 between the individual browsers EP 1K, EP 2 and EP 3 to the conference application K-A are not translated through appropriate payload data paths
• the browser EP 1K assumes the role of a MediaServer or MediaNode, and the user data streams (audio and / or video data) are transmitted via signal paths 20 from the individual further browsers EP 2 and EP 3 to the conferable browser EP 1K, where they are mixed and transferred the same paths in mixed form returned.
• a selection takes place on the part of the conference-capable browser EP 1K, for example, whenever a subscriber is currently speaking, whose image is displayed on the browsers, and not otherwise.
• the advantage of the procedure according to FIG. 2 is that the payload streams remain within the enterprise network 10. It is therefore for a higher one Data security ensured. Furthermore, less bandwidth is needed between enterprise network 10 and cloud data center 12.
• the structure of the conferable browser EP 1K is described below with reference to FIG. 3 explained in more detail.
• a client application for example, a JavaScript client application 22, which gives him the ability to communicate with the central conference ⁇ control application KA. He can therefore assume the role of a client.
• a conference client application 24 is provided, such as in JavaScript, which gives the client the ability to signal that he is capable of conferencing.
• the client application 22 is generally responsible for Webrtc client signaling with the conference application KA (see reference character "SC""signalingclient")
• the further application 24 is responsible for additional signaling of the conference client ("signaling Conference Client ", SKC), which ⁇ example, the conference switching commands of the central conference ⁇ renzêtune receives (role MediaServer in EPIK).
• the browser 25 comprises a web interface, in particular a time-controlled interface 26, in English: Webrtc API, Web Real-Time Control Application Programming Interface. It includes a session management and conference management unit 28. Further, it requires a corresponding voice unit 30 ("Voice.") For encoding and decoding Engine “with corresponding codecs) and the same for video data in the unit 32 (" Video Engine "with corresponding codecs). Exemplary codecs are G.711, Opus, H.264, VP8, etc. In addition, there is a unit 34 for mixing or switching (selecting, forwarding). The transmission interface (transport interface) 36 ensures the forwarding of the data, and to the other browsers EP 2 and EP 3, there is a client / browser OS interface.
• the EP 2 and EP 3 browsers where EP stands for "end point", ie telecommunication subscribers, likewise exchange corresponding signals SC with the conference application K A.
• the conference application decides that the browser EP 1K decides the conference
• the browsers EP 2 and EP 3 send their payloads N2 and N3 to the unit 34 where these payloads N2 and N3 are merged with respective payload data Nl generated by the units 30 and 32 or subjected to selection in which the mixed data are sent back as data M2 and M3 and the selected (“switched") data are sent back as SW2 and SW3.
• the in FIG. 2 is divided into the two paths 20a for the direction towards the unit 34 and 20b for the direction away from the unit 34 to the browsers EP 2 and EP 3.
• FIG. 4 shows the corresponding signals:
• the request is sent to the conference control application KA by the browser EP 1K to join or start the conference room (see "EP 1K JoinRequest") in part 4.
• ConCaps Conferencing Capabilities.
• conference conferencing capabilities that are indicated include: 1) conference type (audio conference, videoconference, screen share conference (mostly video), 2) conference type (conference mixing, selective forwarding unit, ..), supported codecs (G. 711, OPUS, H.264, VP 8, VP 9, ..), conference credentials (for authentication).
• the conference application KA requests the browser EP 1K (in its role as "MediaNode") to make a corresponding media resource available in the EP 1K (see “Conf Create Request” in FIG. 4).
• the IP address and port of the client 1 are signaled in step S12 to the browser Media Resource.
• the browser EP 1K answers ( "ver MediaSer-” in his role as) in step S 14 with the confirmation that he has the ge ⁇ Wanted (s) Media Resource (s) provided and signaled as part of step S14, IP address / port of the Webrtc Browser Conference Resource See in FIG 4 the command "Conf Create Confirm", which includes that information is sent to the conference application KA that the browser EP 1K the media resource starts or holding the conference resources.
• step S 16 the conference control application KA then confirms to the browser EP 1K (in its role as "client / Webrtc browser") that a media resource has been generated and the client EP 1K can send to this media resource ("EP 1K Join Confirm ").
• the application conference room is active, with a participant (EP1K) in the conference and the possibility of joining by other Webrtc browsers.
• step S 20 the browser EP 2 inquires whether it can join the conference ("EP 2 Join Request").
• the browser EPK1 in its role as “MediaServer” then receives the order from the conference control unit in step S22 ⁇ processing to switch the EP2 in the conference (Conf Add Requ ⁇ est) and confirms this in turn in step S 24 ( "Conf add confirm”).
• step S 26 send the specializedapplikat ion K A in step S 26 the confirmation to the browser EP 2, that the conference has been joined to EP 1K
• steps S10, S12, S14, S16 regarding exchange of the IP and port receive addresses between client EP 1K and the conference resource (in client EP 1K)
• the receive IP addresses and ports in steps S20, S22, S24 and S26 are also exchanged between EP2 and the conference resource (in EP 1K).
• steps S 28, S 30, S 32 and S 34 also take place in the third browser EP 3.
• the browsers EP 2 and EP 3 then send their audio and video data in steps S 36 and S 38 to the conference resource of the browser EP 1K.
• the arrow S 40 illustrates that the browser EP 1K is internally (in its as a client) itself contributes its own audio and video data recorded with the associated microphone or associated camera to mix.
• the client EP 1K does not have to send its locally displayed media data via the LAN interface (IP address) to the media resource of the same EP 1K, but can do this internally in the browser.
• the received user data are mixed in such a way that corresponding data can then be output in the steps S 44 at the browser EP 1K itself or in the steps S 46 and S 48 are transmitted to the browsers EP 2 and EP 3 can and can be spent there.
• the browsers shown so far in the figures are all conference participants.
• the invention is also applicable when there is already a conference and only a subgroup in a corporate network wants to hold a side conference.
• the requesting U ser required permission and (GUI) controls on his browser client eg "Split local Conference"
• his browser client eg "Split local Conference”
• payload re config ionsaufträgen sent via the central Confe rence ⁇ tax application.

Landscapes

• Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Databases & Information Systems (AREA)
• Data Mining & Analysis (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Telephonic Communication Services (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Information Transfer Between Computers (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=62002129

Family Applications (1)

Country Status (5)

Families Citing this family (1)

Family Cites Families (25)

• 2017
  • 2017-04-13 DE DE102017108017.1A patent/DE102017108017A1/de not_active Withdrawn
• 2018
  • 2018-04-12 EP EP18718136.7A patent/EP3610642A1/de not_active Ceased
  • 2018-04-12 CN CN201880024784.8A patent/CN110546947A/zh active Pending
  • 2018-04-12 WO PCT/EP2018/059464 patent/WO2018189337A1/de unknown
  • 2018-04-12 US US16/500,247 patent/US11444821B2/en active Active
• 2022
  • 2022-08-17 US US17/889,698 patent/US20220391452A1/en not_active Abandoned

Also Published As

Similar Documents

Legal Events