專利名稱：下一代網(wǎng)絡(luò)中用于非sip講述者的服務(wù)網(wǎng)關(guān)代理的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及下一代網(wǎng)絡(luò)，并且具體地說，涉及在下一代網(wǎng)絡(luò)中向一般承載流量提供QoS處理。
背景技術(shù)：
目前，諸如第三代合作伙伴項(xiàng)目(3GPP)、歐洲電信標(biāo)準(zhǔn)協(xié)會(ETSI)和國際電信聯(lián)盟(ITU)等各種國際標(biāo)準(zhǔn)團(tuán)體和聯(lián)盟正在參與定義下一代網(wǎng)絡(luò)的倡議。根據(jù)ITU-T，下一代網(wǎng)絡(luò)(NGN)是基于分組的網(wǎng)絡(luò)，該網(wǎng)絡(luò)能夠提供包括電信服務(wù)的服務(wù)，并能夠利用多個(gè)寬帶、 啟用QoS的傳輸技術(shù)，并且其中服務(wù)相關(guān)功能獨(dú)立于基礎(chǔ)傳輸相關(guān)技術(shù)。NGN為用戶提供對不同服務(wù)提供商的無限制接入。它也支持通用移動性，該移動性將允許向用戶提供一致和無所不在的服務(wù)。下一代網(wǎng)絡(luò)一般基于因特網(wǎng)多媒體子系統(tǒng)(MS)體系結(jié)構(gòu)，并且利用會話啟動協(xié)議(SIP)管理雙方之間通信會話的建立和拆除(tear-down)。此布置有利之處在于IMS/SIP為因特網(wǎng)協(xié)議(IP)網(wǎng)絡(luò)以防欺詐的方式建立包括話音IP(VoIP)電話呼叫在內(nèi)的多媒體會話提供了框架，并且該框架允許使用極其類似于公共交換電話網(wǎng)(PSTN)和蜂窩網(wǎng)絡(luò)運(yùn)營商當(dāng)前采用的那些方法來進(jìn)行隨后的計(jì)費(fèi)和域間結(jié)算。也就是說，能夠?yàn)槊總€(gè)單獨(dú)的呼叫/會話向用戶開單并帶有與提供的服務(wù)類型有關(guān)的費(fèi)用，并且這些費(fèi)用能適當(dāng)?shù)胤峙涞胶艚?會話遍歷的每個(gè)承載網(wǎng)絡(luò)(或管理域)。如同PSTN—樣，設(shè)想是NGN將包括許多運(yùn)營商/管理域，并且MS體系結(jié)構(gòu)為一個(gè)運(yùn)營商的訂戶與另一運(yùn)營商的訂戶建立話音呼叫或多媒體會話提供基礎(chǔ)，兩個(gè)運(yùn)營商(及任何中間運(yùn)營商)保留其各自管理域中的必需網(wǎng)絡(luò)資源以支持傳送與該會話相關(guān)聯(lián)的話音或多媒體流的承載分組流量所需的服務(wù)質(zhì)量(QoS)。此外，MS體系結(jié)構(gòu)完全支持終端用戶的漫游，受訪域以與歸屬域相同的方式支持承載流量QoS。圖I以示意圖方式示出代表性下一代網(wǎng)絡(luò)體系結(jié)構(gòu)。如在PSTN和因特網(wǎng)中一樣，NGN預(yù)期為多個(gè)管理域的網(wǎng)絡(luò)的集聚(conglomeration)。管理域的業(yè)務(wù)可主要是服務(wù)終端客戶的業(yè)務(wù)或主要是向其它管理域提供轉(zhuǎn)接的業(yè)務(wù)。對本申請來說，提供轉(zhuǎn)接的管理域的網(wǎng)絡(luò)稱為轉(zhuǎn)接網(wǎng)絡(luò)(TN)2。服務(wù)終端客戶的管理域由兩種類型的網(wǎng)絡(luò)組成核心IP網(wǎng)絡(luò)(CN) 4和經(jīng)附接網(wǎng)關(guān)10將終端客戶的終端設(shè)備(TE) 8 “附接”到核心網(wǎng)絡(luò)4使得終端客戶能接收MS服務(wù)的一個(gè)或多個(gè)附接(或“接入”)網(wǎng)絡(luò)(AN)6。即使在AN由單獨(dú)業(yè)務(wù)實(shí)體(AN運(yùn)營商)操作時(shí)(CN運(yùn)營商從該單獨(dú)業(yè)務(wù)實(shí)體購買“全部接入”)，AN —般也被認(rèn)為是與它們連接到的CN在同一管理域中。注意，雖然轉(zhuǎn)接網(wǎng)絡(luò)和核心網(wǎng)絡(luò)基于每個(gè)分組的報(bào)頭中的目的地IP地址路由IP分組，但AN在TE與CN的附接點(diǎn)之間傳輸分組，而不考慮IP地址。雖然附接網(wǎng)絡(luò)能與導(dǎo)線或時(shí)域復(fù)用(TDM)電路一樣簡單，但它通常由媒體特定的第一英里網(wǎng)絡(luò)和更通常的分組回程網(wǎng)絡(luò)組成(在3GPP無線術(shù)語中，此回程網(wǎng)絡(luò)由術(shù)語“核心”表示，但它仍是AN的一部分，而不要與CN混淆)。在圖I所示的網(wǎng)絡(luò)體系結(jié)構(gòu)中，分組在各種核心與轉(zhuǎn)接網(wǎng)絡(luò)之間通過每個(gè)網(wǎng)絡(luò)中的傳輸邊界網(wǎng)關(guān)(TBG) 14托管的交換鏈路12傳輸。對于任意對網(wǎng)絡(luò)，交換鏈路可以是物理鏈路或某一形式的虛擬電路。本領(lǐng)域的技術(shù)人員將認(rèn)識到多個(gè)網(wǎng)絡(luò)也能通過無連接交換網(wǎng)絡(luò)(XN)互連。XN的范圍可以從單個(gè)以太網(wǎng)交換機(jī)到全球IP網(wǎng)絡(luò)或虛擬專用網(wǎng)絡(luò)不等。MS被指定為使用會話啟動協(xié)議(SIP)建立和拆卸(take down)多媒體呼叫或會話。IMS體系結(jié)構(gòu)指定遍布于網(wǎng)絡(luò)的多個(gè)呼叫狀態(tài)控制功能(CSCF) 16，該呼叫狀態(tài)控制功能16處理SIP消息并對它起作用。在特定會話的建立中，SIP訊息(SIP messaging)需要由與會話發(fā)起者相關(guān)聯(lián)的至少一個(gè)始發(fā)服務(wù)CSCS (S-CSCF)和與會話建立的目標(biāo)或目的地相關(guān)聯(lián)的目的地S-CSCF處理。然而，通常SIP客戶端不直接與其相關(guān)聯(lián)S-CSCF對等(peer)，并且存在在SIP客戶端與其相關(guān)聯(lián)S-CSCF之間及始發(fā)與目的地CSCF之間路由和轉(zhuǎn)發(fā)SIP消息的中間CSCF。與本申請?zhí)貏e相關(guān)的是負(fù)責(zé)在管理域之間轉(zhuǎn)發(fā)SIP消息的對等CSCF。在本描述中，我們指定在管理域中最后一個(gè)將SIP消息轉(zhuǎn)發(fā)到另一域或在管理域中第一個(gè)從另一域接收SIP消息的任何CSCF為邊界CSCF (b-CSCF)。熟悉3GPP和/或其它NGN標(biāo)準(zhǔn)要 點(diǎn)的人將認(rèn)識到關(guān)于將如何構(gòu)建邊界控制功能性有一些爭論。術(shù)語“b-CSCF”旨在涵蓋諸如查詢CSCF(I-CSCF)、互連邊界控制功能(IBCF)和出口網(wǎng)關(guān)控制功能(BGCF)的方面等功能組件。在邊界控制不是很強(qiáng)的運(yùn)營商要求時(shí)，甚至S-CSCF可以為b-CSCF。在附接網(wǎng)絡(luò)中無CSCF -所謂的代理CSCF(P-CSCF)的對等實(shí)際上是終端設(shè)備的SIP客戶端功能。由于SIP客戶端(特別是在應(yīng)用服務(wù)器(AS)8b中)可能直接與S-CSCF對等，因此，在本描述中，我們使用術(shù)語周邊CSCF(p-CSCF)來表示處理來自/至SIP客戶端的SIP消息的第一個(gè)/最后一個(gè)CSCF。圖I示出在漫游TE 8 (附接到受訪核心網(wǎng)絡(luò))與應(yīng)用服務(wù)器AS Sb之間的會話建立中的相關(guān)CSCF，其中，歸屬核心網(wǎng)絡(luò)通過轉(zhuǎn)接網(wǎng)絡(luò)2分隔。會話的媒體流作為承載(分組)流量跨網(wǎng)絡(luò)傳輸。在IP分組環(huán)境中，承載流量路徑不是自動與SIP信令遍歷的路徑相同，這是因?yàn)槌休d流量路徑不需要經(jīng)過托管CSCF功能的節(jié)點(diǎn)。域間承載流量在本文中表示為傳輸邊界網(wǎng)關(guān)(TBG) 14的節(jié)點(diǎn)處退出和進(jìn)入管理域。同樣地，在附接網(wǎng)絡(luò)與核心網(wǎng)絡(luò)之間的情況是不同的核心網(wǎng)絡(luò)中接口到附接網(wǎng)絡(luò)的節(jié)點(diǎn)有各種稱謂，如服務(wù)邊緣、核心網(wǎng)絡(luò)邊緣、邊界節(jié)點(diǎn)、接入媒體網(wǎng)關(guān)、接入路由器或諸如GPRS網(wǎng)關(guān)支持節(jié)點(diǎn)(GGSN)或?qū)拵нh(yuǎn)程接入服務(wù)器(BRAS)等接入網(wǎng)絡(luò)類型特定的術(shù)語。在本描述中，我們將使用術(shù)語附接網(wǎng)關(guān)(AG) 10。AG橫跨(Straddle)AN 6與CN 4之間的邊界。指定承載流量QoS要求
正如本領(lǐng)域所熟知的一樣，啟動會話的SIP消息傳送要與會話相關(guān)聯(lián)的承載流量(或需要時(shí)的多個(gè)承載流量)的描述。此描述為會話描述協(xié)議(SDP)的參數(shù)形式。例如，參閱 “SDP :會話描述協(xié)議”(Handley, M.和 V. Jacobson, “SDP: session descriptionprotocol ”, Request for Comments 2327, April 1998)。目前，SIP 消息的 SDP 部分給出承載流量要包含的內(nèi)容(即，話音或視頻及要使用的編解碼器和比特率)的完整描述。此信息最初旨在允許終端系統(tǒng)(end system)指定它們希望如何將話音或視頻數(shù)據(jù)編碼成實(shí)時(shí)協(xié)議(RTP)分組。在MS解決方案中，SDP參數(shù)也可由介于終端系統(tǒng)之間的各種網(wǎng)絡(luò)域中的CSCF解釋，以便確定網(wǎng)絡(luò)表征的承載路徑。通常，此信息從SDP的媒體行(以m=開始)得出。例如，
m= audio 8004 RTP/AVP 9
中的最后參數(shù)指示根據(jù)正好為G. 722的音頻可視化規(guī)范概要(AVP) 9編碼的音頻承載流量，它是64kb/s流(網(wǎng)絡(luò)要求必須包括分組報(bào)頭等并將它向上推進(jìn)到大約100kb/S)?；赟DP參數(shù)，CSCF執(zhí)行被稱為連接許可控制(CAC)的過程，但該過程將更準(zhǔn)確地稱為會話許可控制。CAC過程確定承載流量的資源要求，使得嵌入的媒體流能以預(yù)期的QoS提供(deliver)。如果域沒有支持新承載流量的資源，則相關(guān)CSCF將中止會話建立。3GPP文檔《3GPP TS 23. 207》中提供了有關(guān)此的描述(用于p-CSCF和AG)。 業(yè)備類
業(yè)務(wù)類是有些難以歸類(amorphous)的概念，在不同的業(yè)務(wù)管理模型中表示為不同術(shù)語。在IETF IntServ模型中，有三個(gè)業(yè)務(wù)類“保證”(“guaranteed”)、“受控負(fù)載”(“ controlled load”)和“盡力服務(wù)”(“best effort”)。有點(diǎn)類似的是，IETF DiffServ模型提供三種類型的業(yè)務(wù)轉(zhuǎn)發(fā)行為加速轉(zhuǎn)發(fā)(EF)、確保轉(zhuǎn)發(fā)(AF)(但能有最多4類的AF業(yè)務(wù))和默認(rèn)或盡力服務(wù)。ITU研究組在延遲和抖動(及吞吐量)外加諸如分組丟失率和如何處理超出規(guī)范或遲到的分組等因素方面為服務(wù)定義了業(yè)務(wù)類。在NGN的可行部署中，將存在用于實(shí)時(shí)交談的業(yè)務(wù)類，在該業(yè)務(wù)類中，延遲和抖動均將為可能的最小值(或者運(yùn)營商可選擇若干此種類，一個(gè)用于話音交談，一個(gè)用于視頻電話，一個(gè)用于游戲)，并且將存在保證吞吐量而帶有受約束抖動的另一個(gè)類，該類適于媒體流播出(同樣地，運(yùn)營商可選擇區(qū)分話音與視頻)。由于決不存在專用于盡力服務(wù)業(yè)務(wù)的資源，因此，使用SIP建立盡力服務(wù)型承載流量實(shí)用性很少，但為保證完整性，可定義此類碼點(diǎn)。QoS控制和處理的范圍
圖2示出分成段20的承載流量18。承載流量的每段20遍歷單個(gè)分組傳輸網(wǎng)絡(luò)2-6，并且通過終端裝置或網(wǎng)關(guān)14定界。承載流量段20能根據(jù)傳輸它們的網(wǎng)絡(luò)的類型命名對于穿過附接網(wǎng)絡(luò)的承載流量部分命名為附接段等。對承載流量分組提供特殊處理的需要可能不是端對端擴(kuò)展。廣泛接受的是如果特定分組傳輸網(wǎng)絡(luò)過量提供，則給予所有分組的QoS處理將足以支持任何特定承載流量。本領(lǐng)域的技術(shù)人員也將認(rèn)識到DifTserv可用于為特定類的業(yè)務(wù)模擬過量提供。設(shè)想一些或所有核心網(wǎng)絡(luò)將過量提供(或使用Diffserv來為MS分組模擬過量提供)，結(jié)果是將無需為遍歷此類過量提供的核心網(wǎng)絡(luò)的承載流量的核心段保留資源。然而，極可能是將必須為附接段保留資源以便確保那些段上的流量的分組的傳輸不會將端對端流量的QoS降到低于流量在支持的服務(wù)可接受的質(zhì)量。咨源和許可控制功能(RACF)
為承載流量保留資源的功能與承載流量是其組成的會話的許可控制密切相關(guān)。在現(xiàn)有會話的當(dāng)前承諾條件下，如果鏈路上的帶寬容量不足，節(jié)點(diǎn)處的轉(zhuǎn)發(fā)容量不足，或缺少為新會話的承載流量提供請求的QoS所需的其它資源，則會話建立中止，并且已經(jīng)為該會話保留的任何資源被釋放。更一般地說，在會話建立前，需要做出有關(guān)是否許可會話的多個(gè)策略決定。在IMS體系結(jié)構(gòu)中，這些決定在CSCF處發(fā)起，由會話建立中的第一消息(SIP邀請消息)的處理觸發(fā)。一些策略決定的執(zhí)行被限于CSCF，但有關(guān)承載流量QoS的那些決定由控制CSCF通過信號發(fā)送到將處理承載流量的網(wǎng)關(guān)。圖3為涉及兩個(gè)域的會話示出在附接網(wǎng)關(guān)(AG) 10和傳輸邊界網(wǎng)關(guān)(TBG) 14中分別由p-CSCF和b-CSCF進(jìn)行的RACF功能控制。熟悉NGN標(biāo)準(zhǔn)的人將認(rèn)識到在MS體系結(jié)構(gòu)中，在CSCF與網(wǎng)關(guān)之間，存在形成RACS(資源和許可控制子系統(tǒng))網(wǎng)絡(luò)層的中間策略決定功能(HF)。PDF可向CSCF呈現(xiàn)附接網(wǎng)絡(luò)QoS控制細(xì)節(jié)的抽象視圖并隱藏AG和TBG的拓?fù)浼霸谡埱驫oS承載流量的不同應(yīng)用之間仲裁。無論其優(yōu)點(diǎn)如何，NGN具有限制，因?yàn)镮MS被設(shè)計(jì)為向通過實(shí)時(shí)分組(RTP)分組流量傳輸?shù)亩嗝襟w業(yè)務(wù)(包括視頻和/或VoIP)提供QoS處理。然而，存在將從QoS處理的應(yīng)用中受益的許多其它類型的業(yè)務(wù)。另外，在無MS支持的計(jì)費(fèi)和結(jié)算功能性的情況下，網(wǎng)絡(luò)服務(wù)提供商對投資支持多媒體和VoIP外的業(yè)務(wù)類型所需的NGN技術(shù)積極性不高。IMS的又一限制在于通信會話的雙方必須是SIP客戶端。由于單獨(dú)的終端用戶必須遷移(migrate)至IJ “啟用SIP”的應(yīng)用，因此，這對NGN的部署提供了障礙。相應(yīng)地，仍非常希望有在下一代網(wǎng)絡(luò)中允許一般承載流量的QoS處理的方法和技術(shù)。

發(fā)明內(nèi)容
本發(fā)明的目的是在下一代網(wǎng)絡(luò)中提供允許一般承載流量的QoS處理的方法和技術(shù)。因此，本發(fā)明的方面在會話啟動協(xié)議(SIP)用于建立帶有承載流量的QoS處理的通信會話的通信網(wǎng)絡(luò)中，提供一種為目的地是經(jīng)連接到附接網(wǎng)關(guān)的附接段附接到網(wǎng)絡(luò)的非SIP客戶端的承載流量提供QoS處理的方法。接收有關(guān)承載流量的SIP邀請消息。SIP邀請消息包含將非SIP客戶端標(biāo)識為承載流量的目的地的通用資源標(biāo)識符(URI)。根據(jù)SIP邀請消息中標(biāo)識的業(yè)務(wù)規(guī)范(T-Spec)，嘗試在附接段上安裝QoS策略，并且檢測安裝嘗試的結(jié)果。代表非SIP客戶端生成適當(dāng)?shù)腟IP訊息以基于檢測到的結(jié)果接受或拒絕承載流量。本發(fā)明未專用于任何特定業(yè)務(wù)管理模型，而是只假設(shè)將存在運(yùn)營商對其達(dá)成一致的多個(gè)業(yè)務(wù)類，并且承載流量的所期望的業(yè)務(wù)類能被指定為SDP中的參數(shù)。本發(fā)明假設(shè)對于每個(gè)AG，存在能為經(jīng)過該網(wǎng)關(guān)的承載流量請求QoS處理的P-CSCF (及類似地，對于每個(gè)TBG，存在b-CSCF)，而不考慮用于其內(nèi)部通信的中間HF、節(jié)點(diǎn)和特定的協(xié)議選擇的數(shù)量(若有的話)。特定承載流量的承載段的QoS處理可通過將策略推進(jìn)(push)到該段一端處的網(wǎng)關(guān)而以單端方式設(shè)置，或者可通過將策略推進(jìn)到在該段兩端處的網(wǎng)關(guān)而以雙端方式設(shè)置。如上文所定義，網(wǎng)關(guān)是承載流量的一個(gè)承載段的端點(diǎn)和其下一段的起點(diǎn)推進(jìn)到網(wǎng)關(guān)的單個(gè)策略可用于為兩個(gè)段請求QoS資源。本領(lǐng)域的技術(shù)人員將認(rèn)識到存在用于請求網(wǎng)關(guān)為承載段提供QoS的若干不同方法所謂的“推進(jìn)”方法導(dǎo)致網(wǎng)關(guān)從CSCF(或通過策略決定功能的分層)直接接收“策略決定”以便向承載段提供指定的QoS，并且導(dǎo)致網(wǎng)關(guān)隨后向CSCF回復(fù)它具有“實(shí)行”策略的資源，或它不具有該資源。下面的描述根據(jù)RACS的“推進(jìn)”模型闡述，但本發(fā)明旨在獨(dú)立于QoS要求如何傳遞到網(wǎng)關(guān)而起作用。實(shí)際上，正如本領(lǐng)域的技術(shù)人員將認(rèn)識到的一樣，“帶寬代理”可能跟蹤鏈路或網(wǎng)絡(luò)上的帶寬資源而不曾向在端點(diǎn)的網(wǎng)關(guān)發(fā)送信號。然而，假定段在域內(nèi)部邊界開始或結(jié)束，則網(wǎng)關(guān)將對通過信號發(fā)送到它們的新承載段有具體要求存在額外的原因控制(police)承載流量，更改Diffserv標(biāo)志，生成計(jì)費(fèi)記錄。雖然實(shí)際的資源保留不可能需要在交換鏈路或網(wǎng)絡(luò)上進(jìn)行，但RAC功能將可能被b-CSCF調(diào)用以便檢查每個(gè)管理域?qū)τ嘘P(guān)它準(zhǔn)備從其它域接受的流量的類型和數(shù)量的策略遵從性。


結(jié)合附圖，從下面的詳細(xì)描述中將明白本發(fā)明的其它特性和優(yōu)點(diǎn)，其中
圖I是以示意圖方式示出其中可實(shí)現(xiàn)本發(fā)明的方法的代表性下一代網(wǎng)絡(luò)的框 圖2是以示意圖方式示出在圖I的網(wǎng)絡(luò)中承載流量段的框 圖3是為涉及兩個(gè)域的會話以示意圖方式示出資源和許可控制功能的控制的框 圖4是根據(jù)本發(fā)明的一方面，以示意圖方式示出使用網(wǎng)絡(luò)地址映射釘扎承載段的框
圖5是根據(jù)本發(fā)明的一方面，以示意圖方式示出使用網(wǎng)絡(luò)地址映射在包括多個(gè)承載段的網(wǎng)絡(luò)中釘扎承載段的框 圖6是根據(jù)本發(fā)明的一方面，以示意圖方式示出使用網(wǎng)絡(luò)地址映射在包括多個(gè)IP地址域的網(wǎng)絡(luò)中釘扎承載段的框 圖7是根據(jù)本發(fā)明的一方面，以示意圖方式示出支持非SIP客戶端的方法的框 圖8是根據(jù)本發(fā)明的一方面，以示意圖方式示出在包括多個(gè)IP地址域的網(wǎng)絡(luò)中支持非SIP客戶端的方法的框 圖9是根據(jù)本發(fā)明的一方面，以示意圖方式示出與遺留協(xié)議互配的方法的框 圖10是根據(jù)本發(fā)明的一方面，以示意圖方式示出RSVP到SIP互配的方法的消息流程
圖11是根據(jù)本發(fā)明的一方面，以示意圖方式示出RTSP到SIP互配的方法的消息流程
圖12是根據(jù)本發(fā)明的一方面，以示意圖方式示出用于支持與遺留協(xié)議互配的服務(wù)器操作的框 圖13是根據(jù)本發(fā)明的一方面，以示意圖方式示出用于支持RSVP到SIP互配的服務(wù)器操作的消息流程圖；以及
圖14是根據(jù)本發(fā)明的一方面，以示意圖方式示出用于支持RTSP到SIP互配的服務(wù)器操作的消息流程圖。注意，在所有附圖中，類似的特性通過類似的標(biāo)號標(biāo)識。
具體實(shí)施例方式本發(fā)明提供在下一代網(wǎng)絡(luò)中啟用目的地為非SIP客戶端的承載流量的QoS處理的方法和技術(shù)。本發(fā)明的實(shí)施例在下面僅通過示例，參照圖4-14進(jìn)行描述。一般而言，本發(fā)明提供能單獨(dú)或組合用于擴(kuò)展NGN的IMS/SIP體系結(jié)構(gòu)以便向一般承載流量提供QoS服務(wù)的方法和系統(tǒng)。這些方法和系統(tǒng)能在廣義上分成四個(gè)類別，即SIP到一般承載流量的擴(kuò)展；通信會話的承載流量到用于建立會話的SIP信令遍歷的AG和TBG的釘扎；對非SIP客戶端的支持；以及用于遺留IP信令的網(wǎng)關(guān)功能性。在下面的描述中，將通過代表性示例解釋這些類別的每個(gè)類別。
應(yīng)注意，本申請主要針對用于實(shí)現(xiàn)服務(wù)器網(wǎng)關(guān)代理以在NGN中支持非SIP客戶端的技術(shù)。將承載流量釘扎到用于建立會話的SIP信令遍歷的AG和TBG的技術(shù)和用于遺留IP信令的網(wǎng)關(guān)功能性分別是申請人的題為“在下一代網(wǎng)絡(luò)中釘扎IP承載流量的路由，，(Pinning the Route of IP Bearer Flows in a Next Generation Network)的共同待定美國專利申請xx/xxx, XXX和題為“在下一代網(wǎng)絡(luò)中提供SIP互配”(Providing SIPInterworking in a Next Generation Network)的共同待定美國專利申請 yy/yyy, yyy 的重點(diǎn)，兩個(gè)申請與本申請同時(shí)提交。一般承載流暈
如目前定義的一樣，SIP和MS具有限制，因?yàn)樗鼈冎惶幚碜鳛槎嗝襟w流的承載流量。然而，如果許多其它有用的應(yīng)用的承載流量被IMS標(biāo)識，則它們能利用IMS基礎(chǔ)結(jié)構(gòu)。根據(jù)本發(fā)明的一個(gè)方面，通過將描述一般承載流量的QoS要求的顯式業(yè)務(wù)規(guī)范(T-Spec)參數(shù)添加到SIP信令中的SDP，并在MS中擴(kuò)展RACS機(jī)制以解釋新T-Spec參數(shù)，能克服此限制。在SIP信令的SDP部分中添加顯式T-Spec參數(shù)使兩個(gè)SIP端點(diǎn)能夠請求 網(wǎng)絡(luò)來為任何任意流量(一般承載流量)執(zhí)行資源分配和/或連接許可控制。因此，盡管對于RTP或多媒體承載流量而言，IMS功能要素從媒體編碼和其它媒體描述性SDP參數(shù)中推斷出資源要求，但對于一般承載流量而言，CSCF將使用顯式T-Spec參數(shù)作為資源和許可控制過程的基礎(chǔ)。例如，假設(shè)有一個(gè)網(wǎng)絡(luò)，其中采用了 ITU推薦Y. 1541的服務(wù)指定類。此類情況下，按照RFC 2327的準(zhǔn)則，顯式T-Spec能由兩個(gè)媒體層屬性行組成，一行指定Y. 1541服務(wù)類，而另一行指定所需的容量或帶寬。因此
a = ITU-CLassOfService: Oa = ITU-Capacity: 100
能用于指定承載流量需要100 kb/s和服務(wù)類O ( S卩，根據(jù)Y. 1541，小于100 msec的端對端延遲等)。需要時(shí)，其它方法可用于表示顯式T-Spec參數(shù)。例如，在下面所述的代表實(shí)現(xiàn)中，運(yùn)營商可選擇將名稱指配到帶寬和業(yè)務(wù)類的組合，這允許使用單個(gè)SDP屬性(S卩，指配的名稱)來提供顯式T-Spec。示例使用
一名出差的企業(yè)員工使用VPN客戶端建立從其膝上型計(jì)算機(jī)返回到其企業(yè)的VPN服務(wù)器的IPSec隧道(tunnel)，使得她能接入企業(yè)網(wǎng)絡(luò)的設(shè)施(包括其IP PBX)以撥打和接收電話呼叫。如果此IPSec隧道通過盡力服務(wù)型因特網(wǎng)建立，則加密分組的延遲、抖動和丟失率將是不定的，并且可能不足以支持其膝上型計(jì)算機(jī)上的軟客戶端與企業(yè)IP PBX之間的VoIP會話。為了獲得適合IPSec隧道中話音分組的保證的QoS，要求將IPSec隧道視為一般承載。支持一般承載的運(yùn)營商可選擇為每個(gè)業(yè)務(wù)類收取有限數(shù)量帶寬(傳送容量)的使用費(fèi)，然后為傳送容量和業(yè)務(wù)類的每個(gè)組合指定標(biāo)準(zhǔn)名稱。示例可能為
votel = 100kb/s最低延遲,最低抖動,使用費(fèi)每分鐘$0. 02, vidtel= I Mb/s最低延遲,最低抖動，$0. 10。sdtv = I. 5Mb/s 下游，保證的吞吐量，$0. 03 ;hdtv = 8Mb/s下游，保證的吞吐量，$0. 06 ;
預(yù)期分別用于話音電話、視頻電話、標(biāo)準(zhǔn)清晰度視頻流傳送及高清晰度視頻流傳送。隨后，標(biāo)準(zhǔn)名稱將用作SIP消息的SDP部分中的唯一 T-Spec參數(shù)。在此示例中，將“votel ”QoS指配到一般承載將足以支持用戶VoIP會話。在企業(yè)站點(diǎn)處的VPN服務(wù)器附接到一些運(yùn)營商的NGN網(wǎng)絡(luò)，并且向該域注冊。對于本描述，假設(shè)在VPN客戶端與VPN服務(wù)器之間存在多個(gè)管理域時(shí)，VPN客戶端與VPN服務(wù)器之間IP分組的正常路由行為遍歷與SIP信令將遍歷的相同域鏈，并且假設(shè)關(guān)于分組使用哪些TBG 14不存在模糊性(釘扎承載流量以使用特定TBG在下面詳細(xì)描述)。VPN客戶端8的SIP客戶端部分22在公共MS域中注冊。因此，根據(jù)MS的正常操作，歸屬s-CSCF現(xiàn)在能發(fā)送客戶端SIP信令消息。(注意，VPN客戶端8的SIP客戶端部分22不同于在膝上型計(jì)算機(jī)上的軟電話SIP客戶端-它們可共享相同的代碼，但最終軟電話SIP客戶端將向企業(yè)IP PBX注冊。一個(gè)備選實(shí)現(xiàn)可能使用能夠雙重注冊的單個(gè)SIP客戶端。)VPN客戶端8與VPN服務(wù)器之間安全關(guān)聯(lián)的建立隨后通過使用IKE (因特網(wǎng)密鑰交 換)協(xié)議序列，以通常方式繼續(xù)，附帶條件是VPN客戶端在其IKE消息中聲稱(assert)的身份必須可由VPN服務(wù)器轉(zhuǎn)換成VPN客戶端的SIP身份(URI)。這能夠通過讓VPN客戶端的身份成為其SIP URI而得以保證，但要獲得甚至更高的安全，客戶端的SIP地址能作為授權(quán)過程的結(jié)果而返回(例如，RADIUS或DIAMETER響應(yīng)的一部分)。一旦VPN服務(wù)器已對客戶端鑒權(quán)(實(shí)際上，在IKE的兩個(gè)階段完成后)，它便通過在公共域中發(fā)出SIP邀請消息而向VPN客戶端撥打“呼叫”。SDP中的F-Spec標(biāo)識已被達(dá)成一致的隧道端點(diǎn)。(注意，標(biāo)準(zhǔn)IPSec分組在其報(bào)頭中沒有端口號，而是具有對給定地址對之間的每個(gè)隧道唯一的安全參數(shù)索引字段。此字段能在F-Spec中使用，但實(shí)際上，由于網(wǎng)絡(luò)中存在NAT，因此，對于VPN接入操作樣式，隧穿的正常模式是在Μ)Ρ數(shù)據(jù)報(bào)中封裝IPSec分組，因此，F(xiàn)-Spec的正常樣式用于標(biāo)識分組的IPSec隧道流量。)在一種操作模式中，用于VPN客戶端的T-Spec作為授權(quán)過程的一部分返回到VPN服務(wù)器，S卩，每個(gè)VPN客戶端始終具有管理員設(shè)置的固定QoS級別。在此情況下，T-Spec作為SDP的一部分包括在來自VPN服務(wù)器的邀請消息中。在MS的正常方式中，SIP邀請信令消息通過公共MS CSCF轉(zhuǎn)發(fā)到VPN客戶端的SIP客戶端部分?？蛻舳讼刃枰獙⑤斎胄帕钆c安全關(guān)聯(lián)相關(guān)聯(lián)(我們假設(shè)安全參數(shù)索引即使不是F-Spec的一部分也包括在SDP中，參閱上述內(nèi)容)。在VPN客戶端用戶開始選擇所需服務(wù)類的一種操作模式中(例如，用戶能指定他們是否要撥打/接收話音呼叫或視頻呼叫)，VPN客戶端將為隧道創(chuàng)建T-Spec，并且將它包括在返回到VPN服務(wù)器的SIP響應(yīng)中。(假設(shè)響應(yīng)將是200 OK消息。)MS系統(tǒng)建立會話，將其F-Spec通知IPSec隧道遍歷的AG和TBG，并指示它們根據(jù)T-Spec的指定提供QoS處理。IMS系統(tǒng)也將生成所需的計(jì)費(fèi)記錄，使得隨后能向企業(yè)為服務(wù)開單。VPN服務(wù)器到客戶端之間的IPSec隧道現(xiàn)在是一般承載路徑由客戶端或服務(wù)器發(fā)送的匹配F-spec的分組確保在它們遍歷的每個(gè)域中進(jìn)行指定QoS處理。注意，由于加密在隧道中將所有分組的實(shí)際報(bào)頭隱藏，因此，所有分組得到一致的QoS處理。此外，由于IPSec可能依賴序列完整性，因此，將原diff-serv標(biāo)志轉(zhuǎn)為IPSec分組報(bào)頭并使用它們對不同類的分組進(jìn)行不同的QoS處理不是一個(gè)好的想法。相反，如果實(shí)現(xiàn)希望將IPSec —般承載中的業(yè)務(wù)限為只是(加密)多媒體流，則它將必須為多媒體流和盡力服務(wù)型業(yè)務(wù)建立單獨(dú)的IPSec隧道-無需為盡力服務(wù)型隧道使用SIP請求QoS處理，而是能為不同類型的流量建立不同的IPSec隧道，每個(gè)隧道通過單獨(dú)的T-Spec參數(shù)發(fā)送信號。安全建立一丟失，VPN服務(wù)器便終止SIP會話。本領(lǐng)域的技術(shù)人員將認(rèn)識到有關(guān)上述內(nèi)容存在許多變化。具體而言，情況可能不是在隧道建立的持續(xù)時(shí)間內(nèi)，而是僅在話音呼叫實(shí)際正在啟動時(shí)，或者是甚至僅在呼叫期間盡力服務(wù)型傳輸?shù)谋槐O(jiān)視性能降到低于某一閾值時(shí)才從網(wǎng)絡(luò)請求IPSec隧道的QoS處理。其它增強(qiáng)能夠是IP-Sec隧道一被啟動，就使服務(wù)器建立帶有最低QoS處理的一般承載流量，但隨后服務(wù)器能響應(yīng)在隧道內(nèi)探聽消息(如在軟電話客戶端與IP PBX之間的SIP消息)和/或在企業(yè)域內(nèi)的服務(wù)器請求時(shí)，使用SIP重新邀請來修改流量的服務(wù)類/帶寬。釘扎承載流暈
如圖I所示，會話的端點(diǎn)可附接到不同(核心)網(wǎng)絡(luò)，會話的SIP信令和承載流量遍歷若干個(gè)域。目前，MS中未對承載流量中分組行進(jìn)的路徑給予太多關(guān)注-通常假設(shè)它們將沿IP路由確定的路徑行進(jìn)。另一方面，SIP信令的路由至少部分被定義為經(jīng)過一系列的CSCF，其中，CSCF是相互的成對對等體。在NGN中，在每個(gè)CSCF處的SIP消息的轉(zhuǎn)發(fā)選擇由策略支配(dictate)(基于轉(zhuǎn)接的商業(yè)協(xié)定等)。因此，事實(shí)是在發(fā)起者和終接者在不同域中的情況下，SIP信令遍歷的中間域無需完全為在IP轉(zhuǎn)發(fā)規(guī)則的正常操作下從發(fā)起者發(fā)送并尋址到終接方的IP分組將遍歷的相同域。然而，有兩個(gè)充分理由解釋為什么承載流量的路徑不應(yīng)只由IP路由確定，而是明確設(shè)為遍歷特定域和特定傳輸邊界網(wǎng)關(guān)(TBG)。首先，從商業(yè)角度而言，可能強(qiáng)烈要求會話的承載流量不遍歷未分享(participate in)會話的信令的域,理由是如果域不知道流量所屬的會話，則它無法為其生成計(jì)費(fèi)記錄。其次，對承載流量的QoS提供通常要求將承載流量的授權(quán)通知路徑上的網(wǎng)絡(luò)元件以接收QoS。因此，對于核心網(wǎng)絡(luò)上和/或交換鏈路上的QoS，承載流量的路徑必須被約束為經(jīng)過(釘扎到)會話建立時(shí)b-CSCF選擇的TBG，這是因?yàn)閎-CSCF只能將授權(quán)發(fā)送到它們控制的TBG。除上述兩個(gè)釘扎承載流量的原因外，涉及建立會話的CSCF可確定承載流量需要經(jīng)過某一類型的媒體網(wǎng)關(guān)。承載流量路徑中可能需要媒體網(wǎng)關(guān)以執(zhí)行媒體樣本的代碼轉(zhuǎn)換，這是因?yàn)闀挾它c(diǎn)沒有相互共同的編解碼器。媒體網(wǎng)關(guān)的另一使用可能是因?yàn)槎它c(diǎn)之一要服從合法偵聽(LI)令，并且會話的媒體流需要經(jīng)過LI網(wǎng)關(guān)，使得能使它們的副本安全地轉(zhuǎn)發(fā)到相關(guān)法律部門。本發(fā)明的第二方面為會話的承載流量提供路徑釘扎機(jī)制，以促使承載分組遍歷通過在會話建立時(shí)確定的特定的網(wǎng)關(guān)鏈。下面的描述和圖4-6集中在將承載流量釘扎到傳輸邊界網(wǎng)關(guān)(TBG)，但基于本文中提供的描述，本領(lǐng)域的技術(shù)人員將容易理解包括釘扎到其它網(wǎng)關(guān)(媒體轉(zhuǎn)換、合法偵聽等)的其擴(kuò)展。如上所述，并且如圖2所示，承載流量可分割成承載(流量)段20的串行級聯(lián)。除第一個(gè)流量段開始和最后段的結(jié)束點(diǎn)外，這些承載段在網(wǎng)關(guān)14開始和結(jié)束。在承載流量要釘扎到TBG 14時(shí)，中間承載段20的開始和結(jié)束點(diǎn)是TBG14。注意，由于附接網(wǎng)絡(luò)6不遵從IP轉(zhuǎn)發(fā)，因此，對于特定終端8或服務(wù)器Sb而言，在其附接到網(wǎng)絡(luò)的持續(xù)時(shí)間內(nèi)，其業(yè)務(wù)被釘扎到特定AG 10，S卩，第一和最后的承載段始終在適當(dāng)?shù)奈恢蒙?。公開的機(jī)制用于在AG 10之間釘扎承載路徑。網(wǎng)絡(luò)元件能力:
釘扎承載流量的機(jī)制在下面分三部分公開。先描述在所有網(wǎng)絡(luò)元件處于同一 IP地址域中時(shí)它如何工作；隨后描述在客戶端TE處于專有IP地址域中，但所有運(yùn)營商域處于單個(gè)IP地址域中時(shí)它將如何工作；并且最后描述不同核心網(wǎng)絡(luò)屬于不同IP地址域時(shí)的工作。在所有三種情況下，假設(shè)有相同的能力，即
網(wǎng)關(guān)(包括TBG、AG和特殊媒體網(wǎng)關(guān))能在承載流量分組的報(bào)頭上執(zhí)行NAT轉(zhuǎn)換；以及CSCF是SIP應(yīng)用層網(wǎng)關(guān)(ALG)，能轉(zhuǎn)換SIP消息中SDP中的IP地址和端口號(F-Spec)，并且能控制它們控制的網(wǎng)關(guān)執(zhí)行的NAT轉(zhuǎn)換。如圖I所示，p-CSCF控制AG，b-CSCF控制TBG -媒體網(wǎng)關(guān)可能由S-CSCF或代理控制。有兩種可能的方案來協(xié)調(diào)CSCF進(jìn)行的F-Spec改變和在網(wǎng)關(guān)中NAT映射的設(shè)置。 在第一種方案中，CSCF確定映射并將它推進(jìn)到網(wǎng)關(guān)，而網(wǎng)關(guān)安裝它或者在映射不可行(例如，轉(zhuǎn)換表已滿)時(shí)返回錯(cuò)誤響應(yīng)。備選，CSCF能通過提交原IP地址和端口，并且從網(wǎng)關(guān)接收作為響應(yīng)的完整的映射而向網(wǎng)關(guān)請求映射。在任一方案中，CSCF在將SIP消息轉(zhuǎn)發(fā)到下一 CSCF前改變SDP中的F-spec部分。注意，安裝NAT映射可以是從CSCF到網(wǎng)關(guān)的更大的一般策略推進(jìn)的一部分(例如，安裝QoS策略)。注意，此公開內(nèi)容不闡述選擇哪些特定TBG以形成釘扎點(diǎn)的鏈(這是SIP路由問題的一部分)的方法，而只描述改變正常IP路由行為以確保承載流量的分組經(jīng)過所選TBG的機(jī)制?；緳C(jī)制
本節(jié)公開為全部是同一 IP地址域一部分的域的聯(lián)合(例如，公共地址域IPv4或IPv6)實(shí)現(xiàn)承載流量的釘扎的方法。如上所述，用于承載流量的SDP參數(shù)隱含地包括通過源和目的地IP地址、分組類型及源和目的地端口號來標(biāo)識流量的承載流量的F-Spec。嚴(yán)格地說，F(xiàn)-Spec標(biāo)識單向流量,但明顯的是用于反向流量的F-Spec能從原F-Spec普通地生成，因此，在期望建立雙向流量時(shí)，我們將仍討論單個(gè)F-Spec。在此第一實(shí)現(xiàn)中，所有F-Spec IP地址屬于同一 IP地址域。方法的本質(zhì)在于，通過改變發(fā)射到下一 CSCF上的F-Spec，SIP信令的路徑上的CSCF將承載流量分割成承載段，使得修改的F-Spec只描述在由涉及的CSCF控制的網(wǎng)關(guān)之間的承載段。隨后，CSCF在那些網(wǎng)關(guān)中安裝雙向“交叉連接”映射，使得在輸入承載段中的分組由網(wǎng)關(guān)轉(zhuǎn)發(fā)到下一承載段上。在此處所述的特定實(shí)例化中，“交叉連接”映射是NAT映射，并且分組到下一承載段上的轉(zhuǎn)發(fā)通過執(zhí)行輸入分組報(bào)頭中地址和端口的NAT轉(zhuǎn)換以便使它們成為承載路徑的下一段的分組，然后根據(jù)正常IP路由過程轉(zhuǎn)發(fā)分組而實(shí)現(xiàn)。參照圖4，先更詳細(xì)描述用于涉及兩個(gè)域的會話啟動的機(jī)制，為方便用符號表示，兩個(gè)域示為左側(cè)域和右側(cè)域在圖4中，會話啟動由SIP客戶端TE 8在左側(cè)域中發(fā)起，并且要在右側(cè)域在SIP客戶端AS 8b處終止，因此，SIP邀請消息從左向右遍歷，并且諸如200OK等響應(yīng)從右向左傳播。要描述的過程在域之間的每個(gè)邊界處應(yīng)用，使得當(dāng)有不止兩個(gè)域涉及時(shí)，則左側(cè)域是最靠近發(fā)起者的一個(gè)域(轉(zhuǎn)發(fā)邀請消息到右側(cè)域)，并且右側(cè)域是最靠近終接者的一個(gè)域(轉(zhuǎn)發(fā)200 OK消息到左側(cè)域)。在圖4中，在會話啟動要建立的承載流量中，承載流量的TE端被指定為在IP地址A和端口 a始發(fā)/終止，為此我們使用術(shù)語Aa。在SIP會話啟動開始時(shí)，用于承載流量的AS端的地址和端口號對TE 8是未知的，因此，由TE 8發(fā)出的SIP邀請消息24的SDP中的F-Spec不完整，并且可表示為[Aa，？ ]。在TE 8發(fā)出的SIP邀請消息到達(dá)在左側(cè)域邊界處的b-CSCF 16時(shí)，該b_CSCF選擇TBG 14來釘扎通過承載路徑，并為該TBG請求或生成映射(在26)以應(yīng)用到Aa。假設(shè)結(jié)果是映射Aa => Bb,則b-CSCF修改F-Spec，將TE的始發(fā)IP地址和端口 Aa替換為RBG的IP和端口 Bb，并將邀請轉(zhuǎn)發(fā)(在28)到右側(cè)域中的其對等體。在邀請消息到達(dá)對等b-CSCF時(shí)，該b-CSCF可選擇在右側(cè)域的邊緣處的哪個(gè)TBG 14將形成其交換承載段的末端(注意，在圖4中，不同于其它圖形，在域之間的分組傳輸示為交換網(wǎng)絡(luò)XN，而不只是交換鏈路-如果在成對對等TBG之間只存在單個(gè)交換鏈路，則左側(cè)域b-CSCF的TBG選擇將支配右側(cè)域中的 TBG)。
右側(cè)域中的b-CSCF為所選的TBG 14請求或生成映射(在30)以應(yīng)用到Bb。同樣地，假設(shè)結(jié)果是Bb => Ce，則F-Spec修改為[Ce，？ ]。圖4中會話啟動只涉及兩個(gè)域的情況下，SIP邀請消息將隨后前進(jìn)(在32)通過右側(cè)域中的CSCF，直至它到達(dá)目的地SIP客戶端22 (在圖4中示為應(yīng)用服務(wù)器AS)。在更普遍的情況下，SIP邀請向與下一域?qū)Φ鹊腷-CSCF 轉(zhuǎn)發(fā)。從AS 8b的角度而言，它接收的SIP邀請正請求帶有端點(diǎn)Ce的承載流量。假設(shè)AS通過200 OK消息回復(fù)，則它將指定其承載流的末端(例如，為Zz)，因此，200 OK消息34的SDL中的F-Spec將為[Ce，Zz]。(本領(lǐng)域的技術(shù)人員將認(rèn)識到傳送目的地F-spec部分的響應(yīng)消息可以為180振鈴消息。)200 OK消息遍歷邀請的反向路徑，并回到右側(cè)域b-CSCF。該b-CSCF將在36請求或生成另一映射(例如，Yy <= Zz)，并隨后在TBG 14中激活Bb〈=>CC，Yy〈=>Zz的完全I(xiàn)P報(bào)頭雙向網(wǎng)絡(luò)地址轉(zhuǎn)換。最后，b-CSCF修改200 OK消息中的F-Spec以將承載流量源地址和端口顯示為Yy，并且將目的地顯示為Bb，并將它轉(zhuǎn)發(fā)(在38)到左側(cè)域中的其對等體。在左側(cè)域的對等b-CSCF，200 OK消息的接收促使請求或生成映射Xx〈=Yy、左側(cè)域TBG中雙向映射Aa〈=>Bb、Xx〈=>Yy (在40)的激活，及最終帶有[Aa，Xx]的F-Spec的200 OK消息向始發(fā)SIP客戶端的傳播(在42)。從TE SIP客戶端22的角度而言，會話的承載流量的另一端點(diǎn)是在左側(cè)域TBG 14的Xx。上述公開過程所做的實(shí)際上是將承載流量分段成三個(gè)承載流量段，并在TBG中安裝映射以“重新標(biāo)記”分組，使得它們被轉(zhuǎn)發(fā)到下一段上。在它將承載分組發(fā)送到AS Sb時(shí)，TE 8在它們上放置Xx的目的地地址，它是在200 OK F-Spec中接收該目的地地址。Xx是TE的核心域中TBG 14服務(wù)的地址和端口號第一承載流量段是在TE (地址A)與TBG (左側(cè)核心網(wǎng)絡(luò)上地址X的通告者)之間附接段和最左側(cè)核心段的級聯(lián)。第二段是在左側(cè)TBG(交換網(wǎng)絡(luò)上的地址B)與右側(cè)TBG(交換網(wǎng)絡(luò)上的地址Y)之間的交換段。第三段同樣是附接段和核心段的級聯(lián)，在右側(cè)TBG(右側(cè)核心網(wǎng)絡(luò)上地址C的通告者)與八5(地址2)之間。分組根據(jù)正常IP路由規(guī)則，沿每個(gè)單獨(dú)的承載段轉(zhuǎn)發(fā)到承載段的端點(diǎn)，這是因?yàn)榉纸M報(bào)頭中的目的地地址是段端點(diǎn)的IP地址。在TBG處，分組報(bào)頭被改寫以將分組放置在下一承載段的開始處。熟知標(biāo)簽交換路徑的人員可認(rèn)識到這是標(biāo)簽交換的一種形式，其中，標(biāo)簽字段是整個(gè)IP報(bào)頭源和目的地地址和端口字段。在始發(fā)與終接域之間存在多個(gè)域時(shí)，能利用查看存在機(jī)制的此方案以解釋其應(yīng)用的結(jié)果。圖5用定義每個(gè)承載段的NAT映射補(bǔ)充了圖2。也可能觀察到，在通過單個(gè)IP地址域操作時(shí)，只需要重新映射目的地地址，因?yàn)榉纸M中的源地址不影響其路由。然而，由于在各種安全檢查中使用源地址，如防火墻中和用于安裝QoS策略，因此，需要一致的方案。在涉及多個(gè)地址域(參閱下述內(nèi)容)時(shí)，源地址必須重新映射，因此，我們采用它始終應(yīng)重新映射的方案。還應(yīng)注意的是，在單個(gè)IP地址域中，只有在無法依賴IP轉(zhuǎn)發(fā)將分組轉(zhuǎn)發(fā)到下一承載段的節(jié)點(diǎn)處需要NAT “標(biāo)簽交換”。承載流量只在網(wǎng)關(guān)處需要分段，該網(wǎng)關(guān)可能不是始終在IP轉(zhuǎn)發(fā)流量路徑上。通常，域間交換鏈路的包含拓?fù)淇赡軌虮ＷC網(wǎng)關(guān)將始終在IP轉(zhuǎn)發(fā)流量路徑上，并因此無需是承載段端點(diǎn)。例如，如果有互連兩個(gè)域的單對TBG，并且保證它們之間的最短路徑不遍歷第三個(gè)域，則從TE到AS的單個(gè)承載段將足以確保分組始終經(jīng)過該對 TBG。多個(gè)IP地址域
上述NGN組織不要求每個(gè)管理域是同一 IP地址域的一部分。相反，由于被叫方在SIP消息中根據(jù)URI而不是IP地址標(biāo)識，因此，CSCF的鏈能跨IP地址域邊界向被叫方轉(zhuǎn)發(fā)SIP消息。這確實(shí)要求在b-CSCF從不在同一地址域的其對等體接收SIP信令時(shí)，它們能使SIP信令適應(yīng)其自己的IP地址域，例如，在圖6中，在IPv6域的b-CSCF將從在公共IPv4域的其對等體接收IPv4格式的SIP消息，并且在將它們轉(zhuǎn)發(fā)到其自己域中的其它CSCF上前，將必須將該消息重新格式化為IPv6形式。如上所述，SIP消息在SDP部分中包含用于要建立的承載流量的暗含的流量規(guī)范(F-Specs)。在承載流量要遍歷多個(gè)地址域時(shí)，SIP消息中的F-specs需要在地址區(qū)域邊界更改以反映將在承載流量上實(shí)現(xiàn)的網(wǎng)絡(luò)地址和端口轉(zhuǎn)換。重新格式化SIP消息和改變F-Specs經(jīng)常被稱為SIP ALG(應(yīng)用層網(wǎng)關(guān))功能。圖6示出使用三個(gè)IP地址域的兩個(gè)管理域服務(wù)終端(TE)的管理域?yàn)榻K端指配專用IPv4地址(可能是因?yàn)樗粗概浣o它足夠的公共IPv4地址，無法為每個(gè)終端賦予其自己的公共IP地址)，但在核心網(wǎng)絡(luò)中使用公共地址，而另一管理域全部使用公共IPv6地址。互連兩個(gè)NGN域的交換網(wǎng)絡(luò)在圖6中示為IPv4網(wǎng)絡(luò)，是公共IPv4地址域的一部分。這是任意的選擇，并且交換網(wǎng)絡(luò)能同樣已是IPv6地址域的一部分。比較圖4和圖6，將觀察到在左側(cè)AG處存在地址區(qū)域邊界。在分組穿過(cross)附接網(wǎng)絡(luò)與核心網(wǎng)絡(luò)之間時(shí)，此AG需要在分組上執(zhí)行NAT功能。因此，控制AG的p-CSCF，即與附接到AG 10的TE 8中SIP客戶端22對等的p-CSCF 16需要轉(zhuǎn)換SIP消息的SDP中的F-Spec (使得承載流量看來像是在AG發(fā)起)，并且在AG中安裝必要的NAT映射以終接附接承載段和發(fā)起核心承載段。具體而言，圖6中所示的地址Aa是專用IP地址和端口指配，而Bb是由AG 10通告到核心網(wǎng)絡(luò)中的公共IP地址(和端口號)。同樣地，熟悉專用和公共IPv4路由和默認(rèn)路由的人員將觀察到，所示的Ww〈=Xx映射不是絕對需要的，這是因?yàn)閷Ｓ煤凸睮Pv4地址不重疊，并且無論如何，附接網(wǎng)絡(luò)將把分組轉(zhuǎn)發(fā)到AG。然而，不在承載分組上進(jìn)行完全I(xiàn)P報(bào)頭重新映射將在承載流量前向和后向分割成承載段中產(chǎn)生不對稱，并且這可能導(dǎo)致微妙的維護(hù)問題。圖6中的另一地址域邊界是在右側(cè)域TBG處。此TBG具有在IPv4地址域操作的一個(gè)或多個(gè)接口，并且具體而言，地址Y是接口(之一)的IPv4地址。它也具有在IPv6地址域操作的一個(gè)或多個(gè)接口，地址D是TBG IPv6接口地址。如上所述，從左側(cè)域b-CSCF到達(dá)右側(cè)域b-CSCF的SIP消息將是以IPv4格式，帶有IPv4報(bào)頭和所有v4嵌入式IP地址。在將消息轉(zhuǎn)發(fā)到下一 CSCF上之前，b-CSCF必須轉(zhuǎn)換這些消息以具有IPv6報(bào)頭和嵌入式IP地址。對于SIP邀請消息的SDP中的F-Spec，轉(zhuǎn)換必須匹配將在TBG中安裝的NAT映射，也就是說公開的路由釘扎過程無更改。在客戶側(cè)的隱藏NAT
意識到公共VoIP服務(wù)的實(shí)際部署問題的人員將認(rèn)識到經(jīng)常存在在TE與附接網(wǎng)絡(luò)(AN)之間執(zhí)行的NAT功能。此功能發(fā)生在帶有專用IP地址域的住所或企業(yè)邊界處。現(xiàn)在，此NAT功能不是SIP感知型(即，不包括SIP應(yīng)用層網(wǎng)關(guān)(ALG))。然而，此現(xiàn)象不會在實(shí)質(zhì)上影響上述機(jī)制；現(xiàn)在允許VoIP工作的相同解決方案能繼續(xù)使用。因此，客戶端通過先查詢STUN(NAT的UDP簡單穿越)服務(wù)器來確定應(yīng)用什么NAT映射來“固定”SIP信令(參閱RFC3489);或者p-CSCF檢測到NAT轉(zhuǎn)換已在來自客戶端的SIP信令上執(zhí)行(因?yàn)檠埢蚧貜?fù)消息的SDP中嵌入的客戶端IP地址與消息報(bào)頭中的IP源地址不匹配)，并在處理承載流量 時(shí)指示AG對此進(jìn)行補(bǔ)償。 將來，執(zhí)行NAT功能的客戶邊緣設(shè)備的家用網(wǎng)關(guān)可得到增強(qiáng)以包括p-CSCF功能或由p-CSCF控制，使得住所內(nèi)的承載流量段完全在SIP會話建立過程的控制下。對承載流暈進(jìn)行NAT的其它益處
上面公開的路由釘扎機(jī)制的優(yōu)點(diǎn)在于它使用在TBG(和AG)中經(jīng)常存在的一種能力(MT)，并且它不要求核心網(wǎng)絡(luò)中其它路由器的任何支持。該機(jī)制導(dǎo)致NAT功能被應(yīng)用到穿過管理域的所有承載路徑。即使附接網(wǎng)絡(luò)與核心網(wǎng)絡(luò)處在同一 IP地址域中，它也允許NAT功能在AG應(yīng)用。下面簡要地描述始終對承載流量進(jìn)行NAT的兩個(gè)其它益處，這些益處使它成為IMS中承載流量的路由釘扎的優(yōu)選方法。匿名
在PSTN中，主叫方能請求不向被叫方呈現(xiàn)主叫方的電話號碼。SIP信令支持禁止主叫方的SIP地址，但承載分組的源IP地址可足以讓被叫方標(biāo)識主叫方或主叫方的位置。至少，具有主叫方的IP地址將允許被叫方易于安裝針對主叫方的拒絕服務(wù)攻擊或執(zhí)行某一其它形式的因特網(wǎng)騷擾。如果照例承載流量分成承載段，并且各方只看到其本地AG的IP地址，則撥打或接收SIP呼叫將不向任一方顯示另一方的IP地址，也不擴(kuò)展與在完全鑒權(quán)方的IMS框架外的該方通信的任何方式。掩蔽合法偵聽
實(shí)現(xiàn)合法偵聽的方法要求偵聽目標(biāo)不能檢測到其通信在被偵聽。實(shí)現(xiàn)合法偵聽的另一約束是除直接負(fù)責(zé)執(zhí)行偵聽的那些人外的操作員個(gè)人不能檢測到偵聽在進(jìn)行-此約束通常導(dǎo)致在目標(biāo)的歸屬核心網(wǎng)絡(luò)中部署特定目的偵聽媒體網(wǎng)關(guān)。NAT如上所述使用時(shí)，向終端客戶端呈現(xiàn)的承載流量的SDP描述和實(shí)際分組報(bào)頭不包含另一方的IP地址，而是中間網(wǎng)關(guān)的IP地址，因此，用戶無法(從檢查IP地址)斷定其承載路徑是否已轉(zhuǎn)向偵聽媒體網(wǎng)關(guān)以便復(fù)制承載路徑分組。對非SIP客戶端的支持
IMS已在假設(shè)例如圖I中的客戶端和應(yīng)用服務(wù)器等會話的兩端的實(shí)體使用SIP協(xié)議(講SIP)以便能夠建立承載流量的條件下進(jìn)行開發(fā)。上述方法將MS的應(yīng)用性擴(kuò)展到為不一定是多媒體流的承載流量要求QoS處理的應(yīng)用，但應(yīng)用仍需要具有SIP能力。雖然假設(shè)應(yīng)用服務(wù)器具有SIP功能性是合理的，但最好是能夠建立到不是SIP講述者(SIP speaker)的客戶端的承載流量。與在應(yīng)用能利用新NGN提供的QoS傳輸前應(yīng)用客戶端(遠(yuǎn)多于服務(wù)器)必須升級以具有SIP功能性時(shí)將發(fā)生的情況相比，此類能力將更迅速地?cái)U(kuò)展NGN IMS網(wǎng)絡(luò)支持的有用服務(wù)和應(yīng)用的范圍。根據(jù)本發(fā)明的第三方面，非應(yīng)用感知型客戶端代理與控制附接網(wǎng)關(guān)10的CSCF相關(guān)聯(lián)，通過該附接網(wǎng)關(guān)10，非SIP客戶端附接到網(wǎng)絡(luò)?？蛻舳舜泶砜蛻舳隧憫?yīng)來自應(yīng)用服務(wù)器的SIP邀請消息，使得能提供通過至少附接段的承載流量的QoS處理。在下述實(shí)施例中，應(yīng)用服務(wù)器可以是SIP感知型并能夠調(diào)用本文中所述機(jī)制的服務(wù)器。備選，可部署帶有所需功能性的應(yīng)用服務(wù)器代理，而不是升級應(yīng)用服務(wù)器。任一情況下，所述技術(shù)消除了為所有可能的應(yīng)用客戶端類型部署應(yīng)用感知型特定代理的需要(在多域網(wǎng)絡(luò)中這將是極其困難的過程)。本發(fā)明能通過增強(qiáng)控制應(yīng)用客戶端附接到的AG的p-CSCF以便為客戶端提供一般應(yīng)用獨(dú)立代理功能而實(shí)現(xiàn)。下面我們描述本發(fā)明的兩個(gè)典型實(shí)施例1)其中只確保承載流量的應(yīng)用客戶端 末端附接段的QoS處理，以及2)其中，要為整個(gè)承載流量提供QoS處理。第一種實(shí)現(xiàn)可能對許多部署很有用，因?yàn)榕c核心網(wǎng)絡(luò)相比，帶寬在附接網(wǎng)絡(luò)中更加受限，特別是帶有無線第一英里的那些網(wǎng)絡(luò)?？蛻舳烁浇映休d段的QoS處理
在此實(shí)施例中，目標(biāo)是只為應(yīng)用客戶端的附接承載段提供QoS處理(參見圖7)。假設(shè)AS 8b (應(yīng)用服務(wù)器或其代理)是在某一 MS域(服務(wù)器的歸屬域)中向S-CSCF注冊的SIP講述者。應(yīng)用客戶端附接到某一域的核心網(wǎng)絡(luò)(指定為圖7中的客戶端的服務(wù)域)，從中它接收至NGN網(wǎng)絡(luò)的IP連接。由于應(yīng)用客戶端8不是SIP感知型，因此，它未向任何CSCF注冊。然而，應(yīng)用客戶端的附接點(diǎn)被假設(shè)為是在客戶端的服務(wù)域中P-CSCF控制下的AG。此AG被指定為TE的服務(wù)網(wǎng)關(guān)。雖然圖7將客戶端的服務(wù)域示為通過轉(zhuǎn)接鏈路與服務(wù)器歸屬域分開了零個(gè)或更多個(gè)將它們互連的轉(zhuǎn)接域，但本發(fā)明也適用于應(yīng)用服務(wù)器和客戶端在同一域中的網(wǎng)絡(luò)。為簡單起見，下面的描述先假設(shè)域(服務(wù)器的歸屬域、客戶端的服務(wù)域和任何轉(zhuǎn)接域)全部是同一 IP地址域的一部分，處理在不同IP地址域中的域的另外機(jī)制在本節(jié)末尾公開。由于應(yīng)用服務(wù)器Sb要將分組(在承載流量中)發(fā)送到客戶端8，它必須能夠生成承載流量的F-Spec (否則，它將不能生成分組的IP報(bào)頭)。通常，在需要建立承載流量前，在客戶端與服務(wù)器之間將已經(jīng)存在一些交互示例有在IPSec隧道建立前的因特網(wǎng)密鑰交換(IKE)交互或在視頻剪輯向客戶端進(jìn)行流傳送前選擇視頻剪輯的導(dǎo)航。從初始交換中的IP報(bào)頭中，服務(wù)器將獲得承載流量的客戶端末端的IP地址和端口號。服務(wù)器了解的客戶端的IP地址是AG 10通告的地址，而客戶端8通過該AGIO附接到核心網(wǎng)絡(luò)4。實(shí)際上，F(xiàn)-Spec描述從應(yīng)用服務(wù)器10到AG 8b的承載段。AG 10使用輸入分組中的客戶端IP地址將它們指引(steer)到附接承載段，該附接承載段使到客戶端8的流量路徑變得完整。本發(fā)明考慮了一種新的SIP URI (通用資源標(biāo)識符)形式，我們將它指定為服務(wù)網(wǎng)關(guān)URI，用作應(yīng)用服務(wù)器Sb生成的SIP邀請消息的邀請目的地參數(shù)(并插入“T0”子句中)。此URI中的標(biāo)識符是IP地址的表示此URI的預(yù)期語義是此URI命名的目的地(被叫方)是能將策略推進(jìn)到在URI中通告IP地址的AG 10的p-CSCF 16。有多個(gè)機(jī)制可用于路由將此新服務(wù)網(wǎng)關(guān)URI作為其目的地的SIP邀請消息。例如，如果b-CSCF與它們所處的AS (自主子系統(tǒng))相關(guān)聯(lián)，并且AS編號在其對等b-CSCF的轉(zhuǎn)發(fā)表中提供，則在b-CSCF接收邀請消息時(shí)，它只需確定到目標(biāo)IP地址的BGP-4路由的“下一跳” AS以標(biāo)識要將邀請轉(zhuǎn)發(fā)到的新管理域和對等b-CSCF。一旦邀請到達(dá)了目的地管理域，則它能被轉(zhuǎn)發(fā)到特殊指定的S-CSCF，域中的所有p-CSCF向該S-CSCF注冊了它們控制的網(wǎng)關(guān)的地址范圍。此指定的S-CSCF隨后將服務(wù)網(wǎng)關(guān)URI與地址范圍進(jìn)行匹配以確定要將邀請消息轉(zhuǎn)發(fā)到的P-CSCF。根據(jù)需要，也可使用其它轉(zhuǎn)發(fā)方法。根據(jù)上述假設(shè)，在應(yīng)用服務(wù)器與客戶端之間的承載流量的建立如下所述進(jìn)行 在第一步驟，應(yīng)用服務(wù)器8b向位于其歸屬域中的其S- CSCF (經(jīng)其p-CSCF)發(fā)送帶有
TO子句的SIP邀請，該子句包含指定客戶端的IP地址的服務(wù)網(wǎng)關(guān)URI，并在SDP部分中包括到客戶端的承載流量的F-spec和服務(wù)器希望應(yīng)用的T-spec。(由于是服務(wù)器將為會話 而被開單，因此，指定T-Spec是服務(wù)器的特權(quán)。)
一旦S-CSCF對邀請執(zhí)行了正常起源處理，它便向客戶端的服務(wù)域轉(zhuǎn)發(fā)邀請。如果客戶端的服務(wù)域不同于服務(wù)器的歸屬域，則邀請將例如使用上面概述的轉(zhuǎn)發(fā)決定過程經(jīng)b-CSCF轉(zhuǎn)發(fā)，可能經(jīng)過若干域邊界，直至它在客戶端的服務(wù)域邊界到達(dá)b-CSCF。一旦邀請到達(dá)在客戶端服務(wù)域中的b-CSCF，它便要被轉(zhuǎn)發(fā)到控制客戶端8實(shí)際附接的AG 10 (調(diào)用AGIO的策略決定功能)的p-CSCF。同樣地，上述概述的示例機(jī)制可能使用，但本領(lǐng)域的技術(shù)人員將認(rèn)識到存在多個(gè)可能的機(jī)制。在收到邀請消息時(shí)，p-CSCF請求AG IO (的RACF)在符合為邀請消息的SDP中F-Spec標(biāo)識的承載流量指定的T-Spec的附接網(wǎng)絡(luò)中安裝QoS策略。正是在此時(shí)在包含服務(wù)網(wǎng)關(guān)URI的TO子句和嘗試安裝QoS策略的結(jié)果的觸發(fā)下，p-CSCF的修改行為開始出現(xiàn)(kick in)。在常規(guī)系統(tǒng)中，p-CSCF將轉(zhuǎn)發(fā)邀請到客戶端8，在本例中(客戶端是非SIP客戶端)，客戶端8將不知道如何處理它。因此，根據(jù)本發(fā)明，為客戶端8例示的一般代理44 (或等同地，充當(dāng)一般代理的P-CSCF)代表客戶端8將適當(dāng)?shù)腟IP回復(fù)發(fā)送回應(yīng)用服務(wù)器Sb。如果嘗試在AG上安裝QoS策略成功，則一般代理將接受(例如，“200 0K”)消息沿邀請的反向路徑發(fā)送回應(yīng)用服務(wù)器Sb。備選，如果QoS策略安裝請求失敗，則來自一般代理44的返回消息將是BYE消息，向服務(wù)器Sb指示在附接網(wǎng)絡(luò)中資源不足，無法為承載流量支持請求的T-Spec。在此操作中，將注意到QoS處理應(yīng)用到附接承載段和為完成承載流量的建立而生成的SIP信令，而b-CSCF(或一般代理44)對客戶端應(yīng)用無任何感知。因此，一般代理44確實(shí)是一般性，它能用于為任何客戶端應(yīng)用建立帶有QoS處理的承載流量。一旦應(yīng)用服務(wù)器Sb完成了 SIP會話建立，它發(fā)送到符合F-Spec的客戶端8的分組將以普通盡力服務(wù)方式遍歷各種中間域，但將以指定的QoS遍歷接入/附接網(wǎng)絡(luò)6。在應(yīng)用服務(wù)器Sb結(jié)束為客戶端8服務(wù)時(shí)，它能通過沿原邀請的路徑發(fā)送SIP BYE消息而釋放QoS資源。它到達(dá)p-CSCF時(shí)，BYE消息將促使用于承載流量的QoS策略以普通方式釋放，但同樣地，生成SIP確認(rèn)訊息的將是p-CSCF (或一般代理44)，而不是客戶端應(yīng)用本身。注意，附接網(wǎng)絡(luò)中的QoS策略由所謂“拉”(pull)機(jī)制安裝時(shí)，上面公開的機(jī)制將對未修改的應(yīng)用客戶端不起作用，這是因?yàn)椤袄睓C(jī)制要求在該過程中涉及客戶端，而所述方法的本質(zhì)是在附接網(wǎng)絡(luò)中安裝QoS策略而不涉及客戶端。處理NAT :多個(gè)IP地址域
如上所述，在TE 8和AS 8b處于不同的IP地址域時(shí)，有兩種情況要處理。這兩種情況的第一情況是在TE 88在專用IP地址域中并且核心網(wǎng)絡(luò)是單個(gè)公共IP地址域的一部分時(shí)。AG 8b執(zhí)行NAT功能，將正進(jìn)入核心網(wǎng)絡(luò)4中的分組上的IP報(bào)頭轉(zhuǎn)換，使得在分組到達(dá)應(yīng)用服務(wù)器8b時(shí)，來自客戶端8的分組中的源地址是由AG 10通告的公共地址。假設(shè)應(yīng)用服務(wù)器8b在構(gòu)建服務(wù)網(wǎng)關(guān)URI和F-Spec中使用此公共地址(并且不是控制分組內(nèi)的未轉(zhuǎn)換地址)，則邀請消息將如上所述到達(dá)控制p-CSCF。p-CSCF使用公共IP地址域F-spec進(jìn)行其RACF請求意識到它在對來自客戶端8的業(yè)務(wù)進(jìn)行NAT處理的AG 10需要在附接網(wǎng)絡(luò)中安裝任何IP層“門”前映射F-spec中的客戶端IP地址。)在核心網(wǎng)絡(luò)14之間存在IP地址域邊界時(shí)，事情變得有點(diǎn)更棘手承載流量路徑實(shí)際上在執(zhí)行內(nèi)部地址域NAT的TBG14處被分段成兩部分。在圖8中，左側(cè)IP地址域與右側(cè)IP地址域之間的邊界示為在服務(wù)器的歸屬域的邊緣(但它可能在任何域的邊界)，并且該處的TBG 14是在所有業(yè)務(wù)上執(zhí)行 NAT的TBG。從生成服務(wù)網(wǎng)關(guān)URI的應(yīng)用服務(wù)器Sb的角度而言，該TBG 14是服務(wù)網(wǎng)關(guān)(即，從TE客戶端到達(dá)的分組中源地址的該通告者，在圖8中應(yīng)用服務(wù)器看到B的源地址，這是右側(cè)IP地址域中的地址。)SIP邀請消息能路由到使用例如上述相同的機(jī)制控制NAT TBG14的b-CSCF。如上所述，控制地址域邊界TBG的b-CSCF必須能夠執(zhí)行SIP ALG功能。這種情況下，在SIP邀請消息到達(dá)控制網(wǎng)關(guān)前，關(guān)注的F-Spec的NAT映射將已在NAT TBG中安裝。b-CSCF的第一個(gè)動作必須是輪詢(poll)TBG 14以了解NAT映射，以便它隨后能夠?yàn)榭蛻舳藗?cè)(左側(cè))IP地址域構(gòu)建邀請消息，帶有用于TE 8附接到的AG 10的服務(wù)網(wǎng)關(guān)URI和用于客戶端側(cè)承載段的F-Spec。在圖8中，新服務(wù)網(wǎng)關(guān)URI將包含地址A。從這一點(diǎn)開始，過程如上所述繼續(xù)，b-CSCF對回復(fù)SIP消息執(zhí)行所需的ALG功能。在處理核心網(wǎng)絡(luò)之間的IP地址域邊界時(shí)，有一個(gè)中止申請(caveat)。如上所述，承載流量的路由IP路徑可不遍歷與SIP信令相同的域。具體而言，可存在一些網(wǎng)絡(luò)，在這些網(wǎng)絡(luò)中路由IP路徑可通過未參與NGN的域。如果NAT轉(zhuǎn)換發(fā)生在不是NGN—部分(即，不在b-CSCF控制下)的邊界網(wǎng)關(guān)，則上述機(jī)制將失效。對這種情況的對策是使用如下一部分中所述的完全路由釘扎。示例
本發(fā)明的使用的典型示例將是用于遺留(即，pre SIP)流傳送視頻服務(wù)。視頻服務(wù)提供商可能希望以大于大多數(shù)接入/附接網(wǎng)絡(luò)在“盡力服務(wù)型”服務(wù)級別能可靠支持的質(zhì)量級別提供流傳送視頻。一旦本發(fā)明在NGN中部署，視頻服務(wù)提供商便將升級其服務(wù)器以具備SIP能力(包括能夠生成服務(wù)網(wǎng)關(guān)URI)，并隨后協(xié)商來自本地運(yùn)營商的MS服務(wù)。本地運(yùn)營商將設(shè)置使用費(fèi)，該使用費(fèi)可按每部電影，或基于時(shí)間，或按在特定QoS類傳送的每兆字節(jié)來收取。此形式的使用費(fèi)將取決于競爭因素，并且對于保持“按凈計(jì)算”(“on-net”)的會話(客戶端附接到運(yùn)營商自己的網(wǎng)絡(luò))，將可能低于對于運(yùn)營商必須與一個(gè)或多個(gè)其它運(yùn)營商共享費(fèi)用的會話。使用費(fèi)也可以對應(yīng)用客戶端在使用的附接網(wǎng)絡(luò)類型是特定的，對無線收取高于有線的費(fèi)用。視頻服務(wù)提供商與NGN運(yùn)營商之間的SLA也將包括在會話失敗時(shí)的退款問題。視頻服務(wù)的潛在客戶端按通常一樣繼續(xù)，與視頻應(yīng)用服務(wù)器交互以瀏覽和選擇電影。在瀏覽響應(yīng)的一部分顯示時(shí)，觀看電影的價(jià)格將向用戶呈現(xiàn)視頻服務(wù)提供商將可能設(shè)置價(jià)格以包括運(yùn)送(delivery)費(fèi)用的成本?？赡茈娪皩⒏綆в胁煌那逦?，以不同的價(jià)格，適合不同的客戶端附接網(wǎng)絡(luò)。一旦用戶選擇完成，視頻服務(wù)器便啟動SIP會話，邀請的TO子句包含帶有客戶端的IP地址的服務(wù)網(wǎng)關(guān)URI和用于視頻流的T-Spec。這將促使在為客戶端服務(wù)的AG在客戶端當(dāng)前正使用的附接網(wǎng)絡(luò)中安裝QoS策略，使得從服務(wù)器到客戶端的視頻內(nèi)容分組接收視頻服務(wù)器在邀請消息中請求的QoS處理。承載流量的端對端QoS處理
如上所述，NGN網(wǎng)絡(luò)能向承載流量的所有段提供QoS處理，承載流量“釘扎”通過參與SIP信令交換的管理域的TBG。TE客戶端不是SIP講述者時(shí)，此機(jī)制和結(jié)果端對端QoS能力能與服務(wù)器網(wǎng)關(guān)URI的使用組合在一起。與用于只在客戶端附接段上提供QoS的機(jī)制相比，組合機(jī)制使每個(gè)P-和b-CSCF (在服務(wù)器的邀請消息被路由到控制TE的服務(wù)網(wǎng)關(guān)的p-CSCF時(shí)，處理該消息)也讓網(wǎng)關(guān)準(zhǔn)備好以進(jìn)行NAT轉(zhuǎn)換來釘扎承載流量，使得它接收請求的QoS處理。
除在附接段上QoS所需的條件和假設(shè)外，提供端對端QoS需要有一個(gè)額外的規(guī)定在發(fā)送是承載流量的一部分的分組時(shí)，應(yīng)用服務(wù)器必須使用從在SIP回復(fù)“200 0K”消息中收到的最終F-Spec得出的目的地地址和端口號，而不是它從遺留協(xié)議中了解的原客戶端地址和端口號(它將其放置在原F-Spec中)。由于CSCF生成的最終F-Spec定義用于應(yīng)用服務(wù)器的附接承載段，因此，使用分組報(bào)頭中的其地址確保即使當(dāng)應(yīng)用服務(wù)器具有在適當(dāng)位置的多個(gè)網(wǎng)絡(luò)附接鏈路，應(yīng)用服務(wù)器也將向SIP信令已“準(zhǔn)備好”的AG轉(zhuǎn)發(fā)承載分組，以提供QoS和映射分組報(bào)頭以便將分組轉(zhuǎn)發(fā)到下一承載段上；并且在有不止一個(gè)IP地址域要遍歷時(shí)，路由釘扎操作促使使用通過控制b-CSCF來設(shè)置其NAT映射的NAT網(wǎng)關(guān)。益處
本方法的益處能從遺留視頻流傳送服務(wù)的上述示例明白。未使用本發(fā)明時(shí)，視頻服務(wù)提供商對遺留(即，非SIP)客戶端確保QoS的唯一方式將是視頻服務(wù)提供商與其訂戶使用的每個(gè)附接網(wǎng)絡(luò)提供商建立(enter into)特殊的關(guān)系，使得來自其視頻服務(wù)器的所有業(yè)務(wù)被給予(accord)那些附接網(wǎng)絡(luò)上的增強(qiáng)QoS。這具有的缺陷在于服務(wù)在地理范圍要受限，或者視頻服務(wù)提供商必須與其任何客戶可能希望使用的每個(gè)附接網(wǎng)絡(luò)提供商協(xié)商。借助于本發(fā)明，視頻服務(wù)提供商只需要與是NGN的一部分的一個(gè)運(yùn)營商協(xié)商，并隨后能夠?yàn)楦浇拥饺魏蜰GN運(yùn)營商的網(wǎng)絡(luò)的訂戶服務(wù)。接著，還存在在接入網(wǎng)絡(luò)中靜態(tài)保留資源的問題，因?yàn)闊o論視頻服務(wù)提供商是否使用它們，接入網(wǎng)絡(luò)提供商可能希望得到合理的補(bǔ)償。這將可能導(dǎo)致視頻服務(wù)提供商將在每個(gè)附接網(wǎng)絡(luò)上對它將保留的視頻會話的容量/數(shù)量變得保守；視頻服務(wù)器將不得不針對這些保留/預(yù)分配的資源運(yùn)行其自己的RAC以確保SLA業(yè)務(wù)級別未被違反。熟悉SIP操作的人員將認(rèn)識到，即使一端不是SIP感知型，能使用SIP建立承載路徑也有其它益處。例如，可能出現(xiàn)在會話過程期間，附接網(wǎng)絡(luò)能不再支持在會話啟動時(shí)同意的T-Spec -例如，移動終端可已進(jìn)一步移離基站，并且兩者之間的可用傳輸率已降低。在RACS子系統(tǒng)的適當(dāng)操作中，控制p-CSCF將得知其推進(jìn)的QoS策略不能再得到滿足。隨后，它能啟動返回發(fā)起者的重新邀請SIP信令序列，包括發(fā)送回反映當(dāng)前附接鏈路特征的T-Spec。因此，以更低QoS重新建立會話還是終止會話是應(yīng)用決定。用于遺留IP信令的網(wǎng)關(guān)
上面陳述了向NGN上的非SIP講述應(yīng)用提供QoS的公開方法的備選是為客戶端和服務(wù)器開發(fā)應(yīng)用特定的SIP講述代理。此解決方案的問題在于將不得不迎合的大范圍的可能應(yīng)用。然而，一些應(yīng)用可能已經(jīng)使用某一形式的資源保留協(xié)議(遺留IP信令)，并且這些協(xié)議的數(shù)量極其有限?？赡苄枰紤]的僅有兩種協(xié)議是RSTP [H. Schulzrinne等人所著“實(shí)時(shí)流傳送協(xié)議(RTSP)，，(Real Time Streaming Protocol (RTSP)), RFC 2326，1998 年 4月]和 RSVP [R. Braden (ed.)等人所著“資源保留協(xié)議(RSVP) ^(Resource ReservationProtocol (RSVP))，RFC 2205，1997年9月]。本發(fā)明的第四方面提供一種網(wǎng)關(guān)裝置，該裝置提供遺留IP信令到SIP信令互配。因此，能提供托管信令互配功能(SIWF)的互配網(wǎng)關(guān)，該功能在網(wǎng)絡(luò)邊緣處終止RTSP和/或RSVP信令，并生成跨核心網(wǎng)絡(luò)的SIP消息以建立(啟用QoS的)端對端承載路徑。
圖9是互配網(wǎng)關(guān)的部署的圖示。在此圖中，信令互配功能(SIWF)示為在用于要與承載流量互連的兩個(gè)應(yīng)用實(shí)體(TE上的客戶端和AS上的服務(wù)器)的服務(wù)AG上托管。始終在往來終端系統(tǒng)的分組路徑中的AG是托管信令互配功能的優(yōu)先選擇，這是因?yàn)橥ㄟ^使用深度分組檢查，它們能檢測帶內(nèi)遺留信令分組(“帶內(nèi)”指信令分組與其它業(yè)務(wù)混合)。然而，AG不是唯一可能的選擇。另一種可能實(shí)現(xiàn)將AG的職責(zé)約束為檢測信令分組并將它們以某種形式的隧道轉(zhuǎn)發(fā)到與AG的控制p-CSCF共處在同一平臺上的信令互配功能。SIWF的操作能簡要概述如下
每個(gè)SIWF建立與p-CSCF的關(guān)聯(lián)，并將自身注冊為用于它服務(wù)的終端系統(tǒng)的SIP客戶端。如在服務(wù)網(wǎng)關(guān)(發(fā)明3)的情況中一樣，注冊的客戶端地址可僅是AG為附接到它的終端系統(tǒng)通告的IP地址。備選，并且更多為了符合商業(yè)考慮，應(yīng)用服務(wù)器可具有在運(yùn)營商授權(quán)使用SIWF功能性建立跨NGN網(wǎng)絡(luò)的啟用QoS的承載路徑時(shí)通過管理過程指配的名稱。在檢測到遺留信令消息，該消息是源于它服務(wù)的終端系統(tǒng)的建立承載流量的請求時(shí)，SIffF從消息中提取承載流量的F-Spec和T-Spec，并構(gòu)建尋址到遺留消息尋址到的同一實(shí)體的SIP邀請消息。然而，遺留信令協(xié)議的名稱可用作URI的第一部分，而不是對邀請請求URI的方案部分進(jìn)行“sip ”處理，以向目的地指示邀請消息確實(shí)來自SIWF。此外，源IP遺留信令消息可以以在SIP-I (也稱為SIP-T)中傳送ISUP消息的相同方式作為字段“SIP消息正文”傳送。NGN網(wǎng)絡(luò)向?qū)⑵淠康牡豒RI作為名稱注冊的SIWF轉(zhuǎn)發(fā)SIP邀請消息(假設(shè)通過支持注冊其名稱或IP地址的SIWF功能的AG，目的地附接到NGN)。邀請消息到達(dá)注冊了目的地的SIWF時(shí)，該SIWF(直接從邀請中傳送的消息的封裝版本，或通過反向執(zhí)行生成邀請中F-Spec和T-Spec的過程)重新構(gòu)成遺留信令消息。重新構(gòu)成的遺留消息隨后被轉(zhuǎn)發(fā)到目的地實(shí)體。在本發(fā)明的一個(gè)實(shí)現(xiàn)中，SIWF將辭去(leave)作為實(shí)際始發(fā)實(shí)體的遺留消息的明顯源，但在其它實(shí)現(xiàn)中，特別是始發(fā)和目的地實(shí)體在不同地址域中的那些實(shí)現(xiàn)中，SIffF將顯示為遺留信令消息的發(fā)起者。(此后一方案使得SIWF易于接收遺留信令回復(fù)，這是因?yàn)樗鼘⒈欢ㄏ虻皆摶貜?fù)，但由于它是無ALG的NAT的一種形式，因此，它也可造成應(yīng)用中斷。)
適當(dāng)?shù)臅r(shí)候，目的地實(shí)體將生成遺留協(xié)議響應(yīng)。這將被服務(wù)AG捕獲并引導(dǎo)到SIWF。SIffF將把對重新構(gòu)成的原消息的響應(yīng)和對原邀請的響應(yīng)進(jìn)行匹配。SIWF將遺留響應(yīng)轉(zhuǎn)換成SIP響應(yīng)(例如，200 OK)，并在返回信令路徑上將它轉(zhuǎn)發(fā)到為發(fā)起者服務(wù)的SIWF。SIP響應(yīng)中的一些SDP字段可從遺留響應(yīng)中的字段提取，而其它字段將源于邀請中輸送的SDP?；赟DP中的F-Spec和T-Spec，信令路徑上的CSCF將為承載路徑保留資源。在SIP響應(yīng)到達(dá)為發(fā)起者服務(wù)的SIWF時(shí)，它再次重新構(gòu)成遺留響應(yīng)消息，并將它轉(zhuǎn)發(fā)到實(shí)際發(fā)起者上。由于RSVP和RTSP是很不相同的協(xié)議，因此，SIffF過程的更詳細(xì)公開內(nèi)容為每個(gè)協(xié)議單獨(dú)提供。 RSVP當(dāng)前操作模式
RSVP協(xié)議預(yù)期在支持單向承載流量(在RSVP RFC中稱為簡單的“數(shù)據(jù)流量”)的網(wǎng)絡(luò)中保留資源。雖然RSVP能用于為多播流量和通常任意點(diǎn)對任意點(diǎn)的會議會話保留資源，但本描述局限于其用于單播或只在如圖9中的AS與TE等兩個(gè)實(shí)體之間的點(diǎn)對點(diǎn)承載流量的使用。在RSVP操作模式下，流量的源啟動帶有“路徑”消息的保留過程，消息包含某一形式的F-Spec (稱為fiIterspec)和T-Spec。對于單播承載流量，F(xiàn)-Spec是源和目的地IP地址以及端口號(及協(xié)議)的完整元組，稱為固定濾波器，這意味著在源發(fā)送出“路徑”消息前，該源需要知道目的地IP地址和端口號?！奥窂健毕ぶ返匠休d流量的預(yù)期接收方，因此沿發(fā)送方與接收方之間的IP路由路徑行進(jìn)。在簡單的單播情況下，“路徑”消息的主要效應(yīng)是在具有遍歷的RSVP能力的路由器中記錄前一跳地址，使得返回消息“resv”消息能以相同路徑從接收方遍歷回到發(fā)送方。接收方通過“resv”消息回復(fù)，該消息反向沿“路徑”消息的逐跳路徑行進(jìn)。在它處理“resv”消息時(shí)，每個(gè)具有RSVP能力的路由器基于“resv”消息中的T-Spec (有點(diǎn)混淆地稱為flowspec)將網(wǎng)絡(luò)資源指定(commit)用于承載流量。使用RSVP 到 SIP SIffF 網(wǎng)關(guān)
圖10是概括消息序列圖，示出在從應(yīng)用服務(wù)器(AS)到客戶端終端設(shè)備(TE)跨NGN的承載流量建立中的信令互配，AS和TE均使用RSVP請求網(wǎng)絡(luò)為承載流量提供QoS。SIffF功能位于從AS和TE兩者的第一 IP跳處，根據(jù)圖I所述的NGN體系結(jié)構(gòu)，這暗示SIWF功能性在附接網(wǎng)關(guān)(AG)上托管。(如上所述，通過例如在與托管控制AG的p-CSCF相同的平臺上讓AG認(rèn)識并隧穿RSVP信令消息到在網(wǎng)絡(luò)中進(jìn)一步托管的SIWF功能，可擴(kuò)展此第一跳。)假設(shè)AS提供到TE的應(yīng)用由它們之間的消息交換啟動。在某個(gè)點(diǎn)(例如，電影已選定并且付款細(xì)節(jié)已解決)，AS確定它需要將分組流量(承載流量)提供到TE，并構(gòu)成“路徑”消息，該“路徑”消息指定流量的源和目的地IP地址和端口號(F-Spec)及用于流量的T-Spec。它將此消息尋址到TE，并在S2將它寄出?！奥窂健毕⒈籗IWF截取(intercept)并轉(zhuǎn)換成SIP邀請消息S4。承載流量的F-Spec和T-Spec被轉(zhuǎn)換成SDP參數(shù)(使用用于T-Spec的發(fā)明I)，并且在TE通過IP地址標(biāo)識的條件下，SIP目的地URI將是服務(wù)網(wǎng)關(guān)URI (如上所述)。除將F-Spec和T-Spec從RSVP格式轉(zhuǎn)換到SIP格式外，源RSVP消息可能可附加到SIP消息。在SIWF機(jī)制的一個(gè)實(shí)施例中，整個(gè)RSVP “路徑”消息能作為邀請消息中的不透明字段封裝和傳送。在另一實(shí)施例中，邀請消息中將只傳送“路徑”消息的內(nèi)部字段而不傳送其報(bào)頭。此外，如上所述，本發(fā)明的實(shí)施例可選擇更改URI的“方案”，產(chǎn)生象如下所示的邀請消息的第一行INVITE rsvp : xxx. xxx. xxx. xxx SIP/2, y 其中，xxx. xxx. xxx. xxx 是 IP (v4)地址。NGN網(wǎng)絡(luò)將把SIP邀請消息以上述方式轉(zhuǎn)發(fā)到為AG服務(wù)的ρ-CSCF，而該AG為TE服務(wù)。根據(jù)SIWF已執(zhí)行的注冊它能夠執(zhí)行其互配功能的IP地址(或地址范圍)的注冊功能，ρ-CSCF將是有能力的。在更改URI中的方案的實(shí)施例中，那將足以改變p-CSCF以將邀請轉(zhuǎn)發(fā)到服務(wù)SIWF。SIffF隨后在封裝(部分)的原路徑消息包括在內(nèi)時(shí)使用該消息從邀請消息重新生成RSVP “路徑”消息，并將其自己的IP地址作為“前一跳”添加到消息中。它將“路徑”消息轉(zhuǎn)發(fā)到TE 8(在S6)上。TE 8將通過尋址到托管SIWF功能的節(jié)點(diǎn)(其前一跳)的“resv”消息S8進(jìn)行響應(yīng)。SIWF功能將使“resp”消息(S8)與在接收邀請消息時(shí)它安裝的狀態(tài)相配，并從中它將生成對邀請的響應(yīng)，例如，200 OK消息S10。由于RSVP的規(guī)則允許TE將“resp”中的T-Spec參數(shù)更改為它在“路徑”消息中收到的不同值，因此，SIffF將不得不為響應(yīng)重新生成SDP的T-Spec部分,而不是只回應(yīng)(echo back)它在邀請中收到的相同值。200 OK消息通過NGN傳送回到為AS服務(wù)的SIWF，消息的路徑中的CSCF將適當(dāng)?shù)牟呗?推進(jìn)到網(wǎng)關(guān)，使得SDP中F-Spec描述的承載流量將接收SDP中T-Spec指定的QoS處理。在SIffF重新生成了 “resv”消息S12并將它轉(zhuǎn)發(fā)到AS后，AS能開始發(fā)送承載流量分組S14。RSVP是軟狀態(tài)協(xié)議，而SIP是硬狀態(tài)。這意味著發(fā)送方(圖10中的AS)和接收方(圖10中的TE)分別定期發(fā)出“路徑”和“resv”消息以“刷新”用于承載路徑的網(wǎng)絡(luò)資源保留。啟用RSVP的路由器將在“清除超時(shí)”間隔內(nèi)未看到這些“刷新”消息時(shí)釋放資源。明顯的是，SIffF功能應(yīng)只將新RSVP消息轉(zhuǎn)換成SIP消息，并且只使用“刷新”消息來重置計(jì)時(shí)器。如果在足夠長的間隔內(nèi)未收到“刷新”消息，則SIWF應(yīng)發(fā)出SIP BYE消息以拆除會話。此外，雖然SIP會話在進(jìn)行，但SIWF不得不生成匹配的刷新消息，使得發(fā)送方和接收方不會認(rèn)為承載路徑已失去其保留。像允許資源保留作廢一樣，RSVP確實(shí)規(guī)定了顯式拆除。在圖10中，發(fā)送方示出通過發(fā)出” pathtear”消息S16來終止承載路徑，作為與接收方的會話結(jié)束。在SIWF從RSVP發(fā)送方(或接收方)接收“pathtear”(或“resvtear”)消息時(shí)，它發(fā)出SIP BYE消息S18。BYE消息被確認(rèn)(通過200 OK響應(yīng)S20)，而RSVP “tear”消息不被確認(rèn)。本領(lǐng)域的技術(shù)人員將認(rèn)識到不要求TE和AS離其服務(wù)SIWF —個(gè)IP跳。具體而言，AS和/或TE能連接到RSVP支持網(wǎng)絡(luò)(例如，帶有啟用RSVP的路由器的企業(yè)網(wǎng)絡(luò))，并且在NGN邊界處的SIWF功能可能間隔幾個(gè)IP跳。RTSP
像SIP —樣，RTSP是基于文本的應(yīng)用協(xié)議。并且，像SIP —樣，它使用SDP來描述媒體流。在語義學(xué)(semantics)中有相當(dāng)大的重疊。然而，由于比SIP更早開發(fā),它針對的是SIP支持的應(yīng)用子集。RTSP的主要應(yīng)用領(lǐng)域是包括存儲和直播型的多媒體演示。網(wǎng)上直播及其從儲存器的隨后重放是RTSP的一種使用，音頻或視頻的因特網(wǎng)流傳送是另一使用。RTSP消息的語義學(xué)不直接與SIP相等。一種類型的消息“描述(DESCRIBE)響應(yīng)消息”傳送描述可能幾個(gè)承載流量的演示的SDP (并且從中不得不推斷每個(gè)流量的T-Spec)，而另一類型的消息“建立(SETUP)消息”傳送用于一個(gè)承載流量的F-Spec。每個(gè)承載流量需要單獨(dú)的建立消息。更糟糕的是，RSTP不要求使用描述消息應(yīng)用客戶端能通過任何技術(shù)了解承載流量的媒體初始化參數(shù)。因此，必須認(rèn)識到將難以產(chǎn)生有效的SIP-RTSP SIffF來處理RTSP的所有可能使用。由于實(shí)際上極少量的RTSP媒體服務(wù)器和播放器(即，REAL、Quicktime、Windows)支配了因特網(wǎng)上RTSP的使用，因此，設(shè)計(jì)為處理其RTSP使用模式的SIWF將是最有益的。下面描述本發(fā)明的一個(gè)實(shí)施例，該實(shí)施例針對在已交換描述消息后在會話中建立承載流量的應(yīng)用。艦RTSP 到 SIP SIffF 網(wǎng)關(guān)
圖11示出用于RSTP客戶端或播放器(在TE上托管)的消息流程，該RSTP客戶端或播放器跨在其邊緣具有截取來自TE和AS的RTSP消息的RTSP到SIP SIffF功能的NGN向RSTP講述應(yīng)用服務(wù)器(AS)請求媒體流。希望啟動RSTP會話的RTSP客戶端將知道應(yīng)用服務(wù)器的URL，因此，它能生成描述請求消息的請求URI，并將該消息發(fā)送(在S22)到服務(wù)器。在圖11中，描述請求消息示為 直接經(jīng)過托管SIWF功能的節(jié)點(diǎn)。只有響應(yīng)RTSP 200 0K(S24)是它們關(guān)注的，并且實(shí)際上只有為客戶端服務(wù)的SIWF需要緩沖對描述的響應(yīng)的SDP正文部分。應(yīng)注意的是，描述會話的媒體流的應(yīng)用服務(wù)器無需是提供媒體流的相同實(shí)體，因此，將不保證服務(wù)應(yīng)用服務(wù)器的SIWF將是與服務(wù)媒體服務(wù)器相同的SIWF?？蛻舳说腟IWF(即，在TE附接的AG處托管的SIWF)需要能夠檢測引導(dǎo)到客戶端的消息流中的RTSP 200 OK消息。具體而言，它需要檢測和緩存在消息正文中傳送的媒體流的描述。實(shí)際上，SIWF能指定為檢查“內(nèi)容-類型應(yīng)用/sdp”行的所有形式的200 OK消息，并緩存正文內(nèi)容來針對來自客戶端的可能將來RTSP建立請求。具體而言，這將包括使用HTTP響應(yīng)輸送用于會話的SDP參數(shù)的情況?？蛻舳耸盏降腟DP參數(shù)描述構(gòu)成會話的一個(gè)或多個(gè)媒體流源。為每個(gè)源包括的是其URI。因此，客戶端向每個(gè)媒體流源發(fā)出建立請求，并帶有它從描述響應(yīng)中了解的請求URI (圖11示出為是AS的媒體源發(fā)出的一個(gè)建立請求)。在建立消息中包括的是客戶端希望接收承載流量的端口號(本領(lǐng)域的技術(shù)人員將認(rèn)識到，對于rtp/avp配置文件承載流量，它實(shí)際上是指定的一對端口號，但這些端口號的第二個(gè)端口號是用于RTSP業(yè)務(wù)，該業(yè)務(wù)不可能從優(yōu)于“盡力服務(wù)” QoS處理而受益)。在客戶端的SIWF認(rèn)識到建立請求S26時(shí)，它先不得不使它與以前描述響應(yīng)的緩存SDP中的媒體流描述進(jìn)行匹配。進(jìn)行此操作有兩個(gè)關(guān)鍵在建立消息的分組報(bào)頭源字段和描述響應(yīng)的目的地字段中的客戶端的IP地址，以及建立消息的請求URI，它應(yīng)匹配來自描述響應(yīng)的SDP的媒體流源URI。(通常只匹配媒體流源URI將足夠，但可存在為不同客戶端提供不同編碼的情況，因此，更安全的做法是也匹配客戶端。)在找到匹配時(shí)，SIWF能為SIP邀請消息S28構(gòu)建SDP的T-Spec部分。F-Spec的接收方端(即，分組類型和客戶端IP地址和端口號)也編碼到SDP中。由于在建立消息中有請求URI，因此，在邀請消息中的請求/目的地URI有兩個(gè)選擇，即如果媒體服務(wù)器已管理地注冊了獨(dú)特的URI (即，SIffF能承認(rèn)由SIP可路由到的一個(gè)URI)，并已將該URI作為描述響應(yīng)的一部分返回，則從建立消息中復(fù)制的此URI能用作邀請的請求URI ;否則，建立消息的目的地IP地址能用于構(gòu)建服務(wù)網(wǎng)關(guān)URI (如上所述并類似于上述RSVP的情況)。邀請消息由NGN以之前所述方式向服務(wù)器轉(zhuǎn)發(fā)，并且到達(dá)服務(wù)器的SIWF( S卩，與附接到服務(wù)器的AG相關(guān)聯(lián)的SIWF)。假設(shè)策略檢查得到滿足(參閱下述內(nèi)容)，則SIWF重新生成建立請求S30并將它轉(zhuǎn)發(fā)到媒體服務(wù)器。同樣地，如在RSVP的情況中一樣，本發(fā)明的實(shí)施例可實(shí)際上傳送在邀請消息中封裝的建立消息的副本，但邀請消息中除此以外的信息將足以允許生成在語義上與客戶端發(fā)送的相同的建立消息。服務(wù)器在發(fā)出其對建立消息的響應(yīng)S32時(shí)，在其中包括源端口號，使得在服務(wù)器的SIWF截取消息時(shí)，它能使對邀請消息的響應(yīng)S34中SDL的F-Spec部分變得完整。SIP200 OK響應(yīng)消息S34的其它部分從邀請消息的內(nèi)容構(gòu)建。在200 OK響應(yīng)通過邀請的反向路徑傳回時(shí)，各種CSCF在網(wǎng)關(guān)中安裝QoS策略以確保F-Spec描述的承載路徑接收T-Spec指示的QoS處理?？蛻舳说腟IWF將SIP 200 OK響應(yīng)S34轉(zhuǎn)換成對原建立消息的響應(yīng)(RSTP 200 OK響應(yīng)S36)，并將該響應(yīng)發(fā)送到客戶端上。不同于SIP，RTSP也具有控制媒體流播出(例如，啟動快進(jìn)序列)的方法(命令)集。這些命令只涉及服務(wù)器，并且無需由SIWF解釋。在此 命令集中包括的是播放(PLAY)請求，服務(wù)器在收到播放請求前，實(shí)際上不發(fā)送任何承載流 分組。然而，TEARD0WN請求S38由SIWF截取并轉(zhuǎn)換成SIP BYE消息S40。RTSP的TEARD0WN和SIP的BYE消息均要求確認(rèn)(200 OK) S42、S44。授權(quán)和計(jì)費(fèi)
IMS體系結(jié)構(gòu)的主要益處之一在于用戶(以SIP客戶端的形式)得到鑒權(quán)(在注冊(REGISTRATION)步驟期間)，并且NGN生成計(jì)費(fèi)信息，將用戶與他們請求的QoS承載流量聯(lián)系在一起。如上所述，在NGN中提供SIWF網(wǎng)關(guān)會削弱這些控制，這是因?yàn)樗鼈冊试S未注冊端點(diǎn)來請求和使用網(wǎng)絡(luò)資源。在實(shí)際的商業(yè)部署中，運(yùn)營商將需要預(yù)授權(quán)承載流量的一端(可能是應(yīng)用服務(wù)器)，這是因?yàn)榇嬖谂c其協(xié)商帳務(wù)安排的極少的應(yīng)用服務(wù)器。運(yùn)營商將管理地提供應(yīng)用服務(wù)器的地址到其服務(wù)SIWF中，并明確允許互配功能。SIWF能得到它向s-CSCF注冊的服務(wù)器的URL，使得SIP消息能使用該URL作為目的地URI而不是服務(wù)網(wǎng)關(guān)IP地址方法路由到SIWF。QoS的詵擇件應(yīng)用
然而，即使當(dāng)應(yīng)用服務(wù)器被安全標(biāo)識，并且商業(yè)安排到位以便為它建立的QoS承載流量向它開單時(shí)，服務(wù)器也不能選擇在發(fā)送給它的流量上特定的客戶端是接收QoS處理還是盡力服務(wù)處理。(這可取決于客戶端用戶是否具有向應(yīng)用服務(wù)器提供商的預(yù)訂。)適用于諸如通過URI標(biāo)識媒體流的RTSP等遺留協(xié)議的本發(fā)明的進(jìn)一步改進(jìn)可讓應(yīng)用使用不同的URI，根據(jù)媒體流是否要接受QoS處理來標(biāo)識其它相同的媒體流。NGN中的所有SIWF將必須能夠區(qū)分兩種類型的URI。參照圖11，在建立消息到達(dá)服務(wù)SIWF的客戶端時(shí)，它將檢查目的地URI，并只在URI指示應(yīng)用服務(wù)器“請求” 了 QoS處理時(shí)才將建立消息轉(zhuǎn)換為SIP邀請消息。否則，SIWF功能忽略建立消息，并且它以標(biāo)準(zhǔn)遺留方式行進(jìn)到應(yīng)用服務(wù)器而無進(jìn)一步的網(wǎng)絡(luò)涉及。本領(lǐng)域的技術(shù)人員將認(rèn)識到有許多方案能用于區(qū)分URI : —個(gè)示例將是使用服務(wù)器的服務(wù)域的IMS域名作為附加到應(yīng)用服務(wù)器自己的URL后的URI的域部分。在上述的本發(fā)明的第三方面，為建立QoS承載流量，服務(wù)器需要是SIP講述者，但服務(wù)器與客戶端之間的協(xié)議被忽略。另一方面，在上述第四方面，客戶端與服務(wù)器之間的協(xié)議被轉(zhuǎn)換成SIP。正如可理解的一樣，組合這兩種方法是可能的。圖12示出提供用于在應(yīng)用服務(wù)器與客戶端之間的QoS承載路徑的NGN實(shí)施例，其中，應(yīng)用服務(wù)器使用到本地SIffF網(wǎng)關(guān)的遺留信令協(xié)議以請求QoS，并且SIWF網(wǎng)關(guān)將信令轉(zhuǎn)換成到客戶端TE的服務(wù)網(wǎng)關(guān)(p-CSCF控制)的SIP消息。有兩種情況要考慮。在一種情況下，客戶端不是遺留信令協(xié)議的講述者。服務(wù)器使用遺留信令協(xié)議，這是因?yàn)樗萐IP更易于實(shí)現(xiàn)。這在用于RSVP情況的圖13中示出。注意，雖然在此情況下，在使用RSVP時(shí)，SIffF功能(或至少RSVP消息的檢測)必須在服務(wù)器的服務(wù)AG中托管，但對于諸如允許配置代理(即，消息是通過IP尋址到代理)的RTSP等其它協(xié)議，SIffF功能 無需在服務(wù)器與客戶端之間的分組的直接路徑中。具體而言，SIWF功能能包括在服務(wù)器的服務(wù)p-CSCF中。在另一情況下，遺留信令協(xié)議在客戶端與服務(wù)器之間交換，但它也由服務(wù)器的SIWF進(jìn)行檢查而不是修改。對于RTSP的情況，這通過圖14示出。這種情況下，SIWF功能充當(dāng)透明代理(即，RTSP分組不要尋址到它)，并且因此必須是服務(wù)AG的一部分。本文中所述的方法和系統(tǒng)因而克服了現(xiàn)在MS的限制，該限制是只處理通過SIP講述端點(diǎn)之間的RTP提供的多媒體。本文中一起描述和聲明的發(fā)明允許任何內(nèi)容在從任何內(nèi)容源到任何目的地的QoS承載流量上提供，同時(shí)保持了 MS的安全和收費(fèi)框架，為下一代網(wǎng)絡(luò)的運(yùn)營商從客戶和應(yīng)用服務(wù)提供商擴(kuò)大了新的收入來源。上述本發(fā)明的實(shí)施例僅旨在說明。因此，本發(fā)明的范圍將只受隨附權(quán)利要求的范圍的限制。
權(quán)利要求
1.一種在通信網(wǎng)絡(luò)中使用的呼叫狀態(tài)控制功能CSCF設(shè)備，在該通信網(wǎng)絡(luò)中會話啟動協(xié)議SIP用于建立帶有承載流量的QoS處理的通信會話，所述CSCF設(shè)備被配置成通過如下各項(xiàng)提供目的地是經(jīng)連接到附接網(wǎng)關(guān)的附接段附接到所述網(wǎng)絡(luò)的非SIP客戶端的承載流量的QoS處理 接收有關(guān)所述承載流量的SIP邀請消息，所述SIP邀請消息包含通用資源標(biāo)識符URI，所述通用資源標(biāo)識符將所述非SIP客戶端標(biāo)識為所述承載流量的目的地； 嘗試根據(jù)所述SIP邀請消息中標(biāo)識的業(yè)務(wù)規(guī)范T-Spec，在所述附接段上安裝QoS策略； 檢測安裝所述QoS策略的所述嘗試的結(jié)果；以及 代表所述非SIP客戶端生成適當(dāng)?shù)腟IP訊息，以基于檢測到的結(jié)果接受或拒絕所述承載流量。
2.如權(quán)利要求I所述的CSCF設(shè)備，其中標(biāo)識所述SIP邀請消息中所述非SIP客戶端的所述URI是服務(wù)網(wǎng)關(guān)URI，該服務(wù)網(wǎng)關(guān)URI解析成為到達(dá)所述非SIP客戶端而由所述附接網(wǎng)關(guān)通告的因特網(wǎng)協(xié)議IP地址。
3.如權(quán)利要求I所述的CSCF設(shè)備，其中所述CSCF控制所述附接網(wǎng)關(guān)，所述CSCF被進(jìn)一步配置成接收所述SIP邀請消息，嘗試安裝所述QoS策略和檢測安裝所述QoS策略的所述嘗試的結(jié)果。
4.如權(quán)利要求3所述的CSCF設(shè)備，其中所述CSCF被進(jìn)一步配置成在安裝所述QoS策略的所述嘗試不成功時(shí)，代表所述非SIP客戶端生成適當(dāng)?shù)腟IP訊息。
5.如權(quán)利要求3所述的CSCF設(shè)備，其中所述CSCF被進(jìn)一步配置成在安裝所述QoS策略的所述嘗試成功時(shí)，通過將所述SIP邀請消息轉(zhuǎn)發(fā)到所述非SIP客戶端的一般客戶端代理，代表所述非SIP客戶端生成適當(dāng)?shù)腟IP訊息，所述一般客戶端代理響應(yīng)所述SIP邀請消息的接收，代表所述非SIP客戶端生成所述SIP訊息。
6.如權(quán)利要求5所述的CSCF設(shè)備，其中所述一般客戶端代理是所述CSCF功能性的擴(kuò)展。
7.如權(quán)利要求I所述的CSCF設(shè)備，其中所述SIP邀請消息包括所述承載流量的所期望的QoS處理的顯式標(biāo)識。
8.如權(quán)利要求7所述的CSCF設(shè)備，其中所期望的QoS處理的所述顯式標(biāo)識包括至少標(biāo)識所需帶寬的彳目息。
9.如權(quán)利要求8所述的CSCF設(shè)備，其中所述信息包括至少代表預(yù)定帶寬的標(biāo)識符。
10.如權(quán)利要求7所述的CSCF設(shè)備，其中所期望的QoS處理的所述顯式標(biāo)識還包括標(biāo)識所需業(yè)務(wù)類的信息。
全文摘要
本發(fā)明提供下一代網(wǎng)絡(luò)中用于非SIP講述者的服務(wù)網(wǎng)關(guān)代理。用于擴(kuò)展NGN的IMS/SIP體系結(jié)構(gòu)以向一般承載流量提供QoS服務(wù)的方法和系統(tǒng)。對于目的地是經(jīng)連接到附接網(wǎng)關(guān)的附接段附接到網(wǎng)絡(luò)的非SIP客戶端的承載流量，支持其QoS處理。接收有關(guān)承載流量的SIP邀請消息。SIP邀請消息包含將非SIP客戶端標(biāo)識為承載流量的目的地的通用資源標(biāo)識符(URI)。根據(jù)SIP邀請消息中標(biāo)識的業(yè)務(wù)規(guī)范(T-Spec)，嘗試在附接段上安裝QoS策略，并且檢測安裝嘗試的結(jié)果。代表非SIP客戶端生成適當(dāng)?shù)腟IP訊息以基于檢測到的結(jié)果接受或拒絕承載流量。
文檔編號H04L29/06GK102882866SQ20121035203
公開日2013年1月16日 申請日期2007年11月15日 優(yōu)先權(quán)日2006年12月14日
發(fā)明者L.凱西 申請人:北方電訊網(wǎng)絡(luò)有限公司