在第一端点和第二端点之间生成rtc连接的电信系统和方法
【技术领域】
[0001]本发明包括依照权利要求1的前序部分的用于在第一端点和第二端点之间生成RTC连接的方法，以及依照权利要求1O的对应的电信系统。
【背景技术】
[0002]用于实时通信或RTC的典型的电信系统是基于由IETF(因特网工程任务组)和W3C(万维网联盟)被称为RTCWeb或WebRTC(在本文中将使用术语“WebRTC”来代替任一名称)的标准的多媒体技术，或通常被称为RTC，其中使用多个相似标准化的协议。用于确定最佳RTC有效负荷连接的ICE(交互式连接性建立，RFC 5245)也使用STUN(用于NAT(网络地址转换)会话穿透效用，RFC 5389)协议来运行所谓的“连接性检查”。这些检查确定可疑路由原则上是否可用于所期望的有效负荷连接。
[0003]在VoIP(因特网协议电话)中，实时连接(RTP/RTCP)的端点尽可能直接地被连接到彼此，即没有互相连接的服务器。然而，IPv4地址的缺点导致了在许多情况中NAT或NAPT(网络地址&端口转换)被用在内联网和因特网之间的事实。这使得在不采取特殊手段的情况下不可能建立从因特网到内联网端点的直接联系。这涉及ICE(交互式连接性建立)，其在VoIP示例中与SIP信令协议以及STUN和TURN(STUN的扩展)协议一起工作。由于ICE对可能的连接不要求任何预设置，作为其运行的部分，所有连接候选首先由端点确定并且然后被简单测试(进行/不进行(go/no go)，基于STUN的“连接性检查”)。使用检查列表来完成这些检查。该列表包含所有候选，通过优先级分类(从在顶部的假定最佳连接到在底部的假定最不合适连接(例如经由TURN服务器))。在ICE RFC中描述了用于建立优先级的算法，但是其仅包含不计及(account for)当前网络负载或任何网络干扰的固定规则。
[0004]因为在本说明书中理解标准中描述的各种方案是重要的，因此在下面简要地略述这些方案。依照标准精确地在该(优先级)序列(从顶部到底部)中执行连接性检查，如在图1-3中所示:
图1:直接主机-主机连接
图2:通过NAT连接
图3:使用TURN中继服务器的连接。
[0005]接下来，问题出现了:为什么直接主机-主机连接(见图1)相比于其它两个连接之一应该有可能质量更差。答案在于以下事实:上面说明的方案仅示出了逻辑结构，而没有考虑物理特性。图5(在顶部是逻辑网络视图，以及在下面是两个物理表示)示范了该观念;尽管它在逻辑上是相同的配置，但是通过两个VPN路由器(R1，R2)建立的连接的质量与左边所示(经由以太网)的直接连接显著地不同:通过两个VPN路由器的连接通常具有明显地更差的服务质量值。
[0006]类似地可以在所有方案中使用VPN，而它不为ICE方法所知。因此，在优先级分配中考虑服务质量总是一个好主意。
[0007]然而，目前仅有少数预定义的标准如所述的那样被用于决定最终选择哪个路由用于有效负荷(即，用户数据)。在RTC(实时通信)环境中重要的服务质量方面仍然不经常被考虑O
[0008]目前，利用STUN仅执行“进行/不进行”测试(“连接性检查”，即测试消息是或否进行从发送器到STUN服务器并再返回的完整电路)。特别地，不考虑对于实时应用来说重要的QoS方面。当然，在ICE中对各种替换(被称为候选)分配应该为质量改进(以及如果可适用的话成本减少)做贡献的优先级，但是严格来说各种替换(被称为候选)是基于设想或方针，如在优先化标准的以下示例中所示:
?在IPv4之前的IPv6，即战略方针
?在NAT之前的直接连接(采用无地址转换);这对IP技术是可以的，但是不允许任何QoS声明
?在TURN(中继)之前的NAT; TURN服务器是潜在的带宽瓶颈，并且因此该设想是可理解的，但是可靠的QoS声明还是不可能的。
[0009]在通过前述优先化建立的序列中执行上述STUN连接性检查。然而，STUN或其它QoS相关的标准不影响优先化其自身。
[0010]总之:例如用于WebRTC或SIP系统的标准的IETF ICE规程仅测试针对(ICE)通信端点(客户端、应用服务器)的所提供的RTC有效负荷候选地址对的基本连接性(“STUN连接性检查”)。然而，没有针对考虑各种候选有效负荷路径的QoS特性的功能。
【发明内容】
[0011]本发明意图消除在生成RTC连接时的前述缺点，并意图在将来生成更高效的RTC连接。
[0012]通过如权利要求1中的方法，如权利要求8中的计算机程序产品或计算机程序，如权利要求9中的具有存储在其上的计算机程序的机器可读数据载体以及如权利要求10中的电信系统来实现本目的。
[0013]依照本发明，用于生成在IP网络中的第一端点和第二端点之间的RTC连接的(计算机实现的)方法(其中使用ICE方法的已知的STUN连接性检查规程)按照如下被执行:首先，生成在第一端点和第二端点之间的可能连接路径(甚至所有的可能连接路径)的列表。然后，针对该列表上的可能连接路径(也被称为候选)中的每一个，建立确定针对在STUN过程中的连续连接性检查的序列的相应的优先级，以查看是否可以使用该特定连接路径建立在所述第一端点和所述第二端点之间的连接。其次，依照所确定的优先级建立在所述第一端点和所述第二端点之间的RTC连接，其中系统首先尝试使用具有最高优先级的连接路径建立RTC连接。如果这成功，那么不必有另外步骤。然而，如果出于任何原因其失败，那么系统尝试使用具有下一个最高优先级的连接路径来建立RTC连接。这些尝试遵循所确定的或所建立的优先级序列继续，直到最终建立RTC连接。
[0014]本发明的特征在于，为了建立相应的优先级，不仅应用了现今已知的标准，而且针对每个可能的连接路径确定相应的服务质量值并将该值包括在用于确定该连接路径的优先级的列表中。
[0015]使用该过程意味着，通过使用在相应的服务质量(也被称为QoS)上可用的统计，考虑了有时对实时应用来说是决定性的服务质量或QoS值，使得更高效地建立对应的实时连接或RTC连接成为可能。
[0016]依照本发明在ICE规程(STUN连接性检查)中考虑QoS允许首先测试来自QoS观点的可能的最佳ICE地址对。因此可以避免不必要的并且耗费时间的STUN连接性检查，这导致更短的实时连接建立时间、更少的网络负载以及选择具有最佳Qo S特性(相比于替换)的I CE候选对(连接路径)。
[0017]依照发明的方法的一个有利版本，第一端点还通过使用STUN消息将针对在第一端点和第二端点之间的可能连接路径的服务质量值传输到其它端点。因为在这里术语“第一端点”不意图指示对任何特定的端点的限制，因此所有端点都将关于服务质量值的知识传输到其余的端点。换言之，在STUN消息中来回交换针对每个可能连接路径(也称为ICE候选对)的QoS数据。以这种方式，每个端点将来自其伙伴的对应的信息添加到其自己的QoS统计。不仅是针对先前的“真实”连接的QoS数据，还有针对要发出的当前呼叫(其也可以被称作RTC连接)所执行的连接性检查的结果，将被包括在当前ICE候选选择中。经由STUN连接性检查交换的QoS数据也被集成在用于ICE端点的QoS统计数据