用于降低呼叫建立時(shí)間的系統(tǒng)和方法
【專利摘要】一種用于降低至少兩個(gè)設(shè)備之間的實(shí)時(shí)通信的呼叫建立時(shí)間的方法。該方法包括：在系統(tǒng)的第一內(nèi)部服務(wù)器接收來(lái)自呼叫者的第一通信，其中該第一通信是推送請(qǐng)求，該推送請(qǐng)求包括發(fā)起與被呼叫者的連接的嘗試；經(jīng)由第一內(nèi)部服務(wù)器向被呼叫者發(fā)送推送通知，其中該第一內(nèi)部服務(wù)器具有至少兩個(gè)接口，其中該至少兩個(gè)接口的每一個(gè)接口都包含用戶數(shù)據(jù)報(bào)協(xié)議(UDP)端口，其中該發(fā)送包括：通過第一內(nèi)部服務(wù)器將被呼叫者能夠連接到的該至少兩個(gè)接口的外部UDP(IP，端口)對(duì)封裝到推送通知中。
【專利說(shuō)明】用于降低呼叫建立時(shí)間的系統(tǒng)和方法
[0001]相關(guān)申請(qǐng):
[0002]本申請(qǐng)涉及并要求于2012年5月10日提交的申請(qǐng)?zhí)枮?1/645，249、標(biāo)題為“SECURED WIRELESS SESS1N INITIATE FRAMEWORK”的美國(guó)臨時(shí)專利申請(qǐng)的優(yōu)先權(quán)。本申請(qǐng)還涉及并要求于2013年3月15日提交的申請(qǐng)?zhí)枮?3/834，152、標(biāo)題為“SECURED WIRELESSSESS1N INITIATE FRAMEWORK”的美國(guó)專利申請(qǐng)的優(yōu)先權(quán)。在此通過引用將上述各申請(qǐng)并入本文。

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

【專利附圖】

【附圖說(shuō)明】
[0005]圖1A根據(jù)實(shí)施例描繪了安全的無(wú)線會(huì)話發(fā)起框架探戈(tango) (“SWIFT”)系統(tǒng)，該系統(tǒng)用于降低在實(shí)時(shí)通信中的兩個(gè)客戶端的連接過程中的連接建立時(shí)間。
[0006]圖1B根據(jù)實(shí)施例描繪了 SWIFT服務(wù)器，該服務(wù)器用于降低在實(shí)時(shí)通信中的兩個(gè)客戶端的連接過程中的連接建立時(shí)間。
[0007]圖2根據(jù)實(shí)施例描繪了用于降低在實(shí)時(shí)通信中的兩個(gè)客戶端的連接過程中的連接建立時(shí)間的方法的流程圖。
[0008]圖3A和3B根據(jù)實(shí)施例描繪了用于降低在實(shí)時(shí)通信中的兩個(gè)客戶端的連接過程中的連接建立時(shí)間的方法的流程圖。
[0009]除非具體指出，本說(shuō)明書中提及的附圖應(yīng)當(dāng)被理解為不是按照比例繪制的。

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