阅读说明：本技术 用于进行音频和/或视频会议的方法 (method for conducting an audio and/or video conference ) 是由 K.克拉格霍费尔 于 2018-04-12 设计创作，主要内容包括：一种用于进行音频和/或视频会议的方法包含：终端设备中的一个与中央会议控制装置(K-A)耦合的终端设备(EP 1K)承担媒体服务器的角色,其中这在中央会议控制装置(K-A)的控制下进行。(A method for conducting an audio and/or video conference comprising: one of the terminal devices (EP 1K) coupled to the central conference control device (K-A) assumes the role of a media server, wherein this takes place under the control of the central conference control device (K-A).)

用于进行音频和/或视频会议的方法

技术领域

本发明涉及一种用于进行音频和/或视频会议的方法，其中多个终端设备经由数据网络与中央会议控制装置耦合。这些终端设备中的至少一个预先确定的终端设备包括数据处理装置，该数据处理装置通过运行应用程序（Applikation）、尤其是浏览器应用程序（Browser-Applikation）来使终端设备能够参加会议。通常，这种预先确定的终端设备是个人计算机，该个人计算机具有嵌入的摄像机和嵌入的麦克风（或连接摄像机和麦克风）和屏幕以及扬声器（或连接）。该数据处理装置同样可以是相对应地配备的平板计算机设备、智能电话或者诸如此类的便携式终端设备。借助于浏览器，个人计算机（或其它设备）有参加会议能力：在使用摄像机的情况下拍摄图像，在使用麦克风的情况下检测语言表达。在屏幕上显示自己的图像和/或显示其他参与者的图像，通过麦克风来进行语音输出。

背景技术

到目前为止常见的是：多个参与者（客户端）借助于他们的浏览器在中央会议控制装置上登记，该中央会议控制装置通常处在云中。这里，这示范性地依据图1来阐述。

图1示出了企业网络10，在该企业网络中，各个客户端EP 1、EP 2和EP 3（Webrtc浏览器，网络实时控制的浏览器）共同希望进行多方会议并且在这种情况下在公共云（PublicCloud）12中在中央会议控制装置K-A上登记，在那里，Konferenz-Applikation（会议应用程序）在Webrtc下运行。通过在图1中用实线来示出的信令路径来进行登记。即信令是从各个客户端或浏览器EP 1、EP 2、EP 3到会议应用程序K-A。现在，会议应用程序K-A提供可通过其来进行音频和/或视频会议的资源。该资源被称作MediaServer（媒体服务器），部分也被称作MediaNode（媒体节点），而在图1中对于MediaServer用“MS”来缩写。各个音频和视频数据包经由用虚线绘制的数据线16被传送给媒体服务器MS，由该媒体服务器来混合录制并且重新被发回给各个客户端，用于提供音频和/或视频会议数据。替代混合录制，也可以进行“选择”（即从所接收到的音频或视频数据信道中选择，将所接收到的数据流转发给各个客户端，从而在客户端本身中整理数据流，这些客户端接着被称作选择性转发单元（Selective Forwarding Unit，SFU））。例如，可以显示相应正在说话的人员，而且不选择保持沉默的人员，而是将保持沉默的人员过滤掉。

在像按照图1那样的做法方面不利的是：出于多方会议的目的，音频和视频数据离开企业网络10。由此，安全的数据交换无论如何都可能受到威胁。此外，对于数据传输来说，需要比当该数据传输会在网络之内进行时更多的资源。

从US 2014/0122600 A1公知一种会议服务器，该会议服务器承担将音频或视频数据混合录制的任务。在JavaScript下运行的各个浏览器拥有参加会议的相对应的能力，但是没有自己的混频器。

EP 1 014 666 A1公开了一种用于实现在H.323数据通信网络的多个终端设备之间的多点连接（即多方会议）的方法，其中会议单元引起在终端设备之间经由该会议单元的有效数据信道（即音频和视频数据信道）的打开。

EP 1 001 596 A2描述了一种用于通话的多媒体终端设备，该多媒体终端设备本身能够实现多点连接。

在US 2004/0210637 A1描述了补充于其它路径地设置外部会议桥。

在2017年4月3日，在计算机链接https://Webrtchacks.com/web-audio-conference/下能获得如下论文，从该论文能获悉如下原理：浏览器承担中央会议控制装置的角色，以便进行本地音频会议。该论文提到了“Poor-Man的会议解决方案”，因为不使用服务器。从该论文中并不知道可以如何召开这种音频会议。

发明内容

本发明的任务是提供一种用于进行音频和/或视频会议的方法，该方法优选地借助于客户端来实现，这些客户端拥有应用程序、尤其是浏览器应用程序，而且其中在该方法的情况下存在对数据网络的尽可能高效的使用和/或在交换音频和/或视频数据（有效数据）时的尽可能最优的安全性。

在一个方面，该任务通过根据权利要求1的方法来解决，在其它方面，该任务通过根据权利要求8、根据权利要求9和根据权利要求10的计算机程序产品来解决。

按照本发明的用于进行音频和/或视频会议的方法（其中多个终端设备经由数据网络与中央会议控制装置耦合，而且其中至少一个第一终端设备包括数据处理装置，该数据处理装置通过运行应用程序、尤其是浏览器应用程序来使终端设备能够参加会议）具有按照本发明的特性：该至少一个第一终端设备中的预先确定的终端设备基于中央会议控制装置的控制指令（信令）至少在满足预先确定的标准时从其它终端设备接收音频和/或视频数据流（即有效数据流），而且

a) 借助于应用程序、尤其是浏览器应用程序来将音频和/或视频数据流（即有效数据流）混合录制（尤其是也在由第一终端设备本身生成的音频和/或视频数据流的情况下）并且将音频和/或视频数据流（即有效数据流）以混合录制的形式发还给所述其它终端设备，和/或

b) 将对所接收到的音频和/或视频数据和这些所接收到的音频和/或视频数据中的由该至少一个第一终端设备生成的音频和/或视频数据的选择转交给所述其它终端设备。

因此，本发明基于如下原理：使用在客户端之外的（集中式或分布式）媒体服务器，这通常在集中式会议时情况如此；更确切地说，客户端之一（即该至少一个第一终端设备中的预先确定的终端设备）本身充当媒体服务器或媒体节点，这通常只在无会议服务器的会议方法中情况如此。由此，可以在各个浏览器或所属的终端设备之间进行数据交换，然而不必放弃中央会议控制装置的优点（具有相对应的会议室User Experience（用户体验），UserAuthentication（用户认证）等等）。因而，如果例如全部终端设备都处在同一企业网络之内，则安全敏感的音频和/或视频数据不必离开该企业网络。即否则如果在Webrtc标准下音频和视频数据在客户端与中央Webrtc会议服务器之间经加密地来传输，则例如音频包必须由（在云中的）会议服务器解密，以便可以被混合录制，从而紧接着可以重新经加密地被发送给客户端。也就是说，常常并不存在完全的“端到端保密”。由此能看出：出于保密的原因，在LAN中将媒体数据保持在本地可以是有利的。其它优点是所需的WAN带宽、即在所在地/企业网络/客户端与Webrtc会议解决方案的云服务提供商的数据中心之间的带宽的显著减小。

优选地，应用程序是Webrtc（Web Real-Time Control）浏览器应用程序、即网络实时控制的浏览器应用程序。因此，该应用程序可以基于Webrtc技术来构造。至少一个终端设备中的其中一个预先确定的终端设备仅须配备适合的应用程序插件。这里，应用程序插件不能与浏览器插件混淆，因为Webrtc浏览器（例如，Google Chrome®、Mozilla Firefox®等等）通过在W3C Webrtc标准化（World Wide Web Consortium（万维网联盟））中的定义而不需要浏览器插件，至少对于基础Webrtc功能性来说不需要浏览器插件。

在一个变型方案中，该至少一个第一终端设备中的其中一个终端设备从所有其它终端设备接收音频和/或视频数据流，而且将这些音频和/或视频数据流混合录制或者对这些音频和/或视频数据流进行选择。因此，整个会议原则上由预先给定的第一终端设备关于有效数据流方面予以支持。进一步优选地，在这种情况下规定：所有音频和/或视频数据流仅仅流经预先确定的第一终端设备，即不再设置并行的有效数据流。以这种方式，可以确保在封闭式网络（例如企业网络）中客户端或其浏览器的适当的处境下的安全性。

在第二变型方案中，该至少一个第一终端设备中的其中一个终端设备从其它终端设备中的仅仅一个子组接收音频和/或视频数据流，而且将这些音频和/或视频数据流混合录制或者对这些音频和/或视频数据流进行选择。在这种情况下，例如可以进行额外会议：在企业网络之内的终端设备处的那些参与者可以分开地进行通信，以便例如讨论他们对在企业网络之外的与其进行谈判的参与者的态度。那么，安全相关的数据这里也留在封闭式网络、即企业网络之内。

因此，优选地规定：预先确定的标准（在满足该预先确定的标准时，中央会议控制装置总的来说首先使该至少一个第一终端设备中的预先确定的终端设备进行接收以及混合录制/做出选择）包含：那些从中接收音频和/或视频数据流的其它终端设备在共同的局域网、即LAN、Local Area Network中彼此耦合。

在本发明的一个优选的实施方式中，任何终端设备为了参加会议都必须在中央会议控制装置处登记。预先确定的终端设备将如下信息（在这种登记时）传送给或者（在先前的首次登记时）传送给了中央会议控制装置：该预先确定的终端设备能够接收音频和/或视频数据流而且a)将这些音频和/或视频数据流混合录制并且b)对这些音频和/或视频数据流进行选择，而且该预先确定的标准包含：这种信息已经被传送。以这种方式，中央会议控制装置一般可以设计为：就其而言将有效数据流混合录制或者对这些有效数据流进行选择。只有当其中一个具有相对应地设立的浏览器的终端设备报告该终端设备拥有适当的浏览器扩展以便自己召开会议时，该任务才被转移给相对应的浏览器。

在本发明的另一方面，提供了一种用于提供或扩展（后者以插件的形式）在第一数据处理装置上的应用程序、尤其是浏览器应用程序的计算机程序产品。该计算机程序产品被设计为：赋予第一数据处理装置如下能力：从至少一个第二数据处理装置接收音频和/或视频数据，而且将一方面从该第二数据处理装置接收到的和另一方面由第一数据处理装置提供的和/或从其它第二数据处理装置接收到的音频和/或视频数据混合录制和/或对这些音频和/或视频数据进行选择，而且将被混合录制的和/或被选择的音频和/或视频数据转发给该至少一个第二数据处理装置。因此，该计算机程序产品引起浏览器的运行，该浏览器具有上文所描述的特性，也就是说为中央会议控制装置分担将音频和/或视频数据混合录制和/或从音频和/或视频数据中进行选择的任务。尤其是，浏览器应用程序可以通过该计算机产品而能够将如下吸引人的消息发给中央会议控制装置：该浏览器有参加会议能力。

在本发明的另一方面，提供了一种用于提供或扩展（以插件的形式）在第二数据处理装置上的应用程序、尤其是浏览器应用程序的计算机程序产品，该计算机程序产品被设计为：赋予第二数据处理装置如下能力：与中央数据处理装置交换控制信号并且将音频和/或视频信号传送给在中央数据处理装置之外的第一数据处理装置。该计算机程序产品允许本身没有参加会议能力的浏览器应用程序在中央数据处理装置的控制下使用有参加会议能力的浏览器应用程序。

在又一其它方面，本发明提供了如下计算机程序产品，该计算机程序产品用于提供或扩展（以插件的形式）在第三数据处理装置上的应用程序、尤其是多方会议应用程序，该计算机程序产品被设计为赋予第三数据处理装置如下能力：从第一数据处理装置获得如下信息，该信息说明了该第一数据处理装置能够从第二数据处理装置接收音频和/或视频数据并且将这些音频和/或视频数据混合录制和/或对这些音频和/或视频数据进行选择并且将被混合录制的和/或被选择的音频和/或视频数据转发给其它数据处理装置，其中第三数据处理装置在获得这种信息时将这种混合录制和/或进行选择的任务转移给发送了该信息的第一数据处理装置。

附图说明

随后，本发明的优选的实施方式参考随附的附图进一步予以描述，其中

图1阐明了用于进行会议的装置，该装置实现了按照现有技术的方法；

图2阐明了用于进行会议的装置，该装置实现了按照本发明的方法；

图3阐明了关于在按照本发明的方法中使用的有参加会议能力的Webrtc浏览器和来自该浏览器以及到该浏览器的数据流的细节；

图4示出了按照本发明的方法对消息的交换的流程图。

具体实施方式

在依据图2来阐明的按照本发明的方法中，替代平常的Webrtc浏览器，提供了有参加会议能力（有会议资源）的这种Webrtc浏览器EP 1K。该会议资源通过涉及云Webrtc的中央应用程序（会议控制应用程序）来控制。在企业网络10中存在其它浏览器EP 2和EP 3。会议控制应用程序K-A处在云（数据中心）12中。如也在现有技术中那样，在各个浏览器EP 1K、EP 2和EP 3与会议应用程序K-A之间存在信令路径14。然而，这些信令路径没有通过在企业网络之外的相对应的有效数据路径来补充。尤其是，不存在媒体服务器MS，或对于所描述的场景来说不需要中央媒体服务器。作为替代，浏览器EP 1K承担媒体服务器或媒体节点的角色，而且有效数据流（音频和/或视频数据）经由信号路径20从各个其它浏览器EP 2和EP 3被传送给有参加会议能力的浏览器EP 1K，在那里被混合录制并且经由相同的路径以混合录制的形式重新被发送回来。替选于混合录制或者附加地，可以规定：从有参加会议能力的浏览器EP 1K方面进行选择：例如每当有参与者恰好说话时，在浏览器上呈现该参与者的图像，而否则就不在浏览器上呈现该参与者的图像。按照图2的做法的优点在于：有效数据流留在企业网络10之内。因而，导致数据安全性更高。此外，在企业网络10与云数据中心12之间需要更少的带宽。

随后，有参加会议能力的浏览器EP 1K的构造参考图3进一步予以阐述。

首先，该有参加会议能力的浏览器拥有客户端应用程序、例如JavaScript客户端应用程序22，该客户端应用程序赋予该有参加会议能力的浏览器与中央会议控制应用程序K-A进行通信的能力。因而，该有参加会议能力的浏览器可以承担客户端的角色。作为插件地或者被嵌入到客户端应用程序中地，设置会议客户端应用程序24，比如也以JavaScript来设置会议客户端应用程序24，该会议客户端应用程序赋予客户端如下能力：用信令通知该客户端有参加会议能力。客户端应用程序22一般负责与会议应用程序K-A的Webrtc客户端信令（参见附图标记“SC”，“Signaling Client（信令客户端）”），而另一应用程序24负责实现会议客户端的附加的信令（“Signalisierung Konferenz-Client（会议客户端的信令）”，SKC），该信令例如也接受中央会议控制装置的多方会议指令（在EP1K中的媒体服务器角色）。

浏览器25包括网络接口、尤其是网络实时控制接口26，英文是：Webrtc API、WebReal-Time Control Application Programming Interface。该浏览器包括用于管理会话和会议（“Session Management and Conference Management（会话管理和会议管理）”）的单元28。此外，为了进行编码和解码，该浏览器需要相对应的调音单元30（具有相对应的编解码器的“语音引擎（Voice Engine）”），而且对于在单元32中的视频数据来说需要相同的调音单元（具有相对应的编解码器的“视频引擎（Video Engine）”）。示例性的编解码器是是G.711、Opus、H.264、VP8等等。还存在用于混合录制或用于切换（选择、转发）的单元34。传输接口（Transportschnittstelle）36负责转发数据，而且存在客户端/浏览器OS接口朝向其它浏览器EP 2和EP 3。

浏览器EP 2和EP 3与会议应用程序K-A同样交换相对应的信号SC，其中EP表示“end point（终点）”、即电信成员。通过信令SKC，会议应用程序决定浏览器EP 1K应该媒体式地进行会议。作为对此的反应，浏览器EP 2和EP 3将它们的有效数据N2和N3发送给单元34，在该单元34处，这些有效数据N2和N3与相对应的、由单元30和32生成的有效数据N1混合录制或者对这些有效数据N2和N3进行选择，其中被混合录制的数据作为数据M2和M3被发送回来或被选择的（“被交换的”）数据作为SW2和SW3被发送回来。这里，在图2中示出的信号路径20被分成两个路径，针对朝向单元34的方向的路径20a和从单元34远离浏览器EP 2和EP3的方向的路径20b。

详细地，数据的交换可以如随后所阐述的那样来执行：

图4示出了相对应的信号：

在图4中，首先，在步骤S 10中，通过浏览器EP 1K将加入会议室或启动该会议室的请求发送给会议控制应用程序K-A（参见“EP 1K JoinRequest”）。在步骤S10中的信令的内容的部分例如是客户端EP 1的IP地址和端口（Port）、所支持的编解码器（Codec）以及客户端1的其它与会议相关的能力（英文“ConfCaps” = Konference Capabilities）。会议应用K-A基于该信令而识别出：客户端/浏览器EP 1K具有支持本地浏览器会议的能力，包括会议详细能力在内。属于信令化的会议详细能力（英文ConfCaps）的例如是：1)会议方式（音频会议、视频会议、屏幕共享会议（大多是视频）），2)会议类型（会议混合录制、选择性转发单元，...）、所支持的编解码器（G.711、OPUS、H.264、VP8、VP9，...）、会议凭证（ConferenceCredentials）用于认证（Authentication）。

在下一步骤S 12中，会议应用程序K-A向浏览器EP 1K（其作为“媒体节点（MediaNode）”）请求提供在EP 1K中的相对应的媒体资源（参见图4中的“Conf CreateRequest”）。在步骤S12中，客户端1的IP地址和端口一并用信令通知浏览器媒体资源。在步骤S 14中，浏览器EP 1K（在其作为“媒体服务器（MediaServer）”的角色下）用如下确认来进行回答：该浏览器已经提供了所希望的一个或多个媒体资源（Media Resource）并且在步骤S14的框架内用信令通知Webrtc浏览器会议资源（Webrtc Browser Konferenz Resource）的IP地址/端口。为此在图4中参见指令“Conf Create Confirm”，该指令“Conf CreateConfirm”包含将如下信息发送给会议应用K-A：浏览器EP 1K已经启动了媒体资源或维持会议资源。然后，在步骤S 16中，会议控制应用程序K-A向浏览器EP 1K（在该浏览器作为“客户端/Webrtc浏览器”的角色下）确认：已经生成了媒体资源并且客户端EP 1K可以将媒体资源发送给该会议控制应用程序（“EP 1K Join Confirm”）。借此，如在步骤S 18中示出的那样，应用程序会议室是活跃地、在会议中有参与者（EP 1K）和其它Webrtc浏览器加入的可能性的情况下被提供。

在步骤S 20中，浏览器EP 2询问它是否能加入会议（“EP 2 Join Request”）。接着，在步骤S 22中，浏览器EP 1K（在其作为“媒体服务器”的角色下）获得会议控制装置的使EP2加入会议的委托（Conf Add Request）并且就其而言在步骤S 24中确认这一点（“ConfAdd Confirm”）。接着，在步骤S 26中，会议应用程序K-A将如下确认发送给浏览器EP 2：已经加入了与EP 1K的会议。与关于在客户端EP 1K与（在客户端EP 1K中的）会议资源之间交换IP和端口接收地址方面的步骤S10、S12、S14、S16类似地，在步骤S20、S22、S24和S26中也在EP2与（在EP 1K中的）会议资源之间交换接收IP地址和端口。

在第三浏览器EP 3中也进行相对应的步骤S 28、S 30、S 32和S 34。然后，在步骤S26或S 34结束之后，浏览器EP 2和EP 3在步骤S 36和S 38中将它们的音频和视频数据发送给浏览器EP 1K的会议资源。通过箭头S 40来阐明：浏览器EP 1K内部（在其作为客户端的角色下）本身将它自己的音频和视频数据用于进行混合录制，这些音频和视频数据是用所分配的麦克风或所分配的摄像机来拍摄的。在此，客户端EP 1K不必经由LAN接口（IP地址）将该客户端的在本地生成的媒体数据发送给同一EP 1K的媒体资源，而是可以在浏览器内部执行这一点。在混合录制的步骤S 42中，所获得的有效数据被混合录制为使得接着相对应的数据可以在步骤S 44中在浏览器EP 1K本身上被输出或可以在步骤S 46和S 48中被传送给浏览器EP 2和EP 3而且可以在那里被输出。

到目前为止在这些附图中示出的浏览器全部都是会议参与者。当会议已经存在而且在企业网络中的仅仅一个子组想要进行额外会议时，本发明也能被应用。在这种情况下，提出申请的用户需要相对应的授权和在该用户的浏览器客户端上的（GUI）操作元件（例如“拆分本地会议（Split local Conference）”），与相对应的有效负载重新配置命令相关联地经由中央会议控制应用程序来发送。