在第一端點和第二端點之間生成rtc連接的電信系統(tǒng)和方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明包括依照權(quán)利要求1的前序部分的用于在第一端點和第二端點之間生成RTC連接的方法，以及依照權(quán)利要求1O的對應(yīng)的電信系統(tǒng)。
【背景技術(shù)】
[0002]用于實時通信或RTC的典型的電信系統(tǒng)是基于由IETF(因特網(wǎng)工程任務(wù)組)和W3C(萬維網(wǎng)聯(lián)盟)被稱為RTCWeb或WebRTC(在本文中將使用術(shù)語“WebRTC”來代替任一名稱)的標(biāo)準(zhǔn)的多媒體技術(shù)，或通常被稱為RTC，其中使用多個相似標(biāo)準(zhǔn)化的協(xié)議。用于確定最佳RTC有效負(fù)荷連接的ICE(交互式連接性建立，RFC 5245)也使用STUN(用于NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)會話穿透效用，RFC 5389)協(xié)議來運行所謂的“連接性檢查”。這些檢查確定可疑路由原則上是否可用于所期望的有效負(fù)荷連接。
[0003]在VoIP(因特網(wǎng)協(xié)議電話)中，實時連接(RTP/RTCP)的端點盡可能直接地被連接到彼此，即沒有互相連接的服務(wù)器。然而，IPv4地址的缺點導(dǎo)致了在許多情況中NAT或NAPT(網(wǎng)絡(luò)地址&端口轉(zhuǎn)換)被用在內(nèi)聯(lián)網(wǎng)和因特網(wǎng)之間的事實。這使得在不采取特殊手段的情況下不可能建立從因特網(wǎng)到內(nèi)聯(lián)網(wǎng)端點的直接聯(lián)系。這涉及ICE(交互式連接性建立)，其在VoIP示例中與SIP信令協(xié)議以及STUN和TURN(STUN的擴(kuò)展)協(xié)議一起工作。由于ICE對可能的連接不要求任何預(yù)設(shè)置，作為其運行的部分，所有連接候選首先由端點確定并且然后被簡單測試(進(jìn)行/不進(jìn)行(go/no go)，基于STUN的“連接性檢查”)。使用檢查列表來完成這些檢查。該列表包含所有候選，通過優(yōu)先級分類(從在頂部的假定最佳連接到在底部的假定最不合適連接(例如經(jīng)由TURN服務(wù)器))。在ICE RFC中描述了用于建立優(yōu)先級的算法，但是其僅包含不計及(account for)當(dāng)前網(wǎng)絡(luò)負(fù)載或任何網(wǎng)絡(luò)干擾的固定規(guī)則。
[0004]因為在本說明書中理解標(biāo)準(zhǔn)中描述的各種方案是重要的，因此在下面簡要地略述這些方案。依照標(biāo)準(zhǔn)精確地在該(優(yōu)先級)序列(從頂部到底部)中執(zhí)行連接性檢查，如在圖1-3中所示:
圖1:直接主機(jī)-主機(jī)連接
圖2:通過NAT連接
圖3:使用TURN中繼服務(wù)器的連接。
[0005]接下來，問題出現(xiàn)了:為什么直接主機(jī)-主機(jī)連接(見圖1)相比于其它兩個連接之一應(yīng)該有可能質(zhì)量更差。答案在于以下事實:上面說明的方案僅示出了邏輯結(jié)構(gòu)，而沒有考慮物理特性。圖5(在頂部是邏輯網(wǎng)絡(luò)視圖，以及在下面是兩個物理表示)示范了該觀念;盡管它在邏輯上是相同的配置，但是通過兩個VPN路由器(R1，R2)建立的連接的質(zhì)量與左邊所示(經(jīng)由以太網(wǎng))的直接連接顯著地不同:通過兩個VPN路由器的連接通常具有明顯地更差的服務(wù)質(zhì)量值。
[0006]類似地可以在所有方案中使用VPN，而它不為ICE方法所知。因此，在優(yōu)先級分配中考慮服務(wù)質(zhì)量總是一個好主意。
[0007]然而，目前僅有少數(shù)預(yù)定義的標(biāo)準(zhǔn)如所述的那樣被用于決定最終選擇哪個路由用于有效負(fù)荷(即，用戶數(shù)據(jù))。在RTC(實時通信)環(huán)境中重要的服務(wù)質(zhì)量方面仍然不經(jīng)常被考慮O
[0008]目前，利用STUN僅執(zhí)行“進(jìn)行/不進(jìn)行”測試(“連接性檢查”，即測試消息是或否進(jìn)行從發(fā)送器到STUN服務(wù)器并再返回的完整電路)。特別地，不考慮對于實時應(yīng)用來說重要的QoS方面。當(dāng)然，在ICE中對各種替換(被稱為候選)分配應(yīng)該為質(zhì)量改進(jìn)(以及如果可適用的話成本減少)做貢獻(xiàn)的優(yōu)先級，但是嚴(yán)格來說各種替換(被稱為候選)是基于設(shè)想或方針，如在優(yōu)先化標(biāo)準(zhǔn)的以下示例中所示:
?在IPv4之前的IPv6，即戰(zhàn)略方針
?在NAT之前的直接連接(采用無地址轉(zhuǎn)換);這對IP技術(shù)是可以的，但是不允許任何QoS聲明
?在TURN(中繼)之前的NAT; TURN服務(wù)器是潛在的帶寬瓶頸，并且因此該設(shè)想是可理解的，但是可靠的QoS聲明還是不可能的。
[0009]在通過前述優(yōu)先化建立的序列中執(zhí)行上述STUN連接性檢查。然而，STUN或其它QoS相關(guān)的標(biāo)準(zhǔn)不影響優(yōu)先化其自身。
[0010]總之:例如用于WebRTC或SIP系統(tǒng)的標(biāo)準(zhǔn)的IETF ICE規(guī)程僅測試針對(ICE)通信端點(客戶端、應(yīng)用服務(wù)器)的所提供的RTC有效負(fù)荷候選地址對的基本連接性(“STUN連接性檢查”)。然而，沒有針對考慮各種候選有效負(fù)荷路徑的QoS特性的功能。

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

[0011]本發(fā)明意圖消除在生成RTC連接時的前述缺點，并意圖在將來生成更高效的RTC連接。
[0012]通過如權(quán)利要求1中的方法，如權(quán)利要求8中的計算機(jī)程序產(chǎn)品或計算機(jī)程序，如權(quán)利要求9中的具有存儲在其上的計算機(jī)程序的機(jī)器可讀數(shù)據(jù)載體以及如權(quán)利要求10中的電信系統(tǒng)來實現(xiàn)本目的。
[0013]依照本發(fā)明，用于生成在IP網(wǎng)絡(luò)中的第一端點和第二端點之間的RTC連接的(計算機(jī)實現(xiàn)的)方法(其中使用ICE方法的已知的STUN連接性檢查規(guī)程)按照如下被執(zhí)行:首先，生成在第一端點和第二端點之間的可能連接路徑(甚至所有的可能連接路徑)的列表。然后，針對該列表上的可能連接路徑(也被稱為候選)中的每一個，建立確定針對在STUN過程中的連續(xù)連接性檢查的序列的相應(yīng)的優(yōu)先級，以查看是否可以使用該特定連接路徑建立在所述第一端點和所述第二端點之間的連接。其次，依照所確定的優(yōu)先級建立在所述第一端點和所述第二端點之間的RTC連接，其中系統(tǒng)首先嘗試使用具有最高優(yōu)先級的連接路徑建立RTC連接。如果這成功，那么不必有另外步驟。然而，如果出于任何原因其失敗，那么系統(tǒng)嘗試使用具有下一個最高優(yōu)先級的連接路徑來建立RTC連接。這些嘗試遵循所確定的或所建立的優(yōu)先級序列繼續(xù)，直到最終建立RTC連接。
[0014]本發(fā)明的特征在于，為了建立相應(yīng)的優(yōu)先級，不僅應(yīng)用了現(xiàn)今已知的標(biāo)準(zhǔn)，而且針對每個可能的連接路徑確定相應(yīng)的服務(wù)質(zhì)量值并將該值包括在用于確定該連接路徑的優(yōu)先級的列表中。
[0015]使用該過程意味著，通過使用在相應(yīng)的服務(wù)質(zhì)量(也被稱為QoS)上可用的統(tǒng)計，考慮了有時對實時應(yīng)用來說是決定性的服務(wù)質(zhì)量或QoS值，使得更高效地建立對應(yīng)的實時連接或RTC連接成為可能。
[0016]依照本發(fā)明在ICE規(guī)程(STUN連接性檢查)中考慮QoS允許首先測試來自QoS觀點的可能的最佳ICE地址對。因此可以避免不必要的并且耗費時間的STUN連接性檢查，這導(dǎo)致更短的實時連接建立時間、更少的網(wǎng)絡(luò)負(fù)載以及選擇具有最佳Qo S特性(相比于替換)的I CE候選對(連接路徑)。
[0017]依照發(fā)明的方法的一個有利版本，第一端點還通過使用STUN消息將針對在第一端點和第二端點之間的可能連接路徑的服務(wù)質(zhì)量值傳輸?shù)狡渌它c。因為在這里術(shù)語“第一端點”不意圖指示對任何特定的端點的限制，因此所有端點都將關(guān)于服務(wù)質(zhì)量值的知識傳輸?shù)狡溆嗟亩它c。換言之，在STUN消息中來回交換針對每個可能連接路徑(也稱為ICE候選對)的QoS數(shù)據(jù)。以這種方式，每個端點將來自其伙伴的對應(yīng)的信息添加到其自己的QoS統(tǒng)計。不僅是針對先前的“真實”連接的QoS數(shù)據(jù)，還有針對要發(fā)出的當(dāng)前呼叫(其也可以被稱作RTC連接)所執(zhí)行的連接性檢查的結(jié)果，將被包括在當(dāng)前ICE候選選擇中。經(jīng)由STUN連接性檢查交換的QoS數(shù)據(jù)也被集成在用于ICE端點的QoS統(tǒng)計數(shù)據(jù)