用于建立媒体会话的方法和装置

本申请是申请日为2016年6月24日、申请号为201680037441.6的发明专利申请“用于建立媒体会话的方法和装置”的分案申请。

背景技术

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

可以在经由通信网络连接的两个端点(例如，用户设备)之间建立媒体会话，使得实时媒体在这些端点之间可以经由网络被发送和接收。端点运行客户端软件以使媒体会话能够被建立。媒体会话可以是IP语音或视频(VOIP)会话，其中呼叫的音频和/或视频数据作为媒体流在VOIP会话中的端点之间被发送和接收。端点和其他类型的网络节点可以由网络地址(例如，IP地址)来标识。传输地址由IP地址和标识与IP地址相关联的端口的端口编号组成。可以在与端点相关联的传输地址之间建立媒体会话。媒体会话的示例是SIP(“会话初始化协议”)媒体会话。例如建立或终止呼叫或其他通信事件的SIP信令可以经由一个或多个SIP(代理)服务器。为此，SIP代理在端点之间转发SIP请求(例如“邀请(INVITE)”、“确认(ACK)”、“再见(BYE)”)和SIP响应(例如“100尝试(100TRYING)”，“180振铃(180RINGING)”，“200确定(200OK)”)。与媒体中继服务器形成对比，媒体(音频/视频)数据本身并不经由基本SIP代理来流送，即代理仅处理信令，尽管在某些情况下可能在某些情况下将代理和媒体中继功能进行组合。为了建立媒体会话，端点中的一个可以将媒体会话请求发送到其他端点。本文中，发起针对媒体会话(例如，音频/视频通信)的请求的端点被称为“发起端点”或者等同于“呼叫方端点”。接收并且处理来自呼叫方的通信请求的端点被称为“响应端点”或“被呼叫方端点”。每一个端点都可以具有多个相关联的传输地址，例如，本地传输地址、NAT的公共端的传输地址、被分配在中继服务器上的传输地址等。在媒体会话建立期间，对于每一个端点，可以针对该端点选择相应的地址以用于发送和接收媒体会话中的数据。例如，地址可以根据ICE(“交互连接建立”)协议来选择。一旦建立了媒体会话，媒体可以在不同端点的那些选定的地址之间进行流送。

已知类型的媒体中继服务器是TURN(围绕NAT使用中继遍历(Traversal UsingRelays around NAT))服务器，例如，包含TURN和STUN功能的TURN/STUN(用于NAT的会话遍历实用程序(Session Traversal Utilities for NAT))。网络可以具有分层架构，由此不同的逻辑层提供不同类型的节点到节点通信服务。每一个层都由该层下面紧靠的层(除了最低的层之外)来服务，并向该层上面紧靠的层(除最高的层之外)提供服务。媒体中继服务器区别于较低层组件(例如路由器和NAT)，因为媒体中继服务器在网络层的最高层(应用层)处工作。应用层提供了进程到进程连接。例如，可以在应用层实现TURN协议以处理(例如，生成、接收和/或处理)TURN消息，每一个TURN消息由TURN报头和包含例如用于输出到用户的媒体数据的TURN有效负载组成。TURN消息被向下传递到网络层下面的传输层。在传输层，实现一个或多个传输层协议(例如，UDP(用户数据报协议)、TCP(传输控制协议))以将一组接收的TURN消息打包成一个或多个传输层分组，每一个传输层分组都具有在传输层被附接的各自的传输层(例如，TCP/UDP)报头。传输层提供主机到主机(端到端)连接。传输层分组进而被传递到传输层下面的互联网层(网络层)。在互联网层，实现互联网层协议(例如IP)以进一步将一组接收的传输层分组打包成一个或多个互联网层(例如IP)分组，每一个互联网层分组都具有在互联网层被附接的各自的网络层(例如IP)报头。互联网层提供相邻网络之间的分组路由。互联网层分组进而被向下传递到最低层(链路层)以用于经由网络进行组帧和传输。在相反的方向上，从网络接收的数据被向上传递到IP层，在此网络层(例如，IP)报头被移除并且剩余的网络层有效负载数据被向上传递到传输层，该网络层有效负载数据构成了包括传输层报头的一个或多个传输层分组。在传输层，传输层(例如，UDP/TCP)报头被移除并且在该示例中构成一个或多个TURN消息的剩余的有效负载数据被向上传递到应用层以用于最终处理，例如，将包含在其中的任何媒体数据输出给用户，或用于向前中继TUN消息的目的。这种类型的消息流在端点和TURN服务器两者上被实现，即端点和TURN服务器以这种方式在应用层工作。

IP地址唯一地标识网络内(例如，在公共网络(例如，互联网)内或私有网络内)的网络节点的网络接口。可以存在多个应用层进程在该节点中运行，并且传输地址(IP地址+端口编号)唯一地标识在该节点上运行的应用层进程。即，每一个进程都被分配有其本身唯一的端口。该端口(或者等同地“套接字”)是软件实体，针对该进程的消息可以被写入到该软件实体中，使得它们变得可用于该进程。IP地址通过互联网层协议(例如IP)用于在互联网层进行路由，并且构成被包含在互联网层分组的报头中的互联网层网络地址，而端口编号通过传输层协议(例如TCP/UDP)被用在传输层以确保接收的数据被传递到正确的应用层进程。传输层分组将端口编号包括在报头中，其标识该分组被派往的进程。根据TCP/IP协议套件，端口编号的长度为16比特。这表示可以最多将2

与媒体中继服务器形成对比，路由器通常仅在互联网层工作，基于IP分组报头中的IP地址来路由IP分组。理论上，NAT也仅在网络层工作，并且区别于基本路由器，因为NAT在路由期间修改IP报头以掩盖源的IP地址。然而，越来越多的NAT在传输层执行修改，即对传输层分组报头进行修改，从而也掩盖源端口编号，例如，提供一对多的网络地址转换。

发明内容

提供本发明内容以便以简化的形式来引入下面的具体实施方式部分中进一步描述的概念的选择。本发明内容不是要识别所要求保护的主题的关键特征或主要特征，也不是要用作限制所要求保护的主题的范围。

通过并行地从第一端点发送以下消息，在第一端点和第二端点之间建立媒体会话：

·到第二端点的，指示对第一端点可用的媒体中继服务器的第一服务器网络地址并且包括唯一的会话标识符的消息；

·到媒体中继服务器的，包括唯一的会话标识符的激活请求。这通过使会话标识符在媒体中继服务器处与由激活请求传送的源地址相关联来激活会话标识符。

一旦会话标识符被激活，则在第一服务器网络地址处从第二端点接收的包括唯一会话标识符的媒体分组从媒体中继服务器被中继到源地址以用于由第一端点接收。

附图说明

为了帮助理解主题并且说明如何实现该主题，现在将仅以示例的方式来参考以下附图，在附图中：

图1示出了通信系统；

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

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

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

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

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

图6A示出了用于常规交互式连接建立过程的信令图；

图6B示出了典型的TURN部署场景；

图6C示出了用于创建常规TURN会话的过程的信令图；

图7示出了媒体中继服务器的功能模块；

图8是示出了用于创建活跃的媒体会话的过程的信令的信令图；

图9A示出了临时分配请求的可能的格式；

图9B示出了用于承载媒体流的媒体数据的MTURN分组的可能的格式；

图10图示了经由NAT的端点与媒体中继服务器之间的交互；

图11A-图11C示出了在媒体会话的各种阶段如何填充数据库中的媒体会话数据块；

图12A和图12B示出了可以通过其改变现有媒体会话的所有权的机制；

图13A示出了具有附加的新属性的STUN消息；

图13B示出了现有媒体会话如何可以被转移到新媒体中继服务器；

图14示出了用于即时提议/应答机制的信令流；

图15A-图15B示出了在图14的即时提议/应答信令期间在端点和服务器之间发生的交互；

图16示出了在初始即时提议/应答交换之后在连接检查期间执行的信令流，通过该信令流可以授予用于在端点之间的直接消息传送的NAT权限。相似的附图标记表示附图中相对应的特征。

具体实施方式

如在本文的发明内容部分中所指出的，在建立第一端点和第二端点之间的媒体会话时，第一端点并行地发送了两个消息：到第二端点的消息，其向第二端点标识可以代表第一端点接收包括媒体数据(音频和/或视频数据)的媒体分组的媒体中继服务器；以及到媒体中继服务器的激活请求，用于激活会话标识符。

“并行”表示到第二端点的消息是与激活请求基本同时被发送的，在第一端点处从媒体中继服务器接收到针对激活请求的任何响应之前，并因此与接收的响应无关。换言之，针对激活请求的响应是在到第二端点的消息已被发送之后在第一端点处从媒体中继服务器接收的。因此，向第二端点发送消息的时间与激活请求被发送的时间之间的时间间隔(图14中的ΔT1)可以小于在第一端点和媒体中继服务器之间的一个往返时间(例如图14中的RTT)。往返时间表示可以完成在第一端点和媒体中继服务器之间的单个请求-响应交换的最小时间(其可以例如是秒、数百毫秒、数十毫秒或毫秒级的)。

发送到第二端点的消息和激活请求独立于彼此的结果而被发送。即，到第二端点的消息的传输与对激活请求的传输的结果无关，且反之亦然，例如，激活请求由于某种原因可能会失败，但是在这一点上消息已经被发送。在这种情况下，失败的激活可能导致呼叫建立失败。然而，通过适当管理媒体中继服务器上的会话标识符(例如，确保它们没有过早到期)，可以使失败的激活的可能性最小化。

在消息被发送时，在到第二端点的消息中的唯一的会话标识符(ID)尚未被激活，即，在消息被发送时，在媒体中继服务器处会话ID尚未与这样的网络地址相关联：服务器可以将接收的媒体数据中继到该网络地址以用于由第一端点来接收。会话标识符仅通过激活请求与消息本身并行地被激活，即与服务器处的这样的网络地址相关联。在媒体中继服务器处与会话标识符相关联以激活该会话标识符的网络地址是由服务器根据激活消息本身来确定的，即其是由激活消息本身运送的源地址。

由于会话ID是与消息的发送并行地被激活的，所以消息可以在需要时立即被发送。这与在发送消息之前激活会话ID形成对比，其在消息可以被发送之前会需要在第一端点和服务器之间的初始消息传送的至少一个往返行程。

在所描述的实施例中，消息是“即时提议”或“即时应答”。即，提议消息，其中直接响应于在第一端点处(例如，从第一端点的用户)接收的会话发起输入而发送提议消息和激活请求；或应答消息，其中直接响应于在第一端点处从第二端点接收的提议消息而发送应答消息和激活请求。

在该上下文中，“直接”表示仅使用在接收到输入或邀请时在第一端点处已经可用的信息或者在接收到指令或邀请时在第一端点处本地(不与媒体中继服务器进行通信)可以获得的信息来生成候选标识消息。即，使得在接收到输入/提议的时间与运输到第二端点的提议/应答的时间之间，在第一端点与服务器之间不发生往返行程消息传送交换。因此，在接收用户输入/提议与发送提议/应答的时间之间的时间(图14中的ΔT2)也可以小于第一端点与服务器之间的一个往返时间RTT。这减少了建立媒体会话所花费的时间，即接收邀请或提议与在第一端点处开始从第二端点接收媒体会话的媒体数据分组的时间之间的时间。

消息(提议/应答)通过SDP(例如，经由合适的代理服务器或被配备用于管理呼叫建立的信令阶段的其他代理实体)被发送。

这与基于当前ICE协议的现有系统形成对比，其中在接收这样的用户输入或邀请时，第一端点在TURN/STUN服务器可以将提议或应答分别发送到第二端点之前必须首先与可用的TURN/STUN服务器进行通信，以便获得必要的中继的和/或服务器反射网络候选地址(参见下文)，并且因此不能够直接对用户输入或提议进行响应。即，其中在接收用户输入或提议消息与分别发送提议消息或应答消息之间，需要在第一端点与中继服务器之间的至少一个往返行程。特别地，在这样的系统中，对于第一端点来说在没有首先与TURN服务器进行通信的情况下发送提议或应答将是不可行的，因为根据ICE协议，这将要求第一端点被预先分配有TURN服务器上的唯一端口。如下面进一步详细解释的，端口是有限资源，并且因此在至少一些实现中，预先分配它们是不可行的。相反，本发明使用会话标识符，这样可以具有大得多的地址空间，如果需要则允许多个媒体流在相同的端口上被多路复用(参见下文)。

此外，并行激活(与预先激活会话ID相反)确保当在消息被发送时在媒体中继服务器处与会话ID相关联的网络地址是有效的，同时使保持网络地址有效所需的消息传送开销最小化，从而节省带宽。这种影响在带宽受限的网络(例如移动网络)中尤为严重。

特别地，如果第一端点位于网络地址转换器(NAT)的后面，则由媒体中继服务器看到的并因此与会话ID相关联的源地址将是对第一端点本身不直接可见的NAT的公共地址，但是在NAT处其被映射到第一端点的私有本地地址并因此对服务器是可见的。在实践中，NAT仅在不活跃的有限持续时间内维持该映射：如果在某一持续时间内没有数据被发送到该公共网络地址或从该公共网络地址被接收，则在NAT处的映射到期(即超时)，使得不能再经由该公共地址到达第一端点。这个持续时间可以如分钟一样短，在某些情况下甚至更短。一旦会话ID被激活，即在服务器处与该公共地址相关联，映射需要保持活动的。这表示在需要的情况下“人为地”保持它是活动的，即通过周期性地经由将防止映射超时所需的那么多的刷新消息发送到/从这个地址。由于会话ID仅在到第二端点的消息被发送时被激活，因此用于映射的需要被人为维持的时间被最小化，并且在某些情况下，完全消除了对刷新消息传送的需要(注意，如果以及当中继服务器开始根据其与会话ID的关联将媒体数据分组转发到公共地址时，由于媒体分组本身将保持映射活动，所以不再需要刷新消息)。

在实施例中，激活请求的源地址可以是当由第一端点发送时的第一端点的本地网络地址。然而，激活请求可以经由第一端点所连接到的第一网络地址转换器来发送，其生成了在第一网络地址转换器的公共网络地址与本地网络地址之间的映射，并且将激活请求的源地址改变为公共网络地址的，使得会话标识符一旦被激活就在媒体中继服务器处与公共网络地址相关联。这继而表示媒体中继服务器将接收的媒体分组中继到网络转换器的地址，根据该地址网络地址转换器将会将它们路由到第一端点。

在所描述的实施例中，没有“服务器反射”候选被包括在消息中(即，在即时提议或即时应答中)。即，发送到第二端点的消息不指示第一端点所连接到的第一网络地址转换器的任何公共网络地址。这确保了(i)当接收消息时不会由发现这样的公共地址而引起延迟(例如根据STUN协议，这将需要在第一端点与NAT的公共侧上的实体(例如媒体中继服务器)之间的消息传送的至少一个往返行程)；以及(ii)不需要或者需要最少的刷新消息来保持这种消息活动(包括在消息中的任何预先高速缓存的公共NAT地址将需要被保持为活动的以便可用)。相反，在下面描述的实施例中，在消息(例如，即时提议/应答)已经被发送之后，任何这样的公共NAT地址完全动态地被发现(即，排他地由端点本身发现)，作为媒体会话建立过程的一部分。以这种方式发现的公共NAT地址被称为“对等端反射”候选。

在所描述的实施例中，在端点之间根本没有通过SDP交换的反射候选，而是排他地被发现作为ICE连接检查的一部分。

实际上，在所描述的实施例中，尽管反射候选的聚集和检查可以是ICE规定的消息格式并且可以基于ICE的一般原则，但是其有意违反ICE RFC协议中制定的规则。特别是，在某些实施例中，至少第一端点执行针对主机-对等(host-peer)反射候选对的连接检查，即通过从第一端点向第二端点的动态发现的公共NAT地址发送探测消息，其具有作为其源地址的第一端点的本地(即主机)地址。这与在ICE RFC标准中制定的内容是相反的，ICE RFC标准指示不应该对这种类型的候选对执行连接检查。这种违反标准的检查提供了新的机制以用于在第一网络地址转换器上开放任何必要的权限，使得第二端点在其后可以直接与第一端点传送消息，其中第一端点位于第一网络地址转换器后面。下面将参考图16进一步详细地描述示例。

如“服务器反射”、“对等端反射”、“候选”以及“候选对”之类的术语在STUN/TURN/ICE协议的上下文中是众所周知的，并且在下面进行详细描述以供参考。相比之下，术语“MTURN”指代TURN协议的新颖的改编版以包含会话标识符，如下面进一步详细解释的。

即时提议/应答机制的更多细节将在朝向具体实施方式的结尾处给出。首先，提供了关于这个新颖的“MTURN”概念的附加的上下文。

在所描述的实施例中，唯一的会话标识符被用于提供端口多路复用，即，使多个媒体流能够同时经由媒体中继服务器的相同端口被中继到多个不同的网络端点，即，存在每端口同时具有多于一个接收端点。

媒体中继服务器(其例如可以是TURN服务器)用于在网络的端点之间实现通信事件(例如语音和/或视频呼叫)，其包括网络接口、计算机存储装置、资源分配模块以及中继模块。网络接口被分配有服务器网络地址(例如，IP地址)并且具有与由端口标识符(例如，16比特的端口编号)标识的服务器网络地址相关联的端口。

计算机存储装置保持与端口相关联的端口多路复用数据库。资源分配模块被配置为：从网络接收多个分配请求，每一个分配请求指示(例如，包括或以其他方式使得可用于媒体中继服务器)不同的端点网络地址，并且将与唯一的会话标识符(ID)(例如，具有64比特或更大的大小)相关联的每一个端点网络地址存储在数据库中。网络地址可以例如是网络端点(例如，用户设备)的网络接口本地的网络地址、网络端点所连接到的NAT的公共侧的网络地址、或者甚至是在已经分配资源以供网络端点使用(使得媒体经由多个中继服务器被中继)的另一媒体中继服务器上的网络地址等等。

媒体中继服务器的输入被配置为同时经由端口从网络接收多个媒体流，每一个流被引导到服务器网络地址并且指示(例如，包括或以其他方式使得可用于媒体中继服务器)端口标识符和分离的目标会话标识符(即与端口标识符分离的)。

中继模块被配置为针对每一个流：确定数据库中的与由该流所指示的目标会话标识符相关联的端点网络地址，并且将该流发送到该端点网络地址。以这种方式，多个媒体流同时经由相同的端口被中继到不同的网络端点。

如所述的，尽管不是全部，一些实施例实现在本文中被称为“多路复用TURN”(MTURN)的内容，MTURN指代包含本公开内容的多路复用的TURN协议的修改版本。在这种上下文下，会话标识符有时被称为“MTURN标识符”。

端口是上述类型的软件实体，并且为了消除歧义有时在本文中被称为“物理端口”，与可以被认为是“虚拟端口”标识符的会话标识符形成对比，多个虚拟端口由单个物理端口来提供。

这与例如现有的TURN服务器形成对比，现有的TURN服务器将单独的端口分配给每一个网络端点，即，使得给定端口一次将媒体流仅中继到单个网络端点。

如鉴于以下内容将变得显而易见，在各种实施例中，唯一的会话标识符可以：

1)加速TURN候选的聚集；

2)随着移除对物理端口的依赖，移除TURN的可缩放性限制；

3)实现来自对等端的分组流而不需要明确的消息来实现许可；

4)实现漫游/移动性场景，而不会对现有媒体会话造成显著影响；

5)作为用于实现高可用性和灾难恢复(HA/DR)场景的构建块；

6)针对其中ICE连接检查可能不可行的受限网络提供连接路径。

在TCP/IP的上下文中，针对现有的TURN服务器，其如所指示的那样将单独的端口分配给每一个请求网络端点，可以由TURN服务器服务的网络端点的数量被限于65535(≈64k)每中继服务器IP地址。就限制而言，这与某些限制相比较不严格，并且针对现有的TURN服务器部署，其他因素用于早在达到64k限制之前约束可以由TURN服务器同时服务的用户的数量。这是因为，在现有的TURN部署(例如当前支持Microsoft(R)Lync(R)系统的各种TURN服务器)中被分配的端口具有高带宽要求。因此，早在TURN服务器用尽端口之前，带宽可用性用作将可以由TURN服务器服务的用户数量约束在远远低于64k。

然而，在开发新颖的部署时，发明人已经认识到以下的情境：在其中，与常规观点形成对比，64k端口限制将预期成为跟随现有的TURN方法的限制因素。

例如，发明人已经开发的一种新颖的用例是使用媒体中继服务器向客户端提供备份媒体路径。即，发明人已经认识到，在媒体中继服务器上的资源可能可用于客户端，每一个客户端被配置为仅在通过网络用于媒体会话的主要的即“首选”路线(一个或多个)失败的情况下使用该资源。由于客户端是以这种方式进行配置的，因此可以安全地假设，在任何时候TURN服务器资源理论上已分配到的不多于特定分数的客户端将实际地使用这些资源，这是因为它们仅用作备份。因此，可以将资源分配给大量的客户端，使得如果这些客户端中的所有客户端都试图立即使用它们来经由TURN服务器建立媒体会话，则TURN服务器的可用带宽会溢出，基于以下安全的假设：至少有一些(也可能是很多的)不会这样做，这是因为他们能够经由他们的优选路线(中的一个)来建立媒体会话。

在其中使用ICE协议建立呼叫的实施例中，这可以例如通过添加新的多路复用中继候选来实现，多路复用中继候选包括服务器IP和地址、端口编号以及分离的会话标识符，并且分配给这个新型候选低于其他候选的优先级，使得其他候选在可能的情况下受到青睐。

发明人已经认识到，在其中使用优选路径成功的概率高的情况下，经由媒体中继服务器将备份路径分配给(可能显著地)多于64k用户是可行的(尽管通过使用针对媒体流分配的路径实际上仅有少量将消耗可用带宽)。以上述方式在单个端口上的多路复用媒体会话(即，使得多个网络端点同时共享单个端口)确保64k限制不限制在服务器上可以分配备份资源的程度。例如，在一些情况下，单个端口可以同时在数据库中同时与数十、数百、数千、数万甚至数十万的用户相关联(尽管这些用户中只有少数可以实际上正在使用他们的分配)。

在一些实施例中，只有中继服务器上的单个端口可以用于媒体中继，即，使得经由该服务器中继的所有媒体流都经由单个端口被中继。在其他实施例中，单个相应的端口可以用于每一个媒体模态-例如，第一端口用于音频、第二单个端口用于视频。即，被引导到服务器网络地址的所有音频流可以经由多个端口中的第一端口来中继，并且被引导到服务器网络地址的所有视频流都可以经由多个端口中的第二端口来中继。因此，经由该服务器中继的所有音频(相应的视频)都经由第一(相应的第二)端口重放。在任一种情况下，媒体流可以同时经由相同的端口被中继到潜在的大量网络端点，例如至少10、100、1000或甚至10000个不同的网络端点。如果需要，还可以提供第三单个端口以用于中继任何其他类型的数据。

在各种实施例中，与现有的TURN服务器相比，本公开的端口多路复用还使呼叫建立时间能够减少，原因如下。

为了在现有TURN服务器上分配资源，端口必须单独地被分配给请求客户端，如所讨论的。由于64k端口的限制，端口是充分的有限资源(即端口是足够有价值的)，其在没有首先认证请求客户端的情况下不能安全地被分配到请求客户端。例如，通过在客户端和服务器之间的证书的交换来进行认证，并且总是需要经由网络进行若干个请求-响应消息交换。由于直到客户有其单独的端口分配呼叫建立才能进行，因此这些潜在的长度交换可以显著地延迟呼叫建立。

这可以通过使用具有比端口编号的比特长度(显著地)更长的比特长度的会话标识符来避免-例如，可以使用64比特或GUID(“全局唯一标识符”，通常具有≥128比特的大小)会话标识符，尽管在一些情况下取决于例如用户基数的大小较少的标识符可以是足够的。长的会话标识符可以安全地被分配给请求客户端，而不需要首先认证请求客户端。因此，分配可以采用不超过单个请求-响应交换，在那之后可以进行呼叫建立而不需要进一步延迟。然后，认证可以与呼叫建立并行地进行，而不需要进一步延迟它(当然除非认证失败)。例如，呼叫建立可以通过客户端发送包括会话标识符的ICE“初始提议”(呼叫方客户端)或ICE“应答”(被呼叫方客户端)来进行。

即使认证确实揭示了请求客户端已经请求了用于恶意结束的会话标识符，但是在发布会话标识符的该时刻这不是问题：会话标识符以如下方式是没有价值的：端口和会话标识符在认证成功完成之前实际上并不可用，因此在认证之前发布会话标识符不会带来附加的风险。因此，使用会话标识符可以减少呼叫建立时间而不会以任何方式来危害安全性。

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

公共网络2是公共的基于分组的互联网(即，互连的单独的网络的系统)(例如互联网)其具有公共地址空间。公共网络2包括多个路由器3，其在公共互联网2的不同的单独的网络(未示出)之间路由业务。

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

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

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

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、服务器12、14a、14b以及路由器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也运行客户端软件7'a、7'b的相应的实例以达到类似的效果。客户端可以例如是在相关用户设备的处理器上执行的独立应用，或者是在处理器上执行的另一应用的插件，例如Web浏览器。

可替代地或附加地，用户设备可以通过不涉及任何NAT的一些其他机制连接到公共网络2，尽管这在图2中未示出。例如，用户设备可以经由Wi-Fi连接被连接到私有网络，并且经由移动网络被连接到公共网络，而不涉及NAT。

图1A示出了用于呼叫信令(不是媒体流)的示例性信令路径(表示为虚线)。信令是经由SIP代理15在用户设备6a、6b之间的，并且表示SIP请求-SIP响应消息的交换，其导致呼叫或者其他通信事件被建立、终止、修改等。一旦建立了，呼叫的媒体流可以例如经由一个或多个媒体中继服务器14在用户设备6a、6b之间流送，或者“直接”经由不涉及任何应用层中介(即，只有较低层中介例如路由器3和NAT 8)的网络2的路径流送。

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

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

图3是媒体中继服务器14的示意性框图。中继服务器14包括处理器32，处理器32连接了存储器30和网络接口34，网络接口34使中继服务器12能够连接到网络1。存储器30保持控制软件13，其当在处理器32上被执行时使得中继服务器14实现控制软件13的功能。虽然被描绘为单个设备，但是中继服务器12的功能可以被分布跨多个设备，例如，在数据中心中的多个服务器设备。

网络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提供路由，即在互联网1的不同的单独的网络之间的通信，例如，经由在互联网层工作的路由器3/NAT 8，后者提供在互联网层和传输层处的网络地址信息的转换(网络地址转换)。链路层102提供经由在链路层102处工作的网络交换机和/或集线器等在相同的单独的网络互联网1中的相邻节点的物理网络地址(例如，MAC(“媒体访问控制”)地址)之间的通信。

将通过网络1发送的应用层数据17(应用数据，例如用户数据)在发送主机处从应用层108被传递到传输层106，在传输层106处将其根据传输层协议(例如，UDP(“用户数据报协议”)或TCP(“传输控制协议”))分组成传输层分组。TCP是“可靠的”流递送服务，因为它涉及确认/重传机制，而UDP是“不可靠的”流传送服务，因为它不涉及任何这样的机制。不可靠的服务的分组被称为数据报。然后，传输层分组(例如，TCP分组/UDP数据报)的数据被传送到该主机处的互联网层104，在那里该数据根据互联网协议(其是互联网层协议)被进一步分组成IP数据报。然后，IP数据报的数据被传送给链路层102，以用于通过网络1发送给接收主机。当在接收主机处被接收时，IP数据报的数据被向上传送到互联网层104，在互联网层104从IP数据报的有效负载中提取传输层分组的数据并将其向上传送到传输层106，在传输层106从传输层分组的有效负载中提取应用数据并将其向上传递到应用层。图4中示出了传输层分组(例如，TCP分组或UDP数据报)10。传输层分组106包括传输层报头(例如，UDP/TCP报头)10i，其在发送主机的传输层106处被生成并附接，以及传输层有效负载(例如，UDP/TCP有效负载)10ii，其对从应用层108接收的应用数据进行编码。

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

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

如所指示的，这样的私有地址空间在该私有网络之外是不可用的。因此，存在用于在私有网络(例如5a/5b)与公共网络(例如2)之间转发IP数据报的简单的路由器，该私有网络之外的节点将不能响应于这样的数据报，因为他们不具有IP报头中的任何可用的源地址。

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

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

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

NAT 8维持初始传输地址与新的传输地址之间的映射9，使得其可以将已经经由公共网络2被引导到新的传输地址的任何返回业务(并且因此其将在NAT 8结束)经由私有网络5转发到用户设备6的初始传输地址。在最简单的示例中，NAT简单地用其自己的公共IP网络地址代替私有IP地址，并且不改变该端口。然而，NAT实现地址空间伪装变得越来越普遍，由此私有地址空间被隐藏在单个网络地址的后面。为了防止返回分组中的歧义，NAT通常必须改变其他信息，例如与源地址相关联的端口。例如，NAT可以具有单个公共IP地址，并用其本身的单个公共IP地址和唯一的(并且可能不同的)端口来替代私有地址空间中的每一个传输地址，使得在私有网络的私有网络节点之外仅通过与该单个公共IP地址相关联的端口而彼此进行区分。

这对于简单地将响应引导到IP报头中的源地址的协议(例如，HTTP)通常是可接受的。

然而，包括一些媒体会话信令协议(例如SIP)的其他协议也依赖于被编码在应用数据17本身中的端点的地址。例如，SIP协议规定端点应当使用包含在SIP邀请/SIP响应中的地址来建立媒体会话，其将在应用数据级别被编码。如图5所示，这不会被NAT 8修改。

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

为此，已经开发了协议(例如，STUN(“用于NAT的会话遍历实用程序”)和TURN(“使用中继NAT的遍历”))以使SIP会话等能够在由一个或多个NAT分离的端点之间被建立。

STUN允许端点来确定其是否位于NAT后面，并且如果是的话，则NAT的公共地址被映射到发起端点的私有地址(即，有效地赋予其对映射9的访问权)，使得端点可以包含IP有效负载中的该公共地址而不是其自己的私有地址。通常，STUN通过发起端点向STUN服务器发送通过NAT并且经由公共网络作为IP数据报被中继到STUN服务器的查询来工作。由于NAT用在NAT的公共侧上的相对应的公共地址来替换查询的IP报头中的私有地址，所以STUN服务器可以从查询的IP报头获得后者，其继而可以提供给发起端点。然后，发起端点可以使用该公共地址而不是其自己的私有地址来建立会话，由此在会话请求中将在IP有效负载级的可用地址运送给响应端点。响应端点可以类似地发现在响应中在应用数据级可以运送到发起端点的其相关联的公共地址而不是其自己的私有地址。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中继至少在媒体会话期间需要被分配到该(那些)服务器上的资源(包括被分配在TURN服务器上的唯一的公共传输地址)，并且TURN中继还表示媒体会话的媒体经由比在媒体会话在端点之间直接建立或经由一个或多个NAT被建立时较不直接的路径来传播。虽然它确实需要附加的资源，但是TURN中继可以更多或更少地保证针对媒体会话提供通过网络的可用路径。

STUN和TURN功能可以被并入在相同的服务器中，其有时也简单地被称为TURN/STUN服务器，或者简单地称为TURN服务器，即使它也包括STUN功能。

图1的媒体服务器14是TURN服务器，其至少包含TURN功能并因此具有地址查找和媒体中继功能。可替换地，这个和/或其他功能可以被分解在分离的服务器之间，或者由以下描述的媒体服务器14a、14b执行的功能可以由相同的服务器来执行。

ICE(“交互式连接建立”)是用于建立遍历网络地址NAT和防火墙的VOIP会话的连接的已知协议，其尝试依据媒体延迟来建立最有效的路径以确保理想的媒体质量。ICE协议的细节可以在公开可用的RFC 5245，交互式连接建立(ICE)：AProtocol for NetworkAddress Translator(NAT)Traversal for Offer/Answer Protocols,J.Rosenberg(4月2010)中找到。ICE协议的某些扩展在[MS-ICE2]交互式连接建立(ICE)扩展文档中被定义(http://msdn.microsoft.com/en-us/library/office/cc431504(v＝office.12).aspx)

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

ICE协议试图基于静态优先级来识别被认为是最有效的路径，静态优先级被分配给可以用于媒体会话的多个所谓的“候选对”中的每一个。候选是与发起端点或响应端点相关联的传输地址。候选对是一对候选(i，r)，第一个(i)与发起端点相关联，第二个(r)与响应端点相关联。术语“候选”涉及这样的事实：ICE机制最初假设与端点相关联的任何传输地址可以用于媒体会话(虽然由于以上讨论的原因实际上可能不可用)-然后，ICE协议涉及检测识别候选中的哪一个实际上是可用的。ICE将候选分为3类：主机候选、反射候选以及中继的候选。

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

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

潜在地，发起端点的候选传输地址中的任何一个都可以被用于与响应端点的候选传输地址中的任何一个进行通信。即，第一用户设备6a可以潜在地将数据从其自己的相关联的地址中的任何一个引导到与第二用户设备相关联的地址中的任何一个，反之亦然。

然而，实际上，一些候选对将是无效的(即，将不起作用)。例如，如果端点都在NAT后面，并且它们的主机候选是私有网络5a/5b中的私有地址，则出于上述原因，它们可能不能够直接使用那些地址来进行通信。然而，如果其主机候选是公共地址，则其在被使用时不涉及通过任何NAT路由数据，则候选对(40a、40b)可以是有效的。类似地，取决于NAT的类型(例如，如果它是对称NAT)，反射候选的使用如所讨论的那样是不可能的。

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

其中尝试候选对的顺序由ICE静态优先级方案来规定，较高优先级对在较低优先级对之前被尝试。根据ICE协议，可以根据等式1为每一个候选(例如40a-44b)分配静态优先级：

优先级＝(2

类型偏好是从0到126(包括0和126)的整数，并且表示对候选类型(本地、服务器反射、对等端反射和中继的)的偏好。126是最高偏好，并且0是最低的。将该值设置为0表示这种类型的候选只能用作最后的手段。类型偏好针对相同类型的所有候选是相同的，并且针对不同类型的候选是不同的。对等端反射候选的类型偏好高于服务器反射候选的。ICE协议建议主机候选的值为126(除非这些是来自虚拟私有网络接口，其中建议情况0)、服务器反射候选为100、对等端反射候选为110、以及中继的候选为0。本地偏好是从0到65535(包括0和65535)的整数，并且表示针对特定IP地址的偏好，根据该特定IP地址在端点是多宿主的(multihome)(连接到不止一个计算机网络)时获得候选。当只有单个IP地址时，ICE建议将其设置为最大值65535，在没有多宿主时有效地使这个项变为冗余的。组件ID项是候选的标识符。可以看出，到目前为止，方程1中最重要的项是基于候选类型的第一项。因此，ICE优先级方案经由中继的候选来对间接的路径去优先级，这只是作为最后的手段使用，并且另外将静态优先级偏离反射候选。一旦根据等式(1)形成了候选对并且分配了优先级，则可以根据等式2来计算针对每一个候选对的候选对静态优先级：

对优先级＝2

总而言之，ICE可以用于在被呼叫方端点和呼叫方端点之间建立媒体流。在典型的部署中，在两个端点之间可以存在网络地址转换(NAT)设备或防火墙。部署NAT和防火墙以提供私有地址空间并保护端点所属的私有网络。如果端点通知其本地接口地址，则远程端点可能不能够到达该端点。此外，NAT和防火墙在他们创建NAT映射的地址方式中表现出不同的行为。ICE提供了通用机制来帮助媒体遍历NAT和防火墙，而不需要端点知道他们的网络拓扑。ICE通过以下方式来帮助媒体遍历NAT和防火墙：聚集两个端点可以潜在地用于通信的一个或多个传输地址，并且然后确定哪个传输地址针对两个端点是最适用于建立媒体会话的。

图1A示出了具有建立媒体会话的两个端点的典型部署场景。

图6示出了概述了使用ICE在两个端点(呼叫方6a和被呼叫方6b)之间建立会话所涉及的各个阶段的顺序图。这些阶段是：

1.候选聚集以及在呼叫方和被呼叫方端点之间的聚集的传输地址的交换(P1)；

2.连接检查(P2)；

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

在候选聚集阶段P1期间，端点聚集用于连接的潜在的候选。这包括主机候选(绑定到本地接口)、服务器反射候选(使用TURN服务器发现的NAT映射)以及中继候选(被分配在TURN又名媒体中继服务器上的转发端口)。由被呼叫方6a聚集的候选经由网络2以提议消息的形式被发送给呼叫方6b。该提议可以被编码为SDP提议并且通过信令协议(例如SIP)进行交换。呼叫方端点6a充当控制代理并负责选择用于媒体流的最终候选。被呼叫方6b在接收到提议后，按照相同的过程来聚集其候选。它聚集的候选被编码并经由网络2以应答消息的形式被发送给呼叫方。在候选交换完成的情况下，现在每一个端点6a、6b知道其对等端(即其他端点的)的候选。

在连接检查阶段P2期间，两个端点将本地候选和远程候选进行配对以形成基于候选对的优先级进行排序的候选对的检查列表，并且使用STUN绑定请求响应交换来系统地执行连接检查。如果所有其他类型的路径都失败了，则此顺序可确保TURN中继仅用作最后的手段。在连接检查结束时，呼叫方6a指定(P3)用于媒体流的最佳候选对，并且丢弃所有其他候选。

由ICE使用的使用中继NAT遍历(TURN)协议使位于一个或多个网络地址转换(NAT)后面的私有网络上的TURN客户端能够从位于互联网上的TURN服务器中分配传输地址。这个被分配的传输地址可以用于从对等端接收数据。TURN协议还使客户端能够发现其外部NAT映射。

在图6B中示出了由TURN协议支持的典型部署，其中协议客户端在NAT后面并且正在与互联网上的对等端进行通信。

在图6C中示出了根据现有协议的在协议客户端与TURN服务器之间的典型的TURN消息的基本流程。

当协议客户端7a需要公共地址来发送数据到对等端或从对等端接收数据时，其将分配请求消息Req l发送到TURN服务器14。该请求由TURN服务器通过摘要挑战机制来认证。一旦TURN服务器认证了分配请求，则它就以分配响应消息Resp l的形式向协议客户端返回分配的地址。

此时，分配的地址已被协议客户端保留。直到协议客户端7a尝试通过将数据封装在发送请求消息中以用于将数据发送到对等端7b，分配的地址才能用于从对等端接收数据。即，在这个阶段，客户端7a可以经由中继14将数据发送到对等端6b的唯一方法是以发送请求消息的形式。发送请求消息提供两个功能：

·TURN服务器将包含在发送请求消息中的数据D1中继到由发送请求消息的目的地属性标识的对等端6b；

·以如下方式在分配的地址上设置的权限：从对等端6b到达分配的地址的数据D2以数据指示消息的形式被中继到协议客户端7a。

如果协议客户端7a需要与不止一个对等端进行通信，则可以向每一个对等端发送发送请求消息。一旦针对对等端设置了权限，则从该对等端在分配的地址上接收的任何数据都将被中继回到被封装在数据指示消息中的协议客户端。该消息包括标识初始数据的对等端的远程地址属性。在这个阶段，数据指示消息是对等端6b可以将数据发送到客户端7a的唯一方式

如果协议客户端7a决定与优选的对等端进行通信，则其可以将设置活跃目的地请求消息Req2发送到TURN服务器14。TURN服务器14通过用设置活跃目的地响应消息Resp 2进行响应来确认协议客户端的请求。这允许协议客户端7a和TURN服务器14停止使用发送请求和数据指示消息来封装针对该对等端6b端对端流送的数据，因此使数据通信信道更有效。图6C中的D3和D4表示经由不具有这种封装的中继服务器14来进行中继

现有的TURN机制具有若干个缺点。例如：

1)聚集中继候选的过程涉及在端口可以被分配之前的消息(即请求-响应)交换的若干往返行程。这会影响呼叫建立时间。

2)TURN要求将服务器上的单独的物理端口分配给每一个请求客户端。这限制了服务器可以支持限制可缩放性的媒体会话的数量。

3)在可以从对等端IP地址接收分组之前，TURN需要明确的消息来开放针对对等端IP地址的权限。

4)分配的TURN会话的所有权不能被转移到现有会话，即所有者不能在会话期间进行改变；来自新对等端IP地址的分组也不可以被接收。这样可以防止交换媒体流流经本地接口或移动(Wi-Fi到3G切换)所需的新对等端地址或高可用性和灾难恢复方案。

5)使用ICE/TURN/STUN建立媒体会话可以是“啰嗦的”，并且针对具有极差网络条件的地区可能是不适用的。对于这样的情况，MTURN提供了用于媒体流的路径，而不需要若干轮连接检查交换。

本公开限定了机制和协议交换，除了别的以外，其解决了这些缺点并且可以充当用于实现移动性、在有限带宽、HA/DR场景下的呼叫建立的构建块。

图7示出了服务器14的框图。媒体中继服务器14包括网络接口14.网络接口具有被分配的服务器网络地址以及与服务器网络地址相关联的一个或多个物理端口50，服务器网络地址是服务器14的IP地址。物理端口50是在媒体中继服务器14的处理器32上执行的上述所讨论的类型的软件实体。作为示例示出了三个分离的物理端口50m、50n以及50l，尽管可以存在比在服务器上正在活跃使用的更少或更多的端口，最多达64k的限制。每一个端口由相应的端口标识符来标识，端口标识符是上述所讨论的类型的16比特端口编号#1、#m、#n的形式。

服务器14包括以下功能模块，每一个功能模块表示通过在处理器32上执行控制代码13的相应的部分而实现的相应的功能：包括重新分配模块52R的资源分配器52；媒体中继模块54；以及会话标识符分配器74；以及认证模块76，其被示为包括消息完整性验证模块76a。服务器14的存储器30被配置为实现端口多路复用数据库DB，可由资源分配器52和媒体中继模块54访问。

资源分配模块52可以访问数据库DB以对其进行更新，并且媒体中继模块54可以访问数据库DB以至少读取存储在其中的数据。数据库DB保持由资源分配模块创建和维持的多个会话数据块(会话)56a、56b、...。媒体中继模块在网络1的网络端点之间中继媒体流。从被保持在数据库DB中的会话56a、56b规定媒体中继模块应该如何中继经由端口50中的任何一个接收的媒体流以及特别是他们应该被中继到何处的意义上而言，数据库DB与端口50相关联。

资源分配器52与认证器76和完整性验证器78通信地耦合。资源分配器52和会话ID发生器74可以经由网络接口34(例如，经由端口50l、50m、50n中的一个、或经由网络接口34的不同端口)将数据发送到网络2或从网络2接收数据。在一些情况下，会话56a、56b的创建以及后续处理至少在某种程度上以认证器76的操作并且特别是完整性验证器76a的那些操作为条件。

现有的实现方式。

ICE：

聚集中继候选中的延迟：

在候选聚集阶段期间，ICE尝试聚集每一个可能的候选。这包括TURN TCP、TURNUDP、服务器反射候选和主机候选。主机候选可以几乎即时被聚集，但是聚集中继候选可能需要花费时间，特别是在网络条件差的情况下。中继候选的聚集分两个阶段来进行：

1.联系阶段-将探查多个服务器(如果被配置)以找到可以达到的服务器。

2.分配阶段-从在先前阶段到达的第一个服务器中聚集中继候选。

在一些现有的实现方式中，联系阶段可以具有最坏情况的超时(t1秒)。即，如果没有一个服务器是能够到达的，则提议将在t1秒内就绪但没有中继候选。只有在联系阶段成功到达中继服务器的情况下，分配阶段才能进行。分配阶段还可以具有一个最坏情况的超时(t2秒)。包括两个阶段，绝对最差的情况是用于提议就绪的时间为tl+t2秒。

静态连接方案：

在连接检查结束时，丢弃除最终候选之外的所有候选。在主路径出现故障的情况下，现有实现方式不维持备用路径以进行后退。现有的实现方式还不会动态地发现新的候选并将它们添加到连接矩阵中。这主要是由于需要信令支持来交换到对等端的新的候选，因为TURN服务器不会转发来自未知目的地的分组。在媒体会话期间主路径中的失败导致呼叫被丢弃，而没有直接内置到传输层的恢复机制。

不一致的NAT映射：

ICE状态机由于其试图评估多个路径并在运行中发现新的映射而本质上是复杂的。NAT和软件有效负载平衡器可以错误地运转将ICE状态机置于不一致的状态，导致两个端点不能收敛到正确的媒体路径。通过在相同的端口上实现RTP/RTCP的多路复用，这个问题已经得到了很大的缓解。

信号依赖：

当前的ICE实现方式依赖于用于不仅发起候选交换而且还用于确认最终候选的信令。这通过增加跨越团队边界的依赖来将脆弱性构建到系统中。传输层应该能够在运行时独立地对媒体路径进行改变，而不需要信令尽可能大的支持。

TURN:

物理端口限制：

TURN服务器当前需要被分配以用于每一个TURN分配的物理端口。这限制了由TURN服务器可以支持的TURN会话的数量。这使得客户预先分配或维持存在已久的TURN分配作为备份路径成本过高。此外，在媒体中继上分配物理端口会创建配置负担以维持并确保ACL(访问控制列表)和防火墙策略被建立以允许数据中心内部/外部的宽泛的端口范围内的业务。

权限建立：

TURN服务器将仅从已经使用发送请求针对其明确建立了权限的地址转发来自分配的端口的分组。这需要在中继的候选可以被使用之前依赖于独立的信道来将远程IP地址用信号传送到对等端以建立权限。

协议指定分配：

客户端必须分别通过UDP到达中继以分配UDP候选，并且类似地，通过TCP到达中继以分配TCP中继候选。这增加了用于聚集中继候选的时间，特别是在网络条件差的情况下。例如，在Windows平台上，例如，如果TCP SYN分组丢失了，则TCP SYN将仅在三秒之后重试。

TURN会话的所有权：

分配的TURN会话的所有权被绑定到根据其分配TURN会话的传输地址。目前不存在用于将现有TURN会话的所有权转移到不同的传输地址的机制。这限制了TURN可以提供无缝漫游和接口切换场景的程度。

新的MTURN实施方式：

与常规的TURN形成对比，在MTURN中，所有TURN会话都在一小组MTURN分配的端口上进行多路复用。

MTURN解决了上述现有TURN实现方式的限制，并提供了附加的功能以支持围绕呼叫建立时间、可靠性以及移动性的新兴要求。

MTURN还增加了针对中继服务器的选播部署的支持。用于TURN的相同的认证方案可以用于MTURN，并且在很大程度上在中继上分配MTURN候选的过程类似于分配TURN候选。用于MTURN的安全衍生物和缓解也将涵盖在内。选播是一对最近的(one-to-nearest)路由方法，由此将分组从路由节点路由到一组潜在接收者中的单个成员，这些潜在接收者都由相同的目标地址标识。单个成员是到路由节点的拓扑上最近的节点。

针对被配置为实现MTURN的媒体中继服务器14，分配过程如下：

1.当客户端请求MTURN分配时，客户端没有被分配有唯一的物理端口，而是被分配有唯一的MTURN会话标识符和在相同模态类型的TURN会话之间共享的分配的端口。MTURN会话标识符将充当预留令牌。例如，可以使用以下端口分配：

a.音频端口编号3479(M-TURN-AUDIO-PORT)，经由该端口音频流可以通过其对等端6b被中继到请求客户端；

b.视频端口编号3480(M-TURN-VIDEO-PORT)，经由该端口视频流可以通过其对等端6b被中继到请求客户端；

c.应用端口M-TURN-APP-PORT(3481)，经由该端口任何其他类型的数据可以通过其对等端6b被中继到请求客户端。例如，可以针对任何和所有其他模态(例如，通过语音、屏幕共享、文件共享、白板会话、即时消息传送等共享的)提供一个端口，或者可以针对每一个模态提供单独的端口。更一般地，可以以任何组合的方式在一个或多个其他媒体模态之间共享一个或多个附加的端口。

2.有权访问该会话标识符的任何对等端端点都可以将分组发送到MTURN会话的所有者，而不要求TURN会话的所有者明确地开放任何权限。

3.MTURN会话所有权至少最初与被分配给TURN会话的IP地址和端口(即，请求客户端的)相关联。本公开提供了一种将所分配的会话的所有权移交给客户端上的不同的本地IP地址和/或端口的方式。

端口分配方案使得应用模态特定服务质量(QoS)标记变得简单。

此外，分配的端口(例如3478、3480、3481)与控制端口(例如，3478)分离，即，在TURN服务器上提供分离的专用控制端口，用于控制媒体会话的控制信号可以被引导到该端口。使控制端口3478和分配的端口分离减小了客户端上的报头开销。

分配和使用MTURN候选：

参考图8，现在将描述当客户端被配置有用于音频模态的媒体中继服务器14的选播IP地址时分配和使用MTURN候选所涉及的示例性步骤。图8是用于MTURN候选分配过程的信令图。

步骤如下。

步骤1：呼叫方6a将针对MTURN候选的分配请求(第一/临时分配请求)57发送到媒体中继服务器的选播地址。存在于分配请求57中的服务质量属性由中继服务器14使用以识别模态类型。例如，服务质量属性可以指示呼叫方6a仅被允许针对音频(不是视频)到媒体中继服务器14。

步骤2：作为响应，媒体中继服务器14发送提供媒体中继服务器的直接IP地址的分配错误响应(401)57R(第一响应)，M-TURN-AUDIO-PORT的端口编号(在该示例中)以及作为唯一MTURN会话标识符S1的预留令牌在该示例中由会话ID分配器54生成。可替代地，可以从分配错误响应响应57R中省略端口编号，并且呼叫方6b可以被配置为使用默认的音频端口编号。呼叫方6a的反射传输地址也可以由客户以所描述的方式来确定并在响应57R中被返回。

步骤3a：此时，服务器14尚未创建TURN会话，但是客户端具有足够的信息来将包括MTURN候选的ICE提议70(即图6A中的“初始提议”)发送到对等端端点。MTURN候选包括直接媒体中继IP地址、M-TURN-AUDIO-PORT以及会话标识符S1。

步骤3b：与在步骤3b发送提议70并行地，呼叫方客户端7a通过将包括会话标识符的分配请求58(第二/非临时分配请求)发送到服务器14来激活与在步骤2中提供的会话标识符S1相关联的MTURN会话。步骤3b的分配请求58是消息完整性保护的。消息58的验证由服务器14的完整性验证器76a根据这个完整性保护来执行。提供的消息58被发现是有效的，即提供消息58的完整性是不被危害的，即提供消息58被确定为自从它被发送以来没有被改变，则服务器14的资源分配器52创建包括与呼叫方的传输地址X'相关联的在端口多路复用数据库DB中的会话标识符S1(见下文)的活跃的会话56作为响应，以及将对第二请求58的响应58R(第二响应)返回给呼叫方6a指示会话现在处于活跃状态。如果消息的完整性不能被验证，则请求58被拒绝。

如图10所示，传输地址X'是在呼叫方6a前面的NAT 8a的公共侧的传输地址，其在那里映射到私有网络5a中的呼叫方6a的本地传输地址X。其可以以所讨论的方式由服务器14来获得。

一旦已经创建了活跃的会话56，被呼叫方6b就可以开始通过用包括在提议中提供的会话标识符S1的薄MTURN报头来封装分组从而将到呼叫方端点的媒体分组60发送到提议70中的媒体中继14的IP地址。媒体中继服务器14的中继模块54读取瘦报头中的会话标识符S1，并且将分组60转发到与数据库DB中的会话标识符S1相关联的传输地址X'。

返回图7，示出了具有私有传输地址Xa、Xb的多个不同的呼叫方端点，其通过NAT被映射到公共地址Xa'、Xb'。会话ID分配器74被配置为接收用于不同呼叫方端点的多个临时请求57a、57b，并且被配置为响应于每一个请求而分配唯一的会话ID Sa1、Sb1。每次接收到包含相关会话标识符Sal、Sbl的后续非临时请求58a、58b时，资源分配模块创建相应的会话56a、56b，其在数据库DB中将该会话标识符与相关呼叫方端点的公共传输地址Xa'、Xb'相关联。此后，指定给不同呼叫方端点的分组60a、60b可以被引导到服务器14的相同端口(例如，#n)。媒体中继模块54在数据库DB中查找与该分组60a、60b的瘦MTURN报头中的会话标识符Sal、Sb1相关联的传输地址Xa'、Xb'，并将其中继到该传输地址Xa'、Xb'。一旦到达相关的NAT，分组就将从那里被路由到正确的呼叫方端点。

在端点不在NAT后面但是出于任何原因仍希望经由服务器14来中继的情况下，数据库DB中的关联将在会话标识符和呼叫方的本地传输地址之间(这种情况下其将是公共地址)。

通过以上所述的，生成提议60所需的时间仅仅是通过UDP从呼叫方6a到媒体中继服务器14的一个RTT(往返时间)，即仅有在呼叫方6a和中继14之间的一个请求-响应交换。一旦接收到提议60，对等端端点6b就可以开始使用MTURN会话标识符将媒体60发送到呼叫方6a，并且分组将被传送到在呼叫方端点6a上的客户端7a。呼叫方6a不需要为被呼叫方6b开放权限。

将请求(步骤1)与激活(步骤3)分离不是必需的，但是在某些实施例中出于以下原因而遵循这种分离。

首先，来自客户端7a的第一分配请求57不是消息完整性保护的；出于安全的原因，媒体中继14可以被配置为使得直到媒体中继14已经接收到完整性保护的消息(其是第二请求58)才创建任何状态或代表客户端7a加速资源。

这实现了在STUN短期证书机制(参见RFC5389“Session Traversal Utilitiesfor NAT(STUN)”；10.Authentication and Message-Integrity Mechanisms；http://tools.ietf.org/html/rfc5389#secti on-10)的框架内的操作。

短期证书机制假设在STUN事务之前，客户端6a和服务器8a已经使用了一些其他协议来交换以用户名和密码形式的时间受限的证书。该证书用于形成用于后续消息的消息完整性检查。在该框架内，会话标识符可以在证书交换已经发生之前并因此在设备6a已经被认证之前安全地被发布，而没有完整性保护减低呼叫建立时间的第一分配请求57。然而，直到发生了证书交换，会话标识符才能被使用，因为需要证书来保护第二请求58，这确保安全性不被危害。

这也是响应57R是错误响应(401)的原因-根据短期证书机制，错误响应被返回给未利用证书被完整性保护的任何请求。

注意：不排除完整性保护第一请求57的可能性，例如通过在可替代实现方式中的一些其他完整性保护机制。此外，短期证书机制只是本公开范围内的一种选择；例如，可以使用长期证书机制(http://tools.ietf.org/html/rfc5389#section-10.2)来代替，其基于本质上基于持久性的传统登录，而不是时间限制、用户名和密码。

其次，步骤3提供附加的安全层。即使对等端获得持有会话ID S1，其也只能在中继14上被用于其中该会话ID S1已被激活的窗口。

以另一种方式来看，步骤1和步骤3的分离表示会话标识符可以安全地被分发给任何请求客户端，而不需要首先认证该客户端。再加上会话标识符由于其比特长度较大(与常规TURN的上下文中的端口相比)是非常没有价值的资源这一事实，这使得媒体中继服务器在会话标识符被请求时可以不负责分发会话标识符，即直接响应于请求，这继而减少了呼叫建立时间，因为请求客户端7a可以马上发送提议70。换言之，其是i)使用会话标识符的端口多路复用和ii)将认证与发布会话标识符分离使得在单个请求-响应交换中直接提供会话标识符可行(即，直接响应于临时分配请求57)的组合，由此减小了呼叫建立时间，特别是在客户端7a、7b遵循ICE呼叫建立过程的情况下，因为MTURN候选可以更快地变得可用(比床柜的TURN候选可以更安全地变得可用)。

上面的流程示出了中继服务器14分配MTURN会话标识符S1。然而，功能上，会话标识符S1可以由客户端7a或服务器14来生成。

一方面，服务器侧生成使得标识符的大小(即比特长度)能够被减小，因为服务器14可以协调以避免在客户端生成更短的标识符时可能另外发生的冲突。

另一方面，由于客户端可以立即发送包含自生成的会话标识符的提议60，即不必首先从服务器14请求会话标识符，所以客户端侧生成使得呼叫建立时间能够进一步被减小。

利用这种方法，较长的会话标识符(例如，GUID)更适合于减小(在GUID的情况下，有效地消除)冲突的可能性。针对GUID，这会将MTURN标识符的大小增加到16个字节。

哪种方法最合适是取决于上下文的。

注意，以上通过举例考虑了将MTURN资源分配到呼叫方端点的情况。然而，这仅仅是一个示例–可替代地或附加地，可以以相同的方式将MTURN资源分配到被呼叫方端点。在ICE的上下文中，被呼叫方端点可以在阶段P1结束时在其“应答”中包括MTURN候选(参见图6A)。

针对基于ICE的实现方式，MTURN候选可以被视为其好像是常规TURN中继候选，经历附加会话标识符，连接检查(阶段P2)和最终选择(阶段P3)相应地进行。在这种情况下，包含MTURN候选(针对呼叫方、被呼叫方或两者)的候选对通常将仅被用作阶段P3中的最终候选对作为最后的手段，如果在阶段P2中连接检查针对所有其他候选对都失败了。这可以通过将相对于其他类型的候选合适的低优先级分配给多路复用的中继候选来实现。

消息格式和属性：

MTURN会话标识符属性：

图9A示出了由服务器14返回的第一响应57R的可能的格式。针对服务器侧会话ID生成，响应于来自客户端的分配请求56，第一响应57R中的会话标识符属性由媒体中继服务器14填充。填充的属性被包括在第一响应57R中。图9A中示出了示例性会话标识符属性72。

在该示例中，属性的长度是8个字节(64比特)，并且中继服务器14确保该标识符是随机生成的并且对于每个活跃的TURN会话56是唯一的。

MTURN-IDENTIFIER属性的值是从用户可定义的范围中挑选的，并将MTURN与其他协议区分离来。长度字段保持遵循属性长度字段本身的会话标识符的以字节为单位的长度。

MTURN报头：

图9B示出了要由服务器14中继的媒体数据分组60的可能的格式，该格式包括在该示例中为12字节的瘦MTUN报头60h，随后是包含要被中继的实际媒体数据的有效负载60p。这12字节的开销足够小以至于不会随着利用报头封装使分组大小增加而产生问题。

采用MTURN报头格式，其使相同的端口能够接收例如RTP、STUN或MTURN消息。通过检验报头60h的第一个字节的头两个比特来消除协议的歧义。例如：00＝>STUN，10＝>RTP，11＝>MTURN。

信道ID字段可以例如被设置为用于MTUN分组的预定值，例如，0xFF10，其中0x表示十六进制。

目的地字段保持作为目的地的MTURN分配的端口的64比特MTURN会话标识符S1。长度字段保持紧接在长度字段本身之后的帧的字节的数量。

分组60是应用层分组，即，报头60h和有效负载两者构成在发送时被包含在一个或多个较低层分组的有效负载中的应用数据。因此，与作为传输层标识符的端口标识符形成对比，会话标识符构成应用数据。更具体地，会话标识符构成在应用层由应用传输层协议使用的应用传输层参数(而使用端口编号的TCP/UDP是在应用程序传输层下面的网络传输层的较低层传输协议)。

MTURN会话：

当客户端7a发送由消息完整性保护的分配请求58以激活MTURN会话标识符S1时，在媒体中继服务器14上创建MTURN会话56。该部分继续由客户端将第二消息完整性保护的分配请求58发送到媒体中继以激活会话标识符S1。

现在将参考图10来描述示例性MTURN会话。客户端6a将具有MTURN会话标识符S1的分配请求58从10.21.21.42：4000(X)发送，NAT8a将其映射到65.35.52.12:5000(X')。该消息58是消息完整性保护的，并且用于激活会话标识符S1。TURN服务器最终将看到来源于X'的请求。为了简洁，假设对等端6b在95.12.32.43：3000(Y)上是在公共互联网2上可直接到达的，尽管如果对等端也在NAT后面，则Y可以被替换为NAT的公共侧的传输地址或者实际上是已经将资源分配给对等端6b的另一TURN服务器的传输地址(见下文)。

在接收请求时TURN服务器14将创建TURN会话56。TURN会话是数据库DB中的数据块，其包含用于维持和服务TURN会话的所有相关信息。图11A中示出了示例性MTUN会话，并且其被示出为包括MTURN会话标识符字段56(i)和MTURN会话所有者字段。还示出了活跃的目的地地址和活跃的MTURN会话标识符字段56(iii)、56(iv)，随后其目的将在下面进行描述。

MTURN会话标识符：该字段被填充有会话标识符S1。

MTURN所有者：该字段被设置为被分配有并拥有MTURN端口的传输地址X'(IP地址+端口)。这是发送参考标识符S1的分组60将被递送到的传输地址。

活跃的目的地地址：如果分配的端口的所有者发送设置活跃的目的地(“SAD”)请求以减少在MTURN所有者与TURN服务器之间的支路上的发送请求和数据指示开销，则该字段被填充。即，允许经由服务器14将数据从Y发送到客户端7a而不使用数据指示消息，并且使客户端7a能够经由服务器14将数据发送到Y而不使用发送请求消息(参见上文)。图11B示出了当MTURN所有者已经将活跃的目的地56(iii)设置为Y时的会话56。

活跃的MTURN会话标识符：如果对等端6b本身是MTURN候选，则SAD请求除了活跃的目的地地址Y之外还将提供第二MTURN会话标识符S2。这样做是为了减少客户端上的报头开销，使得媒体中继服务器可以一旦SAD完成则代表客户端添加MTURN报头。

考虑可替代的拓扑，其中媒体在两个媒体中继服务器(分别具有传输地址MR1和MR2)之间流送MTURN-MTURN，分别具有用于音频的MTURN标识符S1和S2。即，X<->MR1<->MR2<->Y。这与常规的TURN拓扑形成对比，其中媒体通常仅在每一个方向上最多流经一个服务器，即X->MR2->Y(MR2是Y的候选中的一个)并且X<-MR1-X(MR1是X的候选中的一个)。

对于SAD之后的这种情况，MR1上的TURN会话56将被填充，如图11C所示。特别是，活跃的MTURN会话标识符字段被填充有服务于对等端6b的其他媒体中继服务器上的会话的第二会话标识符S2。

在SAD事务之后如上所述建立TURN会话，中继服务器14可以接管添加MTURN报头，所以客户端将不再需要包括MTURN报头并避免MTURN报头开销。即，当媒体中继14接收来自X(不是Y)的流时，其将流修改为包括会话标识符S2(不是S1)，并将修改的流引导到MR2。由于S2已被包括在流中，所以这允许其他媒体中继服务器14'通过其自己的端口进行多路复用(图11C的示例中的3479)。

对于两个媒体中继之间的业务，这也开放了批量分组的可能性，并且如果数据中心支持甚至可能甚至是巨型分组。例如，如果媒体路径是MTURN-MTURN，则媒体路径包括两个TURN服务器之间的支路。TURN服务通常部署在具有高带宽和吞吐量的大型数据中心中。这就开放了在服务器之间涉及的发送/接收批量业务和巨型业务的可能性。

使用MTURN端口发送分组：

除了接收中继的分组之外，MTURN所有者X(即，6a)可使用由TURN发送分组所使用的标准发送请求机制使用分配的端口来将分组发送到Y(即6b)。服务器和客户端上的处理与常规TURN分组相同。

在SAD之后使用MTURN端口发送分组：

如果对等端Y是非MTURN候选，则可以在设置活跃的目的地之后在没有任何MTURN封装的情况下发送分组。在移除发送请求和数据指示报头后，这将继续工作。

然而，如果对等端也是MTURN候选，则SAD目的地请求还应该包括目的地MTURN候选的MTURN标识符，使得中继服务器可以在发送到远程中继服务器的分组上添加MTURN报头。

这种确定将由客户端进行，即客户端确定其对等端是否是MTURN候选。随着候选的提议应答交换，两个端点都将知道媒体流所使用的路径。

在MTURN分配的端口上接收分组：

当在来自对等端6b的MTURN分配的端口上接收分组时，中继服务器14可以使用作为MTURN报头60h的一部分的MTURN会话标识符S1来识别正确的MTURN会话56。如果找到有效的MTURN会话56，则有效负载60p被转发到MTURN会话56的MTURN所有者地址字段X'。如果不存在有效的TURN会话，则丢弃该分组。

分组60的处理在设置活跃的目的地之前和之后是相同的。会话总是使用MTURN报头60h中存在的会话标识符S1来标识。

对于上面的示例，如果对等端Y想要使用MTURN分配的端口来发送分组X，则Y将如下来发送其分组：

在SDP中对MTURN候选进行编码：

将引入新的候选类型mrelay以支持MTURN候选而不破坏向后兼容性：格式：a＝候选：1UDP MRIP地址MTURN端口typ mrelay ID MTURN会话标识符例如：a＝候选：1 UDP202.202.1.2 3479 typ mrelay 302452389 raddr 10.21.21.42 rport 4000

MTURN和ICE：

MTURN可以是或者用于独立于ICE的独立路径或者用于提供附加类型的ICE候选(类似于降级场景)。

ICE提供用于验证媒体路径的框架，并且MTURN是用于ICE状态机的另一潜在路径。针对ICE实现方式，多路复用的中继的候选(“MTURN候选”)可以是作为ICE连接建立的一部分被聚集和交换的候选中的一个。MTURN候选是由TURN服务器上的传输地址(IP地址+端口编号)和除端口编号以外的独立的唯一的会话标识符组成的。MTURN候选形成适用于连接检查的ICE候选对的一部分，并且其将被选择以用于媒体会话，假设i)在连接检查中确定没有更高优先级的候选对是有效的，并且ii)在连接检查中MTURN候选对本身被确定是有效的。MTURN候选对中的其他候选可以是主机候选、反射候选、常规中继的候选(即，TURN服务器上的传输地址没有会话标识符)或用于MTURN<->MTURN路径的另一MTURN候选(具有其自己的会话标识符)。MTURN候选可以被包括在多个候选对中，每一个候选对都适用于连接检查。注意，可以实现优化，由此实际上不针对用于媒体会话的候选来执行连接检查：例如，在候选对包括中继的(例如，多路复用的中继的)候选的情况下，由端点通过假设可以确定其是有效的(因为其很有可能是有效的)，而不需要检查该候选。在候选对中的两个候选都被中继的情况下，可以假设该对是有效的，并且根本不对该候选对进行连接检查。在那种情况下，如果在连接检查期间未发现较高优先级的候选对是有效的，则双中继的候选对可以用于媒体会话，而不执行对双中继的候选对的连接检查。

安全考虑：

只要对等端6b知道MTURN会话标识符S1，MTURN就允许分组通过中继服务器14进行中继。通过在≤64比特空间上随机生成会话标识符S1，并且会话标识符仅在媒体会话期间(即，媒体会话56为活跃期间)有效的，来减轻任何潜在的风险。

在实施例中，可以使用消息完整性保护的同意新鲜度检查(consent freshnesscheck)来提供另一层保护。未通过同意新鲜度检查的媒体会话将被取消。

呼叫建立可靠性和建立时间：

优化呼叫建立时间：

对于移动设备以及对于网络质量差的新兴市场，MTURN可以被用于显著减少呼叫建立时间并提高可靠性。这将非常接近即时连接建立。基于ECS配置，端点可以被配置为仅聚集和使用MTURN候选作为极限解决方案。即使MTURN候选仅被分配作为呼叫建立的一部分，聚集MTURN候选并使提议就绪的时间也只是一个UDP RTT。

不需要进一步的连接检查验证或探测以建立媒体路径。媒体可以在MTURN候选的初始提议/应答交换之后立即开始流送。随着中继服务器和MDN(消息布置通知)的选播部署，可以安全地采用可靠的媒体中继部署。

如果可以由客户端预先分配和/或生成MTURN候选，则可以进一步减少呼叫建立时间。这实现了非常有用的接近即时的连接，例如，从蜂窝到VOIP的呼叫升级场景。

注意：如果客户端在UDP阻断后面，则MTURN候选仍然可以通过TCP进行分配。这将花费比一个RTT更长的时间以用于UDP。可以通过并行地尝试UDP和TCP来减小延迟，以及如果客户端可以成功地通过UDP到达中继那么丢弃TCP来减小延迟，以使得无论如何都不会引发不必要的延迟。

在这方面，服务器8a可以被配置为提供TCP-UDP桥。声明客户端7a可以通过TCP到达MTURN服务器，但是仍然获得是UDP的分配的端口，例如：客户端7a与MTURN服务器8a之间的支路可以是TCP，但是MTURN分配的端口与对等端端点6b/MTURN服务器6b之间的流可以是UDP。

提高的可靠性：

呼叫方和被呼叫方端点6a、6b都能够在地理上最靠近它们的中继服务器上分配MTURN候选。利用现有的TURN实现方式，即使端点中的一个由于任何原因而遇到中继分配失败，如果涉及的端点位于NAT后面，则将导致连接失败。

利用MTURN，即使只有端点中的一个能够聚集MTURN候选呼叫也能够存活并被建立。即使两个端点都在NAT后面，这也是有效的。使用会话标识符S1，NAT映射的地址不再需要被发现，以开放明确地针对IP地址的权限。

所有权移交：

无缝本地接口切换：

活跃的MTURN会话的所有权可以通过重新分配模块52R在会话中间进行转移从当前传输地址X'到新的传输地址Z'。这可以在现有媒体流被中继到X'的同时，并且响应于重新分配，媒体中继模块54将现有媒体流重新引导到新地址Z'。

现在将参考图12A和图12B来描述这一点

作为示例，考虑其中机器具有有线接口(具有本地传输地址X)和无线接口(具有本地传输地址Z)两者的情况，并且响应于分配请求58，使用有线接口(X)分配MTURN候选。在这种情况下，底层TURN会话将被填充，如图12B的左侧所示。

如果有线接口断开连接，则MTURN会话的所有权可以如下被无缝地移交到无线接口。

从无线接口192.1.1.12:5000发送包含相同的MTURN会话标识符S1的新的分配请求58'。这个分配请求58'也由消息完整性保护，因此使用该方法不存在安全问题。重新分配模块52R更新具有该会话标识符的会话56以用从新请求58'获得的Z'来替换X'。

在中继服务器处理分配请求之后的MTURN会话状态被示出在图12B的右侧。

该切换仅通过到中继服务器14的一个分配请求58'被无缝地实现。该切换不涉及任何信令支持或任何附加的设置活跃的目的地事务。此后，MTURN候选可以由无线接口使用，并且由对等端发送到MTURN端口的任何分组将被中继到无线接口(Z)而不是有线接口(X)。

高可用性和呼叫弹性：

利用当前实现方式，在连接检查结束时，两个端点会汇聚在媒体路径上。如果这个媒体路径出于任何原因失败了，这将转化为呼叫中间失败。本节将介绍几个潜在的失败情况，以及针对这些失败呼叫如何可以继续幸存。

中继升级/损耗：

利用部署在边缘机器上的中继服务器，在呼叫中间，中继服务器可以被潜在地取下。客户应该能够尽可能无缝地检测到不同中继服务器的呼叫。

存在两种可能的情况：

1.中继使用分配错误响应通知客户端其将被取下替换为可替代的服务器，客户端可以试图使用用于发送分组被分配的端口以响应于客户端的企图。针对作为已建立的媒体会话的一部分的TURN会话，这需要媒体中继服务器和客户端上的新功能来处理。

2.客户端通过定期刷新分配请求来实现死中继检测。检测方案可以被最终定为详细设计的一部分。

对于这两种情况，客户端将需要从中继分配新的MTURN候选，并将媒体流切换到新的MTURN候选，而不会对呼叫造成显著影响。存在媒体流的几种潜在的变形。呼叫可以如下流送：直接-直接(direct-direct)、MTURN-直接(MTURN-direct)、MTURN-MTURN，但底层恢复机制是相同的。

呼叫恢复：

呼叫可以是直接-直接、MTURN-直接、MTURN-MTURN流送，针对这三者的底层恢复机制是相同的。

1.检测现有媒体路径的失败。通过定期刷新分配请求中的失败可以检测到中继中断。可以使用同意新鲜度来检测媒体路径失败E2E，即使不涉及中继服务器。

2.通过向对等端端点通知要使用的新媒体路径来恢复呼叫。

如果两个端点始终在备用路径上维持MTURN候选，则不管其是否用于媒体流，都可以通过使用下面概述的路径切换基元切换到MTURN路径来显而易见地恢复该呼叫。只要一端具有正在运行的MTURN候选，这些呼叫就可以幸存。注意，这是通过使用会话标识符而变得可行的：会话标识符实际上被保留以供在发生失败时使用，例如，作为ICE建立过程的一部分，以实践中端口不能(因为它是太有价值的资源)的方式。

另一种情况是当用于媒体流的媒体中继服务器由于计划和未计划的任何原因而关闭时。

通知对等端媒体路径切换：

用于构建弹性和高可用性场景的路径切换基元如下：

1.通过向具有新事务ID的STUN绑定请求添加新属性来向对等端6b通知路径切换。对等端6b在接收STUN绑定请求时将切换为将媒体发送到新的目的地。如果对等端6b正在使用MTURN候选，则其将把新的远程地址设置为当前活跃的目的地。

2.对等端6b发送STUN绑定响应，其是使用STUN绑定响应中的事务ID由发起方6a进行匹配的。

以上路径切换可以利用一个STUN绑定请求/响应事务来完成。利用这种方法不存在新的安全问题，因为STUN消息交换是受到消息完整性保护的。

图13A示出了被添加到STUN消息80的新属性82的可能的格式。家庭字段被设置为IPv4(例如，由0x01指示的)和IPv6(例如，由0x02指示的)中的一个。该属性的前8个比特被设置为0，并且不被使用在本示例中。

注意：如果端点想要从在一个中继上使用MTURN候选切换到另一个中继，则还需要包括被分配在其他中继上的MTURN的MTURN会话标识符。可替代地，如果客户端生成MTURN会话标识符，则客户端也可以将相同的MTURN标识符分配在另一中继上，并避免将MTURN标识符添加到路径切换消息。

示例场景：

参考图13B，现在将概述失败的情况，其中中继MR1在建立的音频会话的中间期间下降。对于下面的部署，其中呼叫方位于NAT后面的并且被呼叫方直接可访问。媒体路径是从X<->MR1<->Y.

这是其中只有一个端点具有MTURN候选的更极端的示例。对于大多数场景，至少一个端点将具有可用的MTURN候选，并且媒体路径可以被切换到该路径而不对媒体流作任何中断。

以下是恢复此呼叫所涉及的步骤：

1.端点6a(X)检测到先前服务它的媒体中继服务器14(MR1)通过分配刷新机制而下降。

2.端点6a通过将新的分配请求58”发送到新媒体中继14'获得在新的媒体中继服务器14'(MR3)上的新的MTURN候选。这个新的消息包括标识原始服务器14上的会话的会话标识S1，即相同的会话标识符S1用于标识新服务器14上新创建的会话。消息58”受到完整性保护，并且会话是由新服务器14”(受到验证)以与上述相同的方式来创建的。端点6a可以使用在NAT 8a的公共侧的相同的端口(例如5000)以用于新的媒体路径，或者其可以使用在NAT 8a的公共侧的不同端口(例如5005，如图13B的示例)-任一选项都是可行的，尽管第二种更可能：这种映射取决于正在使用的NAT的类型。一些NAT将生成相同的端口映射，但是大多数NAT将生成新的端口映射以用于图13B所示的场景。所使用的传输地址中的无论哪一个都是在新的中继服务器14'处被映射到会话标识符S1的地址，使得新的中继14'可以将媒体转发给它。

3.作为响应，端点6a将路径改变请求STUN绑定请求发送到对等端6b(Y)，指定MR3＝[MR3 IP]：3479作为新的目的地，其中[MR3 IP]是新服务器14'的IP地址，并且3479是音频端口。

4.在接收到请求时对等端6b(Y)切换为将媒体分组发送到[MR3 IP]：3478而不是MR1，并且还响应于STUN绑定请求。

5.在接收到STUN绑定请求时，呼叫恢复过程完成。

由此，媒体路径被切换到X<->MR2<->Y而对现有媒体会话没有显著的影响，即，现有会话实际上从服务器14被转移到新的服务器14”，而没有中断或者最少的中断。所花费的时间基本上是一个RTT用于分配新的MTURN候选，以及另一个RTT用于通知对等方中继地址改变。

即时提议/应答

在现有的通信系统中，建立媒体会话通常要求呼叫方聚集其潜在的候选以包括在提议中。同样，被呼叫方将聚集其候选以包括在应答中。这个候选聚集需要时间，并且可以影响呼叫建立时间和感知的用户体验，特别是在低带宽网络上。

相比之下，本公开的即时提议/应答机制允许即时生成提议和应答，减少了呼叫建立时间。即，本主题减少了在端点之间建立实时媒体会话所花费的时间，即使在具有低带宽网络上。

另外，实施例允许NAT的动态遍历，使得可以实现呼叫建立时间减少而不增加中继服务器上的负载。这是通过在发送即时提议/应答之后动态地发现NAT映射(而不是在提议/应答本身中包括NAT映射)来实现的。

在任何呼叫被采用之前，本地预先获取并高速缓存至少一个MTURN候选(可替代地，如所描述，其可由客户端生成)。高速缓存的MTURN候选不需要保持活跃的探测或任何额外的网络或处理开销来保持高速缓存的候选是活跃的，因为根据上述MTURN协议其仅在发送提议/应答时被激活。此外，NAT映射是动态发现的，并且使用缓存的MTURN候选可以高效地遍历NAT。

与常规TURN相比，上述的“MTURN”协议本身显著地减少了提议和应答生成时间，即使候选直到开始建立呼叫时才聚集。然而，对于质量差的网络，即使对于MTURN，提议/应答生成时间仍然是不可忽视的，特别是当候选聚集过程与呼叫信令针对可用宽带竞争时。

为此，下面提供进一步的协议扩展和设计，以使传输候选可用于立即生成提议/应答所需的候选行，而不是将TURN/STUN候选聚集为呼叫建立本身的一部分。

图14示出了用于以下的信令图：(i)将MTURN ID S1预分配给呼叫方客户端7a所涉及的步骤，以及(ii)随后到被呼叫方客户端7b的提议以及在建立呼叫开始时并行激活S1。

步骤S1402-S1404构成在呼叫建立之前在任何合适的时间(例如，多达一小时(若干小时)、甚至一天(若干天)之前)执行的预建立阶段。在步骤S1402，呼叫方客户端7a经由第一NAT 8a向其TURN服务器14a发送分配请求57。例如，在由刷新周期设置的时间，或者在任何其他适当的时间(预定的或事件驱动的)，响应于客户端6a最初被加载(即，在第一用户设备7a的处理器22上实例化)，步骤S1402可以被执行。针对MTURN候选的分配请求57被发送到媒体中继服务器的选播地址。

作为响应，在步骤S1404，媒体中继服务器14a将分配错误响应(401)57R发送到呼叫方客户端7a，其提供以下被包含在给被呼叫方7b的提议中的：

·给呼叫方客户端7a的媒体中继服务器14a的直接IP地址，

·与该地址关联的MTURN端口，以及

·唯一的MTURN会话标识符S1。

在这一点上，如上所述，呼叫方的服务器14a尚未创建TURN会话，但呼叫方客户端7a具有足够的信息来立即向对等端端点6b发送提议，具有零网络往返。MTURN候选由直接媒体中继IP地址、MTURN端口(其构成传输地址MR1)以及会话标识符S1形成。

注意，步骤S1402-S1404完全对应于图8的前两个步骤。事实上，其被预先执行实现了在步骤S1408b(见下文)处的提议的立即发送。预先获得的MTURN候选S1被存储在第一用户设备6a的本地存储器20中，随时准备随后在需要时发送给被呼叫方7b。

在步骤S1406，在步骤S1404处已经预先获得了MTURN候选S1之后，在呼叫方客户端7a处从第一用户4a接收到呼叫发起输入。呼叫发起输入可以例如通过用户选择经由客户端7a的用户接口(例如，图形用户接口、自然用户接口)来呼叫第二用户4b的选项而被发动，或者其可以是到第一用户设备6a的语音或姿势输入、或任何其他合适的用户输入，其传送第一用户在那个时刻呼叫被呼叫方客户端7b的愿望。这可以是在步骤S1406处已经接收到响应57R之后的一小时(若干小时)或者甚至一天(若干天)。

直接响应于S1406的用户输入，呼叫方客户端7a立即发送：

·到被呼叫方6b的提议消息70(S1408a)以及，

·并行地，MI保护的分配请求58包括会话标识符S1(S1408b)。提议消息70可以经由SIP服务器15或者可以将其中继到被呼叫方7b的一些其他代理服务器实体来传送(但是其不适用于中继媒体会话本身的媒体数据-因此需要发现用于媒体数据的潜在路径)。提议70可以经由SDP或适用于会话建立的任何其他协议来发送。

在常识呼叫之前，只要在呼叫方客户端7a处从其中继14a接收到响应57R，则提议70将立即可用而没有延迟。提议70包括MTURN候选(MR1+S1)以及在其NAT 8a后面的私有地址空间中的第一用户设备6a的主机候选，但是不包括反射候选(即，它不指示第一NAT 8a的任何公共传输地址。即，它不包括任何服务器反射候选。即使服务器反射候选已经在预建立阶段期间从其中继服务器14a在响应57R中被传送到呼叫方客户端7a，情况也是如此。排除这种情况的原因是，除非使用保持活动的探测，否则在发送提议70(如上所述可以是几小时甚至几天之后)时，将不再构成NAT有效的映射-在这种情况下其是没用的。在所有其他方面，步骤S1408a和S1408b分别与图8的步骤3a和步骤3b完全对应。

如上所述，会话标识符S1仅基于步骤S408b的MI保护的分配请求57而被激活，其中分配请求57是在呼叫建立开始时被发送的。与先前被发送用于首先获得S1的请求57相比，这是从不同的套接字被发送的，并因此是不同的传输地址。这是非实质的，因为其只是在建立呼叫开始时发送的第二个分配请求58，其使得会话标识符S1被激活，即，在经过第一个NAT8a之后，会话ID S1与由后面的分配请求60传送的源地址相关联。因此，在步骤S1402中用于获取S1的传输地址是非实质的；只有在步骤S1408b中用于激活它的传输地址需要保持为有效的。一旦S1已经被激活，则在步骤S1410将响应58R发送回到呼叫方7a。之后，参考图8，流程完全如上所述地进行。

由于包括步骤S1402-S1404的预建立阶段不是呼叫建立的一部分，所以针对呼叫方7a或被呼叫方7b的候选聚集所花费的时间没有约束。因此，在这个阶段期间可以执行附加的探测和分析，以预先获得就绪以用于呼叫建立的附加信息。例如，客户端7a可以在这个预建立阶段期间确定是否有可能通过UDP到达服务器14(这可能是不可能的，例如如果其NAT 8a阻断UDP)。如果在该预建立阶段期间确定了与服务器14的UDP通信是不可能的，则呼叫方客户端7a可以跳过尝试通过UDP来激活MTURN会话ID S1(在步骤S1408a)，因为其知道这几乎将肯定失败。这减小了激活过程的复杂性，并节省了另外在失败的消息中不必要地被使用的带宽。

如上所述，利用图14的即时提议生成流，初始分配请求57由呼叫方客户端7a来发送。作为其中的一部分，呼叫方客户端可以偶然发现NAT映射作为在401错误响应57R中接收的NAT映射的地址的一部分。这在图15A中被示出(对应于图14的步骤S1402)，其示出了呼叫方客户端7a将初始分配请求57(没有MI)发送到服务器14。呼叫方客户端6a从初始本地传输地址X(10.21.21.42:3000)发送分配请求，本地传输地址X NAT映射到X'(65.35.52.12:3000)。传输中继服务器14a因此将看到源自X'(65.35.52.12:3000)的请求。服务器14a用具有(S1)的MTURN会话标识符的410错误响应57R、中继服务器(202.202.1.2)的IP地址以及MTURN端口(3478)来进行响应。该IP地址和端口构成媒体中继14a MR1(202.202.1.2：3478)的传输地址，其与会话标识符S1一起构成MTURN候选。

响应57R还可以向客户端6a指示公共地址X'。然而，通常，后面的MI保护的激活70将使用不同的套接字来发送到中继14a，该套接字将具有不同的NAT映射。这在图15B中被示出(对应于图14的步骤S1408b)，其示出了呼叫方7a从与呼叫方客户端7a先前的不同的端口来激活MTURN ID S1。即，客户端从NAT映射到Z'≠X'(65.35.52.12:5000)的不同传输地址Z≠X(10.21.21.42:4000-不同端口)发送具有MTURN会话标识符S1的分配请求。TURN服务器将看到源自Z'的请求，并因此通过将S1与Z'(而不是X')关联来创建TURN会话。

由于X'是无用的，所以由呼叫方在步骤S1408a生成的提议70仅包括主机候选和MTURN候选，而不包括X，即：

·Z(10.21.21.42:4000)

·S1+MR1(202.202.1.2:3478)

此外，由于提议70在激活完成之前被发出，所以在这一点之后发现的任何NAT映射(例如，在步骤S1410的分配响应58R中被传送的)都不能经由SDP交换到对等端，而不增加附加若干轮SDP消息交换。

在已经接收到提议70之后，被呼叫方7b可以开始通过将分组与包括会话标识符S1的瘦MTURN报头进行封装来将到呼叫方7a的媒体分组60发送到提议70中指示的中继服务器14b的传输地址MR1，其中会话标识符S1被提供在提议57中，如上所述。

尽管在图14中未明确示出，但是由被呼叫方客户端7b来执行完全等同的步骤，以便生成对提议70的即时应答。针对即时提议，在步骤S1404接收的提议70在客户端处替换了用户输入。即，在接收到提议70之前，被呼叫方客户端通过等同于S1402和S1404的步骤，针对其自己的MTURN候选预先获得其自己的唯一的会话ID S2。然后，直接响应于提议70：

·被呼叫方客户端在与步骤S1408b等同的步骤中利用其自己的TURN服务器(14b，图16)来激活该会话标识符S2，并且，

·并行地，将包括其自己的本地地址Y和其自己的MTURN候选MR2+S2的即时应答发送到呼叫方客户端7a(相当于步骤S1408b)。

对于即时提议70，可以使用SDP或一些其他合适的协议经由SIP代理或其他合适的代理来发送即时应答。

因此，在图15B的示例中，被呼叫方7b将发送具有以下候选的即时应答：

·Y(12.32.43：3000)；

·MR2+S2。这里MR2是以同样的方式获得的被呼叫方的中继14b的传输地址(65.20.33.2.3478)。S2是在已经以与S1相同的方式接收到提议70之前从第二中继服务器14b预先获得的被呼叫方的会话标识符。

Y是被呼叫方7b的私有本地传输地址，其在第二NAT 8b上被映射到公共地址Y'。与提议60一样，由于相同的原因，响应没有服务器反射候选。即时提议/应答交换后的NAT映射的动态发现：

ICE协议依赖于STUN候选发现和有效的STUN候选的交换作为提议-应答交换的一部分以成功地遍历NAT，而不需要用于媒体流的中继服务器。ICE协议可以成功地遍历完整圆锥型(Full Cone)、IP受限型和端口限制型NAT，而不使用用于媒体流的中继服务器。此功能对于将中继服务器上的负载保持在可管理的级别是非常重要的，并确保了仅在绝对必要时才使用中继服务器。

为了确保反射候选仍可以被发现而不需要附加的SDP交换，并且NATS8a、8b上的必要权限被开放以使得这些动态发现的地址可用，则呼叫方和被呼叫方客户端7a、7b在动态的发现过程中进行协作，如下。

图16示出了在该动态发现过程期间发生的客户端7a、7b之间的信令流。当客户端7a、7b具有彼此的主机和MTURN候选时，在即时提议/应答交换之后执行该过程，作为连接检查的一部分。

针对连接检查，在呼叫方和被呼叫方两者上初始可用的候选对(即，紧接在即时提供/应答交换之后的)如下：

·主机-主机，即主机传输地址Z和Y的配对。由于两个地址都在私有地址空间(除非它们恰好在相同的私有地址空间中)中，因此此路径将不工作。

·主机-MTURN，即，用于呼叫方7a的(X，MR2+S2)；用于被呼叫方7b的(Y，MR1+S1)。这条路径在很多情况下都可以工作，但是由于

需要使用中继服务器，所以(在网络资源方面)比较昂贵

·MTURN-MTURN，即，MR1+S1和MR2+S2的配对。这个路径是保证工作的，但是由于需要使用中继服务器而是很昂贵的。

转到图16并且初始地集中在用于呼叫方7a的主机-TURN路径，当呼叫方7a将连接检查请求(即，探测消息，例如ICE连接检查请求)从Z发送到被呼叫方的MTURN候选MR2+S2(1.a),消息将经由被呼叫方的中继服务器14b被传送到被呼叫方7b，作为MTURN标识符S2在分组的主体中的结果。注意，由于消息是经由第一NAT 4a被发送的，所以对于被呼叫方7b而言，消息将显示为源自Z'(2.a)，因此该消息将呼叫方的公共地址Z'传送到被呼叫方(3.a)。即，被呼叫方将看到源自地址Z'的请求，该地址未被公布在SDP提议70中。作为响应，被呼叫方7b创建包括Z'的新的对等端导出的远程候选。那么现在被呼叫方7b已经动态地发现了呼叫方6a的正确的NAT动态映射Z'。

类似地，当被呼叫方7b在图16中执行其对应于1.a-3.a的连接检查1.b-3.b时，呼叫方7a也将动态地发现被呼叫方7b的Y'映射。被呼叫方7b将连接检查消息发送到具有Y的MR1+S1作为其源地址(1.a)，其由第二NAT 8b(2.b)改变为Y'。该消息经由第一中继服务器14a被中继到呼叫方7a，由此将Y'传送给呼叫方7a(3.b)。

作为结果，主机-TURN路径对呼叫方和被呼叫者都是成功的，并且两侧都发现了NAT映射。因此到目前为止，实现方式依附ICE RFC。

然而，此刻在流程中，该过程偏离RFC并且仅将新发现的对等端反射远程候选映射到本地主机候选，以用于附加的连接检查。这违反了ICE RFC，其声明对等端反射远程候选不应与其他本地候选配对(https://tools.ietf.Org/html/rfc5245#section-7.2.1.3)。作为结果，呼叫方和被呼叫方将分别具有下列候选对。

·Z-Y'(呼叫方7a)

·Y-Z'(被呼叫方7b)

与ICE RFC形成对比，也针对这些主机-对等端反射候选对执行连接检查。这种偏离行为仅适用于在MTURN候选上收到的连接检查上发现的对等端反射候选。

对此原因在于，针对一些类型的NAT，如果由呼叫方7a已经将消息从Z发送到Y'，则呼叫方的NAT 8a会只将在Z'处接收的消息从Y'中继到Z；类似地，如果由被呼叫方7b已经将消息从Y发送到Z'，则被呼叫方的NAT8b可以只将在Y'处接收的消息从Z'中继到Y。因此，针对一些类型的NAT，即使呼叫方6a现在具有Y'，它仍然不具有在第二NAT 8b处直接将消息发送到Y'(即，不经由被呼叫方的TURN服务器14b)的权限，并且第二NAT8b因此会忽视任何这样的信息。类似地，针对一些类型的NAT，即使被呼叫方6b现在具有X'，它仍然不具有在第一NAT 8a直接将消息发送到Z'(即，不经由呼叫方的TURN服务器14a)的权限，并且第一NAT 8a因此将忽略任何这样的消息。

这个问题通过对主机-对等端反射候选对执行附加的连接检查来解决，如下所示：

·4.b：被呼叫方7a经由第一个NAT 8a将连接检查消息发送给新发现的Y'，其中Z是源地址。Z在第一个NAT 8a处被映射到Z'，并且在接收时，针对Y'开放了呼叫方的NAT 8a上的权限(5.b)。然后，随着权限这样被开放了，在Z'处接收的以Y为源地址的消息(例如，对连接检查消息或实际媒体分组的响应)将由呼叫方的NAT 8a中继给Z.

·4.a：类似地，当连接检查分组从Y-Z'由被呼叫方7b发送时，针对Z'，以完全相同的方式开放在被呼叫方的NAT 8b上的权限(5.a)。

通过激活请求在服务器14a、14b处被映射到会话标识符S1、S2的传输地址可以与图16的流程中所使用的传输地址相同，即MR1+S1和MR2+S2可以被分别映射到服务器14a/14b的Z'和Y'。然而，这不是必须的：呼叫方和被呼叫方7a、7b可以使用不同的传输地址来从中继服务器14a、14b接收数据，而他们不是用于彼此直接通信。即，MR1+S1和MR2+S2可以分别被映射到第一和第二NAT 8a、8b上的不同的公共传输地址，而不是Z'和Y'。

在连接检查期间，在接收到响应于其较早的探测请求中的至少一个的连接检查时，被呼叫方7a和被呼叫方7b两者将发现它们自己的NAT映射作为对等端导出的本地候选。在连接检查结束时，针对媒体流选择的最终路径将是：

·Z'-Y'(呼叫方)，候选类型分别是对等端导出的本地和对等端导出的远程。

·Y'-Z'(被呼叫方)，候选类型分别是对等端导出的本地和对等端导出的远程。

通过以上所述，成功地动态地发现了相关的NAT映射，并且即使NAT映射的候选没有在初始(并且仅仅是)SDP提议/应答交换中被交换，媒体路径也可以被建立，而不使用用于媒体流的中继，并且也不需要附加若干轮的SDP信令。

聚集新的MTURN候选：

响应于下述的触发事件中的任何一个，客户端7a/7b将从其中继14a/14b中获得至少一个新的MTURN候选：

·当客户端被加载时；

·如果现有的MTURN中继信息陈旧，即已过期。这可以基于自MTURN信息被聚集后的超时。

·检测到的网络接口和/或网络位置更改。

·客户端还周期性地验证由中继提供的MTURN候选的IP地址，并且如果该IP地址不再有效则进行刷新，例如因为中继已经失效或者被取下以用于维护。验证时间段可以被设置为平衡带宽使用、可靠性和潜在的预期中继下降时间。

·在呼叫建立时激活预先获得的MTURN候选失败。

多个MTURN ID和相关的安全考虑：

在实施例中，客户端7a在存储器20中维持多个MTURN ID(例如，三到五个)的池。当使用MTURN ID时，可以获得新的MTURN ID以维持池的大小。

当与其相关联的证书到期时，服务器12实现清理机制以使MTURN ID到期。针对MTURN ID冲突的跟踪和诊断；这些不太可能发生，并且可以在传输中继服务器上采取步骤以确保MTURN标识符不被过早地回收以避免冲突。在其上客户端包含MTURN标识符的时间表与清除机制的时间表相匹配，当客户端仍有机会使用它们时，会话ID不会到期。例如，在适当的情况下，ID可以在其过期之前保持若干小时或若干天是有效的。

如上所述，除了MTURN候选的分配和MTURN候选的激活在时间上是分离的事实之外，图14的即时提议/应答流程基本上与上述MTURN分配请求过程相同。初始分配请求与来自媒体堆栈层的MI保护的分配请求之间的持续时间可以是任意长的。

这种改变开放了攻击者保留大量MTURN ID的可能性，这导致了性能下降，或者在最坏的情况下，拒绝服务(DOS)。为了减轻这一点，中继14可以将会话标识符的发布与通信系统内的用户名(或其他用户标识符)绑定。

在图14的示例中，这表示服务器14在发送具有MTURN ID的401分配错误响应401之前验证用户4a的用户名，使得会话ID只能由具有有效用户名的人获得。服务器14还针对发布给任何一个用户名的非活跃的MTURN ID的数量设置最大上限。

注意，在本上下文中的“唯一的”表示足够独特以便区分经由相同的媒体中继服务器端口被中继的不同的会话。在一些但不是全部情况下，标识符可以是全球唯一的，例如，以实现未经检查的客户端侧验证和/或实现例如由于失败的媒体中继服务器之间的会话转移。在任何给定的上下文中，所需的唯一性级别将是显而易见的。

本主题的第一方面涉及一种在第一端点与第二端点之间建立媒体会话的方法，所述方法包括：从第一端点向第二端点发送指示对第一端点可用的媒体中继服务器的第一服务器网络地址并且包括唯一的会话标识符的消息；以及与该消息并行地从第一端点向媒体中继服务器发送包括该唯一的会话标识符的激活请求，从而通过使会话标识符在所述媒体中继服务器处与激活请求运送的原地址相关联来激活会话标识符；其中一旦会话标识符被激活，则在第一服务器网络地址处从第二端点接收的、包括唯一会话标识符的媒体分组被从媒体中继服务器中继到源地址以用于由第一端点来接收。

在实施例中，消息可以是提议消息，并且直接响应于在第一端点(例如，从第一端点的用户)处接收的会话发起输入，可以发送提议消息和激活请求。

可替代地，该消息可以是应答消息，并且直接响应于在第一端点处从第二端点接收的提议消息，可以发送应答消息和激活请求。

在这样的实施例中，在发送消息之前发生的本文中公开的任何事件也在接收到输入或提议之前发生。

激活请求的源地址可以是当由第一端点发送时第一端点的第一本地网络地址。

激活请求可以经由第一端点所连接到的第一网络地址转换器来发送，其生成在第一网络地址转换器的第一公共网络地址与第一本地网络地址之间的映射，并且将激活请求中的源地址改变为第一公共网络地址，使得会话标识符一旦被激活就在媒体中继服务器处与第一公共网络地址相关联。

发送到第二端点的消息可以不指示第一网络地址转换器的第一公共网络地址。它可以不指示第一网络地址转换器的任何公共网络地址。

例如，第一网络地址转换器的第一公共网络地址可以在消息已经被发送之后由媒体中继服务器传送到第一端点，使得其不可以被包括在到第二端点的消息中。

该消息可以使用SDP来发送。然而，第一网络地址转换器的公共网络地址不会通过SDP被传送到第二端点。第一端点永远不会通过SDP从第二端点接收第二端点所连接到的第二网络地址转换器的任何公共网络地址。即，公共NAT地址完全不会通过SDP进行传送。

所述方法可以包括：在发送消息之后，经由第一端点所连接到的第一网络地址转换器将第一传出探测消息(例如，ICE连接检查请求)发送到第二端点，由此第二端点可以根据第一传出探测消息来确定第一网络地址转换器的第三公共网络地址。

由第二端点确定的第一NAT的第三公共网络地址可以与第一NAT的第一公共网络地址相同或不同，其中在媒体中继服务器处所述第一NAT的第一公共网络地址与会话标识符相关联。

所述方法可以包括：从第二端点接收对第一传出探测消息的响应(例如，ICE连接检查响应)，并且根据响应确定第三公共网络地址。

第一传出探测消息在被传送时可以具有第一端点的第三本地网络地址作为其源地址(其可以与根据其激活请求被发送的第一本地网络地址相同或不同)，第一端点的第三本地网络地址在第一网络地址转换器处被映射到第三公共地址。

第三公共网络地址可以与在媒体中继服务器处与会话标识符相关联的第一公共网络地址不同，在这种情况下，第一和第三本地地址也可以是不同的。可替代地，第一和第三网络地址可以是彼此相同的；在这种情况下，第一和第三网络地址可以是彼此相同的。

所述方法可以包括：在第一端点处从第二端点接收对第二端点可用的媒体中继服务器的第二服务器网络地址的指示符，其中，第一传出探测消息可以被发送到第二服务器网络地址以用于转发到第二端点。即，第一传出探测消息可以经由对第二端点可用的媒体中继服务器被发送(例如，其已经被授权允许通过第二端点所连接到的第二网络地址转换器将消息发送到第二端点)。

在一些情况下，利用第二服务器网络地址的指示符来接收另一唯一的会话标识符，并且第一传出探测消息包括其他唯一的会话标识符。

第一传出探测消息可以具有在被发送时作为其源地址的第三本地网络地址，并且被发送到第二服务器网络地址。例如，它可以是针对(主机，[M]TURN候选对)的ICE连接检查的一部分。

所述方法可以包括：在发送消息之后，在第一端点处经由第二端点所连接到的第二网络地址转换器从第二端点接收传入探测消息(例如，ICE连接检查请求)；并且根据传入探测消息确定在第二网络地址转换器处被映射到第二端点的第二本地地址的所述第二网络地址转换器的第二公共网络地址。

所述方法可以包括：向第二端点发送对传入探测消息的响应(例如，ICE连接检查响应)，该响应向其传送第二网络地址转换器的第二公共网络地址。

传入探测消息可以经由对第一端点可用的媒体中继服务器来接收。

所述方法可以包括：向第二网络地址转换器的第二公共网络地址发送第二传出探测消息(例如，ICE连接检查请求)。

第二传出探查消息在被发送时可以具有在第一网络地址转换器处被映射到第三公共地址的第一端点的第三本地地址作为其源地址，并因此使得第一网络地址转换器授予第二端点权限以直接向第三公共地址发送消息。例如，第二传出探测可以作为(主机，对等端反射)候选对的ICE连接检查的一部分来发送-与ICE RFC形成对比–执行该操作是为了在第一网络地址转换器上开放这个权限。即，第二传出探测消息可以是ICE连接检查请求，其作为ICE连接检查的一部分被发送，该ICE连接检查是针对由第一端点的第三本地地址和第二端点的第二公共地址形成的主机-对等端反射候选对的。

所述方法可以包括在被授予权限之后，在第一端点经由第一网络地址转换器接收：

·对第二传出探测消息的响应，其将第三公共网络地址传送到第一端点，和/或

·媒体分组；

该响应和/或媒体分组已由第二端点直接发送到第三公共地址。

所述方法可以包括将以下内容从第一端点直接发送到第二端点的第二公共网络地址：

·第二端点的第二公共网络地址的指示符，从而将其传送到第二端点；和/或

·媒体分组。

这可以是在第二端点启动了等效(主机，对等端反射)连接检查之后，开放在第二网络地址转换器上的必要的权限。

会话标识符可以被预先分配，即，在消息被发送之前(在接收到用户输入或提议消息之前)，由媒体中继服务器分配给第一端点，并且分配的会话标识符可以被存储在第一端点处以用于消息中的后续传输。

为了获得会话标识符，第一端点可以向媒体中继服务器呈现与第一端点相关联的用户标识符，其中，仅当用户标识符被服务器确定为有效和/或已经分配给该用户标识符的会话标识符的总数低于阈值时，才将会话标识符分配给第一端点。

在消息被发送之前，第一端点可以根据优选的网络协议(例如UDP)将请求发送到媒体中继服务器，其中，如果没有接收到响应，则将激活请求根据可替代的网络协议(例如TCP)发送到媒体中继服务器。

为了获得会话标识符，第一端点可以经由第一网络地址转换器将分配请求发送到媒体中继服务器。响应于分配请求，媒体中继服务器可以将根据分配请求由媒体中继服务器确定的会话标识符和第一网络地址转换器的不同的公共网络地址发送到第一端点，其中，在被传送到第二端点的消息中没有指示不同的公共网络地址。

会话标识符可以是由第一端点生成的全局唯一的标识符。

网络地址可以是传输地址(IP地址+端口)。如果传输地址具有不同的端口，即使它们具有相同的IP地址，则传输地址也是不同的。

根据本主题的第二方面，第一端点包括：网络接口；以及处理器，其被配置为实现本文中公开的方法步骤中的任何一个。

根据第三方面，一种计算机程序产品，其包括存储在计算机可读存储介质上的代码，并且当在第一端点的计算机上被执行时，被配置为实现本文中公开的方法步骤中的任何一个。

在第一、第二和第三方面的实施例中，第一端点和/或第二端点和/或媒体中继服务器可以根据下面所述的其他方面中的任何一个或其实施例来进行配置。

本公开的第四方面涉及一种用于在网络的端点之间实现通信事件的媒体中继服务器，所述服务器包括：网络接口，其被分配有服务器网络地址并且具有与由端口标识符识别的服务器网络地址相关联的端口；计算机存储装置，其用于保持与端口相关联的端口多路复用数据库；资源分配模块，其被配置为：从所述网络接收多个分配请求，每一个分配请求指示不同的端点网络地址，并且将与唯一的会话标识符相关联的每一个端点网络地址存储在所述数据库中；输入，其被配置为同时经由端口从网络接收多个媒体流，每一个流都被引导到服务器网络地址并且指示端口标识符和分离的目标会话标识符；以及中继模块，其被配置为针对每一个流：确定在数据库中的与使用由该流指示的目标会话标识符相关联的端点网络地址并且将该流发送到该端点网络地址，由此将多个媒体流同时经由相同的端口中继到不同的网络端点。

在实施例中，媒体中继服务器可以是TURN服务器。

媒体中继服务器可以包括会话标识符分配器，其被配置为向请求者分配所请求的会话标识符。

例如，媒体中继服务器可以包括认证模块，其被配置为认证请求者，但是会话标识符分配器可以被配置为在请求者已经被认证模块认证之前，用对请求者的指示所请求的会话标识符的响应来对请求者进行响应。

作为示例，当请求者已经被认证模块成功认证时，所请求的会话标识符可以仅与数据库中的期望的端点网络地址相关联，使得在此之前所请求的会话标识符不能用于将媒体经由端口中继到期望的端点网络地址。

可替代地或附加地，会话标识符分配器可以被配置为利用对请求者的指示所请求的会话标识符的响应来直接对请求者进行响应，由此所请求的会话标识符在单个请求-响应交换中呈现为对请求者是可用的。

可替代地或附加地，会话标识符分配器可以被配置为在所请求的会话标识符已经与数据库中的任何端点网络地址相关联之前，用对请求者的指示所请求的会话标识符的响应来对来自请求者的临时分配请求进行响应，使得所请求的会话标识符在其被用于经由端口将媒体中继到任何端点网络地址之前呈现为对请求者是可用的。

例如，响应于指示期望的端点网络地址的后续分配请求，期望的端点网络地址可以仅与数据库中的所请求的会话标识符相关联，使得在此之前所请求的会话标识符不能用于经由端口将媒体中继到期望的网络地址。

可替代地或附加地，后续分配请求可以是消息完整性保护的，并且媒体中继服务器可以包括完整性验证模块，其被配置为验证后续分配请求；仅当后续分配请求由完整性验证模块确定为是有效的时，期望的网络地址才可以与数据库中的所请求的会话标识符相关联。

在一些情况中，临时分配请求可以不受消息完整性保护。

可以已从网络接收到会话标识符中的至少一个。例如，至少一个会话标识符可以已经被生成在端点中的一个端点处。可替代地或附加地，可能的是，至少一个会话标识符先前在另一媒体中继服务器处被用于将现有媒体流中继到端点，由此现有媒体流被重新引导到媒体中继服务器以用于继续经由媒体中继服务器中继到该端点。

媒体中继服务器可以包括重新分配模块，其被配置为响应于来自指示新的端点网络地址的网络的重新分配请求以及被存储在数据库中的与当前端点网络地址相关联的会话标识符，来更新数据库以将已存储的会话标识符与新的端点网络地址相关联。

例如，可以在现有媒体流被中继到当前网络地址的同时来执行更新，并且中继模块可以被配置为将现有媒体流重新引导到新的端点网络地址作为响应。

针对网络端点地址中的至少一个，还可以将以下内容与至少一个端点网络地址相关联地存储在数据库中：另一媒体中继服务器的另一服务器网络地址以及另一会话标识符。所述媒体中继模块可以被配置为：

从具有至少一个端点网络地址的网络端点接收另一媒体流，另一媒体流包括其他媒体中继服务器的端口的另一端口标识符，并且

修改另一媒体流以除了另一个端口标识符之外还包括其他会话标识符，并且将修改的媒体流经由网络中继到其他媒体中继服务器的端口，从而允许其他媒体中继服务器将媒体流也经由其他媒体中继服务器的端口同时中继到不同的端点。

会话标识符可以具有至少64比特的大小。

媒体中继服务器可以包括多个端口，每一个端口与不同的媒体模态相关联，其中，被引导到服务器网络地址的媒体模态的所有媒体流都经由该端口被中继。

每一个媒体流都可以包括：

·网络层报头数据，其对服务器网络地址进行编码，从而将该流引导到该网络层处的服务器网络地址；

·传输层报头数据，其对端口标识符进行编码，从而指示在传输层的端口标识符；和

·应用层数据，其对目标会话标识符进行编码，从而指示在应用层的目标会话标识符。

第五方面涉及一种在网络的端点之间经由媒体中继服务器实现通信事件的方法，其中，媒体中继服务器包括网络接口，其被分配有服务器网络地址并且具有与由端口标识符识别的服务器网络地址相关联的端口，其中在所述媒体中继服务器处，所述方法包括：

从所述网络接收多个分配请求，每一个分配请求指示不同的端点网络地址；

将与唯一的会话标识符相关联的每一个端点网络地址存储在与所述端口相关联的端口多路复用数据库中；

同时经由端口从网络接收多个媒体流，每一个流都被引导到服务器网络地址并且指示端口标识符和独立的目标会话标识符；以及

针对每一个流：确定数据库中的与由该流指示的目标会话标识符相关联的端点网络地址，并且将该流发送到该端点网络地址，由此，多个媒体流同时经由相同的端口被中继到不同的网络端点。

第六方面涉及一种用于在发起端点和响应端点之间经由通信网络实现媒体会话的计算机实现的方法，所述方法包括在发起端点和响应端点中的至少一个处的计算机处实现以下步骤：

·在端点处生成一组候选对，每一个候选对包括对发起端点可用的相应的网络地址以及通过在发起端点和响应端点之间交换网络地址而对响应端点可用的相应的网络地址；以及

·使用一组中的通过以下方式被确定为是有效的候选对来建立媒体会话：通过由所述端点针对一组中的至少一个候选对执行连通性检查来确定候选对是否有效；

该组包括多路复用的中继的候选对，其包括由以下各项形成的多路复用的中继的候选：可用于端点中的至少一个的媒体中继服务器的服务器网络地址、与该服务器网络地址相关联的媒体中继服务器的端口的端口标识符、以及独立的唯一的会话标识符，以允许多个媒体流同时经由媒体中继服务器的端口进行中继。

在实施例中，用于建立媒体会话的候选对可以不是多路复用的中继的候选对，并且所述方法还可以包括：将多路复用的中继的候选对存储在端点可访问的存储器中；检测所建立的媒体会话中的失败；并且作为响应，使用存储的多路复用的中继的候选对来重建失败的媒体会话，其中，媒体会话被重建而不用重新执行连通性检查。

可替代地，用于建立媒体会话的候选对可以是多路复用的中继的候选对，并且该方法还可以包括：检测媒体中继服务器的中断(例如，媒体中继服务器的失败、以及媒体中继服务器的计划的失败)；作为响应，将会话标识符发送到新的媒体中继服务器，并且使用由以下内容组成的新的多路复用的中继的候选来重建媒体会话：新的媒体中继服务器的服务器网络地址、与新媒体中继服务器的服务器网络地址相关联的新媒体中继服务器的端口的端口标识符、以及会话标识符，由此，使用相同的会话标识符来重建媒体会话。

多路复用的中继的候选可以通过端点将包括端点的本地网络地址的消息发送到媒体中继服务器以用于与会话标识符进行关联来生成，由此，被引导到多路复用的中继的候选的媒体数据被中继到本地网络地址。

例如，消息可以经由网络地址转换器被发送到媒体中继服务器，这修改消息以用网络地址转换器的公共网络地址替换了本地网络地址，由此，被引导到多路复用的中继的候选的媒体数据经由网络地址转换器被中继到本地网络地址。

可替代地或附加地，所述方法可以包括执行本地接口切换过程的端点，本地接口切换过程包括：在建立的媒体会话期间，端点将包含端点的新的本地网络地址的消息发送到媒体中继服务器以用于与会话标识符进行关联，因此，使得其后被引导到多路复用的中继的候选的媒体数据在建立的媒体会话期间，被中继到新的本地网络地址。

所述方法可以包括端点将会话标识符请求发送到媒体中继服务器，由媒体中继服务器返回会话标识符作为响应。

在一些情况下，所述方法可以包括认证过程，其中，端点将至少一个认证消息发送到服务器以针对媒体中继服务器认证该端点，在认证过程结束之前，在端点处接收到会话标识符。

会话标识符请求可以不受消息完整性保护，并且至少一个认证消息可以受消息完整性保护。

可替代地或附加地，所述至少一个认证消息可以包括端点的本地网络地址，在媒体会话期间，被发送到多路复用的中继的候选的媒体数据由媒体中继服务器中继到端点的本地网络地址。

可替代地或附加地，媒体中继服务器的端口是UDP端口，由此，媒体数据通过UDP被引导到多路复用的中继的候选，并且会话标识符请求可以由端点通过TCP被发送到媒体中继服务器。

连接检查可以包括：向每一个候选对分配相应的优先级，其中，多路复用的中继的候选对被分配有比不包括任何服务器网络地址的一个或多个候选对更低的优先级；并且按照优先级顺序检查候选对，直到到达被确定为有效的候选对。

例如，一个或多个候选对可以每个均包括：

端点中的一个的本地网络地址；和/或

反射网络地址，其是可用于端点中的一个的网络地址转换器的公共网络地址。

可替代地或附加地，可以基于分配给每一个候选对的网络地址的类型来分配相应的优先级，每个被分配的类型是包括以下的一组类型中的一个类型：本地类型、反射类型以及多路复用的中继的类型，多路复用的中继的候选被分配有多路复用的中继的类型。可选地，该组类型还可以包括非多路复用的中继的类型。

多路复用的中继的候选对中的其他网络地址可以是：

主机网络地址，其是另一端点本地的公共网络地址；

反射网络地址，其是可用于其他端点的网络地址转换器的公共网络地址；或者

可用于其他端点的另一服务器网络地址。

多路复用的中继的候选对可以包括由以下内容组成的另一多路复用的中继的候选：其他服务器网络地址、与其他服务器网络地址相关联的端口的端口标识符、以及另一分离的唯一的会话标识符。

根据第七方面，一种用于在用户设备和通信网络的另一端点之间经由通信网络来实现媒体会话的计算机设备，包括：网络接口，其被配置为连接到所述通信网络；存储器；处理器，其耦合到所述存储器并且被配置为执行以下操作：在所述存储器中生成一组候选对，每一个所述候选对包括可用于所述计算机设备的相应的网络地址以及通过在计算机设备与响应的端点之间经由网络接口交换网络地址从而可用于其他端点的相应的网络地址，并且使用通过针对一组中的至少一个候选对执行连接检查以确定候选对是否是有效的从而被确定为有效的一组中的候选对经由网络接口来建立媒体会话。该组包括多路复用的中继的候选对，其包括由以下各项形成的多路复用的中继的候选：可用于端点中的至少一个的媒体中继服务器的服务器网络地址、与服务器网络地址相关联的媒体中继服务器的端口的端口标识符、以及独立的唯一的会话标识符，以允许多个媒体流同时经由媒体中继服务器的端口进行中继。

根据第八方面，一种计算机程序产品包括存储在计算机可读存储介质上的代码，并且被配置为在被执行时实现本文中公开的方法步骤或设备(例如，服务器、用户设备)功能中的任何一个。

通常，可使用软件、固件、硬件(例如，固定逻辑电路)或这些实现方式的组合来实现本文中所描述的功能中的任何一个。本文中使用的术语“模块”、“功能”、“组件”以及“逻辑”通常表示软件、固件、硬件或其组合。在软件实现的情况下，模块、功能或逻辑表示在处理器(例如，CPU或多个CPU)上被执行时执行指定任务的程序代码。程序代码可以被存储在一个或多个计算机可读存储设备中。下面描述的技术的特征是独立于平台的，表示这些技术可以被实现在具有各种处理器的各种商业计算平台上。例如，用户设备(用户终端)还可以包括使得用户终端的硬件执行操作的实体(例如软件)，例如处理器功能块等等。例如，用户终端可以包括计算机可读介质，该计算机可读介质可以被配置为维持使得用户终端并且更具体地使得用户终端的操作系统和相关联的硬件执行操作的指令。因此，指令的作用是配置操作系统和相关联的硬件来执行操作，并以这种方式导致操作系统和相关联的硬件的转换以执行功能。指令可以由计算机可读介质通过各种不同的配置提供给用户终端。

计算机可读介质的一种这样的配置是信号承载介质，并因此被配置为将指令(例如作为载波)例如经由网络发送到计算设备。计算机可读介质还可以被配置为计算机可读存储介质，并因此不是信号承载介质。计算机可读存储介质的示例包括随机存取存储器(RAM)、只读存储器(ROM)、光盘、闪速存储器、硬盘存储器以及可以使用磁性、光学和其他技术来存储指令和其他数据的其他存储设备。

尽管已经用特定于结构特征和/或方法动作的语言描述了主题，但是应当理解，在所附权利要求中限定的主题不一定限于上述的具体特征或动作。相反，上述的具体特征和动作被公开作为实施权利要求的示例形式。