[发明专利]在第一端点和第二端点之间生成RTC连接的电信系统和方法

说明书

本发明涉及用于使用ICE STUN连接性检查规程在IP网络中的第一端点（EP1）和第二端点（EP2）之间生成RTC连接的方法和电信系统，所述规程包括以下步骤：‑ 生成在所述第一端点（EP1）和所述第二端点（EP2）之间的可能连接路径的列表，‑ 针对包括在所述列表中的每个可能连接路径建立相应的优先级，以及‑ 生成在所述第一端点（EP1）和所述第二端点（EP2）之间的RTC连接，其中‑ 首先存在使用最高优先级的连接路径生成RTC连接的尝试，‑ 并且如果这不可能，然后系统尝试使用具有下一最高优先级的连接路径来建立RTC连接，直到实际建立了RTC连接，其特征在于，针对每个可能的连接路径，确定其各自的服务质量值，并且当在所述列表上建立其优先级时考虑所述服务质量值。

技术领域

本发明包括依照权利要求1的前序部分的用于在第一端点和第二端点之间生成RTC连接的方法，以及依照权利要求10的对应的电信系统。

背景技术

用于实时通信或RTC的典型的电信系统是基于由IETF（因特网工程任务组）和W3C（万维网联盟）被称为RTCWeb或WebRTC（在本文中将使用术语“WebRTC”来代替任一名称）的标准的多媒体技术，或通常被称为RTC，其中使用多个相似标准化的协议。用于确定最佳RTC有效负荷连接的ICE（交互式连接性建立，RFC 5245）也使用STUN（用于NAT（网络地址转换）会话穿透效用，RFC 5389）协议来运行所谓的“连接性检查”。这些检查确定可疑路由原则上是否可用于所期望的有效负荷连接。

在VoIP（因特网协议电话）中，实时连接（RTP/RTCP）的端点尽可能直接地被连接到彼此，即没有互相连接的服务器。然而，IPv4地址的缺点导致了在许多情况中NAT或NAPT（网络地址端口转换）被用在内联网和因特网之间的事实。这使得在不采取特殊手段的情况下不可能建立从因特网到内联网端点的直接联系。这涉及ICE（交互式连接性建立），其在VoIP示例中与SIP信令协议以及STUN和TURN（STUN的扩展）协议一起工作。由于ICE对可能的连接不要求任何预设置，作为其运行的部分，所有连接候选首先由端点确定并且然后被简单测试（进行/不进行（go/no go），基于STUN的“连接性检查”）。使用检查列表来完成这些检查。该列表包含所有候选，通过优先级分类（从在顶部的假定最佳连接到在底部的假定最不合适连接（例如经由TURN服务器））。在ICE RFC中描述了用于建立优先级的算法，但是其仅包含不计及（account for）当前网络负载或任何网络干扰的固定规则。

因为在本说明书中理解标准中描述的各种方案是重要的，因此在下面简要地略述这些方案。依照标准精确地在该（优先级）序列（从顶部到底部）中执行连接性检查，如在图1-3中所示：

图1：直接主机-主机连接

图2：通过NAT连接

图3：使用TURN中继服务器的连接。

接下来，问题出现了：为什么直接主机-主机连接（见图1）相比于其它两个连接之一应该有可能质量更差。答案在于以下事实：上面说明的方案仅示出了逻辑结构，而没有考虑物理特性。图5（在顶部是逻辑网络视图，以及在下面是两个物理表示）示范了该观念；尽管它在逻辑上是相同的配置，但是通过两个VPN路由器（R1，R2）建立的连接的质量与左边所示（经由以太网）的直接连接显著地不同：通过两个VPN路由器的连接通常具有明显地更差的服务质量值。

类似地可以在所有方案中使用VPN，而它不为ICE方法所知。因此，在优先级分配中考虑服务质量总是一个好主意。

然而，目前仅有少数预定义的标准如所述的那样被用于决定最终选择哪个路由用于有效负荷（即，用户数据）。在RTC（实时通信）环境中重要的服务质量方面仍然不经常被考虑。