CN107534520A - 用于多个序列流的集束前向纠错(fec) - Google Patents

Abstract

各种实施例实现“集束FEC保护”，其中可使用单个修复流来为多个个体源RTP流提供恢复保护。各实施例技术可以利用新颖的FEC源有效载荷和修复有效载荷的定义，这些定义使得能够为多个RTP流定义单个修复流。例如，由于FEC FRAME Raptor代码选项目前不涉及在多个实时传输协议(RTP)同步源(SSRC)上的多种媒体类型的集束保护的情况，所以可使用RTP流报头扩展来允许单个FEC RTP流被配置为向多个源RTP流提供冗余，而不管其内容类型(例如，音频或视频)。基于此类扩展，各实施例技术允许对各自具有唯一序列号空间的多个源RTP流的保护。

Description

用于多个序列流的集束前向纠错(FEC)

相关申请

本申请要求于2015年5月1日提交的题为“Bundled Forward Flow ErrorCorrection(FEC)for Multiple Sequenced Flows(用于多个序列流的集束前向纠错(FEC))”的美国临时申请No.62/155,639的优先权权益，其全部内容通过援引纳入于此。

背景技术

前向纠错(FEC)是一种为在通信链路上发送的数据提供可靠性的机制。使用常规FEC技术，由于数据通信本身可包括适合于恢复通信的丢失或其他不可访问的部分(或分组)的冗余的编码信息，所以可能对重传协议的依赖性更小，以确保数据通信的可靠性。存在用于任意流送协议的FEC框架，诸如由因特网工程任务组的FEC框架(称为“FEC FRAME”)所定义的。具体而言，FEC FRAME能够提供一些用于与序列协议联用的FEC功能性，诸如利用RTP流的每个分组的序列号(即分组标识符(“ID”))的实时协议(RTP)。用于流送的这种FEC可利用各种标准化的FEC码，诸如Reed-Solomon、Raptor、RaptorQ和低密度奇偶校验码(LDPC)。

概述

各种实施例包括用于扩展前向纠错(FEC)以使用单个FEC RTP流来保护多个实时协议(RTP)流的方法和计算设备。各种实施例可包括经由发送方计算设备的处理器与接收方计算设备交换会话初始化数据，经由处理器生成用于多个源RTP流的源RTP流数据，经由处理器生成用于与多个源RTP流对应的FEC RTP流的FEC RTP流数据，以及将多个源RTP流和FEC RTP流传送到接收方计算设备。一些实施例可进一步包括经由处理器调整多个源RTP流中的每个源RTP流的报头扩展以包括源FEC有效载荷标识符(ID)。一些实施例可进一步包括经由处理器调整FEC RTP流以包括修复FEC有效载荷标识符(ID)。

一些实施例可进一步包括经由处理器构建用于多个源RTP流的FEC RTP流的修复块，其中该修复块至少包括每个源RTP流的流标识符、长度指示符和s值，并且经由处理器将FEC RTP流的有效载荷格式注册为集束媒体类型。

在一些实施例中，多个源RTP流中的每个源RTP流是音频流和视频流中的一者。在一些实施例中，会话初始化数据包括会话描述协议(SDP)数据。

各种实施例可包括经由接收方计算设备的处理器接收来自发送方计算设备的多个源RTP流和FEC RTP流，经由处理器确定是否从多个源RTP流中的任何源RTP流丢失任何源块数据，以及响应于确定存在丢失的源块数据，经由处理器从FEC RTP流的修复块中检索丢失的源块数据，以及经由处理器使用多个源RTP流的数据。在一些实施例中，多个源RTP流中的每个源RTP流是音频流和视频流中的一者。

进一步的实施例包括发送方计算设备，包括收发机和配置有处理器可执行指令的处理器，指令用以执行上面总结的用于生成多个源RTP流和FEC RTP流并将它们传送到接收方计算设备的方法的操作。

进一步的实施例包括接收方计算设备，包括收发机和配置有处理器可执行指令的处理器，指令用以执行上面总结的从传送方计算设备接收多个源RTP流和FEC RTP流并对它们进行处理的方法的操作。

附图简述

纳入本文且构成本说明书一部分的附图解说了权利要求书的各种实施例，并与以上给出的概括描述和下面给出的详细描述一起用来解释权利要求书的特征。

图1A-1B是解说计算设备之间的常规RTP流交换的示图。

图2是解说根据一些实施例的与多个源RTP流一起传送的集束FEC RTP流的示图。

图3A是解说用于供计算设备交换具有报头扩展的源RTP流连同集束FEC RTP流的实施例方法的处理流程图。

图3B是适用于一些实施例中的指示与具有报头扩展的源RTP流对应的集束FECRTP流的SDP数据的示图。

图4A是解说用于供计算设备交换具有集束FEC RTP流的RTP流的实施例方法的处理流程图。

图4B是适用于一些实施例中的FEC有效载荷的示图。

图4C是适用于一些实施例中的指示与源RTP流对应的集束FEC RTP流的SDP数据的示图。

图5A是解说用于供发送方计算设备传送具有各种配置的集束FEC RTP流的RTP流的实施例方法的处理流程图。

图5B是解说用于供接收方计算设备接收具有各种配置的集束FEC RTP流的RTP流的实施例方法的处理流程图。

图6是适用于一些实施例中的移动计算设备的组件框图。

图7是适用于一些实施例中的服务器计算设备的组件框图。

详细描述

将参照附图详细描述各种实施例。在可能之处，相同附图标记将贯穿附图用于指代相同或类似部分。对特定示例和实现作出的引述用于解说性目的，而无意限定权利要求的范围。

术语“计算设备”在此用于指配备至少一个处理器的电子设备。计算设备的示例可包括移动设备(例如，蜂窝电话、可穿戴设备、智能电话、上网板、平板计算机、启用因特网的蜂窝电话、启用的电子设备、个人数据助理(PDA)、膝上型计算机等)、个人计算机、和服务器计算设备。在各种实施例中，计算设备可以配置有存储器或存储以及联网能力，诸如被配置成建立广域网(WAN)连接(例如，蜂窝网络连接等)和/或局域网(LAN)连接(例如，经由路由器的到因特网的有线/无线连接等)的网络收发机和天线。适用于各种实施例的移动计算设备在下文参照图6描述。

术语“服务器”用于指代能够用作服务器的任何计算设备，诸如主交换服务器、web服务器、邮件服务器、文档服务器以及配置有用于执行服务器功能的软件的个人或移动计算设备(例如，“轻量级服务器”)。服务器可以是专用计算设备或包括服务器模块的计算设备(例如，运行可导致计算设备作为服务器来工作的应用)。服务器模块(或服务器应用)可以是全功能服务器模块或轻量级或副服务器模块(例如，轻量级或副服务器应用)。轻量级服务器或副服务器可以是服务器型功能性的精简版，其可以在个人或移动计算设备(诸如，智能电话)上实现，由此使得其能够在诸如用于提供本文描述的功能性所必需的有限程度上用作因特网服务器(例如，企业电子邮件服务器)。适用于各种实施例的服务器在下文参照图7描述。

术语“源流(stream)”或“源RTP流”或“源流(flow)”在本文中被可互换地使用，是指包括各种数据源块的数据流。源流的示例可包括可用于提供在计算设备之间通过联网连接(例如，因特网、P2P等)传送的流送媒体服务(例如，流送电影、无线电等)和/或电话通信(例如，因特网协议(IP)音频/视频聊天)的音频和视频数据流。术语“修复流(stream)”或“FEC RTP流”或“修复流(flow)”或“FEC流”在本文中被可互换地使用，是指包括与源流对应的冗余数据的数据流。例如，FEC流可包括可由接收方设备用来修复、替换或以其他方式补偿源流的缺失、丢失和/或损坏的数据的各种修复块。

本申请的各实施例技术涉及与实时协议(RTP)数据流相关的前向纠错(FEC)的新颖性改进，并由此对各种常规的或标准的FEC和/或RTP概念进行改进。因此，在下面的描述中，可参考在以下文献中描述或相关的各种概念(例如，规范、格式、标准)：2005年12月的因特网工程任务组(IETF)请求评论(RFC)文档4288，题为“Media Type Specifications andRegistration Procedures(媒体类型规格和注册规程)”(“RFC4288”)；2007年2月的因特网工程任务组(IETF)请求评论(RFC)文档4855，题为“Media Type Registration of RTPPayload Formats(RTP有效载荷格式的媒体类型注册)”(“RFC4855”)；2007年10月的因特网工程任务组(IETF)请求意见(RFC)文档5053，题为“Raptor Forward Error CorrectionScheme for Object Delivery(用于对象传递的Raptor前向纠错方案)”(“RFC5053”)；2008年7月的因特网工程任务组(IETF)请求评论(RFC)文档5285，题为“A General Mechanismfor RTP Header Extensions(用于RTP报头扩展的一般机制)”(“RFC5285”)；2011年8月的因特网工程任务组(IETF)请求评论(RFC)文档6330，题为“RaptorQ Forward ErrorCorrection Scheme for Object Delivery(用于对象传递的RaptorQ前向纠错方案)”(“RFC6330”)；2011年10月的因特网工程任务组(IETF)请求评论(RFC)文档6363，题为“Forward Error Correction(FEC)Framework(前向纠错(FEC)框架)”(“RFC6363”)；2011年10月的因特网工程任务组(IETF)请求评论(RFC)文档6364，题为“Session DescriptionProtocol Elements for the Forward Error Correction(FEC)Framework(用于前向纠错(FEC)框架的会话描述协议元素)”(“RFC6364”)；2012年8月的因特网工程任务组(IETF)请求评论(RFC)文档6681，题为“Raptor Forward Error Correction(FEC)Schemes forFECFRAME(用于FECFRAME的Raptor前向纠错(FEC)方案)”(“RFC6681”)；以及2012年8月的因特网工程任务组(IETF)请求评论(RFC)文档6682，题为“RTP Payload Format for RaptorForward Error Correction(FEC)(用于Raptor前向纠错(FEC)的RTP有效载荷格式)”(“RFC6682”)。

一般而言，为了防止RTP流中的分组丢失，实现常规FEC技术的计算设备可将源流划分为数据源块，该划分可随着源流变得可用而在运行中完成。计算设备可基于源块数据生成包括源块的数据和FEC修复信息的编码块，以提供防止分组丢失的保护。该编码块可在与源流相对应的修复流中传送，使得当源流中存在一些分组丢失时，接收方设备可潜在地恢复源块。通常，利用较小的源块的FEC流送技术可导致更好的端到端等待时间，因为较小的源块减少了用于编码块的编码数据量。然而，具有较小源块的错误恢复潜能是有限的。对于较大的源块，FEC流送技术可具有更好的恢复性能，但需要更多的带宽。一般而言，多个RTP流可能不受青睐，因为太多的RTP流可能被防火墙阻止、需要大量带宽，或者以其他方式被宽带网络禁止。

FEC FRAME提供了允许支持序列数据流(诸如RTP流(即，源RTP流))的特定代码选项。在此类情况下，发送方计算设备可在无修改的情况下发送源RTP流，并且还可发送与源RTP流相关联的单独修复FEC RTP流，该单独修复FEC RTP流包括使得FEC RTP流能够回引源RTP流的数据(即，“修复FEC有效载荷ID”)。具体而言，修复FEC有效载荷ID可以标识在创建FEC RTP流的每个修复分组时曾使用的源RTP流的初始RTP分组的序列号。此类常规实现通常以1对1的方式(即，一个修复流用于一个源流)提供冗余。

图1A-1B解说了计算设备之间的常规RTP流交换。对于常规RTP流，可以将序列号指派给发送出去的每个分组以用于分组标识目的。可生成FEC RTP流(或“修复流”)，该FECRTP流可从各个源RTP流标识此类序列号。然而，常规FEC RTP流被配置为仅为单个源流(例如，仅保护视频流保护或音频流保护)提供冗余。

图1A解说了此类常规场景100，其中示出了发送方计算设备102(例如，媒体流送服务器等)将具有相关源RTP流104、106的多个FEC RTP流105、107传送到接收方计算设备120(例如，智能电话移动设备、平板、膝上型计算机等)。可使用有线或无线连接将流104、105、106、107传送到网络110(诸如局域网、蜂窝网络、因特网等)。发送方计算设备102可被配置为传送第一FEC RTP流105以及第二FEC RTP流107，第一FEC RTP流105包括具有用于第一源RTP流104的源块的冗余数据的修复块，而第二FEC RTP流107包括具有用于第二源RTP流106的源块的冗余数据的修复块。该配置提供了用于避免源RTP流104、106的分组丢失的某种机制。然而，该配置可能需要较大数目的总RTP流。对于带宽和/或网络运营商/承运商规范或其他限制，此类要求可能不是最佳的。图1A解说的场景可用于浏览器应用的常规使用以进行点对点(P2P)视频-音频呼叫(例如，“Web实时通信”(WebRTC)技术)。

在某些场景中，源内容被组合或混合，以减少所传送的流的数目并能够使用单个FEC RTP流。具体而言，RFC6681描述了允许保护包括多个源的单个源RTP流的常规技术，其中多个源中的每个源可由协调源(CSRC)RTP报头来标识。

图1B解说了此类常规场景150，其中发送方计算设备102(例如，服务器)被示出为传送具有相关联混合源RTP流152的单个FEC RTP流155。例如，混合源RTP流152可包括已由发送方计算设备102混合在一起的多个音频流。例如，发送方计算设备102可组合对应于会议呼叫的多个扬声器的多个音频轨。FEC RTP流155可被配置为提供用于恢复混合源RTP流152的缺失/丢失数据的冗余。然而，该技术可有有限的价值，这是因为由于FEC RTP流仅仅涉及单个(尽管被组合)的源流，可能需要发送方计算设备102和接收方计算设备120为了混合和处理组合的源数据而花费附加的资源。进一步，此类技术可能不是最佳的，因为组合的源流通常用于相同类型的流(例如，所有音频流)。由此，这些技术可能不提供用于不同媒体类型(例如，音频流和视频流)的传输的单一FEC支持。

为了解决上述常规FEC技术的局限性，各种实施例提供了用于“集束FEC保护”的方法、设备、系统和非瞬态处理可读存储介质，其中单个修复流可用于为多个个体源RTP流提供恢复保护。由于当前标准(例如在RFC6681中定义的那些)没有精确地为RTP定义多个源RTP流的此类集束FEC保护，所以各实施例可以采用FEC FRAME的协议扩展来支持多个RTP源流的FEC保护。换言之，各实施例技术可以利用新颖的FEC源有效载荷和修复有效载荷定义，这些定义使得能够为多个RTP流定义单个修复流。例如，由于FEC FRAME Raptor代码选项目前不涉及在多个实时传输协议(RTP)同步源(SSRC)上的多种媒体类型的集束保护的情况，所以可利用RTP流报头扩展来允许单个FEC RTP流被配置为向多个源RTP流提供冗余，而不管其内容类型(例如，音频或视频)。基于此类扩展，各实施例技术允许保护各自具有唯一序列号空间的多个源RTP流。

在一些实施例中，可使用源RTP流的RTP报头扩展内的显式源FEC有效载荷ID(即，“显式源标识”技术)来完成集束FEC保护。此类RTP报头扩展可标识源有效载荷ID(写入报头扩展中)，使得源RTP流的接收方计算设备及与其相关联的FEC RTP流可以基于源有效载荷ID将修复有效载荷与源有效载荷相匹配。该显式源标识技术可能需要对源RTP流的修改。

在一些实施例中，可通过将FEC RTP流配置为包括对源RTP流的适当引用来完成集束FEC保护，使得在不必像其他实施例中必须使用RTP报头扩展(即，“隐式源标识”技术)。此类实现可以不修改源RTP流(或它们的报头结构)，而是可以定义和利用可标识在制作FECRTP流的修复有效载荷时涉及的所有源RTP流的不同类型的FEC修复ID。此类隐式源标识技术可能不需要对源RTP流的修改。

通过使单个FEC流能够同时为不同类型的媒体(例如，音频和视频)提供保护，各实施例技术可能是有益的。通过利用较大的有效载荷使得恢复潜力更大，各实施例技术可能是进一步有益的，因为FEC码通常在较大的有效载荷/流的情况下更好地工作。例如，如果提供FEC流以支持单个音频源RTP流，则与源有效载荷相对应的修复有效载荷可以相当小，从而使有效载荷被分解为小块，由此导致FEC获益减少。然而，如果FEC流涉及通常具有大得多的源有效载荷大小的音频和视频流两者，则FEC操作可能更有效。进一步，由各种实施例实现的集束FEC保护可以使总RTP流计数更低，并由此改善带宽使用，因为不需要个体源流和修复流之间的1对1关系。

图2解说了根据各种实施例的集束FEC RTP流202与多个源RTP流104、106一起传送的场景200。具体而言，发送方计算设备102可被配置为传送FEC RTP流202，FEC RTP流202包括具有用于第一源RTP流104和第二源RTP流106两者的源块的冗余数据的修复块。这提供了一种避免分组丢失的机制，以使得接收方计算设备120可以从FEC RTP流202中获得从源RTP流104、106中任一者缺失/损坏的数据。此类场景可使用显式源标识技术(如下文参照图3A-B进一步描述)或隐式源标识技术(如下文参照图4A-4C描述)来实现。

如果使用源FEC有效载荷ID(例如，与如RFC6681的第6节中定义的源有效载荷一起发送源FEC有效载荷ID)显式地标识源，则可以保护任意多序列源流。然而，可以修改源流报头信息以包括可与单个FEC流内的数据组合使用以恢复缺失分组的此类源信息。具体而言，源FEC有效载荷ID可在从发送方计算设备传送到接收方计算设备的源RTP流的报头扩展中发送。图3A-3B涉及此类实施例，其中可修改源RTP流以包括用于提供源FEC有效载荷ID的报头扩展。

图3A解说了用于供计算装置交换具有报头扩展的源RTP流连同集束FEC RTP流(即，“显式源标识”技术)的实施例方法300和330。方法300的操作可由发送方计算设备102的处理器执行，并且方法330的操作可由接收方计算设备120的处理器执行。在各种场景中，任何计算设备可根据方法300、330被配置为发送或接收。在各种实施例中，方法300、330可利用FEC RTP流和源RTP流，该FEC RTP流包括利用如RFC6681内所描述的语法/格式化的修复有效载荷ID，而该源RTP流包括也利用RFC6681内所描述的语法/格式化的源有效载荷ID以及基于RFC5285的扩展RTP报头(或报头扩展)。

发送方计算设备102的处理器可在方法300的框301中与接收方计算设备120交换邀约/应答，并且类似地，接收方计算设备120的处理器可在方法330的框331中与发送方计算设备102交换邀约/应答。框301和331的操作可以被认为是会话初始化(或会话启动)操作，其中两个设备都可使用协议(诸如会话描述协议(SDP))来交换会话初始化数据并且确定用于多个源RTP流的集束FEC保护是否可经由FEC RTP流来实现。

返回方法300，发送方计算设备102可在框302中生成源RTP流(或流数据)，诸如音频流数据、视频流数据等。在框304中，发送方计算设备102可选择多个源RTP流中的下一源RTP流以发送到接收方计算设备120(即，N个计数流)。例如，对于方法300的操作环的第一次迭代，发送方计算设备102可在源RTP流的列表中选择第一源RTP流。在框306中，发送方计算设备102可调整所选择的源RTP流的报头扩展(或所选择的源RTP流内的源数据)以包括源FEC有效载荷ID数据。可在发送方计算设备处接收的SDP数据中定义用于示例报头扩展的数据，诸如利用SDP行“a＝extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:SourceID”来定义。源FEC有效载荷ID可用于每个源RTP源流分组的RTP报头扩展中。

在一些实施例中，源FEC有效载荷ID可以是32位长(即，4字节)，以使得1字节报头扩展解决方案(如RFC5285的第4.2节中所定义)可足以标识源FEC有效载荷ID。在一些实施例中，例如当需要8位扩展ID编码时，可如RFC5285的第4.3节中所提供的使用2字节的报头扩展。在一些实施例中，源FEC有效载荷ID可在RFC6681的第6.2.2节中定义。

在确定框308中，发送方计算设备102可确定是否存在更多的源RTP流要处理。响应于确定存在更多的源RTP流要处理(即，确定块308＝“是”)，发送方计算设备102可利用框304中的操作来继续选择另一源RTP流。

响应于确定不存在更多的源RTP流要处理(即，确定块308＝“否”)，在框310中，发送方计算设备102可建立/生成用于经调整的源RTP流的FEC RTP流(或FEC RTP流数据)。在框312中，发送方计算设备102可调整FEC RTP流(或FEC RTP流数据)以包括修复FEC有效载荷ID(诸如通过将修复FEC有效载荷ID添加到FEC RTP流的报头扩展)。例如，发送方计算设备102可调整FEC RTP流以包括在会话初始化期间提供给发送方计算设备102的修复FEC有效载荷ID(例如，经由经带外信号接收的SDP数据)。

在一些实施例中，修复FEC有效载荷ID可在RFC6681的第6.2.3节中定义，并且可与FEC RTP流中的相关联修复有效载荷一起被发送。在一些实施例中，修复FEC有效载荷ID也可作为RTP报头扩展来发送，尽管它可被包括在FEC RTP流的RTP有效载荷中。如同源FEC有效载荷ID，在用于修复FEC有效载荷ID的一些实施例中可使用1字节的报头扩展或2字节的报头扩展。

在框314中，发送方计算设备102可将源RTP流和FEC RTP流数据传送到接收方计算设备(诸如经由广域网(WAN))。发送方计算设备102可在框302中以用于生成新的源RTP流数据(例如，源块)的操作继续。

返回方法330，在框332中，发送方计算设备102可接收来自发送方计算设备102的源RTP流和FEC RTP流的数据。在判定框334中，接收方计算设备120可判定对于任何源RTP流是否存在缺失数据(例如，缺失源块)。响应于确定存在缺失数据(即，确定框334＝“是”)，在框336中，接收方计算设备120可使用经调整的报头扩展从FEC RTP流(例如，从FEC或修复块)检索该缺失数据(或缺失源块数据)。响应于确定不存在缺失数据(即，判定块334＝“否”)或响应于执行框336的操作，在框338中，接收方计算设备120可使用源FEC流，诸如通过将音频和/或视频作为IP电话呼叫或其它流送媒体(例如，流送电影等)的一部分进行呈现。接收方计算设备120可在框332中继续接收后续的RTP流。

在一些实施例中，源FEC有效载荷ID和/或修复FEC有效载荷ID可利用在实时传输协议(RTP)参数注册表的RTP紧凑报头扩展子注册表中定义的新的RTP报头扩展统一资源标识符(URI)。例如，源FEC有效载荷ID可以利用扩展URI，诸如“urn:ietf:params:rtp-hdrext:FEC-FR:SourceID”，并且修复FEC有效载荷ID可以利用扩展URI，诸如“urn:ietf:params:rtp-hdrext:FEC-FR:RepairID”。

图3B是适用于各种实施例的SDP数据350的示例，其指示与具有报头扩展的源RTP流(例如，音频和视频流)对应的集束FEC RTP流的使用。SDP数据可以包括指示在接收方计算设备120和发送方计算设备102之间的通信中使用的RTP流的特性的各行。此类SDP数据的行(或内联行)的顺序可在最终传输中定义源流/分组的出现。在一些实施例中，此类SDP数据可由发送方计算设备或接收方计算设备120经由带外信令在会话初始化阶段期间接收。在一些实施例中，可基于RFC5285的第5节中提供的指导来对SDP行进行格式化，并且SDP行可进一步包括可以从RFC6681的第10节导出的与FEC保护相关的信息。

以下是SDP数据的解说。通常，“a＝group(群组):”行可被包括在SDP数据内，并且可涉及群组中的所有MID，其中MID可以是与描述要发送的流(诸如音频或视频流)的SDP数据的m行相关联的标识符。SDP数据的其他行可为相关联的m行提供“extmap:”参数，其中“extmap:”参数可以是特定于用于每个关联流的RTP扩展报头的类型。具体而言，SDP数据可包括指示群组的RTP流的顺序(例如，S1、S2、R1)的行351(例如，“a＝group:”attributeline(属性行))。行352、362、372可被认为是由第一行351标识的m行。SDP数据可包括指示要传送第一源RTP流(例如，视频流)的第一行352。第二行354可包括指示第一源RTP流可以利用报头扩展以用于FEC目的(例如，可包括源有效载荷ID)的“extmap:”参数。SDP数据可包括指示要传送的第二源RTP流(例如，音频流)的第三行362。第三行364可包括指示第二源RTP流可以利用报头扩展以用于FEC目的(例如，可包括源有效载荷ID)的“extmap:”参数。SDP数据可包括可以指示将要发送FEC RTP流的第五行372。第六行374可包括指示FEC RTP流可以利用报头扩展(例如，可包括修复有效载荷ID)的“extmap:”参数。

图4A解说了用于供计算装置交换具有集束FEC RTP流的未修改的源RTP流(即，“隐式源标识”技术)的实施例方法400和430。换言之，图4A解说了在没有源FEC有效载荷ID的情况下使用多序列流的技术。方法400、430可类似于上面参照图3A描述的方法，区别在于方法400、430不包括修改源RTP流的操作。相反，在方法400、430中，发送方计算设备102和接收方计算设备120可仅对在FEC RTP流内传送的信息进行调整，以便支持对在源流内丢失数据的恢复。具体而言，可使用FEC RTP流的修复FEC有效载荷ID而不编辑源RTP流。以这种方式，修复有效载荷ID的大小可随着经由FEC RTP流保护的源RTP流的数目而增大。由于可能需要发送方计算设备102标识每个序列号、从每个源RTP流获取的字节数目、以及指示用于在FECRTP流中的修复有效载荷ID的源RTP流的信息，因此该技术关于FEC RTP流的生成可能较昂贵。

方法400的操作可由发送方计算设备102的处理器执行，并且方法430的操作可由接收方计算设备120的处理器执行。在各种场景中，任何计算设备可根据方法400、430被配置为发送或接收。尽管RFC6681中的第8节描述了单序列流程的规程，但是各种实施例将这种单序列流方法扩展用于多序列流，尤其是对应于不同同步源(即SSRC)的多个RTP流。在各实施例中，隐式源标识技术可用于各种FEC码(诸如FEC方案ID 5和6)。在各种实施例中，方法400、430可利用FEC RTP流以及源RTP流，FEC RTP流包括利用如RFC6681内所描述的语法/格式化的修复有效载荷ID，而源RTP流包括也利用RFC6681内所描述的语法/格式化的源有效载荷ID。

方法400的框301、302、314的操作和方法430的框331、332、334、338的操作可类似于上面参照图3A描述的类似编号的框的操作。在框402中，发送方计算设备102的处理器可为多个源RTP流建立/生成FEC RTP流(或FEC RTP流数据)。框402的操作可类似于图3A的框310的操作，区别在于框402的操作可基于尚未被修改以包括报头扩展的源RTP流来建立/生成FEC RTP流。

在框404中，发送方计算设备102可构建用于FEC RTP流的修复块，其至少包括用于每个源RTP流的流标识符、长度指示符和s值(即，在RFC6681，第5节内定义的最小整数值)。在一些实施例中，可仅为一种格式的修复FEC有效载荷提供多序列流的必要扩展。在一些实施例中，可使用带外信令(例如，经由如图4C中所解说的SDP数据)来确定修复分组中的流的数目和在修复分组中流出现的顺序。

在一些实施例中，在框404的操作期间，发送方计算设备102可执行源码元构造。具体而言，发送方计算设备102可利用如RFC6681的第5节中定义的FEC方案5和FEC方案6规程，以构建可应用FEC码的一组源码元。例如，在构建源块期间，发送方计算设备102可确定源分组信息中包括的每个源RTP流(或流)的流标识符(即，f[i])、包括在每个分组的源分组信息中并且取决于传输有效载荷内携带的协议的长度指示(即，l[i])，以及在每个分组的源分组信息的构造中的s(即，s[i])的值，其可被标识为使得s[i]*T>＝(1[i]+3)最小整数，其中T可以是以八位位组计的源码元大小，而i可以是源RTP流索引。

在一些实施例中，源FEC分组标识信息的推导可被发送方计算设备利用。例如，源分组的源FEC分组标识信息可从每个分组中的流、分组的每个个体流的序列号以及在属于该源块的任何修复FEC分组中接收的信息中导出。构成源块的应用数据单元(ADU)可以由框中的第一源分组的相关联流标识符和序列号来标识。可在与源块相关联的所有修复FEC分组中在初始序列号字段中用信令通知该信息。

在一些实施例中，源块内的源分组的源分组信息的长度(以八位位组计)可以等于该块的包含修复分组(即，不包括修复FEC有效载荷ID)的编码码元的有效载荷的长度，其对于所有修复分组可能是相同的。码元中的应用数据单元信息长度(ADUIL)可以等于该长度除以编码码元大小(其可在FEC框架配置信息中用信令通知)。包括在源块中的该组源分组可以由初始序列号(ISN)和源子块长度(SSBL)确定如下：令f为流的索引(即，如果f指源块中第一个流，则f＝1)，I(f)是来自流f的源子块的初始序列号，LP(f)是用于流f的码元中的源子块信息长度，LB(f)是用于流f的码元中的源子块长度。那么，源块中可包括具有序列号从I(f)到I(f)+(LB(f)/LP(f))-1的源分组(包括流f在内)。源子块长度(SSBL)、LB(f)可被选择为使得至少与最大源分组信息长度LP(f)一样大。

在一些实施例中，对于FEC方案1，可如RFC5053的5.3.2节中规定地来演算放置到修复分组中的编码码元ID(ESI)值。在一些实施例中，对于FEC方案2，可如RFC6330的4.4.2节中规定地来演算放置到修复分组中的ESI值。然而，在FEC方案1或方案2中，K(即，源块可被划分成某个大小T个八位位组的源码元的数目，诸如在RFC6330，第4.4.1节中定义的)可与修复分组中指示的所有SSBL的总和相同。

在一些实施例中，对于RTP源分组流，RTP序列号字段可以用作上文所述规程中的序列号。包括在应用数据单元信息中的长度指示可以是所有流的RTP有效载荷长度的总和加上贡献源(CSRC)(如果有)、RTP报头扩展(如果存在)、和RTP填充八位位组(如果有)的长度。该长度通常可以等于分组的用户数据报协议(UDP)有效载荷长度减去12。

在框406中，发送方计算设备102可将FEC RTP流的有效载荷格式注册为集束媒体类型，并且可在框314中将源RTP流和FEC RTP流数据传送到接收方计算设备120。在一些实施例中，可使用根据RFC4855注册并使用RFC4288的模板的“集束/RaptorFEC”媒体类型来注册RTP有效载荷格式。此类媒体类型定义可与在RFC6682第6.2.1节中可找到的“视频/RaptorFEC”相同。

在方法430的框332中，接收方计算设备120可接收源RTP流和FEC RTP流数据。与图3A中讨论的源RTP流不同，图4A中的源RTP流可能不包括源FEC有效载荷ID(即，源RTP流的源分组可不被修改)。由于带外信令(诸如在会话初始化期间(例如，在框331的操作期间)接收到的)，接收方计算设备120可能已经知道对应于各种源RTP流的第一序列号或源块长度。接收方计算设备120可期望将存在由FEC RTP流内的每个源RTP流贡献的分组(或块)(即，可期望FEC RTP流的每个修复分组包括相同数目的来自每个流的源字节)。如果没有接收到FEC修复分组，则不能进行FEC解码，并且接收方计算设备120可能不必标识源RTP流分组的源FEC分组标识信息。

在判定框334中，接收方计算设备120可判定源RTP流之一中是否存在缺失数据，如上文参照图3A相同编号的框所述。响应于判定在源RTP流之一中存在缺失数据(即，判定框334＝“是”)，在框436中，接收方计算设备120可使用集束媒体FEC有效载荷，从FEC RTP流中检索缺失数据(或缺失源块数据)。响应于判定不存在来自源RTP流的缺失数据(即，判定块334＝“否”)或响应于执行框436的操作，接收方计算设备120可在框338中使用源RTP流，并且在框332中继续接收分组。

图4B是适用于各实施例中的FEC有效载荷格式440的示例。图4B所解说的FEC有效载荷格式440可以类似于RFC6681的第8.1.3节中定义的格式“A”，除了FEC有效载荷格式440包括多序列流的必要扩展。关于多序列修复FEC有效载荷ID格式440，“初始序列号”(ISN)字段(例如，流i ISN)可以是16位，并且可以是指定要被包括在此子块中的第一分组的序列号的最低16位的字段。如果序列号短于16位，则接收到的序列号可以分别在逻辑上用零位填充至长度为16位。ISN字段类型可以是无符号整数。源子块长度(SSBL)字段可以是16位，并且可以指定以码元计的源子块长度。SSBL字段类型可以是无符号整数。编码码元ID(ESI)字段可以是16位，并且可指示在该修复分组内包含哪些修复码元。提供的ESI可以是分组中第一个修复码元的ESI。ESI字段类型可以是无符号整数。

图4C解说了适用于在一些实施例中的与源RTP流对应的集束FEC RTP流的SDP数据450的示例。此类SDP数据450可向发送方/接收方计算设备提供修复分组中的流的数目以及在修复分组中流出现的顺序，并且可使用带外信令将此类SDP数据450递送到这些设备。SDP数据450可以是类似于如上文图3B所解说的SDP，除了SDP数据450不指示源RTP流的报头扩展。如上所述，SDP数据的行(或内联行)的顺序可在最终传输中定义源流/分组的出现。在一些实施例中，指示集束FEC保护的SDP数据可以从RFC6681的第10节导出。

作为解说，SDP数据可包括指示RTP流的出现顺序(即，S1、S2、R1)的行451(例如，“a＝group:”attribute line(属性行))。SDP数据450可包括指示要传送第一源RTP流(例如，视频流)的第一行452(例如，m行)。第二行462(例如，m行)可指示要传送第二源RTP流(例如，音频流)。第三行472(例如，m行)可指示要传送FEC RTP流。第四行474可指示用于FEC RTP流的集束配置信息。

在一些实施例中，发送方和接收方计算设备可被配置为利用显式源标识技术、隐式源标识技术、和/或用于提供源RTP流的FEC保护的其他技术。图5A-5B解说了用于供发送方和接收方计算设备动态地利用各种技术的实施例方法。

图5A解说用于供发送方计算设备传送具有各种配置的集束FEC RTP流的源RTP流的实施例方法500。换言之，发送方计算设备可连续评估与传出源RTP流相关联的数据，以确定如何实现集束FEC保护。方法500的框301-302的操作可以类似于以上文参照图3A描述的类似编号的框的操作。

在判定框504中，发送方计算设备可判定是否使用显式源标识集束FEC保护(即，使用经修改的源RTP流的RTP报头扩展技术)。此类判定可基于框301的操作期间接收的并且如图3B所解说的SDP数据。响应于判定应使用RTP报头扩展(即，判定框504＝“是”)，发送方计算设备可执行如上文参照图3A描述的框304-314的发送操作。

响应于判定不应使用RTP报头扩展(即，判定框504＝“否”)，在判定框506中，发送方计算设备可判定是否使用隐式源标识技术来提供集束FEC保护(即，不对源流进行修改/无源RTP报头扩展)。响应于判定应使用隐式源标识技术(即，判定框506＝“是”)，发送方计算设备可执行如上文参照图4A描述的框314、402-406的发送操作。

响应于判定不应使用隐式源标识技术(即，判定框506＝“否”)，在多个RTP源流上的集束FEC保护或许是不可能的，并且可能需要发送方计算设备利用类似于RFC6681中描述的技术，但使用CSRC来区分不同的源流。例如，发送方计算设备可使用CSRC来分离通常可用于混合网关(例如，多方语音/视频会议桥)中的源。换言之，发送方计算设备可以作为多个源的混合器来操作。在框508中，发送方计算设备可以将源RTP流混合在一起，在框510中，使用CSRC生成用于混合源RTP流的FEC RTP流，并且在框512中将混合的源RTP流和FEC RTP流传送到接收方计算设备。

图5B解说用于供接收方计算设备接收和处理具有各种配置的集束FEC RTP流的源RTP流的实施例方法550。方法550的框331的操作可以类似于以上文参照图3A描述的类似编号的框的操作。

在判定框504中，接收方计算设备可判定是否使用显式源标识集束FEC保护(即，修改源流的RTP报头扩展技术)。此类判定可基于框331的操作期间接收的且如图3B所解说的SDP数据。响应于判定应使用RTP报头扩展(即，判定框504＝“是”)，接收方计算设备可执行如上文参照图3A描述的框332-338的接收和处理操作。

响应于判定不应使用RTP报头扩展(即，判定框504＝“否”)，在判定框506中，接收方计算设备可判定是否使用隐式源标识技术来提供集束FEC保护(即，不对源流进行修改，无源RTP报头扩展)。响应于判定应使用隐式源标识技术(即，判定框506＝“是”)，接收方计算设备可执行如上文参照图4A描述的框332、334、338、436的接收和处理操作。

响应于判定不应使用隐式源标识技术(即，判定框506＝“否”)，接收方计算设备可采取利用混合源RTP流的方式。框552-558的操作可以类似于图4A的框332-338或框332、334、436、338的操作，除了框552-558的操作可考虑单个混合源RTP流和FEC RTP流。例如，为了将源RTP流用于框558中的操作，可能需要接收方计算设备执行分离操作，以便在呈现等操作之前区分各种混合在一起的流。此类分离操作可以利用CSRC。作为解说，多方呼叫中的端点(例如，发送方计算设备)可以不同的编码器速率发送多个音频流，以支持呼叫中具有不同音频编解码器能力的其他各方。这些流可在单个RTP会话(即，“音频多播”)上被发送，其中每个音频流可以由CSRC来标识。该接收方计算设备可接收单个RTP会话并且基于所包括的CSRC数据来标识个体音频流。

上面描述的各种实施例的更多细节可以在标题为“用于多个RTP同步源的FECFRAME Raptor扩展”的文档中找到，该文档附加到本申请中并且整体地并入本说明书中，如同本文所呈现的。

各种形式的计算设备(包括个人计算机和膝上型计算机)可被用于实现各种实施例。此类计算设备通常包括图6所解说的移动设备120的组件。在各种实施例中，移动设备120可包括耦合到触摸屏控制器604和内部存储器602的处理器601。处理器601可以是指定用于通用或特定处理任务的一个或多个多核IC。内部存储器602可以是易失性或非易失性存储器，并且还可以是安全和/或加密的存储器、或者不安全和/或未加密存储器，或其任何组合。触摸屏控制器604和处理器601还可被耦合到触摸屏面板612，诸如电阻式传感触摸屏、电容式传感触摸屏、红外传感触摸屏等。移动设备120可具有彼此耦合和/或耦合至处理器601的一个或多个无线电信号收发机608(例如，蓝牙 RF无线电)以及用于发送和接收的天线610。收发机608和天线610可与以上提及的电路系统一起使用以实现各种无线传输协议栈和接口。移动设备120可包括蜂窝网络无线调制解调器芯片616，该芯片使得能够经由蜂窝网络进行通信并且可耦合至处理器。移动设备120可以包括耦合至处理器601的外围设备连接接口618。外围设备连接接口618可被配置成单独接纳一种类型的连接，或者被配置成多路接纳共用的或专有的各种类型的物理和通信连接，诸如USB、火线(FireWire)、雷电(Thunderbolt)或PCIe。外围设备连接接口618还可被耦合至类似地配置的外围设备连接端口(未示出)。移动设备120还可包括用于提供音频输出的扬声器614。移动设备120还可包括用于容纳本文所讨论的组件中的全部或一些组件的外壳620，其由塑料、金属或多种材料的组合来构成。移动设备120可以包括耦合至处理器601的电源622，诸如一次性或可充电电池。可充电电池还可以耦合至外围设备连接端口以从移动设备120外部的源接收充电电流。

各种形式的计算设备(包括个人计算机、移动计算设备(例如智能电话等)、服务器、膝上型计算机等)可被用于实现各种实施例。此类计算设备典型情况下至少可包括图7中解说的组件，图7解说了示例服务器计算设备。此类服务器计算设备102通常可包括耦合至易失性存储器702和大容量非易失性存储器(诸如盘驱动器703)的处理器701。服务器计算设备102还可包括耦合至处理器701的软盘驱动器、压缩碟(CD)或数字多用盘(DVD)碟驱动器706。服务器计算设备102还可包括耦合至处理器701的用于建立与网络705(诸如耦合至其他系统计算机和服务器的因特网和/或局域网)的数据连接的网络接入端口704(或接口)。

本文所描述的各种处理器可以是能通过软件指令(应用)配置成执行包括本文所描述的各种实施例的功能在内的各种功能的任何可编程微处理器、微型计算机或者一个或多个多处理器芯片。在各种设备中，可提供多个处理器，诸如一个处理器专用于无线通信功能并且一个处理器专用于运行其他应用。通常，软件应用可被存储在内部存储器中，然后它们被访问并被加载到这些处理器中。处理器可包括足以存储应用软件指令的内部存储器。在许多设备中，内部存储器可以是易失性或非易失性存储器(诸如闪存)，或这两者的混合。出于本说明书的目的，对存储器的一般性引述是指可由这些处理器访问的存储器，包括内部存储器或插入到各种设备中的可移除存储器、以及在处理器内部的存储器。

上述方法描述和过程流图仅作为解说性示例提供，且并非旨在要求或暗示各种实施例的步骤必须按所给出的次序来执行。如本领域技术人员将领会的，前述实施例中的步骤次序可按任何次序来执行。诸如“此后”、“然后”、“接着”等的措辞并非旨在限定步骤的次序；这些措辞仅是简单地用以指引读者遍历方法的描述。进一步，对单数形式的权利要求元素的任何引述(例如使用冠词“一”、“某”或“该”的引述)不应解释为将该元素限定为单数。

结合本文中所公开的实施例来描述的各种解说性逻辑框、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、块、模块、电路、以及步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员可针对每种特定应用以不同方式来实现所描述的功能性，但此类实现决策不应被解读为致使脱离权利要求的范围。

用以实现结合本文中公开的实施例描述的各种解说性逻辑、逻辑框、模块、以及电路的硬件可用设计成执行本文中描述的功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其他可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，处理器可以是任何常规处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如，DSP与微处理器的组合、多个微处理器、与DSP核心协同的一个或多个微处理器、或任何其它此类配置。替换地，一些步骤或方法可由专用于给定功能的电路系统来执行。

在一个或多个实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现，则这些功能可作为一条或多条指令或代码存储在非瞬态处理器可读、计算机可读或服务器可读介质或非瞬态处理器可读存储介质上，或藉由其进行传送。本文所公开的方法或算法的步骤可在处理器可执行软件模块或处理器可执行指令中实施，该处理器可执行软件模块或处理器可执行指令可驻留在非瞬态计算机可读存储介质、非瞬态服务器可读存储介质、和/或非瞬态处理器可读存储介质上。在各种实施例中，此类指令可以是所存储的处理器可执行指令或所存储的处理器可执行软件指令。有形非瞬态计算机存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，此类非瞬态计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁存储设备、或能被用来存储指令或数据结构形式的期望程序代码且能被计算机访问的任何其他介质。如本文所用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、DVD、软盘和蓝光碟，其中盘(disk)通常以磁的方式再现数据，而碟(disc)通常用激光以光学方式再现数据。以上的组合也应被包括在非瞬态计算机可读介质的范围内。另外，方法或算法的操作可作为一条代码和/或指令或者代码和/或指令的任何组合或集合而驻留在可被纳入计算机程序产品中的有形、非瞬态处理器可读存储介质和/或计算机可读介质上。

提供所公开的实施例的先前描述是为了使本领域任何技术人员皆能制作或使用本权利要求。对这些实施例的各种修改对于本领域技术人员而言将是显而易见的，并且本文中定义的通用原理可被应用于其他实施例而不会脱离权利要求的范围。由此，本公开并非旨在限定于本文中示出的实施例，而是应被授予与所附权利要求和本文中公开的原理和新颖性特征一致的最广义的范围。

Claims (16)

1.一种用于扩展前向纠错(FEC)以使用单个FEC RTP流来保护多个实时协议(RTP)流的方法，包括：

经由发送方计算设备的处理器，与接收方计算设备交换会话初始化数据；

经由所述处理器，生成用于所述多个源RTP流的源RTP流数据；

经由所述处理器，生成对应于所述多个源RTP流的用于FEC RTP流的FEC RTP流数据；以及

将所述多个源RTP流和所述FEC RTP流传送到所述接收方计算设备。

2.如权利要求1所述的方法，其特征在于，进一步包括：

经由所述处理器，调整所述多个源RTP流中的每个源RTP流的报头扩展以包括源FEC有效载荷标识符(ID)。

3.如权利要求2所述的方法，其特征在于，进一步包括：

经由所述处理器，调整所述FEC RTP流以包括修复FEC有效载荷标识符(ID)。

4.如权利要求1所述的方法，其特征在于，进一步包括：

经由所述处理器，构建用于所述多个源RTP流的所述FEC RTP流的修复块，其中所述修复块至少包括用于每个所述源RTP流的流标识符、长度指示符和s值；以及

经由所述处理器，将所述FEC RTP流的有效载荷格式注册为集束媒介类型。

5.如权利要求1所述的方法，其特征在于，所述多个源RTP流中的每个源RTP流是音频流和视频流中的一者。

6.如权利要求1所述的方法，其特征在于，所述会话初始化数据包括会话描述协议(SDP)数据。

7.一种用于扩展前向纠错(FEC)以使用单个FEC RTP流来保护多个实时协议(RTP)流的方法，包括：

经由接收方计算设备的处理器，从发送方计算设备接收多个源RTP流和FEC RTP流；

经由所述处理器，确定是否从所述多个源RTP流中的任何源RTP流中缺失任何源块数据；

响应于确定存在缺失源块数据，经由所述处理器，从所述FEC RTP流的修复块中检索缺失源块数据；

经由所述处理器，使用所述多个源RTP流的数据。

8.如权利要求7所述的方法，其特征在于，所述多个源RTP流中的每个源RTP流是音频流和视频流中的一者。

9.一种计算设备，包括：

收发机；

处理器，所述处理器连接至所述收发机且配置有用于执行操作的处理器可执行指令，所述操作包括：

与接收方计算设备交换会话初始化数据；

生成用于多个源RTP流的源实时协议(RTP)流数据；

生成对应于所述多个源RTP流的用于FEC RTP流的前向纠错(FEC)RTP流数据；以及

将所述多个源RTP流和所述FEC RTP流传送到所述接收方计算设备。

10.如权利要求9所述的计算设备，其特征在于，所述处理器配置有用于执行进一步包括以下操作的处理器可执行指令：

调整所述多个源RTP流中的每个源RTP流的报头扩展以包括源FEC有效载荷标识符(ID)。

11.如权利要求10所述的计算设备，其特征在于，所述处理器配置有用于执行进一步包括以下操作的处理器可执行指令：

调整所述FEC RTP流以包括修复FEC有效载荷标识符(ID)。

12.如权利要求9所述的计算设备，其特征在于，所述处理器配置有用于执行进一步包括以下操作的处理器可执行指令：

构建用于所述多个源RTP流的所述FEC RTP流的修复块，其中所述修复块至少包括用于每个所述源RTP流的流标识符、长度指示符和s值；以及

经由所述处理器，将所述FEC RTP流的有效载荷格式注册为集束媒介类型。

13.如权利要求9所述的计算设备，其特征在于，所述多个源RTP流中的每个源RTP流是音频流和视频流中的一者。

14.如权利要求9所述的计算设备，其特征在于，所述会话初始化数据包括会话描述协议(SDP)数据。

15.一种计算设备，包括：

收发机；

连接至收发机的处理器，其中所述处理器配置有处理器可执行指令以执行操作，所述操作包括：

从发送方计算设备接收多个源实时协议(RTP)流和前向纠错(FEC)RTP流；

确定是否从所述多个源RTP流中的任何源RTP流中缺失任何源块数据；

响应于确定存在缺失源块数据，从所述FEC RTP流的修复块中检索缺失源块数据；

使用所述多个源RTP流的数据。

16.如权利要求15所述的计算设备，其特征在于，所述多个源RTP流中的每个源RTP流是音频流和视频流中的一者。