專利名稱：基于重傳的流修復和流加入的制作方法
技術(shù)領(lǐng)域：
本公開內(nèi)容一般涉及用于基于因特網(wǎng)協(xié)議(IP)的媒體流的基于重傳 的修復和快速流加入方案。
背景技術(shù)：
實時傳輸協(xié)議(RTP)和與其有關(guān)的標準定義了重傳分組格式和通過 數(shù)據(jù)已經(jīng)丟失的否定確認(NACK)分組進行反饋的方式。下面的標準 RTP (RFC 3550) 、 RTP重傳(RFC 4588) 、 RTCP反饋(RFC 4585)和 利用SSM會話的RTCP (draft-ietf-avt-rtcpssm-ll.txt)都通過引用被結(jié)合于 此，并且描述了單播反饋、用于單播會話的重傳和用于多播會話的帶有多 播重傳的單播反饋。
然而，當RTP協(xié)議組被針對某些類型的因特網(wǎng)協(xié)議(IP)媒體傳送 (諸如向不同端點傳送流播視頻)而使用時，其具有局限性。例如，RTP 和任何其它公共媒體傳輸協(xié)議都不能在沒有數(shù)據(jù)丟失的情況下執(zhí)行多播媒 體流的單播修復或者不同多播媒體流之間的快速有效切換。


圖1示出在用于多播媒體流的旁視模式(lookaside mode)中使用的修 復方案。
圖2示出利用IP任播(anycast)地址的圖1中的修復方案。
圖3是示出不同媒體流如何能夠與不同IP任播地址相關(guān)聯(lián)的示圖。
圖4是示出修復方案如何被用在源模式中的示圖。
圖5是示出用于信道加入的重傳方案的另一實施例的示圖。
圖6是更具體地說明在圖5中所示的重傳方案的流程圖。
具體實施例方式
基于實時傳輸協(xié)議(RTP)的單播修復方案被用于修復RTP多播流中
的錯誤。通過將新媒體流的加入建模作為修復操作，修復方案還被擴展用 于快速加入媒體信道。應當注意，術(shù)語"信道"和"流"在下面可以互換 使用。
參考圖1，媒體流源12可以是可通過因特網(wǎng)協(xié)議(IP)網(wǎng)絡10源發(fā) 出諸如視頻、音頻、語音、數(shù)據(jù)，等等的IP媒體的服務器、計算機或者任 何其它類型的網(wǎng)絡處理設(shè)備。在本示例中，媒體流源12通過IP網(wǎng)絡IO傳 送多播媒體流14，多播媒體流14被不同媒體流接收器24A-24N接收，并 且還被重傳系統(tǒng)18接收。
媒體流接收器24可以是接收、存儲或者提供多播媒體流14的任何設(shè) 備。例如，媒體流接收器24可以是機頂盒(STB)、數(shù)字視頻記錄儀 (DVR)、計算機終端、個人計算機(PC)、具有IP接口的電視、基于 IP的語音(VoIP)電話、蜂窩電話、個人數(shù)字助理(PDA)，等等。重傳 系統(tǒng)18可以是緩存并重傳多播媒體流14的部分的任何類型的媒體服務 器。媒體流源12和重傳系統(tǒng)18被示為單獨的設(shè)備，但是它們可以存在于 相同的實體位置處，并且可以通過局域網(wǎng)(LAN)或其它底板連接 (backplane connectivity)而連接在一起。
在一個實施例中，特定源多播(SSM)多播會話被建立用于在媒體流 源12和一個或多個媒體流接收器24之間傳送多播媒體流14。媒體流源 12知道用于傳送特殊媒體流的IP地址和端口。重傳系統(tǒng)18知道什么IP地
址和端口用于接收媒體流和什么地址和端口用于發(fā)送重傳。媒體流接收器 24知道什么IP地址和端口用于監(jiān)聽媒體流和重傳以及向哪里發(fā)送重傳請 求。所有這些地址和端口信息可以利用會話描述協(xié)議(SDP)來描述，但 其它媒體描述方案也可以使用。
反饋目標IP地址16被媒體流接收器24作為目的地地址用于請求重傳 多播媒體流14的部分。例如，來自多播媒體流14的分組可能不能成功到 達特殊媒體流接收器，或者可能以惡化狀態(tài)被接收。
媒體流接收器24向與反饋目標IP地址16相關(guān)聯(lián)的重傳系統(tǒng)18發(fā)送包括用于識別丟失媒體分組的信息30的重傳請求28。在一個示例中，重 傳請求28是利用反饋目標地址16作為目的地地址29的單播實時傳輸控制 協(xié)議(RTCP)否定確認(NACK)分組。如果從重傳系統(tǒng)到請求接收器的 單播RTP修復會話還沒有存在的話，則向重傳系統(tǒng)18發(fā)送單播RTCP NACK分組28動態(tài)地例示出這樣的會話。
重傳系統(tǒng)18包括媒體緩存器22，媒體緩存器22用于緩存來自多播媒 體流14的分組的近來的歷史。在單播RTP修復會話期間，多播媒體流14 的丟失分組在重傳請求28的丟失分組信息30中被識別出。重傳系統(tǒng)18識 別出媒體緩存器22中的與重傳請求28中的丟失或者惡化分組的信息30相 對應的分組。
媒體緩存器22中被識別出的媒體分組作為單播媒體修復分組34而被 發(fā)送返回請求媒體流接收器28。媒體流接收器24然后將接收到的單播媒 體修復分組34插入媒體流14中相應的丟失分組位置處。因此，在一個實 施例中，修復會話使用單播NACK分組28和單播媒體修復分組37來修復 多播媒體會話。
在圖1中所示的媒體配置被稱為"旁視模式"，因為重傳系統(tǒng)18 (修 復元件)沒有被要求將初始媒體流14中繼到媒體流接收器24。而是，媒 體流源12將媒體流14直接多播傳送到接收器24。旁視模式可以產(chǎn)生較高 的可用性，因為如果重傳系統(tǒng)18損毀或者變得不能用時，媒體流14不一 定會被中斷。
在本示例中，只有當重傳系統(tǒng)18故障時，單播修復功能才停止。因 為重傳系統(tǒng)18只接收并緩存多播媒體流14，并且還不必向媒體流接收器 24重傳媒體流14，所以還提供了更高的性能。因此，通過僅僅提供媒體 流修復，重傳系統(tǒng)18的恒定工作要素則被減半。
在該旁視模式中，重傳系統(tǒng)18通過使用和與SSM媒體流源12相關(guān)聯(lián) 的源IP地址不同的用于重傳系統(tǒng)18的反饋目標地址16而與媒體流源12 相區(qū)別。
參考圖2，為了提供高可用性和載荷共享，修復方案的一個實施例使 用IP任播地址46作為用于重傳系統(tǒng)18的反饋目標地址。這使得修復操作能夠適應性地指向當前最佳可用的重傳系統(tǒng)18A或18B。任播地址方案采 用了 IP單播路由的度量，該度量自動將分組路由到與最便宜的IP路由成 本相關(guān)聯(lián)的網(wǎng)絡處理設(shè)備。
為了更詳細地解釋，消息40識別用于能夠用于修復多播媒體流14的 多個不同重傳系統(tǒng)18A和18B的單個IP任播地址46。此SDP被提供給重 傳系統(tǒng)18A和18B以及接收器，以便它們將它們的重傳請求指向此任播反 饋地址。重傳系統(tǒng)18A和18B緩存媒體流14，并且能夠用于將丟失分組 重傳到任意的媒體流接收器24A-24D。
重傳系統(tǒng)18A和18B共享在消息40中所識別的相同IP任播源地址 46。 IP任播地址涉及被多個網(wǎng)絡處理設(shè)備同時用作目的地地址的單播IP 地址。在本示例中，共享IP地址46的網(wǎng)絡處理設(shè)備包括重傳系統(tǒng)18A和 18B。
重傳系統(tǒng)18A和18B以及媒體流接收器24按照與上面在圖1中所描 述的實質(zhì)上相同的方式進行操作。在本示例中，所有媒體流接收器24A-24D都接收來自媒體流源12的相同多播媒體流14。或者，媒體流接收器 24可以通過源自重傳系統(tǒng)18A和18B的其中之一的單獨多播流來間接接 收多播媒體流14。本實施例被稱為"源模式"，并且下面在圖4中被更具 體地描述。
任何媒體流接收器24A-24D都可以從多播媒體流14檢測丟失的或者 惡化的分組或幀。在響應中，接收器24發(fā)出單播NACK重傳請求消息 44。為了解釋的目的，圖2中的每個媒體流接收器24A-24D當前都正在接 收媒體流14，并且它們中的一個或多個已經(jīng)從媒體流14識別出丟失的 幀。經(jīng)歷丟失或惡化的接收器24A-24D分別發(fā)送重傳請求消息44A-44D。
重傳請求消息44A-44D中的每個分別包括相同IP任播目的地地址46 和相關(guān)聯(lián)的媒體流接收器源地址48A-48D。重傳請求消息44A-44D還包括 用于識別哪些幀從多播媒體流14中丟失的丟失分組信息。
IP網(wǎng)絡10中的路由器42和44使用內(nèi)部路由度量來選擇重傳系統(tǒng) 18A和18B中的哪個具有用于路由消息44A-44D的最便宜的IP路由成 本。因為IP任播地址46被兩個不同網(wǎng)絡處理設(shè)備18A和18B所共享，所以路由器42和43中的傳統(tǒng)的路由度量將自動選擇兩個設(shè)備18A和18B中 的一個用于重傳任何消息44A-44D。在本示例中，路由器42確定重傳系 統(tǒng)18A具有用于從接收器24A和24B分別接收的重傳請求消息44A和 44B的最短路由路徑?；蛘?，路由器43確定重傳系統(tǒng)18B具有用于從接 收器24C和24D分別接收的重傳請求消息44C和44D的最短路由路徑。
重傳系統(tǒng)18A接收單播NACK重傳請求消息44A和44B,并且重傳 系統(tǒng)18B接收單播NACK重傳請求消息44C和44D。重傳系統(tǒng)18A通過 將來自其緩存器的多播媒體流14的單播媒體修復分組發(fā)送返回接收器 24A和24B來返回響應。例如，重傳系統(tǒng)18A將單播媒體修復分組34發(fā) 送返回在消息44B中所識別的媒體流接收器24B。重傳系統(tǒng)18B通過將來 自其緩存器的多播媒體流14的單播媒體修復分組分別發(fā)送返回接收器24C 和24D來響應重傳請求消息44C和44D。
當使用與上面在圖1中所描述的實質(zhì)上相同的修復方案時，這樣的重 傳請求44A-44D的分布式路由既增加了可用性又增加了載荷共享能力。例 如，如果重傳系統(tǒng)18A或18B失效，則路由器42和44將自動從內(nèi)部路由 表中丟棄失效的重傳系統(tǒng)。因此，先前被路由到失效的重傳系統(tǒng)18的修 復請求被自動重新路由到可操作的重傳系統(tǒng)18中的不同的一個系統(tǒng)。
圖3示出不同IP任播地址被用作用于不同媒體流54和56的反饋地址 的。這通過使得一個或多個不同重傳系統(tǒng)50和52能夠與不同多播媒體流 相關(guān)聯(lián)而進一步增加了媒體修復方案的可擴展性。
例如， 一個或多個重傳系統(tǒng)50可以被特定地指定用于為特殊多播媒 體流54提供媒體分組修復。在特定源多播(SSM)多播會話中被識別用 于多播媒體流54的反饋目標IP任播地址被用作重傳系統(tǒng)50的每個系統(tǒng)的 源地址。類似地， 一個或多個重傳系統(tǒng)52可以被指定用于為不同多播媒 體流56提供媒體分組修復支持。在SSM多播會話中被識別用于多播媒體 流56的反饋目標IP任播地址被用作重傳系統(tǒng)52的每個系統(tǒng)的源地址。
在本示例中，媒體流接收器24B正在接收用于多播媒體流54的分 組。如果多播分組的任何分組丟失，則媒體流接收器24B向與多播媒體流 54相關(guān)聯(lián)的IP任播目的地地址X發(fā)送單播NACK重傳請求消息58。 IP基礎(chǔ)結(jié)構(gòu)中的路由器(未示出)自動將重傳請求消息58路由到重傳系統(tǒng)50
的一個系統(tǒng)，并且該系統(tǒng)然后發(fā)送返回包含所識別出的丟失分組的單播媒 體修復分組。
這樣，不同重傳系統(tǒng)可以與不同媒體流相關(guān)聯(lián)，以進一步增加修復方
案的可擴展性。然而，在其它實施例中，重傳系統(tǒng)50可以為不止一個媒 體流提供修復支持。
圖4示出用于修復方案的替代"源模式"。在該源模式中，重傳源70 提供媒體流修復，并且也像媒體流源12初始生成的用于多播流14的SSM 分布源那樣進行操作。媒體流源12可以是本地編碼器、本地接合器 (splicer)，或者是在IP網(wǎng)絡10中從重傳源70A和70B遠程操縱的單獨 媒體流服務器。
重傳源70A將初始媒體流14緩存在媒體緩存器22A中，并且如果有 必要，則作為合法RTP混合器/翻譯器(translator)根據(jù)RTP規(guī)范進行操 作來重新源發(fā)出所接收的媒體流14。類似地，重傳源70B將緩存在媒體緩 存器22B中的初始媒體流14作為多播媒體流64重傳。
在該源模式中，當多播媒體流分組丟失時，重傳源70A和70B仍然接 收到來自媒體流接收器24的單播NACK重傳請求消息44。重傳源70相 應地發(fā)送返回包含被請求的丟失媒體的單播媒體修復分組34。
在一個實施例中，兩個重傳源70A和70B仍然也是共享相同的IP源 地址46。此用于反饋目標的公共IP源地址46可以被再次識別用于使用帶 外或帶內(nèi)消息傳遞的多播媒體會話。在媒體流源12、重傳源70和媒體流 接收器24之間交換的消息60將媒體流14與反饋目標IP單播地址46關(guān)聯(lián) 起來。
共享相同IP目的地地址46以與上面在圖2中所描述的相同的方式為 類似的修復方案提供了高可用性和載荷共享。然而，圖4中的重傳源70A 和70B還作為用于媒體流14的重傳源進行操作。因此，相對于初始媒體 流14的多播傳送，共享相同SSM源地址46還提供了更高的可用性和載荷 共享。將任播IP地址用作用于媒體源的SSM源地址也提供了此能力。
例如，重傳源70A重新發(fā)起媒體流14作為多播媒體流62，并且重傳源70B重新發(fā)起媒體流14作為多播媒體流64。用于多播媒體流62的多播 分組72和來自多播媒體流64的多播分組74中使用相同的源IP地址46。
IP網(wǎng)絡10中用于接收具有相同源地址的媒體流62和64的任何路由 器42根據(jù)被認為是"反向路徑重傳"的多播路由的基本特性而自動丟棄 用于兩個流中的一個流的分組。對于在多播樹上重傳的分組，只有從上游 分枝接收的指向樹的根處的源IP地址的那些分組才被接受用于重傳。在本 示例中，路由器42丟棄了用于媒體流64的多播分組，并且僅僅將用于媒 體流62的多播分組72路由到媒體流接收器24。
如果重傳源70A永遠失效，則路由器42將重新計算內(nèi)部路由度量， 并且然后自動開始將用于媒體流64的多播分組74路由到媒體流接收器 24。因此，使用共享的IP任播地址46和SSM源地址也為多播媒體流源提 供了冗余和載荷共享。
被共享的IP源地址46通過使得重傳源70A或70B像上面在圖3中描 述的那樣接收并響應由媒體流接收器24中的任何媒體流接收器發(fā)送的重 傳請求44而依然如上面在圖3中描述的那樣增加了重傳修復冗余和載荷 平衡。也有可能重傳源70中的一個在其它重傳源70通過接收單播重傳請 求44并以媒體修復分組34返回響應時結(jié)束向接收器24重新發(fā)起多播媒體 流。
用于快速流加入的修復方案的擴展
與媒體流修復操作相比，可以對流加入提供若干評述。正在加入新 RTP會話的媒體流接收器可能不知道需要向哪些分組提供當前的流。此 外，由于可能涉及多播視頻會話，所以媒體流接收器很可能在時間上"落 后"于多播流，并且可能需要"追趕"。這是很重要的，因為媒體流接收 器可能不能提供媒體流，直到其接收到可能在該媒體流接收器試圖加入多 播會話很短時間之前通過的經(jīng)過幀內(nèi)編碼的幀為止。
參考圖5，快速流加入方案(或者被稱為快速信道加入)使用了上述 多種修復方案。多個不同的多播媒體流82A-82N分別由不同的媒體流源 80A-80N生成。媒體流所使用的同步源(SSRC)在帶外被以SDP消息84傳送給媒體流接收器24。 SDP消息84還包括用于如上所述的與修復多播 媒體流相關(guān)聯(lián)的一個或多個重傳系統(tǒng)86。
媒體流接收器24檢測加入新多播媒體流的請求，并且向重傳系統(tǒng)86 發(fā)送指定接收器希望接收的新信道的單播請求96。信道加入請求可以例如 通過檢測使用用戶接口 94的用戶的機頂盒來被檢測，以選擇新的或不同 的多播媒體信道。
在一個實施例中的單播信道加入請求96實質(zhì)上與上面在圖1-4中所描 述的RTCPNACK重傳請求消息相同。但是，在本實施例中，消息96是 包含圖像丟失指示(PLI) 98的NACK分組。PLI指示98通知重傳系統(tǒng)86 發(fā)送需要被加入新識別的媒體流102的所有信息。替代地請求來自已經(jīng)連 接的媒體流的特定丟失分組是與圖1中的重傳請求消息28不同的。
信道加入請求96由媒體流接收器24發(fā)送到與被識別的新媒體流102 相關(guān)聯(lián)的用于重傳系統(tǒng)86的反饋目標地址100。需要注意，快速信道/流 加入發(fā)起的方案類似于上面描述的修復方案，因為其采用相同的NACK和 重傳機制。
參考圖5和圖6，重傳系統(tǒng)86在接收到信道加入請求96時執(zhí)行下面 的操作。在操作110中，重傳系統(tǒng)86使用單播NACK信道加入請求96中 的SSRC 102、 NACK分組的目的地傳輸?shù)刂泛投丝趤泶_定接收器24正在 加入哪個媒體流信道。如上所述，SSRC 102之前在SDP消息84的信道描 述中已被傳送給接收器24。
在操作112中，重傳系統(tǒng)86使用所緩存的用于被選擇的媒體流的視 頻信息來從緩存器提取接收器24可能需要用來"起動"其解碼器97的所 有元素。這可以包括運動圖像專家組(MPEG)節(jié)目關(guān)聯(lián)表(PAT)和節(jié) 目映射表(PMT)元素、加密控制消息(ECM)以及解碼器97所需的其 它可能的非視頻數(shù)據(jù)。在操作114中，重傳系統(tǒng)86構(gòu)建特定于應用 (APP)的實時傳輸控制協(xié)議(RTCP)解碼器分組88，并且在操作116 中將解碼器起動分組88發(fā)送給請求信道加入的媒體流接收器26。
在操作118中，重傳系統(tǒng)86再次參考媒體緩存器87以識別包含最近 緩存的經(jīng)過幀內(nèi)編碼的幀(I幀)的RTP數(shù)據(jù)。在操作120中，重傳系統(tǒng)86發(fā)送被緩存的包含I幀的RTP分組和所有隨后的幀，直到媒體流接收器 24的當前緩存時間為止。被識別出的幀90以比接收器24實際提供分組中 的媒體更快(即，比實際時間更快)的速度被突發(fā)傳送給接收器24。這通 過使得接收器能夠提供返回之前的I幀的視頻而加快了信道加入過程。
被發(fā)送返回的流部分不一定是簡單加入新流的。接收器可以通過得知 用于媒體流的SDP并執(zhí)行傳統(tǒng)的IGMP加入操作而在不請求信道加入的情 況下加入流。從之前的I幀返回的所存儲的數(shù)據(jù)的突發(fā)使得接收器在加入 完成并且下一 I幀到達之前就開始提供。如果數(shù)據(jù)突發(fā)傳送地沒有實際時 間快，則接收器將不能"追趕"上多播流，其中，多播流在時間上先于接 收器。因此，突發(fā)幀本質(zhì)上"反向填充"到先前的I幀，接收器因此能夠 在多播流中的下一I幀到達之前就提供媒體。
接收器24中的解碼器97被以來自解碼器分組88和媒體幀90的信息 起動。在被起動并且接收到突發(fā)之后，接收器24可以加入用于新流的多 播組，并且可以開始提供來自被加的多播媒體流82N的任何隨后的媒體。
像基本分組修復操作那樣，快速信道加入方案可以采用圖3和圖2的 旁視模式方案或者圖4所示的源模式方案中提供的基于任播的可用性和載 荷共享特征的任何特征。
預期到各種實施，其中，修復或信道加入方案被通過經(jīng)由各種接入網(wǎng) 絡提供IPTV服務的服務提供上所使用，所述接入網(wǎng)絡包括但不限于數(shù)字 訂戶回路(DSL)、電纜、WiMax，等等。
還應當注意，媒體修復和信道加入方案本質(zhì)上無狀態(tài)。除了在修復和 信道加入期間，它們對于各個接收器保持無狀態(tài)。這使得該系統(tǒng)能夠比潛 在地希望請求修復或信道加入操作的其中在重傳系統(tǒng)中對于各個接收器保 持永久或半永久狀態(tài)的系統(tǒng)具有更好的比例。IP網(wǎng)絡中的路由器的正常路 由狀態(tài)提供了確保重傳請求或信道加入請求被指向到可操作的重傳系統(tǒng)18 所需的任何消息。IP網(wǎng)絡路由器中的路由度量作為副產(chǎn)品還提供了一定程 度的載荷平衡。
因此，不需要與媒體流相關(guān)聯(lián)的媒體源、重傳系統(tǒng)和媒體流接收器來 跟蹤哪些媒體流源或哪些重傳系統(tǒng)是可操作的，或者哪些媒體流接收器當前被連接到哪些媒體流。
RTP單播修復方案還不要求重傳系統(tǒng)記住哪些修復或信道加入分組已 經(jīng)之前被接收或被發(fā)送給媒體流接收器。每個重傳或信道加入請求可以是 由重傳系統(tǒng)在不需要知道之前對該請求接收器已經(jīng)執(zhí)行了哪些其它修復操 作的情況下而使用單個響應或一組響應來答復的單個整體請求。
因此，利用具有上述擴展的RTP協(xié)議機制使得能夠創(chuàng)建一種既用于基
于重傳的媒體流修復又用于快速信道加入(即，流加入)的統(tǒng)一技術(shù)。以 旁視模式或者以源模式進行的操作都可以使用基于任播的反饋尋址來改進 可擴展性、健壯性和性能。單獨的操作被利用公共機制、低協(xié)議、狀態(tài)和 計算開銷而被統(tǒng)一。
上述系統(tǒng)可以專用于執(zhí)行一些或者所有這些操作的處理器系統(tǒng)、微控 制器、可編程邏輯設(shè)備或者微處理器。上述這些操作中的一些可以以軟件 來實現(xiàn)，并且其它操作可以以硬件來實現(xiàn)。
為方便起見，操作被描述為各種互連的功能塊或者不同的軟件模塊。 然而，并不一定是這樣的，并且可以有這樣地情形，其中這些功能塊或模 塊被以不清楚的邊界等同地集合到一個邏輯設(shè)備、程序或操作中。在任何 情況中，功能塊和軟件模塊或靈活接口的特征可以以硬件或軟件的方式自 身實現(xiàn)，或者與其它操作組合實現(xiàn)。
已經(jīng)以本發(fā)明的優(yōu)選實施例描述和說明了本發(fā)明的原理，很明顯，在 不脫離此原理的情況下可以在設(shè)置和細節(jié)上修改本發(fā)明。我/我們請求所有 修改和變體都落入下面的權(quán)利要求書的精神和范圍。
1權(quán)利要求
1. 一種裝置，包括媒體重傳設(shè)備，其緩存因特網(wǎng)協(xié)議(IP)傳送的媒體流的多個部分，并且與一個或多個其它媒體重傳設(shè)備共享IP地址，被共享的IP地址使得來自特定媒體流接收器的重傳請求根據(jù)所述媒體重傳設(shè)備和媒體流接收器的子集之間的IP網(wǎng)絡拓撲關(guān)系而被分配回所述媒體流重傳設(shè)備。
2. 根據(jù)權(quán)利要求1所述的裝置，其中，所述被共享的IP地址使得IP 網(wǎng)絡路由器將從所述媒體流接收器發(fā)送的重傳請求分配給共享所述IP地址 并且具有最便宜的IP路由成本的不同媒體重傳設(shè)備。
3. 根據(jù)權(quán)利要求1所述的裝置，其中，所述被共享的IP地址是IP任 播地址。
4. 根據(jù)權(quán)利要求1所述的裝置，其中，所述媒體重傳設(shè)備緩存來自媒體流源的多播媒體流分組，并且接收來自使用所述被共享的IP地址的媒體 流接收器的單播重傳請求分組。
5. 根據(jù)權(quán)利要求4所述的裝置，其中，所述媒體重傳設(shè)備將單播媒體 修復分組發(fā)送回發(fā)送了包含所述多播媒體流的丟失部分的重傳請求分組的 媒體流接收器。
6. 根據(jù)權(quán)利要求1所述的裝置，其中，所述重傳請求是使用所述被共 享的IP地址作為目的地地址的實對傳輸控制協(xié)議(RTCP)否定確認(NACK)分組。
7. 根據(jù)權(quán)利要求1所述的裝置，其中，所述媒體重傳設(shè)備既充當所述 媒體流的初始傳送源又充當重傳修復源。
8. 根據(jù)權(quán)利要求1所述的裝置，其中，所述媒體重傳設(shè)備只充當所述 媒體流的重傳源，并且第二傳送設(shè)備充當所述媒體流的初始傳送源。
9. 根據(jù)權(quán)利要求1所述的裝置，其中，所接收的重傳請求和相同的共 享IP地址在被識別作為媒體流修復請求時，使得所述媒體重傳設(shè)備發(fā)回從 所述媒體流丟失或惡化的被緩存的媒體流分組，并且在被識別作為信道加 入請求時，使得所述媒體重傳設(shè)備發(fā)送解碼新媒體流所需的一組緩存的媒體流幀和解碼器信息。
10. —種裝置，包括媒體流接收器，其被配置為發(fā)送單播重傳請求，該單播重傳請求用于 請求重傳當前接收的多播媒體流的一部分或用于請求加入新多播媒體流，所述媒體流接收器還被配置為接收返回的單播修復分組，所述返回的 單播修復分組包含所述當前接收的媒體流的被請求的部分或者包含所述被 請求的新媒體流的一部分。
11. 根據(jù)權(quán)利要求IO所述的裝置，其中，所述用于請求重傳所述當前 接收的媒體流的單播重傳請求是實時傳輸控制協(xié)議(RTCP)否定確認(NACK)分組，并且所述用于請求加入新媒體流的單播重傳請求是報告 圖像丟失指示(PLI)的RTCPNACK分組。
12. 根據(jù)權(quán)利要求IO所述的裝置，其中，所述媒體流接收器以所述重 傳請求發(fā)送丟失分組消息，所述丟失分組消息使得所述當前接收的媒體流 的被識別的部分被傳回，并且發(fā)送信道加入消息，以使得解碼新媒體流所 需的新媒體流的解碼器信息部分被傳回。
13. 根據(jù)權(quán)利要求IO所述的裝置，其中，所述媒體流接收器使用被多 個不同重傳設(shè)備共享的所述重傳請求中的因特網(wǎng)協(xié)議(IP)任播目的地地 址，所述IP任播目的地地址使得所述重傳請求被路由到所述多個不同重傳 設(shè)備中具有最便宜的路由成本的 一個重傳設(shè)備。
14. 一種裝置，包括媒體傳送設(shè)備，其被配置為緩存多播媒體流的一部分， 所述媒體傳送設(shè)備還被配置為接收單播因特網(wǎng)協(xié)議(IP)消息，所述 單播因特網(wǎng)協(xié)議(IP)消息請求重傳所述多播媒體流的至少一部分并且然 后單播返回與所請求的多播媒體流的部分相對應的被緩存的所述多播媒體 流的部分。
15. 根據(jù)權(quán)利要求14所述的裝置，其中，所述媒體傳送設(shè)備既充當多 播所述媒體流的初始傳送源又充當用于重傳返回在所述單播IP消息中所請 求的被緩存的所述媒體流的部分的重傳源。
16. 根據(jù)權(quán)利要求14所述的裝置，其中，所述媒體傳送設(shè)備被配置為識別所述單播IP消息中的重傳從所述多播媒體流丟失的媒體分組的請求，并且然后發(fā)回與所述丟失的媒體分組相對應的被緩存的所述多播媒體流的部分。
17. 根據(jù)權(quán)利要求14所述的裝置，其中，所述媒體傳送設(shè)備被配置為 識別所述單播IP消息中的加入新媒體流的請求，并且然后突發(fā)返回被緩存 的數(shù)據(jù)以使得接收器能夠開始提供所述新媒體流。
18. 根據(jù)權(quán)利要求17所述的裝置，其中，所述媒體傳送設(shè)備被配置為 發(fā)送解碼器信息，并且突發(fā)傳送一組被緩存的媒體流，該組被緩存的媒體 流包括經(jīng)幀內(nèi)編碼的媒體幀(I幀)，所述I幀是用于在下一I幀在針對所 述流的本地多播中被傳送之前解碼所述新媒體流的部分所需的。
19. 根據(jù)權(quán)利要求14所述的裝置，其中，所述媒體傳送設(shè)備被配置為 傳送多播媒體流，并且與傳送相同多播媒體流的其它媒體傳送設(shè)備共享因 特網(wǎng)協(xié)議(IP)源地址，被共享的IP源地址使得只有所述多個多播媒體流 中的一個被路由到任意一個媒體流接收器。
全文摘要
實時傳輸協(xié)議(RTP)和與其有關(guān)的標準定義了重傳分組格式和通過數(shù)據(jù)已經(jīng)丟失的否定確認(NACK)分組進行反饋的方式。在一個實施例中，單播RTP修復會話與主要的特定源多播(SSM)多播會話相關(guān)聯(lián)。實時傳輸控制協(xié)議(RTCP)NACK分組(28)然后被用于反饋到SSM反饋目標地址。這動態(tài)地例示出用于多播會話的單播RTP修復。該修復方案可被用于修復多播信道或者加入新多播信道。在另一實施例中，媒體傳送設(shè)備與一個或多個其它媒體傳送設(shè)備共享IP地址。被共享的IP地址還可以被用于將多個相同的多播媒體流(14)路由到不同的媒體流接收器(24)。
文檔編號H04J3/00GK101473571SQ200780022360
公開日2009年7月1日 申請日期2007年8月20日 優(yōu)先權(quán)日2006年9月11日
發(fā)明者戴維·R·奧蘭 申請人:思科技術(shù)公司