用于建立瘦客戶端會話的方法
【專利摘要】本發(fā)明提供一種用于建立瘦客戶端會話的方法。示例性實施例涉及一種用于在瘦客戶端設(shè)備與瘦客戶端服務(wù)器之間建立瘦客戶端會話的方法，該瘦客戶端設(shè)備和該瘦客戶端服務(wù)器在基于SIP的架構(gòu)之上的會話協(xié)商期間交換握手消息和初始化消息，其中，所述瘦客戶端設(shè)備(2)和所述瘦客戶端服務(wù)器(4)交換表示瘦客戶端上下文的附加信息，瘦客戶端上下文使得能夠在瘦客戶端會話期間組合和適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流。
【專利說明】用于建立瘦客戶端會話的方法
[0001]本申請是 申請人:為日本電氣株式會社于2009年9月18日提交的題為“用于建立瘦客戶端會話的方法”、申請?zhí)枮?00980140159.0的發(fā)明的分案申請。
【技術(shù)領(lǐng)域】
[0002]本發(fā)明有關(guān)通信領(lǐng)域，并且涉及用于在諸如MS之類的基于SIP的架構(gòu)之上發(fā)起瘦客戶端系統(tǒng)工作的新的會話描述。
[0003]更具體地，本發(fā)明關(guān)于用于改進(jìn)在瘦客戶端設(shè)備與瘦客戶端服務(wù)器之間建立瘦客戶端連接的方法，該瘦客戶端設(shè)備和瘦客戶端服務(wù)器在基于會話發(fā)起協(xié)議(SIP)的架構(gòu)之上的會話協(xié)商期間交換握手消息和初始化消息。
[0004]本發(fā)明還關(guān)于適于實現(xiàn)所述方法的瘦客戶端設(shè)備和瘦客戶端服務(wù)器。
【背景技術(shù)】
[0005]會話描述協(xié)議(SDP) [IETF RFC4566]旨在描述用于會話公告、會話邀請和其它形式的多媒體會話發(fā)起的多媒體會話。SDP最常見的是被用于利用在用于最少控制下的音頻和視頻會議的RTP簡檔[IETF RFC3551]中定義的音頻和視頻媒體的簡檔，來描述通過實時傳輸協(xié)議(RTP) [IETFRFC3550]被傳輸?shù)拿襟w流。此外，RTP有效載荷格式[IETF RFC3555]的MME類型注冊定義了用于音頻和視頻會議的RTP有效載荷格式來作為MME子類型。
[0006]然而，SDP可被用于描述可通過實時傳輸協(xié)議(RTP)傳輸?shù)囊纛l和視頻以外的其它媒體簡檔。
[0007]SDP通常被承載在會話發(fā)起協(xié)議(SIP) [IETF RFC3261]消息中，以便對端點間的共同媒體描述達(dá)成一致。利用會話描述協(xié)議(SDP) [IETFRFC3264]的提出/應(yīng)答(offer /answer)模型定義了用于使兩個端點可以交換SDP媒體描述并且對應(yīng)當(dāng)使用哪個媒體流達(dá)成一致的架構(gòu)，并且定義了與媒體相關(guān)的參數(shù)。
[0008]在瘦客戶端會話的典型情況中，可能希望通過分組或電路交換載體連接來配置和建立用于遠(yuǎn)程桌面/應(yīng)用顯示以及用于控制事件的媒體流。這樣的會話通常利用諸如基于遠(yuǎn)程幀緩沖器(RFB)協(xié)議或遠(yuǎn)程桌面協(xié)議(RDP)的虛擬網(wǎng)絡(luò)計算(VNC)之類的瘦客戶端協(xié)議，以及獨立計算體系結(jié)構(gòu)協(xié)議(ICA)、X11協(xié)議來實現(xiàn)。此外，甚至可以利用實時傳輸協(xié)議(RTP)來流傳輸像素，并且這樣的圖形原語(primitive)將被承載在RTP分組中。
[0009]在移動性、下一代網(wǎng)絡(luò)和豐富媒體應(yīng)用的上下文中，重要的是注意到服務(wù)質(zhì)量(QoS)、適應(yīng)性(適用性)和認(rèn)證是關(guān)鍵點，并且查看媒體格式對于資源預(yù)留處理以及對于運營商控制無線電載體流量和IP流(例如，基于給定策略、用戶預(yù)訂或服務(wù)簡檔來應(yīng)用適當(dāng)?shù)馁Y源分配)來說同樣是重要的。此外，如第三代合作伙伴計劃[3GPP TS23.228]所定義的-基于SIP和在核心網(wǎng)絡(luò)之上提供重疊網(wǎng)絡(luò)的一IP多媒體子系統(tǒng)(IMS)也能夠與包括對QoS資源進(jìn)行授權(quán)的能力的策略和收費控制體系結(jié)構(gòu)[3GPP TS23.203]互聯(lián)。
[0010]由于應(yīng)用在從基于簡單文本和/或圖形的應(yīng)用到可遭受網(wǎng)絡(luò)延遲和高吉格比(high gigue ratio)的基于音頻和/或視頻的應(yīng)用的范圍中，因此需要適應(yīng)于遠(yuǎn)程桌面控制會話內(nèi)的不同類型流量的方式。
[0011]從服務(wù)方面，可預(yù)見到將遠(yuǎn)程桌面訪問與諸如電話呼叫建立或推向x(pUsh-to-x)服務(wù)之類的其它服務(wù)相組合。通過利用SIP，擴展傳統(tǒng)的遠(yuǎn)程桌面控制用例變得可能。
[0012]從Q0S方面，也希望使得能夠進(jìn)行通過瘦客戶端媒體描述的QoS控制。例如，媒體的圖形和事件類型可被分配預(yù)定義QoS簡檔，它們甚至可以通過分組或電路交換載體連接而被流傳輸。此外，當(dāng)瘦客戶端設(shè)備移動時，接入網(wǎng)環(huán)境可以改變，因此可能希望重新分配適當(dāng)?shù)馁|(zhì)量設(shè)置(資源分配、諸如編解碼器、傳輸協(xié)議之類的媒體參數(shù)的重新協(xié)商，等
坐 ')
Tj-./ O
[0013]然而，從認(rèn)證的角度，已知的瘦客戶端協(xié)議使用其自己的規(guī)則和機制的集合(即，內(nèi)置協(xié)商)來認(rèn)證和建立瘦客戶端設(shè)備與瘦客戶端服務(wù)器之間的連接。

【發(fā)明內(nèi)容】

[0014]技術(shù)問題
[0015]相關(guān)技術(shù)的技術(shù)未提供用于混合并適配利用到SIP架構(gòu)之上的遠(yuǎn)程桌面控制能力的諸如音頻/視頻之類的多媒體傳送的手段。
[0016]問題的解決方案
[0017]本發(fā)明的一個示例性目的是向現(xiàn)有功能添加遠(yuǎn)程桌面控制，以便協(xié)商SIP會話內(nèi)的媒體并且允許與遠(yuǎn)程桌面控制的會話有關(guān)的自適應(yīng)媒體傳送(即，視頻傳送、音頻傳送...)。
[0018]根據(jù)本發(fā)明的示例性方面，提供了一種用于在瘦客戶端設(shè)備與瘦客戶端服務(wù)器之間建立瘦客戶端會話的方法，該瘦客戶端設(shè)備和該瘦客戶端服務(wù)器在基于SIP的架構(gòu)之上的會話協(xié)商期間交換握手消息和初始化消息，其中，所述瘦客戶端設(shè)備和所述瘦客戶端服務(wù)器交換表示瘦客戶端上下文的附加信息，瘦客戶端上下文使得能夠在瘦客戶端會話期間組合和適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流。
[0019]根據(jù)本發(fā)明的示例性方面，提供了一種瘦客戶端設(shè)備，適于實現(xiàn)用于建立與瘦客戶端服務(wù)器的瘦客戶端會話的方法，該瘦客戶端設(shè)備包括用于與所述瘦客戶端服務(wù)器交換表示瘦客戶端上下文的附加信息的裝置，所述瘦客戶端上下文使得能夠在所述瘦客戶端會話期間組合和適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流，所述附加信息包括SDP (會話描述協(xié)議)提出/應(yīng)答消息或者被嵌入在SIP消息的主體中的基于XML的提出/應(yīng)答消息。
[0020]根據(jù)本發(fā)明的示例性方面，提供了一種瘦客戶端服務(wù)器，適于實現(xiàn)用于建立與瘦客戶端設(shè)備的瘦客戶端會話的方法，該瘦客戶端服務(wù)器包括用于與所述瘦客戶端設(shè)備交換表示瘦客戶端上下文的附加信息的裝置，所述瘦客戶端上下文使得能夠在所述瘦客戶端會話期間組合和適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流。
[0021]本發(fā)明的有益效果
[0022]根據(jù)本發(fā)明，實現(xiàn)了向現(xiàn)有功能添加遠(yuǎn)程桌面控制，以便協(xié)商SIP會話內(nèi)的媒體并且允許與遠(yuǎn)程桌面控制的會話有關(guān)的自適應(yīng)媒體傳送(即，視頻傳送、音頻傳送...)。
【專利附圖】

【附圖說明】[0023]當(dāng)集合圖示出本發(fā)明的示例性實施例的附圖進(jìn)行閱讀時，將更好地了解前面的概述以及下面的詳細(xì)描述，在附圖中:
[0024]圖1示意性地圖示出基于MS的體系結(jié)構(gòu)。
[0025]圖2圖示出瘦客戶端查看器，其示出了由可動態(tài)地進(jìn)行適配的若干個區(qū)域構(gòu)成的遠(yuǎn)程桌面。
[0026]圖3圖示出描述根據(jù)本實施例的方法的步驟的流程圖。
[0027]圖4示意性地圖示出根據(jù)本實施例的應(yīng)用顯示重定向的示例。
【具體實施方式】
[0028]根據(jù)本實施例，提供了用于建立瘦客戶端設(shè)備與瘦客戶端服務(wù)器之間的瘦客戶端連接的方法，該瘦客戶端設(shè)備和瘦客戶端服務(wù)器在基于會話發(fā)起協(xié)議(SIP)的架構(gòu)之上的會話協(xié)商期間交換握手消息和初始化消息。
[0029]根據(jù)本實施例，所述瘦客戶端設(shè)備和所述瘦客戶端服務(wù)器交換表示瘦客戶端上下文的附加信息，以使得能夠在所述瘦客戶端會話期間組合并適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流。
[0030]附加信息允許多媒體傳送能力和遠(yuǎn)程桌面控制能力兩者，并且可以包括按照SDP (會話描述協(xié)議)提出/應(yīng)答消息或者嵌入在SIP消息的主體中的基于XML的提出/應(yīng)答消息而被格式化的瘦客戶端信息。
[0031]遠(yuǎn)程桌面控制能力包括這樣的功能，該功能包括動態(tài)地將至少一個遠(yuǎn)程應(yīng)用的圖形更新從第一設(shè)備定向或重定向到第二設(shè)備上去。
[0032]所述第一設(shè)備可以是移動通信設(shè)備并且所述第二設(shè)備可以是固定通信設(shè)備。
[0033]根據(jù)本發(fā)明另一方面，所述遠(yuǎn)程桌面控制能力還包括這樣的功能，該功能包括最終在與用于下行鏈路圖形更新的無線電載體和/或IP連接不同的無線電載體和/或IP連接上傳送上行鏈路事件。無線電載體是根據(jù)3GPP定義的用于在用戶設(shè)備與無線電接入網(wǎng)絡(luò)之間傳送用戶數(shù)據(jù)的第2層服務(wù)。單獨的IP連接可以通過分配不同的端口號或者經(jīng)由未加密或加密的IP隧道傳輸機制(即，IPSec)而獲得的。
[0034]遠(yuǎn)程桌面控制能力還包括這樣的功能，該功能包括將至少一個音頻/視頻流關(guān)聯(lián)到遠(yuǎn)程桌面控制的會話(即，瘦客戶端會話)。
[0035]在本實施例的一個實施例中，所述附加信息包括與被關(guān)聯(lián)到所述瘦客戶端會話的所述音頻/視頻流相對應(yīng)的遠(yuǎn)程顯示幀緩沖器坐標(biāo)和大小。所述幀緩沖器坐標(biāo)和大小使得能夠在設(shè)備的本地屏幕上適當(dāng)?shù)囟ㄎ贿h(yuǎn)程桌面顯示之上的視頻呈現(xiàn)。
[0036]此外，所述附加信息允許發(fā)送向服務(wù)器指示幀緩沖器上的特定區(qū)域不需要更新的客戶端請求(FramebufferForgetRequest)。
[0037]在本實施例的另一實施例中，所述附加信息包括窗口 -1d屬性并且允許發(fā)送向服務(wù)器指示由窗口 -1d屬性標(biāo)識的圖形區(qū)域已被重新調(diào)節(jié)大小、已被移動或者這兩者的客戶端請求(WindowUpdate)。
[0038]由于根據(jù)本實施例的方法，使得能夠:
[0039]-允許服務(wù)的組合
[0040]-使得能夠控制來自移動設(shè)備的遠(yuǎn)程應(yīng)用的顯示重定向[0041]-使得能夠進(jìn)行服務(wù)質(zhì)量控制和準(zhǔn)確的會話控制
[0042]-使得能夠使用統(tǒng)一協(xié)商以避免寬范圍的特定瘦客戶端認(rèn)證和媒體協(xié)
[0043]商機制。
[0044]由于本實施例，諸如RFB或ITU T.120 (用于多媒體會議的數(shù)據(jù)協(xié)議)之類的已知協(xié)議的協(xié)商步驟部分地或者全部被基于SDP的協(xié)商取代，并且新的信息被提供以允許混合用于遠(yuǎn)程顯示連接的媒體流量。利用SDP和SIP架構(gòu)協(xié)商這樣的瘦客戶端連接在如下方面提供了靈活性:從由先前引用的公知瘦客戶端協(xié)議應(yīng)用的屏幕更新策略區(qū)分開瘦客戶端會話的信令和控制。有利地，該瘦客戶端會話可以從會話重定向特征以及其它公知的SIP和SDP擴展中獲益。
[0045]另外，瘦客戶端連接可以在由第三代合作伙伴計劃標(biāo)準(zhǔn)化的IP多媒體子系統(tǒng)[3GPP TS23.228]中被準(zhǔn)確地跟蹤和控制。
[0046]在一些典型的用例中，可能希望在與發(fā)送圖形更新的無線電載體和/或IP連接不同的另外的無線電載體和/或IP連接中發(fā)送諸如公知的鍵和鼠標(biāo)事件之類的上行鏈路用戶事件。通過這樣做，服務(wù)質(zhì)量可被應(yīng)用，并且例如可以通過確保事件載體的非常高的優(yōu)先級來制定關(guān)于調(diào)整系統(tǒng)的響應(yīng)性的策略。
[0047]此外，在移動性上下文中，移動設(shè)備可能從高帶寬分組交換載體可用的無線網(wǎng)絡(luò)區(qū)域移動到具有較低帶寬的無線局域網(wǎng)(WLAN)可用的另一區(qū)域。因此，圖形媒體可能經(jīng)受延遲和帶寬變化。因此希望重新協(xié)商會話參數(shù)，并且可以通過利用SIP和SDP提出/應(yīng)答模型以及頂S移動性管理過程來實現(xiàn)此。
[0048]通過利用所提出的實施例，可以建立上行鏈路載體來發(fā)送用戶事件并且建立下行鏈路載體來接收圖形更新。在瘦客戶端設(shè)備處，還可以定義替代傳輸協(xié)議，以制備適于查看器傳輸模式的查看器(例如，從TCP協(xié)議上的RFB / VNC切換到RTP協(xié)議)，以使能播放影片的并將利用RTP被流傳輸?shù)钠聊伙@示的某個部分，同時背景利用RFB協(xié)議僅定期地被更新。如果查看器不支持替代機制，則在協(xié)商階段期間其僅不被接受而已。
[0049]根據(jù)本實施例的方法可以利用不脫離本發(fā)明的范圍的任何其它SIP和SDP擴展(RFC3108、RFC4975、draft-garcia-mmusic-sdp-cs-01)來實現(xiàn)。
[0050]根據(jù)本實施例的方法通過瘦客戶端設(shè)備和瘦客戶端服務(wù)器來實現(xiàn)，瘦客戶端設(shè)備包括用于與瘦客戶端服務(wù)器交換表示瘦客戶端上下文的附加信息的裝置，瘦客戶端上下文使得能夠在瘦客戶端會話期間組合和適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流，附加信息包括SDP (會話描述協(xié)議)提出/應(yīng)答消息或者被嵌入在SIP消息的主體中的基于XML的提出/應(yīng)答消息。
[0051]所述瘦客戶端設(shè)備可以是移動用戶設(shè)備，該移動用戶設(shè)備包括用于使得用戶能夠登記對媒體重定向的興趣的接口，以便在接收到所述媒體重定向時被通知，并且發(fā)送重定向應(yīng)答。
[0052]此外，所述移動用戶設(shè)備適于建立用于上行鏈路事件的分離的IP連接，以用于觸發(fā)將單獨的無線電載體分配用于在與用于下行鏈路圖形更新的無線電載體不同的無線電載體上傳送所述上行鏈路事件，并且適于將(一個或多個)音頻/視頻流的呈現(xiàn)映射到其屏幕上的所述遠(yuǎn)程顯示幀緩沖器。
[0053]所述移動用戶設(shè)備包括用于使得用戶能夠登記對媒體重定向的興趣的接口，以便在接收到所述媒體重定向時被通知，并且發(fā)送重定向應(yīng)答。
[0054]本實施例還涉及一種瘦客戶端服務(wù)器，適于實現(xiàn)用于建立與瘦客戶端設(shè)備的瘦客戶端會話的方法，所述瘦客戶端服務(wù)器包括用于與所述瘦客戶端設(shè)備交換表示瘦客戶端上下文的附加信息的裝置，所述瘦客戶端上下文使得能夠在所述瘦客戶端會話期間組合和適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流。
[0055]本實施例允許擴展在正在進(jìn)行的工作[draft-garcia-mmusic-sdp-collaboration-00]中定義的媒體類型，并且定義新的瘦客戶端媒體類型和屬性。
[0056]為了實現(xiàn)此，本實施例提議定義控制事件媒體類型?，F(xiàn)有的“控制”媒體類型被用來指定用于會話的附加會議控制信道。我們需要使用不同的媒體類型來精確指定用于諸如指針或鍵事件之類的用戶事件的控制信道。
[0057]最后，本實施例提供了用于將多媒體流與瘦客戶端遠(yuǎn)程顯示流相混合的方式。“Grouping of Media Lines in SDP (SDP 中的媒體行的成組)” [IETF RFC3388]提供了用于成組媒體流的手段，以便表達(dá)出會話內(nèi)的不同媒體流彼此如何相關(guān)，更具體地，出于唇同步(Lip synchronization)或流標(biāo)識的目的。應(yīng)當(dāng)注意，成組機制取決于“a=group”會話級屬性的語義。因此，我們提供了用于瘦客戶端(“TC”)上下文的新的語義。
[0058]將基于RFB協(xié)議圖示出實施方式。
[0059]<第一示例性實施例>
[0060]將參考圖1描述本示例性實施例，圖1圖示出了用于向移動設(shè)備遞送IP多媒體服務(wù)的由第三代合作伙伴計劃[3GPP TS23.228]定義的MS體系結(jié)構(gòu)架構(gòu)。該體系結(jié)構(gòu)包括作為瘦客戶端設(shè)備的移動用戶設(shè)備2、瘦客戶端服務(wù)器4、IMS核心系統(tǒng)6、策略決定功能模塊8 (PDF)、3GPP分組交換(PS)核心網(wǎng)絡(luò)10。MS核心系統(tǒng)6主要包括呼叫會話控制功能(CSCF)(其包括代理-CSCF (P-CSCF)、服務(wù)-CSCF (S-CSCF)和詢問-CSCF (1-CSCF))。CSCF 提供了用于訂戶訪問頂(IP多媒體)核心系統(tǒng)6內(nèi)的服務(wù)的會話控制。實質(zhì)上，CSCF是SIP服務(wù)器。其負(fù)責(zé)與諸如用于移動性的HSS和用于安全性的AAA(訪問、授權(quán)和計費)服務(wù)器之類的網(wǎng)絡(luò)數(shù)據(jù)庫交互。需要這些模塊來處理MS中的SIP信令分組。
[0061]IMS應(yīng)用服務(wù)器執(zhí)行服務(wù)并且與S-SCSF接口。如在[3GPP23.228]中定義的一些接口在圖1中示出:ISC接口用來在CSCF與瘦客戶端服務(wù)器4之間交換消息。
[0062]Gm接口用來在UE2與CSCF之間交換基于SIP的信息。
[0063]GQ接口用來在CSCF與策略決定功能(PDF)之間交換信息策略決定信息。
[0064]接口 Cx旨在用于CSCF與歸屬訂閱服務(wù)器(HSS)之間的通信，并且接口 Dx用于在多HSS環(huán)境中尋找正確的HSS。
[0065]由瘦客戶端服務(wù)器4使用的接口 Sh用于與HSS或者與具有SIP / OSA服務(wù)能力的服務(wù)器(0SA / SCS)傳輸信息。
[0066]接口 Go用于控制并授權(quán)服務(wù)質(zhì)量，并且在MS與3GPP策略和收費控制(PCC)體系結(jié)構(gòu)[3GPP TS23.203]之間交換相關(guān)性信息。
[0067]接口 Ut用于控制應(yīng)用服務(wù)器并且是基于HTTP協(xié)議的。
[0068]當(dāng)使用MS SIP信令協(xié)議時，瘦客戶端UE2可以通過建立SIP會話而連接到MS瘦客戶端應(yīng)用服務(wù)器(TCAS) 4，如圖1所示。在此處理期間，瘦客戶端UE2和TCAS4可以協(xié)商QoS和媒體參數(shù)。UE2還可以通過Ut接口對該TCAS4執(zhí)行一些配置，例如，配置桌面環(huán)境。由應(yīng)用生成的像素經(jīng)由Ut*接口以端到端的方式被流傳輸?shù)経E2，并且視頻或音頻媒體也可被流傳輸?shù)経E2。
[0069]根據(jù)本示例性實施例的方法將SDP擴展來描述瘦客戶端會話、相關(guān)聯(lián)的媒體以及遠(yuǎn)程控制事件。一種替代方式是利用如W3C可擴展標(biāo)記語言(XML) 1.0 (第四版本)所定義的XML語法來提供所述描述。
[0070]更具體地，該方法允許將至少一個音頻/視頻流關(guān)聯(lián)到瘦客戶端連接，該瘦客戶端連接是利用SIP信令以如下方式協(xié)商成的:音頻和/或視頻IP流可以被動態(tài)地、適應(yīng)性地添加到可通過如RFB之類的瘦客戶端協(xié)議機制來呈現(xiàn)其關(guān)聯(lián)IP流的遠(yuǎn)程桌面控制的SIP會話。
[0071]下面的描述提供了提供SDP中的瘦客戶端會話的描述所需的擴展的語法和語義。
[0072]根據(jù)SDP[IETF RFC4566]，SDP中的連接數(shù)據(jù)線具有下面的語法:
[0073]c=<nettype><addrtype><connection-address>
[0074]其中，〈nettype〉指示網(wǎng)絡(luò)類型，〈addrtype〉指示地址類型，并且〈connection_address>是依賴于地址類型的連接地址。
[0075]基本地，SDP公告由會話級部分及其后的一個或多個媒體級部分構(gòu)成，如SDP [IETFRFC2327]中描述的。會話級信息提供默認(rèn)值，因此如果連接數(shù)據(jù)線存在于會話級，則其適用于媒體級部分，除非連接數(shù)據(jù)線在媒體描述中被傳達(dá)。注意，如果連接數(shù)據(jù)線存在于所有媒體中，則其不需要在會話級中。
[0076]媒體描述開始于“m=”行，并且繼續(xù)到下一媒體描述或者整個媒體描述的末尾。在IETF RFC4566中定義的“m=”媒體行如下
[0077]m=<media><port><transport><fmt list>
[0078]其中，〈media〉是媒體類型，〈port〉是媒體流將被發(fā)送到的傳輸端口，〈transport〉是其值取決于“c=”字段的傳輸協(xié)議,并且〈fmt list〉表示媒體格式。對于音頻和視頻，媒體格式通常是媒體有效載荷類型，如RTP音頻/視頻簡檔中定義的。
[0079]此時，媒體類型針對音頻、視頻、應(yīng)用、數(shù)據(jù)和控制而被定義。
[0080]瘦客戶端媒體類型
[0081]首先，我們考慮遠(yuǎn)程幀緩沖器(RFB)協(xié)議，其可用來控制顯示更新并且可應(yīng)用各種編碼。
[0082]媒體類型可以專用于瘦客戶端技術(shù)。媒體類型可以是“application / rfb”、“application / T120”。
[0083]m=application<port><transport>RFB
[0084]此外，我們關(guān)注本文獻(xiàn)中的遠(yuǎn)程幀緩沖器協(xié)議。
[0085]瘦客戶端事件媒體類型
[0086]除了遠(yuǎn)程顯示的圖形更新之外，還可以建立用于上行鏈路事件的特定連接。為此，媒體類型“application / control-events”被定義并且媒體行為m=application<port><transport>控制事件.RFB特定屬性。屬性版本“v=”必須被給出并且其是指RFB協(xié)議版本號。
[0087]a=V:<version_number>
[0088]其中，version_number可以是意味著RFB協(xié)議版本3.8適用的“3.8”。[0089]編碼方案屬性為這樣的形式:
[0090]a=encoding-scheme:<encoding scheme value>
[0091]其中，〈encodingscheme value〉可以為 “RAW”、“C0PYRECT，，、“RRE，，、“HEXTILE，，、“ZLRE”、“CURSOR”、“CORRE”、“ZLIB.. 。
[0092]顯示編號也可以被指定。如果未被指示，則默認(rèn)端口被分配。實際上，RFB服務(wù)器默認(rèn)端口號通常等于(5900+display number),其中，display通常在產(chǎn)生6種可能的顯示連接的從O到6的范圍中。
[0093]顯示nu屬m性be為r這樣的形式:
[0094]a=dpy: <di spIay_number>
[0095]在RFB協(xié)議的情況中，提供了下面的附加屬性。
[0096]客戶端可以指示會話是否被共享。如果未指示，則會話不準(zhǔn)被共享。
[0097]a=shared
[0098]服務(wù)器必須指示幀緩沖器大小:
[0099]a=framebuff-w:<the width value〉
[0100]a=framebuff-h:<the height value〉
[0101]客戶端可以指示下面的屬性作為偏好，并且服務(wù)器必須指示這些屬性。
[0102]O a=pixformat-bpp:〈bit-per_pixel value>
[0103]O a=depth:<depth value〉
[0104]〇 a=big-endian
[0105]〇 a=true-color
[0106]〇 a=red_max:〈red_max value>
[0107]〇 a=green_max:〈green_max value>
[0108]〇 a=blue_max:〈blue_max value〉
[0109]〇 a=red-shift:<red-shift value〉
[0110]〇 a=green_shift:〈green_shift value>
[0111]〇a=blue_shift:〈blue_shift value〉
[0112]出于互操作性考慮，除了握手消息和初始化消息由SDP提出/應(yīng)答消息取代之外，與前面的這些屬性的理解有關(guān)的客戶端和服務(wù)器行為與在RFB規(guī)范3.8中規(guī)定的相同。
[0113]TC 語義
[0114]接收包含利用TC語義被成組在一起的“m”行的會話描述的查看器應(yīng)用必須顯示并且將遠(yuǎn)程桌面控制協(xié)議(例如，RFB)與如RTP音頻/視頻流之類的相應(yīng)媒體流相關(guān)聯(lián)。
[0115]a=group:TC
[0116]然后，媒體級屬性“a=mid: ”必須被用在術(shù)語群組的每個媒體行中。
[0117]為了適當(dāng)?shù)爻尸F(xiàn)遠(yuǎn)程顯示，與RTP流(例如，用于視頻傳送)相對應(yīng)的(一個或多個)媒體行還指示相對于遠(yuǎn)程顯示幀緩沖器坐標(biāo)和大小的顯示位置。通過該信息，使得瘦客戶端設(shè)備得知應(yīng)當(dāng)呈現(xiàn)遠(yuǎn)程桌面幀緩沖器上的RTP視頻流的位置?？蛻舳艘虼丝梢赃m配幀緩沖器更新策略。更具體地，在幀緩沖器更新由客戶端驅(qū)動的RFB的情況中，輪詢間隔以及遠(yuǎn)程桌面顯示的哪個部分應(yīng)當(dāng)被更新可以被調(diào)節(jié)。
[0118]a=area~x:<x position value>[0119]a=area-y:<y position value>
[0120]a=area_w:〈width value〉
[0121]a=area~h:<height value〉
[0122]其還可以指示win-1d屬性
[0123]a=wind-1d:<window identifier)
[0124]這樣的win-1d在用于遠(yuǎn)程桌面控制的用戶會話內(nèi)必須是唯一的。該id的使用將在下節(jié)中進(jìn)一步說明。
[0125]用于對幀緩沖器的特定于窗口的管理的RFB協(xié)議擴展
[0126]RFB圖形更新策略是客戶端驅(qū)動的畫面更新。在RFB規(guī)范3.8中，客戶端可以請求更新整個畫面的一部分以節(jié)省帶寬。
[0127]通過除了引入幀緩沖器更新外還引入視頻流量的組合，客戶端可以接收視頻并將視頻映射到屏幕的專用部分上去。
[0128]例如，在諸如移動電話之類的有限屏幕設(shè)備中，客戶端可以決定重新調(diào)節(jié)視頻緩沖器大小以適合于整個移動設(shè)備屏幕。在這樣的情況中，客戶端停止更新用于RFB幀緩沖器更新消息的幀緩沖器。我們將該特定幀緩沖器稱為“桌面幀緩沖器”(桌面FB)。
[0129]在另一預(yù)見到的用例中，客戶端接收在專用窗口中打開的媒體播放器的圖形更新。然后，客戶端可以在其設(shè)備上本地地自由移動遠(yuǎn)程桌面幀緩沖器上的視頻，并且可以在用戶請求時將播放器示出或隱藏。此情形中的問題在于窗口移動可能必須被指示給服務(wù)器以進(jìn)行適當(dāng)呈現(xiàn)和屏幕顯示管理，更具體地，如果桌面在多個用戶間被共享的話。例如，第一用戶可以控制該桌面，而其它參與者僅可以看見所述第一用戶產(chǎn)生的動作。
[0130]在實際中，將在分離的幀緩沖器上接收并處理RTP視頻流。通過引入用于將視頻媒體關(guān)聯(lián)到遠(yuǎn)程桌面能力的能力，并且通過添加win-1d信息，客戶端能夠在自由地處理其屏幕上的視頻媒體呈現(xiàn)(執(zhí)行旋轉(zhuǎn)、切換到全屏模式，等等...)的同時仍然被關(guān)聯(lián)到相同用戶會話。Win-1d不一定指窗口，而是還可以指圖形區(qū)域，盡管在實際中可能更容易利用窗口來實現(xiàn)它，更具體地，如果所述窗口有可能被重新調(diào)節(jié)大小或者被移動的話。兩種新的客戶端請求隨后被定義:
[0131]FramebufferForgetRequest (message-type, window-1d, χ-position,y-position, width, height),其告訴服務(wù)器巾貞緩沖器上的特定區(qū)域不需要更新。這在該區(qū)域通過另一媒體流(例如，通過RTP傳輸?shù)腍263編碼視頻)被刷新時可能發(fā)生。
[0132]WindowUpdate(message-type, window-1d, χ-position, y-position, width,height)，其告訴服務(wù)器與在服務(wù)器上打開的窗口(或圖形區(qū)域)相對應(yīng)的所接收的媒體流已被重新調(diào)節(jié)大小、已被移動，或者這兩者。
[0133]如果不存在窗口 -1d時，S卩，如果未接收到與窗口相對應(yīng)的獨立媒體流時，這些客戶端請求不準(zhǔn)被使用。
[0134]這還需要服務(wù)器發(fā)送屬性“a=win-1d”來指示所接收的媒體流是否與服務(wù)器上的窗口相匹配。如果不匹配，則win-1d屬性被設(shè)置為零，并且如果屬性不存在，則客戶端不準(zhǔn)將媒體流關(guān)聯(lián)到窗口。
[0135]當(dāng)媒體流不與遠(yuǎn)程服務(wù)器上的任何窗口相關(guān)時，客戶端不準(zhǔn)重新調(diào)節(jié)幀緩沖器上的媒體的大小或者移動它，因此WindowUpdate不準(zhǔn)被使用。然而，在輪詢模型(或者客戶端驅(qū)動的巾貞緩沖器更新)中，客戶端可以使用FramebufferForgetRequest消息以便通知服務(wù)器不更新在請求中指定的區(qū)域。然而，在推送模型中，這可能不需要，因為服務(wù)器應(yīng)當(dāng)已經(jīng)知道該區(qū)域利用另一協(xié)議或編碼被更新。
[0136]當(dāng)媒體流與遠(yuǎn)程服務(wù)器上的窗口有關(guān)時，上面的客戶端請求(FramebufferForgetRequest和WindowUpdate)被用來更新遠(yuǎn)程服務(wù)器上的窗口的位置。FramebufferForgetRequest中的窗口 _id信息使得客戶端能夠修改服務(wù)器將不針對其發(fā)送任何幀緩沖器更新的區(qū)域指示。
[0137]圖2圖示出瘦客戶端查看器，其呈現(xiàn)出由可動態(tài)地進(jìn)行適配的若干個區(qū)域構(gòu)成的遠(yuǎn)程應(yīng)用顯示(遠(yuǎn)程桌面)。區(qū)域A是基于RFB協(xié)議在圖形上被更新的遠(yuǎn)程桌面的背景。其它區(qū)域依賴于區(qū)域A，例如，區(qū)域B被圖示出。
[0138]區(qū)域B是屏幕中相對于區(qū)域A(x，Y基礎(chǔ)坐標(biāo))位于(x，y)位置處的區(qū)域。還可通過寬度(w)和高度(h)尺寸來表征它。圖形輸出通過實時協(xié)議(RTP)被流傳輸并且例如利用H263編解碼器被編碼。
[0139]區(qū)域B上的任何用戶交互因此可以被關(guān)聯(lián)到遠(yuǎn)程桌面(背景)，并且來自區(qū)域B的指針事件可被發(fā)送給遠(yuǎn)程服務(wù)器，就像它們在區(qū)域A上被執(zhí)行似的。當(dāng)區(qū)域B在瘦客戶端設(shè)備的屏幕上本地地被重新調(diào)節(jié)大小或者被移動時，這可以被使用，而不必觸發(fā)服務(wù)器處的窗口大小重新調(diào)節(jié)和移動。
[0140]圖3圖示出作為瘦客戶端設(shè)備的UE2與作為瘦客戶端服務(wù)器4的遠(yuǎn)程桌面PC之間的瘦客戶端連接建立。
[0141]UE2通過用于通信的IP接入網(wǎng)絡(luò)與遠(yuǎn)程桌面PC4連接，并且發(fā)起包括瘦客戶端參數(shù)的SDP提出/應(yīng)答，瘦客戶端參數(shù)包括圖形編碼方案、傳輸設(shè)置(RFB(遠(yuǎn)程幀緩沖器)、RDP (遠(yuǎn)程桌面協(xié)議)、ICA (獨立計算體系結(jié)構(gòu)協(xié)議)、或像素/ RTP (實時傳輸協(xié)議)、IP地址和端口號)以及無線電載體設(shè)置(分組交換或電路交換連接)。
[0142]在步驟20，UE2向桌面4發(fā)送SDP提出，該SDP提出包含瘦客戶端會話屬性并且還包含適當(dāng)SIP會話建立所需的參數(shù)。
[0143]當(dāng)接收到所述SDP提出時，桌面4判定UE2希望利用RFB協(xié)議建立瘦客戶端連接，基于UE2所在的環(huán)境判定RFB協(xié)議和所提出的屬性是可接受的，并且在步驟22，發(fā)送回指示RFB和屬性被選擇的SDP應(yīng)答消息。
[0144]UE2和桌面4同意傳送圖形更新和事件的方向。另外，它們識別出瘦客戶端連接與它們之間正在進(jìn)行的會話相關(guān)。
[0145]當(dāng)在兩側(cè)上同意了瘦客戶端連接參數(shù)之后，桌面4在步驟24中向UE2發(fā)送圖形更新消息，而所述UE2在步驟26中向桌面4發(fā)送上行鏈路鍵和指針事件。
[0146]桌面4可以拒絕連接并且由此可以將與圖形或事件流相對應(yīng)的端口號設(shè)為零，如在IETF RFC3264中規(guī)定的。
[0147]如果一些瘦客戶端參數(shù)不為桌面4所知，則后者默默地忽略這些參數(shù)，如IETFRFC4566中規(guī)定的。
[0148]在步驟28，UE2和桌面4交換RFB媒體和事件。
[0149]在步驟30，用戶打開媒體播放器以觀看視頻并且桌面4發(fā)送第二 SDP提出，UE2可以或可以不接受該第二 SDP提出。實際上，桌面4希望例如通過RTP來發(fā)送視頻，并且通過包括視頻參數(shù)信息的新的SDP提出來觸發(fā)重新協(xié)商。由于視頻輸出由桌面媒體播放器應(yīng)用生成，因此瘦客戶端會話標(biāo)識符和圖形位置信息被給出，以使得UE2可以在正確的位置處顯示視頻流。因此，視頻流被組合到正在進(jìn)行的瘦客戶端會話中。
[0150]在步驟32，UE2確認(rèn)該提出，并且發(fā)送回應(yīng)答。桌面4適配顯示更新以使得視頻被流傳輸?shù)膮^(qū)域不經(jīng)由瘦客戶端協(xié)議被更新。
[0151]圖4圖示出根據(jù)本示例性實施例的方法在應(yīng)用顯示重定向中的使用。
[0152]例如當(dāng)用戶決定將其在移動UE2上接收的視頻重定向到TV40時，該情形可能發(fā)生，TV40被SIP連接在服務(wù)器處，例如在機頂盒或任何其它后端SIP服務(wù)器處并且可經(jīng)由其公共地址被達(dá)到。
[0153]在此情況中，在步驟42，UE2通過用于與遠(yuǎn)程桌面PC4通信的IP接入網(wǎng)絡(luò)連接到遠(yuǎn)程桌面4。這也與圖3中的步驟20、22、24、26和28有關(guān)。
[0154]UE2通過發(fā)送鍵和鼠標(biāo)事件來與桌面交互。在一時刻時，用戶打開媒體播放器并且決定播放視頻。
[0155]在步驟44，桌面4發(fā)送SDP提出/應(yīng)答以使得能夠流傳輸視頻。該決定基于本地策略和情報(intelligence)以及本地服務(wù)器接口實施方式。在第一實施例中，這隱含了駐留在服務(wù)器上的應(yīng)用向瘦客戶端服務(wù)器模塊請求特定媒體傳輸手段(我們稱這為應(yīng)用知道的媒體傳送適配)。在第二實施例中，這隱含了瘦客戶端服務(wù)器模塊自治地選最適當(dāng)?shù)膫魉褪侄巍?br> [0156]當(dāng)接收到該請求時，UE2在步驟46中發(fā)送回用于接受或拒絕該視頻流的應(yīng)答。在此典型示例中，UE2支持重定向特征。用戶經(jīng)由UE2用戶界面選擇重定向選項并且選擇將視頻重定向到TV40。假設(shè)移動電話知道其TV SIP公共地址或IP地址。這意味著瘦客戶端設(shè)備提供了用于向用戶通知是接受該媒體流還是將其定向至另一設(shè)備的用戶界面。應(yīng)答消息包含TV的地址以及針對其請求了重定向的應(yīng)用的ID，例如以重定向web瀏覽器顯示。
[0157]在此情況中，重定向是指應(yīng)用(其可以是web瀏覽器、即時消息傳輸應(yīng)用、視頻)的顯示重定向。
[0158]桌面4接收該消息，解釋該消息并且準(zhǔn)備將媒體重定向到TV40。沒有屏幕更新(與視頻輸出所位于的區(qū)域相對應(yīng)的)被發(fā)送給UE2。這需要應(yīng)答消息包括關(guān)于輸出流是否仍然被流傳輸?shù)揭苿釉O(shè)備的指示。
[0159]如果支持SIP，則TV40通過SIP接著進(jìn)行媒體協(xié)商。桌面4可以經(jīng)由其它手段來協(xié)商視頻傳送。
[0160]在步驟48，桌面4將SDP提出發(fā)送給TV40。
[0161]在步驟50，SDP提出被TV接受，該TV發(fā)送回SDP應(yīng)答。
[0162]在步驟52，UE2被通知TV40接受了該重定向。
[0163]最后，在步驟54，視頻被顯示在TV屏幕40上。用戶可以利用遠(yuǎn)程桌面控制裝置繼續(xù)與遠(yuǎn)程桌面4交互。
[0164]在上面的示例中，TV40優(yōu)選地被SIP連接在服務(wù)器處，例如機頂盒或任何其它后端SIP服務(wù)器處，并且可經(jīng)由其公共地址被達(dá)到。
[0165]盡管已參考本發(fā)明的示例性實施例具體地示出和描述了本發(fā)明，然而本發(fā)明不限于這些實施例。本領(lǐng)域技術(shù)人員將明白，在不脫離如權(quán)利要求所限定的本發(fā)明的精神和范圍的情況下，可以對其在形式和細(xì)節(jié)上作出各種改變。
[0166]〈引用結(jié)合〉
[0167]本申請基于2008年10月8日提交的歐洲專利申請N0.EP08166122.5并要求其優(yōu)先權(quán)，該申請的公開通過引用被整體結(jié)合于此。
[0168]標(biāo)號列表
[0169]2移動用戶設(shè)備
[0170]4瘦客戶端服務(wù)器
[0171]6 MS核心系統(tǒng)
[0172]8策略決定功能模塊(PDF)
[0173]10 3GPP分組交換(PS)核心網(wǎng)絡(luò)
[0174]40 TV
【權(quán)利要求】
1.一種用于在瘦客戶端設(shè)備與瘦客戶端服務(wù)器之間建立瘦客戶端會話的方法，所述瘦客戶端設(shè)備和所述瘦客戶端服務(wù)器在基于SIP的架構(gòu)之上的會話協(xié)商期間交換握手消息和初始化消息，其中，所述瘦客戶端設(shè)備和所述瘦客戶端服務(wù)器交換表示瘦客戶端上下文的附加信息，所述瘦客戶端上下文使得能夠在所述瘦客戶端會話期間組合和適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流。
2.根據(jù)權(quán)利要求1所述的方法，其中，所述附加信息包括按照SDP(會話描述協(xié)議)提出/應(yīng)答消息被格式化的瘦客戶端信息。
3.根據(jù)權(quán)利要求1所述的方法，其中，所述附加信息包括按照嵌入在SIP消息的主體中的基于XML的提出/應(yīng)答消息被格式化的瘦客戶端信息。
4.根據(jù)權(quán)利要求2或權(quán)利要求3所述的方法，其中，所述附加信息包括多媒體傳送能力和遠(yuǎn)程桌面控制能力兩者。
5.根據(jù)權(quán)利要求4所述的方法，其中，所述遠(yuǎn)程桌面控制能力還包括動態(tài)地將遠(yuǎn)程應(yīng)用的圖形更新從第一設(shè)備定向或重定向到第二設(shè)備上去。
6.根據(jù)權(quán)利要求5所述的方法，其中，所述第一設(shè)備是移動通信設(shè)備并且所述第二設(shè)備是固定通信設(shè)備。
7.根據(jù)權(quán)利要求6所述的方法，包括:在與用于下行鏈路圖形更新的無線電載體不同的無線電載體上傳送上行鏈路事件。
8.根據(jù)權(quán)利要求7所述的方法，包括:在與用于下行鏈路圖形更新的IP連接不同的IP連接上傳送上行鏈路事件 。
9.根據(jù)權(quán)利要求1所述的方法，包括:將至少一個音頻/視頻流關(guān)聯(lián)到所述瘦客戶端會話。
10.根據(jù)權(quán)利要求8所述的方法，其中，所述附加信息包括與被關(guān)聯(lián)到所述瘦客戶端會話的所述音頻/視頻流相對應(yīng)的遠(yuǎn)程顯示幀緩沖器坐標(biāo)和大小。
11.根據(jù)權(quán)利要求9所述的方法，其中，所述附加信息允許發(fā)送向所述服務(wù)器指示幀緩沖器上的特定區(qū)域不需要更新的客戶端請求(FramebufferForgetRequest)。
12.根據(jù)權(quán)利要求11所述的方法，其中，所述附加信息包括窗口-1d屬性。
13.根據(jù)權(quán)利要求12所述的方法，其中，所述附加信息允許發(fā)送向服務(wù)器指示由所述窗口 -1d屬性標(biāo)識的圖形區(qū)域已被重新調(diào)節(jié)大小、已被移動或者這兩者的客戶端請求(WindowUpdate)。
14.一種瘦客戶端設(shè)備，適于實現(xiàn)根據(jù)權(quán)利要求1所述的用于建立與瘦客戶端服務(wù)器的瘦客戶端會話的方法，所述瘦客戶端設(shè)備包括用于與所述瘦客戶端服務(wù)器交換表示瘦客戶端上下文的附加信息的裝置，所述瘦客戶端上下文使得能夠在所述瘦客戶端會話期間組合和適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流，所述附加信息包括SDP(會話描述協(xié)議)提出/應(yīng)答消息或者被嵌入在SIP消息的主體中的基于XML的提出/應(yīng)答消肩、O
15.根據(jù)權(quán)利要求14所述的瘦客戶端設(shè)備，包括移動用戶設(shè)備，所述移動用戶設(shè)備包括用于使得用戶能夠登記對媒體重定向的興趣的接口，以便在接收到所述媒體重定向時被通知，并且發(fā)送重定向應(yīng)答。
16.根據(jù)權(quán)利要求14所述的瘦客戶端設(shè)備，適于建立用于上行鏈路事件的單獨的IP連接，以用于觸發(fā)將單獨的無線電載體分配用于在與用于下行鏈路圖形更新的無線電載體不同的無線電載體上傳送所述上行鏈路事件，并且適于將(一個或多個)音頻/視頻流的呈現(xiàn)映射到其屏幕上的所述遠(yuǎn)程顯示幀緩沖器。
17.一種瘦客戶端服務(wù)器，適于實現(xiàn)根據(jù)權(quán)利要求1所述的用于建立與瘦客戶端設(shè)備的瘦客 戶端會話的方法，所述瘦客戶端服務(wù)器包括用于與所述瘦客戶端設(shè)備交換表示瘦客戶端上下文的附加信息的裝置，所述瘦客戶端上下文使得能夠在所述瘦客戶端會話期間組合和適應(yīng)性地傳送至少一個遠(yuǎn)程應(yīng)用顯示中的多個媒體流。
【文檔編號】H04L29/06GK103546457SQ201310438068
【公開日】2014年1月29日 申請日期:2009年9月18日 優(yōu)先權(quán)日:2008年10月8日
【發(fā)明者】弗雷德里克·阿·純·弗克, 本諾特·萊卡洛特 申請人:日本電氣株式會社