在RTP会话中递送时间同步的任意数据

摘要

本公开涉及无线通信。一个方面生成多个数据分组，每个分组包括头部以及媒体数据有效载荷，接收与至少一个分组的有效载荷有关的不透明数据，以及将该不透明数据嵌入在该至少一个分组的扩展头部中。一个方面接收多个数据分组，每个分组包括头部以及媒体数据有效载荷，以及接收与至少一个分组的有效载荷有关的不透明数据，该不透明数据被嵌入在该至少一个分组的扩展头部中。

说明书

相关申请的交叉引用

本专利申请要求于2012年7月27日提交的题为“DELIVERING TIME  SYNCHRONIZED ARBITRARY DATA IN AN RTP SESSION(在RTP会话中递 送时间同步的任意数据)”的美国临时申请No.61/676,476的权益，该临时申请 已被转让给本申请受让人并由此通过援引明确地整体纳入于此。

公开领域

本公开涉及无线通信，更具体地，涉及在实时传输协议(RTP)会话中递 送时间同步的任意数据。

背景

蜂窝通信系统可通过共享可用系统资源来支持多用户的双向通信。蜂窝系 统不同于可主要支持或仅支持从广播站到用户的单向传输的广播系统。蜂窝系 统被广泛部署以提供各种通信服务，并且可以是多址系统，诸如码分多址 (CDMA)系统、时分多址(TDMA)系统、频分多址(FDMA)系统、正交 FDMA(OFDMA)系统、单载波FDMA(SC-FDMA)系统等。

蜂窝系统可以支持广播、多播、以及单播服务。广播服务是可被所有用户 接收的服务，例如，新闻广播。多播服务是可被一群用户接收的服务，例如， 订阅视频服务。单播服务是旨在给特定用户的服务，例如，语音呼叫。群通信 可使用单播、广播、多播、或每一者的组合来实现。

在两个或更多个用户之间的多媒体会话中，用户可能希望在现有的媒体之 上覆盖或叠放另一媒体或任意数据。例如，在视频聊天会话中，用户可能希望 在屏幕上画一个动画，该动画会覆盖在目标设备处的流送视频之上。这要求在 视频和覆盖动画之间的严格时间同步。

概述

本公开涉及无线通信。一种用于无线通信的方法包括生成多个数据分组， 每个分组包括头部以及媒体数据有效载荷，接收与至少一个分组的有效载荷有 关的不透明数据，以及将该不透明数据嵌入在该至少一个分组的扩展头部中。

一种用于无线通信的方法包括接收多个数据分组，每个分组包括头部以及 媒体数据有效载荷，以及接收与至少一个分组的有效载荷有关的不透明数据， 该不透明数据被嵌入在该至少一个分组的扩展头部中。

一种用于无线通信的设备包括配置成生成多个数据分组的逻辑，每个分组 包括头部以及媒体数据有效载荷，配置成接收与至少一个分组的有效载荷有关 的不透明数据的逻辑，以及配置成将该不透明数据嵌入在该至少一个分组的扩 展头部中的逻辑。

一种用于无线通信的设备包括配置成接收多个数据分组的逻辑，每个分组 包括头部以及媒体数据有效载荷，以及配置成接收与至少一个分组的有效载荷 有关的不透明数据的逻辑，该不透明数据被嵌入在该至少一个分组的扩展头部 中。

一种用于无线通信的设备包括用于生成多个数据分组的装置，每个分组包 括头部以及媒体数据有效载荷，用于接收与至少一个分组的有效载荷有关的不 透明数据的装置，以及用于将该不透明数据嵌入在该至少一个分组的扩展头部 中的装置。

一种用于无线通信的设备包括接收用于接收多个数据分组的装置，每个分 组包括头部以及媒体数据有效载荷，以及用于接收与至少一个分组的有效载荷 有关的不透明数据的装置，该不透明数据被嵌入在该至少一个分组的扩展头部 中。

一种用于无线通信的非瞬态计算机可读介质包括用于生成多个数据分组 的至少一个指令，每个分组包括头部以及媒体数据有效载荷，用于接收与至少 一个分组的有效载荷有关的不透明数据的至少一个指令，以及用于将该不透明 数据嵌入在该至少一个分组的扩展头部中的至少一个指令。

一种用于无线通信的非瞬态计算机可读介质包括用于接收多个数据分组 的至少一个指令，每个分组包括头部以及媒体数据有效载荷，以及用于接收与 至少一个分组的有效载荷有关的不透明数据的至少一个指令，该不透明数据被 嵌入在该至少一个分组的扩展头部中。

附图简述

给出附图以帮助对本发明实施例进行描述，且提供附图仅用于图示实施例 而非对其进行限定。

图1是根据本发明的至少一个实施例的支持接入终端和接入网的无线网络 架构的示图。

图2更详细地解说了图1的无线通信系统的示例。

图3解说了根据本公开的诸方面的用户装备(UE)的示例。

图4解说了包括被配置成执行功能性的逻辑的通信设备。

图5解说了根据本公开的各个方面的示例性服务器。

图6解说了具有扩展头部以及不具有扩展头部的实时传输协议分组的示 例。

图7解说了具有示例性扩展头部的示例性实时传输协议头部。

图8解说了发送方和接收方之间的示例性对等呼叫流。

图9解说了包括一个发送方和两个接收方的一群用户之间的示例性对等呼 叫流。

图10解说了用于采用中间服务器并且具有后加入者的示例性呼叫流程。

图11解说了根据本公开的一方面的用于无线通信的示例性流程。

图12解说了根据本公开的一方面的用于无线通信的示例性流程。

详细描述

在以下描述和相关的附图中公开了各个方面。可以设计替换方面而不会脱 离本公开的范围。另外，本公开中众所周知的元素将不被详细描述或将被省去 以免湮没本公开的相关细节。

措辞“示例性”在本文中用于表示“用作示例、实例或解说”。本文中描 述为“示例性”的任何实施例不必被解释为优于或胜过其他实施例。同样，术 语“实施例”或“本发明的实施例”不要求所有的实施例都包括所讨论的特征、 优点或操作模式。

本文所使用的术语仅出于描述特定实施例的目的，而并不旨在限定各实施 例。如本文所使用的，单数形式的“一”、“一个”和“该”旨在也包括复数 形式，除非上下文另有明确指示并非如此。还将理解，术语“包括”、“具有”、 “包含”和/或“含有”在本文中使用时指定所陈述的特征、整数、步骤、操作、 要素、和/或组件的存在，但并不排除一个或多个其他特征、整数、步骤、操作、 要素、组件和/或其群组的存在或添加。

此外，许多实施例是根据将由例如计算设备的元件执行的动作序列来描述 的。将认识到，本文描述的各种动作能由专用电路(例如，专用集成电路 (ASIC))、由正被一个或多个处理器执行的程序指令、或由这两者的组合来 执行。另外，本文描述的这些动作序列可被认为是完全体现在任何形式的计算 机可读存储介质内，其内存储有一经执行就将使相关联的处理器执行本文所描 述的功能性的相应计算机指令集。因此，各个实施例的各种方面可以用数种不 同形式来体现，所有这些形式都已被构想为落在所要求保护的主题内容的范围 内。另外，对于本文描述的每个实施例，任何此类实施例的对应形式可在本文 被描述为例如“被配置成执行所描述的动作的逻辑”。

在本文被称为用户装备(UE)的高数据率(HDR)订户站可以是移动的 或驻定的，并且可与一个或多个可被称为B节点的接入点(AP)通信。UE通 过一个或多个B节点向无线电网络控制器(RNC)传送和从其接收数据分组。 B节点和RNC是被称为无线电接入网(RAN)的网络的部分。无线电接入网 可在多个接入终端之间传输语音和数据分组。

无线电接入网可进一步连接至该无线电接入网外部的附加网络并且可在 每个UE与此类网络之间传输语音和数据分组，此类核心网包括特定承运商相 关的服务器和设备以及至其他网络(诸如企业内联网、因特网、公共交换电话 网(PSTN)、服务通用分组无线电服务(GPRS)支持节点(SGSN)、网关 GPRS支持节点(GGSN))的连通性。已与一个或多个B节点建立活跃话务 信道连接的UE可被称为活跃UE，并且可被称为处于话务状态。处在与一个或 多个B节点建立活跃话务信道(TCH)连接的过程中的UE可被称为处于连接 建立状态。UE可以是通过无线信道或通过有线信道进行通信的任何数据设备。 UE还可以是数种类型设备中的任何设备，包括但不限于PC卡、致密闪存设备、 外置或内置调制解调器、或者无线或有线电话。UE藉以向(诸)B节点发送 信号的通信链路被称为上行链路信道(例如，反向话务信道、控制信道、接入 信道等)。(诸)B节点藉以向UE发送信号的通信链路被称为下行链路信道 (例如，寻呼信道、控制信道、广播信道、前向话务信道等)。如本文所使用 的，术语话务信道(TCH)可以指上行链路/反向或下行链路/前向话务信道。

图1解说了根据至少一个实施例的无线通信系统100的一个示例性实施例 的框图。系统100可包含跨空中接口104与接入网或无线电接入网(RAN)120 进行通信的UE(诸如蜂窝电话102)，接入网或无线电接入网(RAN)120能 将UE 102连接至提供分组交换数据网(例如，内联网、因特网、和/或核心网 126)与UE 102、108、110、112之间的数据连通性的网络装备。如此处所示， UE可以是蜂窝电话102、个人数字助理108、在此处示为双向文本寻呼机的寻 呼机110、或者甚至是具有无线通信口的分开的计算机平台112。因此，各实 施例能在任何形式的包括无线通信口或具有无线通信能力的UE上实现，包括 但不限于无线调制解调器、PCMCIA卡、个人计算机、电话、或者其任何组合 或子组合。此外，如本文所使用的，术语“UE”在其他通信协议(即，除W-CDMA 以外的其他通信协议)中可被互换地称为“接入终端”、“AT”、“无线设备”、 “客户端设备”、“移动终端”、“移动站”及其变型。

参照回到图1，无线通信系统100的组件以及各实施例的元件的相互关系 不限于所解说的配置。系统100仅仅是示例性的并且可包括允许远程UE(诸 如无线客户端计算设备102、108、110、112)通过空中在彼此之间或当中通信 和/或在经由空中接口104和RAN 120连接的组件(包括但不限于核心网126、 因特网、PSTN、SGSN、GGSN和/或其他远程服务器)之间和当中通信的任何 系统。

RAN 120控制向RNC 122发送的消息(通常是作为数据分组发送的消息)。 RNC 122负责信令通知、建立、以及拆除服务通用分组无线电服务(GPRS) 支持节点(SGSN)与UE 102/108/110/112之间的承载信道(即，数据信道)。 如果启用了链路层加密，则RNC 122还在通过空中接口104转发内容之前对该 内容进行加密。RNC 122的功能在本领域是公知的且出于简明起见将不作进一 步讨论。核心网126可通过网络、因特网和/或公共交换电话网(PSTN)与RNC 122通信。替换地，RNC 122可直接连接到因特网或外部网络。通常，核心网 126与RNC 122之间的网络或因特网连接传递数据，而PSTN传递语音信息。 RNC 122可连接到多个B节点124。以与核心网126相似的方式，RNC 122通 常通过网络、因特网和/或PSTN连接到B节点124以用于数据传递和/或语音 信息。B节点124可无线地向UE(诸如蜂窝电话102)广播数据消息。如本领 域已知的，B节点124、RNC 122及其它组件可形成RAN 120。然而，替换配 置也可被使用并且各实施例不限于所解说的配置。例如，在另一实施例中，RNC  122以及一个或多个B节点124的功能性可被折叠到具有RNC 122和B节点 124两者的功能性的单个“混合”模块中。

图2更详细地解说了图1的无线通信系统100的示例。具体而言，参照图 2，UE 1…N被示为在由不同分组数据网端点服务的位置处连接至RAN 120。 图2的解说针对W-CDMA系统和术语，但是将领会图2可如何被修改以遵循 各种其他无线通信协议(例如，LTE、EV-DO、UMTS等)，并且各种实施例 不限于所解说的系统或元件。

UE 1和UE 3在由第一分组数据网端点162(例如，其可对应于SGSN、 GGSN、PDSN、归属代理(HA)、区外代理(FA)等)服务的一部分处连接 至RAN 120。第一分组数据网端点162进而经由路由单元188连接至因特网175 和/或连接至以下一者或多者：认证、授权和记账(AAA)服务器182、置备服 务器184、网际协议(IP)多媒体子系统(IMS)/会话发起协议(SIP)注册服 务器186和/或应用服务器170。UE 2和5…N在由第二分组数据网端点164(例 如，其可对应于SGSN、GGSN、PDSN、FA、HA等)服务的一部分处连接至 RAN 120。类似于第一分组数据网端点162，第二分组数据网端点164进而经 由路由单元188连接至因特网175和/或连接至以下一者或多者：AAA服务器 182、置备服务器184、IMS/SIP注册服务器186和/或应用服务器170。UE 4 直接连接至因特网175，并且通过因特网175可随后连接至以上描述的任何系 统组件。

参照图2，UE 1、3和4…N被解说为无线蜂窝电话，UE 2被解说为无线 平板PC和/或膝上型PC。然而，在其他实施例中，将领会，无线通信系统100 可连接至任何类型的UE，并且在图2中解说的示例并非旨在限制该系统内可 实现的UE的类型。

图3解说了根据本公开的诸方面的UE的示例。参照图3，UE 300A被解 说为发起呼叫的电话，而UE 300B被解说为触摸屏设备(例如，智能电话、平 板计算机等)。如图3中所示，UE 300A的外壳被配置成具有天线305A、显 示器310A、至少一个按键315A(例如，PTT按键、电源键、音量控制键等) 以及小键盘320A及其它组件，如本领域中已知的。而且，UE 300B的外壳被 配置成具有触摸屏显示器305B、外周按键310B、315B、320B以及325B(例 如，电源控制键、音量或震动控制键、飞行模式切换键等)、至少一个前面板 键330B(例如，Home(主屏)键)以及其它组件，如本领域中已知的。虽然 未被明确示出为UE 300B的一部分，但UE 300B可包括一个或多个外部天线 和/或内建到UE 300B的外壳中的一个或多个集成天线，包括但不限于WiFi天 线、蜂窝天线、卫星定位系统(SPS)天线(例如，全球定位系统(GPS)天 线)等等。

虽然UE(诸如UE 300A和300B)的内部组件可以用不同硬件配置来实施， 但在图3中，内部硬件组件的基本高级UE配置被示为平台302。平台302可 接收并执行传送自RAN 120的、可能最终来自核心网140、因特网175和/或其 他远程服务器和网络(例如应用服务器170、web URL等)的软件应用、数据 和/或命令。平台302还可独立地执行本地存储的应用而无需RAN交互。平台 302可包括收发机306，收发机306可操作地耦合到专用集成电路(ASIC)308 或其他处理器、微处理器、逻辑电路、或其他数据处理设备。ASIC 308或其他 处理器执行与无线设备的存储器312中的任何驻留程序相对接的应用编程接口 (API)310层。存储器312可包括只读存储器(ROM)或随机存取存储器(RAM)、 电可擦除可编程ROM(EEPROM)、闪存卡、或计算机平台常用的任何存储 器。平台302还可包括能存储未在存储器312中活跃地使用的应用以及其它数 据的本地数据库314。本地数据库314通常为闪存单元，但也可以是本领域已 知的任何辅助存储设备，诸如磁介质、EEPROM、光学介质、带、软盘或硬盘、 或诸如此类。

相应地，本发明的一个方面可包括具有执行本文描述的功能的能力的UE (例如，UE 300A、300B等)。如将由本领域技术人员领会的，各种逻辑元件 可实施在在分立元件、在处理器上执行的软件模块、或软件与硬件的任何组合 中以达成本文公开的功能性。例如，ASIC 308、存储器312、API 310和本地数 据库314可以全部协作地用来加载、存储和执行本文所公开的各种功能，且用 于执行这些功能的逻辑由此可分布在各种元件上。替换地，该功能性可被纳入 到一个分立的组件中。因此，图3中的UE 300A和300B的特征将仅被视为解 说性的，且本公开不限于所解说的特征或布局。

UE 300A和/或300B与RAN 120之间的无线通信可以基于不同的技术，诸 如CDMA、W-CDMA、时分多址(TDMA)、频分多址(FDMA)、正交频分 复用(OFDM)、GSM、或可在无线通信网络或数据通信网络中使用的其他协 议。如上文所讨论的以及本领域中已知的，可以使用各种各样的网络和配置将 语音传输和/或数据从RAN传送到UE。因此，本文提供的解说并非意图限定本 公开的诸方面，而仅仅是辅助描述本公开的诸方面。

图4解说了包括被配置成执行功能性的逻辑的通信设备400。通信设备400 可对应于上述通信设备中的任一者，包括但不限于UE 102、108、110、112或 200，B节点或基站120，RNC或基站控制器122，分组数据网端点(例如，SGSN  160、GGSN 165、长期演进(LTE)中的移动性管理实体(MME)等)，服务 器170到186中的任一者等。因此，通信设备400可对应于被配置成通过网络 与一个或多个其它实体通信(或促成通信)的任何电子设备。

参照图4，通信设备400包括配置成接收和/或传送信息的逻辑405。在一 示例中，如果通信设备400对应于无线通信设备(例如，B节点124、UE 300A 或300B等)，则配置成接收和/或传送信息的逻辑405可包括无线通信接口(例 如，蓝牙、WiFi、2G、CDMA、W-CDMA、3G、4G、LTE等)，诸如无线收 发机和相关联的硬件(例如，RF天线、调制解调器、调制器和/或解调器等)。 在另一示例中，配置成接收和/或传送信息的逻辑405可对应于有线通信接口 (例如，串行连接、USB或火线连接、能用来接入因特网175的以太网连接等)。 因此，如果通信设备400对应于某种类型的基于网络的服务器(例如，SGSN 160、GGSN 165、应用服务器170等)，则配置成接收和/或传送信息的逻辑 405在一示例中可对应于以太网卡，该以太网卡经由以太网协议将基于网络的 服务器连接至其它通信实体。配置成接收和/或传送信息的逻辑405可包括配置 成接收与至少一个分组的有效载荷有关的不透明数据的逻辑、配置成接收多个 数据分组的逻辑(每个分组包括头部以及媒体数据有效载荷)、以及配置成接 收与至少一个分组的有效载荷有关的不透明数据的逻辑(该不透明数据嵌入在 该至少一个分组的扩展头部中)。在进一步示例中，配置成接收和/或传送信息 的逻辑405可包括传感或测量硬件(例如，加速计、温度传感器、光传感器、 用于监视本地RF信号的天线等)，通信设备400可藉由该传感或测量硬件来 监视其本地环境。配置成接收和/或传送信息的逻辑405还可包括在被执行时允 许配置成接收和/或传送信息的逻辑405的相关联硬件执行其接收和/或传送功 能的软件。然而，配置成接收和/或传送信息的逻辑405不单单对应于软件，并 且配置成接收和/或传送信息的逻辑405至少部分地依赖于硬件来实现其功能 性。

参照图4，通信设备400进一步包括配置成处理信息的逻辑410。在一示 例中，配置成处理信息的逻辑410可至少包括处理器。可由配置成处理信息的 逻辑410执行的处理类型的示例实现包括但不限于执行确定、建立连接、在不 同信息选项之间作出选择、执行与数据有关的评价、与耦合至通信设备400的 传感器交互以执行测量操作、将信息从一种格式转换为另一种格式(例如，在 不同协议之间转换，诸如.wmv到.avi等)，等等。例如，配置成处理信息的逻 辑410可包括配置成生成多个数据分组的逻辑(每个分组包括头部以及媒体数 据有效载荷)、配置成接收与至少一个分组的有效载荷有关的不透明数据的逻 辑、配置成将该不透明数据嵌入该至少一个分组的扩展头部中的逻辑、配置成 接收多个数据分组的逻辑(每个分组包括头部以及媒体数据有效载荷)、以及 配置成接收与至少一个分组的有效载荷有关的不透明数据的逻辑(该不透明数 据嵌入在该至少一个分组的扩展头部中)。包括在配置成处理信息的逻辑410 中的处理器可对应于被设计成执行本文所描述功能的通用处理器、数字信号处 理器(DSP)、ASIC、现场可编程门阵列(FPGA)或其他可编程逻辑器件、 分立的门或晶体管逻辑、分立的硬件组件、或其任何组合。通用处理器可以是 微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微 控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处 理器的组合、多个微处理器、与DSP核心协同的一个或多个微处理器或任何其 它此类配置。配置成处理信息的逻辑410还可包括在被执行时允许配置成处理 信息的逻辑410的相关联硬件执行其处理功能的软件。然而，配置成处理信息 的逻辑410不单单对应于软件，并且配置成处理信息的逻辑410至少部分地依 赖于硬件来实现其功能性。

参照图4，通信设备400进一步包括配置成存储信息的逻辑415。在一示 例中，配置成存储信息的逻辑415可至少包括非瞬态存储器和相关联的硬件(例 如，存储器控制器等)。例如，包括在配置成存储信息的逻辑415中的非瞬态 存储器可对应于RAM、闪存、ROM、可擦除可编程和ROM(EPROM)、EEPROM、 寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储 介质。配置成存储信息的逻辑415还可包括当被执行时准许配置成存储信息的 逻辑415的相关联硬件执行其存储功能的软件。然而，配置成存储信息的逻辑 415不单单对应于软件，并且配置成存储信息的逻辑415至少部分地依赖于硬 件来实现其功能性。

参照图4，通信设备400进一步可任选地包括配置成呈现信息的逻辑420。 在一示例中，配置成呈现信息的逻辑420可至少包括输出设备和相关联的硬件。 例如，输出设备可包括视频输出设备(例如，显示屏、能承载视频信息的端口， 诸如USB、HDMI等)、音频输出设备(例如，扬声器、能承载音频信息的端 口，诸如话筒插孔、USB、HDMI等)、振动设备和/或信息可藉以被格式化以 供输出或实际上由通信设备400的用户或操作者输出的任何其它设备。例如， 如果通信设备400对应于如图3中示出的UE 300A或UE 300B，则配置成呈现 信息的逻辑420可包括UE 300A的显示器310A或UE 300B的触摸屏显示器 305B。在进一步示例中，对于某些通信设备，诸如不具有本地用户的网络通信 设备(例如，网络交换机或路由器、远程服务器等)而言，配置成呈现信息的 逻辑420可被省略。配置成呈现信息的逻辑420还可包括在被执行时允许配置 成呈现信息的逻辑420的相关联硬件执行其呈现功能的软件。然而，配置成呈 现信息的逻辑420不单单对应于软件，并且配置成呈现信息的逻辑420至少部 分地依赖于硬件来实现其功能性。

参照图4，通信设备400进一步可任选地包括配置成接收本地用户输入的 逻辑425。在一示例中，配置成接收本地用户输入的逻辑425可至少包括用户 输入设备和相关联的硬件。例如，用户输入设备可包括按钮、触摸屏显示器、 键盘、相机、音频输入设备(例如，话筒或可携带音频信息的端口，诸如话筒 插孔等)、和/或可用来从通信设备400的用户或操作者接收信息的任何其它设 备。例如，如果通信设备400对应于如图3中示出的UE 300A或UE 300B，则 配置成接收本地用户输入的逻辑425可包括小键盘320A、按键315A或310B 到325B中的任意一个、触摸屏显示器305B等。在进一步的示例中，对于某些 通信设备，诸如不具有本地用户的网络通信设备(例如，网络交换机或路由器、 远程服务器等)，可省略配置成接收本地用户输入的逻辑425。配置成接收本 地用户输入的逻辑425还可包括在被执行时允许配置成接收本地用户输入的逻 辑425的相关联硬件执行其输入接收功能的软件。然而，配置成接收本地用户 输入的逻辑425不单单对应于软件，并且配置成接收本地用户输入的逻辑425 至少部分地依赖于硬件来实现其功能性。

参照图4，尽管被配置的逻辑405到425在图4中被示出为分开或相异的 块，但将领会，相应各个被配置的逻辑用来执行其功能性的硬件和/或软件可部 分交迭。例如，用于促成被配置的逻辑405到425的功能性的任何软件可被存 储在与配置成存储信息的逻辑415相关联的非瞬态存储器中，从而被配置的逻 辑405到425各自部分地基于由配置成存储信息的逻辑415所存储的软件的操 作来执行其功能性(即，在这一情形中为软件执行)。同样，直接与被配置的 逻辑中的一个相关联的硬件可不时地被其它被配置的逻辑借用或使用。例如， 配置成处理信息的逻辑410的处理器可在数据由配置成接收和/或传送信息的 逻辑405传送之前将此数据格式化为适当格式，从而配置成接收和/或传送信息 的逻辑405部分地基于与配置成处理信息的逻辑410相关联的硬件(即，处理 器)的操作来执行其功能性(即，在这一情形中为数据传输)。

一般而言，除非另外明确声明，如贯穿本公开所使用的短语“配置成…的 逻辑”旨在援用至少部分用硬件实现的方面，而并非旨在映射到独立于硬件的 纯软件实现。同样，将理解，各个框中的被配置逻辑或“配置成…的逻辑”并 不限于具体的逻辑门或元件，而是一般地指代执行本文描述的功能性的能力 (经由硬件或者硬件和软件的组合)。因此，尽管共享措词“逻辑”，但如各 个框中解说的被配置逻辑或“配置成…的逻辑”不必被实现为逻辑门或逻辑元 件。从以下更详细地描述的各方面的审阅中，各个框中的逻辑之间的其它交互 或协作将对本领域普通技术人员而言变得清楚。

本公开的各个方面可以在各种可购买到的服务器设备(诸如图5中所解说 的服务器500)中的任一个上实现。在一示例中，服务器500可对应于上述应 用服务器170的一个示例配置。在图5中，服务器500包括耦合到易失性存储 器502和大容量非易失性存储器(诸如盘驱动器503)的处理器500。服务器 500还可包括耦合到处理器501的软盘驱动器、紧致碟(CD)或DVD碟驱动 器506。服务器500还可包括耦合到处理器501的用于建立与网络507(诸如 耦合到其它广播系统计算机和服务器或耦合到因特网的局域网)的数据连接的 网络接入端口504。在图4的上下文中，将领会，图5的服务器500解说了通 信设备400的一个示例实现，由此被配置成传送和/或接收信息的逻辑405对应 于被服务器500用来与网络507通信的网络接入点504，配置成处理信息的逻 辑410对应于处理器501，而配置成存储信息的逻辑415对应于易失性存储器 502、盘驱动器503和/或碟驱动器506的任何组合。被配置成呈现信息的可任 选逻辑420和被配置成接收本地用户输入的可任选逻辑425未在图5中显式示 出，并且可以被或可以不被包括在其内。由此，图5帮助展示通信设备400除 了如图3中的305A或305B的UE实现之外，还可被实现为服务器。

万维网联盟(W3C)所提出的实时通信Web(RTCWeb)标准试图定义浏 览器之间的实时对等(P2P)通信会话所需的必要互操作性规范。这些通信会 话一般涉及多媒体数据传输，诸如音频、视频或两者。然而，RTCWeb标准还 包括供web应用发起浏览器之间的数据流送会话的能力。

一种推荐的用于RTCWeb会话中的音频和/或视频的传输协议是实时传输 协议(RTP)。RCTWeb会话可包括一个或多个RTP流，其中每个流由包括在 RTP头部中的同步源(SSRC)来标识。

RTP标准中的现有机制可能不允许RTP会话端点以时间同步的方式呈现 多个SSRC。因此，提出了将允许RTCWeb端点明确地确定哪些SSRC是时间 同步的并且必需被如此呈现的数个机制。

即便时间同步的SSRC能够被关联起来，但仍然可能存在以下情况，其中 SSRC可能具有与同样应当被作为RTCWeb会话的一部分来流送的由应用生成 的数据(即，不透明数据)的时间关系。一个示例是在视频电话会话期间基于 web触摸事件的视频叠加。在这种情况下，web应用检测到视频预览上的动画 (基于终端用户使用设备触摸表面来绘制图像)，且该web应用被要求发送这 一信息到RTCWeb端点以使得动画能够被呈现。

每当不透明数据需要与媒体流协同地在接收方处呈现时，就需要将该不透 明数据与该媒体流进行时间同步。例如，在视频叠加情景中，发送视频流的应 用使用触摸事件API来捕捉用户在视频预览上绘画。应用随后对触摸事件格式 化并将其经由不透明数据流发送到接收方。不透明数据可以是与视频流中叠加 所在位置的像素相关联的坐标。接收方随后在本地显示器上同时呈现绘画动画 和视频流。

互联网工程任务组(IETF)已关注两种用于传送媒体和通用应用数据的传 输协议：用于媒体流的RTP和用于通用应用数据的流控制传输协议(SCTP)。

存在数种用于在各RTP流具有相同的主机端点但具有不同SSRC的情况下 同步各RTP流的方法。不同的SSRC意味着例如音频可能在一个RTP会话中 传送而视频在另一个RTP会话中传送。在一种方法中，当每个RTP流存在一 个SSRC时，可使用会话描述协议(SDP)编组机制。在另一方法中，可跨各 SSRC使用规范名称(CNAME)。在另一方法中，媒体流标识符(MSID)可 被用于对SSRC进行编组然而，这些编组机制仅适用于RTP传输。在任何给定 的标准化机制中都不处理不透明数据流同步。

一种可被采用在RTCWeb中用于数据流送的办法利用SCTP，而另一种办 法提供对会话描述协议(SDP)的必要扩展以描述SCTP流。SDP是在RTCWeb 中用来描述多媒体会话的机制，通常作为邀请或呼叫宣告的一部分。SDP消息 中的m行可包括足够的信息来描述SCTP会话(例如，明文SCTP、采用数据 报传输层安全(DTLS)的SCTP等)。例如，给定来自地址为xxx.xx.xx.xx的 提议方(offerer)、使用端口yyyy用于SCTP通信的SDP消息，则可能的SDP 提议(offer)将包括

m＝应用yyyyy SCTP*

c＝IN IP4 xxx.xx.xx.xx

如果存在由该提议方发送的需要与SCTP流同步的基于RTP的额外媒体 源，则理想的情况将是利用现有的SDP编组机制。SDP编组框架的mid(媒体 标识编组)属性也可能潜在地被利用。例如：

c＝IN IP4 xxx.xx.xx.xx

a＝组:LS 1 2

m＝应用yyyyy SCTP*

a＝mid:1

m＝视频zzzzz RTP/AVP

a＝mid:2

然而，这种办法存在一些问题，诸如在每个RTP流中存在多个SSRC的情 况。不过，SDP编组可提供足够的解决方案来将SCTP流同步到RTP流，只要 在每个RTP流只有一个SSRC。SDP编组应当还适用于多个SSRC是该提议的 一部分并且与CNAME相关联的情形，其中在该SDP中使用因源而异的媒体属 性的属性指南(例如，“a＝ssrc:<ssrc-id>cname:<cname>”以及“a＝mid:…”)。

在另一办法中，可利用带外机制(如MSID)来将SCTP端口号与RTP流 的SSRC相关联。例如，一种可能的SDP提议可包括：

m＝视频51372 RTP

a＝ssrc:1234 msid:examplefoo

m＝应用54321 SCTP*

a＝msid:examplefoo

然而，这一办法也存在问题。例如，在SCTP会话内协商的逻辑信道标识 符可能无法被访问以供包括在SDP属性中。SCTP中的逻辑信道比SSRC更加 动态，并且它们可出现在任何时候。另一问题是在SCTP中没有固有的时戳化， 因此无法确保同步。

又一办法提供了用于RTCWeb数据信道的SCTP封装式控制协议，该控制 协议利用了SCTP的多流送能力。SCTP允许针对任何给定数据块的个体流标 识符以及相关联的序列号。这允许对一个SCTP会话内的个体流进行流控制。 流还进一步通过作为逻辑信道请求的一部分的标签属性来标识。由于流是动态 的，因此要将任何给定时刻的SCTP流与RTP会话关联起来并不容易。另外， SCTP可以是多重初始地址的，即端点可以与不止一个IP地址相关联。

这种办法的一个问题是描述数据信道流的SDP属性应当基于逻辑信道标 签还是SCTP流ID的问题。另一个问题是如果SDP提议中提供的数据信道流 标识符与带内发送的信息不匹配，那么所需要的接收方行为是什么的问题。注 意，类似的问题对于使用CNAME和SSRC的RTP流也存在。

为了以更简单的方式来解决这些问题，针对RTCWeb提出了以下的方针： SDP编组机制不应针对SCTP会话中的个体流。换言之，一旦在RTP流和SCTP 会话间建立了时间关系，则该关系将应用于该SCTP会话中的所有流。

用于将不透明数据与相关的媒体流同步的另一种办法利用针对不透明数 据的RTP流送。例如，可在同一会话内发起一个分开的RTP流。然而，这仍 将要求这两个RTP流之间的时间同步。另外，在一些情况下，打开另一用户数 据报协议(UDP)套接字可能也不是无关紧要的。例如，无线运营商一般限制 在它们的网络中打开多个UDP套接字。此外，由于不透明数据传输通常是异 步且不频繁的，因此RTP休止定时器很可能生效并且卸除用于不透明数据的 RTP流。

替代地，不透明数据可以与主媒体复用。在这种情况下，RTP有效载荷将 在同一RTP分组中包括不透明数据继之以主媒体。然而，这一办法存在互操作 性问题，因为非兼容的应用将假设不透明数据是主媒体的一部分。这还违反RTP 标准。

在另一替代方案中，不透明数据可被嵌入到主媒体内。具体地，与不透明 数据相关联的比特可被嵌入到主媒体的比特句法内。然而，这将需要专门的编 码器/解码器，并且应用通常依赖于该平台上所流行的标准多媒体栈。

本公开的各个方面通过使用RTP扩展头部来发送在RTP媒体流中复用的 周期性的不透明数据而克服了这些和其他问题。这具有使得用于RTP的同步机 制能够被用于不透明数据的优点。接收方识别扩展头部并将数据转发到web应 用。取决于RTP实现，还可将扩展头部用于除了不透明数据传输以外的目的。 例如，扩展头部字段的前两个八位位组可被用于定义因应用而异的用途。

在本公开的各个方面，假定RTP是多媒体会话中的底层媒体传输信道。 RTP扩展头部可被用于协同主媒体(诸如视频/音频)递送任意或者不透明的媒 体或数据。具体地，不透明数据可被包括在RTP扩展头部内，而同一RTP分 组的RTP有效载荷携带对应的主媒体。不透明数据利用主媒体的标准RTP头 部内的RTP时戳来实现不透明数据和主媒体之间的时间同步。也就是说，在目 标设备上的播出期间，相同的RTP时戳可被用于不透明数据和主媒体。如此， 在例如视频聊天会话中，如果第一用户在他或她的UI上画了一个动画，则视 频将在RTP有效载荷中被传输，而该动画将在属于同一RTP分组的RTP扩展 头部中被传输。

这一机制假定不透明数据占用远小于主媒体的带宽。也就是说，不透明数 据将需要比主媒体小的吞吐量(在大部分情况下)。此外，假定了不透明数据 的传输与主媒体相比是较不频繁的。

如本文所使用的，术语“主媒体”指的是在多媒体会话中的RTP分组中携 带的媒体，例如视频、图像、音频等。术语“不透明数据”指的是在还携带主 媒体的RTP分组的扩展头部中携带的因应用而异的、不透明的、或任意的数据 或媒体。术语不透明数据、不透明媒体、任意数据、任意媒体、以及因应用而 异的数据在本文被可互换地使用。

在一个方面，RTP扩展头部可包含传递不透明数据的细节的简档字段(例 如，2字节的值)。简档可在应用级协商(有可能是带外的)。与扩展头部中 的不透明数据相关联的简档字段中的简档标识符能够映射到生成该不透明数 据的“源”。因此，在给定RTP会话中，如果RTP扩展头部存在，则RTP分 组会携带主媒体以及不透明数据，否则如果不存在RTP扩展头部，则仅携带主 媒体。

图6解说了具有扩展头部以及不具有扩展头部的RTP分组的示例。示例性 RTP分组610包括标准RTP头部602以及RTP有效载荷604。示例性RTP分 组620包括标准RTP头部602、RTP有效载荷604、以及RTP扩展头部606。 RTP有效载荷604包含主媒体(诸如视频数据)，而RTP扩展头部606包含对 应于RTP有效载荷604的不透明数据。

图7解说了具有RTP头部700、扩展头部710以及有效载荷712的示例性 RTP分组。RTP头部700可包括序列号702、时戳704、SSRC标识符706、以 及可选的贡献源(CSRC)标识符708。RTP分组可进一步包括可选的扩展头部 710，扩展头部710可包括简档标识符716、头部扩展长度718、以及头部扩展 数据714。头部扩展数据714可包括对应于有效载荷712的不透明数据。

在RTP头部700中，扩展位X可被设置以用于指示扩展头部710的存在。 扩展头部710中的16位简档标识符716的值可以是因实现而异的。这一字段 可替代基于SCTP的数据信道中的信道标签来使用。否则，这一字段可被接收 方所忽略。

将扩展头部用作不透明数据传输手段的信令可由两个端点通过类似SDP 之类的提议/应答协议来商定。可使用带外信令信道来指示接收方基于RTP扩 展头部创建数据信道。在这种情况下，还可使用新的因源而异的属性(诸如‘数 据’:a＝ssrc:<ssrc-id>数据)来利用SDP中的各个因源而异的媒体属性。然而， SDP交换不是严格必需的，因为RTP流的SSRC已经被协商，并且扩展头部事 实上是RTP媒体流数据的一部分。

web应用可以按照底层用户代理将使用RTP扩展头部来将应用数据复用到 现有的RTP流上的方式来利用来自RTCWeb规范中的基于消息的数据信道 API。随后，从提议方的角度来看，对等连接设置可照常进行。表1解说了使 用JavaScript会话建立协议(JSEP)的示例性消息收发流。注意在表1中，“JS” 表示JavaScript，而“UA”表示用户代理。

表1

在以上办法中，创建带有数字标签的数据信道触发OffererUA(提议方用 户代理)使用扩展头部。数字标签可作为扩展头部中的简档字段的一部分来直 接发送，条件是数字标签不超过16比特。带有扩展头部的RTP数据的初次接 收触发onDataChannel事件从AnswererUA(应答方UA)激发。

图8解说了发送方802和接收方804之间的示例性P2P呼叫流800。在810， 网络以RTP作为传输协议来执行发送方802和接收方804之间的会话协商。发 送方802随后开始发送包括多个标准RTP分组的媒体流，如虚线所示。

在820，发送方802开始接收由例如用户在UI上绘画所生成的不透明数据。 这致使发送方802生成并发送多个具有扩展头部的RTP分组，如实线所示。在 发送方802侧，构建RTP分组，使得生成不透明数据和主媒体的时刻是相同的。 不透明数据被包括在扩展头部中，而主媒体被包括在RTP有效载荷中。在接收 方804侧，包含在扩展头部内的不透明数据与包含在RTP分组中的有效载荷同 时显示。

在830，发送方802停止接收由用户在UI上绘画所生成的不透明数据，因 为例如用户已停止绘画。发送方802继续作为标准RTP分组来传送媒体流，直 到用户之一开始在他或她的UI上绘画或者生成某种其它形式的不透明数据。

图9解说了包括一个发送方902和两个接收方904和906的一群用户之间 的示例性P2P呼叫流900。在910，网络以RTP作为传输协议来执行发送方902 与接收方904和906之间的会话协商。发送方902随后开始发送包括多个标准 RTP分组的媒体流，如虚线所示。

在920，发送方902开始接收由例如用户在UI上绘画所生成的不透明数据。 这致使发送方902生成并发送多个具有扩展头部的RTP分组，如实线所示。在 发送方902侧，构建RTP分组，使得生成不透明数据和主媒体的时刻是相同的。 不透明数据被包括在扩展头部中，而主媒体被包括在RTP有效载荷中。

在930，发送方902停止接收由用户在UI上绘画所生成的不透明数据，因 为例如用户已停止绘画。发送方902继续作为标准RTP分组来传送媒体流，直 到用户之一开始在他或她的UI上绘画或者生成某种其它形式的不透明数据。

图10解说了用于采用中间媒体服务器1070并且具有后加入目标1006的 示例性呼叫流。在加入之后，后加入目标1006需要得到会话的上下文。因此， 媒体服务器1070可高速缓存不透明数据，以使得一旦后加入目标1006成为会 话的一部分，媒体服务器1070就可将不透明数据转发给后加入目标1006。在 接收“最新”的主媒体之后，后加入目标1006可叠放或处理不透明数据。因 此，会话中的所有参与者将具有相同的上下文。

在1005，发起方1002发送呼叫邀请给目标1004和1006，但只有目标1004 确收。媒体服务器1070以RTP作为传输协议来执行发起方1002和目标1004 之间的会话协商。如1010处所示，后加入目标1006当前还不是会话的一部分。 发起方1002随后开始发送包括多个标准RTP分组的媒体流，如虚线所示。

在1015，发起方1002开始接收由例如用户在UI上绘画所生成的不透明数 据。这致使发起方1002生成并发送多个具有扩展头部的RTP分组。在发起方 1002侧，构建RTP分组，使得生成不透明数据和主媒体的时刻是相同的。不 透明数据可被包括在扩展头部中，而主媒体被包括在RTP有效载荷中。在1020， 媒体服务器1070高速缓存当前正共享的任何不透明数据。

在1025，发起方1002停止接收由用户在UI上绘画所生成的不透明数据， 因为例如用户已停止绘画。发起方1002继续作为标准RTP分组来传送媒体流， 直到用户之一开始在他或她的UI上绘画或者生成某种其它形式的不透明数据。

在1030，后加入目标1006决定加入群呼叫。在1035，媒体服务器1070 发起SDP协商。后加入目标1006现在成为会话的一部分。媒体服务器1070可 将目前为止该呼叫中已生成的任何不透明数据转发给后加入目标1006。在 1040，后加入目标1006上的应用可不对被转发的不透明数据采取动作，直到 接收到足够的RTP分组。在这段时间期间，目标1004和后加入目标1006继续 接收标准RTP分组。在1045，后加入目标1006上的应用现在具有足够的RTP 分组来使用不透明数据，且该应用在恰当时呈现不透明数据。

图11解说了根据本公开的一方面的用于无线通信的示例性流程。图11的 流程可由UE(诸如UE 102、108、110、112、300A或300B)来执行。

在1110，UE生成多个数据分组，每个分组包括头部和媒体数据有效载荷。 头部可以是RTP头部。媒体数据可以是视频、图像和/或音频数据中的至少一 者。

在1120，UE接收与至少一个分组的有效载荷有关的不透明数据。不透明 数据可以是与这多个数据分组有关的由用户生成的数据。由用户生成的数据可 以是例如因用户在用户接口上描绘而生成的坐标数据。替代地，不透明数据包 括由应用自动生成的与该多个数据分组有关的数据。

在1130，UE将不透明数据嵌入在该至少一个分组的扩展头部中。扩展头 部可包括标识简档的简档标识符字段，简档指示目标用户设备如何处理该不透 明数据。

在1140，UE在该至少一个分组的头部中设置扩展头部字段以指示该至少 一个分组包括不透明数据。尽管1130和1140被解说为顺序进行，但它们可以 按相反的顺序进行(即先1140再1130)或者同时进行。

在1150，UE将该多个数据分组传送给目标用户设备。不透明数据和该至 少一个分组的有效载荷可由接收该多个分组的目标用户设备同时播放。

图12解说了根据本公开的一方面的用于无线通信的示例性流程。图12的 流程可由UE(诸如UE 102、108、110、112、300A或300B)或服务器(诸如 应用服务器170或媒体服务器1070)来执行。

在1210，UE/服务器接收多个数据分组，每个分组包括头部和媒体数据有 效载荷。头部可以是RTP头部。媒体数据可以是视频、图像和/或音频数据中 的至少一者。

在1220，UE/服务器接收与至少一个分组的有效载荷有关的不透明数据， 该不透明数据被嵌入在该至少一个分组的扩展头部中。扩展头部可包括标识简 档的简档标识符字段，简档指示目标用户设备如何处理该不透明数据。不透明 数据可以是与该多个数据分组有关的由用户生成的数据。由用户生成的数据可 以是例如因用户在用户接口上描绘而生成的坐标数据。替代地，不透明数据包 括由应用自动生成的与该多个数据分组有关的数据。

在1230，UE/服务器在该至少一个分组的头部中检测到指示该至少一个分 组包括不透明数据的扩展头部字段。

在1240，UE/服务器根据简档标识符字段中标识的简档来处理该不透明数 据。如果UE正执行图12中解说的流程，则UE可同时播放该不透明数据和该 至少一个分组的有效载荷。如果服务器正执行图12中解说的流程，则服务器 可高速缓存该不透明数据并在目标用户设备加入进行中的群呼叫时将该不透 明数据传送给目标用户设备。

本公开的各个方面提供了多个优点。例如，不需要单独的信道或并行协议 来传递不透明数据。此外，各个实施例使用主媒体固有的RTP时戳用于对不透 明数据进行时间同步。此外，互操作性不再是问题，因为RTP扩展头部如果不 被应用理解则可被忽略。此外，不需要对主有效载荷或RTP有效载荷作任何修 改，因为不透明数据是在同一RTP分组内独立地传递的。

不透明数据可影响与主媒体有关的吞吐量，因为添加扩展头部增加了分组 大小。然而，不透明数据的传输很可能是不频繁的且占用远小于主媒体的带宽。

各个方面需要因应用而异的逻辑的事实不再是问题，因为这是一个应用对 应用的特征。此外，与不透明数据相关联的简档的带外协商也不再是问题，因 为这一协商对于任何因应用而异的特征都适用。

存在RTP扩展头部的其它用途。这些用途包括快速同步特征(这允许定时 元数据被插入到RTP流中)、客户机到混音器音频电平、以及混音器到客户机 音频电平。扩展头部的这些用途可消耗的简档空间可避免用于也使用头部扩展 的逻辑数据信道。

本领域技术人员将领会，信息和信号可使用各种不同技术和技艺中的任何 一种来表示。例如，以上描述通篇可能引述的数据、指令、命令、信息、信号、 位(比特)、码元、和码片可由电压、电流、电磁波、磁场或磁粒子、光场或 光粒子、或其任何组合来表示。

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

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

结合本文公开的方面描述的方法、序列和/或算法可直接在硬件中、在由处 理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM、 闪存、ROM、EPROM、EEPROM、寄存器、硬盘、可移动盘、CD-ROM或本 领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使 得该处理器能从/向该存储介质读写信息。替换地，存储介质可以被整合到处理 器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端(例如， UE)中。替换地，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性方面中，所描述的功能可在硬件、软件、固件或其任 何组合中实现。如果在软件中实现，则各功能可以作为一条或多条指令或代码 存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介 质和通信介质两者，包括促成计算机程序从一地向另一地传递的任何介质。存 储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计 算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁 盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的期望 程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机 可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线 (DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务 器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸 如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本 文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数 字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据， 而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可 读介质的范围内。

尽管前面的公开示出了本公开的解说性方面，但是应当注意在其中可作出 各种变更和修改而不会脱离如所附权利要求定义的本发明的范围。根据本文中 所描述的本公开的方面的方法权利要求中的功能、步骤和/或动作不一定要以任 何特定次序执行。此外，尽管本公开的要素可能是以单数来描述或主张权利的， 但是复数也是已料想了的，除非显式地声明了限定于单数。