一組預先定義的特征。SIP允許會話的終端對這些特征進行協(xié)商。舉例來說，視頻通話要求這些終端協(xié)商彼此音頻流及視像流的特征，如編解碼器的類別及視像的幀率。
[0060]一個用戶(應用程序)的會話(如視頻電話，實時通訊對話)可能由一個或多個SIP會話所組成。就語音電話來說，用戶(應用程序)的會話即與SIP會話重疊。當SIP會話結(jié)束時，電話也即結(jié)束。就即時消息來說，用戶(應用程序)的會話可能由多個相繼且可能彼此重疊的SIP會話所組成
[0061]圖1說明應用程序110如何于不同的終端A及終端B間互相通訊的模型100。每個終端A及B包含應用程序110、SIP協(xié)議棧120及互聯(lián)網(wǎng)通訊協(xié)議(Internet Protocol,IP)棧130。兩個應用程序110是利用管理下層IP連線150的SIP會話140來彼此通訊。
[0062]導管
[0063]應用程序之間的通訊常被稱作用戶或應用程序會話。為能區(qū)分用戶會話及SIP會話的差異，導入以終端間的虛擬用戶(應用程序)會話作為導管的概念。
[0064]圖2說明導管260如何在兩個相異終端A及B的應用程序210之間提供通訊接口的模型200。每個終端A及B包含應用程序210、SIP協(xié)議棧220和IP協(xié)議棧230。導管260可管理SIP會話240，而SIP會話240則管理下層的IP連線250。
[0065]導管可管理兩個特定應用程序之間的通訊。舉例來說，語音電話導管管理兩個語音電話應用程序間的通訊。為使每個終端接收導管以得知所對應的應用程序，每個導管包含可用以辨識所對應的應用程序的信息。這筆信息將通過SIP在導管的兩個終端間傳送。
[0066]利用SIP來傳送這筆信息有以下的幾種方式:
[0067]1.修改SIP的標頭中已有的內(nèi)容元素。
[0068]2.新增SIP的標頭中的新內(nèi)容元素。
[0069]3.在SIP中新增新方法函數(shù)。
[0070]4.新增新內(nèi)容元素到由SIP所協(xié)商的復數(shù)個會話描述協(xié)議(Sess1nDescript1n Protocol, SDP)參數(shù)。
[0071]5.修改已有的SDP參數(shù)。
[0072]上述第1-5項的任一方法皆可提供必要的應用程序信息。然而，較佳的選擇仍是無須對SIP協(xié)議棧或其使用方法做出重大改變的作法。對于已有協(xié)議和應用程序僅需最少量修改的作法是修改已有的SDP參數(shù)。這個做法無須對SIP協(xié)議?；蚱渑cSDP參數(shù)協(xié)商的方式做出任何修改，詳細的做法將在稍后說明。
[0073]利用導管來完成RCS數(shù)據(jù)交流
[0074]RCS應用程序所用的數(shù)據(jù)交流可被分為下面幾種類別:
[0075]1.實時的數(shù)據(jù)流
[0076]2.短訊息
[0077]3.數(shù)據(jù)傳輸
[0078]此外，RCS定義了兩種數(shù)據(jù)流的類型:音頻流及視像流。
[0079]交流類型形成了 RCS中的幾種核心應用程序:
[0080]1.利用實時音頻流的語音電話。
[0081]2.利用實時音頻流及實時視像流的視頻電話。
[0082]3.利用短訊息和文件傳輸?shù)亩绦磐ㄈ喊l(fā)系統(tǒng)(Short Message Service，SMS)和即時消息。
[0083]4.利用文件傳輸?shù)奈募鬏敗?br>[0084]5.利用實時視像流及文件傳輸?shù)膬?nèi)容共享。
[0085]這些數(shù)據(jù)交流一般可組合到應用程序之中。舉例來說，音頻流及視像流可由一個電話管理應用程序來管理。在終端上管理數(shù)據(jù)交流的應用程序可利用導管來與在另一個終端上的應用程序相溝通。
[0086]導管可被延伸用來處理新的應用程序及新的數(shù)據(jù)類型，如以下所說明。
[0087]用于新應用程序的延伸導管
[0088]根據(jù)現(xiàn)今RCS應用程序的作法，應用程序會由其應用程序所使用的數(shù)據(jù)類性來定義。根據(jù)這樣的做法，音頻流及視像流皆會由同一個電話管理應用程序所管理。如同對電話管理程序所做的說明，短文字訊息也將由訊息應用程序來處理。
[0089]這個做法的一個問題是新的應用程序無法使用已有應用程序已經(jīng)在使用的數(shù)據(jù)交流。舉例來說，一個西洋棋應用程序使用短訊息來溝通彼此的移動。在現(xiàn)在的模型下，新的應用程序必須建立自己的協(xié)議及其自己的新數(shù)據(jù)類型，并分別向RCS服務器注冊。另外的作法則是這個新的應用程序必須得到已有的訊息應用程序的信任以將所有的訊息與既存的訊息應用程序分享，并使所有其他的應用程序能完全的存取SIP。這兩個做法的限制已在先前的段落中被提及。
[0090]通過使用導管，不同的應用程序可以安全地共享相同的數(shù)據(jù)交流。在必要時，甚至可以加入新的數(shù)據(jù)交流類型。下面的段落將說明如何新增新的應用程序。
[0091 ] 使用已有數(shù)據(jù)交流類型的新應用程序
[0092]新的應用程序可以通過建立不同的導管來共享相同類型的數(shù)據(jù)交流。舉里來說，西洋棋的游戲可建立一個特定的IM導管。為使導管的兩端都可得知其所對應的應用程序，導管的底層協(xié)議必須能傳達其所對應應用程序。
[0093]如上所述，一個傳達導管所對應的應用程序的較佳作法是使用SIP邀請函中SDP會話的已有欄位:會話名稱。雖然會話名稱是一個主要欄位，但在現(xiàn)行的SIP會話的SDP參數(shù)協(xié)商中并未被使用到。已有的應用程序，如語音/視頻電話，即時消息…等，可依現(xiàn)行的作法來設定會話名稱:加入一個空白格以填入會話名稱。新應用程序可以利用用來執(zhí)行可行事項交換的標記來設定會話名稱。如此標記SIP會話，導管即可將SIP會話數(shù)據(jù)導引到所對應的應用程序。
[0094]RCS中已有用以交換可行事項的規(guī)范。為使不同的應用程序可以共享媒體類型，這里提出可用以提示會話與特定應用程序相關(guān)聯(lián)的作法。即可以通過以會話名稱辨識所對應的應用程序來完成。
[0095]下面的例子是通過新增會話名稱來辨識西洋棋應用程序以延伸媒體部分。
[0096]s = chess_applicat1n_tag
[0097]m = aud1 49170 RTP/AVP O
[0098]m = message 9 TCP/MSRP*
[0099]如果應用程序有新的數(shù)據(jù)流類型，即可利用媒體部分來新增新的數(shù)據(jù)流類型，如下所示:
[0100]s = my_game_tag
[0101]m = aud1 49170 RTP/AVP O
[0102]m = game, stream 51002 RTP/GP 0
[0103]此作法將由下面的例子來說明。
[0104]應用程序的設計人員希望能新增新的西洋棋游戲，并通過簡單的短訊息來傳達兩個玩家的在西洋棋盤上的移動。由頂及SMS訊息應用程序所使用的短訊息可用來傳達西洋棋的移動。然而西洋棋的移動不應出現(xiàn)在訊息應用程序當中。以下將說明這可以通過為西洋棋應用程序建立新的導管來完成。
[0105]當一個用戶想要向另一個特定的用戶發(fā)起西洋棋會話時，應用程序可為西洋棋游戲要求一個新的導管。協(xié)議引擎可以根據(jù)GSMA RCS-e的規(guī)范檢查用戶終端是否可支持西洋棋的可行事項。如果遠程終端可以支持西洋棋的可行事項，協(xié)議引擎會發(fā)起一個SIP會話。而SDP的描述中則提供了用以描述SIP會話是對應于西洋棋應用程序的會話名稱。
[0106]遠程終端會接收西洋棋應用程序的SIP邀請及SDP會話名稱。遠程終端上的協(xié)議引擎會通知收聽中的應用程序，表示已接收到西洋棋導管。西洋棋應用程序接收到通知。用戶可以決定是否接受新導管。如果用戶接受導管，應用程序即可利用短訊息來開始游戲。由于這些訊息都是專屬于西洋棋游戲，因此不會出現(xiàn)在訊息應用程序中。
[0107]西洋棋應用程序的概念可以更加地延伸到支持兩個終端間的聲音對談。而這只需要在導管當中新增聲音媒體即可。底層的協(xié)議引擎將可就語音電話進行協(xié)商。由于語音電話已經(jīng)由核心的RCS應用程序所支持，導管中的聲音引擎可利用完全相同于聲音電話的方式來管理。
[0108]利用上述使用導管的方法，即可滿足上述所有第三方應用程序所需的條件。相對的，GSMA工作團隊的提案則僅能滿足上述的第I項條件。
[0109]安卓(Android)操作系統(tǒng)的先前版本提供了在一個在不同應用程序間共享訊息的方法:排序廣播法。為使用排序廣播法，每一個應用程序會注冊一個聽取特定廣播消息對象(Intent)的要求排序。當訊息對象中有可讀取的訊息時，每個應用程序會根據(jù)其要求排序被先后通知。任何一個在此排序中的應用程序都可以使用這個訊息，并可以防止要求排序較低的應用程序接收到此訊息。然而這卻成為了致命的安全性弱點。這個弱點已在安卓4.4 (Kit Kat)中被修正為僅允許一個應用程序接收SMS訊息，而用戶可以選擇由哪一個應用程序來接收SMS訊息。隨著安卓作業(yè)系統(tǒng)的更新，不同的應用程序已無法再共享訊息。
[0110]以下以西洋棋游戲的例子說明導管協(xié)商成功及導管協(xié)商失敗的兩種流程。以下的應用程序流程是以兩個客戶端彼此相連并可互認為前提。
[0111]成功的會談協(xié)商
[0112]圖3為說明應用程序由一終端發(fā)起會話到另一終端會談流程圖，并包含對