專利名稱：媒體服務(wù)方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種媒體服務(wù)方法及系統(tǒng)。
背景技術(shù)：
移動流媒體技術(shù)是把連續(xù)的聲音和影像信息經(jīng)過采集、壓縮處 理后存儲到網(wǎng)絡(luò)服務(wù)器上，使移動終端用戶能夠一邊下載一邊收聽、 觀看，而不需要等到整個多媒體文件下載完成就可以即時觀看的技 術(shù)。在提供移動流々某體業(yè)務(wù)時， 一般是根據(jù)用戶歸屬的物理區(qū)域分 別架設(shè)服務(wù)器節(jié)點，由該節(jié)點為本區(qū)域內(nèi)的用戶提供媒體服務(wù)。當(dāng) 系統(tǒng)中的媒體文件越來越多時，會給節(jié)點的存儲造成很大壓力，同 時對于一些較生僻的冷門內(nèi)容，每個節(jié)點都保存一份會造成存儲資 源的浪費，但是，如果為了減輕存儲壓力使每個節(jié)點有選擇性地保 存部分媒體文件，當(dāng)用戶請求節(jié)點上不存在的^某體文件時，系統(tǒng)無法提供服務(wù)，影響用戶體驗。 發(fā)明內(nèi)容針對相關(guān)技術(shù)中的服務(wù)器分節(jié)點在存儲資源時產(chǎn)生的存儲資源 浪費以及資源不存在時系統(tǒng)無法提供服務(wù)的問題而提出本發(fā)明，為此，本發(fā)明的主要目的在于提供一種改進(jìn)的媒體服務(wù)方案，以解決 上述問題至少之一。為了實現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，^是供了一種々某體 服務(wù)方法。根據(jù)本發(fā)明的i某體服務(wù)方法包括邊緣節(jié)點接收來自用戶設(shè)備 的i某體服務(wù)請求，其中，媒體服務(wù)請求用于請求媒體資源；邊緣節(jié) 點判斷其能否為用戶設(shè)備提供媒體資源；邊緣節(jié)點在判斷結(jié)果為否 的情況下，向中心節(jié)點發(fā)送請求消息；邊緣節(jié)點接收來自中心節(jié)點 響應(yīng)于請求消息的媒體資源，并將媒體資源發(fā)送給用戶設(shè)備。優(yōu)選地，邊緣節(jié)點接收來自中心節(jié)點響應(yīng)于請求消息的媒體資 源包括中心節(jié)點向邊緣節(jié)點發(fā)送攜帶有用于提供媒體資源的媒體 服務(wù)器地址的URL;邊緣節(jié)點根據(jù)URL向URL對應(yīng)的媒體服務(wù)器 發(fā)起媒體服務(wù)請求，并接收來自URL對應(yīng)的媒體服務(wù)器的媒體資源。優(yōu)選地，邊緣節(jié)點向中心節(jié)點發(fā)送請求消息包括邊緣節(jié)點向 用戶設(shè)備發(fā)送攜帶有邊緣節(jié)點的媒體服務(wù)器地址的URL,其中， URL中攜帶有邊緣節(jié)點不能提供媒體資源的指示標(biāo)識；用戶設(shè)備根 據(jù)URL向URL對應(yīng)的々某體服務(wù)器發(fā)起4某體服務(wù)請求；URL對應(yīng)的 媒體服務(wù)器接收到來自用戶設(shè)備的服務(wù)請求之后，向中心節(jié)點發(fā)送 "i青求消息。優(yōu)選地，在判斷結(jié)果為是的情況下，邊緣節(jié)點將媒體資源發(fā)送 給用戶設(shè)備。優(yōu)選地，在邊緣節(jié)點接收到來自用戶設(shè)備的々某體服務(wù)請求之前， 方法還包括邊緣節(jié)點根據(jù)預(yù)定策略保存媒體資源。為了實現(xiàn)上述目的，才艮據(jù)本發(fā)明的另一方面，4是供了一種々某體 服務(wù)系統(tǒng)。
根據(jù)本發(fā)明的媒體服務(wù)系統(tǒng)包括邊緣節(jié)點和中心節(jié)點，其中，
邊緣節(jié)點包括第一接收模塊，用于接收來自用戶設(shè)備的媒體服務(wù) 請求，其中，媒體服務(wù)請求用于請求媒體資源；判斷才莫塊，用于判 斷邊緣節(jié)點能夠為用戶設(shè)備提供媒體資源；第一發(fā)送模塊，用于在 判斷模塊的判斷結(jié)果為否的情況下，向中心節(jié)點發(fā)送請求消息；第 二接收模塊，邊緣節(jié)點接收來自中心節(jié)點響應(yīng)于請求消息的媒體資 源；第二發(fā)送模塊，用于將媒體資源發(fā)送給用戶設(shè)備。
優(yōu)選地，第二接收模塊包括第一接收子模塊，用于接收來自 中心節(jié)點的攜帶有用于提供媒體資源的媒體服務(wù)器地址的URL;發(fā) 起子模塊，用于根據(jù)URL向URL對應(yīng)的媒體服務(wù)器發(fā)起媒體服務(wù) 請求；第二接收子模塊，用于接收來自URL對應(yīng)的媒體服務(wù)器的媒
體資源。
優(yōu)選地，第一發(fā)送模塊包括第一發(fā)送子模塊，用于向用戶設(shè) 備發(fā)送攜帶有邊緣節(jié)點的媒體服務(wù)器地址的URL,其中，URL中攜 帶有邊緣節(jié)點不能提供媒體資源的指示標(biāo)識，以便于用戶設(shè)備根據(jù) URL向URL對應(yīng)的媒體服務(wù)器發(fā)起媒體服務(wù)請求；第二發(fā)送子模 塊，用于在接收到來自用戶設(shè)備的服務(wù)請求之后，向中心節(jié)點發(fā)送 -清求消息。
優(yōu)選地，邊緣節(jié)點還包括保存才莫塊，用于根據(jù)預(yù)定策略保存 媒體資源。
優(yōu)選地，中心節(jié)點包括第三接收才莫塊，用于接收來自邊緣節(jié) 點請求消息，其中，請求消息用于請求力某體資源第三發(fā)送才莫塊， 用于將媒體資源發(fā)送給邊緣節(jié)點。
7通過本發(fā)明，采用了根據(jù)策略在分節(jié)點(即，邊緣節(jié)點)上保 存媒體資源，當(dāng)用戶終端請求的媒體資源在分節(jié)點上不存在時，該 分節(jié)點從中心節(jié)點獲取該^某體資源，解決了的服務(wù)器分節(jié)點在存儲 資源時產(chǎn)生的存儲資源浪費以及資源不存在時系統(tǒng)無法提供服務(wù)的 問題，進(jìn)而達(dá)到了優(yōu)化系統(tǒng)的資源共享能力以及提高用戶體驗的效 果。


此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本申 請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并
不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中
圖1是根據(jù)本發(fā)明實施例的媒體服務(wù)方法的流程圖2是根據(jù)本發(fā)明實施例的移動流4某體系統(tǒng)組網(wǎng)的結(jié)構(gòu)示意
圖3是根據(jù)本發(fā)明實施例的服務(wù)中繼方法的流程圖4是根據(jù)本發(fā)明實施例的以非中繼形式提供點播服務(wù)的流程
圖5是根據(jù)本發(fā)明實施例的以中繼形式提供點播服務(wù)的流程
圖6是根據(jù)本發(fā)明實施例的媒體服務(wù)系統(tǒng)的結(jié)構(gòu)框圖7是根據(jù)本發(fā)明實施例的媒體服務(wù)系統(tǒng)具體的結(jié)構(gòu)框圖。
具體實施例方式
功能相克述
相關(guān)技術(shù)中的服務(wù)器分節(jié)點在存儲資源時產(chǎn)生的存儲資源浪費 以及資源不存在時系統(tǒng)無法提供服務(wù)的問題，本發(fā)明實施例提供了
一種媒體服務(wù)方案，該方案的處理原則如下邊緣節(jié)點接收來自用 戶設(shè)備的媒體服務(wù)請求，其中，媒體服務(wù)請求用于請求媒體資源； 邊緣節(jié)點確定在其不能為用戶設(shè)備提供々某體資源的情況下，向中心 節(jié)點發(fā)送請求消息；邊緣節(jié)點接收來自中心節(jié)點響應(yīng)于請求消息的 媒體資源，并將媒體資源發(fā)送給用戶設(shè)備。
需要說明的是，在不沖突的情況下，本申請中的實施例及實施 例中的特4i可以相互組合。下面將參考附圖并結(jié)合實施例來詳細(xì)"i兌 明本發(fā)明。
在以下實施例中，在附圖的流程圖示出的步-銀可以在i者如一組 計算才幾可執(zhí)行指令的計算機系統(tǒng)中執(zhí)行，并且，雖然在流程圖中示 出了邏輯順序，4旦是在某些情況下，可以以不同于此處的順序寺丸行 所示出或描述的步驟。
方法實施例
根據(jù)本發(fā)明的實施例，提供了 一種々某體服務(wù)方法，圖1是根據(jù) 本發(fā)明是實施例的々某體月良務(wù)方法的流程圖，如圖1所示，該方法包 括如下的步艱^ S102至步-驟S106:
步驟S102，邊緣節(jié)點接收來自用戶設(shè)備的媒體服務(wù)請求，其中， 媒體服務(wù)請求用于請求媒體資源。步驟S104,邊緣節(jié)點判斷該邊緣節(jié)點能否為用戶設(shè)備提供請求 的媒體資源，并在確定在其不能為用戶設(shè)備提供媒體資源的情況下， 向中心節(jié)點發(fā)送請求消息；在邊緣節(jié)點確定其能為用戶設(shè)備提供4某 體資源的情況下，邊緣節(jié)點將媒體資源發(fā)送給用戶設(shè)備。
步驟S106，邊緣節(jié)點接收來自中心節(jié)點響應(yīng)于請求消息的々某體 資源，并將媒體資源發(fā)送給用戶設(shè)備。
邊緣節(jié)點不能為用戶設(shè)備提供媒體資源的原因可以是該邊緣節(jié) 點不存在該々某體資源，^f旦原因并不限于此，例如，該原因還可以是 因為邊緣節(jié)點的負(fù)載過大等。
需要說明的是，邊緣節(jié)點不需要保存所有的媒體資源，可以根 據(jù)預(yù)定策略保存媒體資源，例如，可以根據(jù)該媒體資源點播的次數(shù)， 該々某體資源的創(chuàng)建時間等。
其中，在步驟S106中的邊緣節(jié)點接收來自中心節(jié)點響應(yīng)于請 求消息的媒體資源包括如下步驟
步驟A，中心節(jié)點向邊緣節(jié)點發(fā)送攜帶有用于提供^ 某體資源的 J 某體月良務(wù)器地址的統(tǒng)一資源定位符(Uniform Resource Locator,簡 稱為URL )。
步驟B ，邊緣節(jié)點根據(jù)URL向URL對應(yīng)的媒體服務(wù)器發(fā)起媒 體服務(wù)請求，并接收來自URL對應(yīng)的媒體服務(wù)器的媒體資源。
在步驟SI04中，邊緣節(jié)點向中心節(jié)點發(fā)送請求消息包括如下 步驟
10步驟c,邊緣節(jié)點向用戶設(shè)備發(fā)送攜帶有邊緣節(jié)點的媒體服務(wù) 器地址的URL，其中，URL中攜帶有邊緣節(jié)點不存在媒體資源的指 示標(biāo)識。
步驟D,用戶設(shè)備根據(jù)URL向URL對應(yīng)的媒體服務(wù)器發(fā)起媒 體服務(wù)請求。
步驟E, URL對應(yīng)的媒體服務(wù)器接收到來自用戶設(shè)備的服務(wù)請 求之后，向中心節(jié)點發(fā)送請求消息。
下面結(jié)合具體的網(wǎng)絡(luò)對上述步驟102至步驟S106，圖2是根據(jù) 本發(fā)明實施例的移動流^某體系統(tǒng)組網(wǎng)的結(jié)構(gòu)示意圖，如圖2所示， 在該移動流々某體系統(tǒng)中采用總部-省分二級架構(gòu)的方式進(jìn)4亍部署，在 總部設(shè)置一個中心節(jié)點(也稱為總部節(jié)點)；在各省設(shè)置一個邊緣節(jié) 點(也稱為省分節(jié)點或本地節(jié)點)，其中，在省分節(jié)點的媒體服務(wù)器 上配置總部節(jié)點的業(yè)務(wù)引擎地址信息，在此節(jié)點是指一個業(yè)務(wù)引擎 設(shè)備和多臺媒體服務(wù)器設(shè)備的組合。
業(yè)務(wù)引擎用來管理媒體服務(wù)器設(shè)備和各媒體服務(wù)器設(shè)備上存放 的文件信息(即，々某體資源)，其中，省分業(yè)務(wù)引擎還負(fù)責(zé)處理與用 戶i殳備(User Equipment,簡稱為UE)的交互。業(yè)務(wù)引擎4妄收到來 自用戶設(shè)備的媒體服務(wù)請求后，先從數(shù)據(jù)庫中檢索出有哪些媒體服 務(wù)器設(shè)備包含用戶請求的媒體文件(即，媒體資源)，然后，綜合該 省分節(jié)點內(nèi)各媒體服務(wù)器的硬件性能和/或并發(fā)流數(shù)選擇一個最合 適的服務(wù)器，最終組裝出用于提供々某體服務(wù)的URL提供給用戶，用 戶使用此URL進(jìn)行媒體服務(wù)請求。
媒體服務(wù)器上可以為用戶提供點播、直播和下載等媒體服務(wù)， 可以由多臺媒體服務(wù)器設(shè)備共同組成集群，媒體服務(wù)器使用大容量 磁陣保存節(jié)點上媒體文件的實體內(nèi)容。總部節(jié)點中的音^L步貞無線4妄入十辦i義(Wireless Access Protocol， 簡稱為WAP)門戶負(fù)責(zé)展現(xiàn)移動流媒體系統(tǒng)中的媒體文件，用戶設(shè) 備通過訪問WAP門戶瀏覽系統(tǒng)中的4某體文4牛列表。
總部節(jié)點的媒體服務(wù)器上保存所有的々某體文件，每個省分節(jié)點 根據(jù)一定的策略只存儲部分實體文件，例如，可以根據(jù)系統(tǒng)實際運 營情況只保存熱門內(nèi)容或者新上線的內(nèi)容并定期動態(tài)調(diào)整。所有的 移動流媒體用戶都可以根據(jù)其終端編號(例如，手機號碼)歸屬到 某個邊緣節(jié)點。當(dāng)一個用戶設(shè)備請求々某體服務(wù)時，由無線網(wǎng)絡(luò)或有 線固定網(wǎng)絡(luò)負(fù)責(zé)將請求發(fā)送到其歸屬的省分節(jié)點的省分業(yè)務(wù)引擎， 該省分業(yè)務(wù)引擎^^據(jù)本節(jié)點數(shù)據(jù)庫中保存的々某體文件記錄進(jìn)^f亍查 詢，如果在省分^某體服務(wù)器上存在用戶請求的^某體文件，則直接由 該節(jié)點的本地媒體服務(wù)器為用戶提供服務(wù)；如果省分媒體服務(wù)器上 不存在對應(yīng)J 某體文件，則觸發(fā)月l務(wù)中繼流禾呈，經(jīng)由省分々某體月良務(wù)器、 總部業(yè)務(wù)引擎和總部媒體服務(wù)器等網(wǎng)元通過一系列交互后選擇一個 最優(yōu)的可用總部媒體服務(wù)器設(shè)備，由其負(fù)責(zé)向省分媒體服務(wù)器提供 用戶請求內(nèi)容的媒體服務(wù)。下面對該中繼流程進(jìn)行詳細(xì)的介紹。
該中繼流程為當(dāng)用戶設(shè)備請求服務(wù)時若自身歸屬節(jié)點不具備 服務(wù)條件，先由歸屬節(jié)點內(nèi)的省分媒體服務(wù)器向總部業(yè)務(wù)引擎發(fā)起 重定向請求(需要說明的是，重定向是指根據(jù)系統(tǒng)中媒體文件的分 布信息和各媒體設(shè)備的運行情況，選取一臺媒體服務(wù)器為用戶提供 服務(wù))，總部業(yè)務(wù)引擎生成一個包括總部媒體服務(wù)器地址的服務(wù) URL返回給省分媒體服務(wù)器，省分媒體服務(wù)器使用此URL向總部 媒體服務(wù)器請求服務(wù)，總部媒體服務(wù)器向省分媒體服務(wù)器發(fā)送媒體 碼流，省分媒體服務(wù)器將々某體碼流轉(zhuǎn)發(fā)給用戶設(shè)備，完成媒體交互 流程。其中提供總部媒體服務(wù)器與省分媒體服務(wù)器之間、省分媒體 服務(wù)器與用戶設(shè)備之間時的數(shù)據(jù)傳輸形式跟服務(wù)類型相關(guān)， 一般的 ^J 某體凄t寺居傳豐lr是通過實時4專車lr十辦i義(Real-time Transport Protocol, 簡一爾為RTP )禾口實時傳IIH空制十辦i義(Real-time Transport Control
12Protocol,簡稱為RTCP)配合完成。圖3是根據(jù)本發(fā)明實施例的服 務(wù)中繼方法的流^E圖，如圖3所示，該流禾呈包4舌如下步^^:
步驟S301,用戶設(shè)備向歸屬節(jié)點的省分業(yè)務(wù)引擎發(fā)起媒體服務(wù) 請求。
步驟S302，省分業(yè)務(wù)引擎接收到該媒體服務(wù)請求后，在數(shù)據(jù)庫 中查找用戶請求的內(nèi)容在本地節(jié)點的々某體服務(wù)設(shè)備上是否存在。
步驟S303,根據(jù)步驟S302中的查找結(jié)果，并結(jié)合省分節(jié)點中 々某體服務(wù)設(shè)備的硬件性能和并發(fā)流數(shù)等情況確定省分節(jié)點是否可以 提供服務(wù)。
步驟S304，如果省分節(jié)點可以為用戶提供服務(wù)，直接由省分媒 體服務(wù)器向用戶設(shè)備發(fā)送i某體碼流，開始服務(wù)流程。
步驟S305,如果省分節(jié)點無法提供服務(wù)，需要觸發(fā)中繼流程。 此時，由省分業(yè)務(wù)引擎生成一個臨時的服務(wù)URL返回給用戶設(shè)備， URL中的月良務(wù)i殳備網(wǎng)3各十辦i義(Internet Protocol,簡稱為IP) i也址;真 寫本節(jié)點中任意一個々某體服務(wù)器的地址，同時，在URL中通過一個 標(biāo)識參數(shù)表示本次服務(wù)需要走中繼流程。
步驟S306,用戶i殳備4吏用步驟S305中返回的URL向省分々某體 服務(wù)器發(fā)起請求，省分媒體服務(wù)器取出請求URL中的中繼標(biāo)識參 數(shù)，向總部業(yè)務(wù)引擎發(fā)起重定向請求。
步驟S307,總部業(yè)務(wù)引擎在總部節(jié)點內(nèi)進(jìn)4亍重定向，生成一個 含有總部媒體服務(wù)器地址的可用URL,然后，將URL封裝在某種 格式的響應(yīng)消息中將結(jié)果返回給發(fā)出請求的省分媒體服務(wù)器。步驟S308，省分媒體服務(wù)器使用接收到的新URL向總部媒體 服務(wù)器請求服務(wù)，總部媒體服務(wù)器向省分媒體服務(wù)器發(fā)送所請求內(nèi) 容的碼流ft據(jù)。
步驟S309，省分媒體服務(wù)器將接收到的碼流數(shù)據(jù)轉(zhuǎn)發(fā)給用戶設(shè) 備，開始媒體服務(wù)流程。
下面以用戶設(shè)備請求視頻文件點播月良務(wù)為例，分別說明當(dāng)用戶 歸屬的省分節(jié)點上存在用戶請求的內(nèi)容和不存在用戶請求的內(nèi)容兩 種情況下，本實施例的流程。
圖4是根據(jù)本發(fā)明實施例的以非中繼形式提供點播服務(wù)的流程 圖，如圖4所示，在該流程中由省分流媒體服務(wù)器直接為用戶提供 月良務(wù)，UE—4殳指移動手才幾終端；WAP是指音#見頻WAP門戶，門 戶上提供節(jié)目入口列表，實際應(yīng)用中用戶i殳備先訪問WAP門戶， 在頁面上選擇一個感興趣的內(nèi)容進(jìn)行訪問觸發(fā)點播流程；本地流々某 體月良務(wù)器(Local Streaming Server,簡稱為LSS )部署在網(wǎng)絡(luò)邊纟彖節(jié) 點，負(fù)責(zé)某個省的用戶本地接入，提供流媒體的點播、直播、下載 等服務(wù)的々某體服務(wù)器；本地業(yè)務(wù)引擎(Local Service Engine,簡稱 為LSE)與本地流媒體服務(wù)器組成省分節(jié)點，共同為用戶提供移動 流々某體服務(wù)。如圖4所示，該流程包括如下步驟
步驟S401 ，用戶i殳備通過無線網(wǎng)絡(luò)訪問移動流々某體系統(tǒng)的WAP 門戶。
步驟S402， WAP門戶將移動流媒體系統(tǒng)中的音3見頻々某體文件 以列表的方式展玉見在頁面上，返回纟會用戶i殳備。步驟S403,用戶選擇感興趣的媒體文件進(jìn)行點播，向自身節(jié)點 的LSE發(fā)送點播服務(wù)請求，該消息是一個超文本傳輸協(xié)議 (HyperText Transfer Protocol,簡稱為HTTP )才各式的GET i會求。
步驟S404， LSE在自身節(jié)點數(shù)據(jù)庫的內(nèi)容記錄表中檢索，查找 用戶請求的內(nèi)容在本地流媒體服務(wù)器上是否存在，如果存在用戶請 求的內(nèi)容流々某體服務(wù)器運行正常，則將結(jié)果消息以HTTP包的形式 返回，HTTP消息頭中結(jié)果碼是200, HTTP消息體中包含了 LSE 生成的結(jié)果URL, URL中設(shè)置proxy參數(shù)為0表示該內(nèi)容在省分節(jié) 點存在，不需要走服務(wù)中繼流程。
步-驟S405,用戶i殳備收到LSE的響應(yīng)后，取出響應(yīng)消息中的 URL,以實時;危十力4義(Real-time Streaming Protocol,簡^爾為RTSP ) 消息向LSS發(fā)起服務(wù)請求。
步驟S406, LSS收到用戶設(shè)備RTSP請求后，判斷發(fā)現(xiàn)其i青求 URL中proxy參數(shù)為0,在服務(wù)器的磁陣上定位到用戶請求的文件 所在位置，開始向用戶設(shè)備發(fā)送碼流數(shù)據(jù)，提供點播服務(wù)。
圖5是根據(jù)本發(fā)明實施例的以中繼形式提供點播服務(wù)的流程圖 如圖5所示，當(dāng)用戶設(shè)備請求點播時，省分業(yè)務(wù)引擎向用戶設(shè)備返 回的消息中通知用戶設(shè)備需要觸發(fā)中繼流程，然后通過省分流々某體 服務(wù)器、總部業(yè)務(wù)引擎和總部流媒體服務(wù)器之間進(jìn)行交互完成點播 中繼流程。全局流4某體服務(wù)器(Global Streaming Server,簡稱為 GSS),部署在移動流i某體系統(tǒng)的總部節(jié)點，通過中繼的方式分擔(dān)各 省分節(jié)點的服務(wù)壓力；全局業(yè)務(wù)引擎(Golbal Service Engine,簡稱 為GSE)當(dāng)收到LSS的重定向請求時在總部節(jié)點的流i某體服務(wù)器器 中選擇一個最優(yōu)的可用設(shè)備，將該服務(wù)器的信息傳回給LSS。該流 程包括如下步驟步驟S501,用戶i殳備訪問移動流々某體系統(tǒng)的WAP門戶。
步驟S502， WAP門戶將系統(tǒng)中的音視頻媒體文件以列表的方 式展現(xiàn)在頁面上，返回主合用戶i殳備。
步驟S503，用戶選擇感興趣的媒體文件進(jìn)行點播，向自身節(jié)點 的LSE發(fā)送點播服務(wù)請求。
步驟S504, LSE在節(jié)點數(shù)據(jù)庫的內(nèi)容記錄表中檢索，查找用戶 請求的內(nèi)容在本地流媒體服務(wù)器上是否存在，如果不存在則生成一 個臨時的服務(wù)URL ， URL中的流々某體服務(wù)器地址填寫本地節(jié)點中任 一流J 某體月良務(wù)器IP,同時通過將URL中的標(biāo)識參凄t proxy設(shè)置為1 表示本地?zé)o此內(nèi)容，后續(xù)需要觸發(fā)中繼流程，響應(yīng)消息也以HTTP 包的形式返回，HTTP消息頭中結(jié)果碼是200, HTTP消息體中包含 了 LSE生成的結(jié)果URL。
步驟S505,用戶i殳備收到LSE的響應(yīng)后，取出響應(yīng)消息體中 的URL，以RTSP才各式向LSS發(fā)起月良務(wù)i青求。
步驟S506, LSS收到用戶設(shè)備請求后，判斷發(fā)現(xiàn)其請求URL 中proxy參數(shù)為l，向GSE發(fā)起重定向請求，請求獲取一個可以服 務(wù)的點纟番URL。
步驟S507， GSE檢索總部節(jié)點數(shù)據(jù)庫的內(nèi)容記錄表，查找哪些 流媒體設(shè)備包含用戶請求的媒體文件，同時根據(jù)各設(shè)備的運行情況 選擇一個流媒體服務(wù)器，最終生成一個可以給LSS提供中繼服務(wù)的 可用URL,才各式形力n:
rtsp:〃<GSS-IP>:<GSS-Port>/vod.3gp7userid=8618807880000&s ubcontentid=9013100020090514012300...,
16其中，GSS-IP是總部節(jié)點中一個可以服務(wù)的流々某體服務(wù)器的地 址，GSS-Port是該流媒體服務(wù)器提供視頻流媒體服務(wù)的端口號，然 后GSE封裝一個RTSP響應(yīng)消息，消息中結(jié)果碼填為302 ( Moved Temporarily,重定向，表示要完成請求必須進(jìn)行進(jìn)一步操作)，同時 將新生成的URL填入響應(yīng)包頭(response-header)中的4立置 (Location )參數(shù)域中，然后返回給省分流々某體服務(wù)器。
步-驟S508， LSS收到結(jié)果碼為302的RTSP響應(yīng)后，/人響應(yīng)消 息包里response-header的Location i或中取出tf的URL發(fā)起中繼"i青 求。
步驟S509, GSS收到LSS的服務(wù)請求后定位到所請求的實體 文件，開始向LSS發(fā)送碼流數(shù)據(jù)。
步驟S510, LSS將收到的碼流數(shù)據(jù)轉(zhuǎn)發(fā)給用戶設(shè)備，開始給用 戶提供點播服務(wù)。
在本實施例中以點播服務(wù)為例進(jìn)行說明，同理，也可以擴展到 直才番和下載等々某體力良務(wù)領(lǐng)域。以上所述〗又為本發(fā)明的一種4交好的實
施方式，但本發(fā)明的保護(hù)范圍并不局限于此，所有基于本發(fā)明的實 質(zhì)進(jìn)行的各種替換和修改，均應(yīng)屬于本發(fā)明的權(quán)利保護(hù)范圍。
裝置實施例
根據(jù)本發(fā)明的實施例，提供了一種媒體服務(wù)系統(tǒng)，圖6是才艮據(jù) 本發(fā)明實施例的々某體服務(wù)系統(tǒng)的結(jié)構(gòu)框圖，如圖6所示，中心節(jié)點 可以連接一個或多個邊緣節(jié)點，邊緣節(jié)點包括第一接收模塊62、 第一發(fā)送才莫塊64、第二4妻收沖莫塊66、第二發(fā)送才莫塊68,下面對該 邊纟彖節(jié)點進(jìn)4于詳細(xì)的介紹。第一接收模塊62,用于接收來自用戶設(shè)備的媒體服務(wù)請求，其 中，媒體服務(wù)請求用于請求媒體資源；判斷模塊60連接至第一接收 模塊62和第一發(fā)送模塊64,該模塊用于判斷邊緣節(jié)點能否為用戶 設(shè)備提供媒體資源；第一發(fā)送模塊64連接至第一接收模塊62,用 于在確定邊緣節(jié)點不能為用戶設(shè)備提供媒體資源的情況下，向中心 節(jié)點發(fā)送請求消息；第二接收模塊66連接至第一發(fā)送模塊64,邊 緣節(jié)點接收來自中心節(jié)點響應(yīng)于請求消息的媒體資源；第二發(fā)送模 塊68連接至第二接收模塊66，用于將媒體資源發(fā)送給用戶設(shè)備。
圖7是根據(jù)本發(fā)明實施例的媒體服務(wù)系統(tǒng)具體的結(jié)構(gòu)框圖，如 圖7所示，第二接收模塊66包括第一接收子模塊662、發(fā)起子模 塊664、第二接收子模塊666，下面對此進(jìn)行詳細(xì)描述。
第一接收子模塊662，用于接收來自中心節(jié)點的攜帶有用于提 供媒體資源的媒體服務(wù)器地址的URL;發(fā)起子模塊664連接至第一 接收子模塊662，用于根據(jù)URL向URL對應(yīng)的媒體服務(wù)器發(fā)起媒 體服務(wù)請求；第二接收子模塊666,連接至發(fā)起子模塊664用于接 收來自URL對應(yīng)的媒體服務(wù)器的媒體資源。
如圖7所示，第一發(fā)送才莫塊64包括第一發(fā)送子才莫塊642和 第二發(fā)送子模塊644，其中，第一發(fā)送子模塊642，用于向用戶設(shè)備 發(fā)送攜帶有邊緣節(jié)點的媒體服務(wù)器地址的URL，其中，URL中攜帶 有邊緣節(jié)點不能提供媒體資源的指示標(biāo)識，以便于用戶設(shè)備根據(jù) URL向URL對應(yīng)的媒體服務(wù)器發(fā)起媒體服務(wù)請求；第二發(fā)送子模 塊644，用于在接收到來自用戶設(shè)備的服務(wù)請求之后，向中心節(jié)點 發(fā)送請求消息。
如圖7所示，該邊緣節(jié)點還包括4呆存才莫塊74,該沖莫塊用于才艮 據(jù)預(yù)定策略保存々某體資源。如圖7所示，該中心節(jié)點包括第三接收模塊76、第三發(fā)送模 塊78 ，下面刈-該中心節(jié)點進(jìn)4亍詳細(xì)的介紹。
第三接收模塊76,用于接收來自邊緣節(jié)點請求消息，其中，請 求消息用于請求媒體資源第三發(fā)送模塊78連接至第三接收模塊 76,用于將媒體資源發(fā)送給邊緣節(jié)點。
可以看出，通過本發(fā)明描述的方法使各省分節(jié)點按照一定的策 略保存系統(tǒng)中的部分內(nèi)容資源，同時對于本地節(jié)點不存在的內(nèi)容可 以通過中繼的方式提供服務(wù)，能有效地解決節(jié)點內(nèi)容存儲和提供穩(wěn) 定服務(wù)之間的矛盾，較好地優(yōu)化了系統(tǒng)的資源共享能力。
顯然，本領(lǐng)域的4支術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或 各步艱《可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算 裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡(luò)上，可選地，它們 可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲
在存儲裝置中由計算裝置來執(zhí)行，或者將它們分別制作成各個集成 電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模 塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。
以上所述^又為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明， 對于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在 本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等， 均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
19
權(quán)利要求
1.一種媒體服務(wù)方法，其特征在于，包括邊緣節(jié)點接收來自用戶設(shè)備的媒體服務(wù)請求，其中，所述媒體服務(wù)請求用于請求媒體資源；所述邊緣節(jié)點判斷其能否為所述用戶設(shè)備提供所述媒體資源；所述邊緣節(jié)點在判斷結(jié)果為否的情況下，向中心節(jié)點發(fā)送請求消息；所述邊緣節(jié)點接收來自所述中心節(jié)點響應(yīng)于所述請求消息的所述媒體資源，并將所述媒體資源發(fā)送給所述用戶設(shè)備。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述邊緣節(jié)點接收 來自所述中心節(jié)點響應(yīng)于所述請求消息的所述々某體資源包括所述中心節(jié)點向所述邊緣節(jié)點發(fā)送攜帶有用于^是供所述 媒體資源的媒體服務(wù)器地址的URL;所述邊緣節(jié)點根據(jù)所述URL向所述URL對應(yīng)的媒體服務(wù) 器發(fā)起媒體服務(wù)請求，并接收來自所述URL對應(yīng)的媒體服務(wù) 器的所述i某體資源。
3. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述邊緣節(jié)點向所 述中心節(jié)點發(fā)送所述請求消息包括所述邊緣節(jié)點向所述用戶設(shè)備發(fā)送攜帶有所述邊緣節(jié)點 的媒體服務(wù)器地址的URL，其中，所述URL中攜帶有所述邊 緣節(jié)點不能提供所述媒體資源的指示標(biāo)識；所述用戶i殳備才艮據(jù)所述URL向所述URL對應(yīng)的所述J 某體 服務(wù)器發(fā)起媒體服務(wù)請求；所述URL對應(yīng)的媒體服務(wù)器接收到來自所述用戶設(shè)備的 服務(wù)請求之后，向所述中心節(jié)點發(fā)送所述請求消息。
4. 根據(jù)權(quán)利要求1至3中任一項所述的方法，其特征在于，在所 述判斷結(jié)果為是的情況下，所述邊緣節(jié)點將所述々某體資源發(fā)送 給所述用戶i殳備。
5. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述邊緣節(jié)點接 收到來自所述用戶設(shè)備的所述媒體服務(wù)請求之前，所述方法還 包括所述邊緣節(jié)點根據(jù)預(yù)定策略保存^某體資源。
6. —種媒體服務(wù)系統(tǒng)，包括邊緣節(jié)點和中心節(jié)點，其特征在于， 所述邊緣節(jié)點包括第 一接收沖莫塊，用于接收來自用戶設(shè)備的媒體服務(wù)請求， 其中，所述i某體服務(wù)請求用于請求媒體資源；判斷模塊，用于判斷所述邊緣節(jié)點能夠為所述用戶設(shè)備提 供所述媒體資源；第 一發(fā)送模塊，用于在所述判斷模塊的判斷結(jié)果為否的情 況下，向中心節(jié)點發(fā)送請求消息；第二接收模塊，所述邊緣節(jié)點接收來自所述中心節(jié)點響應(yīng) 于所述請求消息的所述媒體資源；第二發(fā)送模塊，用于將所述i某體資源發(fā)送給所述用戶設(shè)備。
7. 根據(jù)權(quán)利要求6所述的系統(tǒng)，其特征在于，所述第二接收模塊 包括第一接收子模塊，用于接收來自所述中心節(jié)點的攜帶有用 于提供所述媒體資源的媒體服務(wù)器地址的URL;發(fā)起子才莫塊，用于才艮據(jù)所述URL向所述URL對應(yīng)的媒體 服務(wù)器發(fā)起媒體服務(wù)請求；第二接收子才莫塊，用于接收來自所述URL對應(yīng)的々某體服 務(wù)器的所述媒體資源。
8. 根據(jù)權(quán)利要求6所述的系統(tǒng)，其特征在于，第一發(fā)送模塊包括第一發(fā)送子模塊，用于向所述用戶設(shè)備發(fā)送攜帶有所述邊 緣節(jié)點的媒體服務(wù)器地址的URL，其中，所述URL中攜帶有 所述邊緣節(jié)點不能提供所述媒體資源的指示標(biāo)識，以便于所述起媒體服務(wù)請求；第二發(fā)送子模塊，用于在接收到來自所述用戶設(shè)備的服務(wù) 請求之后，向所述中心節(jié)點發(fā)送所述請求消息。
9. 根據(jù)權(quán)利要求7所述的系統(tǒng)，其特征在于，所述邊緣節(jié)點還包 括保存模塊，用于根據(jù)預(yù)定策略保存媒體資源。
10. 才艮據(jù)4又利要求7至9中任一項所述的系統(tǒng)，其特征在于，所述 中心節(jié)點包括第三接收模塊，用于接收來自所述邊緣節(jié)點請求消息，其 中，請求消息用于請求々某體資源第三發(fā)送模塊，用于將所述媒體資源發(fā)送給所述邊緣節(jié)占
全文摘要
本發(fā)明公開了一種媒體服務(wù)方法及系統(tǒng)，該方法包括邊緣節(jié)點接收來自用戶設(shè)備的媒體服務(wù)請求，其中，媒體服務(wù)請求用于請求媒體資源；邊緣節(jié)點判斷其能否為用戶設(shè)備提供媒體資源；邊緣節(jié)點在判斷結(jié)果為否的情況下，向中心節(jié)點發(fā)送請求消息；邊緣節(jié)點接收來自中心節(jié)點響應(yīng)于請求消息的媒體資源，并將媒體資源發(fā)送給用戶設(shè)備。通過本發(fā)明優(yōu)化了系統(tǒng)的資源共享能力，提高了用戶體驗的效果。
文檔編號H04L29/06GK101626385SQ20091016408
公開日2010年1月13日 申請日期2009年8月10日 優(yōu)先權(quán)日2009年8月10日
發(fā)明者勤 熊, 王印龍, 王德超 申請人:中興通訊股份有限公司