专利名称：向设备发送信令以不执行同步或在多媒体流上包括同步延迟的方法
技术领域：
本发明一般涉及IP多媒体通信领域。更特别地，本发明涉及用 于多媒体通信的信令机制以指令接收设备不执行同步或包括不同多 媒体流之间的同步抖动。
背景技术：
在IP多媒体呼叫建立期间，呼叫的发送设备(即提供端或发启 端)指定会话信息。会话信息包括媒体和与传输相关的信息。会话
信息承载于例如会话描述协议(SDP)的协议消息中。SDP承载于例 如会话发起协议(SIP)和实时流协议(RTSP)等的高级信令协议中。 第三代合作伙伴项目(3GPP)将SIP指定为IP多媒体子系统(IMS) 的多媒体会话建立的信令协议的选择。
在SDP中，发送设备和接收设备可以为多媒体流指定不同的方 向，从而得到不同类型的应用。例如，如果发送设备希望建立单向 媒体会话(即其希望发送视频并且希望接收设备只接收该视频)， 则其在SDP中指定该々某体流为a-sendonly。当接收设备接收该SDP 消息时并且如果其希望参与到该会话中，则接收设备可以指定该流 为a=recvonly。对于视频电话呼叫，发送设备和接收设备都指定力某 体流的方向为a=sendrecv。
通常，在IP多媒体呼叫中，在接收设备侧存在同步不同媒体类 型的需求。例如，在音频/视频IP呼叫中，为了好的用户体验需要 在接收设备侧执行唇音同步。同步的另一个示例涉及字幕的使用； 如果音频和/或视频的发送端正在说英语并且如果在讲话的同时，在 不同的实时传输协议(RTP)流中在用不同的语言发送讲话的文字， 则需要在接收设备侧同步这两个流。不同的媒体流(来自发送设备侧)承载于不同的RTP/用户数据 协议(UDP ) /互联网协议(IP )流中。RTP时间戳被接收设备客户端 用来执行媒体间同步。
图1描述了从发送设备接收多媒体流的接收设备。横轴表示逝去 的时间并且示出接收的分组。图1中示出的音频和视频緩冲器在从 发送设备接收分组时保存RTP分组。緩冲器执行抖动消除(来自网 络的)并且为每个々某体的每个分组计算播出时间(playout time)。 一旦分组在緩冲器中保留了一段给定的时间，则执行解码。该时间 段通常是变化的并且该时间段的 一 部分称为抖动。 一 旦基于播出时 间完成了解码，则将分组用于显示或用于播放。应当理解，可以有 两个不同的緩冲器用于保存进入的RTP分组-一个用于抖动， 一个 用于解码排队。为了清晰和示例性的目的，在图l中仅示出了一个 排队，其中示出了结合的抖动和解码緩冲器。解码后， 一旦经过了 播出时间，分组就可以用于播放或显示。然而，如果接收设备试图 执行音频/视频同步，则其将试图延迟首先到达的分组。
在图1所示的示例中，音频分组1在TA1处到达，并且一见频分组 在时间上较晚于TA1的TV1处到达。应当理解，术语"到达"可以 代表分组到达的时间或每个分组的播出时间。在图l的示例中，需 要同步具有相同的播放时间的音频和视频分组，因为它们具有相同 的基准时钟捕获时间(在发送设备处)，即在发送设备处它们是在 相同的时间得以采样。使用在RTP分组中的RTP时间戳和在RTCP发 送端报告(SR)分组中发送的NTP时间戳，执行基准时钟捕获时间 的计算。音频和视频分组很有可能在不同的时间到达接收设备处， 因为它们可能经过不同的网络路径，并且每个分组的处理延迟(编 码，分组化，解分组化，解码)可以不同。因此在图l所示的示例 中，必须将音频分组延迟TV1-TA1的时间段，其为同步抖动或延迟。
在图l所示的示例中，如果应用(或发送端)不试图执行A/V 同步，但接收设备仍然试图执行同步(因为其为默认的行为)，则 接收设备将被迫将音频分组保存额外的时间。该动作有可能使音频 緩冲器溢出。此外，当试图同步时，在排队的开头的音频分组被延迟，这可以导致差的用户体验或媒体质量。如果要保障服务质量
(QoS)，则在音频和视频分组在排队中有较大的延迟的情况下，将
不得不被丢弃。因此，虽然发送设备可能不希望媒体流被同步，但 由于缺乏发送设备可以向接收设备指示不需要同步或延迟的同步的 机制，可能会发生例如分组丟失、延迟的分组和浪费计算资源的问题。
在互联网工程任务组的网络工作组的请求说明(RFC) No. 3388 中，指定了发送设备可以明确地指定需要同步会话中的哪些媒体流 的机制。定义了新的SDP属性(例如"group" 、"mid"和唇音同 步(LS))，这可以帮助发送设备指定需要对会话中的哪些媒体流 进行唇音同步。另外，RTP接收设备的默认实现行为是同步从相同的 源接收的媒体流。此外，规范未规定如果必须同步多媒体流，则要 求RFC 3388。 RFC 3388只指定了可以使发送设备在其发送两个或多 个流的情况下指定需要同步哪些流的机制。
存在要求多媒体流不应当被同步的应用和使用情况。例如，在实 时视频共享(RTVS)应用中，用户开始单向视频共享会话。通过在 SDP中将媒体流声明为a=sendonly或a=recvonly，建立单向媒体会 话。在两方之间已经存在双向(或可以是单向)音频会话建立。呼 叫中的一方希望与另一方共享视频。尽管有可能音频或视频会话也 可以建立在电路交换载体上，但在IP载体上建立音频和视频。共享 的视频可以是来自文档或来自现场的摄像镜头。
在单向视频共享的某些情况下，发送设备不希望同步视频(共享 自文档的)和讲话。不期望进行同步的一个原因可能是发送设备希 望在接收设备处接收到高质量的视频，虽然有延迟。在此情况下， 发送设备希望接收设备具有较大的延迟緩冲器并且因此不希望执行 同步。
单向视频共享的另一个示例涉及用户正在拍摄某个物体的视频 并且在谈论该物体。在此情况下，粗劣形式的同步就足够了，不必 进行完美的同步，因为此人不是在拍摄其自己的脸部的视频而是拍 摄不同的物体。又一个示例涉及"扩大的真实感"，其中将图形与实时音频和视频混合。在此情况下，粗劣形式的同步将可以满足要 求。
如果客户端的默认行为是同步这两个流，则接收设备客户端将采 用特别的算法以同步这些流。在接收设备侧的同步算法将要求指定 量的计算复杂性，并且甚至在当发送设备不希望任何同步时，客户 端也将浪费某些资源。音频和视频流到达接收设备时可以具有不同 的延迟。如果接收设备试图同步这些流，则将导致音频和视频帧的 丢弃，因此降低了接收的媒体的质量。
遗憾的是，RFC 3388未讨论可以明确地确定哪些流不应当被同 步的机制。例如，如果发送设备希望在会话中发送三个流，两个音 频流(Al和A2)和一个视频流(VI),并且发送设备希望同步(唇 音同步)流Al和VI，则其可以使用group、 mid-SDP属性和LS语义 标签加以指定。这将为接收设备指示Al和VI需要进行同步而A2不 需要进行同步。但对于有两个或多个流并且不需要流同步的使用情 况，RFC 3388存在不足。另外，为指示唇音同步的性能(并且在某 些情况下RFC 3388可以用于指定无唇音同步)，RFC 3388必须被强 制执行。最后，RFC 3388不提供用来使设备可以指示在不同的媒体 之中的期望的同步抖动的机制。
出于上述原因，目前没有使发送设备可以为多媒体呼叫中的接收 设备指示不同步由发送设备传输的多媒体流的机制，也不存在为多 媒体流指定同步延迟或抖动的机制。
发明内容
本发明提供 一 种机制，其中传输或发送设备可以明确地指示被发 送的多媒体流中的哪些流不应当被同步或应当包括指定的同步抖动 量。该机制帮助接收设备理解流特性，并且允许接收设备做出关于 是否应当执行同步以及是否指定同步抖动值的被告知的决定。对于 例如单向视频共享或视频PoC的某些应用，流的发送设备可以指示 接收设备为了更好的媒体质量不执行任何同步。
本发明的一个实施例涉及若干新SDP属性的引入。发送设备将在会话建立阶段期间在SDP中声明这些属性，并且这些属性可以承载 于任何高级信令协议(例如SIP、 RTSP等)中。然而，这些属性不 限于SDP协议的使用，并且这些属性可以使用在ISO 0SI协议栈的 阶层1-7的任何一层上的任何其他的通信协议(例如XML、 HTTP、 UPnP、 CC/PP等)进行定义和承载。
本发明通过在会话建立阶段期间提供指示发送设备不在媒体流 中间进行同步的选择的能力，为常规的RFC 3388框架提供了实质性 的益处。存在发送设备不希望其发送的媒体被同步的使用情况和应 用。当该选择可以以信令发送给接收设备时，接收设备可以相应地 建立资源并且不必浪费可用于其他任务或用于更好的媒体质量的计 算资源。作为结果，本发明导致了在接收设备处的较少的分组丢失， 否则如果接收设备试图执行媒体流同步，将发生分组丟失。
除上述之外，本发明通过在会话建立阶段期间提供指示发送设备 在媒体流之间的同步抖动的选择的能力改进了 RFC 3388。由于也存 在发送设备希望发送的媒体进行具有粗劣抖动的同步的使用情况和 应用，将该选择用信令发送到接收设备的能力允许接收设备相应地 建立资源。这也提供了节省计算资源的机会。在某些情况下，这还 可以产生媒体质量等级的改善。事实上，在强制媒体同步的情况下， 由于在接收设备处的数据丢弃或其他原因，可能有某些分组丢失， 如果接收设备试图执行媒体流同步，就可能发生分组丢失。这是由 于这样的事实，即媒体数据到达接收设备时有不同的延迟，这将导 致某些内容过迟地到达，而不可用于完全同步的播放。通过控制同 步抖动，可以减轻或消除此问题。
本发明的这些和其它目标、优点和特征以及其组织和操作方式将 从下面结合附图的详细描述中变得显而易见，其中贯穿以下附图相 同的元件将具有相同的标号。
图1是示出了多个音频和视频分组从发送设备到接收设备的传 输的表示，其中虽然发送设备不要求同步，但接收设备执行同步；图2为用于本发明的实现方式的电子设备的透视图3是图1的电子设备的电路的示意性表示；以及
图4是示出了本发明的一个实施例的一般实现方式的流程图。
具体实施例方式
本发明提供一种机制，其中传输或发送设备可以明确地指示被发 送的多媒体流中的哪些流不应当被同步或应当包括指定量的同步抖 动。该机制帮助接收设备理解流特性，并且允许接收设备做出是否 应当执行同步以及是否指定同步抖动值的被告知的决定。
为理解本发明的实现方式，图1可用于基于发送设备在会话建立 阶段期间通知接收设备其希望接收设备不执行任何同步或使用具体 值(例如500毫秒)执行具有粗劣同步延迟或抖动的同步。在此情 况下，当已经完成解码并且每个媒体流的每个分组已经到了播出时 间，接收设备可以提供相应的分组以便呈现。接收设备对分组进行 的延迟不需长于指定的值。这可以用于防止抖动緩冲器溢出的问题， 不为同步的目的而延迟分组，并且改善了媒体质量。在此情况下， 接收必须独立地管理两个没有任何相互关系的媒体排队。
在发送设备希望接收设备执行具有指定的延迟值的某些同步的 情况下，接收设备在解码之后确定音频和视频分组的播出时间之间 的差(TV1-TA1 )。如果该值小于在会话建立中为同步抖动定义的值， 则接收设备不需要将音频和视频分组保存比播出时间指示的时段较 长的时段。如果值(TV1-TA1)大于同步抖动，则接收设备需要将分 组保存一短的时间段。例如，如果在会话建立期间指定的同步抖动 为5 00毫秒并且TV1-TA1为350毫秒，则接收设备不需要进行任何 指定。然而，如果TV1-TA1为600毫秒，则音频分组必须在排队中 延迟额外的100毫秒。
在本发明的第一实施例中，指定了两个机制，以允许多媒体流的 发送设备指示多媒体流不应当被同步。该实施例涉及新SDP参数的 引入，该新SDP参数帮助多媒体流的发送设备指定接收设备不应当 执行同步。在第一机制中，引入了称为"NO — SYNC"的新SDP属性。"NO —SYNC" 指示该流不应当与会话中的任何其他多媒体流进行同步。将该 N0-SYNC属性声明为a=N0 —SYNC。
该NO-SYNC属性可以在J;某体级(即在SDP中的m行之后)或可以 在会话级上得以定义。当在媒体级上定义之后，NO-SYNC属性意味着 该媒体流不应当与会话中的任何其他流进行同步。使用NO-SYNC属 性的示例如下
v=0
o=NRC 289084412 2890841235 IN IP4 123.124.125.1 s=D6mo
c=IN IP4 123. 124. 125. 1 m=video 6001 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=N0—SYNC
m=video 5001 RTP/AVP 99 a=rtpmap 99 H2.63/90000 m-audio 6001 RTP/AVP 98 a=rtpmap: 98 AMR
在以上示例中，在接收设备处第一视频流不应当被同步。当接收 设备客户端接收该SDP时，其知道不应当将任何其他流与该视频流 (具有MPEG4编解码器)进行同步。接收设备可以选择同步或不同 步其余的(音频和视频)流。
NO — SYNC属性可以在会话的开始处得以声明，这暗示了会话中的
所有的流都不应当进行同步。其描述如下 v=0
o=NRC 289084412 2890841235 IN IP4 123.124.125.1 s=Demo
c=IN IP4 123.124.125.1
a=N0_SYNC
m=video 6001 RTP/AVP 98a=rtpmap:98 MP4V-ES/90000 m=audio 6001 RTP/AVP 98 a=rtpmap: 98 AMR
在以上示例中，发送设备指示接收设备该会话中的所有的流都不 应当进行同步。
在另一个实现方式的示例中，可以定义RFC 3388的扩展。该扩 展可用于指定哪些流应当被同步。以下为常规RFC 3388系统的示例， 其展示了在SDP中如何指示同步
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0
c=IN IP4 224. 2.17.12/127 a=group:LS 1 2 m=audio 30000 RTP/AVP 0 a=mid: 1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
在以上的示例中，具有mid 1和mid 2的流:故同步。这是用group 属性中的LS语义标签来指示的。然而，利用新的实现方式，使用具 有group属性"NLS"的新的语义标签，其具有不同步的语义。以下 的示例示出了如何提供关于流不应当与在会话中的任何其他的流进 行同步的指示
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com 1=0 0
c=IN IP4 224.2.17.12/127 a=group: NLS 1
13m=audio 30000 RTP/AVP 0 a=mid:1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
在以上的示例中，具有mid 1的流不与会话中的任何其他流进行 同步。因此，RFC 3388可以利用该新的语义标签进行扩展，这将帮 助发送设备指示媒体流不要求同步。
语义标签LS和NLS可用于相同的会话描述中以描述哪些流需要 同步而哪些流不需要同步。例如，在以下描述的SDP示例中，流l 不应当与会话中的任何其他流进行同步，而流2和流3应当得以同 步。以此方式，发送设备可以明确地描述哪些流应该进行同步而哪 些流不需要同步。
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0
c=IN IP4 224.2.17.12/127 a=group:NLS 1 a=group:LS 2 3 m=audio 30000 RTP/AVP 0 a=mid: 1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
在本发明的第二实施例中，引入了允许多媒体流的发送设备指示 在其希望接收设备进行同步的多媒体流之间的同步延迟和抖动值的机制。在此实施例中，新SDP参数用于指定抖动值，利用这些SDP
属性，发送设备还可以指定在给定的多媒体会话中的哪些流不应当 与在相同的会话中的任何其他流进行同步。
在该实施例的一个具体的实现方式中，定义称为"sync —jitter" 的新SDP属性。该属性指示多媒体流之间的同步延迟。sync-jitter SDP属性以时间单位(例如毫秒)或任何其他合适的单位来指定。 sync-jitter的0的值意味着不应当执行同步。在SDP中将属性声明 为
a=sync — j i t ter: value //值例如为毫秒。
sync—jitter SDP属性可与group和mid属性以及LS语义标签 (如在RFC 3388中定义的)结合使用。当与该属性一起使用时， sync_jitter指定在如LS语义标签所指定的需要同步的流之间的可 接受的同步抖动。以下为RFC 3388的示例，其描述了在SDP中如何 常^L地指示同步 v=0
o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0
c=IN IP4 224. 2.17. 12/127 a-group:LS 1 2 m-audio 30000 RTP/AVP 0 a=mid: 1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
在以上的示例中，具有mid 1和mid 2的流要进行同步。这是用 在group属性中的LS语义标签来指示的。然而，在此示例中，无法 指示在具有mid l和mid 2的流之间的期望的同步抖动。取决于不 同的应用(例如单向^L频共享或实时对话;f见频电话)，同步值将不同。
以下示例利用sync-jitter属性扩展上述示例。如果上述SDP 描述是用于单向视频共享应用，并且如果粗劣形式的同步将满足特 定情况的要求，则发送设备可以例如针对具有mid l和mid 2的流 之间的同步抖动使用500毫秒的值。在此情况下，SDP将如下
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com 1=0 0
c=IN IP4 224. 2.17. 12/127 a=group:LS 1 2 a=sync—jitter: 500 m=audio 30000 RTP/AVP 0 a=mid: 1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
sync_jitter属性可以使用O值。0值特别指定了发送设备不希 望特定的媒体流与在给定的会话中的任何其他流进行同步。如前所 述，默认的实现方式是执行同步，并且如果发送设备SDP实现方式 不支持RFC 3388，则发送设备可以使用值为0的sync —jitter属性以 指示其不希望会话中的给定的流与任何其他流进行同步。发送设备 指定sync-jitter值为0的SDP示例如下
v=0
o=NRC 289084412 2890841235 IN IP4 123.124.125.1 s=Demo
c=IN IP4 123.124.125.1 m=video 6001 RTP/AVP 98 a=rtpmap: 98MP4V-ES/90000 a=sync — j i t ter: 0 m=video 5001 RTP/AVP 99 a=rtpmap 99 H2. 63/90000 m=audio 6001 RTP/AVP 98 a=rtpmap: 98 AMR
在以上的示例中，发送设备不希望第一视频流(具有MPEG-4) 与会话中的任何其他流进行同步。接收设备可以选择是否同步在会 话中给定的其余的两个流。
应当理解，有可能需要为sync_jitter选择非0的适当的值，以 指示不要求同步，因为O将具有不同的语义。
图4为示出本发明实施例的实现方式的一般流程图，其中发送设 备指明不进行同步或引入同步抖动的某个值。在图4的步骤300中， 发送设备传输SDP信息。SDP信息包括关于被传输的多媒体流的同步 的以上讨论的类型的引入。在步骤310中，接收设备接收SDP信息。 在步骤320中，接收设备读取SDP信息以确定是否存在不同步任何 或所有多媒体流的指令，是否包括某个数量的同步抖动，或是否应 当进行完全的同步。如果存在不进行同步的指令，则在步骤330中 遵循该指令。如果存在同步抖动值，则在步骤340处将指明的抖动 量引入到流中。如果不存在关于缺乏同步或同步抖动数量的指令， 或如果存在完全同步的具体指令，则在步骤350进行完全同步。
图2和图3示出了一个在其中可以实现本发明的代表性电子设备 12。图2和图3中的电子设备包括移动电话并且可以用作发送设备 或接收设备。然而，还应该理解，本发明不限于电子设备的一种特 定类型。例如电子设备12可以包括个人数字助理(PDA) 、 PDA和移 动电话的结合、集成的消息发送设备(IMD)、台式计算机、笔记本
计算机或各种其他设备。
图2和图3中的电子设备12包括外壳30、液晶显示器形式的显 示器32、小键盘34、麦克风36、耳机38、电池40、红外端口42、 天线44、以根据本发明一个实施例的UICC形式的智能卡46、读卡器48、无线接口电路52、编解码器电路54、控制器56和存储器58。 各个电路和元件全都是现有技术已知的类型，例如诺基亚移动电话 的范围。
用方法步骤的一般上下文描述了本发明，在一个实施例中其可以 由程序产品实现，其中程序产品包括计算机可执行指令，例如可以 由在联网环境中的计算机执行的程序代码。
通常，程序模块包括例程、程序、对象、组件、数据结构等，其 可以执行特定的任务或实现特定的抽象数据类型。计算机可执行指 令、相关数据结构和程序模块代表用于执行在此公开的方法步骤的 程序代码的示例。这样的可执行指令的特定序列或相关数据结构代 表用于实现在这样的步骤中描述的功能的相应动作的示例。
本发明的软件和web实现方式可以用标准的编程才支术来完成，该
骤、相关步骤、比较步骤和判决步骤。还应当理解，在此和在权利 要求书中使用的词汇"组件"和"模块"旨在包括使用一行或多行 软件代码的实现、和/或硬件实现、和/或用于接收手动输入的设备。
为了说明和描述的目的，给出了上述的对本发明的实施例的描 述。不旨在穷举或将本发明限制于公开的精确的形式，根据上述启 示的修改和变形是可能的或可以从本发明的实践中获得。为了解释 本发明的原理选择和描述了这些实施例，其实际的应用可使得本领 域技术人员以各种实施例和各种修改利用本发明作为所遇到的特定 用途的适当解决方案。
权利要求
1.一种提供用于多个多媒体流的同步信息的方法，包括将多个多媒体流传输到接收设备；以及传输关于该多个多媒体流的信息，该信息包括用于该接收设备的具体指令，以允许不进行同步或允许在多个多媒体流的至少一个和多个多媒体流的至少一个其他流之间的指定的同步延迟量。
2. 根据权利要求1所述的方法，其中该指令作为在传输到该接 收设备的会话信息中的属性得以包括。
3. 根据权利要求1所述的方法，其中该指令包括在该多媒体流 的至少两个流之间的可接受的同步延迟值。
4. 根据权利要求1所述的方法，其中该指令包括"sync-jitter" 属性。
5. 根据权利要求4所述的方法，其中该"sync —jitter"属性伴 随着指示不进行同步的值。
6. 根据权利要求4所述的方法，其中该"sync —jitter"属性伴 随着可接受的同步延迟值。
7. 根据权利要求4所述的方法，其中该"sync-jitter"属性为 SDP属性。
8. 根据权利要求1所述的方法，其中该指令包括"NO — SYNC"属性。
9. 根据权利要求1所述的方法，其中该指令包括"NLS"语义标签。
10. 根据权利要求1所述的方法，其中该传输的信息指令该接收 设备不进行多个多媒体流彼此之间的任何同步。
11. 根据权利要求1所述的方法，其中该传输的信息指令该接收 设备不进行多个多媒体流之一 与多个多媒体流的任何其他流的同步。
12. —种提供用于多个多媒体流的同步信息的计算机程序产品，包括计算机代码，用于将多个多媒体流传输到接收设备；以及计算机代码，用于传输关于该多个多媒体流的信息，该信息包括 用于该接收设备的具体指令，以允许不进行同步或允许在多个多媒 体流的至少 一 个和多个多媒体流的至少 一 个其他流之间的指定的同 步延迟量。
13. 根据权利要求12所述的计算机程序产品，其中该指令作为 在传输到该接收设备的会话信息中的属性得以包括。
14. 根据权利要求12所述的计算机程序产品，其中该指令包括 在该多媒体流的至少两个流之间的可接受的同步延迟值。
15. 根据权利要求12所述的计算机程序产品，其中该指令包括 "sync —jitter"属性。
16. 根据权利要求15所述的计算机程序产品，其中该 "sync-jitter"属性伴随着可接受的同步延迟值。
17. 根据权利要求15所述的计算机程序产品，其中该 "sync-jitter"属性为SDP属性。
18. 根据权利要求12所述的计算机程序产品，其中该传输的信 息指令该接收设备不进行多个多媒体流之一 与多个多媒体流的任何其他流的同步。
19. 根据权利要求12所述的计算机程序产品，其中该传输的信 息指令该接收设备不进行多个多媒体流彼此之间的任何同步。
20. —种电子设备，包括 处理器；以及存储器单元，操作地连接到该处理器并且包括计算机代码，用于将多个多媒体流传输到接收设备；以及 计算机代码，用于传输关于该多个多媒体流的信息，该信 息包括用于该接收设备的具体指令，以允许不进行同步或允许在多 个多媒体流的至少一个和多个多媒体流的至少一个其他流之间的指 定的同步延迟量。
21，根据权利要求20所述的电子设备，其中该指令作为在传输 到该接收设备的会话信息中的属性得以包括。
22.根据权利要求20所述的电子设备，其中该指令包括在该多 媒体流的至少两个流之间的可接受的同步延迟值。
23.根据权利要求20所述的电子设备，其中该指令包括 "sync —jitter，，属性。
24. 根据权利要求23所述的电子设备，其中该"sync —jitter" 属性伴随着可接受的同步延迟值。
25. 根据权利要求23所述的电子设备，其中该"sync-jitter" 属性为SDP属性。
26. 根据权利要求20所述的电子设备，其中该传输的信息指令 该接收设备不进行多个多媒体流彼此之间的任何同步。
27. 根据权利要求20所述的电子设备，其中该传输的信息指令 该接收设备不进行多个多媒体流之一与多个多媒体流的任何其他流 的同步。
28. 根据权利要求20所述的电子设备，其中该电子设备包括从 如下组中选^r的设备，该组包括移动电话、个人数字助理、膝上 型计算机、台式计算机、集成的消息发送设备以及其组合。
29. —种处理多媒体内容的方法，包括 从发送设备接收多个多媒体流；从该发送设备接收关于该多个多媒体流的信息；以及 如果接收的信息包括允许不进行同步或允许在多个多媒体流的 至少 一 个和多个多媒体流的至少 一 个其他流之间的指定的同步延迟量的具体指令，则根据该接收的具体指令展示该多个多媒体流。
30. 根据权利要求29所述的方法，其中该指令包括在该多媒体 流的至少两个流之间的可接受的同步延迟值。
31. 根据权利要求29所述的方法，其中该指令包括 "sync —jitter"属性。
32. 根据权利要求31所述的方法，其中该"sync —jitter"属性伴随着可接受的同步延迟值。
33. 根据权利要求29所述的方法，其中根据该接收的信息，不 进行多个多媒体流彼此之间的任何同步。
34. 才艮据权利要求29所述的方法，其中^4居该接收的信息，不 进行多个多媒体流之一与多个多媒体流的任何其他流的同步。
35. —种电子设备，包括 处理器；以及存储器单元，操作地连接到该处理器并且包括用于将多个多媒体流传输到接收设备的装置；以及 用于传输关于该多个多媒体流的信息的装置，该信息包括 用于该接收设备的具体指令，以允许不进行同步或允许在多个多媒 体流的至少 一 个和多个多媒体流的至少 一 个其他流之间的指定的同 步延迟量。
全文摘要
一种改进的系统和方法，允许传输电子设备明确地指示被传输的多媒体流中的哪些流不应当被同步或应当包括指定的同步抖动量。本发明帮助接收设备理解流的特性。本发明还允许接收设备做出关于当同步两个或多个流时是否应当使用同步抖动值的被告知的决定。对于例如单向视频共享或视频PoC的某些应用，流的发送设备可以指示接收设备为了更好的媒体质量不执行任何同步或执行有限的同步。
文档编号H04J3/06GK101288257SQ200680038380
公开日2008年10月15日 申请日期2006年8月25日 优先权日2005年8月26日
发明者D·莱昂, I·D·D·屈尔西奥, U·钱德拉 申请人:诺基亚公司