用於無線網絡的多媒體傳送的製作方法

2023-05-20 22:08:21

專利名稱：用於無線網絡的多媒體傳送的製作方法
用於無線網絡的多媒體傳送
背景技術：
3GPP (第三代合作夥伴計劃，wwwJGPP.org)是為第三代(3G ) 移動系統提出技術規範和建議的合作成果。這些建議之一，IP多媒體子 系統(網際協議多媒體子系統或IMS),迅速得到許多人的認可，原因 在於用於IP多媒體的非官方標準服務於3G平臺。
IMS的關鍵特徵之一是把會話啟動協議(SIP)用於呼叫控制和信 令功能。SIP屬於來自網際網路工程任務組(IETF)的RFC標準(RFC 3261 ) ， IETF是負責管理和開發被廣泛接受的用於改造網際網路的技術規 範的組織。SIP也用於促進將多媒體文件(例如視頻剪輯)從一個移動 設備傳送到另 一個接收裝備，例如另 一個終端用戶的行動裝置。
為了傳送視頻剪輯，設置在發送者的手機內的SIP代理常常用於發 送視頻剪輯。例如，如果發送者想要將視頻剪輯發送給指定接收方，首 先將該視頻剪輯裝載到用戶的手機的存儲區域中。使用SIP協議，然後 其中的SIP代理使用由發送者提供的接收方的身份來將該視頻剪輯發送 到接收方。
考慮這樣的情形，其中用戶希望將相同的視頻剪輯發送到一組接收 方(一對多)而不是單個接收方(一對一)。再次地，將該視頻剪輯裝 載到用戶的手機的存儲區域中。用戶指定每個接收方的身份，並且用戶 的手機中的SIP代理依次將視頻剪輯發送到接收方。
儘管基於SIP的方法實現了視頻剪輯的一對多傳送，但是存在許多
缺點。例如，儘管許多現代手機提供指定地址列表的能力，但是該列表
典型地用於快速撥號。更具體而言，目前的地址列表不能被SIP代理用
於將視頻剪輯發送到地址列表中的成員。相反，發送者必須手動地指定 每個接收方。
作為另一個例子，由於視頻剪輯被每次一個地發送給接收方，因此 在發送者的手機和網絡其餘部分之間的帶寬要求是相當大的。例如，如
果用戶希望將5兆字節的視頻剪輯發送給4個接收方，則大約有相當於 20兆字節的視頻數據將被從發送者的行動裝置傳送。由於無線終端鏈路 帶寬(即，行動裝置和到網絡其餘部分的網關之間的帶寬)常常極其有
限且是昂貴的，所以這樣的方法對資源極其有限的網絡資源強加了高帶 寬要求。該限制嚴重製約了當前方法的可伸縮性。
作為又一個例子，用於多媒體數據的 一對多傳送的當前方法可以導 致許多接收方在視頻傳送會話開始之後的數分鐘甚至數小時之後才收 到視頻剪輯。例如，如果指定接收方是接收視頻剪輯的隊列中的第10 個接收方，則該指定接收方在開始接收視頻剪輯之前可能必須等待發送 者的手機中的客戶應用程式完成將視頻剪輯發送到前面的九個接收 方。對於一些實時或近實時視頻流使用情形，當前方法是不能令人滿意 的，原因在於對位於隊列的末尾或靠近隊列末尾的接收方而言時延將會 過長。

發明內容
在一個實施例中，本發明涉及一種用於將多媒體文件從一個用戶的 行動裝置傳送到與另 一個用戶相關聯的用戶裝備的方法。所述方法包括 把邀請從所述用戶的行動裝置發送到所述用戶裝備以請求多媒體文件 的傳送。所述方法還包括在所述用戶的行動裝置和所述裝備之間設置承 載數據信道以便於多媒體文件的傳送，所述傳送被配置成使用消息會話
中繼協議(MSRP)實現。所述方法進一步包括使用MSRP和承載數據 信道來傳送多媒體文件。
在另 一實施例中，本發明涉及一種用於將多媒體文件從一個用戶的 行動裝置傳送到與一個組的多個組成員相關聯的多個用戶裝備的方 法。所述方法包括從伺服器獲得組成員資格信息，所述組成員資格信息 與所述多個組成員有關。所述方法還包括使用所述組成員資格信息將多 媒體文件從應用伺服器發送到所述多個組成員的至少 一個子集。
在另 一實施例中，本發明涉及一種用於將多媒體文件從一個用戶的 行動裝置傳送到與 一個組的多個組成員相關聯的多個用戶裝備的方 法。所述方法包括將包括多媒體文件且指定組接收方的SIP(會話啟動 協議)消息發送到CSCF (呼叫會話控制功能)。所述方法還包括將包 括多媒體文件且指定組接收方的SIP消息轉發到應用伺服器。所述方法 另外包括從伺服器獲得組成員資格信息，所述組成員資格信息與所述多 個組成員有關。所述方法進一步包括使用所述組成員資格信息，使用SIP 將多媒體文件從應用伺服器發送到所述多個組成員的至少一個子集。
在另 一 實施例中，本發明涉及一種包括程序存儲介質的製造物品，
所述介質具有包含在其中的計算機可讀代碼，所述計算機可讀代碼被配 置成將多媒體文件從一個用戶的行動裝置傳送到與一個組的多個組成 員相關聯的多個用戶裝備。所述介質包括用於從伺服器獲得組成員資格 信息的計算機可讀代碼，所述組成員資格信息與所述多個組成員有關。 所述介質還包括用於使用所述組成員資格信息將多媒體文件從應用服 務器發送到所述多個組成員的至少一個子集的計算機可讀代碼。
下面將在本發明的具體描述中結合附圖更詳細地描述本發明的這 些和其他特徵。


在附圖的圖中以舉例而非限制的方式示出了本發明，其中相似的附
圖標記表示同樣的元件，其中
圖1是示出當手機用戶設置一個組時發生的消息流的示例性流程圖。
圖2是示出在用戶註冊期間在用戶的行動裝置和各種網絡部件之間
交換的消息的示例性流程圖。
圖3示出當用戶預訂接收組存在數據時所涉及的示例性消息。
圖4A根據本發明的一個實施例示出在使用MSRP將視頻剪輯從用
戶的行動裝置發送到接收方的視頻接收裝備的過程中所涉及的步驟。 圖4B根據本發明的一個實施例示出了顯示當用戶1希望使用
MSRP承載信道將視頻剪輯傳送到用戶2時交換的消息的示例性流程圖。
圖5A根據本發明的 一個實施例示出使用應用伺服器實現一對多視 頻傳送的步驟。
圖5B根據本發明的一個實施例更詳細地示出一旦AS接收到從用 戶1轉發的SIP邀請消息就使用應用伺服器完成一對多視頻傳送的步驟。
圖5C根據本發明的一個實施例示出了顯示當用戶l希望使用應用 伺服器將視頻剪輯傳送到指定組的多個成員時交換的消息的示例性流程圖。
圖6A根據本發明的一個實施例示出使用SIP消息將視頻剪輯發送 到一個組中的多個組成員的步驟。
圖6B根據本發明的一個實施例示出了顯示當用戶l希望使用應用
伺服器將視頻剪輯傳送到指定組的多個成員時交換的消息的示例性流 程圖。
圖7根據本發明的一個實施例示出了顯示當用戶1希望使用應用服 務器將視頻剪輯傳送到指定組的多個成員時交換的消息的示例性流程圖。
具體實施例方式
現在將參考如附圖中所示的本發明的幾個實施例來詳細地描述本 發明。在以下描述中，闡述了許多具體細節以便提供對本發明的透徹理 解。然而對本領域技術人員將會很明顯的是，可以在沒有這些具體細節 中的一些或全部的情況下實施本發明。在其他實例中，為了不會不必要 地使本發明變得晦澀難懂，就沒有詳細地描述公知的過程步驟和/或結 構。
在下文中描述了包括方法和技術的各種實施例。應當牢記本發明還 涵蓋包括計算機可讀介質的製造物品，所述計算機可讀介質存儲著用於 實現本發明的技術的實施例的計算機可讀指令。所述計算機可讀介質可 以包括例如半導體、磁、光磁、光或用於存儲計算機可讀代碼的計算機 可讀介質的其他形式。此外，本發明還涵蓋著裝置，例如專用和/或可編 程電路，例如用以執行與本發明的實施例有關的任務。這樣的裝置的例 子包括被適當編程的專用計算設備和/或通用計算機並且可以包括計算的組合。
根據本發明的實施例，用戶可以指定待發送到公共或私有組的多媒 體文件，例如視頻剪輯，並且由網絡中的應用伺服器處理對一對多視頻 傳送的請求，由此減少對發送者的行動裝置方的帶寬要求。在以下公開 中，參考視頻剪輯和視頻數據的傳送。然而，做這樣的參考是為了通過 討i侖一致的例子和/或應用來簡化對本發明的理解。本發明的實施例可應 用於任何類型的數據文件的傳送，尤其是包括視頻、音頻和其他類型的 數字數據的多媒體文件的傳送。
本發明的實施例包括這樣的技術，所述技術用於查明組成員的存在 狀態以便可以為存在的(例如登錄的)那些組成員按優先順序排列視頻 剪輯。當發送者請求發送視頻剪輯時可以不向不存在的那些組成員提供 視頻剪輯的拷貝，或者在一個實施例中，可以在以後的時間從應用服務
器向那些組成員提供視頻剪輯的拷貝。
視頻剪輯可以由應用伺服器使用SIP來發送給每個接收方。本發明 的實施例進一步包括使用使應用伺服器和接收方之間的視頻傳送過程
更加高效的協議。這些協議包括MSRP (消息會話中繼協議)、RTP (實
時傳輸協議)等。
可以參考以下的圖和討i侖來更好地理解本發明的實施例的特徵和
優點。圖1-3示出當用戶用組列表管理伺服器(GLMS)創建一個組並 且隨後向一個組(無論是由該用戶還是由其他用戶創建的組)預訂被告 知組數據的變化和被告知組成員的存在狀態時發生的示例性流程。圖1 -3是常規的並且在這裡被討論以便幫助讀者理解包括本發明的實施例
知的，因此在這裡將不對其進行詳細說明。
圖1是示出當蜂窩電話用戶建立 一個組時發生的消息流的示例性流 程圖。在該例子中，用戶的移動裝備(圖1中的UE或用戶裝備)利用 消息101中的HTTP命令Put (放)，HTTP PUT ( group.xml)以便指示 GLMS才艮據文件group.xml創建一個組。文件group.xml與/>共組(即可 以被建立所述組的用戶以外的用戶看到和/或管理的組)有關並且包含組 成員的聯繫數據。應當注意名稱"group (組)"僅僅是例子；所述組和 xml文件可以具有任何合適的名稱。當在這裡使用時，術語用戶移動裝 備或行動裝置包括能夠利用用於數據傳輸的無線介質的任何行動裝置 (例如蜂窩電話、個人數字助理、掌上電腦、膝上型電腦等)。
在消息102中，如果用戶沒有被授權建立列表或者如果用戶沒有用 GLMS正確地鑑別自己，則GLMS可以以HTTP錯誤代碼401做為響應。 下一對消息102和103顯示這樣的情況，其中用戶被正確鑑別並且被授 權去使用HTTP put命令用GLMS創建一個組(消息103)。在這種情 況下，GLMS接受命令和文件group.xml以創建被請求的組。GLMS以 所創建的HTTP消息201作為響應(消息104)。
下一對消息(105和106)示出用戶可以請求GLMS用不同名稱創 建另 一個組(即，消息105中的friend.xml)，並且當組friend.xml被成 功創建時GLMS響應(在消息106中創建的HTTP 201 )。在該例子中， 文件friend.xml與私有組(即，只有建立所述組的用戶才能看到的組) 有關。
步驟110和消息111 - 118示出在用戶隨後登錄時在用戶和GLMS 之間交換的步驟和消息。步驟110是註冊步驟，該註冊步驟發生在用戶 的蜂窩電話被打開之時。在圖2中更詳細地解釋了註冊步驟110。消息 111代表用於從GLMS獲得組數據的消息，所述組數據與先前根據文件 fhend.xml創建的私有組有關。 一旦組數據被成功傳送到行動裝置， GLMS就以消息112 (HTTP 200 OK)進行確認。消息113和114是用 於檢索與先前根據文件group.xml創建的公共組有關的組數據的類似消 息對。
在消息115中，用戶請求(通過消息SIP預訂(group.xml))他希 望預訂組成員數據的改變，並且這樣的請求由GLMS經由HTTP消息200 OK確認(消息116)。如果根據文件group.xml創建的公共組的成員資 格數據隨後有變化(例如成員之一改變了他的電子信箱地址)，則GLMS (經由消息117 SIP通知)通知該用戶。該通知消息由行動裝置在消息 118 (例如HTTP200 OK)中確認。
圖2是示出在用戶註冊期間在用戶的行動裝置和各種網絡部件之間 交換的消息的示例性流程圖。用戶的行動裝置發送請求註冊消息201 (SIP註冊(sip:[email protected]))以向網絡註冊用戶的行動裝置。在 這種情況下，該請求被詢問CSCF接收。眾所周知，CSCF可以具有多 個部分，包括詢問CSCF、代理CSCF和服務CSCF。
詢問CSCF然後使用由用戶的行動裝置提供的數據解析用戶的域。 利用其自身的代理，服務CSCF然後聯繫與所述用戶的域相關聯的歸屬 用戶伺服器(HSS )以(經由請求Diameter MAR或多媒體-鑑別-請求的 消息202 )請求鑑別令牌。HSS然後檢索鑑別向量(步驟250 )並且(經 由消息203， Diameter多媒體-鑑另'卜應答或MAA)將鑑別向量返回到服 務CSCF。
由於用戶的行動裝置還必須向網絡註冊，因此CSCF將經由消息204 向用戶的行動裝置通知(401未授權的RAND AUTN ):用戶當前未被 授權並且CSCF希望從用戶的行動裝置接收鑑別令牌以便將它們與從 HSS接收的鑑別向量進行比較。在消息205中，用戶的行動裝置以被請 求的鑑別令牌響應(SIP註冊RES )。
CSCF然後在步驟260中比較從HSS接收的鑑別令牌與從用戶的移 動設備接收的鑑別令牌以鑑別用戶的行動裝置。如果比較是成功的，那
麼CSCF在消息206中將Diameter SAR (伺服器分配請求)發送到HSS 以請求存儲服務CSCF的名稱。
HSS將服務CSCF存儲在用戶的簡檔中(方框270 )並且在消息207 中以更新的用戶簡檔響應。用戶簡檔包括關於用戶的帳戶的信息，例如 用戶的公共URI，預訂的服務，用戶的帳戶是否被禁止，和服務觸發器 信息(例如當SIP預訂消息的事件標題被設置為存在時的存在服務觸發 器)。在這時，註冊完成並且CSCF在消息208中向請求用戶的移動設 備確認註冊任務的完成(200 OK)。
如果用戶的簡檔包括對存在伺服器(PS)的預訂(在步驟280中查 明)，則CSCF然後在消息209中將SIP註冊消息轉發到存在伺服器 (PS ) 。 PS然後在流程210中以發送給CSCF的確認做出響應並且記錄 用戶的有效性。這允許存在伺服器將與用戶的行動裝置有關的存在數據 提供給其他用戶。
圖3示出當用戶預訂接收組存在數據時涉及的示例性消息。在這種 情況下，由於組[email protected]是公共組，因此預訂用戶可以是任何用 戶，而未必是創建所述組的用戶。方框330包括消息301 - 304,所述消 息被交換以使用戶能夠預訂組存在。在消息301中，用戶的行動裝置將 SIP預訂([email protected])發送到CSCF詢問部分，並且事件標題設置 為存在。所述請求指示用戶希望預訂接收由URI(統一資源標識符) [email protected]識別的組中的成員的存在信息。CSCF在消息302中將所 述請求轉發到存在伺服器(PS)。
由於在本例子中請求用戶是所述組的最初所有者，因此PS將允許 用戶預訂(消息303 ),這經由CSCF被發送到用戶(消息304)。
在這時，PS可以獲得組成員信息並且可以預訂接收組信息的變化 (方框320,包括消息310-321 )。首先，PS獲得成員資格列表。該成 員資格列表駐留於GLMS,在那裡用戶最初提交成員列表(如結合圖1 所述的那樣)。因而，PS將SIP預訂([email protected])發送到CSCF (消息310)，然後CSCF將所述請求轉發到GLMS(消息311 ) 。 GLMS 確認收到所述請求，所述請求經由GLMS被發送回PS (消息312和 313 )。隨後，GLMS經由CSCF將[email protected]的成員資格列表發送 到PS(使用SIP通知消息314和315，所述消息可以被多次發送以便傳 送所有成員的數據)。 一旦成員資格信息被接收，PS就以200 OK消息 確認，所述消息經由CSCF被轉發到GLMS (消息316和317)。
一旦PS具有了成員資格信息，它就能夠將與成員有關的存在數據 發送到預訂用戶的行動裝置。因而，PS將與[email protected]的成員有關 的存在數據發送到預訂用戶的行動裝置(經由SIP通知消息318和 319,所述消息可以被多次發送以覆蓋所有成員)。存在數據的接收是 由用戶的行動裝置經由200 OK消息320和321而確認的，所述消息經 由CSCF被發送到PS。消息318-321可以被重複，原因在於成員資格 信息可以變化一次以上直到預訂期滿或預訂被取消為止。
圖4A根據本發明的一個實施例示出在使用MSRP將視頻剪輯從用 戶的行動裝置發送到接收方的視頻接收裝備(它可以是另一行動裝置、 個人信息管理器、膝上型電腦或能夠接收視頻的任何計算設備)中涉及 的步驟。在步驟402中，用戶1 (例如希望發送視頻的一方)通過將邀 請消息從用戶1的行動裝置發送到用戶2的UE (用戶裝備)來邀請用 戶2 (例如接收視頻的一方)接收視頻剪輯。在步驟404中，建立MSRP 承載信道以便於在不必在網絡中的中間節點(例如多個CSCF跳、應用 伺服器等)中引起處理開銷的情況下將視頻數據從用戶1傳送到用戶 2。 一旦MSRP承載信道被建立，視頻數據就在該MSRP承載信道上被 直接從用戶1發送到用戶2 (步驟406)。 一旦視頻剪輯被完全傳送， MSRP承載信道就被關閉(步驟408)。
圖4B根據本發明的一個實施例示出了顯示當用戶1 (被示為圖4B 中的UE1或用戶裝備1 )希望使用MSRP承載信道將視頻剪輯傳送到用 戶2 (被示為圖4B中的UE2或用戶裝備2)時交換的消息的示例性流 程圖。在消息451中，用戶1的行動裝置使用MSRP承載數據信道將SIP 邀請([email protected] msrp)發送到CSCF以邀請用戶2接收視頻剪輯。 CSCF經由消息452 ( 100嘗試)確認接收到該請求，所述消息指示 CSCF處於在把該請求轉發到用戶2的過程中。
在將視頻剪輯轉發到用戶2的UE之前，CSCF檢查(方框480 )用 戶2的服務狀態以查明是否適合將視頻剪輯轉發到用戶2。例如，用戶2 對網絡服務可能欠費，並且他的帳戶可能已經被暫時禁止，從而導致用 戶2無資格使用網絡來接收視頻剪輯。作為另一個例子，用戶2有可能 在他的簡檔中表明用戶2並不希望從用戶l或從任何人接收任何視頻 剪輯。如果認為用戶2不能接收視頻剪輯，則可以通知用戶1並且終止會話。
在另一方面，如果用戶2有資格接收視頻剪輯，則CSCF將來自用 戶1的請求(SIP邀請([email protected] msrp ))轉發到用戶2的UE (消 息453 )。用戶2的UE通過將消息454 ( 100嘗試)發送到CSCF來確 認接收到該請求。
在這時，用戶2的UE將試圖建立(方框490 ) MSRP承載數據信 道以便於視頻傳送。使用常規的TCP和MSRP建立程序(箭頭A、箭頭 B和箭頭C) , MSRP承載數據信道被建立在用戶1的行動裝置和用戶2 的UE之間。
一旦MSRP數據信道被建立，用戶2就將200 OK消息發送到用戶 1,其中所述消息通過CSCF被中繼(消息457和458) 。 Ok消息的接 收由用戶1的行動裝置確認，所述消息經由CSCF被發送到用戶2的UE (ACK消息459和460 )。
在這時，MSRP承載數據信道被創建並且視頻傳送可以開始(箭頭 D和E)。在消息461中，使用MSRP將視頻數據從用戶1的行動裝置 發送到用戶2的UE (通過MSRP發送消息)。用戶2的UE使用消息 462進行確認(MSRPOK)。應該注意到，視頻數據的傳送是使用用戶 1的行動裝置和用戶2的UE之間的直接通道來實現的。為傳送所有視 頻數據，該傳送可能涉及MSRP發送和MSRPOK消息的多次循環。
一旦視頻剪輯傳送完成，用戶1的行動裝置通知用戶2的UE:它 正在終止連接。因而用戶1的行動裝置將SIP結束消息463發送到用戶 2的UE。用戶2的UE使用消息200 OK進行確認(在消息464中)。 在這時，視頻剪輯被傳送了並且MSRP承載數據信道被終止。
圖5 A根據本發明的 一個實施例示出使用應用伺服器實現一對多視 頻傳送的步驟。用戶1將SIP邀請消息發送到CSCF ( 502 )。如果SIP 邀請消息指示接收方是單個接收方(504),則CSCF將例如使用在圖 4A和4B中討論的MSRP承載數據信道技術或者如隨後在這裡將結合圖 6A和6B所描述的通過將視頻剪輯附加到SIP消息中來啟動l對l視頻 傳送過程(506 )。在另一方面，如果SIP邀請消息指示接收方是一個 組(504)，則CSCF將把SIP邀請消息路由到應用伺服器(AS)以使 AS能夠將視頻剪輯發送到組成員(508 )。
圖5B根據本發明的一個實施例更詳細地示出這樣的步驟 一旦AS 接收到從用戶1轉發的SIP邀請消息就使用應用伺服器實現一對多視頻
傳送。在利用AS進行一對多視頻傳送之前，視頻剪輯首先被裝載到AS 上(530 )。在這種情況下，用戶1 (發送視頻的一方)可以以圖4A和 4B中所描述的方式使用例如基於MSRP的方法來執行視頻剪輯到應用 伺服器(AS)的初始傳送，從而用AS代替用戶2。如果視頻剪輯相當 短，則初始傳送也可以使用SIP消息來執行，隨後在這裡將結合圖6A 和6B對此進行描述。
一旦到AS的初始一見頻傳送完成，AS可以開始執行一對多傳送。在 步驟532中，AS從GLMS獲得成員資格列表。在步驟534中，AS然後 用PS檢查組成員的存在狀態。對於存在的成員，AS使用例如MSRP承 載數據信道技術或者使用SIP消息技術(如果視頻剪輯相當短的話)將 視頻剪輯發送(536 )到接收方成員。
圖5C根據本發明的一個實施例示出了顯示當用戶1希望使用應用 伺服器將視頻剪輯(它例如可能是大視頻剪輯)傳送到指定組的多個成 員時交換的消息的示例性流程圖。用戶1將像圖4B中那樣把視頻剪輯 發送到應用伺服器，從而用AS代替UE2。在圖5C的例子中，視頻剪 輯通過MSRP承載數據信道被從AS發送到組成員。然而，也可以使用 其他視頻傳送技術來代替MSRP,不過效率的程度會有所不同。
經由消息501 (HTTP GET ( group.xml) ) , AS首先獲得由用戶1
在發送視頻的請求中指定的組的成員資格列表。在該例子中，組是 [email protected],它被保持在GLMS處的group.xml列表中。GLMS以消 息502響應，從而將組成員提供給AS。
在查明組成員的存在狀態過程中涉及到消息503 - 506。因而AS將 SIP預訂([email protected]期滿=0)發送(503 )到PS,以請求 [email protected]的成員的存在狀態。可選參數"期滿=0"將預訂消息的 定時器設置為零以表明AS僅僅對一次獲得的存在狀態感興趣而對被 告知存在狀態以後是否改變不感興趣。然而，也可以不設置定時器或者 將定時器設置為某些其他值以使AS能夠被告知存在狀態變化。例如， AS可能希望在以後的時間當成員的存在狀態從"不存在"變為"存在" 時發送視頻剪輯。在方框320中描述了 PS組列表說明。
PS以消息200 OK來確認預訂消息(504 ) 。 PS然後獲得組的成員 的存在數據並且將存在狀態發送到AS。對於用戶2，PS經由消息SIP通 知([email protected])發送(505 )存在狀態。用戶2的SIP通知消息的 接收用消息200 OK(消息506 )確認。對於該組的用戶3,用戶4..用戶 N，可以重複消息505和506。
在方框510中，AS使用MSRP承載數據信道將視頻剪輯的拷貝從 AS發送到存在的成員。在方框510中涉及的消息基本上與結合圖4A和 4B討論的消息相同，從而用AS代替圖4A和4B的用戶1。視頻剪輯被 逐一地從AS發送。然而，所述發送可以通過AS的多個通信埠^皮並 行地執行或者可以被順序地發送。通過使用AS來執行到多個接收方的 實際視頻傳送，對發送者的行動裝置的帶寬要求相對於現有技術被相當 大程度地減小。此外，該方法是高度可伸縮的，原因在於多個應用服務 器可以用於處理到大量的接收方的視頻傳送和/或處理涉及大視頻剪輯 的^L頻傳送。
圖6A根據本發明的一個實施例示出使用SIP消息將視頻剪輯發送 到一個組中的多個組成員的步驟。由於SIP消息常常用於發送IM(即時 消息)文本，因此該技術很適合發送短視頻剪輯。在步驟602中，用戶 發送包括視頻剪輯的SIP消息，指定組URI作為接收方。在步驟604中， SIP消息(包括視頻剪輯)被CSCF轉發到應用伺服器(AS) 。 CSCF 根據設置在用戶筒檔中的觸發器將SIP消息轉發到AS,例如組URI未 被識別而URI包含目的地為AS的域名(也稱為公共服務標識符或PSI 查找表)。
在步驟606中，AS從GLMS獲得成員信息。該成員信息使AS隨後 能夠將視頻剪輯的拷貝轉發到該組的成員。在步驟608中，AS獲得組 成員的存在狀態。在步驟610中，AS將包括視頻剪輯的SIP消息逐一地 (或並行地或串行地)發送到組成員。
圖6B根據本發明的一個實施例示出當用戶1希望使用應用伺服器 將視頻剪輯傳送到指定組的多個成員時交換的消息的示例性流程圖。在 圖6B的例子中，視頻剪輯經由SIP消息被從AS發送到組成員。經由消 息651，與用戶l(發送者)相關聯的行動裝置將SIP消息([email protected] +視頻剪輯)發送到CSCF。該SIP消息包括視頻剪輯並且指定 [email protected]作為接收方。CSCF並不識別組URI並且使用組URI的 域名而進行了 PSI查找表。在消息652中，CSCF將包括視頻剪輯的SIP 消息轉發到AS以使AS能夠將視頻剪輯的拷貝轉發到組成員。SIP消息 的接收由AS經由消息653 (200 OK)向CSCF確認。
經由消息654 (HTTP GET ( group.xml) ) ， AS首先獲得由用戶1 在發送視頻的SIP請求中指定的組的成員資格列表。在該例子中，組是 [email protected],它被保持在GLMS處的group.xml列表中。GLMS以消 息655響應，將組成員提供給AS。在該時間期間，CSCF經由消息656 (200 OK)向用戶1確認接收到SIP消息。
在查明組成員的存在狀態的過程中涉及消息657 - 660。因而，AS 將SIP預訂([email protected]期滿=0)發送(657 )到PS，以請求 [email protected]的成員的存在狀態。可選參數"期滿=0"將預訂消息的 定時器設置為零以表明AS僅僅對一次獲得的存在狀態感興趣而對被 告知存在狀態以後是否改變不感興趣。然而，也有可能不設置定時器或 者將定時器設置為某些其他值以使AS能夠被告知存在狀態變化。在方 框320中描述了組列表預訂。
PS以消息200 OK來確認預訂消息(658 ) 。 PS然後獲得組的成員 的存在數據並且將存在狀態發送到AS。對於用戶2,PS經由消息SIP通 知([email protected])發送(659 )存在狀態。用戶2的SIP通知消息的 接收用消息200 OK(消息660)確認。對於該組的用戶3，用戶4..用戶 N,可以重複消息659和660。
在方框670中，AS使用SIP消息將視頻剪輯從AS發送到存在的成 員。因而，經由消息661， AS將包括視頻剪輯的SIP消息與指定接收方 數據(SIP消息([email protected] +視頻剪輯))一起發送到CSCF, CSCF
有助於將視頻剪輯轉發到指定接收方。
在方框680中，CSCF執行對指定接收方(在該例子中的用戶2)的 服務控制。在執行服務控制過程中，CSCF檢查用戶2的服務狀態以查 明是否適合將視頻剪輯轉發到用戶2。例如，用戶2對網絡服務可能欠 費，並且他的帳戶可能已經被暫時禁止，從而導致用戶2無資格使用網 絡來接收視頻剪輯。作為另一個例子，用戶2可以在他的簡檔中表明 用戶2並不希望從用戶1或從任何人接收任何視頻剪輯。如果認為用戶 2不能接收視頻剪輯，則可以通知用戶1並且終止會話。
在另一方面，如果用戶2有資格接收視頻剪輯，則CSCF將來自用 戶1的請求(SIP消息([email protected] +視頻剪輯))轉發到用戶2 的UE (消息662)。用戶2的UE經由將消息663 (200 OK)發送到CSCF來確認接收到視頻剪輯。CSCF繼而經由消息664 ( 200 OK)通知 AS:視頻剪輯已經被轉發到用戶2。
圖7根據本發明的一個實施例示出了顯示當用戶1希望使用應用服 務器將視頻剪輯傳送到指定組的多個成員時交換的消息的示例性流程 圖。在圖7的例子中，使用實時傳輸協議(RTP)而不是MSRP (如圖 5C中所執行的那樣)來將視頻剪輯從AS發送到組成員。除了 AS和每 個接收方之間的視頻傳送採用RTP而不是MSRP之外，圖7的消息與 圖5的消息基本上相同。因而，AS使用RTP (圖7中的附圖標記A和 B)將視頻剪輯傳送到每個接收方的UE,而不是MSRP通信信道(圖 5C中的附圖標記D和E)。
儘管在此根據幾個實施例對本發明進行了描述，但是仍存在落入本 發明的範圍內的變化、排列和等效替換。如上所述，儘管為了便於理解 所述例子始終涉及視頻剪輯的發送，但是本發明的實施例也適用於其他 類型的多媒體數據。此外，還存在著許多實現本發明的裝置的替代性方 式。因此後附權利要求旨在被理解成包括落入本發明的真實精神和範圍 內的所有這樣的變化，排列和等效替換。
權利要求
1.一種用於將多媒體文件從一個用戶的行動裝置(UE1)傳送到與另一個用戶相關聯的用戶裝備(UE2)的方法，所述方法包括把邀請從所述用戶的行動裝置(UE1)發送(402)到所述用戶裝備(UE2)以請求所述多媒體文件的傳送；在所述用戶的行動裝置和所述裝備之間建立(404)承載數據信道以便於所述多媒體文件的所述傳送，所述傳送被配置成使用消息會話中繼協議(MSRP)來實現；和使用所述MSRP和所述承載數據信道來傳送(406)所述多媒體文件。
2. 根據權利要求1所述的方法，其中所述多媒體文件是視頻文件 (402)。
3. 根據權利要求1所述的方法，其中使用SIP (會話啟動協議)來 執行所述邀請(451/453 )。
4. 根據權利要求1所述的方法，其中所述發送所述邀請包括通過 呼叫會話控制功能(CSCF)設施來發送所述邀請。
5. 根據權利要求1所述的方法，其中所述建立包括使用HTTP (超 文本傳輸協議)命令來進行建立。
6. 根據權利要求1所述的方法，其中所述用戶的行動裝置是蜂窩 電話。
7. 根據權利要求1所述的方法，其中所述用戶的行動裝置是便攜 式計算設備。
8. 根據權利要求1所述的方法，其中所述用戶的行動裝置是個人 信息管理器(PIM)設備。
全文摘要
本發明公開了一種用於將多媒體文件從一個用戶的行動裝置(UE1)傳送到與另一個用戶相關聯的用戶裝備(UET)的方法。所述方法包括把邀請從所述用戶的行動裝置發送(402)到所述用戶裝備以請求多媒體文件的傳送。所述方法還包括在所述用戶的行動裝置和所述裝備之間建立(404)承載數據信道以便於多媒體文件的傳送，所述傳送被配置成使用消息會話中繼協議(MSRP)或實時傳輸協議(RTP)來實現。所述方法進一步包括使用MSRP或RTP和承載數據信道來傳送(406)多媒體文件。
文檔編號H04L29/06GK101199185SQ200680021439
公開日2008年6月11日 申請日期2006年4月3日 優先權日2005年4月14日
發明者J·亨裡克森, S·林 申請人:惠普開發有限公司