專利名稱：媒體頻道管理的制作方法
技術(shù)領(lǐng)域：
本發(fā)明 一般涉及通信系統(tǒng)中媒體會話的管理，并且特別涉及在這
樣的媒體會話中減少切換媒體頻道(media channel)的用戶察覺時間。
背景技術(shù)：
在現(xiàn)有移動網(wǎng)絡(luò)和移動通信系統(tǒng)中提供和供應(yīng)大范圍的新業(yè)務(wù) 已成為趨勢。目前對于使用移動網(wǎng)絡(luò)用于多媒體或者電視內(nèi)容存在很 大的興趣。在本技術(shù)領(lǐng)域這經(jīng)常被稱為移動電視。移動電視應(yīng)用的目 的是提供類似電視的體驗，用戶可以選擇并且輕易地在不同的多媒體 或者電視頻道之間快速移動。
普通的電視頻道被廣播給以許多用戶，并且典型地用戶可以選擇 接收和觀看哪個頻道。類似地移動電視向若干終端用戶發(fā)送一組(實 況的)媒體或者多媒體流。每個多媒體流對應(yīng)一個電視頻道，并且每 個用戶將能夠選擇觀看哪個頻道。此刻，用于移動電視的廣播/組播 傳送方法處于開發(fā)中。這樣的標(biāo)準(zhǔn)化努力的例子是3GPP多媒體廣播/ 組播服務(wù)(MBMS)以及歐洲電信標(biāo)準(zhǔn)協(xié)會(ETSI)手持式數(shù)字視頻 廣播(DVB-H)。這些標(biāo)準(zhǔn)在其廣播分配方式方面類似于傳統(tǒng)TV。
同時，直到基于組播/廣播的移動電視可用，存在對可以在現(xiàn)有 移動傳輸頻道上實現(xiàn)的解決方案的需求。稍后對于單播傳輸是優(yōu)選分 配方法的具有足夠容量的網(wǎng)絡(luò)和具有少數(shù)用戶的蜂窩也將具有很大 的興趣。
在基于網(wǎng)絡(luò)的網(wǎng)際協(xié)議(IP)上使用流的類似移動電視的服務(wù)可 以在現(xiàn)有移動網(wǎng)絡(luò)中實現(xiàn)。例子是在3GPP中開發(fā)的包交換(PS)流々某 體服務(wù)(Packet-Switched Streaming Service: PSS )。為了開始這樣的多媒體或者電視會話，用戶 一般沖浪到網(wǎng)頁或者入口并且點擊或者 選擇鏈接來觀看流媒體直播頻道。
還存在幾個可用于移動電視的專有流媒體解決方案，例如
RealNetworks (真實網(wǎng)絡(luò))、Apple的Quicktime (迅時)和Microsoft 的mediaplayer (媒體播放器)。這些解決方案還一般具有點擊鏈接以 開始接收某個頻道的入口或者網(wǎng)頁。
移動電視服務(wù)的目標(biāo)之一是能夠在頻道之間快速移動，如同某人 可對通用的廣播電視頻道所做那樣。如果將全部頻道廣播，接收機(jī)可 以通過選擇適當(dāng)?shù)膫鬏旑l道以及使用適當(dāng)?shù)亩嗦份敵鲞x擇器在本地 在頻道之間選擇。這是對于有線、衛(wèi)星或者地面電視和即將出現(xiàn)的移 動標(biāo)準(zhǔn)MBMS和DVB-H的情況。然而，對于單4番會話，客戶端必須改 為影響"服務(wù)器"或者多媒體提供者以發(fā)送想要的頻道。
執(zhí)行基于IP的移動流媒體的傳統(tǒng)方法是在瀏覽器中選擇特定的內(nèi) 容。這開始會話描述協(xié)議(Session Description Protocol: SDP)或者同 步多々某體集成語言(Synchronize Multimedia Integration Language: SMIL)文件的下載，其又在用戶終端的媒體播放器中發(fā)起實時流媒體 協(xié)議(Real Time Streaming Protocol: RTSP )流々某體會話。直到用戶 在用戶終端的屏幕上看到內(nèi)容所需要花費(fèi)的大約時間一般是大約或 者稍微超過10秒，其中大概5秒用于請求建立而其余用于信令(大約2 秒)和緩沖(大約3到4秒)。如果用戶想要切換到另一""多媒體或者 電視頻道"，他必須終止當(dāng)前數(shù)據(jù)流并且返回到他通過點擊鏈接來選擇 另一頻道的瀏覽器。那么，開始新的RTSP會話，媒體播放器啟動并且 開始緩沖，并且存在新的大約10秒的延遲。
在超出用于選擇單播頻道的瀏覽器鏈接時，最簡單的途徑是每當(dāng) 某人切換頻道就發(fā)出向新的URI (Univeral Resource Identifiers:通用 資源標(biāo)志符)建立新流媒體會話的請求。這是相當(dāng)普遍的，但是相當(dāng) 慢，因為必須進(jìn)行全新的RTSP信令處理以及內(nèi)容的緩沖。
為了補(bǔ)救這個緩慢的過程，已經(jīng)開發(fā)了更快的解決方案[l]，其中每個用戶具有連續(xù)的流媒體會話并且可以通過在HTTP (Hypertext Transfer Protocol:超文本傳輸協(xié)議)或其它協(xié)議上的單獨信令來啟動 頻道切換。

發(fā)明內(nèi)容
道以使能夠?qū)γ總€媒體流進(jìn)行一個連續(xù)RTP (實時傳輸協(xié)議)會話。 本發(fā)明克服了先有配置的技術(shù)的這些和其它的缺點。 本發(fā)明的一般目的是提供有效的媒體會話管理。
如隨附專利權(quán)利要求書所定義的本發(fā)明滿足這些以及其他目的。 簡言之，本發(fā)明包括基于單播的媒體會話管理，該媒體會話管理 包括用戶終端和具有多個基于單播的媒體頻道的訪問的媒體服務(wù)器。 通過從用戶終端到媒體服務(wù)器的通用頻道透明會話請求的傳輸發(fā)起 通用頻道透明會話建立過程。該建立過程包括在用戶終端和服務(wù)器之 間以頻道透明請求和響應(yīng)的形式的信息交換。然而，在此建立過程期 間不選擇々某體頻道。這意味著媒體服務(wù)器仍然不知道終端想收聽什么 頻道以及服務(wù)器應(yīng)該發(fā)送什么媒體內(nèi)容給用戶終端。
首先，在完成建立過程時，終端以對此頻道的頻道具體呈現(xiàn)請求 形式通知媒體服務(wù)器所請求的媒體頻道。然后，服務(wù)器可使用在先前 頻道透明建立過程期間協(xié)商的機(jī)制和端口開始傳遞該頻道的媒體內(nèi) 容。
如果用戶隨后希望切換到服務(wù)器的新的基于單播的頻道，則終端 在正在進(jìn)行會話期間僅向服務(wù)器傳輸僅對新頻道的新頻道具體呈現(xiàn) 請求。這意味著該頻道切換發(fā)生在會話內(nèi)部，不需要首先結(jié)束當(dāng)前會 話然后建立新會話的任何要求。因此，對新頻道要再使用該傳送機(jī)制 和端口。這將顯著地減少頻道切換時間，因為在服務(wù)器和終端需要的往返和數(shù)據(jù)處理更少。
本發(fā)明還允許在單播和廣播傳遞之間的無縫或者接近無縫的切 換。用戶終端僅向媒體服務(wù)器傳輸呈現(xiàn)引起當(dāng)前基于單播的頻道的媒 體內(nèi)容的傳送的暫時停止的暫停請求。終端現(xiàn)在可以收聽廣播頻道。 如果用戶重新希望收聽先前的基于單播的頻道或者其它基于單播的 頻道，那么終端發(fā)送對該頻道的新頻道具體呈現(xiàn)請求。因此，不需要 任何新的會話建立過程就恢復(fù)媒體頻道。


通過參考以下結(jié)合附圖所作的說明可以更好地理解本發(fā)明及其
更多的目標(biāo)和優(yōu)勢，其中
圖1A和1B是根據(jù)先有技術(shù)圖解頻道建立過程與頻道切換過程的
信令框圖。
圖2是根據(jù)本發(fā)明圖解管理基于單播的媒體會話的方法的流程
圖3是根據(jù)本發(fā)明的實施例圖解頻道透明會話建立過程的信號框
圖4是根據(jù)本發(fā)明的另 一 實施例圖解頻道透明會話建立的信號框
圖5是根據(jù)本發(fā)明的再一實施例圖解頻道透明會話建立過程的信 號框圖6是根據(jù)本發(fā)明的實施例圖解頻道請求過程的信號框圖； 圖7是圖解本發(fā)明的用于暫停以及用于終止基于單播的媒體會話 過程的信號框圖8是可應(yīng)用本發(fā)明的教導(dǎo)的通信系統(tǒng)的部分的示意概圖； 圖9是根據(jù)本發(fā)明的用戶終端示意框圖10是根據(jù)可在圖9的用戶終端中實現(xiàn)的本發(fā)明的會話建立管理 器的示意框圖；圖ll是根據(jù)本發(fā)明媒體服務(wù)器的示意框圖；以及 圖12是根據(jù)可在圖11的媒體服務(wù)器中實現(xiàn)的本發(fā)明的會話建立 管理器的示意框圖。
具體實施例方式
在附圖中，對于相應(yīng)或者相似單元將使用相同的參考標(biāo)號。
本發(fā)明涉及媒體會話管理，特別涉及管理基于單播的媒體會話。 與先有技術(shù)的方法相比，本發(fā)明的會話管理減少了切換基于單播的媒 體頻道或者在單播和組播/廣播頻道之間切換所需要的往返的數(shù)目。
由于往返數(shù)量的減少，切換媒體頻道的用戶察覺時間減短，接近 "真正的"快速移動水平。因此，本發(fā)明在基于單播的通信系統(tǒng)中提供 與當(dāng)前的通用電視系統(tǒng)和即將來臨的基于組播/廣播的移動電視相似 的類似電視的體驗。本發(fā)明的教導(dǎo)可用于任何此類單播系統(tǒng)、尤其使 用因特網(wǎng)協(xié)議(IP)的無線通信系統(tǒng)，以供數(shù)據(jù)通信。這樣的通信系 統(tǒng)的典型示例是通過PS流(PPS)向已連接用戶提供多媒體數(shù)據(jù)的包 交換(PS)系統(tǒng)。更多的PPS的信息可以參考文檔[2]。
根據(jù)本發(fā)明，媒體頻道可以例如攜帶"實況"媒體或者包括由一個 或多個剪輯組成的預(yù)先錄制的內(nèi)容。
從用戶角度而言，本發(fā)明的頻道切換將被更加平穩(wěn)地體驗，將在 更短的時段執(zhí)行，并且不需要像先有技術(shù)的單播解決方案所需要的那 樣訪問多媒體提供者的網(wǎng)頁也不需要建立新的媒體會話。
根據(jù)本發(fā)明，媒體或者多媒體數(shù)據(jù)包括可以在用戶終端呈現(xiàn)和顯 示的任何形式和類型的媒體。這包括但不限于圖像、視頻、音頻以及 其他在呈現(xiàn)期間能夠由用戶察覺的々某體類型。
為了簡化對本發(fā)明及其優(yōu)點的理解，首先結(jié)合圖1A和1B簡單回顧 建立基于單播的蝶體會話以及切換々某體頻道的先有技術(shù)方法。這些圖 示出了在建立期間執(zhí)行的信令以及實時流媒體協(xié)議(RTSP )會話的管 理。如本領(lǐng)域中所公知的，RTSP是用于對具有實時性的媒體數(shù)據(jù)傳送的控制的應(yīng)用級協(xié)議?，F(xiàn)在，可用包括RTSP 1.0和RTSP2.0的不同版 本的RTSP。本發(fā)明可結(jié)合這兩種版本和其它任何RTSP版本使用。
可用在用戶終端的DESCRIBE (描述)請求的編輯和發(fā)送初始化 RTSP會話。響應(yīng)DESCRIBE請求，媒體服務(wù)器編譯并且返回包括請求 的媒體內(nèi)容說明的響應(yīng)(200 OK消息)。響應(yīng)一般包括在媒體服務(wù) 器的媒體描述的通用資源定位(URL)。此響應(yīng)包含用于請求的媒體 內(nèi)容的全部媒體初始化信息。在典型實施例中，描述具有會話描述協(xié) 議(SDP)文件的形式。其中，除描述信息的通用資源標(biāo)志符(URI) 之外，此SDP文件包含經(jīng)所選媒體的名稱、傳輸?shù)刂芬约翱捎糜诿襟w 的編解碼器(codec)。
具有SDP文件的DESCRIBE響應(yīng)的典型示例可如同
RTSP/1.0 200 OK
CSeq:"會話唯一序列號"
Date:"創(chuàng)建日期和時間"
Content-Type:"包含于響應(yīng)中的文件的內(nèi)容類型" Content-Length:"文件長度"
上述四行構(gòu)成RTSP響應(yīng)的頭標(biāo)。下面的行舉例說明SDP文件內(nèi)容 的例子
v=0 "SDP文件的開始"
0="創(chuàng)建者"
8="會話名稱" 1="會話信息"
uJ'描述的URT e-"電子郵件地址"
c一'連接信息" t^'會話活動計時"
a= control:* "會話層上使用的控制行，^旨定控制URI與用于 DESCRIBE的相同"a=control:audiotrack "用于具有相關(guān)URI的音頻媒體的控制行" m= audio 3456 RTP/ AVP 0
a=control:videotrack "用于具有相關(guān)URI的視頻媒體的控制行" m= video 2232 RTP/AVP 31
在用戶終端(UE)與媒體服務(wù)器(MS)之間的通信的典型實例 可以因此是
UE — MS response:
DESCRIBE rtsp:〃mediaserver.com/movie.test RTSP/1.0 CSeq:l
MS->UE response: RTSP/1.0 200 OK CSeq: 1
Date: 28 Feb 2006 15:35:06 GMT Content-Type: application /sdp Content-Length: 435 v=0
o=- 950814089 950814089 IN IP4 144.132.134.67
s=Example of aggregate control of ARM speech and H.263 video
e=foo@bar.com
c=IN IP4 192.168.30.29
b=AS:77
t=0 0
a=range:npt=0-59.3478
a=control:*
b=AS: 13
a=fmtp:97 mode-set=0,2,5，7; maxptime=200 a=control: streamID=0 m=video 0 RTP/ AVP 98 b=AS:64f
a=rtpmap:98 H263-200/90000 a=fintp:98 profile=3; level=10a=control: streamID=l SDP文件的更多信息可參考文檔[3]。
此后，用戶終端編譯并且傳輸對需要的々某體內(nèi)容的通用資源標(biāo)志 符(URI)的SETUP (建立)請求。典型的媒體會話包括通過基于單 播的i某體頻道傳輸?shù)囊曨l和音頻內(nèi)容。在此情況下，對于兩種內(nèi)容類 型逐步執(zhí)行SETUP過程。例如，可以首先傳輸包含視頻內(nèi)容的URI的 視頻SETUP請求。對于媒體數(shù)據(jù)傳輸，該請求還包含用戶終端可接受 的傳輸參數(shù)的指示。這些參數(shù)尤其包括用于視頻內(nèi)容的客戶端輸入端 口。響應(yīng)SETUP請求，媒體服務(wù)器產(chǎn)生此后作為當(dāng)前媒體會話標(biāo)識符 使用的會話標(biāo)識符。把此會話標(biāo)識符與由服務(wù)器和視頻輸出端口選擇 的傳輸參數(shù)一起返回。
把相應(yīng)的音頻SETUP請求和響應(yīng)在用戶終端與媒體服務(wù)器之間 通信，用于協(xié)商音頻傳輸參數(shù)。與視頻SETUP消息形成明顯對比，音 頻SETUP請求包含所通知的會話標(biāo)識符。
現(xiàn)在成功地建立RTSP會話，并且可以開始實際的媒體內(nèi)容傳送。 用戶終端因此編譯PLAY (播放)請求，該請求告訴服務(wù)器啟動經(jīng)在 會話建立期間協(xié)商的傳送機(jī)制發(fā)送通知的媒體內(nèi)容。PLAY請求可以 指定正常播放時間應(yīng)該開始的范圍，或者指定回放或媒體呈現(xiàn)應(yīng)該開 始的時間參數(shù)。i某體服務(wù)器處理此PLAY請求并且以確認(rèn)的時間參數(shù) 或者范圍以及同步信息響應(yīng)，比如依據(jù)在此響應(yīng)的RTP信息域中的 RTP時間。
然后，能夠使用確定的傳送機(jī)制在基于單播的i某體頻道傳遞所請 求的媒體。
如果用戶隨后想要切換到第二基于單播的頻道，必須首先結(jié)束當(dāng) 前RTSP會話。這可以通過傳輸PAUSE (暫停)請求實現(xiàn)，該請求包 含到媒體服務(wù)器的會話標(biāo)識符和媒體URI。這引起傳遞的媒體流的暫 時中斷。但是，此時沒有分配給此流的資源被釋放。用戶終端繼續(xù)， 傳輸TEARDOWN (拆卸)請求以停止對給定URI的流傳遞，釋放與其關(guān)聯(lián)的資源。這就結(jié)束了當(dāng)前媒體會話。更多RTSP的信息可參考文檔 [4]。
然后，迫使用戶終端建立新的、但用于新的媒體頻道的RTSP會話， 如圖1B所示。這樣，再一次進(jìn)行與如前所述的相同過程，但使用新的 媒體內(nèi)容的URI并使用新的會話標(biāo)識符。因此，在能呈現(xiàn)新^ 某體頻道 的媒體內(nèi)容之前，頻道切換包括進(jìn)行6次往返的大范圍信令以及媒體 服務(wù)器和用戶終端的某些處理延遲。
本發(fā)明經(jīng)頻道特定呈現(xiàn)請求(RTSPPLAY請求)以及通用頻道透 明會話建立過程，通過選#^某體頻道減少此與頻道切換有關(guān)的大范圍 信令。
圖2是管理基于單播的媒體會話的方法流程圖，所述媒體會話包 括用戶終端(客戶端)以及提供多個、即至少兩個不同的媒體頻道的 媒體服務(wù)器。從步驟S1開始，在這里用戶終端產(chǎn)生并且向媒體服務(wù)器 傳輸通用頻道透明會話請求。因此，此會話請求不選擇具體媒體內(nèi)容 或者媒體頻道。這樣，此時仍然沒有通知媒體服務(wù)器用戶終端請求哪
個媒體內(nèi)容。根據(jù)頻道透明會話請求的接收，媒體服務(wù)器以及用戶終 端在下一步驟S2執(zhí)行通用頻道透明媒體會話建立過程。此建立過程基 于先前產(chǎn)生和傳輸?shù)臅捳埱髮嵤＿@樣，步驟S2主要包括在用戶終 端與服務(wù)器之間建立RTSP會話。但是，與先有技術(shù)成明顯對比，此會 話建立過程不包括隨后向用戶終端傳遞媒體內(nèi)容的任何規(guī)范。這樣， 在用戶終端與媒體服務(wù)器之間交換信息、比如傳輸參數(shù)協(xié)商以及會話 標(biāo)識符通告。然而，執(zhí)行此信息交換，沒有要用于々某體會話的任何明 確或者隱含的媒體頻道的選擇。這意味著推遲實際的々某體內(nèi)容/頻道選 擇直到已完成會話建立過程。
一旦已成功建立通用頻道透明媒體會話，首先產(chǎn)生需要的々某體頻 道和內(nèi)容的通告。此時，在步驟S3，用戶終端產(chǎn)生并且向媒體服務(wù)器 傳輸用于所需頻道的頻道具體呈現(xiàn)請求。首先，現(xiàn)在服務(wù)器知道用戶 終端請求哪個特定媒體內(nèi)容，因此開始使用經(jīng)協(xié)商的傳送機(jī)制傳遞所請求頻道的媒體數(shù)據(jù)。在步驟S4中，當(dāng)終端接收媒體數(shù)據(jù)時，它的媒
體播放器開始為其使用者在終端上呈現(xiàn)或者回放該內(nèi)容。該數(shù)據(jù)呈現(xiàn) 一般包括在用戶終端的顯示屏上或者在連接到用戶終端的顯示屏上 顯示視頻內(nèi)容，并且在終端的揚(yáng)聲器上或者連接到終端的揚(yáng)聲器上播 放音頻內(nèi)容。
然后本方法結(jié)束。下面，將結(jié)合圖3到圖5的信號框圖更詳細(xì)地說 明描述通用頻道透明會話建立過程的不同情形。在這些框圖中，媒體 會話作為RTSP會話執(zhí)行并且因此在這些圖中使用了這種RTSP請求和 響應(yīng)的術(shù)語。本發(fā)明的教導(dǎo)仍然可適用于其它用于建立和管理基于單 播的媒體會話的協(xié)議。
圖3是根據(jù)本發(fā)明的實施例圖解執(zhí)行通用頻道透明媒體會話建立 過程的信號框圖。通過向々某體服務(wù)器的通用頻道透明會話請求消息的 傳輸發(fā)起該建立。此請求消息可以是DESCRIBE請求(如果使用的話) 或者SETUP請求。在此圖以及其后的圖中，已經(jīng)使用了DESCRIBE請 求和響應(yīng)，但是也可以把本發(fā)明用于沒有這些請求和響應(yīng)的過程。
DESCRIBE請求并不像本領(lǐng)域那樣指定實際的頻道(在圖1A中的 RTSP:〃tv.com//channell.sdp , 以及在圖 IB 中的 rtsp:/ /tv.com/channel2.sdp)。成明顯對比的是，該請求在它通過來自媒體 服務(wù)器的基于單播的傳遞請求多個、優(yōu)選為全部的可用媒體內(nèi)容的描 述方面是通用的。
媒體服務(wù)器基于接收的DESCRIBE請求產(chǎn)生描述消息或者取預(yù)先 產(chǎn)生的這種消息。此DESCRIBE響應(yīng)優(yōu)選地具有SDP文件的形式或者 某種別的消息格式。此SDP文件包含可用媒體頻道對其媒體內(nèi)容的宣 告。符合先前列出的先有技術(shù)SDP文件的示例，在DESCRIBE響應(yīng)中 返回的SDP文件可以具有下述形式
RTSP/2.0 200 OK
CSeq: 1
Date:"創(chuàng)建日期與時間" Content-Type: allchannels/sdp
19Content-Length:"文件長度" v=0
0="創(chuàng)建者"
i^'會話信息"
u-"描述的URT
t^'會話活動計時"
a=control:tv.com/allchannels.sdp/channell a=control:tv.com/allchannels.sdp / channel2
a=control :tv. com/allchannels.sdp/channelN
這意味著以多個會話控制行補(bǔ)充該SDP描述，其中每個這樣的行 宣布可用媒體頻道之一。在備選方法中，將新屬性"altcontrol"(備選控 制)引入SDP文件中。這意味著保留控制屬性用于向后兼容。
那么，在SDP文件中的對應(yīng)媒體行可以看起來像
a=altcontrol: list channel 1
a=altcontrol: list channel2
a= altcontrol: list channelN
在這兩個實施例中，媒體頻道宣告可以具有所謂的匯聚控制 (aggregated control: AC) URI的形式。這樣的AC URI涉及要在用戶 終端一起呈現(xiàn)的視頻內(nèi)容和相關(guān)聯(lián)的音頻內(nèi)容。在備選方法中，對于 包含視頻和音頻的媒體內(nèi)容，可在control (控制)或者altcontrol (備 選控制)行中使用單獨的URI，以用于每個可用媒體頻道的兩種媒體 類型。
在向后兼容的情況下，除altcontrol屬性以外，還可以用控制屬性 行補(bǔ)充SDP文件，即
a=control: defaultchannel a=altcontrol: list channel 1 a=altcontrol: list channel 2a=altcontrol: list channel
那么，默認(rèn)頻道可以是由媒體服務(wù)器選擇的預(yù)先定義的默認(rèn)頻 道，并且對于那些不支持altcontrol屬性的用戶終端作為初始媒體頻道 使用。在這樣的情況下，這些用戶終端可以用默認(rèn)頻道根據(jù)先有技術(shù) 繼續(xù)會話建立過程。
為了引起信令回退(fallback),會話請求可以包括支持請求，無 論々某體服務(wù)器是否支持通用頻道透明建立過程。這可以通過在由用戶 終端傳輸?shù)牡谝粋€DESCRIBE請求中使用具有要求頭標(biāo)(header)的 特征標(biāo)記實現(xiàn)。因此，此頭標(biāo)能夠包括新屬性multiple-control-uris (多 控制URI):
DESCRIBE rtsp:〃tv.com/allchannels,sdp RTSP/2.0 Require: multiple-control-uris
如果服務(wù)器不支持通用建立過程，那么它可以錯誤信息、比如不 ;故支持的551 Option (選項)響應(yīng)。
一旦用戶終端接收到具有優(yōu)選AC URI的描述消息，它就產(chǎn)生通用 頻道透明傳輸或者建立請求消息。與結(jié)合圖1A的論述一致，如果i某體 頻道包含^L頻和音頻內(nèi)容，那么優(yōu)選地，對于如圖3所示的兩個內(nèi)容 類型，編譯并且發(fā)送通用頻道透明建立請求。第一此類的通用頻道透 明請求可以用于視頻(音頻)內(nèi)容，而第二個請求則專用于音頻(視 頻)內(nèi)容。優(yōu)選地，這些請求指定用戶終端可接受的傳輸參數(shù)，以供 隨后的々某體傳輸。例如，它們包括用戶終端輸入^f見頻和音頻端口的通 告以及其它用于建立媒體會話所需要的傳輸參數(shù)。
此通用建立請求消息一般根據(jù)在媒體服務(wù)器的接收觸發(fā)傳送機(jī) 制的協(xié)商(提供-應(yīng)答過程)以及會話標(biāo)識符的產(chǎn)生。這樣，媒體服務(wù) 器包括分別由服務(wù)器、產(chǎn)生的會話標(biāo)識符以及輸出視頻和音頻端口所 選擇的、要在響應(yīng)中用于隨后的媒體傳遞的傳輸參數(shù)的信息。
因此，如果第一SETUP請求和響應(yīng)涉及視頻內(nèi)容，則對于音頻內(nèi) 容優(yōu)選重復(fù)此過程。如上所述， 一旦會話標(biāo)識符已經(jīng)產(chǎn)生并且通知了 用戶終端，就把它優(yōu)選地包括在隨后的用戶終端和媒體服務(wù)器間的通信中。
現(xiàn)在建立了本發(fā)明的通用頻道透明媒體會話。這意味著已經(jīng)選擇 并通報了所需的輸入和輸出端口 ，已經(jīng)協(xié)商了傳輸參數(shù)且已經(jīng)產(chǎn)生會 話標(biāo)識符。盡管已經(jīng)沒有要在會話中使用的特定媒體頻道的任何規(guī)定 或選擇地進(jìn)行了所有這些過程。
在上文結(jié)合與圖3所述的實施例中，在描述消息(DESCRIBE響應(yīng) 的SDP文件)中向用戶終端通報不同的可用媒體頻道的AC URI。然而， 可能，這些URI、即媒體頻道標(biāo)識符在創(chuàng)建SDP文件時并不巳知。此 外，媒體頻道的有效性可信賴于該日的時間或者可以不同于不同的 天。因此，固定的預(yù)先定義的SDP文件的使用將太不靈活而不能應(yīng)對 此情形。那么，可能的解決方案可以是在媒體服務(wù)器接收DESCRIBE 響應(yīng)的每個時間產(chǎn)生新的SDP文件。然而，這增加媒體服務(wù)器的數(shù)據(jù) 處理要求并且在媒體會話建立過程中引入更多延遲。
備選方法改為在SDP文件中使用通用模板(template)，然后在建 立過程中的稍后位置告知用戶終端相應(yīng)^ 某體頻道URI。在圖4和圖5中 已采用了此方法。
圖4是根據(jù)本發(fā)明的另 一實施例圖解執(zhí)行通用頻道透明i某體會話 建立過程的信號框圖。通過向媒體服務(wù)器的通用頻道透明會話 (DESCRIBE)請求消息的傳輸發(fā)起該建立。根據(jù)此消息的接收，媒 體服務(wù)器提供SDP文件或者其它包含可用媒體頻道的通用宣告的描述 消息。此宣告可結(jié)合以下控制屬性使用
a=control:tv.com/allchannels/*
或者新的altcontrol屬性
a=altcontrol: dynamic
這就發(fā)信號通知備選AC URI的目錄在特定動作是動態(tài)的或者未 知的，且這要由其它方法提供。在增添的巴科斯范式(Bachus-Naur form: ABNF)語法中(參見文檔[5]) ， SDP文件的會話部分可以寫作
altcontrol-line = "a-altcontrol:" control-type [sp rtsp誦URI]
control-type = "list" / "dynamic" /tokenrtsp-URI = "specified as in RTSP 2.0"
還可以在SDP文件中提供各個控制行的實際含義，但可在描述單 播頻道或者單播和廣播頻道的完整頻道表中更好地定義。
剩余的SETUP請求和響應(yīng)信令按在上文結(jié)合圖3所述的方式相同 的通用頻道透明方式執(zhí)行。
然后，用戶終端將編譯并且發(fā)送用于在SDP文件中被動態(tài)/一般宣 布的AC URI的請求?？砂汛苏埱蟀l(fā)給媒體服務(wù)器或者在通信系統(tǒng)中的 其它服務(wù)器或節(jié)點，所述通信系統(tǒng)具有對在媒體服務(wù)器的當(dāng)前可用單 播J 某體頻道的信息的訪問及其各自的URI。例如，此請求可能具有規(guī) 則HTTP請求或者對完整頻道表的請求的形式。媒體服務(wù)器或者其它 服務(wù)器/節(jié)點通過返回在媒體服務(wù)器的當(dāng)前可用的基于單播的媒體頻 道的URI的信息來響應(yīng)此請求。
在另一方法中，通過從媒體服務(wù)器或者其它服務(wù)器或者節(jié)點的廣 播或者多播傳輸執(zhí)行UW通告。在圖5中示意地圖解此情形。在此信號 圖中，單獨的服務(wù)器控制器以廣播/多播用戶服務(wù)描述(user service description: USD)的形式執(zhí)行ACURI通告。
媒體服務(wù)器已經(jīng)預(yù)先通知服務(wù)器控制器它的不同的基于單播的 頻道及頻道的有效性和URI。
如前所述，本發(fā)明的通用頻道透明媒體會話建立過程的執(zhí)行不一 定必須通過DESCRIBE請求的傳輸發(fā)起。這在當(dāng)前圖中進(jìn)一步圖解， 如可省略的虛線框所示。因此，可以通過從用戶終端的通用頻道透明 SETUP請求消息的傳輸直接發(fā)起建立過程。其后的直到最后的SETUP 響應(yīng)的信令類似于先前結(jié)合圖3所述。
此時，通過來自服務(wù)器控制器的USD廣播或者多播，將在媒體服 務(wù)器當(dāng)前可用的士某體頻道的AC URI通知用戶終端。不一定必須在頻道 透明建立過程的完成以后發(fā)送USD消息。這意味著用戶終端可改為在 發(fā)起建立過程(不久)以前或者建立過程期間的某個時間已經(jīng)接收 USD。在這種情況下，可把服務(wù)器控制器配置成在適合的時間間隔周期地廣播或者多播USD。
本發(fā)明預(yù)期，在圖3到圖5中任意所公開的信令的組合可以使用且 處于本發(fā)明的范圍內(nèi)。例如，能夠把URI通告組合到具有URI廣播的 SDP文件，在該情況下可用々某體頻道的更新是突出的。
媒體會話現(xiàn)在已經(jīng)以通用頻道透明方式建立，而沒有任何在會話 期間用戶終端實際上應(yīng)該收聽的媒體頻道的選擇。本發(fā)明的媒體頻道 及其因而媒體內(nèi)容選擇首先在呈現(xiàn)請求、例如RTSP PLAY請求的編譯 和發(fā)送發(fā)生，如圖6所示。此PLAY請求包含所選士某體頻道的標(biāo)識符。 優(yōu)選地，基于與所選媒體頻道相關(guān)聯(lián)且先前在用戶終端所接收的通用 資源標(biāo)志符(URI)產(chǎn)生該請求。優(yōu)選地，呈現(xiàn)請求包含所選媒體頻 道的AC而。
媒體服務(wù)器處理PLAY請求并且以確認(rèn)的時間參數(shù)或者范圍以及 同步信息響應(yīng)，比如依據(jù)此響應(yīng)的RTP信息域中的RTP時間。
然后，使用傳送機(jī)制、在通用頻道透明建立過程確定的到媒體內(nèi) 容的輸入和輸出端口傳輸所請求的頻道的媒體內(nèi)容。
如果用戶終端隨后想切換到任何由媒體服務(wù)器所提供且先前已 向與建立有關(guān)的終端通報的其它基于單播的媒體頻道的任何頻道，那 么對于新的媒體頻道，終端僅僅編譯并且傳輸新的呈現(xiàn)請求、即PLAY 請求。此頻道具體PLAY請求優(yōu)選地基于新頻道的ACURI產(chǎn)生，且更 優(yōu)選地包含新頻道的ACURI或者某些別的標(biāo)識符。此外，在終端上， 基于例如按4建的按下、觸摸感應(yīng)屏或者一些其它輸入行為的用戶輸入 產(chǎn)生PLAY請求。
媒體服務(wù)器以包括同步和時間信息的呈現(xiàn)響應(yīng)答復(fù)。當(dāng)PLAY響 應(yīng)提供同步信息以及用于SSRC字段的值時，在終端的解碼器可以開始 播放新頻道并且識別數(shù)據(jù)包。使用服務(wù)器的相同輸出端口將新頻道的 J(某體內(nèi)容傳輸至用戶終端的相同輸入端口 ，如用于先前的頻道那樣。 一^:保留在頻道透明建立過程期間所確定的其它傳輸參數(shù)。
本發(fā)明預(yù)期，如第一PLAY請求優(yōu)選包含的那樣，第二PLAY請求優(yōu)選包含在通用會話建立過程期間所分配的會話標(biāo)識符。
在優(yōu)選實施例中，為所有媒體流和頻道發(fā)送新同步值(SSRC)。 來自媒體服務(wù)器的PLAY響應(yīng)因此可能具有以下布局 RTSP/ 2.0 200 OK
RTSP-Info: URI="rtsp:〃tv.com/allchannels.sdp/audiotrack"
ssrc=0D12F123 : seq=5712 ; rtptime=93407921, URI="rtsp:〃 tv.com/allchannels.sdp/videotrack" ssrc=789DAF12 : seq=57654: rtptime=2792482193 因此，本發(fā)明的快速頻道切換在正在進(jìn)行的媒體會話、例如RTSP 會話內(nèi)利用呈現(xiàn)請求、比如RTSP PLAY請求來請求新頻道。所以， 在本發(fā)明的通用頻道透明建立期間所協(xié)商和確定的所有那些參數(shù)也 可以保留用于新媒體內(nèi)容的傳遞。這可與先有技術(shù)的切換相比較，在 先有技術(shù)的切換中，必須首先停止和拆卸當(dāng)前RTSP會話，在將新頻道 的媒體內(nèi)容交付并呈現(xiàn)于用戶終端以前，必須建立全新的頻道具體 RTSP會話。通過將圖6與圖1A和1B的情況相比較，4艮明顯，與該信令 有關(guān)的處理和大約6次的往返對于切換媒體頻道不再是必需的。因此， 本發(fā)明的頻道切換比先有技術(shù)的切換更快。
本發(fā)明的呈現(xiàn)請求的實際設(shè)計不是決定性的。 一個示例可如下
PLAY rtsp:〃tv.com/allchannels.sdp/channe12 RTSP/2.0
其中，"tv.com/allchannels.sdp/channel2"是媒體頻道號2的AC URI。
備選方法要使用 PLAY rtsp:〃tv.com/allchannels.sdp channeH2 RTSP/2.0 其中，查詢部分被用于基(base) URI "tv.com/allchannels.sdp"以
及"2"是所請求的頻道的標(biāo)識符。
對每一媒體頻道，優(yōu)選使用ACURI代替使用唯一的URI，能夠?qū)?于所有基于單播的媒體頻道使用同樣的URI但要增加某些信息以區(qū)別 頻道。例如，可以引入新頭標(biāo)。在這樣的情況中，PLAY請求可以如 下
PLAY rtsp:〃tv.com/allchannels.sdp RTSP/2.0x-channel:"所請求頻道的標(biāo)識符"
標(biāo)識符可以僅僅是數(shù)值l、 2、 3等，或者包括MBMS用戶服務(wù)標(biāo) 識符的其它名稱或者標(biāo)識符。
與先有技術(shù)相比，除了減少的切換時間以及更少的往返和與切換 有關(guān)的處理之外，本發(fā)明的頻道切換還具有其它優(yōu)勢。本發(fā)明可用于 在單播頻道和廣播/多播頻道之間提供轉(zhuǎn)換，反之亦然。
如果用戶想要從當(dāng)前基于單播的頻道切換到廣播頻道，那么暫時 中止當(dāng)前媒體內(nèi)容的傳遞。圖7是提供這樣的單播-廣播過渡時機(jī)的本 發(fā)明實施例的信號框圖。
一旦用戶終端接收到切換到廣播頻道的用戶輸入，終端就編譯呈 現(xiàn)暫停請求、例如RTSP PAUSE (暫停)請求。此請求是傳統(tǒng)的PAUSE 請求，如結(jié)合圖1A所述。媒體服務(wù)器通過暫停當(dāng)前基于單播的頻道的 媒體數(shù)據(jù)的發(fā)送響應(yīng)，并且優(yōu)選地用PAUSE答復(fù)或者響應(yīng)答復(fù)。
然后，用戶終端開始收聽廣播頻道并且接收該頻道的媒體數(shù)據(jù)。 此廣播頻道可以由通信系統(tǒng)中的同 一媒體服務(wù)器或者其它媒體服務(wù) 器提供。
如果用戶隨后想返回收聽先前基于單播的媒體頻道或者收聽由 該媒體服務(wù)器提供的另 一基于單播的頻道，那么用戶終端編譯并且向 媒體服務(wù)器傳輸新的頻道具體呈現(xiàn)請求、即PLAY請求。媒體服務(wù)器 以PLAY響應(yīng)答復(fù)，并且使用預(yù)先協(xié)商的傳送機(jī)制和端口將所選基于 單播的頻道的媒體數(shù)據(jù)傳輸?shù)接脩艚K端。
這意味著在到廣播頻道的臨時切換期間沒有終止基于單播的媒 體會話。相反，會話在休眠(dormant)并且依據(jù)新的呈現(xiàn)請求又變成 活動的。
如果用戶終端在切換期間的短時間并行接收兩個媒體數(shù)據(jù)流，那 么對于相同內(nèi)容，可使從單播到廣播訪問的切換或者從廣播到單播訪 問的切換無縫。這意味著在此短時期內(nèi)，用戶終端即從舊的(單播或 者廣播)頻道又從新的(單播或者廣播)頻道接收媒體內(nèi)容。那么，用戶終端將在RTP緩沖以前切換來源。
為了使這樣的無縫轉(zhuǎn)換可靠，優(yōu)選地，單播和廣播之間的傳輸延 遲小。最佳地，這兩個流相同或者完全同步。在這樣的情況中，可以 在流中的任何地方進(jìn)行切換。否則， 一般在用戶終端中在短時期內(nèi)并 行接收來自兩個流的媒體內(nèi)容，并且切換發(fā)生在幀內(nèi)。這降低了漏失 ^H 某體數(shù)據(jù)的數(shù)據(jù)包的風(fēng)險。
由媒體服務(wù)器提供的不同的單播和廣播頻道可以使用不同的編 碼和編解碼器設(shè)置。這可以通過、例如在描述文件(SDP文件)中描
述不同的編碼/設(shè)置來解決，并且供給他們不同的有效載荷類型值。根 據(jù)頻道切換，用戶終端將在接收新頻道的數(shù)據(jù)包時匆忙(on the fly) 切換解碼器配置。也能夠?qū)Σ煌幕趩尾サ念l道使用不同的編碼。
本發(fā)明也非常靈活，因為它能夠?qū)τ趩尾ズ蛷V播使用同一媒體流 而不改變?nèi)魏蜶TP頭標(biāo)域。這尤其與流的相同密碼的使用結(jié)合，簡化 了在正在進(jìn)行的媒體會話期間從單播到廣播的無縫轉(zhuǎn)換。
即使用戶首先想要收聽廣播頻道，也可執(zhí)行本發(fā)明的通用頻道透 明建立過程。這意味著，單播媒體會話建立了但接著休眠了，直到用 戶終端停止收聽廣播頻道并且向媒體服務(wù)器傳輸PLAY請求。這意味
著本發(fā)明的第一頻道具體呈現(xiàn)請求不一定必須在頻道透明建立過程 的完成滯后直接傳輸。改為， 一旦用戶想要從廣播頻道切換到單播頻 道，就首先發(fā)送呈現(xiàn)請求。
如果用戶終端隨后想結(jié)束當(dāng)前媒體會話，執(zhí)行先前描述的具有 PAUSE和TEARDOWN (拆卸)請求和響應(yīng)的過程。
優(yōu)選地，在所有隨后通信的請求和響應(yīng)中，由媒體服務(wù)器和用戶 終端使用媒體服務(wù)器優(yōu)選地產(chǎn)生的、與(第一)通用頻道透明SETUP 請求的接收有關(guān)的會話標(biāo)識符。這意味著，優(yōu)選把會話標(biāo)識符包含在 隨后的用于切換單播頻道的呈現(xiàn)請求中。另外，在用戶終端的廣播頻 道的暫時收聽之后恢復(fù)媒體會話的呈現(xiàn)請求也優(yōu)選地包含此會話標(biāo) 識符。本發(fā)明的通用頻道透明會話建立過程不一定必須遵循結(jié)合圖3到 圖6所描述的信令。在備選方法中，RTSP請求和答復(fù)的流水線操作是 可能的。在這樣的情況中，用戶終端編譯并且傳輸頻道透明的^L頻和 音頻SETUP請求，接著是頻道具體PLAY請求。這意味著終端在傳輸 下一個以前不等待對先前傳輸?shù)恼埱蟮娜魏未饛?fù)。媒體服務(wù)器以接連 地或者實際上一起地發(fā)送一見頻SETUP響應(yīng)、音頻SETUP響應(yīng)以及 PLAY響應(yīng)來響應(yīng)。然后，向用戶終端遞送首先在PLAY請求所請求的 媒體頻道的媒體數(shù)據(jù)。
在此流水線操作的實施例中，在頻道透明建立過程已經(jīng)結(jié)束且所 請求的々某體頻道已經(jīng)請求以后，首先向用戶終端通報會話標(biāo)識符。為 了識別用戶終端以及當(dāng)前會話，終端優(yōu)選地產(chǎn)生唯一的臨時標(biāo)識符并 且將其包括在SETUP以及PLAY請求中。這允許媒體服務(wù)器確定這些 請求發(fā)起于一個和同一用戶終端。 一旦終端已經(jīng)從媒體服務(wù)器、典型 地在第 一個SETUP答復(fù)中接收到會話標(biāo)識符，它就要在切換媒體頻道 時在任何隨后的PLAY請求中使用此會話標(biāo)識符替代臨時標(biāo)識符。
圖8是根據(jù)本發(fā)明實施例的基于單播的無線通信系統(tǒng)l的示意概 圖。通信系統(tǒng)1包含向已連接的用戶終端10、 100傳輸媒體內(nèi)容的基站 或者網(wǎng)絡(luò)節(jié)點20?；?0包含或者連接至本發(fā)明的媒體服務(wù)器200， 該媒體服務(wù)器具有多個可用的基于單播的媒體頻道。在該圖中，第一 用戶終端100收聽這些基于單播的媒體頻道之一。但是，另兩個用戶 終端10收聽在々某體服務(wù)器200也是可用的廣播頻道。
圖9是根據(jù)本發(fā)明實施例的用戶終端100的示意框圖。用戶終端 100包含發(fā)射機(jī)和接收機(jī)或者收發(fā)器IIO，在圖中作為單個單元示意 示出。單元110包括傳統(tǒng)的發(fā)射才幾/接收^L功能，比如調(diào)制器/解調(diào)器、 編碼器/解碼器等。
發(fā)射機(jī)110適合于向媒體服務(wù)器傳輸在頻道透明會話建立過程期 間的通用頻道透明請求，頻道具體呈現(xiàn)請求指示^ 某體傳遞和/或頻道切 換的開始。接收機(jī)110適合于接收對由發(fā)射機(jī)鏈110所發(fā)送的請求的響應(yīng)且當(dāng)然也接收來自媒體服務(wù)器的成流的4某體數(shù)據(jù)。
用戶終端100包含會話建立管理器140，該管理器構(gòu)成用于與媒體 服務(wù)器執(zhí)行通用頻道透明基于單播的會話建立過程的裝置。該建立管 理器140因此編譯由發(fā)射機(jī)110發(fā)送給媒體服務(wù)器的頻道透明請求消 息，并且處理由接收機(jī)110所接收的相應(yīng)的響應(yīng)消息。頻道透明建立 過程包括在用戶終端IOO與服務(wù)器之間的信息交換，但是不包括要使 用的媒體頻道的明確選擇直到會話建立。管理器140基于由發(fā)射機(jī)發(fā) 送的、通用頻道透明會話請求(DESCRIBE或者SETUP請求)與媒體 服務(wù)器執(zhí)行此建立過程。
一旦建立管理器140已與媒體服務(wù)器完成頻道透明建立過程，就 在用戶終端中執(zhí)行呈現(xiàn)或者播放請求產(chǎn)生器135以編譯頻道具體呈現(xiàn) 請求。請求消息包含所選々某體頻道的標(biāo)識符，例如ACURI或者其它頻 道標(biāo)識符。把經(jīng)編譯的呈現(xiàn)請求轉(zhuǎn)送到IIO，發(fā)射機(jī)又把它轉(zhuǎn)送到媒 體服務(wù)器用于開始媒體傳遞。
一般通過終端100的用戶輸入(未示出)激活建立管理器140和請 求發(fā)生器135。這將引起本發(fā)明的請求消息的產(chǎn)生及其向媒體服務(wù)器 的傳輸。
通過在到另 一基于單播的頻道的切換期間觸發(fā)或激活用戶輸入， 或者依據(jù)在廣播頻道收聽的臨時時段之后返回收聽基于單播的頻道， 也把請求發(fā)生器135激活。因此，在正在進(jìn)行的會話期間的頻道切換， 請求發(fā)生器135對新媒體頻道編譯呈現(xiàn)請求，該請求優(yōu)選包含此頻道 的標(biāo)識符。相應(yīng)地，在到廣播收聽的切換，播放請求發(fā)生器135編譯 由發(fā)射機(jī)110發(fā)送到Jf某體服務(wù)器的呈現(xiàn)暫停請求。如果用戶再想返回 先前的基于單播的頻道或者另一此類基于單播的媒體頻道，那么請求 發(fā)生器135形成具有那個媒體頻道的標(biāo)識符的頻道具體呈現(xiàn)請求。
可在多媒體或者用戶終端100的媒體播放器130中執(zhí)行請求發(fā)生 器135。媒體播放器130優(yōu)選地與終端100的顯示屏120和的揚(yáng)聲器160 通信，以用于在其上顯示和播出媒體?？稍谟脩艚K端100中執(zhí)行可選的媒體緩存器150,以用于在由媒體 播放器130在屏幕120和/或擴(kuò)音器160呈現(xiàn)所接收的媒體數(shù)據(jù)以前將其 暫時存儲。在頻道切換的情況下、尤其對于單播到廣播或者廣播到單 播的切換緩存器150有用，因為可以并行接收兩個媒體流并且將其存 儲在緩存器150中以允許無縫的頻道轉(zhuǎn)換。
可以軟件、硬件或其組合提供用戶終端100的單元110、 130、 135 以及140?？稍谌绫緢D所示的媒體播放器130中或者在終端100中的另 一位置實現(xiàn)播》文請求發(fā)生器135 。
圖10是圖9的用戶終端的會話建立管理器140的實施例的示意框 圖。建立管理器140可選地、但優(yōu)選地包含用于產(chǎn)生頻道透明描述請 求的單元141。該DESCRIBE請求發(fā)生器141編譯先前已討論的、可構(gòu) 成本發(fā)明通用頻道透明會話請求消息的頻道透明DESCRIBE請求。
產(chǎn)生的DESCRIBE響應(yīng)由可選的、但是優(yōu)選的描述消息處理器142 處理。該處理器142檢索(retrieve)在媒體服務(wù)器可用的多個媒體頻 道的宣告。在此情況下，把頻道的URI或者其它標(biāo)識符包括在描述消 息中，處理器142檢索這些標(biāo)識符并且將它們轉(zhuǎn)送給用戶終端的呈現(xiàn) 請求發(fā)生器。
在建立管理器140中提供用于組成本發(fā)明頻道透明的視頻SETUP 請求的視頻建立請求發(fā)生器143。該SETUP請求優(yōu)選地包含用戶終端 可接受的那些(視頻)傳輸參數(shù)的信息，包括終端的輸入視頻端口。 在實施例中，該;現(xiàn)頻SETUP請求構(gòu)成本發(fā)明的通用頻道透明會話請 求。
建立請求管理器140也包括^L頻建立消息或者響應(yīng)處理器144,用 于處理來自媒體服務(wù)器的視頻SETUP響應(yīng)。這意味著處理器144檢索 媒體服務(wù)器的視頻輸出端口的信息以及媒體服務(wù)器已經(jīng)選擇的那些 視頻傳輸參數(shù)。把此信息轉(zhuǎn)送到終端的發(fā)射機(jī)/接收機(jī)單元以供在隨后 的媒體數(shù)據(jù)接收期間使用。
優(yōu)選地在建立管理器140中實現(xiàn)對應(yīng)的音頻建立請求發(fā)生器145,以用于產(chǎn)生頻道透明的音頻SETUP請求。該建立請求包括用戶終端可 接受的那些(音頻)傳輸參數(shù)的信息，包括終端的輸入音頻端口。在 實施例中，該音頻建立請求構(gòu)成本發(fā)明通用頻道透明會話請求。
管理器140包括音頻建立響應(yīng)或者消息處理器146。該處理器146 處理由終端接收機(jī)接收的、并由發(fā)生器145響應(yīng)音頻SETUP請求發(fā)生 器產(chǎn)生的、且由終端發(fā)射機(jī)發(fā)射的音頻SETUP響應(yīng)。處理器146尤其 檢索由媒體服務(wù)器選擇的音頻傳輸參數(shù)以及用于音頻內(nèi)容的輸出端 口的信息。也把此信息轉(zhuǎn)送到終端的接收機(jī)，以便在媒體接收期間使 用。
由本發(fā)明可預(yù)期，；規(guī)頻建立發(fā)生器143和處理器144或者音頻建立 發(fā)生器145和處理器146可以從建立管理器140中忽略。在此情況下， 媒體內(nèi)容將僅包含音頻內(nèi)容或者視頻內(nèi)容。然而，對于多數(shù)典型實施
例，在建立管理器140中要求并執(zhí)行視頻和音頻發(fā)生器/處理器143、 144、 145、 146。
要是頻道標(biāo)識符沒有包含在由描述答復(fù)處理器142處理的描述消 息中或者沒有接收到這樣的描述響應(yīng)，則建立管理器140優(yōu)選地利用 可選的但是優(yōu)選的標(biāo)識符請求發(fā)生器147。該發(fā)生器147對在々某體服務(wù) 器可用的基于單播的頻道標(biāo)識符形成請求消息。 一般把所產(chǎn)生的消息 傳輸?shù)椒?wù)器，但是可備選地傳輸?shù)娇梢栽L問此信息的其它網(wǎng)絡(luò)節(jié) 點。
把來自媒體服務(wù)器或者其它節(jié)點的響應(yīng)消息從終端接收機(jī)轉(zhuǎn)送 到建立管理器140的標(biāo)識符響應(yīng)處理器148。該處理器148檢索媒體頻 道的信息，該信息一般以URI的形式并優(yōu)選地以AC URI的形式包含在 答復(fù)中。然后，^fe標(biāo)識符信息轉(zhuǎn)送到呈現(xiàn)請求發(fā)生器并且當(dāng)形成頻道 具體呈現(xiàn)請求時由發(fā)生器使用。
如果通過廣播或者多播傳輸通報頻道標(biāo)識符，那么配置標(biāo)識符消 息處理器148用于處理接收的廣播/多播信息并且從其中^r索頻道標(biāo)識 符信息。會話建立管理器140的單元141到148可以軟件、硬件或其組合提 供。單元141到148可以在建立管理器140中一起實現(xiàn)。把某些單元設(shè) 置在用戶終端中其它地方的分布式的實現(xiàn)也是可能的。
圖1 l是根據(jù)本發(fā)明的媒體服務(wù)器200的示意框圖。媒體服務(wù)器200 包括安排來與外部單元進(jìn)行通信并處理輸入和輸出消息的發(fā)射機(jī)和 接收機(jī)單元210。特別地，執(zhí)行發(fā)射機(jī)210用于向用戶終端傳輸響應(yīng)消 息和包含媒體數(shù)據(jù)的數(shù)據(jù)包。特別地，執(zhí)行接收機(jī)210用于接收來自 用戶終端的請求消息。
媒體服務(wù)器200包括或者可以訪問多個媒體頻道400、 410。這意 味著服務(wù)器200可以包括或者連接至存儲有預(yù)先錄制的媒體內(nèi)容的數(shù) 據(jù)庫。備選地，或者此外，媒體源可為在媒體服務(wù)器200所接收的實 況媒體內(nèi)容的形式，用于進(jìn)一步向請求終端的傳輸。執(zhí)行該服務(wù)器200 的媒體管理器230用于負(fù)責(zé)正確的媒體處理，例如為不同終端選擇正 確的媒體內(nèi)容、用媒體內(nèi)容產(chǎn)生數(shù)據(jù)包。
媒體服務(wù)器200還包括會話建立管理器220,該管理器220構(gòu)成用 于與用戶終端執(zhí)行通用頻道透明基于單播的會話設(shè)置過程的裝置。根 據(jù)由從終端發(fā)起的通用頻道透明會話請求的接收機(jī)觸發(fā)建立管理器 220。建立管理器220產(chǎn)生頻道透明響應(yīng)消息，并分別處理由發(fā)射機(jī)210 發(fā)送到用戶終端并由接收機(jī)21 O從終端接收的頻道透明請求消息。
一旦完成了頻道透明會話建立過程，并且接收機(jī)210接收頻道具 體呈現(xiàn)請求，則此請求被帶到媒體管理器230。纟某體管理器230基于該 請求中的頻道標(biāo)識符識別正確的媒體頻道，并且向發(fā)射機(jī)210轉(zhuǎn)送該 頻道的媒體內(nèi)容。發(fā)射機(jī)使用由會話建立管理器220協(xié)商的傳送機(jī)制 向終端轉(zhuǎn)送數(shù)據(jù)內(nèi)容。
如果接收機(jī)210隨后從終端接收新的頻道具體呈現(xiàn)請求，則媒體 管理器230將在處理該請求以后把媒體內(nèi)容的傳遞從先前的媒體頻道 切換到新請求的頻道。
暫停請求的接收將觸發(fā)媒體管理器230以便暫時停止向發(fā)送請求的終端提供々某體內(nèi)容。如果稍后接收到新的頻道具體呈現(xiàn)請求，則管
理器230將向發(fā)射機(jī)210提供那個頻道的媒體數(shù)據(jù)內(nèi)容，用于正在進(jìn)行 的會話期間的向用戶終端的傳遞。
圖5示意性地圖解單獨的服務(wù)器控制器300的使用，該服務(wù)器控制 器可在無線、基于射頻的通信系統(tǒng)中使用，用于傳輸可來自于媒體服 務(wù)器200的單播(以及廣播)頻道的標(biāo)識符。該控制器300已在圖11中 示出。在此情況下，該控制器300優(yōu)選地包括用于產(chǎn)生包含此標(biāo)識符 信息的消息的標(biāo)識符管理器320。然后，控制器300的發(fā)射機(jī)310向相 應(yīng)終端一般以組播或者廣播傳輸?shù)男问桨l(fā)送消息。
依靠發(fā)射機(jī)310，標(biāo)識符管理器320還可以詢問媒體服務(wù)器200媒 體頻道的信息，包括頻道的標(biāo)識符和有效性。
服務(wù)器控制器300可以連接到并包括來自安裝在通信系統(tǒng)中的若 干不同媒體服務(wù)器200的頻道信息。
可以軟件、硬件或其組合提供媒體服務(wù)器200的單元210到230。 在單網(wǎng)絡(luò)節(jié)點中，可在服務(wù)器200中一起實現(xiàn)單元210到230。可把某 些單元設(shè)置在網(wǎng)絡(luò)中的不同節(jié)點中的分布式實現(xiàn)也是可能的。關(guān)于軟 件/硬件實現(xiàn)的相同論述也適用于服務(wù)器控制器300的單元310和320。
圖12是圖11中的媒體服務(wù)器的會話建立管理器220示意框圖。建 立管理器220可選地、但是優(yōu)選地包括用于處理來自用戶終端的頻道 透明請求的描述請求處理器221。處理器221—般識別發(fā)起請求的終 端，并且通知可選的、但是優(yōu)選的描述響應(yīng)或消息發(fā)生器222。發(fā)生 器編譯先前已論述的、包含在媒體服務(wù)器可用的媒體頻道的通告的 DESCRIBE響應(yīng)。該通告可以是頻道的URI或者實際標(biāo)識符或者可以 被終端選擇的多個頻道的通知，在通知的情況下將分開通告頻道的標(biāo) 識符。
視頻建立請求處理器223和音頻建立請求處理器225處理所接收 的視頻和音頻SETUP請求。處理器223、 225選擇包括要用于會話的輸 出視頻和音頻端口的傳輸參數(shù)。把該信息既轉(zhuǎn)送到媒體服務(wù)器的發(fā)射機(jī)以用于即將來臨的媒體傳遞，又轉(zhuǎn)送到各自的^L頻建立響應(yīng)發(fā)生器 224和音頻建立響應(yīng)發(fā)生器226。發(fā)生器224編譯各自的包含輸入傳輸 參數(shù)的視頻和音頻建立響應(yīng)，用于向終端的傳輸。視頻SETUP響應(yīng)發(fā) 生器224優(yōu)選地也包括會話標(biāo)識符，該會話標(biāo)識符在J 某體服務(wù)器產(chǎn)生 的，并包含在在服務(wù)器和用戶終端之間交換的所有隨后的響應(yīng)和請求 中。
如果描述響應(yīng)發(fā)生器222不把媒體頻道標(biāo)識符包括在描述響應(yīng) 中，那么建立管理器220可以利用可選的標(biāo)識符消息發(fā)生器228。該發(fā) 生器228形成包含當(dāng)前在服務(wù)器可用的基于單播的媒體頻道的標(biāo)識 符、比如ACURI的消息。可依據(jù)來自用戶終端的明確請求的接收操作 發(fā)生器228。備選地，產(chǎn)生的消息可由服務(wù)器廣播或者多播到多個終 端。
可以軟件、硬件或其組合提供會話建立管理器220的單元221到 228。單元221到228可在建立管理器220中一起實現(xiàn)。把某些單元設(shè)置 在媒體服務(wù)器中其它地方的分布式實現(xiàn)也是可能的。
本領(lǐng)域技術(shù)人員要理解，在沒有脫離本發(fā)明范圍下可對本發(fā)明做 各種修改和變化，本發(fā)明的范圍由隨附的權(quán)利要求書定義。
參考文獻(xiàn) WO 2006/096104 3GPP TS 26.234 v7丄0; 3rd Generation Partnership Project; Technical Specification group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs, December 2006 Network Working Group, Request for Comments: 2327, April 1998, SDP: Session Description Protocol Network Working Group, Request for Comments: 2326, April 1998， Real Time Streaming Protocol (RTSP) Network Working Group, Request for Comments: 4234, October 2005, Augmented BNF for Syntax Specifications: ABNF
權(quán)利要求
1. 一種管理包括用戶終端(100)和提供多個媒體頻道的媒體服務(wù)器(200)的基于單播的媒體會話的方法，所述方法包括以下步驟所述用戶終端(100)向所述媒體服務(wù)器(200)傳輸通用頻道透明會話請求；所述用戶終端(100)與所述媒體服務(wù)器(200)并基于所述會話請求執(zhí)行通用頻道透明媒體會話建立過程；以及一旦完成了所述通用頻道透明媒體會話建立過程，所述用戶終端(100)就向所述媒體服務(wù)器(200)傳輸對所述多個媒體頻道的第一媒體頻道的頻道具體呈現(xiàn)請求。
2. 如權(quán)利要求l所述的方法，其中，所述執(zhí)行步驟包括 所述用戶終端(100)與所述媒體服務(wù)器(200)并基于所述會話請求執(zhí)行包括在所述用戶終端(100)和所述媒體服務(wù)器(200)之間 的信息的交換的所述通用頻道透明媒體會話建立過程，而沒有任何要 用于所述媒體會話的媒體頻道的明確選擇。
3. 如權(quán)利要求1或2所述的方法，其中，所述執(zhí)行步驟包括 所述用戶終端(100)從所述媒體服務(wù)器(200)接收基于所述會話請求所產(chǎn)生的通用頻道透明會話描述消息，所述通用頻道透明會話 描述消息包括所述多個媒體頻道的通告。
4. 如權(quán)利要求1到2中任意項所述的方法，其中，所述執(zhí)行步驟包括所述用戶終端(100)向所述士某體服務(wù)器(200)傳輸通用頻道透 明建立請求消息；以及所述用戶終端(100 )接收來自所述媒體服務(wù)器(200 )且基于所 述建立請求消息產(chǎn)生的、包括用于所述々某體會話的至少一個通信端口 的信息的通用頻道透明建立消息。
5. 如權(quán)利要求1到4中任意項所述的方法，其中，所述執(zhí)行步驟包括所述用戶終端(100)向所述媒體服務(wù)器(200)傳輸對用于所述 多個媒體頻道的每個媒體頻道的唯一媒體資源標(biāo)識符的標(biāo)識符請求， 所述方法還包括所述用戶終端(100)基于與所述第一媒體頻道關(guān)聯(lián)的唯一媒體 資源標(biāo)識符產(chǎn)生所述呈現(xiàn)請求。
6. 如權(quán)利要求1到5中任意項所述的方法，其中，所述執(zhí)行步驟包括所述用戶終端(100)接收用于所述多個媒體頻道的每個媒體頻 道的唯一媒體資源標(biāo)識符，所述方法還包括所述用戶終端(100)基于與所述第一媒體頻道關(guān)聯(lián)的唯一媒體 資源標(biāo)識符產(chǎn)生所述呈現(xiàn)請求。
7. 如權(quán)利要求1到6中任意項所述的方法，其中，所述傳輸步驟包括一旦完成了通用頻道透明媒體會話建立過程，所述用戶終端 (100)就向所述媒體服務(wù)器(200)傳輸包括與所述第一媒體頻道關(guān) 聯(lián)的唯一纟某體資源標(biāo)識符。
8. 如權(quán)利要求1到7中任意項所述的方法，還包括 在所述媒體會話期間所述用戶終端(100)向所述媒體服務(wù)器(200 )傳輸對所述多個々某體頻道的第二媒體頻道的頻道具體呈現(xiàn)請 求以便從所述第一媒體頻道切換到所述第二媒體頻道。
9. 如權(quán)利要求1到8中任意項所述的方法，還包括 所述用戶終端(100)向所述媒體服務(wù)器(200)傳輸呈現(xiàn)暫停請求，以暫停來自所述媒體服務(wù)器的所述第一媒體頻道的媒體數(shù)據(jù)的接 收；以及在所述媒體會話期間所述用戶終端(100)向所述媒體服務(wù)器 (200 )傳輸對所述多個媒體頻道的媒體頻道的頻道具體呈現(xiàn)請求以 便恢復(fù)媒體數(shù)據(jù)的接收。
10. —種管理包括用戶終端(100)和提供多個媒體頻道的媒體服 務(wù)器(200)的基于單播的媒體會話的方法，所述方法包括以下步驟所述媒體服務(wù)器(200)從所述用戶終端(100)接收通用頻道透 明會話請求；所述々某體服務(wù)器(200)與所述用戶終端(100)并基于所述會話 請求執(zhí)行通用頻道透明媒體會話建立過程；以及一旦完成了所述通用頻道透明媒體會話建立過程，所述媒體服務(wù) 器(200 )就向所述用戶終端(100)并基于發(fā)起于所述用戶終端(100 ) 的且被接收的、對所述多個媒體頻道的第一媒體頻道的頻道具體呈現(xiàn) 請求，傳輸?shù)谝幻襟w頻道的媒體數(shù)據(jù)。
11. 如權(quán)利要求10所述的方法，其中，所述執(zhí)行步驟包括 所述々某體服務(wù)器(200)與所述用戶終端(100)并基于所述會話請求執(zhí)行包括所述媒體服務(wù)器(200)和所述用戶終端(100)之間的 信息的交換的所述通用頻道透明媒體會話建立過程，而沒有要用于所 述媒體會話的媒體頻道的任何明確選擇。
12. 如權(quán)利要求10或11所述的方法，其中，所述執(zhí)行步驟包括 所述媒體服務(wù)器(200)基于所述會話請求產(chǎn)生包括所述多個媒體頻道的通告的通用頻道透明會話描述消息；以及所述媒體服務(wù)器(200)向所述用戶終端(100)傳輸所述通用頻 道透明會話描述消息。
13. 如權(quán)利要求10到12中任意項所述的方法，其中，所述執(zhí)行步 驟包括所述媒體服務(wù)器(200)基于從所述用戶終端(100)所接收的通用頻道透明建立請求消息產(chǎn)生包括要用于所述媒體會話的至少一個 通信端口的信息的通用頻道透明建立消息；以及所述媒體服務(wù)器(200)向所述用戶終端(100)傳輸所述通用頻 道透明建立消息。
14. 如權(quán)利要求3或13所述的方法，其中，所述通告包括用于所述多個媒體頻道的每個媒體頻道的唯一媒體資源標(biāo)識符。
15. 如權(quán)利要求10到14中任意項所述的方法，其中，所述執(zhí)行步 驟包括所述媒體服務(wù)器(200)向所述用戶終端(100)傳輸用于所述多 個媒體頻道的每個媒體頻道的唯一媒體資源標(biāo)識符。
16. 如權(quán)利要求10到15中任意項所述的方法，還包括 在所述媒體會話期間，所述媒體服務(wù)器(200)向所述用戶終端(100)并基于對發(fā)起于所述用戶終端(100)的、對所述多個媒體頻 道的第二媒體頻道的頻道具體呈現(xiàn)請求，傳輸所述第二媒體頻道的々某體數(shù)據(jù)。
17. 如權(quán)利要求10到16中任意項所述的方法，還包括 所述媒體服務(wù)器(200)基于發(fā)起于所述用戶終端(100)的呈現(xiàn)暫停請求暫停向所述用戶終端(100)的所述第一媒體頻道的所述媒 體數(shù)據(jù)的傳輸；以及所述媒體服務(wù)器(200)向所述用戶終端(100)并基于發(fā)起于所 述用戶終端(100)的、對所述多個媒體頻道的媒體頻道的頻道具體 呈現(xiàn)請求，傳輸所述請求的媒體頻道的媒體數(shù)據(jù)。
18. 如權(quán)利要求1到17中任意項所述的方法，其中，所述基于單^番 的媒體會話是實時流媒體協(xié)議(RTSP)會話。
19. 一種在基于單播的媒體會話中切換媒體頻道的方法，所述媒 體會話包括從提供第一媒體頻道和第二媒體頻道的媒體服務(wù)器(200 ) 接收所述第一媒體頻道的媒體數(shù)據(jù)的用戶終端(100),所述方法包 括所述用戶終端(100)在所述正在進(jìn)行的基于單播的媒體會話期間 向所述媒體服務(wù)器(200)傳輸對所述第二^ 某體頻道的頻道具體呈現(xiàn) 請求。
20. 如權(quán)利要求19所述的方法，其中，所述傳輸步驟包括 所述用戶終端(100)向所述媒體服務(wù)器(200)傳輸包括與所述正在進(jìn)行的基于單播的媒體會話關(guān)聯(lián)的、且在所述基于單播的媒體會話的建立期間所分配的會話標(biāo)識符的頻道具體呈現(xiàn)請求。
21. 如權(quán)利要求19或20所述的方法，還包括所述用戶終端(100)在與所述用戶終端(100)用于接收所述第 一媒體頻道的媒體數(shù)據(jù)所使用的輸入端口相同的輸入端口上接收所 述第二媒體頻道的媒體數(shù)據(jù)。
22. —種用戶終端(100)，包括發(fā)射機(jī)(110)，用于向提供多個媒體頻道的媒體服務(wù)器(200) 發(fā)送通用頻道透明會話請求；以及裝置(140)，用于與所述i某體服務(wù)器(200)并基于所述會話請 求執(zhí)行通用頻道透明基于單播的媒體會話建立過程，其中，設(shè)置所述 發(fā)射機(jī)(110)用于一旦所述執(zhí)行裝置已經(jīng)完成所述通用頻道透明媒 體會話建立過程就向所述媒體服務(wù)器(200)傳輸對所述多個媒體頻 道的第一J 某體頻道的頻道具體呈現(xiàn)請求。
23. 如權(quán)利要求22所述的用戶終端，其中，所述執(zhí)行裝置(140) 包括描述消息處理器(142)，用于處理發(fā)起于所述々某體服務(wù)器(200 ) 且基于所述會話請求所產(chǎn)生的通用頻道透明會話描述消息以檢索所 述多個媒體頻道的通告。
24. 如權(quán)利要求22或23所述的用戶終端，其中，所述執(zhí)行裝置 (140)包括建立請求發(fā)生器(143、 145 ),用于產(chǎn)生去往所述纟某體服務(wù)器(200 ) 的通用頻道透明建立請求；以及建立信息處理器(144、 146)，用于處理發(fā)起于所述媒體服務(wù)器 (200)并基于所述建立請求所產(chǎn)生的通用頻道透明建立消息，所述 通用頻道透明建立消息包括在所述媒體會話期間要由所述用戶終端 (100)的接收機(jī)(110)所使用的至少一個通信端口的信息。
25. 如權(quán)利要求22到24中任意項所述的用戶終端，其中，所述執(zhí) 行裝置(140 )包括標(biāo)識符消息處理器(148)，用于從標(biāo)識符消息檢索用于所述多 個媒體頻道的每個媒體頻道的唯一媒體資源標(biāo)識符，所述用戶終端 (100)還包括呈現(xiàn)請求發(fā)生器(135),用于基于與所述第一媒體頻道關(guān)聯(lián)的 唯一i某體資源標(biāo)識符產(chǎn)生所述呈現(xiàn)請求。
26. 如權(quán)利要求22到25中任意項所述的用戶終端，其中，設(shè)置所 述發(fā)射機(jī)(110)用于一旦所述執(zhí)行裝置(140)已經(jīng)完成所述通用頻 道透明媒體會話建立過程就向所述媒體服務(wù)器(200)發(fā)送包括與所 述第一媒體頻道關(guān)聯(lián)的唯一媒體資源標(biāo)識符的所述頻道具體呈現(xiàn)請求。
27. 如權(quán)利要求22到26中任意項所述的用戶終端，其中，設(shè)置所 述發(fā)射機(jī)(110)用于在所述媒體會話期間向所述媒體服務(wù)器(200) 發(fā)送對所述多個媒體頻道的第二媒體頻道的頻道具體呈現(xiàn)請求，以便 從所述第 一媒體頻道切換到所述第二媒體頻道。
28. 如權(quán)利要求22到27中任意項所述的用戶終端，其中，設(shè)置所 述發(fā)射機(jī)(110 )用于在所述媒體會話期間i )向所述媒體服務(wù)器(200 ) 發(fā)送呈現(xiàn)暫停請求以暫停來自所述媒體服務(wù)器(200)的所述第一媒 體頻道的媒體數(shù)據(jù)的接收，以及ii)向媒體服務(wù)器(200)發(fā)送對所 述多個媒體頻道的媒體頻道的頻道具體呈現(xiàn)請求以便恢復(fù)媒體數(shù)據(jù) 的接收。
29. —種用戶終端(100),包括頻道開關(guān)(135),用于在正在進(jìn)行的基于單播的媒體會話期間 切換媒體頻道，設(shè)置所述頻道開關(guān)用于產(chǎn)生對新媒體頻道的頻道具體 呈現(xiàn)請求；以及發(fā)射機(jī)(110),用于向給所述用戶終端(100)提供當(dāng)前媒體頻 道并且具有對所述新媒體頻道的訪問的媒體服務(wù)器(200)發(fā)送所述 頻道具體呈現(xiàn)請求。
30. —種提供多個媒體頻道的媒體服務(wù)器(200)，所述媒體服務(wù)器(200 )包括接收機(jī)(210 )，用于從用戶終端(100 )接收通用頻道透明會話請求；裝置(220),用于與所述用戶終端(100)并基于所述會話請求 執(zhí)行通用頻道透明基于單播的媒體會話建立過程；發(fā)射機(jī)(210)，用于一旦所述執(zhí)行裝置(220)已經(jīng)完成通用頻 道透明々某體會話建立過程就向所述用戶終端(100)并基于發(fā)起于所 述用戶終端(100)并由所述接收機(jī)(210)所接收的、對所述多個媒 體頻道的第 一媒體頻道的頻道具體呈現(xiàn)請求，發(fā)送所述第 一媒體頻道 的媒體數(shù)據(jù)。
31. 如權(quán)利要求30所述的媒體服務(wù)器，其中，所述執(zhí)行裝置(220) 包括會話描述消息發(fā)生器(222)，用于基于所述會話請求產(chǎn)生包括 所述多個媒體頻道的通告的通用頻道透明會話描述消息，其中，設(shè)置 所述發(fā)射機(jī)(210)用于向所述用戶終端(100)發(fā)送所述通用頻道透 明會話描述消息。
32. 如權(quán)利要求30或31所述的媒體服務(wù)器，其中，所述執(zhí)行裝置 (220)包括建立消息發(fā)生器(224、 226)，用于基于從所述用戶終端(100) 所接收的通用頻道透明建立請求消息產(chǎn)生包括要用于所述媒體會話 的至少一個通信端口的信息的通用頻道透明建立消息，其中，設(shè)置所 述發(fā)射機(jī)(210)用于向所述用戶終端(100)發(fā)送所述通用頻道透明 建立消息。
33. 如權(quán)利要求30到32中任意項所述的媒體服務(wù)器，其中，設(shè)置 所述發(fā)射機(jī)(210)用于在所述々某體會話期間向所述用戶終端(100) 并基于發(fā)起于所述用戶終端(100)的、對所述多個媒體頻道的第二 媒體頻道的頻道具體呈現(xiàn)請求發(fā)送所述第二媒體頻道的媒體數(shù)據(jù)。
34. 如權(quán)利要求30到33中任意項所述的媒體服務(wù)器，其中，設(shè)置所述發(fā)射機(jī)(210)用于i)基于發(fā)起于所述用戶終端(100)的呈現(xiàn) 暫停請求暫停向所述用戶終端(100)的所述第一媒體頻道的所述媒 體數(shù)據(jù)的發(fā)送，以及ii)向所述用戶終端(100)并基于發(fā)起于所述 用戶終端(100)的、對所述多個媒體頻道的媒體頻道的頻道具體呈 現(xiàn)請求發(fā)送所述所請求的媒體頻道的媒體數(shù)據(jù)。
35. —種網(wǎng)絡(luò)節(jié)點(20)，所述網(wǎng)絡(luò)節(jié)點(20)包括依照權(quán)利要 求30到34中任意項所述的々某體服務(wù)器(200)。
全文摘要
本發(fā)明的媒體會話管理包括具有對多個基于單播的頻道的訪問的媒體服務(wù)器(200)和用戶終端(100)。用戶終端(100)產(chǎn)生并向所述服務(wù)器(200)傳輸通用頻道透明會話請求。此請求發(fā)起終端(100)和服務(wù)器(200)之間的通用頻道透明媒體會話建立過程。該建立過程包括請求和響應(yīng)的交換，但是在服務(wù)器(200)仍沒有選擇或者通知媒體頻道。一旦完成了頻道透明建立，用戶終端(100)就向服務(wù)器(200)發(fā)送對需要的媒體頻道的頻道具體呈現(xiàn)請求。在隨后的頻道切換中，終端(100)在正在進(jìn)行的會話期間僅向所述服務(wù)器(200)傳輸對新頻道的新頻道具體請求，并且再使用頻道透明建立過程的經(jīng)協(xié)商的傳輸參數(shù)。
文檔編號H04N7/24GK101473654SQ200780022592
公開日2009年7月1日 申請日期2007年5月4日 優(yōu)先權(quán)日2006年6月19日
發(fā)明者M·韋斯特倫德, T·埃納森, T·洛馬, U·霍恩 申請人:艾利森電話股份有限公司