用于通过业务质量敏感的网络传输具有不同媒体类型的媒体数据的方法和电信装置

摘要

本发明涉及用于通过使用实时协议（RTP）的、业务质量敏感的网络（N1）将媒体数据从第一RTC客户端（30）传输给第二RTC客户端（40）的电信装置（10）和计算机实现的方法，其中业务质量基于不同的流量类别，并且媒体数据包含具有第一流量类别（QoS1）的第一媒体类型和具有第二流量类别（QoS2）的第二媒体类型，所述方法包括以下步骤：?媒体数据由第一RTC客户端（30）捆绑成第二包（P2），所述媒体数据包含具有第一流量类别（QoS1）的第一媒体类型和具有第二流量类别（QoS2）的第二媒体类型，?在每个第二包（P2）中，在实时协议（RTP）的层4和/或层5中对每个媒体类型的流量类别（QoS1、QoS2）进行标记，?在朝向第二RTC客户端（40）的方向上传输第二包（P2），?在过渡到网络（N1）中时或者之前，在使用在实时协议（RTP）的层4和/或层5中的标记的情况下对第二包（P2）解除捆绑，并且捆绑成第一包（P1），所述第一包（P1）中的每个仅具有流量类别（QoS1、QoS2）中的唯一一个，和?通过所述网络（N1）将第一包（P1）传输给第二RTC客户端（40）。

说明书

用于VoIP（因特网协议语音（VoiceoverInternetProtocol））或者IP视频（VideooverIP）的实时通信构成在现有的IP网络架构上的网络覆盖（Netzwerk-Overlay）。实时通信对于包丢失和包传送延迟（尤其包丢失、延时、抖动）是敏感的，并且因此可能损害用户体验（体验质量（Quality-of-Experience）QoE）。

在具有“经典的L2/L3-Qos支持”的IP网络中，流量类别（QoS，QualityofService(业务质量)）被区分，并且在传送层2（层2、L2）和传送层3（层3、L3）上被标记。所述标记能够实现：在转发时对L2/L3-Qos支持的网络（在本发明中被称作业务质量敏感的网络）中的网络组件应用不同的优先级（逐跳行为（Per-hopBehaviour）-PHB）(IEEE802.1p/DiffServ)。PHB的应用逐包地基于上述的标记进行。所述标记的分派可以要么在媒体终点自身（内部）中进行，要么借助于识别到的（媒体）数据流在外部通过网络元件进行。迄今各一个自身的端口号被分配给了这样的（媒体）数据流（流）中的每个，因此这里唯一性已经占主导地位。在此，术语“业务质量敏感的”意味着：PHB对于每个包和在每个节点中被实施，并且也已知为“QoS感知的（Qos-aware）”。用于音频和视频数据的数据流典型地由一系列IP/UDP包组成，所述IP/UDP包包含作为有效数据的一系列实时协议（RTP）协议元素。

虽然诸如音频、视频、屏幕共享、数据或者还有游戏（Gaming）的流量种类通过相同的端口或者甚至在相同的流之内混合在协议技术上是可能的，但是迄今为止未被使用并且因此迄今不被交换机（L2）和路由器（L3）支持。

在此情况下需要区分两种情况：

1.相同媒体类型的不同的流分享相同的端口号（端口复用）；

优点：在服务器中和在与端口有关的网关处的管理耗费被减少。

2.作为业务组件的不同的媒体类型在同一个IP包中被传输（除了端口复用之外，IP包之内的业务复用）；

优点：因为对于多个RTP协议元素仅需要一个IP头部（较小的协议开销），所以除了1以外得出端口管理耗费的进一步的减少和减少的带宽需求。

在两种情况中，从端口到业务组件的可分配性（Zuordenbarkeit）的开头提及的唯一性或者媒体类型丢失。

在第一种情况中，虽然在层面L2和L3上的内部标记和分析的所描述的途径尚起作用，然而外部标记的可能性由于端口号被取消。

在第二种情况中，因为IP包仅能承载一个标记，但是不同的流和不同的媒体类型的部分（可能）位于一个IP包之内，所述部分大多需要不同的标记值，所以具有标记的经典技术也不再有效（greifen）。

例如直接从因特网/网络浏览器（Web-Browsern）中（实时和非实时地）传送媒体数据、诸如在当前的WebRTC（也已知为RTCWeb）标准化方案（例如用于Firefox（火狐）、GoogleChrome（谷歌浏览器）......）中是新的、恰好处于定义中的技术。

在开头描述的“经典的Qos支持”中所选择的从端口到流的分配在多媒体应用的情况下导致提高的管理和实现耗费，并且刚好在克服NAT（网络地址转换（NetworkAddressTranslation））和防火墙的情况下并且这里特别地在所追求的大众市场（例如谷歌云业务）中是不可忽略的障碍。因此，应当减轻WebRTC的单独连接管理和从而不同端口关联（Portassoziationen），这应当通过“端口复用”和/或“业务复用”被实现。

应当假定，在WebRTC技术被标准化并且广泛地应用之后，L2/L3网络元件也应当被配备WebRTC符合的QoS处理。但是所述过渡（迁移（Migration））按照预期越过非常长的时间间隔持续，并且仅逐渐地进行。经典的QoS支持的引入和执行同样是已经持续了很多年并且仍然远远未彻底结束的过程。

因此在引入WebRTC（在Web上的实时通信（RTC））情况下将得出提供针对现有的网络架构的过渡/迁移解决方案的紧迫需求。

目前，所述问题在WebRTC情况下未解决。尽管存在关于SCTP（流控制传输协议（StreamControlTransmissionProtocol））的工作，然而所述解决方案在这里所考察的UDP/RTP环境中不能用（tragen）。

可以在没有端口复用的情况下应用WebRTC（诸如在SIP情况下）。然而由此基本的复用优点（如上所述）既不能在服务器侧（例如在基于云的装置情况下）也不能在网关（防火墙/NAT）处被使用。

本发明所基于的任务是，在RTC环境（目前尤其WebRTC环境）中，可以高效地并且也通过现存的业务质量敏感的网络来传输具有不同媒体类型的媒体数据。

所述任务利用按照权利要求1的计算机实现的方法以及按照权利要求9的电信装置解决。按照本发明的方法可以借助于同样属于本发明的按照权利要求7的计算机程序或者计算机程序产品被实现。机器可读的数据载体也是本发明的主题，所述数据载体具有存储在所述数据载体上的按照权利要求7的计算机程序产品。

本发明的有利的改进方案是从属权利要求的主题。

以下为了描述本发明在不限制一般性的情况下认为：RTC客户端被构造为WebRTC客户端。但是也可以是经修改的SIP客户端。按照本发明，在通过使用实时协议（RTP）的、业务质量敏感的网络将媒体数据从（例如位于网络中）第一WebRTC客户端传输到（位于相同的或者第二网络中）第二WebRTC客户端时可以以以下方式进行，其中应该指出，业务质量基于不同的流量类别，并且媒体数据（至少）包含具有第一流量类别的第一媒体类型和具有第二流量类别的第二类型：具有这里示例性假定的第一流量类别和第二流量类别的不同媒体类型的媒体数据首先由第一WebRTC客户端捆绑成所谓的“第二”包。所述捆绑也已知为“业务复用”。换句话说，因此在IP包中可以存在具有混合业务类别（例如一方面语音或者话音和另一方面视频）的内容的UDP/RTP包（UDP=用户数据报协议（UserDatagramProtocol））。在此，在所述两个包中的每个中，每种媒体类型的流量类别在RTP协议的层4和/或层5上被标记。这是所谓的QoS标记。由此，唯一的UDP/RTP包的RTP音频或者视频包内容可以利用分别不同的QoS值被标记。所述包于是可以在朝向第二WebRTC客户端的方向上被传输。但是为了可以通过业务质量敏感的第一网络传输媒体数据，所述第二包必须事先被转换，其中所述第一网络不考虑并且也不“理解”RTP协议的层4和/或层5上的按照本发明的新的标记。也就是换句话说，要么在从第二网络过渡（übergang）到第二网络中之前，要么在所述过渡过程中，第二包在使用RTP协议的层4中和/或层5中的标记的情况下首先被解除捆绑（解除捆绑=解复用）并且重新被捆绑成所谓的“第一”包，“第一”包中的每个仅具有流量类别中的唯一一个。也就是说，第一包被构成，所述第一包例如（必要时交替地）要么仅包含话音数据要么仅包含视频数据。在第一包可以在第一业务质量敏感的网络中被传输之前，所述分类或者重新的复用或者捆绑必须在此已经实现。换句话说，这意味着：所述过程还在必要时在非业务质量敏感的第二网络之后在进入第一网络中时必须立即进行或者必要时必须在业务质量敏感的第三网络中在发送方向上在其第一路由器之前进行。随后，第一包然后可以通过第一网络和必要时其他的转接网络被传输给第二WebRTC客户端（所述第二WebRTC客户端例如位于第三网络中）。

按照本发明能够实现路由器能力：（例如通过（深度）包检测（(Deep)PacketInspection））理解层4和/或层5中的标记，对每个所接收的UDP/RTP包解除捆绑，也即用各自的话音数据、视频数据等划分，并且输送为此所设置的单独的路由器等候队列（队列（Queue））。在路由器然后将数据转发给所追求的目标之前，进行重新的捆绑或者复用。

概括地说，对于按照本发明的方法应主张的是，即使由RTC客户端在捆绑的或者复用的IP/UDP包中包含不同业务种类(例如语音、视频)的有效数据，通过WebRTC端口复用也可以包含VoIP/IP视频和QoS的已知原理（也即存在路由器等候队列，其中以不同优先级对不同业务进行处理）。由此避免，话音路由器等候队列例如被视频数据堵塞。因此在路由器等候队列中的其他的话音连接不再消极地被影响。

要强调的是，上述方法原则上例如可以在IPv4、IPv6（因特网协议版本4或者版本6）下被使用。

上述方法的变型方案在于，路由器承担所述解除捆绑。按照另一变型方案，接在路由器之前的代理可以代替路由器承担所述解除捆绑的任务。

上述方法的另一变型方案在于，在网络边界之前或之后的从非业务质量敏感的网络到业务质量敏感的网络的网关装置（网关）中，可以对第二包解除捆绑并且捆绑成第一包。

按照本发明的一种有利的实施方式，L4/L5标记在第二包情况下以IPv4格式借助于RTP协议元素的头部的符合标准的、一般性扩展进行。

按照本发明的一种有利的改进方案，标记在IPv6的情况下借助于第二包的头部的扩展进行，其中所述扩展尤其包括出现的标记的列表。因此例如自身的IPv6扩展头部的定义尤其适合于IPv6，所述IPv6扩展头部包含所包含的RTP协议元素的QoS值的概括性列表和其偏移量（Offset）（IP包的内容）。对于必须利用L4/L5标记工作的设备，这带来动态的优点：所述值不必在IP包中在任何地方分散地（作为在其中包含的RTP协议元素的组成部分）被搜索，而是可以访问在IP层面上的特别为此表明的部分中的这些值。所述变型方案因此特别适合于非常高效的和快速的、例如也以硬件实现的L4/L5-QoS处理。此外，这样的头部扩展的设置提供优点：这可以借助于包的头部的扩展的反正已经存在的或者已知的方法被实施。

如果在所述第二包中的标记被改变成在RTP协议的层4中和/或层5中的存在的标记的指示，可以是有利的，其中所述标记在层2（数据链路层、例如以太网）和/或者在层3（交换层、IP头部）中存在并且与在RTP协议元素中包含的媒体类型的各自的流量类别有关。在该基础上，于是复用的混合包可以被发送给代理，所述代理承担到单连接的划分（例如语音、视频）。代理然后将第一包转发给目标域中的对等实体（例如代理B）。处于其间的路由器因此仅看到虚拟连接之内的各个正规的语音或者视频包（或者均匀流），所述语音或者视频包可以根据其流量类别（语音、视频、......）被处理或者转发。

按照本发明方法的另一有利的实施方式，在信令情况下协商，端口复用和/或业务复用是否被实施。原则上，也即例如在WebRTC范围内扩展的SDP提议/应答（Offer/Answer）协议不强制使用端口复用和/或业务复用，这换句话说意味着，端口复用和/或业务复用在WebRTC的情况下也是可选的。因此，本发明的可替代的解决方案在于，两个WebRTC端点作为信令的部分协商：端口复用和/或业务复用是否应当被实施。如果例如在网络已知：WebRTC和QoS不适用于端口复用和/或业务复用，那么端口复用可以通过这样的信令协商被抑制。

此外可以是有利的是，按照本发明在层4和/或层5中被标记的第二包利用DSCP值（DSCP=差分业务代码点（DifferentiatedServciesCodepoint））被标记，所述DSCP值对应于所包含的RTP协议元素的“最差的”值。在例如音频/视频的示例中，这可能是所谓的保证转发（AFxx）代码点（AssuredForwardingCodepoint）之一，以便所述包绝对不可能陷入与纯话音连接的冲突，所述话音连接按标准被分配给所谓的加速转发（ExpeditedForwarding,EF）DSCP代码点。因此，这样的IP包也可以在具有经典的QoS处理的网络中以至少最小QoS特性被输送，但是尽管如此至少不消极地影响非常关键的话音连接。

与例如机器可读的数据载体一样，实现按照本发明的上述方法的计算机程序或者计算机程序产品也可看作属于本发明，这样的计算机程序被存储在所述数据载体上。

本发明所基于的任务也利用按照权利要求9的电信装置解决，所述电信装置包含（例如位于非业务质量敏感的第二网络中）第一WebRTC客户端、（例如在业务质量敏感的第三网络中的）第二WebRTC客户端和（必要时与第二和第三网络连接的）业务质量敏感的第一网络（和可能其他的转接网络），所述第一网络使用实时协议。在简单的装置中，两个WebRTC客户端也可以位于至少部分地是业务质量敏感的网络内。按照本发明，标记单元被设置，所述标记单元实施按照上述权利要求1至7之一的方法。所述标记单元可以例如包括处理器，上述的方法可以在所述处理器上运行，或者所述标记单元也可以被铸造在硬件中。

有利地，标记单元被分配给网关装置、代理而或者路由器/L3交换机或者集成在这样的设备中，其中利用所述网关装置能够实现从第二网络到第一网络的过渡。

因为按照本发明的方法和按照本发明的电信装置相互紧密关联，所以结合所述方法所描述的特征和优点以类似的方式也在电信装置情况下适用并且反之亦然，即使这未详尽地予以说明。

本发明的其他优点、特征和特点由参考附图对有利的实施方式的以下描述得出。其中：

图1示意性地示出按照本发明的本发明电信装置，所述电信装置适用于实施按照本发明的方法，并且应当根据所述电信装置下述描述按照本发明的方法；和

图2示出具有IP和UDP包以及RTP协议元素的MAC帧的结构。

图2示出具有嵌入其中的IP包51和UDP包52的MAC帧50（例如以太网）。MAC帧50在其MAC头部中包含L2-QoS标记。IP包51在其IP头部中包含L3-QoS标记。UDP有效数据53借助于业务复用包含RTP协议元素54和55（如示例性地根据业务“视频”54和“音频”55示出）。每个所述RTP协议的头部按照本发明承载L4/L5-QoS标记，如之后详细地阐述的。

图1示意性地示出按照本发明的本发明电信装置，所述电信装置适用于实施按照本发明的方法，并且应当根据所述电信装置下述地描述按照本发明的方法。

按照本发明的、示意性地示出的电信装置10（一般化地然而非限制地）包括三个网络。在第一网络N1中，这里作为示例示出WebRTC服务器25和两个路由器23，所述WebRTC服务器25和两个路由器23通过业务质量敏感的（基于不同的流量类别的）连接彼此接触。因此，整个网络N1是业务质量敏感的网络。此外，网络N2被设置，其中设置接入路由器32、“正规”路由器33、交换机34、WebRTC服务器35、笔记本电脑和记事本（Notepad），其中WebRTC浏览器36在笔记本电脑上运行，WebRTC浏览器30在所述记事本上运行。WebRTC浏览器30这里应当用作WebRTC客户端的示例，所述WebRTC客户端想要发出具有不同流量类别QoS1和QoS2的媒体数据。WebRTC客户端30通过WLAN与路由器33连接，所述路由器33又与接入路由器32连接。所有这些连接应当以示例性方式是非业务质量敏感的。标记单元QMP被分配给接入路由器32，所述标记单元QMP的功能之后被说明。

本发明电信装置10此外在该示例中包括第三网络N3，所述第三网络N3包括：接入路由器42（所述接入路由器42用作网关装置）、路由器43、交换机44、WebRTC服务器45、笔记本电脑和记事本，其中WebRTC浏览器46在所述笔记本电脑上运行，WebRTC浏览器40在记事本上运行。WebRTC浏览器40这里应当用作第二WebRTC客户端的示例。与在网络N2的情况下不同，标记单元QMP在网络N3中被分配给路由器43。在路由器43和接入路由器42之间的以及与WebRTC服务器45的连接是“经典的”业务质量敏感的连接，而剩余的连接是具有端口/业务复用的这样的连接（如在网络N2中的连接）。

现在应当假定，第一WebRTC客户端30想将具有QoS值QoS1的话音数据以及具有QoS值QoS2的视频数据传送给第二WebRTC客户端40，并且为此想要使用业务质量敏感的网络N1的业务。对此，第一WebRTC客户端30将不同的数据根据事务（Anfall）打包成多个第二包P2，这也可以被称作捆绑或者复用。对于每个所使用的流量类别（其中也可能存在多于两个上面提及的流量类别），第一WebRTC客户端在实时协议的层4中和/或层5中设置相应的标记。所述包P2被传送给路由器33，并且由所述路由器33转发给接入路由器32。标记单元QMP被分配给接入路由器32，由所述接入路由器32可以假定：所述接入路由器32可以解释包头部中的指示和/或在IPv6包的扩展中的标记或者RTP协议元素的头部之内的层4/层5标记的扩展，所述标记单元QMP将混合的数据包P2解除捆绑或者解复用，并且构成新的第一包P1，所述第一包P1是“种类纯的”，也即仅具有唯一的QoS流量类别的RTP协议元素。一旦这样的第一包P1从接入路由器32被移交给了网络N1，并且例如被转发给了路由器23，所述第一包P1就可以由所述网络N1传输。在各个设备之间的各自的连接处说明：哪种种类的包（包P1或者包P2）被输送。包P1然后被传送给网络N3中的接入路由器42，并且从接入路由器42被传送给路由器43。同样，标记单元QMP被分配给路由器43，所述标记单元QMP将数据包P1解除捆绑，并且再次重构最初存在的数据包2，其方式是：所述标记单元QMP等待确定数量的包P1的到达，并且从所述包P1将具有不同媒体类型的相应的媒体数据再次组合或者捆绑成新的第二数据包P2。所述新的数据包P2然后被传输给第二WebRTC客户端40。

在按照本发明所构造的目标路由器43中，该目标路由器32因此根据与IP包计数器对应的预先定义的滑动窗预期分类的UDP/IP包P1，因为通过在网络N1中为了转接包P1不同地应用的PHB可以完全地发生包摆渡（Paketüberholungen）。在窗内所接收的UDP/IP包根据RTP段计数器如最初接收的那样被重构，并且在业务捆绑的RTP/UDP/IP包被转发给WebRTC客户端40之前，用于所述业务捆绑的RTP/UDP/IP包的标准化的或者在网络N3中有效的DSCP代码点被占据。

在当今当前的或者已知的业务质量敏感的网络中，按照本发明的步骤必须在路由之前在网络中进行：这典型地结合路由器发生，所述路由器连接总网络的分布层。与之相反，如果仅网络N1是业务质量敏感的，那么这将会结合相应的接入路由器进行。在此，在层4和/或5中的标记的按照本发明的功能性可以在网关的两侧之一处被提供。

按照RFC3350的RTP协议元素允许使用RTP头部扩展。在RTP头部中显示所述存在。RTP头部扩展包含简档标识（Profilkennzeichnung），所述简档标识按照本发明必须被确定。长度说明应当利用至少1显示各自媒体类型的DSCP代码点（8比特）的和可选地在随后的32比特字中的组合式IP包/RTP协议元素计数器的存在。在剩余的24比特中，IP包计数器和RTP协议元素计数器（具有溢出）可以被编码，所述IP包计数器和RTP协议元素计数器在提供给第二WebRTC客户端之前能够实现最初的第二包的可选的重建。按照本发明的标记单元（所述标记单元例如被分配给路由器或者代理）现在对各个RTP段进行分段、计数并且改写运行的IP包号和RTP协议元素在RTP头部扩展中的UPD/IP包内的位置，其中所述标记单元已经终止起始分布网络段并且识别出具有业务复用的RTP/UDP/IP数据流。有利地，路由器将具有相同的DSCP代码点的RTP协议元素积聚到重新组合的RTP/UDP/IP包中，并且在包被转发之前，根据RTP头部扩展改写UDP/IP头部的DSCP代码点。

在本发明的示例性实施方式的上述描述中认为，仅一个业务质量敏感的网络N1可供使用，以便将媒体数据从（非业务质量敏感的网络N2的）第一WebRTC客户端传送给（业务质量敏感的网络N3的）第二WebRTC客户端。这对应于为了描述所选择的示意性网络配置。在图1中示出的配置中的网络N3也适用于实施按照本发明的方法。

应主张的是，本发明的参考所示出的实施方式描述的特征、诸如各个设备或者装置以及各个方法步骤和其顺序的种类和构型在其他的实施方式情况下也可以存在，除非另有说明或者出于技术原因这本身就是不可能的。

附图标记列表

10=电信装置

23=路由器

25=WebRTC服务器

30=第一WebRTC客户端

32=接入路由器/网关装置

33=路由器

34=交换机

35=WebRTC服务器

36=WebRTC浏览器

40=第二WebRTC客户端

42=接入路由器/网关装置

43=路由器

44=交换机

45=WebRTC服务器

46=WebRTC浏览器

50=MAC帧

51=IP包

52=UDP包

53=有效数据

54=视频数据

55=音频数据

90=数据载体

92=计算机程序产品

N1=用于传输的业务质量敏感的网络

N2=第二网络

N3=第三网络

QMP=标记单元

QoS=流量类别（业务质量）。