專利名稱：向設(shè)備發(fā)送信令以不執(zhí)行同步或在多媒體流上包括同步延遲的方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及IP多媒體通信領(lǐng)域。更特別地，本發(fā)明涉及用 于多媒體通信的信令機制以指令接收設(shè)備不執(zhí)行同步或包括不同多 媒體流之間的同步抖動。
背景技術(shù)：
在IP多媒體呼叫建立期間，呼叫的發(fā)送設(shè)備(即提供端或發(fā)啟 端)指定會話信息。會話信息包括媒體和與傳輸相關(guān)的信息。會話
信息承載于例如會話描述協(xié)議(SDP)的協(xié)議消息中。SDP承載于例 如會話發(fā)起協(xié)議(SIP)和實時流協(xié)議(RTSP)等的高級信令協(xié)議中。 第三代合作伙伴項目(3GPP)將SIP指定為IP多媒體子系統(tǒng)(IMS) 的多媒體會話建立的信令協(xié)議的選擇。
在SDP中，發(fā)送設(shè)備和接收設(shè)備可以為多媒體流指定不同的方 向，從而得到不同類型的應(yīng)用。例如，如果發(fā)送設(shè)備希望建立單向 媒體會話(即其希望發(fā)送視頻并且希望接收設(shè)備只接收該視頻)， 則其在SDP中指定該々某體流為a-sendonly。當(dāng)接收設(shè)備接收該SDP 消息時并且如果其希望參與到該會話中，則接收設(shè)備可以指定該流 為a=recvonly。對于視頻電話呼叫，發(fā)送設(shè)備和接收設(shè)備都指定力某 體流的方向為a=sendrecv。
通常，在IP多媒體呼叫中，在接收設(shè)備側(cè)存在同步不同媒體類 型的需求。例如，在音頻/視頻IP呼叫中，為了好的用戶體驗需要 在接收設(shè)備側(cè)執(zhí)行唇音同步。同步的另一個示例涉及字幕的使用； 如果音頻和/或視頻的發(fā)送端正在說英語并且如果在講話的同時，在 不同的實時傳輸協(xié)議(RTP)流中在用不同的語言發(fā)送講話的文字， 則需要在接收設(shè)備側(cè)同步這兩個流。不同的媒體流(來自發(fā)送設(shè)備側(cè))承載于不同的RTP/用戶數(shù)據(jù) 協(xié)議(UDP ) /互聯(lián)網(wǎng)協(xié)議(IP )流中。RTP時間戳被接收設(shè)備客戶端 用來執(zhí)行媒體間同步。
圖1描述了從發(fā)送設(shè)備接收多媒體流的接收設(shè)備。橫軸表示逝去 的時間并且示出接收的分組。圖1中示出的音頻和視頻緩沖器在從 發(fā)送設(shè)備接收分組時保存RTP分組。緩沖器執(zhí)行抖動消除(來自網(wǎng) 絡(luò)的)并且為每個々某體的每個分組計算播出時間(playout time)。 一旦分組在緩沖器中保留了一段給定的時間，則執(zhí)行解碼。該時間 段通常是變化的并且該時間段的 一 部分稱為抖動。 一 旦基于播出時 間完成了解碼，則將分組用于顯示或用于播放。應(yīng)當(dāng)理解，可以有 兩個不同的緩沖器用于保存進(jìn)入的RTP分組-一個用于抖動， 一個 用于解碼排隊。為了清晰和示例性的目的，在圖l中僅示出了一個 排隊，其中示出了結(jié)合的抖動和解碼緩沖器。解碼后， 一旦經(jīng)過了 播出時間，分組就可以用于播放或顯示。然而，如果接收設(shè)備試圖 執(zhí)行音頻/視頻同步，則其將試圖延遲首先到達(dá)的分組。
在圖1所示的示例中，音頻分組1在TA1處到達(dá)，并且一見頻分組 在時間上較晚于TA1的TV1處到達(dá)。應(yīng)當(dāng)理解，術(shù)語"到達(dá)"可以 代表分組到達(dá)的時間或每個分組的播出時間。在圖l的示例中，需 要同步具有相同的播放時間的音頻和視頻分組，因為它們具有相同 的基準(zhǔn)時鐘捕獲時間(在發(fā)送設(shè)備處)，即在發(fā)送設(shè)備處它們是在 相同的時間得以采樣。使用在RTP分組中的RTP時間戳和在RTCP發(fā) 送端報告(SR)分組中發(fā)送的NTP時間戳，執(zhí)行基準(zhǔn)時鐘捕獲時間 的計算。音頻和視頻分組很有可能在不同的時間到達(dá)接收設(shè)備處， 因為它們可能經(jīng)過不同的網(wǎng)絡(luò)路徑，并且每個分組的處理延遲(編 碼，分組化，解分組化，解碼)可以不同。因此在圖l所示的示例 中，必須將音頻分組延遲TV1-TA1的時間段，其為同步抖動或延遲。
在圖l所示的示例中，如果應(yīng)用(或發(fā)送端)不試圖執(zhí)行A/V 同步，但接收設(shè)備仍然試圖執(zhí)行同步(因為其為默認(rèn)的行為)，則 接收設(shè)備將被迫將音頻分組保存額外的時間。該動作有可能使音頻 緩沖器溢出。此外，當(dāng)試圖同步時，在排隊的開頭的音頻分組被延遲，這可以導(dǎo)致差的用戶體驗或媒體質(zhì)量。如果要保障服務(wù)質(zhì)量
(QoS)，則在音頻和視頻分組在排隊中有較大的延遲的情況下，將
不得不被丟棄。因此，雖然發(fā)送設(shè)備可能不希望媒體流被同步，但 由于缺乏發(fā)送設(shè)備可以向接收設(shè)備指示不需要同步或延遲的同步的 機制，可能會發(fā)生例如分組丟失、延遲的分組和浪費計算資源的問題。
在互聯(lián)網(wǎng)工程任務(wù)組的網(wǎng)絡(luò)工作組的請求說明(RFC) No. 3388 中，指定了發(fā)送設(shè)備可以明確地指定需要同步會話中的哪些媒體流 的機制。定義了新的SDP屬性(例如"group" 、"mid"和唇音同 步(LS))，這可以幫助發(fā)送設(shè)備指定需要對會話中的哪些媒體流 進(jìn)行唇音同步。另外，RTP接收設(shè)備的默認(rèn)實現(xiàn)行為是同步從相同的 源接收的媒體流。此外，規(guī)范未規(guī)定如果必須同步多媒體流，則要 求RFC 3388。 RFC 3388只指定了可以使發(fā)送設(shè)備在其發(fā)送兩個或多 個流的情況下指定需要同步哪些流的機制。
存在要求多媒體流不應(yīng)當(dāng)被同步的應(yīng)用和使用情況。例如，在實 時視頻共享(RTVS)應(yīng)用中，用戶開始單向視頻共享會話。通過在 SDP中將媒體流聲明為a=sendonly或a=recvonly，建立單向媒體會 話。在兩方之間已經(jīng)存在雙向(或可以是單向)音頻會話建立。呼 叫中的一方希望與另一方共享視頻。盡管有可能音頻或視頻會話也 可以建立在電路交換載體上，但在IP載體上建立音頻和視頻。共享 的視頻可以是來自文檔或來自現(xiàn)場的攝像鏡頭。
在單向視頻共享的某些情況下，發(fā)送設(shè)備不希望同步視頻(共享 自文檔的)和講話。不期望進(jìn)行同步的一個原因可能是發(fā)送設(shè)備希 望在接收設(shè)備處接收到高質(zhì)量的視頻，雖然有延遲。在此情況下， 發(fā)送設(shè)備希望接收設(shè)備具有較大的延遲緩沖器并且因此不希望執(zhí)行 同步。
單向視頻共享的另一個示例涉及用戶正在拍攝某個物體的視頻 并且在談?wù)撛撐矬w。在此情況下，粗劣形式的同步就足夠了，不必 進(jìn)行完美的同步，因為此人不是在拍攝其自己的臉部的視頻而是拍 攝不同的物體。又一個示例涉及"擴大的真實感"，其中將圖形與實時音頻和視頻混合。在此情況下，粗劣形式的同步將可以滿足要 求。
如果客戶端的默認(rèn)行為是同步這兩個流，則接收設(shè)備客戶端將采 用特別的算法以同步這些流。在接收設(shè)備側(cè)的同步算法將要求指定 量的計算復(fù)雜性，并且甚至在當(dāng)發(fā)送設(shè)備不希望任何同步時，客戶 端也將浪費某些資源。音頻和視頻流到達(dá)接收設(shè)備時可以具有不同 的延遲。如果接收設(shè)備試圖同步這些流，則將導(dǎo)致音頻和視頻幀的 丟棄，因此降低了接收的媒體的質(zhì)量。
遺憾的是，RFC 3388未討論可以明確地確定哪些流不應(yīng)當(dāng)被同 步的機制。例如，如果發(fā)送設(shè)備希望在會話中發(fā)送三個流，兩個音 頻流(Al和A2)和一個視頻流(VI),并且發(fā)送設(shè)備希望同步(唇 音同步)流Al和VI，則其可以使用group、 mid-SDP屬性和LS語義 標(biāo)簽加以指定。這將為接收設(shè)備指示Al和VI需要進(jìn)行同步而A2不 需要進(jìn)行同步。但對于有兩個或多個流并且不需要流同步的使用情 況，RFC 3388存在不足。另外，為指示唇音同步的性能(并且在某 些情況下RFC 3388可以用于指定無唇音同步)，RFC 3388必須被強 制執(zhí)行。最后，RFC 3388不提供用來使設(shè)備可以指示在不同的媒體 之中的期望的同步抖動的機制。
出于上述原因，目前沒有使發(fā)送設(shè)備可以為多媒體呼叫中的接收 設(shè)備指示不同步由發(fā)送設(shè)備傳輸?shù)亩嗝襟w流的機制，也不存在為多 媒體流指定同步延遲或抖動的機制。

發(fā)明內(nèi)容
本發(fā)明提供 一 種機制，其中傳輸或發(fā)送設(shè)備可以明確地指示被發(fā) 送的多媒體流中的哪些流不應(yīng)當(dāng)被同步或應(yīng)當(dāng)包括指定的同步抖動 量。該機制幫助接收設(shè)備理解流特性，并且允許接收設(shè)備做出關(guān)于 是否應(yīng)當(dāng)執(zhí)行同步以及是否指定同步抖動值的被告知的決定。對于 例如單向視頻共享或視頻PoC的某些應(yīng)用，流的發(fā)送設(shè)備可以指示 接收設(shè)備為了更好的媒體質(zhì)量不執(zhí)行任何同步。
本發(fā)明的一個實施例涉及若干新SDP屬性的引入。發(fā)送設(shè)備將在會話建立階段期間在SDP中聲明這些屬性，并且這些屬性可以承載 于任何高級信令協(xié)議(例如SIP、 RTSP等)中。然而，這些屬性不 限于SDP協(xié)議的使用，并且這些屬性可以使用在ISO 0SI協(xié)議棧的 階層1-7的任何一層上的任何其他的通信協(xié)議(例如XML、 HTTP、 UPnP、 CC/PP等)進(jìn)行定義和承載。
本發(fā)明通過在會話建立階段期間提供指示發(fā)送設(shè)備不在媒體流 中間進(jìn)行同步的選擇的能力，為常規(guī)的RFC 3388框架提供了實質(zhì)性 的益處。存在發(fā)送設(shè)備不希望其發(fā)送的媒體被同步的使用情況和應(yīng) 用。當(dāng)該選擇可以以信令發(fā)送給接收設(shè)備時，接收設(shè)備可以相應(yīng)地 建立資源并且不必浪費可用于其他任務(wù)或用于更好的媒體質(zhì)量的計 算資源。作為結(jié)果，本發(fā)明導(dǎo)致了在接收設(shè)備處的較少的分組丟失， 否則如果接收設(shè)備試圖執(zhí)行媒體流同步，將發(fā)生分組丟失。
除上述之外，本發(fā)明通過在會話建立階段期間提供指示發(fā)送設(shè)備 在媒體流之間的同步抖動的選擇的能力改進(jìn)了 RFC 3388。由于也存 在發(fā)送設(shè)備希望發(fā)送的媒體進(jìn)行具有粗劣抖動的同步的使用情況和 應(yīng)用，將該選擇用信令發(fā)送到接收設(shè)備的能力允許接收設(shè)備相應(yīng)地 建立資源。這也提供了節(jié)省計算資源的機會。在某些情況下，這還 可以產(chǎn)生媒體質(zhì)量等級的改善。事實上，在強制媒體同步的情況下， 由于在接收設(shè)備處的數(shù)據(jù)丟棄或其他原因，可能有某些分組丟失， 如果接收設(shè)備試圖執(zhí)行媒體流同步，就可能發(fā)生分組丟失。這是由 于這樣的事實，即媒體數(shù)據(jù)到達(dá)接收設(shè)備時有不同的延遲，這將導(dǎo) 致某些內(nèi)容過遲地到達(dá)，而不可用于完全同步的播放。通過控制同 步抖動，可以減輕或消除此問題。
本發(fā)明的這些和其它目標(biāo)、優(yōu)點和特征以及其組織和操作方式將 從下面結(jié)合附圖的詳細(xì)描述中變得顯而易見，其中貫穿以下附圖相 同的元件將具有相同的標(biāo)號。


圖1是示出了多個音頻和視頻分組從發(fā)送設(shè)備到接收設(shè)備的傳 輸?shù)谋硎?，其中雖然發(fā)送設(shè)備不要求同步，但接收設(shè)備執(zhí)行同步；圖2為用于本發(fā)明的實現(xiàn)方式的電子設(shè)備的透視圖3是圖1的電子設(shè)備的電路的示意性表示；以及
圖4是示出了本發(fā)明的一個實施例的一般實現(xiàn)方式的流程圖。
具體實施例方式
本發(fā)明提供一種機制，其中傳輸或發(fā)送設(shè)備可以明確地指示被發(fā) 送的多媒體流中的哪些流不應(yīng)當(dāng)被同步或應(yīng)當(dāng)包括指定量的同步抖 動。該機制幫助接收設(shè)備理解流特性，并且允許接收設(shè)備做出是否 應(yīng)當(dāng)執(zhí)行同步以及是否指定同步抖動值的被告知的決定。
為理解本發(fā)明的實現(xiàn)方式，圖1可用于基于發(fā)送設(shè)備在會話建立 階段期間通知接收設(shè)備其希望接收設(shè)備不執(zhí)行任何同步或使用具體 值(例如500毫秒)執(zhí)行具有粗劣同步延遲或抖動的同步。在此情 況下，當(dāng)已經(jīng)完成解碼并且每個媒體流的每個分組已經(jīng)到了播出時 間，接收設(shè)備可以提供相應(yīng)的分組以便呈現(xiàn)。接收設(shè)備對分組進(jìn)行 的延遲不需長于指定的值。這可以用于防止抖動緩沖器溢出的問題， 不為同步的目的而延遲分組，并且改善了媒體質(zhì)量。在此情況下， 接收必須獨立地管理兩個沒有任何相互關(guān)系的媒體排隊。
在發(fā)送設(shè)備希望接收設(shè)備執(zhí)行具有指定的延遲值的某些同步的 情況下，接收設(shè)備在解碼之后確定音頻和視頻分組的播出時間之間 的差(TV1-TA1 )。如果該值小于在會話建立中為同步抖動定義的值， 則接收設(shè)備不需要將音頻和視頻分組保存比播出時間指示的時段較 長的時段。如果值(TV1-TA1)大于同步抖動，則接收設(shè)備需要將分 組保存一短的時間段。例如，如果在會話建立期間指定的同步抖動 為5 00毫秒并且TV1-TA1為350毫秒，則接收設(shè)備不需要進(jìn)行任何 指定。然而，如果TV1-TA1為600毫秒，則音頻分組必須在排隊中 延遲額外的100毫秒。
在本發(fā)明的第一實施例中，指定了兩個機制，以允許多媒體流的 發(fā)送設(shè)備指示多媒體流不應(yīng)當(dāng)被同步。該實施例涉及新SDP參數(shù)的 引入，該新SDP參數(shù)幫助多媒體流的發(fā)送設(shè)備指定接收設(shè)備不應(yīng)當(dāng) 執(zhí)行同步。在第一機制中，引入了稱為"NO — SYNC"的新SDP屬性。"NO —SYNC" 指示該流不應(yīng)當(dāng)與會話中的任何其他多媒體流進(jìn)行同步。將該 N0-SYNC屬性聲明為a=N0 —SYNC。
該NO-SYNC屬性可以在J;某體級(即在SDP中的m行之后)或可以 在會話級上得以定義。當(dāng)在媒體級上定義之后，NO-SYNC屬性意味著 該媒體流不應(yīng)當(dāng)與會話中的任何其他流進(jìn)行同步。使用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
在以上示例中，在接收設(shè)備處第一視頻流不應(yīng)當(dāng)被同步。當(dāng)接收 設(shè)備客戶端接收該SDP時，其知道不應(yīng)當(dāng)將任何其他流與該視頻流 (具有MPEG4編解碼器)進(jìn)行同步。接收設(shè)備可以選擇同步或不同 步其余的(音頻和視頻)流。
NO — SYNC屬性可以在會話的開始處得以聲明，這暗示了會話中的
所有的流都不應(yīng)當(dāng)進(jìn)行同步。其描述如下 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
在以上示例中，發(fā)送設(shè)備指示接收設(shè)備該會話中的所有的流都不 應(yīng)當(dāng)進(jìn)行同步。
在另一個實現(xiàn)方式的示例中，可以定義RFC 3388的擴展。該擴 展可用于指定哪些流應(yīng)當(dāng)被同步。以下為常規(guī)RFC 3388系統(tǒng)的示例， 其展示了在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語義標(biāo)簽來指示的。然而，利用新的實現(xiàn)方式，使用具 有g(shù)roup屬性"NLS"的新的語義標(biāo)簽，其具有不同步的語義。以下 的示例示出了如何提供關(guān)于流不應(yīng)當(dāng)與在會話中的任何其他的流進(jìn) 行同步的指示
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的流不與會話中的任何其他流進(jìn)行 同步。因此，RFC 3388可以利用該新的語義標(biāo)簽進(jìn)行擴展，這將幫 助發(fā)送設(shè)備指示媒體流不要求同步。
語義標(biāo)簽LS和NLS可用于相同的會話描述中以描述哪些流需要 同步而哪些流不需要同步。例如，在以下描述的SDP示例中，流l 不應(yīng)當(dāng)與會話中的任何其他流進(jìn)行同步，而流2和流3應(yīng)當(dāng)?shù)靡酝?步。以此方式，發(fā)送設(shè)備可以明確地描述哪些流應(yīng)該進(jìn)行同步而哪 些流不需要同步。
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
在本發(fā)明的第二實施例中，引入了允許多媒體流的發(fā)送設(shè)備指示 在其希望接收設(shè)備進(jìn)行同步的多媒體流之間的同步延遲和抖動值的機制。在此實施例中，新SDP參數(shù)用于指定抖動值，利用這些SDP
屬性，發(fā)送設(shè)備還可以指定在給定的多媒體會話中的哪些流不應(yīng)當(dāng) 與在相同的會話中的任何其他流進(jìn)行同步。
在該實施例的一個具體的實現(xiàn)方式中，定義稱為"sync —jitter" 的新SDP屬性。該屬性指示多媒體流之間的同步延遲。sync-jitter SDP屬性以時間單位(例如毫秒)或任何其他合適的單位來指定。 sync-jitter的0的值意味著不應(yīng)當(dāng)執(zhí)行同步。在SDP中將屬性聲明 為
a=sync — j i t ter: value //值例如為毫秒。
sync—jitter SDP屬性可與group和mid屬性以及LS語義標(biāo)簽 (如在RFC 3388中定義的)結(jié)合使用。當(dāng)與該屬性一起使用時， sync_jitter指定在如LS語義標(biāo)簽所指定的需要同步的流之間的可 接受的同步抖動。以下為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的流要進(jìn)行同步。這是用 在group屬性中的LS語義標(biāo)簽來指示的。然而，在此示例中，無法 指示在具有mid l和mid 2的流之間的期望的同步抖動。取決于不 同的應(yīng)用(例如單向^L頻共享或?qū)崟r對話;f見頻電話)，同步值將不同。
以下示例利用sync-jitter屬性擴展上述示例。如果上述SDP 描述是用于單向視頻共享應(yīng)用，并且如果粗劣形式的同步將滿足特 定情況的要求，則發(fā)送設(shè)備可以例如針對具有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值特別指定了發(fā)送設(shè)備不希 望特定的媒體流與在給定的會話中的任何其他流進(jìn)行同步。如前所 述，默認(rèn)的實現(xiàn)方式是執(zhí)行同步，并且如果發(fā)送設(shè)備SDP實現(xiàn)方式 不支持RFC 3388，則發(fā)送設(shè)備可以使用值為0的sync —jitter屬性以 指示其不希望會話中的給定的流與任何其他流進(jìn)行同步。發(fā)送設(shè)備 指定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
在以上的示例中，發(fā)送設(shè)備不希望第一視頻流(具有MPEG-4) 與會話中的任何其他流進(jìn)行同步。接收設(shè)備可以選擇是否同步在會 話中給定的其余的兩個流。
應(yīng)當(dāng)理解，有可能需要為sync_jitter選擇非0的適當(dāng)?shù)闹?，?指示不要求同步，因為O將具有不同的語義。
圖4為示出本發(fā)明實施例的實現(xiàn)方式的一般流程圖，其中發(fā)送設(shè) 備指明不進(jìn)行同步或引入同步抖動的某個值。在圖4的步驟300中， 發(fā)送設(shè)備傳輸SDP信息。SDP信息包括關(guān)于被傳輸?shù)亩嗝襟w流的同步 的以上討論的類型的引入。在步驟310中，接收設(shè)備接收SDP信息。 在步驟320中，接收設(shè)備讀取SDP信息以確定是否存在不同步任何 或所有多媒體流的指令，是否包括某個數(shù)量的同步抖動，或是否應(yīng) 當(dāng)進(jìn)行完全的同步。如果存在不進(jìn)行同步的指令，則在步驟330中 遵循該指令。如果存在同步抖動值，則在步驟340處將指明的抖動 量引入到流中。如果不存在關(guān)于缺乏同步或同步抖動數(shù)量的指令， 或如果存在完全同步的具體指令，則在步驟350進(jìn)行完全同步。
圖2和圖3示出了一個在其中可以實現(xiàn)本發(fā)明的代表性電子設(shè)備 12。圖2和圖3中的電子設(shè)備包括移動電話并且可以用作發(fā)送設(shè)備 或接收設(shè)備。然而，還應(yīng)該理解，本發(fā)明不限于電子設(shè)備的一種特 定類型。例如電子設(shè)備12可以包括個人數(shù)字助理(PDA) 、 PDA和移 動電話的結(jié)合、集成的消息發(fā)送設(shè)備(IMD)、臺式計算機、筆記本
計算機或各種其他設(shè)備。
圖2和圖3中的電子設(shè)備12包括外殼30、液晶顯示器形式的顯 示器32、小鍵盤34、麥克風(fēng)36、耳機38、電池40、紅外端口42、 天線44、以根據(jù)本發(fā)明一個實施例的UICC形式的智能卡46、讀卡器48、無線接口電路52、編解碼器電路54、控制器56和存儲器58。 各個電路和元件全都是現(xiàn)有技術(shù)已知的類型，例如諾基亞移動電話 的范圍。
用方法步驟的一般上下文描述了本發(fā)明，在一個實施例中其可以 由程序產(chǎn)品實現(xiàn)，其中程序產(chǎn)品包括計算機可執(zhí)行指令，例如可以 由在聯(lián)網(wǎng)環(huán)境中的計算機執(zhí)行的程序代碼。
通常，程序模塊包括例程、程序、對象、組件、數(shù)據(jù)結(jié)構(gòu)等，其 可以執(zhí)行特定的任務(wù)或?qū)崿F(xiàn)特定的抽象數(shù)據(jù)類型。計算機可執(zhí)行指 令、相關(guān)數(shù)據(jù)結(jié)構(gòu)和程序模塊代表用于執(zhí)行在此公開的方法步驟的 程序代碼的示例。這樣的可執(zhí)行指令的特定序列或相關(guān)數(shù)據(jù)結(jié)構(gòu)代 表用于實現(xiàn)在這樣的步驟中描述的功能的相應(yīng)動作的示例。
本發(fā)明的軟件和web實現(xiàn)方式可以用標(biāo)準(zhǔn)的編程才支術(shù)來完成，該
驟、相關(guān)步驟、比較步驟和判決步驟。還應(yīng)當(dāng)理解，在此和在權(quán)利 要求書中使用的詞匯"組件"和"模塊"旨在包括使用一行或多行 軟件代碼的實現(xiàn)、和/或硬件實現(xiàn)、和/或用于接收手動輸入的設(shè)備。
為了說明和描述的目的，給出了上述的對本發(fā)明的實施例的描 述。不旨在窮舉或?qū)⒈景l(fā)明限制于公開的精確的形式，根據(jù)上述啟 示的修改和變形是可能的或可以從本發(fā)明的實踐中獲得。為了解釋 本發(fā)明的原理選擇和描述了這些實施例，其實際的應(yīng)用可使得本領(lǐng) 域技術(shù)人員以各種實施例和各種修改利用本發(fā)明作為所遇到的特定 用途的適當(dāng)解決方案。
權(quán)利要求
1.一種提供用于多個多媒體流的同步信息的方法，包括將多個多媒體流傳輸?shù)浇邮赵O(shè)備；以及傳輸關(guān)于該多個多媒體流的信息，該信息包括用于該接收設(shè)備的具體指令，以允許不進(jìn)行同步或允許在多個多媒體流的至少一個和多個多媒體流的至少一個其他流之間的指定的同步延遲量。
2. 根據(jù)權(quán)利要求1所述的方法，其中該指令作為在傳輸?shù)皆摻?收設(shè)備的會話信息中的屬性得以包括。
3. 根據(jù)權(quán)利要求1所述的方法，其中該指令包括在該多媒體流 的至少兩個流之間的可接受的同步延遲值。
4. 根據(jù)權(quán)利要求1所述的方法，其中該指令包括"sync-jitter" 屬性。
5. 根據(jù)權(quán)利要求4所述的方法，其中該"sync —jitter"屬性伴 隨著指示不進(jìn)行同步的值。
6. 根據(jù)權(quán)利要求4所述的方法，其中該"sync —jitter"屬性伴 隨著可接受的同步延遲值。
7. 根據(jù)權(quán)利要求4所述的方法，其中該"sync-jitter"屬性為 SDP屬性。
8. 根據(jù)權(quán)利要求1所述的方法，其中該指令包括"NO — SYNC"屬性。
9. 根據(jù)權(quán)利要求1所述的方法，其中該指令包括"NLS"語義標(biāo)簽。
10. 根據(jù)權(quán)利要求1所述的方法，其中該傳輸?shù)男畔⒅噶钤摻邮?設(shè)備不進(jìn)行多個多媒體流彼此之間的任何同步。
11. 根據(jù)權(quán)利要求1所述的方法，其中該傳輸?shù)男畔⒅噶钤摻邮?設(shè)備不進(jìn)行多個多媒體流之一 與多個多媒體流的任何其他流的同步。
12. —種提供用于多個多媒體流的同步信息的計算機程序產(chǎn)品，包括計算機代碼，用于將多個多媒體流傳輸?shù)浇邮赵O(shè)備；以及計算機代碼，用于傳輸關(guān)于該多個多媒體流的信息，該信息包括 用于該接收設(shè)備的具體指令，以允許不進(jìn)行同步或允許在多個多媒 體流的至少 一 個和多個多媒體流的至少 一 個其他流之間的指定的同 步延遲量。
13. 根據(jù)權(quán)利要求12所述的計算機程序產(chǎn)品，其中該指令作為 在傳輸?shù)皆摻邮赵O(shè)備的會話信息中的屬性得以包括。
14. 根據(jù)權(quán)利要求12所述的計算機程序產(chǎn)品，其中該指令包括 在該多媒體流的至少兩個流之間的可接受的同步延遲值。
15. 根據(jù)權(quán)利要求12所述的計算機程序產(chǎn)品，其中該指令包括 "sync —jitter"屬性。
16. 根據(jù)權(quán)利要求15所述的計算機程序產(chǎn)品，其中該 "sync-jitter"屬性伴隨著可接受的同步延遲值。
17. 根據(jù)權(quán)利要求15所述的計算機程序產(chǎn)品，其中該 "sync-jitter"屬性為SDP屬性。
18. 根據(jù)權(quán)利要求12所述的計算機程序產(chǎn)品，其中該傳輸?shù)男?息指令該接收設(shè)備不進(jìn)行多個多媒體流之一 與多個多媒體流的任何其他流的同步。
19. 根據(jù)權(quán)利要求12所述的計算機程序產(chǎn)品，其中該傳輸?shù)男?息指令該接收設(shè)備不進(jìn)行多個多媒體流彼此之間的任何同步。
20. —種電子設(shè)備，包括 處理器；以及存儲器單元，操作地連接到該處理器并且包括計算機代碼，用于將多個多媒體流傳輸?shù)浇邮赵O(shè)備；以及 計算機代碼，用于傳輸關(guān)于該多個多媒體流的信息，該信 息包括用于該接收設(shè)備的具體指令，以允許不進(jìn)行同步或允許在多 個多媒體流的至少一個和多個多媒體流的至少一個其他流之間的指 定的同步延遲量。
21，根據(jù)權(quán)利要求20所述的電子設(shè)備，其中該指令作為在傳輸 到該接收設(shè)備的會話信息中的屬性得以包括。
22.根據(jù)權(quán)利要求20所述的電子設(shè)備，其中該指令包括在該多 媒體流的至少兩個流之間的可接受的同步延遲值。
23.根據(jù)權(quán)利要求20所述的電子設(shè)備，其中該指令包括 "sync —jitter，，屬性。
24. 根據(jù)權(quán)利要求23所述的電子設(shè)備，其中該"sync —jitter" 屬性伴隨著可接受的同步延遲值。
25. 根據(jù)權(quán)利要求23所述的電子設(shè)備，其中該"sync-jitter" 屬性為SDP屬性。
26. 根據(jù)權(quán)利要求20所述的電子設(shè)備，其中該傳輸?shù)男畔⒅噶?該接收設(shè)備不進(jìn)行多個多媒體流彼此之間的任何同步。
27. 根據(jù)權(quán)利要求20所述的電子設(shè)備，其中該傳輸?shù)男畔⒅噶?該接收設(shè)備不進(jìn)行多個多媒體流之一與多個多媒體流的任何其他流 的同步。
28. 根據(jù)權(quán)利要求20所述的電子設(shè)備，其中該電子設(shè)備包括從 如下組中選^r的設(shè)備，該組包括移動電話、個人數(shù)字助理、膝上 型計算機、臺式計算機、集成的消息發(fā)送設(shè)備以及其組合。
29. —種處理多媒體內(nèi)容的方法，包括 從發(fā)送設(shè)備接收多個多媒體流；從該發(fā)送設(shè)備接收關(guān)于該多個多媒體流的信息；以及 如果接收的信息包括允許不進(jìn)行同步或允許在多個多媒體流的 至少 一 個和多個多媒體流的至少 一 個其他流之間的指定的同步延遲量的具體指令，則根據(jù)該接收的具體指令展示該多個多媒體流。
30. 根據(jù)權(quán)利要求29所述的方法，其中該指令包括在該多媒體 流的至少兩個流之間的可接受的同步延遲值。
31. 根據(jù)權(quán)利要求29所述的方法，其中該指令包括 "sync —jitter"屬性。
32. 根據(jù)權(quán)利要求31所述的方法，其中該"sync —jitter"屬性伴隨著可接受的同步延遲值。
33. 根據(jù)權(quán)利要求29所述的方法，其中根據(jù)該接收的信息，不 進(jìn)行多個多媒體流彼此之間的任何同步。
34. 才艮據(jù)權(quán)利要求29所述的方法，其中^4居該接收的信息，不 進(jìn)行多個多媒體流之一與多個多媒體流的任何其他流的同步。
35. —種電子設(shè)備，包括 處理器；以及存儲器單元，操作地連接到該處理器并且包括用于將多個多媒體流傳輸?shù)浇邮赵O(shè)備的裝置；以及 用于傳輸關(guān)于該多個多媒體流的信息的裝置，該信息包括 用于該接收設(shè)備的具體指令，以允許不進(jìn)行同步或允許在多個多媒 體流的至少 一 個和多個多媒體流的至少 一 個其他流之間的指定的同 步延遲量。
全文摘要
一種改進(jìn)的系統(tǒng)和方法，允許傳輸電子設(shè)備明確地指示被傳輸?shù)亩嗝襟w流中的哪些流不應(yīng)當(dāng)被同步或應(yīng)當(dāng)包括指定的同步抖動量。本發(fā)明幫助接收設(shè)備理解流的特性。本發(fā)明還允許接收設(shè)備做出關(guān)于當(dāng)同步兩個或多個流時是否應(yīng)當(dāng)使用同步抖動值的被告知的決定。對于例如單向視頻共享或視頻PoC的某些應(yīng)用，流的發(fā)送設(shè)備可以指示接收設(shè)備為了更好的媒體質(zhì)量不執(zhí)行任何同步或執(zhí)行有限的同步。
文檔編號H04J3/06GK101288257SQ200680038380
公開日2008年10月15日 申請日期2006年8月25日 優(yōu)先權(quán)日2005年8月26日
發(fā)明者D·萊昂, I·D·D·屈爾西奧, U·錢德拉 申請人:諾基亞公司