用於降低呼叫建立時間的系統和方法

2023-09-09 18:56:45

用於降低呼叫建立時間的系統和方法
【專利摘要】一種用於降低至少兩個設備之間的實時通信的呼叫建立時間的方法。該方法包括：在系統的第一內部伺服器接收來自呼叫者的第一通信，其中該第一通信是推送請求，該推送請求包括發起與被呼叫者的連接的嘗試；經由第一內部伺服器向被呼叫者發送推送通知，其中該第一內部伺服器具有至少兩個接口，其中該至少兩個接口的每一個接口都包含用戶數據報協議(UDP)埠，其中該發送包括：通過第一內部伺服器將被呼叫者能夠連接到的該至少兩個接口的外部UDP(IP，埠)對封裝到推送通知中。
【專利說明】用於降低呼叫建立時間的系統和方法
[0001]相關申請:
[0002]本申請涉及並要求於2012年5月10日提交的申請號為61/645，249、標題為「SECURED WIRELESS SESS1N INITIATE FRAMEWORK」的美國臨時專利申請的優先權。本申請還涉及並要求於2013年3月15日提交的申請號為13/834，152、標題為「SECURED WIRELESSSESS1N INITIATE FRAMEWORK」的美國專利申請的優先權。在此通過引用將上述各申請併入本文。

【背景技術】
[0003]無論是直接點對點(成功穿越NAT)還是經由網絡中繼器(TURN)，當前的技術和方法都依賴於XMPP/TURN/STUM/ICE「超時傳輸(jabber) 」協議(源於即時通訊時代)來連接兩個客戶端以實時通信。更具體地，當前技術包括下列基於超時傳輸的方案:ejabberd(目前流行的基於Erlang的XMPP伺服器方案);0penFire ；Tigase ；libjingle(谷歌的用於p2p 客戶端白勺開源實施方案)；TURN 月艮務器(http: //turnserver.souceforqe.net/) ；STUN月艮務器(http: //sourceforqe.net/proiects/stun/)。無論明種實施方案，當前基於XMPP的技術都遭遇到了連接時間長和往返回合(round-trip)多的問題。
[0004]呼叫者與被呼叫者之間的呼叫建立(連接)時間越長，呼叫者掛斷電話、不耐煩和沮喪的可能性越大。因此，連接時間越快，建立呼叫連接的概率越高。

【專利附圖】

【附圖說明】
[0005]圖1A根據實施例描繪了安全的無線會話發起框架探戈(tango) (「SWIFT」)系統，該系統用於降低在實時通信中的兩個客戶端的連接過程中的連接建立時間。
[0006]圖1B根據實施例描繪了 SWIFT伺服器，該伺服器用於降低在實時通信中的兩個客戶端的連接過程中的連接建立時間。
[0007]圖2根據實施例描繪了用於降低在實時通信中的兩個客戶端的連接過程中的連接建立時間的方法的流程圖。
[0008]圖3A和3B根據實施例描繪了用於降低在實時通信中的兩個客戶端的連接過程中的連接建立時間的方法的流程圖。
[0009]除非具體指出，本說明書中提及的附圖應當被理解為不是按照比例繪製的。

【具體實施方式】
[0010]現將對本技術的實施例進行詳細的引用，在附圖中示出了它們的示例。儘管將會結合不同的實施例對本技術進行描述，但是應當理解的是，它們無意將本技術限制於這些實施例。相反，本技術意在覆蓋包含在由所附權利要求所界定的不同實施例的精神和範圍內的所有的替代、修改和等同。
[0011]此外，在下面的實施例的描述中，闡述了大量具體細節以提供對本技術的透徹理解。但是，可在沒有這些具體細節的情況下實施本技術。在其它情況下，為了避免對所呈現的實施例的各個方面產生不必要的模糊，未對公知的方法、過程、組件和電路進行詳細的描述。
[0012]以下討論將首先描述傳統技術的概述,隨後給出對傳統技術加以改良的各個實施例的簡要描述。接下來討論將會返回到圖1A、圖1B、圖2、圖3A、圖3B的描述，它們根據不同實施例描述了用於降低呼叫建立時間的系統和方法。
[0013]概述
[0014]在兩個客戶端之間建立實時連接時，傳統的基於XMPP的技術的實施方式會遭遇連接時間過長和往返回合過多的問題。例如，用於建立呼叫的傳統協議是序列化的:以連續方式執行步驟，使得客戶端與伺服器之間在建立呼叫連接之前產生許多來回通信。
[0015]呼叫者與被呼叫者之間呼叫建立(連接)時間越長，呼叫者掛斷電話、不耐煩和沮喪的可能性越大。相反，連接時間越快，呼叫者不掛電話和進行呼叫連接的可能性越大。呼叫建立時間對於實際連接的呼叫的百分比是重要因素。
[0016]此外，行動網路可以是不同的網絡類型(例如，3G、wifi)。傳統的會話發起協議需要在呼叫建立過程中對其中一個網絡切換進行重新協商，這會使得客戶感覺在該呼叫中「卡住」。提供了多個用於實現兩個客戶端之間的實時通信的連接的系統和方法的實施例，這種連接明顯更少的連接開銷(例如，往返回合)，因此降減少被「卡住」的感受。
[0017]對照需要分別連接到TURN/STUN和jabber伺服器的傳統技術，實施例使用同一伺服器進行NAT穿越、呼叫建立、流量中轉，從而有助於重新建立呼叫(例如，在2G/wifi切換)並進一步減少客戶端在呼叫建立過程中需要打開和/或控制的連接的數量。
[0018]此外，由於實施例默認包括基於UDP的協議，因此能夠充分利用無線通道。因為蜂窩式網絡上的丟包通常是隨機性的，並且通常是源於無線電幹擾而不是擁塞的指示，因此基於TCP的協議不適宜最大程度地利用蜂窩式網絡上的可用帶寬，這是因為它們將這種丟包解釋為擁擠，並以放棄作為響應。當依賴於大量的往返回合(如對於傳統呼叫建立協議的17個往返回合)建立連接時，將加重這種不良的運行情況。由於我們默認使用UDP，我們能夠使用UDP之上的我們自己的中轉控制，這可避免這種毫無意義的等待並且對蜂窩式網絡上的隨機丟包有更好的抵抗力。因此，我們得到更快的連接速度。此外，當網絡接口獨立地切換(例如，Wifi切換為蜂窩式以及反向切換)時，存在優點:將不得不建立完整的TCP連接以重新建立「客戶端環境」從而使伺服器知道它實際上與之前的連接相同。使用UDP比使用TCP輕量得多，因為每個數據包包含足夠的關於這種環境的信息，使伺服器接收到來自新接口的UDP數據包時立刻執行切換。
[0019]總而言之，這些實施例能夠降低呼叫建立時間。傳統的呼叫建立時間要花費17至大約28個往返回合的時間，並且數據包大多通過TCP連接傳送，這有可能會遭受大量的TCP中轉超時。這些實施例能夠將呼叫建立時間降低到大約3個往返回合的時間，並且默認使用m)P協議。因此，利用更少的往返回合時間和使用UDP協議，通過減少傳統的「jabber連接故障」和其它的XMPP相關的超時(目前，這佔所有呼叫建立嘗試的大約6%)，提升了呼叫建立成功率。
[0020]實施例的詳細描述
[0021]圖1A根據實施例描繪了安全的無線會話啟動框架探戈(tango) ( 「SWIFT」)系統100，該系統用於降低在實時通信中的兩個客戶端的連接過程中的連接建立時間。圖1B根據實施例描繪了 SWIFT伺服器110B。圖2描繪了由SWIFT系統100執行的方法200的流程圖，該方法200用於降低在實時通信中的兩個客戶端的連接過程中的連接建立時間。
[0022]簡單地說，SffIFT系統100包括:服務商105 (SWIFT系統100內部的伺服器)；至少一個SWIFT伺服器110A、110B、110C、IlOn…(「SWIFT伺服器110」，除非另有說明。在下面也將SWIFT伺服器110描述為「第一內部設備110」。SffIFT伺服器110是第一內部設備110的一個示例。在下面的一些實施例中，將服務商105描述為「第二內部設備105」。)
[0023]每個SWIFT伺服器110包括兩個接口。其中一個接口 145為虛擬IP (「VIP」)(內部IP)，而另一個接口 150為外部開放IP。VIP是一個負載平衡示例，它允許IP流量拆分到多個伺服器上。VIP具有IP位址，該地址必須是公眾可得到從而可以使用的。VIP具有至少一個分派給它的真實伺服器，VIP將流量分配給該伺服器。通常，存在多個真實伺服器，VIP將會在它們中傳播流量。
[0024]在一些實施例中，每個接口包括傳輸控制協議(TCP)埠和用戶數據報協議(UDP)埠。
[0025]總的來說，SWIFT伺服器110有助於發起兩個客戶端之間的會話並在它們之間中轉流量(如果需要)。SWIFT伺服器110會保存路由表，該表將用戶名映射到客戶端的特定的UDP IP/埠或TCP套接口。路由表中的每個條目將根據客戶流量更新。如果在60秒內未接收到來自特定TCP套接口或UDP IP埠的數據包，則會將其從路由表中移除。除了該表格，SWIFT伺服器110不保存源自客戶的任何狀態，因此我們將SWIFT伺服器110稱為無狀態伺服器。當SWIFT伺服器110停止或崩潰時，將會通過接收客戶的流量來快速重新生成整個路由表並快速恢復服務。由於該同一無狀態特性，它自然支持客戶端無縫WiFi/3G切換。
[0026]現參照圖1A、圖1B和圖2，在操作222，通過首先向SWIFT伺服器110發送推送請求來嘗試連接SWIFT伺服器110的負載平衡器，呼叫者客戶端115( 「呼叫者115」)發起呼叫。從呼叫者115到被呼叫者120的推送請求包括呼叫者115的帳戶標識。負載平衡器將會將該呼叫定向至其中一個SWIFT伺服器210。DNS任播(anycast)用於在不同負載平衡器(站點)之間尋找適當的站點。
[0027]在操作224，SffIFT伺服器110通過SWIFT伺服器110與服務商105之間的HTTPrestful API將操作222的推送請求發送至服務商105，包括帳戶標識信息。
[0028]在操作226，服務商105將動態配置信息和給被呼叫者120的信息列表發送至SWIFT伺服器110。該動態配置信息基於只針對呼叫者115的設備類型和網絡類型(3G/WiFi)。
[0029]在操作228，SffIFT伺服器110在適當的時機將「快速推送」(一種推送通知)立刻發送至被呼叫者120。如果被呼叫者120已經與SWIFT伺服器110連接，則該快速推送激活被呼叫者120。SWIFT伺服器110將其自身的外部TCP和UDP IP/埠嵌入到發送給被呼叫者120的「快速推送」有效負荷(payload)中。被呼叫者120隨後將能夠連接至該外部IP埠。「快速推送」默認是基於UDP的，因此它會被多次發送給被呼叫者。
[0030]在操作232，與操作228中將快速推送發送給被呼叫者120的同時，服務商105向由第三方或Tango提供的推送服務(例如，由Apple?，Google? (GCM/C2DM), Microsoft?, Tango?提供的推送服務)發送推送請求並且隨後推送通知被發送給被呼叫者120從而激活被呼叫者120。與「快速推送」相同，該推送通知將包含SWIFT伺服器110 的 TCP 和 UDP IP/埠。
[0031 ] 值得注意的是，在一個實施例中，在操作226 (其中服務商105向SWIFT伺服器110發送推送通知)後，操作228的快速推送與操作232的第三方通知推送是同時發生的。操作228的快速推送通知比操作232的第三方推送通知更快到達被呼叫者120。在另一個實施例中，在操作232，服務商105向多個設備發送推送通知。
[0032]此外，在操作236，SWIFT伺服器110向呼叫者115發送推送響應，其中將被呼叫者220的信息及其動態配置發送給呼叫者115。
[0033]在操作238，(通過操作228或者操作232)被呼叫者120已接收到包含SWIFT伺服器110的準確UDP和TCP IP/埠的推送通知，並且向SWIFT伺服器110發送「連接」信息。在某些1S和Winphone情況下，還包含由被呼叫者120設置的「接受標記」以表示120將會接受呼叫者115的通信。在某些情況下，被呼叫者120通過他的呼叫設備(例如，Android、PC)上的顯示屏來指示出他對預期通信的接受，因此「接受」信息將被單獨發送。
[0034]在操作240，SffIFT伺服器110向服務商105發送有關被呼叫者120的信息(例如，所使用的網絡接口)並向服務商105查詢用於呼叫者115和被呼叫者120之間的視頻/音頻/網絡速率控制的最佳算法。值得注意的是，服務商105已經具有了在操作224採集的呼叫者115的信息。在操作242，服務商105向SWIFT伺服器110發送動態配置，該動態配置包括在呼叫者115和被呼叫者120之間的通信連接中使用的最佳算法。例如，如果呼叫者115和被呼叫者120都使用wifi，則他們將會使用另外的網絡控制算法。為了確定將要使用的最佳算法，同時為了適應呼叫者115和被呼叫者120使用的不同網絡，服務商105需要同時了解呼叫者115和被呼叫者120的配置。
[0035]在操作244，在操作242中發送至SWIFT伺服器110的動態配置被轉發至呼叫者115。同樣，在操作244，SWIFT伺服器110將會在該信息中嵌入被呼叫者120的外部IP/埠，其將會用於後面的NAT穿越來生成呼叫者115和被呼叫者120之間的點對點直接通道。此外，在操作246，在操作242時發送至SWIFT伺服器110的動態配置被發送至被呼叫者 120。
[0036]值得注意的是，呼叫者115和被呼叫者120隻與SWIFT伺服器110通信(或者接收來自第三方260的通信)。但是，SWIFT伺服器110從服務商105獲取與相應於呼叫者115和被呼叫者120的動態配置信息相對應的信息。
[0037]在操作248，呼叫者115向SWIFT伺服器110發送信號，確定接收到在操作244時從呼叫者120通過SWIFT伺服器110轉發給呼叫者115的數據。
[0038]在操作250，SffIFT伺服器110向被呼叫者120發送操作248中的確認通信。在操作250，SffIFT伺服器110還會將呼叫者115的外部IP/埠裝入該信息中，其目的是用於被呼叫者120的NAT穿越(生成點對點直接連接)。
[0039]在操作252，在一個實施例中，對於Android?或者PC而言，在操作228 (或類似操作)時發送的推送通知未顯示在被呼叫者120正在使用的設備的屏幕上。以將推送通知顯示在被呼叫者120的設備顯示器上的另一種方式將推送通知通知給被呼叫者120。在這種情況下，被呼叫者120向呼叫者115發送額外的接受信息以表明被呼叫者120已經接受與呼叫者115的通信。
[0040]在一個實施例中，SWIFT伺服器110起到中轉通道的作用，該通道用於呼叫者115與被呼叫者120之間進行直接地傳輸視頻/音頻。
[0041]在一個實施例中，在創建中轉通道之後，呼叫者115和被呼叫者120將嘗試使用彼此的外部IP/埠來生成直接的點對點通道。如果這種嘗試成功，則SWIFT系統100從使用SWIFT伺服器110的中轉通道切換為使用點對點通道。點對點通道是呼叫者115和被呼叫者120 (客戶端)之間的直接通道。通過從中轉通道切換到點對點通道，這些實施例創建了更加直接的路徑，通過該路徑可在呼叫者115與被呼叫者120之間傳輸包含通信的數據包。這條更加直接的路徑提供了更快的數據包穿越、更少的延時，並降低了伺服器的負荷。該切換是無縫的，因此不存在從使用中轉通道執行的操作變化為使用點對點通道執行的操作的用戶可察覺的(音頻/視頻信號)跡象。即使點對點通道在使用中，呼叫者115與被呼叫者120也保持與SWIFT伺服器110聯繫，因此在切換期間中轉通道上的在途數據包將不會丟失。
[0042]參照圖2、圖3A和圖3B，示出了根據實施例的用於降低在實時通信中的兩個客戶端的連接期間呼叫建立時間的方法的流程圖。在不同實施例中，方法200和300是在計算機可讀和計算機可執行指令的控制下通過一個或多個處理器和電子組件實現的。計算機可讀和計算機可執行指令駐留在例如有形的數據存儲零件中，如計算機可用易失性和非易失性存儲器。但是，計算機可讀和計算機可執行指令可駐留在任意類型的計算機可讀存儲介質中。在一些實施例中，方法200和300是由服務商105和SWIFT伺服器110執行的(如相對於圖1A和IB所描述的)，或者由諸如本文所描述的SWIFT系統100的系統來執行。
[0043]仍參照圖1A，在一個實施例中，如本文已描述的，標記為IlOB的第一內部伺服器是SffIFT伺服器110。SffIFT伺服器IlOB起到客戶端(呼叫者115與被呼叫者120)之間的中轉設備的作用。現在參照圖1A和圖1B，根據實施例示出了(SWIFT伺服器110的)SWIFT伺服器110B。SWIFT伺服器IlOB包括下列組件:推送請求接收器155 ;推送通知發送器175。SffIFT伺服器110還可選擇性地包括下列組件:推送請求發送器160 ;通信接收器170 ;安全模塊140 ;動態配置信息接收器165 ;接口 145 ;接口 150 ;推送通知響應器(未示出)。安全模塊140可選擇性地包括:解密器，被配置用於解密在第一內部伺服器接收到的控制數據包，其中所述控制數據包是推送請求的一部分；密碼訪問器，被配置用於訪問封裝在控制數據包的報頭中的密碼，其中所述解密器還被配置用於使用所述密碼來解密所述控制數據包；籤名比較器和控制數據包認證器。籤名比較器被配置用於將與呼叫者相對應的第一籤名和位於所述報頭中的第二籤名進行比較。控制數據包認證器與籤名比較器耦接，並且控制數據包認證器被配置為當所述第一籤名與所述第二籤名匹配並成功解密時認證控制數據包。
[0044]SffIFT伺服器110通過SWIFT伺服器110內的不同模塊對推送請求進行接收、發送、響應，例如下列模塊:結合操作222使用的接收來自呼叫者115的推送請求的推送請求接收器155 ;結合操作224、228、230使用的向被呼叫者120發送推送通知的推送通知發送器175 ;結合操作236使用的通過將被呼叫者120的信息發送至呼叫者115來響應操作238時發送的連接標記的推送通知響應器；以及兩個接口 145和150。
[0045]儘管SWIFT伺服器110通常只在呼叫者115、被呼叫者120以及服務商105之間進行中轉信息，但是SWIFT伺服器110實際上解譯控制數據包中的信息(控制數據包包含在呼叫建立過程中在客戶端與服務商105之間發送的信息。例如，在操作222的來自呼叫者115的推送請求包含(或者就是)控制數據包。)(該推送請求由推送請求發送器160通過SffIFT伺服器110發送給服務商105)。
[0046]實施例還提供了用於從呼叫者115到被呼叫者120的通信數據包的系統和方法，其降低了連接建立時間，而不犧牲安全性。SWIFT系統100不依賴於SSL，而且更輕量。SffIFT系統100使用下面的方法200: (I)客戶端從「供應中心」獲得認證令牌，該認證令牌包含加密的{用戶名，密碼}對。密匙在所有的SWIFT伺服器210A-210n…中共享，並且對於客戶端而言是未知的，但是客戶端知道{用戶名；密碼}的明文數值；(2)客戶端用上述的密碼對所有的控制數據包加密。SWIFT伺服器用密匙對每個控制數據包中的認證令牌解密，導出特定客戶端的密碼並隨後使用該密碼來解密控制數據包的有效負荷；(3)數據包不通過SWIFT系統200來加密，而是可在兩個客戶方之間進行端到端的加密；(4)為了防止「重放攻擊」，每個客戶端評估伺服器時間戳並使用自身的密碼對其進行標記。如果伺服器發現時間戳正確地位於適當的窗口中，則控制數據包通過該驗證。否則，伺服器將會發送隨機數來驗證該客戶端。該隨機數包含客戶端的源IP埠和當前的伺服器時間戳。客戶端將自身的時鐘與伺服器時間戳之間的差異存儲在它的本地存儲器，從而使其不會因為時間戳偏差再被驗證；(5)如果伺服器檢測到客戶端使用不同的UDP IP埠或TCP套接口向伺服器上傳數據，則總是會立即進行隨機數驗證。如果該隨機數成功地被客戶端籤署(它預期會在發送給伺服器的後續數據包中)，則伺服器將會將相應的客戶端入口切換到該新的TCP套接口或UDP IP埠。
[0047]當控制數據包被發送至SWIFT伺服器110時，客戶端的密碼被用於加密控制數據包以及被用於封裝數據包籤名，並且將該數據包籤名置於控制數據包的報頭之中。一旦SffIFT伺服器110接收到控制數據包的報頭中的認證令牌，SWIFT伺服器110便使用密碼來解密控制數據包。SWIFT伺服器110還將其具有的客戶端的籤名與位於控制數據包的報頭中的籤名進行對比。如果籤名匹配並成功加密，則SWIFT伺服器110已經驗證過控制數據包。在驗證之後，SWIFT伺服器110接收和處理(中轉)控制數據包。SWIFT伺服器110確保控制數據包來自特定用戶並隨後解密控制數據包。因此，根據實施例，減少往返次數和加速連接建立時間並沒有犧牲安全性。
[0048]在UDP被任何位於客戶端和SWIFT伺服器110之間的防火牆封鎖的情況下，也可使用TCP建立呼叫，這被稱為防火牆穿越。為了快速穿越防火牆，客戶端總是同時使用m)P和TCP。一旦證實UDP有效，則TCP將會停止。狀態機將幫助算出關閉TCP連接的正確時間。
[0049]這些伺服器的職責之一是幫助建立直接的點對點通道，因此要確定哪個呼叫者115和被呼叫者120的IP和埠看上去像來自外界的。傳統的用於確定該信息的方法是向「TURN/STUN」伺服器發送單獨的請求來獲得「P2P候選人」。相對於傳統的方法，在本文所述的方法200期間，SWIFT系統200本質上發現UDP IP埠，由此在確定哪個呼叫者115和被呼叫者120的IP/埠看上去像來自外界時，避免了額外的步驟(或時間需求)。
[0050]服務商105(這裡也稱為「第二內部伺服器105」)可選擇性地包括下列任意組件:推送請求接收器125 ;第一動態配置發送器130 ;第二動態配置發送器140 ;信息接收器135。推送請求接收器125接收來自SWIFT伺服器110的推送請求。第一動態配置發送器130將被呼叫者120的動態配置(呼叫建立過程中的最佳算法)發送至SWIFT伺服器110。第二動態配置發送器140將被呼叫者120與呼叫者115的動態配置發送至SWIFT伺服器110。信息接收器135接收來自SWIFT伺服器110的關於呼叫者115與被呼叫者120的信肩、O
[0051]服務商105用於完成至少例如與像Apple?、Google?的系統接合來推送通知的功能。如本文所描述的，服務商105與第三方260通信以發送推送通知，該推送通知激活被呼叫者120。
[0052]由此，這些實施例提供了默認基於UDP的方法和系統。因此，這些實施例不會像使用基於TCP的方法或系統出現易於丟包的現象。此外，這些實施例提供用於在數據包傳輸過程中對信息打包，因此節省了更多的其間將採集打包信息的往返回合。在傳統的系統和方法中，各步驟是按照順序完成的，而在這些實施例中是以並行的方式完成的，從而使得呼叫建立過程中的顫動(chatter)量最小化。
[0053]現參照圖3A和圖3B，根據實施例示出了一種用於降低至少兩個設備之間實時通信的呼叫建立時間的方法300。在操作305，在系統的第一內部伺服器，接收到來自呼叫者的第一通信，其中該第一通信是包含發起與被呼叫者連接的嘗試的推送請求。在操作310，推送請求經由所述內部伺服器發送給被呼叫者，其中第一內部伺服器具有至少兩個接口，其中該至少兩個接口的每一個都包括用戶數據報協議(UDP)埠，其中該發送包括通過第一內部伺服器，將被呼叫者能夠連接到的該至少兩個接口的外部UDP IP/埠嵌入推送請求中。
[0054]在操作315，從系統第二內部伺服器、呼叫者和被呼叫者中的至少一個接收通信，其中接收通信包括:接收打包信息，其中該打包信息的各部分能夠在第一內部伺服器、第二內部伺服器、呼叫者和被呼叫者之間被連續地發送或接收。
[0055]在操作320，同時使用UDP埠和傳輸控制協議(TCP)埠來發起或接受呼叫，其中的所述至少兩個埠的每一個都包括TCP埠。UDP IP/埠被用作至少UDP IP/埠和TCP埠的默認埠使用；並且如果確定UDP IP/埠有效，則終止TCP埠的使用。
[0056]在操作325，使用UDP IP/埠在與被呼叫者和呼叫者相關的網絡類型之間進行無縫切換。
[0057]在操作330，通過第一內部伺服器，在呼叫者、第二內部伺服器和被呼叫者之間中轉一組通信，其中該組通信至少包括第一通信。
[0058]在操作335，通過第一內部伺服器，解譯包含在作為推送請求的一部分發送的控制數據包中的信息。
[0059]在操作340，第一內部伺服器對其接收到的控制數據包解密，該控制數據包作為推送請求的一部分。在其他一些實施例中，被封裝到控制數據包的報頭的密碼被訪問，使用該密碼通過第一內部伺服器解密控制數據包。其他一些實施例包括:通過第一內部伺服器，將與呼叫者對應的第一籤名和位於報頭中的第二籤名進行比較；如果第一籤名與第二籤名匹配並成功解密，則通過第一內部伺服器驗證控制數據包。
[0060]在操作345，接收到來自系統的第二內部伺服器的動態配置信息，其中該動態配置信息包括基於呼叫者信息和被呼叫者信息選定的要使用的協議，其中呼叫者信息與被呼叫者信息包括呼叫者和被呼叫者的設備時間和存儲器時間，並且其中該選定的協議包括使在呼叫者與被呼叫者之間的連接建立時間期間的往返回合最小化的最佳適配方法。
[0061]本公開描述了一種用於降低至少兩個設備之間的實時通信的呼叫建立時間的方法。所述方法包括:在系統的第一內部伺服器接收來自呼叫者的第一通信，其中該第一通信是一個推送請求，該推送請求包括發起與被呼叫者的連接的嘗試；通過第一內部伺服器向被呼叫者發送推送通知，其中該第一內部伺服器具有至少兩個接口，其中該至少兩個接口的每一個都包含用戶數據報協議(UDP)埠，其中該發送包括:通過第一內部伺服器將被呼叫者能夠連接到的該至少兩個接口的外部UDP(IPj^n )對封裝到推送通知內。
[0062]本文描述了安全的無線會話發起框架和用於降低實時通信的呼叫建立時間的系統和方法的不同實施例。儘管已描述具體的實施例，但是應當認識到，實施例不應被解釋為由這些描述所限制，而是根據權利要求進行解釋。
[0063]本文描述的所有的元件、部件和步驟是優選地包括。應當理解的是，如本領域技術人員將顯而易見的是，任何的這些元件、部件和步驟都可以被其他元件、部件和步驟代替，或者一起刪除。
[0064]構思:
[0065]本文至少披露了下列構思:
[0066]構思1:一種非易失性計算機可讀存儲介質，其存儲有指令，當執行該指令時，使計算機處理器執行用於降低在至少兩個設備之間的實時通信的呼叫建立時間的方法，所述方法包括:
[0067]在系統的第一內部伺服器接收來自呼叫者的第一通信，其中所述的第一通信是包含發起與被呼叫者連接的嘗試的推送請求；
[0068]經由所述第一內部伺服器向所述被呼叫者發送推送通知，其中所述的第一內部伺服器具有至少兩個接口，其中所述至少兩個接口中的每一個都包含用戶數據報協議(UDP)埠，其中所述發送包括:
[0069]通過所述第一內部伺服器將所述被呼叫者能夠連接到的所述至少兩個接口的外部UDPdPj^n )對嵌入到所述推送通知中。
[0070]構思2:構思I所述的非易失性計算機可讀存儲介質，還包括指令用於:
[0071]從所述系統的第二內部伺服器、所述呼叫者和所述被呼叫者中至少一個接收通信，其中所述接收通信包括:
[0072]接收打包信息，其中所述打包信息的各部分能夠在所述第一內部伺服器、所述第二內部伺服器、所述呼叫者和所述被呼之間被連續地發送或接收。
[0073]構思3:構思I或2所述的非易失性計算機可讀存儲介質，還包括指令用於:
[0074]同時使用所述UDP埠和傳輸控制協議(TCP)埠來發起呼叫或接受呼叫，其中所述至少兩個接口中的每一個都包含所述TCP埠 ；
[0075]利用所述UDP埠作為至少所述UDP埠和所述TCP埠的默認埠 ；以及
[0076]如果確定所述UDP埠有效，則終止所述TCP埠的使用。
[0077]構思4:構思1、2或3所述的非易失性計算機可讀存儲介質，還包括指令用於:
[0078]利用所述UDP埠，在與所述被呼叫者和所述呼叫者相關的網絡類型之間無縫切換。
[0079]構思5:構思1、2、3或4所述的非易失性計算機可讀存儲介質，還包括指令用於:
[0080]通過所述第一內部伺服器，在所述呼叫者、第二內部伺服器和所述被呼叫者之間中轉一組通信，其中所述一組通信至少包含所述第一通信。
[0081]構思6:構思1、2、3、4或5所述的非易失性計算機可讀存儲介質，還包括指令用於:
[0082]通過所述第一內部伺服器，解譯包含在作為所述推送請求的一部分發送的控制數據包內的信息。
[0083]構思7:構思1、2、3、4、5或6所述的非易失性計算機可讀存儲介質，還包括指令用於:
[0084]通過所述第一內部伺服器，解密在所述第一內部伺服器接收到的控制數據包，所述控制數據包是所述推送請求的一部分。
[0085]構思8:構思1、2、3、4、5、6或7所述的非易失性計算機可讀存儲介質，還包括指令用於:
[0086]通過所述第一內部伺服器，訪問封裝在所述控制數據包的報頭中的密碼；以及
[0087]通過所述第一內部伺服器，使用所述密碼來解密所述控制數據包。
[0088]構思9:構思1、2、3、4、5、6、7或8所述的非易失性計算機可讀存儲介質，還包括指令用於:
[0089]通過所述第一內部伺服器，將與所述呼叫者相對應的第一籤名和位於所述報頭中的第二籤名進行比較；以及
[0090]如果所述第一籤名和所述第二籤名匹配且所述解密成功，則通過所述第一內部伺服器驗證所述控制數據包。
[0091]構思10:構思1、2、3、4、5、6、7、8或9所述的非易失性計算機可讀存儲介質，還包括指令用於:
[0092]從所述系統的第二內部伺服器接收動態配置信息，其中所述動態配置信息包括根據呼叫者信息和被呼叫者信息選定的要使用的協議，其中所述呼叫者信息和所述被呼叫者信息包含所述呼叫者和所述被呼叫者的設備時間和存儲器時間，其中所述選定的協議包括最佳適配方法，其中所述選定的協議包括音頻/視頻協議。
[0093]構思11: 一種用於降低在至少兩個設備之間的實時通信的呼叫建立時間的系統，所述系統包括:
[0094]第一內部伺服器，其與第二內部伺服器耦接，所述第一內部伺服器包括:
[0095]推送請求接收器，其被配置用於在系統的第一內部伺服器接收來自呼叫者的第一通信，其中所述第一通信是推送請求和發起與被呼叫者連接的嘗試；以及
[0096]推送通知發送器，其被配置用於經由所述第一內部伺服器向所述被呼叫者發送推送通知，其中所述的第一內部伺服器具有至少兩個接口，其中所述至少兩個接口中的每一個接口都包含用戶數據報協議(M)P)埠，其中所述至少兩個接口的外部UDP埠被嵌入到所述推送通知中，使得呼叫者能夠連接到所述外部UDP埠。
[0097]構思12:構思11所述的系統，其中所述的第一內部伺服器還包括:
[0098]通信接收器，其被配置用於從所述系統的所述第二內部伺服器、所述呼叫者和所述被呼叫者中的至少一個接收通信，其中所述接收通信包括:
[0099]接收打包信息，其中所述打包信息的各部分能夠在所述第一內部伺服器、所述第二內部伺服器、所述呼叫者、所述被呼叫者之間被連續地發送或接收。
[0100]構思13:構思11或12所述的系統，其中所述的第一內部伺服器還包括:
[0101]安全模塊，其與所述第一內部伺服器耦接，並且包括控制數據包，所述控制數據包解譯器被配置用於解譯包含在作為所述推送請求的一部分發送的控制數據包內的信息。
[0102]構思14:構思11、12或13所述的系統，其中所述的安全模塊還包括:
[0103]解密器，其被配置用於解密在所述第一內部伺服器接收到的控制數據包，所述控制數據包是所述推送請求的一部分。
[0104]構思15:構思11、12、13或14所述的系統，其中所述的安全模塊還包括:
[0105]密碼訪問器，其被配置用於訪問封裝在所述控制數據包的報頭中的密碼，其中所述解密器還被配置用於使用所述密碼來解密所述控制數據包。
[0106]構思16:構思11、12、13、14或15所述的系統，其中所述安全模塊還包括:
[0107]籤名比較器，其被配置用於將與所述呼叫者相對應的第一籤名和位於所述報頭中的第二籤名進行比較；以及
[0108]控制數據包驗證器，其與所述籤字比較器耦接，所述控制數據包驗證器被配置用於如果所述第一籤名與所述第二籤名匹配並且所述解密成功，驗證所述控制數據包。
[0109]構思17:構思11、12、13、14、15或16所述的系統，其中所述的第一內部伺服器還包括:
[0110]動態配置信息接收器，其被配置用於接收來自所述第二內部伺服器的動態配置信息，其中所述的動態配置信息包括基於呼叫者信息和被呼叫者信息選定的要使用的協議，其中所述呼叫者信息和被呼叫者信息包含所述呼叫者和所述被呼叫者的設備時間和存儲器時間，其中所述選定的協議包括最佳適配方法，並且是音頻/視頻協議。
【權利要求】
1.一種非易失性計算機可讀存儲介質，其存儲有指令，當執行該指令時，使得計算機處理器執行用於降低至少兩個設備之間的實時通信的呼叫建立時間的方法，所述方法包括: 在系統的第一內部伺服器接收來自呼叫者的第一通信，其中所述第一通信是包含發起與被呼叫者連接的嘗試的推送請求； 經由所述第一內部伺服器向所述被呼叫者發送推送通知，其中所述第一內部伺服器具有至少兩個接口，其中所述至少兩個接口中的每一個接口都包含用戶數據報協議(UDP)埠，其中所述發送包括: 通過所述第一內部伺服器將所述被呼叫者能夠連接到的所述至少兩個接口的外部UDP(IPj^n )對嵌入到所述推送通知中。
2.如權利要求1所述的非易失性計算機可讀存儲介質，還包括指令用於: 從所述系統的第二內部伺服器、所述呼叫者和所述被呼叫者中的至少一個接收通信，其中所述接收通信包括: 接收打包信息，其中所述打包信息的各部分能夠在所述第一內部伺服器、所述第二內部伺服器、所述呼叫者和所述被呼之間被連續地發送或接收。
3.如權利要求1所述的非易失性計算機可讀存儲介質，還包括指令用於: 同時使用所述UDP埠和傳輸控制協議(TCP)埠來發起呼叫或接受呼叫，其中所述至少兩個接口中的每一個都包含所述TCP埠 ； 利用所述UDP埠作為至少UDP埠和TCP埠的默認埠 ；以及 如果確定所述m)P埠有效，則終止所述TCP埠的使用。
4.如權利要求1所述的非易失性計算機可讀存儲介質，還包括指令用於: 利用所述UDP埠，在與所述被呼叫者和所述呼叫者相關的網絡類型之間無縫切換。
5.如權利要求1所述的非易失性計算機可讀存儲介質，還包括指令用於: 通過所述第一內部伺服器，在所述呼叫者、第二內部伺服器和所述被呼叫者之間中轉一組通信，其中所述一組通信至少包含所述第一通信。
6.如權利要求1所述的非易失性計算機可讀存儲介質，還包括指令用於: 通過所述第一內部伺服器，解譯包含在作為所述推送請求的一部分發送的控制數據包內的信息。
7.如權利要求1所述的非易失性計算機可讀存儲介質，還包括指令用於: 通過所述第一內部伺服器，解密在所述第一內部伺服器接收到的控制數據包，所述控制數據包是所述推送請求的一部分。
8.如權利要求7所述的非易失性計算機可讀存儲介質，還包括指令用於: 通過所述第一內部伺服器，訪問封裝在所述控制數據包的報頭中的密碼；以及 通過所述第一內部伺服器，使用所述密碼來解密所述控制數據包。
9.如權利要求8所述的非易失性計算機可讀存儲介質，還包括指令用於: 通過所述第一內部伺服器，將與所述呼叫者相對應的第一籤名和位於所述報頭中的第二籤名比較；以及 如果所述第一籤名和所述第二籤名匹配並解密成功，則通過所述第一內部伺服器驗證所述控制數據包。
10.如權利要求1所述的非易失性計算機可讀存儲介質，還包括指令用於: 接收來自所述系統的第二內部伺服器的動態配置信息，其中所述動態配置信息包括基於呼叫者信息和被呼叫者信息選定的要使用的協議，其中所述呼叫者信息和被呼叫者信息包含所述呼叫者和所述被呼叫者的設備時間和存儲器時間，其中所述選定的協議包括最佳適配方法，其中所述選定的協議包括音頻/視頻協議。
11.一種用於降低至少兩個設備之間的實時通信中的呼叫建立時間的系統，所述系統包括: 第一內部伺服器，其與第二內部伺服器耦接，所述第一內部伺服器包括: 推送請求接收器，其被配置用於在系統的第一內部伺服器接收來自呼叫者的第一通信，其中所述第一通信是包含發起與被呼叫者連接的嘗試的推送請求；以及 推送通知發送器，其被配置用於通過所述第一內部伺服器向所述被呼叫者發送推送通知，其中所述第一內部伺服器具有至少兩個接口，其中所述至少兩個接口中的每一個接口都包含用戶數據報協議(UDP)埠，其中所述至少兩個接口的外部UDP埠被嵌入到所述推送通知中，使得所述被呼叫者能夠連接到所述外部UDP埠。
12.如權利要求11所述的系統，其中所述第一內部伺服器還包括: 通信接收器，其被配置用於從所述系統的所述第二內部伺服器、所述呼叫者和所述被呼叫者中的至少一個接收通信，其中所述通信包括: 打包信息，其中所述打包信息的各部分能夠在所述第一內部伺服器、所述第二內部伺服器、所述呼叫者和所述被呼叫者之間被連續地發送或接收。
13.如權利要求11所述的系統，其中所述第一內部伺服器還包括: 安全模塊，其與所述第一內部伺服器耦接，並且包含控制數據包，所述控制數據包解譯器被配置用於解譯包含在作為所述推送請求的一部分發送的控制數據包內的信息。
14.如權利要求13所述的系統，其中所述安全模塊還包括: 解密器，其被配置用於解密在所述第一內部伺服器接收到的控制數據包，所述控制數據包是所述推送請求的一部分。
15.如權利要求14所述的系統，其中所述安全模塊還包括: 密碼訪問器，其被配置用於訪問封裝在所述控制數據包的報頭中的密碼；其中所述解密器還被配置用於使用所述密碼解密所述控制數據包。
16.如權利要求15所述的系統，其中所述安全模塊還包括: 籤字比較器，其被配置用於將與所述呼叫者相對應的第一籤名和位於所述報頭中的第二籤名比較；以及 控制數據包驗證器，其與所述籤字比較器耦接，如果所述第一籤名與所述第二籤名匹配且解密成功，所述控制數據包驗證器被配置用於驗證所述控制數據包。
17.如權利要求11所述的系統，其中所述第一內部伺服器還包括: 動態配置信息接收器，其被配置用於接收來自所述第二內部伺服器的動態配置信息，其中所述動態配置信息包括基於呼叫者信息和被呼叫者信息選定的要使用的協議，其中所述呼叫者信息和被呼叫者信息包含所述呼叫者和所述被呼叫者的設備時間和存儲器時間，其中所述選定的協議包括最佳適配方法，並且是音頻/視頻協議。
【文檔編號】H04W76/02GK104205991SQ201380014058
【公開日】2014年12月10日 申請日期:2013年5月10日 優先權日:2012年5月10日
【發明者】M·張, X·顧, 賈格迪普·桑德, 格雷戈裡·多爾索 申請人:坦戈邁公司