網(wǎng)頁實時通信中采用基于WebSocket協(xié)議的雙向REST的方法與服務(wù)器的制造方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及通信技術(shù)領(lǐng)域,尤其涉及一種用于在網(wǎng)頁實時通信(Web Real-TimeCommunicat1n)中米用基于 WebSocket 協(xié)議的雙向 REST (Representat1nal StateTransfer,表述性狀態(tài)轉(zhuǎn)移)的技術(shù)。
【背景技術(shù)】
[0002]基于網(wǎng)絡(luò)的瀏覽器的通信服務(wù)，如，通過語音視頻的對等通信，由于諸如在線購物、facebook等網(wǎng)絡(luò)服務(wù)的日益增長的需求的驅(qū)動，在最近幾年發(fā)展迅速。
[0003]即使在瀏覽器端定義有很多技術(shù)和標(biāo)準(zhǔn)，在瀏覽器和核心網(wǎng)絡(luò)(如，頂S，即，IPMultimedia Subsystem, IP多媒體子系統(tǒng))間的控制接口還沒有一個滿意的信令協(xié)議。
[0004]WebRTC(Web Real-Time Communicat1n,網(wǎng)頁實時通信)為網(wǎng)頁瀏覽器/客戶端提供一組通用的功能，以促進開發(fā)的簡易性和互操作性。在RFC 6455中定義的WebSocket，是基礎(chǔ)信令協(xié)議，以攜帶應(yīng)用消息。其提供了全雙工傳輸長連接，并在WebRTC的HTML5中被定義，以替代HTTP來支持網(wǎng)絡(luò)的實時通信。WebRTC的WebSocket上的應(yīng)用消息協(xié)議是一個開放的選擇，其可以是SIP(Sess1n Initiat1n Protocol,會話初始協(xié)議)或任何其他可以滿足需求的協(xié)議。
[0005]WebSocket上的SIP是一種選擇。SIP已經(jīng)作為控制信令廣泛應(yīng)用于通信網(wǎng)絡(luò)。其可靠性、交互能力和可擴展性已經(jīng)被證實。如果服務(wù)提供者的目的在于在瀏覽器端復(fù)制一個等同于傳統(tǒng)客戶端的全面的頂S客戶端，那么，WebSocket上的SIP仍然是為實現(xiàn)該功能的合適的方法；然而，如果目的在于提供API以開放給網(wǎng)頁開發(fā)者，則有多個方法更優(yōu)于SIPo 一種可選的方法是基于REST的方法。
[0006]因其簡單、無狀態(tài)性及可擴展，REST在互聯(lián)網(wǎng)很流行。其已被用于網(wǎng)頁服務(wù)器，并在由OMA(Open Mobile Alliance,開放移動聯(lián)盟)定義的第三方電信呼叫控制中被應(yīng)用。
[0007]HTTP的REST已被廣泛的部署。但其具有延遲，控制信令冗余度高，以及工作效率低等問題。
[0008]WebSocket 上的單向 REST，如 SwaggerSocket，由 HTTP 的 REST 進化而來。主要的改變是將HTTP替換為WebSocket。然而，其不能充分利用WebSocket的全雙工特性，仍舊工作在單向模式。因此其仍然有延遲問題。
[0009]REST的延遲問題在于，為了接收響應(yīng)消息，瀏覽器端不得不進行長輪詢，其具有明顯的弊端，我們將在如下部分進行詳細(xì)討論。因此，本發(fā)明的目的在于，支持WebSocket的雙向REST，其通過使用WebSocket的全雙工特性，并且減少控制信令冗余，提高工作效率。

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

[0010]本發(fā)明的目的是提供一種在網(wǎng)頁實時通信中采用基于WebSocket協(xié)議的雙向REST的方法與服務(wù)器。
[0011]根據(jù)本發(fā)明的一個方面，提供了一種在網(wǎng)頁實時通信中米用基于WebSocket協(xié)議的雙向REST的方法，其中，該方法包括以下步驟:
[0012]a在網(wǎng)頁實時通信中，服務(wù)器采用基于WebSocket協(xié)議的雙向REST，向?qū)?yīng)的瀏覽器/客戶端發(fā)送事件通知請求；
[0013]b所述瀏覽器/客戶端根據(jù)所述事件通知請求，向所述服務(wù)器發(fā)送事件通知響應(yīng)。
[0014]優(yōu)選地，所述網(wǎng)頁實時通信包括所述瀏覽器/客戶端發(fā)起呼叫，其中，該方法還包括:
[0015]-所述瀏覽器/客戶端向所述服務(wù)器發(fā)送呼叫會話請求；
[0016]-所述服務(wù)器基于所述呼叫會話請求，向所述瀏覽器/客戶端發(fā)送呼叫會話響應(yīng)；
[0017]其中，所述步驟a包括:
[0018]-所述服務(wù)器采用基于WebSocket協(xié)議的雙向REST，向所述瀏覽器/客戶端發(fā)送事件通知請求，其中，所述事件包括被叫方應(yīng)答事件。
[0019]優(yōu)選地，所述網(wǎng)頁實時通信包括所述瀏覽器/客戶端接收呼入，其中，所述步驟a包括:
[0020]-所述服務(wù)器采用基于WebSocket協(xié)議的雙向REST，向所述瀏覽器/客戶端發(fā)送事件通知請求，其中，所述事件包括呼入事件。
[0021]優(yōu)選地，所述WebSocket協(xié)議包括滿足所述雙向REST的API消息。
[0022]優(yōu)選地，所述服務(wù)器與所述瀏覽器/客戶端之間僅建立一次TCP/HTTP連接。
[0023]根據(jù)本發(fā)明的另一方面，還提供了一種在網(wǎng)頁實時通信中采用基于WebSocket協(xié)議的雙向REST的方法的服務(wù)器，其中，該服務(wù)器包括:
[0024]第一發(fā)送裝置，用于在網(wǎng)頁實時通信中，采用基于WebSocket協(xié)議的雙向REST，向?qū)?yīng)的瀏覽器/客戶端發(fā)送事件通知請求；
[0025]第一接收裝置，用于接收所述瀏覽器/客戶端根據(jù)所述事件通知請求，所發(fā)送的事件通知響應(yīng)。
[0026]優(yōu)選地，所述網(wǎng)頁實時通信包括所述瀏覽器/客戶端發(fā)起呼叫，其中，該服務(wù)器還包括:
[0027]第二接收裝置，用于接收所述瀏覽器/客戶端所發(fā)送的呼叫會話請求；
[0028]第二發(fā)送裝置，用于基于所述呼叫會話請求，向所述瀏覽器/客戶端發(fā)送呼叫會話響應(yīng)；
[0029]其中，所述第一發(fā)送裝置用于:
[0030]-采用基于WebSocket協(xié)議的雙向REST，向所述瀏覽器/客戶端發(fā)送事件通知請求，其中，所述事件包括被叫方應(yīng)答事件。
[0031]優(yōu)選地，所述網(wǎng)頁實時通信包括所述瀏覽器/客戶端接收呼入，其中，所述第一發(fā)送裝置用于:
[0032]-采用基于WebSocket協(xié)議的雙向REST，向所述瀏覽器/客戶端發(fā)送事件通知請求，其中，所述事件包括呼入事件。
[0033]優(yōu)選的，所述WebSocket協(xié)議包括滿足所述雙向REST的API消息。
[0034]優(yōu)選地，所述服務(wù)器與所述瀏覽器/客戶端之間僅建立一次TCP/HTTP連接。
[0035]與現(xiàn)有技術(shù)相比，本發(fā)明在網(wǎng)頁實時通信中，服務(wù)器采用基于WebSocket協(xié)議的雙向REST，向?qū)?yīng)的瀏覽器/客戶端發(fā)送事件通知請求；所述瀏覽器/客戶端根據(jù)所述事件通知請求，向所述服務(wù)器發(fā)送事件通知響應(yīng)。本發(fā)明提出了采用基于WebSocket協(xié)議的雙向REST，其是WebRTC應(yīng)用的最合適的控制信令，其輕量級、簡單、全雙工傳輸、實時、低延遲且低成本，由于其是雙向的，意味著瀏覽器/客戶端和服務(wù)器都可以發(fā)送請求，服務(wù)器不用等待瀏覽器/客戶端的請求以往回發(fā)送東西，由于無需長輪詢，減少了延遲，帶寬消耗更低，且消除了額外處理負(fù)擔(dān)。
【附圖說明】
[0036]通過閱讀參照以下附圖所作的對非限制性實施例所作的詳細(xì)描述，本發(fā)明的其它特征、目的和優(yōu)點將會變得更明顯:
[0037]圖1示出現(xiàn)有技術(shù)的一種瀏覽器/客戶端發(fā)起呼叫的示意圖；
[0038]圖2示出現(xiàn)有技術(shù)的一種瀏覽器/客戶端接收呼入的示意圖；
[0039]圖3不出根據(jù)本發(fā)明一個方面的用于在網(wǎng)頁實時通信中米用基于WebSocket協(xié)議的雙向REST的方法流程圖；
[0040]圖4示出根據(jù)本發(fā)明一個優(yōu)選實施例的瀏覽器/客戶端發(fā)起呼叫的示意圖；
[0041]圖5示出根據(jù)本發(fā)明另一個優(yōu)選實施例的瀏覽器/客戶端接收呼入的示意圖；
[0042]圖6 TK出根據(jù)本發(fā)明另一個方面的用于在網(wǎng)頁實時通信中米用基于WebSocket協(xié)議的雙向REST的方法的設(shè)備示意圖。
[0043]附圖中相同或相似的附圖標(biāo)記代表相同或相似的部件。
【具體實施方式】
[0044]下面結(jié)合