CN110301126B - 会议服务器 - Google Patents

Abstract

会议服务器可从公共互联网直接访问，并且具有主机传输地址，该主机传输地址是公共互联网上的公共IP地址和相关联端口的组合。它包括：会议主持逻辑，用于主持至少一个会议，其中在所述至少一个会议中经由会议服务器在参与端点之间发送和接收媒体数据；媒体处理逻辑，其配置为处理所接收的会议的媒体数据以便在会议中传输；复用控制逻辑，其配置为确定参与端点要使用的多个复用令牌；以及解复用逻辑，其配置为在从主机传输地址处的参与端点接收的序列数据分组的传输层有效载荷数据中识别接收的复用令牌，并且使用在传输层有效载荷数据中识别的复用令牌来解复用数据分组以便由媒体处理逻辑进行处理。

Description

会议服务器

技术领域

概括地说，本发明涉及会议服务器，其包括用于在会议服务器上主持一个或多个会议(例如，语音或视频会议呼叫)的会议逻辑。

背景技术

通信网络可以例如是基于分组的网络和/或互联网。网络通常包括诸如用户设备、路由器、网络地址转换器(NAT)、代理服务器、媒体中继服务器等等之类的不同类型的网络节点，它们在网络内执行不同的功能。例如，路由器在互联网的各个网络之间路由分组。NAT也执行这种路由，以及执行网络地址转换(即，掩盖发送者的网络地址)。两个通信节点(例如，用户设备)之间的通信可以经由网络的其它节点(即，诸如路由器、NAT和媒体中继服务器之类的中间节点)。向连接到网络的(例如，用户设备、服务器等等的)每个活动网络接口分配网络地址(例如，IP(互联网协议)地址)，使得其数据可以通过网络路由到所述网络接口。这可以例如在公共网络的情况下由ISP(互联网服务提供商)分配，或者由其它网络管理者分配。

可以在通过通信网络连接的两个端点(例如，用户设备)之间建立媒体会话，以便可以通过网络在这些端点之间发送和接收实时媒体。端点运行客户端软件以使得能够建立媒体会话。媒体会话可以是IP语音或视频(VoIP)会话，其中呼叫的音频和/或视频数据作为媒体流在VoIP会话中的端点之间进行发送和接收。可以通过网络地址(例如，传输地址)来识别端点和其它类型的网络节点。传输地址由IP地址以及标识与该IP地址相关联的端口的端口号组成。可以在与端点相关联的传输地址之间建立媒体会话。

媒体会话的示例是SIP(“会话发起协议”)媒体会话。SIP信令(例如，用于建立或终止呼叫或其它通信事件)可以通过一个或多个SIP(代理)服务器。为此，SIP代理在端点之间转发SIP请求(例如，“INVITE”、“ACK”、“BYE”)和SIP响应(例如，“100TRYING”、“180RINGING”、“200OK”)。与媒体中继服务器相比，媒体(例如，音频/视频)数据本身并不通过基本SIP代理(即，代理仅处理信令)，虽然在某些情况下可以组合代理和媒体中继功能。为了建立媒体会话，这些端点中的一个端点可以向另一个端点发送媒体会话请求。这里，发起对媒体会话(例如，音频/视频通信)的请求的端点称为“发起方端点”或等同地称为“呼叫者端点”。接收并处理来自呼叫者的通信请求的端点称为“响应端点”或“被呼叫者端点”。每个端点可以具有多个关联的传输地址，例如，本地传输地址、NAT的公共侧的传输地址、在中继服务器上分配的传输地址等等。在媒体会话建立期间，对于每个端点，可以为该端点选择用于在媒体会话中发送和接收数据的相应地址。例如，可以根据ICE(“交互式连接建立”)协议来选择这些地址。一旦建立了媒体会话，媒体就可以在不同端点的那些所选地址之间流动。

已知类型的媒体中继服务器是TURN(使用NAT周围的中继进行穿透)服务器，例如，合并TURN和STUN二者功能的TURN/STUN(用于NAT的会话穿透实用程序)。网络可以具有分层体系结构，由此不同的逻辑层提供不同类型的节点到节点通信服务。每个层由紧接着该层下方的层(除了最低层之外)提供服务，并且为紧接着该层上方的层(除了最高层之外)提供服务。媒体中继服务器区别于诸如路由器和NAT之类的下层组件，这是因为它在网络层的最高层(应用层)操作。应用层提供进程到进程连接。例如，TURN协议可以在应用层实现以处理(例如，生成、接收和/或处理)TURN消息，每个TURN消息由TURN报头和TURN有效载荷形成，TURN有效载荷包含例如用于输出给用户的媒体数据。将TURN消息传递到网络层下面的传输层。在传输层，实现诸如UDP(用户数据报协议)或TCP(传输控制协议)的一个或多个传输层协议，以便将一组接收到的TURN消息打包到一个或多个传输层分组中，每个传输层分组具有在传输层连接的单独传输层(例如，TCP/UDP)报头。传输层提供主机到主机(端到端)连接。转而，将传输层分组传递到传输层下面的互联网层(网络层)。在互联网层，实现诸如IP的互联网层协议以进一步将一组接收的传输层分组打包到一个或多个互联网层(例如，IP)分组中，每个互联层分组具有在互联网层连接的单独的网络层(例如，IP)报头。互联网层提供相邻网络之间的分组路由。转而，将互联网层分组向下传递到最低层(链路层)，以便成帧并且通过网络进行传输。在相反的方向上，将从网络接收的数据传递到IP层，在该IP层处，去除网络层(例如，IP)报头，将剩下的网络层有效载荷数据(其构成包括传输层报头的一个或多个传输层分组)传递到传输层。在传输层，去除传输层(例如，UDP/TCP)报头，并且将剩余的有效载荷数据(在该例子中，其构成一个或多个TURN消息)传递到应用层以进行最终处理，例如，将包含在其中的任何媒体数据输出给用户，或者用于中继TURN消息的目的。在两个端点和TURN服务器上实现这种类型的消息流，即端点和TURN服务器以这种方式在应用层操作。

IP地址唯一地标识网络内(例如，诸如互联网的公共网络内或在专用网络内)的网络节点的网络接口。可以在该节点中运行多个应用层进程，传输地址(IP地址+端口号)唯一地标识在该节点上运行的应用层进程。也就是说，为每个进程分配其自己唯一的端口。端口是一个软件实体，可以将该进程的消息写入该软件实体，以便它们可用于该进程。IP地址用于通过互联网层协议(例如，IP)在互联网层路由，构成包括在互联网层分组的报头中的互联网层网络地址，而传输层协议(例如，TCP/UDP)在传输层使用端口号以确保将接收到的数据传递到正确的应用层进程。传输层分组在报头中包含端口号，其标识了该分组的目的地进程。

与媒体中继服务器相比，路由器通常仅在互联网层操作，基于IP分组报头中的IP地址来路由IP分组。从理论上讲，NAT也仅在网络层运行，并且与基本路由器不同，这是因为NAT在路由期间修改IP报头以掩盖源的IP地址。但是，越来越多的NAT在传输层执行修改(即，对传输层分组报头进行修改)，以便也掩盖源端口号(例如，用于提供一对多的网络地址转换)。

在ICE的上下文中，可用于端点的传输地址(例如，其主机地址、映射到NAT上主机地址的公共地址、以及可以代表该端点从另一个端点接收媒体数据并且将其中继到其它端点的TURN服务器的传输地址)称为该端点的候选。它们由该端点确定，并且在候选收集阶段传送给另一个端点。随后，每个端点确定一组“候选对”，即，端点自己的地址与另一个端点的地址的一组可能的配对。随后，对每个候选对执行连接性检查以确定该候选对是否有效，即确定从该对中的端点自己的地址发送到该对中的另一个地址的探测数据是否被另一个端点成功接收。随后，在使用所选候选对(其在连接性检查中确定为有效)的端点之间建立媒体会话。从每个端点向所选候选对中的另一个端点的网络地址发送媒体会话的媒体数据。连接性检查的进度和候选对的状态，由在端点处实现的相应ICE状态机来跟踪。

也就是说，每个端点可以具有多个关联的传输地址(例如，本地传输地址、NAT公共侧的传输地址、在中继服务器上分配的传输地址等等)。在媒体会话建立期间，对于每个端点，为该端点选择相应的地址以用于发送和接收媒体会话中的数据。例如，可以根据ICE(“交互式连接建立”)协议来选择这些地址。一旦建立了媒体会话，媒体就可以在不同端点的那些所选地址之间流动。为了选择路径，生成候选对列表，其中的每个候选对包括可用于第一端点的网络地址(从第一端点的角度来看是“本地”候选)，但应当注意，该上下文中的“本地”并不限于其本地接口上的主机地址，并且还可以包括NAT的公共侧的自反地址、或者可以将媒体数据中继到第一端点的媒体中继服务器的中继网络地址(中继网络地址)、以及可用于第二端点的网络地址(从第一端点的角度来看是“远程”候选)。通过在连接性检查期间从本地地址向远程地址发送一个或多个探测消息，可以检查本地和远程候选的每个可能的配对以确定其是否有效。

发明内容

根据本发明的一个方面，一种会议服务器被配置为可从公共互联网直接访问，并且包括：具有主机传输地址的网络接口，所述主机传输地址是所述公共互联网上的公共IP地址和相关联端口的组合；会议主持逻辑，用于在所述会议服务器处主持至少一个会议，其中在所述至少一个会议中经由所述会议服务器在参与端点之间发送和接收媒体数据；媒体处理逻辑，其配置为处理所接收的所述会议的媒体数据以便在所述会议中传输；复用控制逻辑，其配置为确定所述参与端点要使用的多个复用令牌；解复用逻辑，其配置为在从所述主机传输地址处的所述参与端点接收的序列数据分组的传输层有效载荷数据中识别接收的复用令牌，并且使用在所述传输层有效载荷数据中识别的所述复用令牌来解复用所述数据分组以便由所述媒体处理逻辑进行处理。

举例而言，本发明的优选用例是提供全局“在线”会议服务器部署，其中，从服务提供商的域中托管的这种可公开访问的会议服务器的池中，将会议作为服务提供给多个组织。在这与更传统的本地部署形成对比，其中在本地部署中，每个组织由他们通常自己管理的本地部署来提供服务。

打开会议服务器以便使其在公共互联网上可访问，以这种方式提出了传统部署模型之外的各种挑战，特别是安全问题以及源自于在公共互联网上普遍存在NAT的挑战。如下面详细解释的，在传输层有效载荷数据中使用复用令牌可以为NAT提供增强的安全性和鲁棒性(特别地，但非排外地，在ICE的上下文中)。其还允许提供具有极少数端口的完全功能的会议服务器。这简化了对客户站点的要求，这是因为其只需要在防火墙上打开少量端口来与会议服务器通信，从而减轻网络管理员的安全关注。

在实施例中，会议服务器可以包括：候选收集逻辑，其配置为通过在所述会议服务器和所述参与端点中的每一个参与端点之间交换网络地址，来针对该参与端点确定一个或多个候选对的集合，其中所述集合中的至少一个候选对是包括所述主机传输地址和唯一地被选择供该参与端点使用的所述复用令牌中的一个复用令牌的复用候选对；连接性检查逻辑，其配置为针对所述参与端点中的每一个参与端点，对所述集合中的至少一个候选对执行连接性检查，以确定它是否有效；候选选择逻辑，其配置为针对所述会议中的每一个参与端点，选择被确定为在针对该参与端点的所述连接性检查中有效的候选对。在一些情况下，可以仅针对所述复用候选对执行所述连接性检查。

所述媒体处理逻辑可以包括音频混合逻辑，其配置为针对所主持的会议中的每个参与端点生成混合音频流。

所述媒体处理逻辑可以包括视频切换逻辑，其配置为针对所主持的会议中的每个参与端点，在不同的接收视频流之间切换。

所述复用令牌可以是经由安全信令信道，在所述会议服务器与所述参与端点之间协商的。

所述复用控制逻辑可以被配置为针对所述端点生成所述复用令牌。

所述解复用逻辑可以被配置为将从所述参与端点中的每一个参与端点接收的媒体数据提供给与该端点相关联的所述媒体处理逻辑的一个或多个媒体处理组件。

所述解复用逻辑可以被配置为通过以下方式，对从所述主机传输地址处的所述多个参与端点中的每一个参与端点接收的UDP数据报进行解复用：识别从该参与端点接收的所述UDP数据报中的每一个UDP数据报的传输层有效载荷数据中的接收复用令牌，从而将该参与端点识别为该数据报的源，以及将该UDP分组的媒体数据提供给与所识别的端点相关联的所述一个或多个媒体处理组件。

所述媒体处理逻辑可以被配置为在不使用利用所述UDP数据报指示的源传输地址的情况下，对所述UDP数据报进行解复用。

所述解复用逻辑可以被配置为通过以下方式，对从所述主机传输地址处的所述多个参与端点中的每一个参与端点接收的TCP分组进行解复用：与来自该端点的传入TCP连接请求相关联地，将在所述主机传输地址处从该端点接收的复用令牌识别为传输层有效载荷数据，从而将该端点识别为该TCP连接请求的源，接受所述传入TCP连接请求，从而建立TCP连接，以及将所述TCP连接与和所识别的端点相关联的所述一个或多个媒体处理功能相关联，从而经由所述TCP连接提供从所述端点到那些媒体处理组件的用于媒体数据的路径。

所述解复用逻辑可以被配置为：当与匹配的复用令牌相关联地接收时，接受来自该端点的新传入连接请求，从而建立新的TCP连接，并且将所述新的TCP连接与所述一个或多个媒体处理组件进行关联，从而经由所述新的TCP连接提供从所述端点到那些媒体处理组件的新路径。

当建立了所述新的TCP连接时，所述TCP连接可以持续存在，从而同时提供从所述端点到所述一个或多个媒体处理组件的两条路径。

可以接受所述TCP连接，并且使用AcceptEx功能来识别所述复用令牌，与所述TCP请求相关联地接收所述复用令牌，因为它是在所述AcceptEx功能读取的初始数据块中进行接收的。

所述网络接口可以具有用于接收TCP分组的第一传输地址和用于接收UDP数据报的第二传输地址。

在示例性Windows实现中，单个TCP套接字可以绑定到会议服务器上的第一传输地址的端口，并且单个UDP套接字绑定到会议服务器上的第二传输地址的端口，并且会议服务器的单个I/O(输入/输出)完成端口绑定到TCP和UDP套接字二者。

所述解复用逻辑可以包括多个处理器核，其中的每个处理器核被配置为服务所述I/O完成端口。

所述处理器核中的每一个可以被配置为执行至少两个线程，其中的每个线程被配置为服务所述I/O完成端口。

本发明的第二方面针对于一种在具有主机传输地址的会议服务器处主持至少一个会议的方法，其中在所述至少一个会议中经由所述会议服务器在参与端点之间发送和接收媒体数据，所述主机传输地址是公共互联网上的公共IP地址和相关联的端口的组合，使得所述会议服务器可从所述公共互联网直接访问，该方法包括在所述会议服务器处执行以下操作：确定要由所述参与端点使用的多个复用令牌；在从所述主机传输地址处的所述参与端点接收的序列数据分组的传输层有效载荷数据中识别接收的复用令牌；使用在所述传输层有效载荷数据中识别的所述复用令牌来解复用所述数据分组以便由所述媒体处理逻辑进行处理；以及处理在所述解复用的分组中接收的所述会议的媒体数据，以便在所述会议中传输。

在实施例中，可以在执行所述方法时，实现第一方面的会议服务器的任何特征或者其任何实施例。

本发明的第三方面针对于一种包括存储在计算机可读存储介质上的代码的计算机程序产品，当所述代码在会议服务器上执行时，所述代码被配置为实现第二方面的方法或者其任何实施例。

附图说明

为了帮助理解本发明并示出如何实现本发明的实施例，现在将仅通过示例的方式参考以下附图，其中：

·图1示出了一种通信系统；

·图1A示出了TURN部署场景；

·图2示出了一种用户设备的框图；

·图3示出了媒体中继服务器的框图；

·图4显示了分层网络架构的表示；

·图5示出了网络地址转换器的操作；

·图6示出了传统ICE信令流的信令图；

·图7示出了会议服务器部署在专用网络上的示例性服务器部署；

·图8示出了本发明实施例中的会议服务器的示例性架构；

·图9示出了本发明实施例中的会议服务器的功能框图；

·图10显示了用于会议服务器的线程模型的高层概述；以及

·图11示出了由端点和会议服务器执行的对等自反候选发现的例子。相同的附图标记表示附图中的相对应特征。

具体实施方式

会议服务器(本文还称为多点控制单元(MCU)或“媒体服务器”)指代能够主持一个或多个会议的服务器实体，其中优选地每个会议可以具有三个或更多参与者。除了将从会议参与者接收的媒体数据转发给会议中的其它参与者之外，它还实现了更高级别的会议主持功能，通常是更高级别的功能，比如音频混合(在音频会议中)、视频切换(在视频会议或屏幕共享上下文中)、存在性(即跟踪会议参与者、当他们加入和离开会议时)和业务逻辑功能。对于每个主持的会议，会议服务器维持该会议的状态，使得可以跟踪会议的进展情况。现代会议服务器还可以提供越来越丰富的会议主持功能，比如语言翻译、记录和广播(例如，在实时网络研讨会(Webinar)上下文中)。

在现有网络部署中，会议服务器往往不能在公共互联网上直接访问。相反，它们倾向于部署在专用网络(例如，企业网络)中，因此只能在该专用网络内直接访问。这意味着会议服务器只能通过公共互联网通过所谓的“边缘”服务器来访问，其中该“边缘”服务器提供专用网络和互联网之间的接口。

通过上下文的方式，下面描述这种部署的示例，其中，将作为TURN服务器的媒体中继服务器部署为边缘服务器，以提供从公共互联网到专用网络中的会议服务器的接口。

图1是一种通信系统的示意图，该通信系统包括：公共网络2；第一和第二端点，它们是由第一用户4a和第二用户4b操作的第一用户设备6a和第二用户设备6b；第三和第四端点，它们是由第三用户4’a和第四用户4’b操作的第三用户设备6’a和第四用户设备6’b；一个或多个媒体中继服务器14(两个通过示例的方式示出)；以及一个或多个代理服务器(通过示例的方式，示出了一个)，例如SIP服务器15。

公共网络2是公共互联网(大写I)，即全球的、具有公共地址空间并且根据TCP/IP协议套件操作的基于分组的互联网(也就是说，互连的单个网络的系统)。公共网络2包括多个路由器3，这些路由器3在互联网2的不同的单独网络(没有示出)之间路由业务。

互联网2的公共地址空间中的IP地址通常由互联网服务提供商(ISP)分配，其继而从更高级管理机构向ISP分配IP地址块。

图1还示出了连接到互联网2的至少一个会议服务器CS。会议服务器CS直接连接到互联网，这是因为它包括在互联网的公共地址空间中具有至少一个IP地址的网络接口19，其中通过互联网可以访问会议服务器CS。这使得会议服务器可直接访问公共互联网2上的端点6。

应当理解，这与上面所描述类型的更典型的会议服务器部署不同，并且以这种方式将会议服务器CS“打开”到公共互联网2，其与专用网络中更常规的部署相比产生了显著的额外挑战。这将在下面进行更详细地讨论，但是将首先描述图1的系统的第一其它细节以提供有用的上下文。

中继服务器14是TURN服务器，下面将描述其操作以提供本发明所述实施例的上下文。但是，应当注意，所描述的实施例的目的是通过将会议服务器CS打开到公共互联网2，在基本上消除TURN服务器14对会议服务器CS主持的呼叫的需求。

与会议服务器CS相比，媒体中继服务器14简单地将接收的媒体流中继到一个端点，而不提供会议服务器的任何更高级别功能。

用户设备6a、6’a连接到第一基于分组的专用网络5a并且是其网络节点，用户设备6b、6’b连接到第二基于分组的专用网络5b并且是其网络节点。

专用网络的每个节点在该专用网络的私有地址空间中具有相应的专用网络地址，连接到同一专用网络的其它节点(并且仅此类节点)可以用于通过该专用网络与该节点通信(并且仅通过该专用网络进行通信)。该地址是私有的，这是因为它不能用于通过未连接到同一专用网络的设备与该节点进行通信(例如，其不能在公共网络2中使用)。此外，虽然该地址在该专用网络内是唯一的，但是其它节点可以在不同网络内使用相同的网络地址(例如，第一用户设备6a和第二用户设备6b可能恰好具有相同的专用网络地址，但该专用网络地址可用于仅与第一专用网络5a内的第一用户设备6a通信、以及可用于仅与第二专用网络5b内的第二用户设备6b通信)。

为了使第一专用网络5a和第二专用网络5b的节点能够与公共网络2进行通信，它们分别经由第一和第二网络地址转换器(NAT)8a、8b连接到公共网络2。每个NAT 8a、8b在适用的私有地址空间中具有相应的专用网络地址(称为该NAT的专用网络侧的地址)以及在公共网络2的公共地址空间中具有相应的公共网络地址(称为NAT的公共网络侧的地址)。因此，第一和第二专用网络5a、5b的节点不仅可以使用那些NAT的专用网络地址分别与第一和第二NAT 8a、8b进行通信，而且该专用网络外部的节点可以使用那些NAT的公共网络地址与那些NAT 8a、8b进行通信。

NAT(例如，8a、8b)通过将专用网络的私有地址空间映射到公共网络的公共地址空间，作为专用网络(例如，5a、5b)和公共网络(例如，2)之间的接口进行操作，从而使专用网络的节点能够通过公共网络在专用网络外部进行通信。专用网络(5a/5b)之一之外的节点可以使用该NAT公共地址将用于该专用网络的特定节点的业务经由公共网络2引导到相关NAT(8a/8b)，然后NAT通过该专用网络将业务转发到该节点。

下面将详细地描述NAT的操作。

专用网络5a、5b和公共网络2构成通信网络1，其中各个用户设备6a、6’b、NAT 8a、8b、服务器14、15、CS和路由器3是其网络节点。通信网络1也是互联网(其包括互联网2的各个网络以及专用网络5a、5b)。

用户设备6a、6b运行通信客户端软件7a、7b的相应实例。客户端使用户设备6a、6b能够通过网络1在用户设备6a、6b之间建立媒体会话，例如以便有助于用户4a、4b之间的实时通信事件(例如，语音和/或视频呼叫)，使得用户4a、4b可以通过网络1彼此通信，在媒体会话中在设备6a、6b之间发送和接收呼叫音频和/或视频。在某种意义上，该通信是“实时的”，这是因为在近端设备处捕获的音频/视频与远端设备接收和输出的音频/视频之间仅存在较短的延迟(例如，大约2秒或更短)。用户设备6’a、6’b还运行客户端软件7a、7b的相应实例以达到类似的效果。客户端可以例如是在相关用户设备的处理器上执行的独立应用程序，或者是在诸如Web浏览器的处理器上执行的另一个应用程序的插件。

应当注意，术语“客户端”可以用于指代客户端软件或者执行该软件的端点设备；在上下文中它具有明确的含义。

替代地或另外地，用户设备可以通过不涉及任何NAT的一些其它机制连接到公共网络2(虽然在图2中没有示出)。例如，用户设备可以经由Wi-Fi连接来连接到专用网络，经由不涉及NAT的移动网络来连接到公共网络。

图1A示出了用于呼叫信令(不是媒体流)的示例性信令路径(其表示为虚线)。该信令在用户设备6a、6b之间经由SIP代理15来发送，该信令表示SIP请求-SIP响应消息的交换，其导致对呼叫或其它通信事件进行建立、终止、修改等等。

在所描绘的例子中，使用ICE协议的修改来建立用于呼叫的媒体路径，其中ICE信令采取特别是会议服务器CS与另一个端点6之间的候选提供-应答交换，通过一个或多个这种SIP代理15来发生。

一旦建立，呼叫的媒体数据可以在用户设备6a、6b流之间流动，例如通过一个或多个媒体中继服务器14，或者“直接”通过网络2进行路由，其不涉及任何应用层中介(即，只有诸如路由器3和NAT 8的低层中介)。

图2是用户设备6(例如，6a、6b、6’a、6’b)的示意性框图。用户设备6是可以采用多种形式的计算机设备，例如桌上型计算机或膝上型计算机、移动电话(例如，智能电话)、平板计算设备、可穿戴计算设备、电视(例如，智能电视)、机顶盒、游戏控制台等等。用户设备6包括连接到存储器20的处理器22、一个或多个输出设备(例如，显示器24和扬声器26)、一个或多个输入设备(例如，摄像机27和麦克风28)以及网络接口24(例如，以太网、Wi-Fi或移动网络(例如，3G、长期演进(LTE)等)接口，其使得用户设备6能够连接到网络1。显示器24可以包括触摸屏，其可以接收来自设备6的用户的触摸输入，在这种情况下，显示器24也是用户设备6的输入设备。显示连接到处理器的任何各种组件可以集成在用户设备6中，或者是非集成的并通过适当的外部接口(诸如以太网、通用串行总线(USB)、火线等等之类的有线，或者诸如Wi-Fi、蓝牙、近场通信(NFC)等等之类的无线)连接到处理器22。存储器20保存客户端7的副本，当其在处理器22上执行时，使用户设备6实现客户端7的功能。客户端7具有用户接口，以用于从用户设备6的用户接收信息并且向用户设备6的用户输出信息(其包括在诸如呼叫之类的通信事件期间)。

用户界面可以包括例如图形用户界面(GUI)，其经由显示器24和/或自然用户界面(NUI)输出信息，NUI使得用户能够以“自然”的方式与设备交互，免受某些输入设备(例如，鼠标、键盘、遥控器等等)施加的人为约束。NUI方法的示例包括利用以下的那些方法：触摸敏感显示器、语音和声音识别、意图和目标理解、使用深度相机的运动手势检测(例如，立体或飞行时间相机系统、红外相机系统、红色、绿色和蓝色(RGB)相机系统以及其组合)、使用加速度计/陀螺仪的运动手势检测、面部识别、3D显示、头部、眼睛、凝视跟踪、沉浸式增强现实和虚拟现实系统等等。

图3是会议服务器CS的示意性框图。会议服务器CS包括与存储器30连接的处理器32、以及网络接口19，如上所述，网络接口19被配置为使会议服务器CS能够直接连接到互联网2。存储器30保持会议控制软件13(即，可执行的计算机可读指令)，当该软件在处理器32上执行时，使会议服务器CS实现会议控制软件13的功能。虽然描述为单个实体，但会议服务器CS的功能可以分布在多个设备上(例如，数据中心中的多个服务器设备)。在这种情况下，这些服务器设备中的每一个可以在互联网2上单独地可达。

网络1具有分层体系结构，其中将网络1的功能组织成抽象层。这在图4中示意性地示出。在该例子中，网络1实现互联网协议套件，据此将功能组织成四个层108-102：应用层108(与OSI(“开放系统互连”)模型的第5、6和7层的组合相当)、应用层108下面的传输层106(与OSI模型的第4层相当)、在传输层106下面的网络层104(与OSI模型的第3层相当)(其是互联网层)层、在互联网层104下面的链路层102(与OSI模型的第1和2层的组合相当)。应用层108提供在不同的主机上运行的进程之间的进程间通信，即连接到网络1的通用计算机设备(例如，用户设备6和服务器12、14)(应当注意，路由器3和NAT 8不是“主机”，如本文中使用的术语)。传输层106提供不同主机之间的端到端通信，其包括在主机之间提供用于供进程使用的端到端通道。互联网层104经由在互联网层操作的路由器3/NAT 8来提供路由(即，互联网1的不同个体网络之间的通信)，其中后者提供互联网和传输层的网络地址信息的转换(网络地址转换)。链路层102提供物理网络地址(例如，互联网1的相同单独网络中的相邻节点的MAC(“媒体访问控制”)地址)之间的通信(例如，通过在链路层102处操作的网络交换机和/或集线器等等)。

在发送主机处，将通过网络1发送的应用层数据17(应用数据，例如用户数据)从应用层108传递到传输层106，在传输层106处根据诸如UDP(“用户数据报协议”)或TCP(“传输控制协议”)之类的传输层协议将其打包成传输层分组。TCP是“可靠的”流传输服务，这是因为它涉及确认/重传机制，而UDP是“不可靠的”流传输服务，这是因为它不涉及任何这样的机制。不可靠服务的分组称为数据报。然后，将传输层分组的数据(例如，TCP分组/UDP数据报)传递到该主机的互联网层104，在该主机的互联网层104处，根据互联网协议(其是互联网层协议)将数据进一步打包成IP数据报。然后，将IP数据报的数据传递到链路层102，以通过网络1向接收方主机进行传输。当在接收主机处接收到IP数据报的数据时，在该互联网层104处，从IP数据报的有效载荷中提取传输层分组的数据并且传递到传输层106，在传输层106处，从传输层分组的有效载荷中提取应用数据并且将其传递到应用层。

图4中示出了传输层分组(例如，TCP分组或UDP数据报)10。传输层分组106包括传输层报头(例如，UDP/TCP报头)10i(其在发送主机的传输层106处生成并且进行附接)和传输层有效载荷(例如UDP/TCP有效载荷)10ii(其对从应用层108接收的应用数据进行编码)。

还示出了IP数据报11。IP数据报11包括IP报头11i和IP有效载荷11ii，在发送主机的互联网层104处生成IP报头11i并且进行附加，IP有效载荷11ii对从传输层106接收的传输层分组的数据进行编码。IP报头包括目的地IP地址和源IP地址，目的地IP地址是IP分组11通过网络1引导到的IP地址，源IP地址是生成IP数据报的主机本地的IP地址(至少在分组生成的这个阶段)。

对于在专用网络(例如，5a/5b)内生成的分组，IP报头11i包括源IP地址，该源IP地址是该专用网络的私有地址空间中的专用网络地址(例如，用户设备6a/6b在5a/5b中的专用网络地址)。包含在一个或多个这样的IP分组有效载荷11i中的UDP/TCP报头10i包括与该私有地址相关联的端口的端口号。IP地址和端口号构成传输地址。

如上面所指示的，这种私有地址空间在该专用网络之外是不可用的。因此，如果使用简单路由器在该专用网络(例如，5a/5b)和公共互联网2之间转发IP数据报，则该专用网络之外的节点将无法响应这样的数据报，这是因为它们在IP报头中没有任何可用的源地址。

为此，NAT 8可以用于提供公共和专用网络之间的接口。

图5示出了NAT 8(例如，8a、8b)的操作。NAT通过专用网络5(例如，5a、5b)从该网络的节点(例如，用户设备6)(例如，6a/6’a、6b/6’b)接收IP数据报11。IP和TCP/UDP报头11i、10i传送用户设备6的初始源传输地址，其包括在专用网络5的私有地址空间中的用户设备6的专用网络地址(其是私有IP地址)以及与该私有地址相关联的端口。IP和UDP/TCP报头11i、10i还传送用户设备6已经向IP数据报11指示的目的地传输地址。

如图所示，对于每个IP数据报，NAT 8修改IP和TCP/UDP报头11i、10i以使用新的源传输地址替换初始源传输地址，从而生成具有修改的IP的修改的IP数据报11’和传送新的源传输地址的TCP/UDP报头11’i、10’i。NAT 8不修改目的地传输地址和应用数据17。新的传输地址由公共网络2的公共地址空间中的NAT 8的公共网络地址(其是公共IP地址)以及与该公共IP地址相关联的端口形成。

NAT 8维护初始传输地址和新传输地址之间的映射9，以便它可以通过专用网络5，将经由公共网络2已经引导到新传输地址的任何返回业务(并且因此将最终到达NAT 8)转发到用户设备6的初始传输地址。

在最简单的示例中，NAT只是将私有IP地址替换为其自己的公共IP网络地址，并且不会更改端口。但是，NAT越来越普遍地实现地址空间伪装，据此将私有地址空间隐藏在单个网络地址之后。为了防止返回分组中的歧义，NAT通常必须改变其它信息(例如，与源地址相关联的端口)。例如，NAT可以具有单个公共IP地址，并且用其自己的单个公共IP地址和唯一的端口(并且可能是不同的端口)替换私有地址空间中的每个传输地址，使得在专用网络之外，专用网络的节点仅通过与该单个公共IP地址相关联的端口来彼此区分。

这通常对于只是简单地直接响应IP报头中的源地址的协议(例如，超文本传输协议(HTTP))来说是可接受的。

但是，包括一些媒体会话信令协议(例如，会话发起协议(SIP))的其它协议也依赖于在应用数据17本身中编码的端点的地址。例如，SIP协议规定端点应当使用SIP邀请/SIP响应中包含的地址来建立媒体会话，其中将在应用程序数据层级对媒体会话进行编码。如图5中所示，NAT 8不对其进行修改。

因此，例如，假设图1中的第一用户设备6a要经由第一NAT 8a将构成媒体会话邀请的应用数据17发送到第二用户设备6b。因此，在接收到邀请后，NAT 8a将不会修改应用数据17，第二用户设备6b将尝试使用来自未修改的应用数据17的第一用户设备6a的未修改的私有传输来响应该邀请：这将失败，因为私有地址在专用网络5a之外是不可用的，因此不可能建立会话。类似地，即使第一用户设备6a不在NAT 8a之后而且具有其自己的公共IP地址，由于第二用户设备5b在NAT 5b之后，因此会话建立仍将失败：响应于具有会话邀请响应的邀请，第二用户设备6b将在应用数据层级编码的响应中包括第二专用网络5b的第二地址空间中的其自己的私有地址，这类似地不能被第一用户设备6a使用。

为此，已经开发了诸如STUN(“用于NAT的会话穿透实用程序”)和TURN(“使用中继NAT进行穿透”)之类的协议，以使得能够在由一个或多个NAT分隔的端点之间建立SIP会话等等。

STUN允许端点确定它是否位于NAT后面，如果是，则确定映射到发起方端点的私有地址的NAT的公共地址(即，有效地使其访问映射9)，使得端点可以在IP有效载荷中包括该公共地址而不是其自己的私有地址。通常，STUN通过发起方端点向STUN服务器发送查询来工作，该STUN服务器通过NAT并且通过公共网络将其作为IP数据报中继到STUN服务器。由于NAT使用NAT公共侧的相应公共地址来替换查询的IP报头中的私有地址，因此STUN服务器可以从查询的IP报头中获取后者，转而可以将其提供给发起方端点。然后，发起方端点可以使用该公共地址而不是其自己的私有地址来建立会话，从而在IP有效载荷层将可用地址传送到会话请求中的响应端点。响应端点可以类似地发现其相关联的公共地址，该公共地址可以在响应中的应用数据层级传送给发起方端点，而不是其自己的私有地址。STUN服务器的角色实际上是提供地址发现的角色，通常一旦建立媒体会话，STUN服务器就不参与媒体会话。

如本领域所公知的，存在以下的情况：即，即使已知NAT的公共地址(例如，当发起方端点和/或响应端点在对称NAT之后时)，也不能建立这样的会话。在这种环境下，通常可以通过TURN服务器中继媒体数据，来使用一个或多个TURN中继服务器来穿透NAT。

当端点需要使用传统的TURN中继时，它向TURN中继发送请求，请求在TURN中继上向该端点分配唯一的公共传输地址(即，单个端口)。如果请求被接受，则使用TURN服务器的公共地址作为该端点的源地址来建立媒体会话。该端点向TURN服务器媒体发送它希望在TURN消息中包含的会话中发送的媒体。TURN服务器从TURN消息中提取媒体，并且从TURN服务器上的公共地址中继转发，其中该公共地址已经分配给该端点作为源地址。TURN服务器还将针对该端点的数据(其已被引导到在TURN服务器上分配的地址)中继到包含在TURN消息中的该端点，以供该端点提取。

如果两个端点都位于不允许STUN的NAT后面，则每个端点都需要在TURN服务器上分配其自己的相应传输地址，在这种情况下，在这两个分配的TURN服务器地址之间建立媒体会话，并且每个端点中继/接收TURN消息中的数据，在媒体会话中将提供给TURN服务器的数据发送到分配给的那些端点的两个TURN服务器地址或者从其接收数据。

TURN中继需要至少在媒体会话持续时间在该(那些)服务器上分配资源(其包括在TURN服务器上分配的唯一公共传输地址)，并且还意味着与直接在端点之间或通过一个或多个NAT建立媒体会话相比，媒体会话的媒体通过较不直接的路径进行传播。虽然它确实需要额外的资源，但是TURN中继可以或多或少地保证通过网络为媒体会话提供可用的路径。

STUN和TURN功能可以并入到同一个服务器中，该服务器有时也称为TURN/STUN服务器，或简单地称为TURN服务器(即使它还包括STUN功能)。

图1的媒体中继服务器14是TURN服务器，其至少包含TURN功能，因此具有地址查找和媒体中继功能。替代地，可以在单独的服务器之间分割该功能和/或其它功能，或者由下面描述的媒体中继服务器14执行的功能可以由同一服务器来执行。

ICE(“交互式连接建立”)是用于为穿透网络地址NAT和防火墙的VoIP会话建立连接的已知协议，其尝试在媒体延迟方面建立最高效的路径以确保理想的媒体质量。可以在公众可获得的、J.Rosenberg发表的标题为“A Protocol for Network AddressTranslator(NAT)Traversal for Offer/Answer Protocols”(2010年4月)的RFC 5245交互式连接建立(ICE)中找到ICE协议的细节。在[MS-ICE2]交互式连接建立(ICE)扩展文档(http://msdn.microsoft.com/en-us/library/office/cc431504(v＝office.12).aspx)中规定了ICE协议的某些扩展。

在ICE的上下文中，相对于间接路径(例如，其涉及使用中间中继服务器(例如，通过TURN服务器中继))，客户端之间的直接路径(即，其不涉及任何TURN中继)优先用于媒体会话。通过一对传输地址来标识路径：其中一个传输地址用于发起方端点发送和接收数据，并且另一个传输地址用于响应端点发送和接收数据。

ICE协议尝试基于静态优先级来识别它认为最高效的路径，向可用于媒体会话的多个所谓“候选对”中的每一个分配静态优先级。候选者是与发起方端点或响应端点相关联的传输地址。候选对是一对候选者(i，r)，第一个(i)与发起方端点相关联(即，可用)，第二个(r)与响应端点相关联。术语“候选者”涉及以下事实：ICE机制最初假定与端点相关联的任何传输地址可用于媒体会话(尽管由于上述原因，它实际上可能不可用)，转而ICE协议涉及检测哪些识别候选者在实际上是可用的。

ICE将候选者分为3类：主机候选、自反候选和中继候选。

主机候选是所讨论的端点本地的传输地址，即在直接连接到端点的网络接口上。例如，用户设备6a、6b的私有地址对于这些用户设备是本地的并且因此是主机候选，类似地，如果用户设备直接连接到公共网络2(而不是经由NAT 8a、8b或者除了经由NAT 8a、8b之外)，则它们将拥有对这些用户设备本地的它们自己的公共地址(其也是主机地址)。

自反候选是对于端点来说不是本地的传输地址，而是NAT的公共端的转换传输地址(例如，如包括在图5的修改的IP报头11’i中)。这些被分为两个子类别：“服务器自反候选”，其是通过以上面所概述方式来查询服务器(例如，STUN服务器)发现的公共NAT地址；“对等自反候选”，其是在媒体会话的建立期间由另一个端点发现的(例如，如响应端点发现的与发起方端点相关联的公共端NAT地址，反之亦然)。

中继候选是以上面所概述方式从媒体中继服务器(例如，TURN服务器)分配的传输地址。

潜在地，任何发起方端点的候选传输地址都可以用于与任何响应端点的候选传输地址通信。也就是说，第一用户设备6a可以潜在地将来自其自己的任何相关地址的数据引导到与第二用户设备相关联的任何地址，反之亦然。

但是，在实践中，一些候选对将是无效的(即，不起作用)。例如，如果端点都在NAT之后并且它们的主机候选是专用网络5a/5b中的私有地址，则由于上面所讨论的原因，它们不太可能能够使用这些地址进行直接通信。但是，如果它们的主机候选是公共地址(当使用时，其不涉及通过任何NAT路由数据)，那么候选对可能是有效的。类似地，根据NAT的类型(例如，如果它是对称NAT)，可能不可能使用自反候选，如上所述。

因此，每个候选对潜在地代表通过某种类型的网络的路径，但是如果候选对实际上有效，则这种路径仅在实践中可用。

尝试候选对的顺序由ICE静态优先级方案决定，其中在较低优先级对之前尝试较高优先级对。

根据ICE协议，可以根据式1为每个候选者分配静态优先级：

优先级＝(2²⁴)*(类型首选项)+(2⁸)*(本地首选项)

a.+(2⁰)*(256－组件ID)

类型首选项是0到126(包括0和126)之间的整数，并且表示候选类型的首选项(本地、服务器自反、对等自反和中继)。126是最高优先级，而0是最低优先级。将值设置为0意味着此类候选将仅用作最后的手段。类型首选项对于相同类型的所有候选者是相同的，并且对于不同类型的候选者是不同的。对等自反候选的类型首选项高于服务器自反候选的类型首选项。ICE协议建议主机候选的值为126(除非它们来自虚拟专用网络(VPN)接口，在这种情况下建议为0)，服务器自反候选为100，对等自反候选为110，中继候选为0。本地首选项是一个从0到65535(包括0和65535)的整数，表示当端点是多宿主(连接到一个以上的计算机网络)时从中获取候选者的特定IP地址的首选项。当只有一个IP地址时，ICE建议将此值设置为最大值65535，在没有多宿主时有效地使该项成为冗余。组件标识(ID)项是候选者的标识符。可以看出，到目前为止，等式1中最重要的项是基于候选类型的第一项。因此，ICE优先级方案通过中继候选而不优先考虑间接路径，它仅作为最后的手段使用，此外将静态优先级偏置远离自反候选。一旦形成候选对并且根据式1分配优先级，就可以根据式2计算每个候选对的候选对静态优先级：

对优先级＝2³²*MIN(G，D)+2*MAX(G，D)+(G>D？1：0)

其中，G是发起方端点的候选者的静态优先级，D对应于响应端点的候选者，G>D？1：0是条件表达式，如果G大于D，则值为1，否则为0。

最低优先级路径是TURN-TURN路径(即，对应于TURN-TURN候选对)，其中两个网络地址都是TURN服务器地址，使得在两个方向上经由一个或多个TURN服务器来中继媒体数据。因此，在传统的ICE，仅在检查了所有其它候选对并且确定其无效时才进行检查，因此仅用作当所有其它选项已经确定用尽时的最后手段。

总而言之，ICE可以用于在被呼叫者端点和呼叫者端点之间建立媒体流。在典型的部署中，两个端点之间可能存在网络地址转换(NAT)设备或防火墙。部署NAT和防火墙以提供私有地址空间，并且确保专用网络到端点的安全。如果端点通告其本地接口地址，则远程端点可能无法访问它。此外，NAT和防火墙在创建NAT映射地址的方式上表现出不同的行为。ICE提供了用于帮助媒体穿透NAT和防火墙，而无需端点了解其网络拓扑结构的通用机制。ICE通过收集一个或多个传输地址来帮助媒体穿透NAT和防火墙，这两个端点可能潜在地使用所述一个或多个传输地址进行通信，然后确定哪个传输地址最适合两个端点用于建立媒体会话。

现有的ICE协议：

为了提供上下文，现在将参考图6来描述传统的ICE信令过程。

图6示出了用于概述使用ICE，在呼叫者端点6a和被呼叫者端点6b的两个端点之间建立会话时涉及的各个阶段的序列图。这些阶段是：

a.候选者收集以及在呼叫者和被呼叫者端点之间交换收集的传输地址(p1)；

b.连接性检查(P2)；

c.通过连接性检查选择的最终候选者的交换(P3)。

在候选收集阶段P1期间，端点收集用于连接的潜在候选者。这包括主机候选(绑定到本地接口)、服务器自反候选(使用TURN服务器14、使用STUN协议发现的NAT映射)、以及中继候选(转发在TURN 14上分配的端口，也称为媒体中继服务器的角色)。通过在呼叫者端点6a和TURN服务器14之一之间交换收集消息44a，来发现服务器自反和中继候选。响应于呼叫者端点6a处的会话发起指令40，发起候选收集阶段P1，在该例子中，从用户4a接收会话发起指令40，但也可以替代地自动生成(例如，在预定的时间)。

经由网络2，在初始提议消息46中将由呼叫者端点6a收集的候选者发送到被呼叫者端点6b。可以将该提议编码成会话描述协议(SDP)提议并且通过诸如SIP的信令协议进行交换。呼叫者端点6a用作控制代理，并且负责为媒体流选择最终候选者。被呼叫者端点6b响应于接收到提议46，通过与TURN服务器14之一(其可以是与由呼叫者端点6a使用的TURN服务器相同或不同的TURN服务器)交换候选收集消息44b，遵循相同的过程来收集其候选者。对其收集的候选者进行编码并且通过网络2在初始应答消息46R中发送给呼叫者。随着候选者的交换完成，每个端点6a、6b现在知道其对等体(即，其它端点)的候选者。

在呼叫者端点6a处，会话发起指令40构成会话发起信号。在被呼叫者端点6b处，其是来自呼叫者端点6a的构成会话发起信号的提议46。

为了确保每个端点可以接收其它候选者，可以例如经由一个或多个代理服务器15(例如，SIP服务器)中的一个代理服务器来发送候选者，虽然在图6中未示出。

在连接性检查阶段P2期间，两个端点6a、6b将本地候选者和远程候选者配对以形成基于候选对的优先级排序的候选对的所谓“检查列表”，并且使用STUN绑定请求响应交换来系统地执行连接性检查。

这涉及呼叫者端点6a和被呼叫者端点6b尝试以下列方式交换每个候选对的探测数据。对于每个候选对，端点6a、6b中的每一个向另一个端点发送探测消息48a、48b(其是STUN绑定请求)。将每个探测消息48a、48b发送到该候选对的另一端点中的传输地址，并且在其主体中指示该候选对的发送端点中的传输地址(即，在探测消息的应用层数据17内)，使得它不受探测消息在传输过程中通过的任何NAT 8a、8b对IP或传输报头10i/11i的任何修改的影响(如果这与IP和传输报头中表示的传输地址不同，接收端点可以推断出探测消息确实通过了NAT，并且还可以确定该NAT上的发送端点的公共传输地址。这是在连接性检查P2期间可以发现对等自反候选的手段，如本领域中已知的)。如果并且当该消息被另一个端点成功接收时，它将向在探测消息的正文中指示的传输地址发送响应48aR、48bR(STUN绑定响应)。如果并且当发送请求48a、48b的端点接收到响应时，该端点确定候选对是有效的。对于每个候选对，在一些情况下，如果没有接收到响应，端点可以尝试在适当的超时之后发送多个探测消息直到重试阈值为止，然后一旦达到重试阈值，则最终确定候选对是无效的。

基于ICE优先级的连接性检查排序的排序，确保TURN中继仅用作传统ICE中的最后手段(当且仅当所有其它类型的路径都失败时)。

在连接性检查结束时，呼叫者端点6a选择(在阶段P3中)要用于媒体流的最佳候选对，并且丢弃所有其它候选者。呼叫者端点6a在最终提议消息50中将所选择的候选对传送给被呼叫者端点6b，并且被呼叫者使用最终响应50R确认该选择。

一旦完成该最终应答-提议交换50、50R，就使用所选择的候选对建立媒体会话52，使得使用该候选对的传输地址在端点6a、6b之间发送媒体会话的媒体数据。根据选择的候选对，可以在端点的相应主机地址之间直接发送媒体数据(通常仅在端点不在NAT 8a、8b之后，或者如果它们碰巧在相同NAT之后使得它们的主机地址可彼此寻址时，才可能进行发送)，或在一个或两个方向上通过NAT 8a、8b发送(其中，所选定的对的一个或两个候选者是自反地址，使得将媒体数据发送到NAT的公共端上的地址)和/或在一个或两个方向上经由TURN服务器14进行发送(其中，所选定的对中的一个或两个候选者是中继候选)仅作为最后的手段。

ICE使用的使用中继NAT进行穿透(TURN)协议使位于一个或多个网络地址转换(NAT)后面的专用网络上的TURN客户端能够从位于互联网2上的TURN服务器分配传输地址。可以使用该分配的传输地址从对等体接收数据。TURN协议还使客户端能够发现其外部NAT映射。

在线服务部署：

图7示出了示例性服务部署的高度示意性框图。边缘服务器池802可以包括多个边缘服务器，经由外部防火墙806和(对于传入业务)至少一个负载平衡器804连接到公共互联网2。例如，这些可以实现为边缘服务器软件的单独实例(服务器滚动)。在云计算上下文中，每个实例可以在虚拟机上运行，该虚拟机在底层云计算硬件上执行。

在负载平衡器804处经由外部防火墙806接收来自连接到互联网2的外部客户端端点6E的请求，选择边缘池802中的可用边缘服务器实例(包含至少一个且优选地多个边缘服务器801)以根据适当的负载平衡方案来处理请求。也就是说，到负载平衡器804的公共IP地址。

边缘服务器801经由内部防火墙810和(对于进入的业务)至少一个另外的负载平衡器812，连接到专用网络(“FE盒”)中的前端(FE)企业池808，其同样可以包括多个服务器FE服务器807。可以在该另外的负载平衡器812处接收来自边缘服务器池802的请求，该另外的负载平衡器812选择前端池808中的可用FE服务器来处理该请求。

外部客户端6E可以经由互联网2但是仅经由边缘服务器801连接到FE服务器807。专用网络的任何内部客户端端点6I可以直接经由专用网络连接到FE服务器807；但是，部署可能没有这样的内部客户端6I(例如，“在线部署”)。

在在线部署中，服务提供商将会议作为服务提供给订阅公司或其它组织。服务提供商在其部署中托管所有的MCU服务器，并且订阅公司只是服务提供商提供的资源的消费者。服务提供商负责托管所有的多点控制单元(MCU)服务器，并且使部署简单易用和适用于订户。在线部署可以满足多个订阅会议服务的公司。

会议服务器-专用部署

作为上下文，在本节中，将参考图7来描述专用网络内的会议服务器的示例性部署，其中TURN服务器操作为边缘服务器。该节还将解释该部署模型的某些缺陷，下一节将解释如何在本发明的实施例中克服这些缺陷。

参考图7，边缘服务器801操作为中继服务器，具体而言是TURN服务器14而不是会议服务器CS，其中边缘池可以包括多个TURN服务器实例。

FE企业池808包含至少一个会议服务器实例，即至少一个MCU实例；也就是说，至少一个FE服务器807操作为会议服务器，但是只能经由边缘中继服务器801访问外部客户端6E。

部署的媒体栈传输层实现ICE协议(STUN和TURN)来在端点之间建立连接。也就是说，根据ICE远程函数调用(RFC)来提供媒体传输。如上所述，ICE协议是尝试收集和探测所有可用路径的通用机制。这是一种通用连接协议，不会尝试针对已知的部署约束进行优化，并且在此过程中需要时间来收集候选者并且收敛到最佳媒体路径，并且在此过程中将使用超出所必要带宽的带宽。

现在将描述该方法的各种缺点。

收集中继候选的延迟

在候选收集阶段期间，ICE尝试收集每一个可能的候选者。这包括TURN TCP、TURNUDP、服务器自反候选和主机候选。主机候选几乎可以即时收集，但是收集中继候选可能需要时间(特别是在糟糕的网络条件下)。中继候选的收集分两个阶段进行。下面是说明如何在图7的上下文中应用这一点的高层级解释，对于外部客户端端点6E尝试执行以下操作：

a.联系阶段：探测会议服务器边缘池802中的多个中继服务器(如果配置的话)以找到可到达的中继服务器实例。

b.分配阶段：从前一阶段到达的第一中继服务器实例收集中继候选。

联系阶段具有几秒的最坏情况超时(T1)。例如：如果没有任何服务器可到达，则在没有中继候选的情况下提议将在TI秒内准备好。仅当在联系阶段成功到达中继服务器时，该过程才进入分配阶段。分配阶段具有最坏情况超时(T2)，其也是几秒钟。包括两个阶段的绝对最坏情况是要准备提议约T1+T2秒。

发明人已经发现，实际上，必须显著地增加超时TI和T2以提高可靠性，这是因为如果端点在NAT后面，则分配中继候选的失败将导致连接失败。这可能会导致设置时间增加大约10秒或更长时间，这意味着呼叫建立时间会有明显的延迟。

中继候选分配中的脆弱性

发明人已经观察到，媒体中继分配失败构成了在这种部署中观察到的整体故障的非常重要部分。本节将介绍导致中继分配脆弱性的主要问题。令人惊讶的是，已经发现，虽然中继ICE候选者应该提供最大的可达性和连接性，但实际上这些通常是最脆弱的。

媒体中继部署复杂性

媒体中继服务器有两个接口：在线部署的数据中心中的服务器角色可访问内部接口、可从互联网2访问外部接口。这对部署管理员部署正确的ACL(访问控制列表)和路由规则以隔离内联网和互联网提出了很高的要求。已经发现这是这种部署中的故障和维护的持续性来源。

此外，虽然FE池808中的中继服务器可以使用基于硬件负载平衡器或基于域名系统(DNS)的负载平衡进行负载平衡，但是这两种方案都有其自身的成本和增加的复杂性。在实践中已经观察到一些错误配置的负载平衡器设置的实例。例如，无响应机器不进行负载平衡轮换、不正确的负载平衡策略(用于TCP的循环而不是针对连接数量等等)、非对称路由导致故障，仅举几个例子。负载平衡的复杂性随着部署的规模和复杂性而增加，对于为全球客户提供服务的全球网络而言，复杂性和维护可能会非常快速地失控。

呼叫建立时间约束

使用ICE，候选收集阶段是呼叫建立的一部分。这是在可靠性和确保及时收集候选者之间的良好平衡行为。这可能导致有耗网络上的中继分配失败(尤其是当TCP是唯一可用的连接时)。

此外，类似的问题也存在，例如，传输中继以及其Anycast(任播)部署模型。传输中继是可通过Anycast访问的TURN服务器版本。Anycast模型在本领域中是公知的，故本文不再详细讨论。

部署不可知连接方案

ICE的优点和缺点都是部署无关性的：它尝试探测所有可用路径，直到验证最高优先级路径或预定的超时到期(其导致延迟最多10秒或更长时间)为止。此外，该过程也可以在最坏的情况下使用超过100kbps来建立一个传输连接。

媒体延迟

利用图7的部署模型，会议服务器807不能由客户端6E直接到达，并且只能通过媒体中继服务器801到达。这为实时媒体业务增加了一个额外的跳和处理延迟。

全球与本地部署

历史上，上面参考图7描述的传输协议栈和部署模型主要面向内部部署模型。也就是说，可用的本地部署虽然可用于潜在的大量用户(例如，约100,000)，但仅为一个组织(例如，公司)提供服务。与在线部署相比，服务器由拥有公司进行托管，该公司还管理自己的部署、服务器和网络。显而易见的是，这与全球在线部署方案完全不同，全球在线部署方案具有自身特殊的挑战。

随着在线服务模式和移动终端的广泛采用，这种模型在可靠性与企业级会议解决方案的部署简易性和可维护性方面已不再适用。

会议服务器–专用部署

现在将描述本发明的优选实施例，其中提供可公开访问的会议服务器CS作为在线部署的一部分，并且旨在提供作为互联网服务的会议。同样，应当注意，在本文中可互换地使用术语“会议服务器”、“媒体服务器”和“MCU”。

该部署具有各种益处，其包括：

a.能够在任何地方和任何网络上以高可靠性为服务部署提供企业级实时媒体体验的能力。

b.能够降低与媒体服务器(例如，AVMCU(音频/视频MCU)、ASMCU(应用程序共享MCU)和中介服务器)的部署和维护相关联的部署复杂性和成本的能力。

c.在移动设备上提高呼叫建立可靠性并且缩短设置时间，特别是在网络条件和可用带宽受到严重限制的情况下。

d.为电话会议呼叫提供端点的无缝漫游。

e.能够实现直接多路径媒体流的能力。

可公开到达的媒体服务器

与图7的部署相比，其中在图7的部署中，媒体服务器实例在FE盒上运行并且不能直接到达客户端，而是部署媒体服务器以可直接到达客户端以完全避免媒体服务器对媒体中继的使用。对于具有针对媒体服务器的UDP或TCP连接的情况，客户端也不需要收集中继候选。

图8示出了会议服务器CS的池CSP的一个示例性部署，其中每个会议服务器CS都如上所述地配置。具体而言，池CSP中的每个会议服务器CS包括在互联网上分配了公共IP地址的网络接口19(如图1中所示)。池CPS中的会议服务器CS可以在一个数据中心中实现，或者跨多个数据中心来实现。

用于服务器池CSP的负载平衡机制LB负责选择会议服务器CS中的一个来主持特定的会议。这可以例如包括数据中心处的本地(优选硬件)负载平衡器，其选择该数据中心处的一个会议服务器来处理特定的会议(例如，当第一参与者加入时或者在某个其它适当的时间)。替代地或另外地，它可以包括基于DNS的负载平衡机制：在这种情况下，池CSP作为整体通过例如统一资源标识符(URI)(或URI集)来识别，基于DNS的负载平衡机制可以通过将URI解析为公共IP地址中的不同公共IP地址来在服务器CS之间进行选择。DNS和本地负载平衡(例如，用于选择特定数据中心来主持会议的基于DNS的负载平衡)的组合、以及本地负载平衡器因此选择该数据中心的一个服务器CS。

在任何情况下，每个会议服务器的网络接口19都具有至少一个(唯一的)公共IP地址，因此可以通过互联网2直接访问，这样，一旦其被选择主持特定会议，参与端点就可以直接通过互联网2将媒体数据发送给它以进行处理并且转发到该会议中的其它参与端点。

每个会议服务器CS例如可以是在数据中心上运行的虚拟机，在该虚拟机上执行会议控制代码13的单独实例。

对于由外部客户端6E正在参与的会议服务器CS所主持的会议，媒体中继(即，TURN)服务器14被降级为仅在特殊情况下使用(如果有的话)。

利用这种改变，消除了呼叫建立失败和延迟的主要来源。

应当注意，在该上下文中，会议服务器成为图6的ICE信令流程中的两个端点6a/6b之一(与作为端点6a/6b之间的中介的TURN服务器14相比)。因此，根据上下文，与图6的信令流有关的所有描述同样适用于作为端点6a或6b的会议服务器CS。

图9示出了会议服务器CS的功能框图，该会议服务器CS包括下面描述的各种类型的逻辑。这些逻辑中的每一个表示由图9的会议服务器池CSP中的每个会议服务器CS实现的功能。

具体而言，将会议服务器CS示出为包括会议主持逻辑902、媒体处理逻辑904、解复用逻辑906、复用控制逻辑908和ICE逻辑910。

会议主持逻辑902实现高级别会议主持功能，它可以例如包括以下类型的逻辑中的一个或多个：存在逻辑，其跟踪会议参与者的存在状态；翻译逻辑，其提供自动语言翻译(比方说，会议音频或文字)；记录逻辑，用于记录会议媒体(例如，创建可以稍后播放的电子存储的音频/视频记录)；广播逻辑，用于允许会议媒体以期望的方式进行广播(例如，在网络研讨会中)。会议主持逻辑902还可以包括业务逻辑；例如，应用规范访问会议服务器的规则，以及哪些用户可以访问哪些会议服务。

会议服务器CS可以同时主持多个会议，并且被配置为在会议服务器CS可访问的电子存储器903中针对每个主持的会议维持呼叫状态。举例而言，指示了第一和第二会议(conf.A、conf.B)，但是会议服务器CS可以同时主持更多会议。

例如，在电子存储器903中，每个会议可以具有唯一的会议标识符，该唯一的会议标识符形成该会议的会议状态的一部分。会议ID用于区分会议服务器CS主持的不同会议。

ICE逻辑910实现本文所描述的会议服务器CS的ICE功能，其包括候选收集、连接性检查和候选者选择。在该上下文中，会议服务器CS承担图6中的呼叫者端点6a(拨出场景)或被呼叫者端点6b(拨入场景)的角色，参见下文。

将媒体处理逻辑904示出为包括多个媒体处理组件(每个媒体处理组件用于不同的会议参与者)，媒体处理组件处理从该会议中的一个或多个其它参与者接收的媒体数据以便传输给该参与者。举例而言，图9示出了第一会议(conf.A)中的三个参与端点N、M和L(它们是用户操作的用户设备)，其中媒体处理组件fN、fM和fL分别生成用于传输到端点N、M和L的输出流。也就是说，在ICE连接性检查之后，它们将发送到为这些端点选择的候选者。

例如，媒体处理组件fN可以包括音频混合组件，其混合从conf.A中的端点M和L接收的音频数据以产生一个混合音频流，该混合音频流包括用于向conf.A中的N传输的M和L的音频数据(同样，fM可以混合用于M的N和L的流；fL可以混合用于L的N和M的音频)。

媒体处理组件fN还可以包括视频选择组件，其选择在视频会议中在会议服务器CS处接收的M和L的视频流中的一个或多个，以便传输到N。可以仅将接收的视频数据选择性地发送给其它参与者。例如，为了节省带宽，可以仅选择L个或M的流中的一个来传输到N。例如，当将L或M分类为说话端点(即，相应的用户正在说话)时，例如，如音频处理组件fN从它们在会议服务器CS处接收的音频数据所检测到的，只有说话端点的视频可以被发送到N。在将N分类为说话端点的情况下，组件fN可以例如一次一个地在L和M的视频流之间切换，使得N可以依次测量所有其他用户的反应。随着情况的变化，fN相应地在不同的视频流之间切换。(当然，这同样适用于fM关于N和L、fL关于N和M)。

为了获得最佳灵活性，可以在媒体处理逻辑904中为每个会议中的每个参与者实现单独且独立的媒体处理组件。也就是说，每个会议的每个参与者至少有一个媒体处理组件，以允许向每个参与者提供定制的会议体验。虽然不是必需的，但这通常是适当的，特别是在音频混合的情况下(其中在该情况下，通常优选的是每个会议中的每个参与者获得包含有同一会议中的所有其他参与者的音频(但不是他自己的)的混合音频流)。

解复用逻辑906从连接到会议服务器CS的参与端点接收媒体数据，并且对所接收的媒体数据进行解复用以使其可用于媒体处理逻辑904的正确媒体处理功能。遵循图9的示例：

a.来自会议A中的端点L的媒体数据可用于媒体处理功能rM和rN，以用于(选择性)处理和分别传输到会议A中的端点M和N；

b.来自会议A中的端点M的媒体数据可用于媒体处理功能rL和rN，以用于(选择性)处理和分别传输到会议A中的端点L和N；

c.来自会议A中的端点N的媒体数据可用于媒体处理功能rL和rM，以用于(选择性)处理和分别传输到会议A中的端点L和M。

在以这种方式使媒体数据可用于媒体处理逻辑904之前，需要对用于ICE连接性检查的一个或多个候选对进行协商，执行连接性检查，并且为每个参与端点选择候选对。

如下面所更详细描述的，ICE逻辑在候选收集阶段P1，通过代理服务器15、由会议服务器CS的主机传输地址(其是公共的、其本地接口19上的主机IP地址以及相关的端口)和唯一的复用令牌形成的至少一个多路复用主机候选来提议910。复用令牌由复用控制逻辑908管理，复用控制逻辑908优选地在服务器CS上生成它们。主机传输地址在多个端点之间共享，并且复用令牌用于对数据进行解复用，即分离从同一主机传输地址的不同端点接收的数据。

这包括连接性检查阶段P2，其中在阶段P2中，使用解复用逻辑906在探测消息中接收的复用令牌对共享的主机传输地址处接收的来自不同端点的探测消息进行解复用，使得它们可以由ICE逻辑910将它们处理为连接性检查的一部分。

在成功的连接性检查之后，使用接收的端点ID对每个主持会议的接收媒体数据进行解复用，其中接收的端点ID是复用令牌。将用于端点K的端点ID/复用令牌表示为eIDK(在图9的例子中，K＝L、M和N)。如上面所指示的，复用令牌是应用层数据17，并且因此形成传输层有效载荷数据11ii的一部分。例如，复用令牌eIDK可以包括在前几个字节中的瘦应用层报头中或者包括在传输层有效载荷数据11i的相应部分中。复用令牌eIDK与IP报头数据10i中的目的地IP地址和传输报头数据11i中的目的地端口一起构成在连接性检查之后由ICE逻辑910选择的会议服务器的候选者。

应当注意，在会议服务器CS处对TCP和UDP进行不同地处理。

对于UDP，每个UDP数据报在其传输层有效载荷数据10ii中包括复用令牌eIDK的副本，其用于对UDP数据报进行解复用以直接隔离在连接性检查中接收的探测数据，并且在会议本身期间将接收的媒体数据提供给媒体处理逻辑904的正确媒体处理功能。

但是，对于TCP，仅需要与传入的TCP连接请求相关联地发送复用令牌以允许传入的TCP请求与候选收集阶段P1中的相应的提议-应答交换相匹配。此时，基于接收到的分组中的源IP和端口(实际上可能是NAT的公共端的传输地址)来创建TCP套接字，其允许以常规方式对另外的TCP数据进行解复用。也就是说，此后，为每个TCP端点创建套接字，使得此后可以通过TCP套接字来接收数据，而不必在此后连续地包括复用令牌eIDK。例如，当第一探测消息从某个端点进入时，可以在连接性检查期间创建TCP套接字，此后可以在会议期间使用相同的套接字来向媒体处理逻辑904的正确媒体处理功能提供接收的媒体数据。

在TCP的上下文中，因此使用复用令牌对来自每个TCP端点的传入的TCP连接请求进行解复用，以允许该请求和所得到的TCP套接字与该端点的候选收集阶段P1中的较早的提议-应答交换相匹配。此后，基于源IP/端口，以TCP的传统方式对从该端点接收的数据进行解复用，并且在连接性检查P2期间经由该套接字输出到ICE逻辑210，或者一旦该端点成功加入了所要求的会议，则输出到媒体处理逻辑904进行处理。

下面描述其进一步的细节。

对于UDP/TCP使用这样的端点ID的益处是会议服务器CS不一定需要从提议应答中广告的IP地址/端口中接收入站TCP连接或UDP分组：考虑客户端在NAT后面的情况(在大多数情况下，它将是这种情形)；客户端将无法提前确定NAT将为针对服务器的TCP连接分配的IP和端口映射。这仅在连接性检查期间进行确定，作为对等自反候选(参见下文)。

在候选收集阶段P1中，在使用安全信令信道交换令牌的情况下，令牌还增加了额外的安全层。在这种情况下，会议服务器CS不仅可以验证由ICE协商的客户端IP地址和端口，还可以验证更安全的令牌eIDK。因此，除了令牌(即使是通过初始验证获得)之外，攻击者还必须猜测客户端IP和端口。因此，优选地，在提议-应答交换(图6的46、46R)期间，在候选收集阶段P1期间，复用令牌eIDK是经由安全信令信道(例如，安全套接字层(SSL)、传输层安全性(TLS)等)，在ICE逻辑910和客户端之间传送的。也就是说，使用某种形式的加密方法进行加密。

候选者收集变化

媒体服务器

媒体服务器角色不会收集或通告中继候选。他们将仅提供可通过互联网2从客户端6E直接访问的主机候选。

媒体服务器支持的候选类型是：

a.主机UDP互联网协议版本4(IP V4)候选。

b.主机UDP互联网协议版本6(IPV6)候选。

c.主机TCP IPv4被动/主动候选。

d.主机TCP IPv6被动/主动候选。

需要IPV6候选者支持仅支持IPV6的客户端的小型分组。

应当注意：并非每次呼叫都需要收集所有支持的候选类型，可以基于场景来优化候选收集。

会议拨入

会议拨入是会议会话的最常见用例。在这种情况下，会议服务器CS承担图6中的被呼叫者端点6b的角色。也就是说，对于拨入，会议服务器CS是被呼叫者，并且具有来自初始提议46的关于呼叫者端点6a支持的候选类型的信息。基于该信息，媒体服务器可以减少收集的候选者的数量。例如，如果客户端支持IPV4候选者，则会议服务器CS可以避免收集IPV6候选者。

类似地，如果客户端不在阻止NAT的UDP之后，则服务器可以避免收集TCP并且通告TCP候选者。

对于最常见的场景，媒体服务器CS因此将需要仅收集一个本地候选者(从其角度看是本地的)，即主机UDP候选者。

这将大大减少要探测的连接性检查路径的数量，并且减少连接性检查所需的带宽。

此外，将显著地减少常见的连接性检查失败桶。这种应答的生成将是即时的，因为只有收集主机候选者所需的操作才是本地套接字绑定。

会议拨出

对于拨出场景，会议服务器CS承担图6的信令流中的呼叫者端点6a的角色。由于在生成提议时不知道被呼叫者客户端端点6b的连接特性，所以来自媒体服务器的提议将包括上面所列出的所有四种主机候选类型。尽管该提议由多个候选者组成，但由于所有候选者都是本地候选者，因此该提议产生将同样是立即生成的。

客户端

如上面所指示的，客户端端点6E将在少数特殊情况下尝试收集最多的中继候选，这些情况可以根据上下文而变化。

这将显著地缩短服务器上的提议/应答生成时间，出于所有实际目的，在没有中继分配的情况下的提议和应答生成将是即时的。客户端6E将不再收集或通告服务器自反候选。

应当理解的是，这去除了图6中的两个候选收集交换44a、44b，允许呼叫者(根据上下文，其可以是会议服务器CS或客户端端点)立即生成初始提议46，并且在直接响应中生成针对初始提议46的应答46R。

客户端(如果他们支持IPV4的话)将仅提供IPV4主机候选。考虑客户端具有IPV4UDP连接的典型情况：客户端将仅提供一个候选主机。现在，连接性检查的范围减少到探测和验证单个媒体路径。

重要的是应当注意，具有UDP连接或TCP连接并不意味着客户端6E可以在互联网2上公开到达。对于大多数情况，客户端6E将在防火墙或NAT 8之后。在该情况下，将在下面关于“智能”连接性检查的部分中介绍建立连接的细节。

智能连接性检查

连接性检查将继续支持符合RFC的分组格式，但它们将利用会议加入场景和部署的知识来优化连接性检查，以提高可靠性并且降低带宽利用率。

候选对减少

对于客户端具有到互联网的IPV4连接的最常见方案。(注意：不一定是直接连接；它们可以在NAT 8后面)ICE状态机将减少到只有一个候选对。

当发生网络接口改变时，可以通过探测STUN或TURN服务器14来轻易地发现客户端连接特性。此外，可以为最常见家庭到工作转换，高速缓存此信息。

从会议服务器CS的角度来看，该候选对将是：

a.本地候选者：MCU主机候选，

b.远程候选者：客户主机候选远程候选者

每个候选都是UDP或TCP、IPV4或IP V6候选者，其取决于客户端连接特性。

例如：如果客户端IPV4 UDP连接，则创建的唯一候选对将是：

a.MCU UDP IPV4主机候选<->客户端UDP IPV4主机候选

即使对于由于任何原因不能检测到客户端6E特性的情况，也必须探测至多三条路径。这与完全遵循ICE协议时创建的候选对的平均数量相比显著减少。

NAT映射的动态发现

在候选收集阶段，由于发现服务器自反候选需要到达中继服务器14，所以省略服务器自反候选。替代开销，当前部署依赖于连接性检查来动态地发现客户端NAT映射(作为实时动态地对等导出的候选者)。也就是说，作为对等自反候选(参见上文)。

利用此方法，仍然保持NAT穿透能力。关键是媒体服务器是可公开到达的。对等导出的候选发现是ICE连接性检查的标准部分。

例如，图11示出了客户端端点6E在NAT 8之后并且具有UDP连接性的例子。唯一的候选对建立将是：

a.MCU主机(Y)<->客户端主机(X)

在MCU和客户端上。这里，X表示NAT 8之后的私有地址空间中的私有传输地址(不能直接从公共互联网2到达)，并且Y是会议服务器CS在互联网的公共地址空间中的公共传输地址。

在连接性检查期间，MCU将尝试从Y>X发送连接性检查分组，但是由于X不可公开到达，因此该路径将不起作用。

但是，当客户端从X->Y进行探测时，MCU将接收到该请求，但它将看到源自NAT映射地址X’的分组。MCU将发现X’作为新的对等导出远程候选者，并且在连接性检查期间在连接响应中将其传送到客户端端点。在从MCU接收的连接响应中，客户端6E将发现其自己的NAT映射(X’)作为对等导出的本地候选。

此时，MCU和客户端都发现了客户端的NAT映射。它们将尝试针对该路径的连接性检查：

a.Y<->X’与X’<->Y

并且将能够验证路径和设置媒体流。这样，现在通过来自媒体中继服务器14的任何帮助，已经建立了穿透NAT 8的呼叫。

无缝漫游

考虑客户端6E在NAT 8之后并且具有UDP互联网连接的前一部分中所示出的相同示例。

假设用户在家中在移动设备上加入了会议，并且在呼叫期间开始驱车到办公场所。最初在家庭Wi-Fi网络上加入该呼叫。随着用户移出Wi-Fi网络的范围，客户端6E接收到Wi-Fi已经掉线并且蜂窝(例如，3G)连接变得可用的接口改变通知。由于MCU是可公开到达的，因此客户端6E将绑定到3G接口并且向MCU发送路径改变请求。

该路径改变请求是具有添加到其的路径切换属性的STUN绑定请求消息。客户端6E将继续发送该请求，直到它从MCU获得STUN绑定响应为止。接收路径切换请求的MCU将进行切换，并且开始将媒体发送到路径改变请求消息的原始地址，还向客户端发送STUN绑定响应。

安全

由于路径切换消息是受MI(消息完整性)保护的STUN绑定请求，因此上面的路径切换不存在安全漏洞。

多路径媒体流

在几种场景下，在多个路径上向MCU发送媒体可能是有用的。

可以使多个接口处于活动状态的端点，能够同时使用这些接口来提高媒体质量。这可以是通过Wi-Fi和3G向MCU发送的相同的媒体，或者通过两个Wi-Fi接口发送的媒体。

在有耗条件下，与MCU建立多个TCP连接来发送媒体能够提供更佳的质量和可靠性。

多个接口

由于MCU是可公开到达的，因此当客户端6E具有可用的新附加接口时，它可以通过在请求中发送具有特殊多路径属性的STUN绑定请求，向MCU通知它正在使用多路径。如果MCU支持多路径，则它将以STUN绑定响应进行响应。此时，客户端6E可以开始使用该附加媒体路径。这可以是扩增媒体流以提高质量或者完全复制流。

多个TCP连接

该方案仅用于客户端仅与MCU建立TCP连接的情况。MCU将在媒体会话期间保持其TCP被动候选活动状态。客户端可以建立到MCU被动端口的多个TCP连接。类似于多接口支持，客户端可以使用在多接口部分中概述的STUN绑定请求响应机制来通告和协商多路径支持。

公共可到达媒体服务器的安全性分歧

公共可到达端口的攻击

服务器将受到攻击，并且应当能够处理恶意分组。恶意分组的威胁已经存在于图7的部署中(在该部署中，将媒体服务器隐藏在中继服务器之后确实提供了一层保护，但它并不完整：老练的攻击者仍然可以通过MCU向媒体服务器发送恶意分组，如果它们能够欺骗客户端IP地址的话)；但是，直接到达可以使这种攻击更容易。

令牌验证提供了检测和丢弃恶意分组的轻量级方式。此外，媒体RTP分组将受到安全实时传输协议(SRTP)的保护。

也可以在会议服务器CS的套接字上强制执行分组速率限制，以动态地警告和阻止攻击。

客户站点上的防火墙要求

部署模型将请求用户向我们的媒体服务器打开其防火墙。这可能存在部署不便性。

为了缓解这种情况，可以统一并且发布将托管MCU服务器的一组子网。对媒体服务器的可达性可以成为针对新客户站点的部署验证和进入过程的一部分。

减少的端口可靠会议

该部署模型将请求网络管理员向媒体服务器CS打开其防火墙。

现有的会议服务器倾向于为连接到它的每个端点分配一个唯一的端口：这需要在防火墙上打开大量端口。应当理解，这具有各种安全问题，并且可能存在明显的部署不便性。

但是，通过在会议服务器CS上使用复用的主机候选，显著地减少需要打开的端口的数量来减轻这种情况。

高水平设计方案

可以将会议服务器CS上的第一和第二端口(优选地，分别为用于UDP的3478和用于TCP的443)部署为可由客户端端点6E公开访问。该设计方案仅需要端口3478和443可直接到达。如果需要的话，可以为视频模态打开另外的端口。

例如，可以在会议服务器CS上提供每个模态每个传输协议一个端口。例如，一个TCP视频端口、一个TCP音频端口、一个UDP视频端口和一个UDP音频端口。

在图9中将这两个端口共同标记为912。实现端口复用的所有端点将媒体数据发送到用于TCP的端口443(例如，图9中的端点N)和用于UDP的端口3478(例如，端点M和L)。每个端口都称为共享端口，这是因为它在多个端点之间共享。

复用的服务器主机候选

媒体服务器CS提供一种新类型的复用候选：

a.a＝x-confcandidate：1 1UDP 2130706431 169.10.179.123 3478typ hostEndpointID：4567

b.a＝x-confcandidate：2 1TCP-PASS 174455807 132.245.112.38 443typ hostEndpointID：4567

也就是说，复用的主机候选是会议服务器CS的主机传输地址(公共IP+相关联端口)的组合，并且除了IP地址和端口之外，还是唯一分配的端点ID(复用令牌)。

如果客户端端点6E通告对新特征扩展的支持，则媒体服务器CS将仅提供新类型的候选者。通过SDP来协商支持。

用户只需为端口3478和443正确地设置配置即可实现最佳连接。

对于拨出呼叫，除了x-confcandidate之外，还将提供常规(非复用的)候选者，以提供向后兼容性。例如，唯一的主机传输地址(注意，如果要支持向后兼容性，则需要在用户的防火墙上打开另外的端口)。

endpointID优选地由媒体服务器生成。它也可以替代地由端点生成，例如，作为全球唯一标识符(GUD)。但是，这可能需要使用更长的ID，其意味着额外的开销。

不支持高级功能的客户端可以安全地忽略这些行。

应当注意，在绝大多数情况下，客户端或服务器的角色都不需要收集中继候选，因为只使用主机候选。

后续部分描述了对媒体分组进行解复用的线程和过程，其中MCU为所有提议/应答提供相同的主机IP地址+端口。

线程架构

参考图10，现在将描述在Windows服务器架构中的会议服务器CS处，服务用于UDP的3478和用于TCP的443上的所有媒体业务的线程模型。

MCU具有绑定到3478的一个UDP套接字(US)和绑定到443的一个TCP侦听套接字(TS)。两个套接字都将关联到相同的I/O(输入/输出)完成端口(IO)。该I/O完成端口将由多个线程1004服务，其中该数量是会议服务器CS的物理核1002的数量的两倍。也就是说，处理传入业务的物理计算机设备上的物理处理器核(例如，中央处理单元(CPU)核)的数量的两倍。I/O完成端口提供改进的服务器规模和性能。

将两个线程关联(分配)到每个物理核，以将负载均匀地分布在可用核心上。工作线程的唯一目的是接收、发布和分配用于UDP的缓冲区和接受用于TCP的入站TCP连接。

UDP媒体接收

对于UDP媒体业务(例如，音频/视频)，客户端6E将需要增加具有端点的瘦报头，以使服务器能够对在3478上接收的分组进行解复用。给定预期在单个MCU上运行的预期数量的端点，四字节帧可能是足够的。

当在服务器上接收到UDP分组时，工作线程将基于在成帧中提供的端点，将缓冲区分派给一组无锁队列中的一个。每个端点ID一个队列。考虑具有N个参与者的会议。服务器上将有表示每个参与者的N个端点。用于每个用户的媒体分组/缓冲区将使用相应的端点ID(令牌)进行封装。基于端点ID，可以向媒体缓冲区分派正确的端点队列和因此正确的端点。

TCP接受

在443上接收的TCP连接将由AcceptEx提供服务，因为这样不仅能够高效地接受入站连接，还能够读取前几个字节以识别端点。也就是说，读取TCP报头数据(10i，图4)来接受连接，它还读取TCP有效载荷数据10ii的前几个字节(在这种情况下，其包含endpointID)。

AcceptEx函数是Windows套接字详细说明的特定于Microsoft的扩展，可以在以下网址找到其详细信息：https://msdn.microsoft.com/en-us/library/windows/desktop/ms737524(v＝vs85).aspx。简而言之，AcceptEx函数不仅接受传入的TCP连接请求，还读取从客户端接收的传输层有效载荷数据的初始块，在这种情况下包括复用的令牌eID。

此后，TCP不需要任何另外的成帧，这是因为将为每个接受的连接创建新的TCP套接字。将新创建的套接字分派到相应的端点。

媒体发送

对于从服务器CS向客户端6E发送的缓冲区，可以使用来自会议服务器CS的引擎线程的非阻塞同步发送，或者替代地，基于IOCP(I/O完成端口)的发送。该线程模型可以与现有体系结构共存，以支持传统和第三方端点。

应当注意：可以以与上面所描述的相同方式来实现IPV6支持。

中途呼叫掉线和漫游

利用这种设计方案，中途呼叫失败只会在极端故障情况下发生，此时客户端会遇到完全的网络故障。可以高效地恢复呼叫而无需信令或者ICE重新协商等的额外复杂性。由于服务器CS是始终可达的，因此客户端可以发送控制消息，请求服务器开始将媒体发送到用于UDP的不同IP/端口或者使用TCP的新TCP连接。

UDP

如果客户端现有网络断开或出现新接口，则恢复所有客户端必须做的是绑定到新接口并且开始发送包含endpointID的缓冲区。将传递该缓冲区，呼叫将以具有最小中断时间来继续。服务器完全不知道对等客户端端点使用的接口在接收方向上已发生变化的事实。客户端可以向服务器发送控制消息以开始向新IP/端口发送媒体。

TCP

在TCP的情况下，如果现有TCP连接断开，则所有客户端需要恢复的是在新的TCP连接上重新连接MCU，并且发送控制以请求服务器切换到新的TCP连接。媒体将以最小的中断继续流动。这种机制仅适用于音频、视频和基于视频的屏幕共享(VBSS)。(注意：支持这种场景用于基于RDP的共享将具有额外的复杂性，这是因为其需要无损传输并且甚至不能丢失单个缓冲区)。

多路径

继续上一节，多路径自然适合复用的服务器候选概念。对于多路径，主要目标是克服有耗的第一跳网络条件。客户端可以绑定到不同类型的接口并且发送媒体业务。只要使用相同的endpointID，就将媒体缓冲区传递到正确的无锁队列。对于TCP场景，客户端可以与MCU具有多个TCP连接。这可以来自不同的接口类型，也可以来自相同的接口类型，以提高吞吐量和可靠性。

监测和报警

媒体服务器将为遥测和诊断保留特殊的“endpointID”。也就是说，实际上不需要对特定端点唯一的特殊复用令牌。

利用此特殊endpointID发送到UDP上的端口3478或TCP上的443的请求，将被传送到将响应连接探测的会议服务器CS的模块。为了安全起见，该模块仅支持简单的请求响应交换。这使得独立于部署和证书管理/凭证依赖性的组件能够评估服务器的连接性和网络状况。

通过这种支持，可以轻松地将探测器部署到客户部署中的Azure、Min-Top盒子，部署的综合事务部分或独立工具为客户提供故障排除和部署验证。这将使得能够实时地监测我们的部署，并且在媒体中继服务器不可用时发出警报。

总之，上面所描述的过程具有各种优点，即：

a.提议和应答生成是即时的，这是因为不需要收集中继候选。

b.连接性检查快速且可靠，并且通常需要大约15kbs或更少，这是因为要探测的路径的数量非常小。对于大多数情况，可以减少到最多两个路径。

c.涉及的TCP连接和媒体支路的数量减少到一个。这将改善对于仅限TCP的客户环境(例如，Microsoft的3M)的支持。

d.解决或缓解媒体可靠性的所有已知主要问题，并且还通过媒体路径中涉及的数量减少的服务器来潜在地提高媒体质量。

通常，本文所描述的任何功能可以使用软件、固件、硬件(例如，固定逻辑电路)或这些实施方式的组合来实现。如本文所使用的术语“模块”、“功能”、“组件”和“逻辑”通常表示软件、固件、硬件或者其组合。在软件实现的情况下，模块、功能或逻辑表示程序代码，当其在处理器(例如，CPU或CPU集)上执行时执行指定的任务。程序代码可以存储在一个或多个计算机可读存储器设备中。下面描述的技术的特征是独立于平台的，其意味着这些技术可以在具有各种处理器的各种商业计算平台上可以实现。例如，用户设备(用户终端)还可以包括使得用户终端的硬件执行操作(例如，处理器功能块等等)的实体(例如，软件)。例如，用户终端可以包括计算机可读介质，该计算机可读介质可以被配置为维护引起用户终端并且(更具体地)操作系统和用户终端的相关硬件执行操作的指令。因此，这些指令用于配置操作系统和相关硬件执行操作，并且以这种方式导致操作系统和相关硬件的转换以执行功能。指令可以由计算机可读介质通过各种不同配置提供给用户终端。计算机可读介质的一种这样的配置是信号承载介质，因此被配置为例如经由网络将指令(例如，载波)发送到计算设备。计算机可读介质还可以被配置为计算机可读存储介质，因此不是信号承载介质。计算机可读存储介质的示例包括随机存取存储器(RAM)、只读存储器(ROM)、光盘、闪存、硬盘存储器、以及可以使用磁性、光学和其它技术来存储指令和其它数据的其它存储器设备。

虽然已经在ICE/TURN/STUN协议的上下文中描述了本发明的实施例，但是本发明并不受此限制并且可以在其它上下文中实现。

虽然以特定于结构特征和/或方法动作的语言描述了本发明的主题，但应当理解，所附权利要求书中规定的主题并不必限于上述的具体特征或动作。而是，将上面所描述的具体特征和动作公开为实现权利要求的示例性形式。

Claims (15)

1.一种被配置为能从公共互联网直接访问的会议服务器，所述会议服务器包括：

具有主机传输地址的网络接口，所述主机传输地址是所述公共互联网上的公共IP地址和相关联端口的组合；

会议主持逻辑，其用于在所述会议服务器处主持至少一个会议，其中在所述至少一个会议中经由所述会议服务器在参与端点之间发送和接收媒体数据；

媒体处理逻辑，其配置为处理所接收的所述会议的媒体数据以便在所述会议中传输；

复用控制逻辑，其配置为管理所述参与端点要使用的所述会议服务器生成的多个复用令牌以识别所述参与端点；以及

解复用逻辑，其配置为在从所述主机传输地址处的所述参与端点接收的序列数据分组的传输层有效载荷数据中识别接收的复用令牌，并且使用在所述传输层有效载荷数据中识别的所述复用令牌来解复用所述数据分组以便由所述媒体处理逻辑进行处理。

2.根据权利要求1所述的会议服务器，其包括：

候选收集逻辑，其配置为通过在所述会议服务器和所述参与端点中的每一个参与端点之间交换网络地址，来针对该参与端点确定一个或多个候选对的集合，其中，所述集合中的至少一个候选对是包括所述主机传输地址和唯一地被选择供该参与端点使用的所述复用令牌中的一个复用令牌的复用候选对；

连接性检查逻辑，其配置为针对所述参与端点中的每一个参与端点，对所述集合中的至少一个候选对执行连接性检查，以确定它是否有效；以及

候选选择逻辑，其配置为针对所述会议中的每一个参与端点，选择被确定为在针对该参与端点的所述连接性检查中有效的候选对。

3.根据权利要求2所述的会议服务器，其中，仅针对所述复用候选对执行连接性检查。

4.根据权利要求1、2或3所述的会议服务器，其中，所述媒体处理逻辑包括：

音频混合逻辑，其配置为针对所主持的会议中的每个参与端点生成混合音频流，和/或

视频切换逻辑，其配置为针对所主持的会议中的每个参与端点，在不同的接收视频流之间切换。

5.根据权利要求1所述的会议服务器，其中，所述复用令牌是经由安全信令信道，在所述会议服务器与所述参与端点之间协商的。

6.根据权利要求1所述的会议服务器，其中，所述复用控制逻辑被配置为针对所述参与端点生成所述复用令牌。

7.根据权利要求1所述的会议服务器，其中，所述解复用逻辑被配置为将从所述参与端点中的每一个参与端点接收的媒体数据提供给与该参与端点相关联的所述媒体处理逻辑的一个或多个媒体处理组件。

8.根据权利要求7所述的会议服务器，其中，所述解复用逻辑被配置为通过以下方式，对从所述主机传输地址处的多个参与端点中的每一个参与端点接收的UDP数据报进行解复用：

识别从该参与端点接收的所述UDP数据报中的每一个UDP数据报的传输层有效载荷数据中的接收复用令牌，从而将该参与端点识别为该数据报的源，以及

将该UDP数据报的媒体数据提供给与所识别的端点相关联的所述一个或多个媒体处理组件。

9.根据权利要求8所述的会议服务器，其中，所述媒体处理逻辑被配置为在不使用利用所述UDP数据报指示的源传输地址的情况下，对所述UDP数据报进行解复用。

10.根据权利要求9所述的会议服务器，其中，所述解复用逻辑被配置为通过以下方式，对从所述主机传输地址处的所述多个参与端点中的每一个参与端点接收的TCP分组进行解复用：

与来自该端点的传入TCP连接请求相关联地，将在所述主机传输地址处从该端点接收的复用令牌识别为传输层有效载荷数据，从而将该端点识别为该TCP连接请求的源，

接受所述传入TCP连接请求，从而建立TCP连接，以及

将所述TCP连接与和所识别的端点相关联的所述一个或多个媒体处理功能相关联，从而经由所述TCP连接提供从所述端点到那些媒体处理组件的用于媒体数据的路径。

11.根据权利要求10所述的会议服务器，其中，所述解复用逻辑被配置为：当与匹配的复用令牌相关联地接收时，接受来自该端点的新传入连接请求，从而建立新的TCP连接，并且将所述新的TCP连接与所述一个或多个媒体处理组件进行关联，从而经由所述新的TCP连接提供从所述端点到那些媒体处理组件的新路径。

12.根据权利要求11所述的会议服务器，其中，当建立了所述新的TCP连接时，所述TCP连接持续存在，从而同时提供从所述端点到所述一个或多个媒体处理组件的两条路径。

13.根据权利要求1所述的会议服务器，其中，所述网络接口具有用于接收TCP分组的第一传输地址和用于接收UDP数据报的第二传输地址。

14.一种在具有主机传输地址的会议服务器处主持至少一个会议的方法，其中在所述至少一个会议中经由所述会议服务器在参与端点之间发送和接收媒体数据，所述主机传输地址是公共互联网上的公共IP地址和相关联的端口的组合，使得所述会议服务器能从所述公共互联网直接访问，所述方法包括在所述会议服务器处执行以下操作：

管理要由所述参与端点使用的所述会议服务器生成的多个复用令牌以识别所述参与端点；

在从所述主机传输地址处的所述参与端点接收的序列数据分组的传输层有效载荷数据中识别接收的复用令牌；

使用在所述传输层有效载荷数据中识别的所述复用令牌来解复用所述数据分组以便由媒体处理逻辑进行处理；以及

处理在所述解复用的分组中接收的所述会议的媒体数据，以便在所述会议中传输。

15.一种计算机可读存储介质，其上存储能够由处理器执行的代码，当所述代码在会议服务器上执行时，所述代码被配置为实现权利要求14所述的方法。

Images