專利名稱：在下一代網(wǎng)絡(luò)中提供sip交互工作的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及下一代網(wǎng)絡(luò)，并且尤其涉及下一代網(wǎng)絡(luò)中SIP交 互工作(interworking)的提供'
背景技術(shù)：
目前，各種國際標(biāo)準(zhǔn)團(tuán)體和協(xié)會(huì)(例如第三代合作計(jì)劃 (3GPP)、歐洲電信標(biāo)準(zhǔn)協(xié)會(huì)(ETSI)和國際電信聯(lián)盟(ITU)) 正在參與定義下一代網(wǎng)絡(luò)的項(xiàng)目。根據(jù)ITU-T，下一代網(wǎng)絡(luò)(NGN ) 是基于包的網(wǎng)絡(luò)，可以提供包括電信服務(wù)的服務(wù)并且可以使用多 個(gè)寬帶的、允許QoS的傳輸技術(shù)，并且在其中服務(wù)相關(guān)功能獨(dú)立 于底層的傳輸相關(guān)的技術(shù)。NGN提供了用戶到不同服務(wù)供應(yīng)商的 無限制接入。它還支持普通的移動(dòng)性，其可以使得向用戶提供一 致的、無處不在的服務(wù)。
下一代網(wǎng)絡(luò)總體上基于互聯(lián)網(wǎng)多媒體子系統(tǒng)(IMS)架構(gòu)，并 且釆用會(huì)話發(fā)起協(xié)議(SIP )用于管理建立和拆除各方間的通信會(huì) 話。這種布置的優(yōu)勢在于，IMS/SIP提供互聯(lián)網(wǎng)協(xié)議(IP)網(wǎng)絡(luò) 的框架來以下列方式建立包括互聯(lián)網(wǎng)協(xié)議(VoIP)電話呼叫的多 媒體會(huì)話，該方式防止了欺騙并且允許使用跟目前公共交換電話 網(wǎng)絡(luò)(PSTN)和蜂窩網(wǎng)絡(luò)運(yùn)營商采用的方法非常相似的方法進(jìn)行 后續(xù)的記賬和域間結(jié)算.也就是說，用戶可以與按交付的服務(wù)類 型相關(guān)的收費(fèi)，為每個(gè)單獨(dú)的的呼叫/會(huì)話付賬，并且這些收費(fèi)可 以被合適地分配給呼叫/會(huì)話經(jīng)過的每個(gè)承載網(wǎng)絡(luò)(或者管理域)。 如同在PSTN中的情況一樣，可以想象，NGN將由多個(gè)運(yùn)營 商/管理域組成，并且IMS架構(gòu)為一個(gè)運(yùn)營商的用戶提供了基礎(chǔ)， 以與另一個(gè)運(yùn)營商的用戶建立語音呼叫或多媒體會(huì)話，其方式是 使得雙方運(yùn)營商(和任何中間運(yùn)營商)在它們各自的管理域內(nèi)保留必要的網(wǎng)絡(luò)資源來支持運(yùn)送與該會(huì)話關(guān)聯(lián)的語音或多媒體流的
承栽包流所需的服務(wù)質(zhì)量(QoS).進(jìn)一步，IMS架構(gòu)全面支持 端用戶的漫游，其方式是使得訪問域以與主域相同的方式支持承 栽流QoS。
圖1示意性地示出了典型的下一代網(wǎng)絡(luò)架構(gòu)。如同在PSTN 和互聯(lián)網(wǎng)中一樣，NGN被期望為多個(gè)管理域網(wǎng)絡(luò)的聚集。管理域 的業(yè)務(wù)可以主要是服務(wù)于最終用戶的或者是向其他管理域提供轉(zhuǎn) 接(transit)的.對于本申請來說，提供管理域的轉(zhuǎn)接的網(wǎng)絡(luò)被 稱為轉(zhuǎn)接網(wǎng)絡(luò)(TN) 2.服務(wù)于最終用戶的管理域由兩種類型的 網(wǎng)絡(luò)組成核心IP網(wǎng)絡(luò)(CN )4和一個(gè)或多個(gè)配屬(attachment) (或"接入")網(wǎng)絡(luò)(AN) 6,其通過配屬網(wǎng)關(guān)10將最終用戶的終 端設(shè)備(TE) 8"連接，，到核心網(wǎng)絡(luò)4，使得他們可以接收IMS服 務(wù).AN們通常被認(rèn)為與它們連接的CN在相同的管理域內(nèi)，即使 它們由分立的商業(yè)實(shí)體(AN運(yùn)營商)運(yùn)行(CN運(yùn)營商從它們那 里購買"批發(fā)接入")。注意，雖然轉(zhuǎn)接網(wǎng)絡(luò)和核心網(wǎng)絡(luò)都基于每 個(gè)包報(bào)頭內(nèi)的目標(biāo)IP地址來路由IP包，但是AN在TEs和CN 配屬點(diǎn)之間傳輸包而與IP地址無關(guān)，當(dāng)配屬網(wǎng)絡(luò)可以如同有線或 時(shí)域多路復(fù)用(TDM)電路那樣簡單時(shí)，它通常由特定介質(zhì)的最 后一英里網(wǎng)絡(luò)(media specific first mile network)和更廣泛的 包回程網(wǎng)絡(luò)(packet backhaul network)組成(在3GPP無線 專門名詞中，這種回程網(wǎng)絡(luò)用術(shù)語"核心"表示，但是它仍然是AN 的一部分并且不與CN混淆)，
在圖1所示的網(wǎng)絡(luò)架構(gòu)中，通過由每個(gè)網(wǎng)絡(luò)中的傳輸邊界網(wǎng) 關(guān)(TBG) 14掌控(host)的交換鏈路12,在各種核心和轉(zhuǎn)接 網(wǎng)絡(luò)之間傳輸包 對于任何一對網(wǎng)絡(luò)，交換鏈路可以是物理鏈路 或者某些形式的虛擬電路。本領(lǐng)域中的技術(shù)人員將認(rèn)識(shí)到，多個(gè) 網(wǎng)絡(luò)也可以在非連接交換網(wǎng)絡(luò)(XN)上進(jìn)行互連.XN的范圍可 以從單個(gè)以太網(wǎng)交換機(jī)到全球|p網(wǎng)絡(luò)或虛擬專用網(wǎng)絡(luò)
IWIS被規(guī)定為使用會(huì)話發(fā)起協(xié)議(SIP)建立和拆除多媒體呼 叫或會(huì)話。IMS架構(gòu)規(guī)定了多個(gè)遍布網(wǎng)絡(luò)的呼叫狀態(tài)控制功能(CSCF),其處理SIP消息并根據(jù)SIP消息動(dòng)作，在特定會(huì)話 的建立中，SIP消息傳遞需要被至少與會(huì)話的發(fā)起方關(guān)聯(lián)的發(fā)起 服務(wù)CSCF (S-CSCF)和與會(huì)話建立的對象或目標(biāo)關(guān)聯(lián)的目標(biāo) S-CSCF處理。但是，通常SIP客戶端并不直接對等(peer)與 它們關(guān)聯(lián)的S-CSCF,并且還有中間CSCFs，它們在SIP客戶端 和與它們關(guān)聯(lián)的S-CSCF之間以及在發(fā)起和目標(biāo)CSCF之間路由 和轉(zhuǎn)發(fā)SIP消息，與本申請?zhí)貏e相關(guān)的是負(fù)責(zé)在管理域之間轉(zhuǎn)發(fā) SIP消息的對等CSCF,在本描述中，我們將任何一個(gè)CSCF (只 要是管理域中最后將SIP消息轉(zhuǎn)發(fā)到其他域的那個(gè)，或者只要是 管理域中最先從其他域接收SIP消息的那個(gè))指定為邊界CSCF
(b-CSCF).那些熟悉3GPP和/或其他NGN標(biāo)準(zhǔn)的專業(yè)人員將 認(rèn)識(shí)到，關(guān)于如何構(gòu)建邊界控制功能還存在一些爭論。術(shù)語 "b-CSCF"用于包含這樣的功能單元，例如詢問-CSCF(卜CSCF)、 互連邊界控制功能(舊CF)和出口網(wǎng)關(guān)控制功能(BGCF)的多 個(gè)方面。當(dāng)邊界控制不是運(yùn)營商強(qiáng)烈要求的時(shí)候，即便是S-CSCF 也可以是b-CSCF。
在配屬網(wǎng)絡(luò)中沒有CSCF-所謂的代理-CSCF (P-CSCF)的 對等實(shí)體實(shí)際上是終端設(shè)備的SIP客戶端功能，由于SIP客戶端
(特別是在應(yīng)用服務(wù)器(AS) 8b中的SIP客戶端)可能直接與 S-CSCF對等，所以在本說明中，我們使用術(shù)語邊緣-CSCF
(p-CSCF)來指代笫一個(gè)/最后一個(gè)處理來自/到SIP客戶端8的 SIP消息的CSCF.圖1描迷在會(huì)話建立中，漫游TE8(配屬于
(attached to)訪問的核心網(wǎng)絡(luò))和應(yīng)用服務(wù)器AS8b之間的相 關(guān)的CSCF,其中主核心網(wǎng)絡(luò)被轉(zhuǎn)接網(wǎng)絡(luò)2分隔，
會(huì)話的媒體流作為承栽(包)流在網(wǎng)絡(luò)上傳輸.在IP包環(huán)境 中，由于承栽流路徑不要求經(jīng)過掌控(hosting) CSCF功能的節(jié) 點(diǎn)，所以承栽流路徑并不自動(dòng)地與SIP信令經(jīng)過的路徑相同。域 間承栽流在節(jié)點(diǎn)(這里稱為傳輸邊界網(wǎng)關(guān)(TBG) 14)處離開和 進(jìn)入管理域。同樣，配屬網(wǎng)絡(luò)和核心網(wǎng)絡(luò)之間的情況是有區(qū)別的 核心網(wǎng)絡(luò)中與配屬網(wǎng)絡(luò)接口的節(jié)點(diǎn)有各種稱呼服務(wù)邊緣、核心網(wǎng)絡(luò)邊緣、邊界節(jié)點(diǎn)、接入媒體網(wǎng)關(guān)、接入路由器或者接入網(wǎng)絡(luò)
類型專門術(shù)語，例如GPRS網(wǎng)關(guān)支持節(jié)點(diǎn)(GGSN)或者寬帶遠(yuǎn) 程接入服務(wù)器(BRAS)。在本描述中，我們將使用術(shù)語配屬網(wǎng)關(guān) (AG) 10。 AG跨越AN6和CN4之間的邊界，
規(guī)定承栽流QoS需求
如本領(lǐng)域中所知的，發(fā)起會(huì)話的SIP消息運(yùn)送與該會(huì)話關(guān)聯(lián) 的承栽流(如果需要的話，多個(gè)承栽流)的描述。該描述采用會(huì) 話描述協(xié)議(SDP)的參數(shù)的形式.參見，例如，Handley，M.和 V.Jacobson的"SDP: session description protocol",評(píng)論請 求2327, 1998年4月。目前，SIP消息的SDP部分給出承栽流 要包含的信息(即，語音或視頻和所使用的編解碼器和比特率) 的完整描述。該信息最初的目的在于使得端系統(tǒng)指定它們希望如 何將語音或視頻數(shù)據(jù)編碼成實(shí)時(shí)協(xié)議包(realtime protocol)。
在IMS解決方案中，SDP參數(shù)還可以由各種網(wǎng)絡(luò)域(位于端 系統(tǒng)之間)中的CSCF解釋，以確定承栽路徑網(wǎng)絡(luò)的特性。通常 這種信息源自SDP的媒體行(以m-開始)。例如下式中的最后 一個(gè)參數(shù)
m=audio 8004 RTP/AVP 9
表示音頻承栽流是根據(jù)音頻視覺概要audio visual profile, AVP)9進(jìn)行編碼的，其剛好是G.722，其是64kb/s的流(網(wǎng)絡(luò) 需求同樣必須包括包頭等，從而使它增大至大約100kb/s).
基于SDP參數(shù)，CSCF執(zhí)行以連接許可控制(CAC)名義進(jìn) 行的過程，盡管該過程更準(zhǔn)確地應(yīng)被稱為會(huì)話許可控制(Session Admission Control) . CAC過程確定承載流的資源需求，使得 可以以期望的QoS傳遞嵌入的媒體流，如果域沒有支持新承栽流 的資源，那么相關(guān)的CSCF將終止會(huì)話建立。3GPP文檔《3GPP TS 23.207》中提供了這點(diǎn)(對于p-CSCF和AG)的描述，
業(yè)務(wù)類別(Traffic Classes )業(yè)務(wù)類別在某種程度上是不確定的概念，在不同業(yè)務(wù)管理模
型中其以不同的術(shù)語表示(capture),在IETF IntServ模型中 有三種業(yè)務(wù)類別"保證的，'(guaranteed )、"控制負(fù)栽的"
(controlled load)和"盡力而為的，'(best effort)。有點(diǎn)類似 的，舊TF DiffServ模型提供了三種業(yè)務(wù)量轉(zhuǎn)發(fā)行為加速轉(zhuǎn)發(fā)
(EF)、確保轉(zhuǎn)發(fā)(盡管AF業(yè)務(wù)可以有多至4個(gè)的類別)和默 認(rèn)或盡力轉(zhuǎn)發(fā).ITU研究組根據(jù)延時(shí)和轉(zhuǎn)接(還有呑吐量)加上 各種因素(例如，包損失比率和如何處理規(guī)范以外或者延時(shí)的包) 來定義服務(wù)的業(yè)務(wù)類別.
在NGN的實(shí)際部署中，有一種使延時(shí)和抖動(dòng)二者盡可能小的 業(yè)務(wù)量類別，用于實(shí)時(shí)通話(或者運(yùn)營商可以選擇若干這樣的類 別， 一種用于語音通話， 一種用于視頻電話， 一種用于游戲)， 還有另一種類別，其以一定范圍的抖動(dòng)來確保吞吐量，適用于媒 體流的播放(同樣，運(yùn)營商可以選擇在語音和視頻之間作區(qū)分)。 由于從來沒有任何專用于盡力而為業(yè)務(wù)的資源，所以使用SIP建 立盡力而為流幾乎沒有實(shí)用性，但是為完整起見，可能有這樣被 定義的編碼點(diǎn)。
QoS控制和處理的范圍
圖2示出被劃分成片段20的承載流18.承栽流的每個(gè)片段 20經(jīng)過單個(gè)包傳輸網(wǎng)絡(luò)2-6并且被端設(shè)備或網(wǎng)關(guān)14定界。承栽 流片段20可以由它們在上面?zhèn)鬏數(shù)木W(wǎng)絡(luò)的類型命名對于穿越配 屬網(wǎng)絡(luò)的承栽流的部分就是配屬片段，等等.
可能不需要向承栽流包提供的特定處理擴(kuò)展到端到端。被廣 泛接受的是，如果特定的包傳輸網(wǎng)絡(luò)被提供過多的包Us over provisioned)，那么對所有包的QoS處理將足以支持任何特定 的承栽流.本領(lǐng)域的技術(shù)人員還將認(rèn)識(shí)到，Diffserv可以被用于 模擬特定業(yè)務(wù)類別的過度提供.可以想象一些或所有的核心網(wǎng)路 將會(huì)被過度提供(或使用Diffserv來為IMS包模仿過度提供)， 其結(jié)果是將不需要為經(jīng)過了這些被過度提供的核心網(wǎng)絡(luò)的承栽流的核心片段保留資源。但是，很可能的是，資源將不得不為配屬 片段而保留，以確保在那些片段上的流的包的傳輸不會(huì)使端到端
流的QoS降低到該流所支持的服務(wù)的可接受水平之下。 資源和許可控制功能(RACF)
為承栽流而保留資源的功能與會(huì)話的許可控制緊密相關(guān)，其 中承栽流是會(huì)話的組成部分。在對現(xiàn)有對話的當(dāng)前給出的服務(wù)質(zhì) 量水平承諾下，如果鏈路上的帶寬容量、節(jié)點(diǎn)上的轉(zhuǎn)發(fā)容量不足 或者缺少為新會(huì)話的承栽流而傳遞請求的QoS所需的其他資源， 那么該會(huì)話建立被終止并且為那個(gè)會(huì)話已經(jīng)保留的任何資源被釋 放。
更普遍地，在會(huì)話建立之前，需要做出關(guān)于是否許可該會(huì)話 的多個(gè)策略決定.在IMS架構(gòu)中，這些確定在CSCF發(fā)起，由會(huì) 話建立中的第一消息的處理觸發(fā)SIP邀請(SIP INVITE)消息。 一些策略決定的執(zhí)行被限制在CSCF,但是與承栽流QoS相關(guān)的 那些由控制CSCF以信號(hào)方式發(fā)送到網(wǎng)關(guān)，圖3示出對于包含兩 個(gè)域的會(huì)話，在配屬網(wǎng)關(guān)(AG) 10和傳輸邊界網(wǎng)關(guān)(TBG) 14 中分別由p-CSCF和b-CSCF進(jìn)行的對RACF功能的控制.那些 熟悉NGN標(biāo)準(zhǔn)的專業(yè)人員將認(rèn)識(shí)到，在IMS架構(gòu)中，在CSCF 和網(wǎng)關(guān)之間存在中間策略決定功能(PDF)，其形成(資源和許 可控制子系統(tǒng))RACS網(wǎng)絡(luò)層。象在請求QoS承栽流的不同應(yīng)用 之間的仲裁那樣，PDF可以向CSCF出示配屬網(wǎng)絡(luò)QoS控制規(guī) 范的抽象圖，也可以隱藏AG和TBG的拓樸.
不管有優(yōu)點(diǎn)，但是NGN受到一些限制，因?yàn)镮MS被設(shè)計(jì)成 向通過實(shí)時(shí)包(RTP)包流傳輸?shù)亩嗝襟w業(yè)務(wù)(包括視頻和/或 VoIP)提供QoS處理，但是，有許多其他業(yè)務(wù)類型將從QoS處 理的應(yīng)用中獲益。另外，沒有了由IWIS支持的記賬和結(jié)算功能， 網(wǎng)絡(luò)服務(wù)供應(yīng)商幾乎沒有動(dòng)機(jī)在還支持除多媒體和VoIP以外業(yè) 務(wù)類型所需的NGN技術(shù)上投資。INS的進(jìn)一步的限制是通信會(huì)話 的雙方必需是SIP客戶端，這造成了 NGN部署的障礙，因?yàn)閱蝹€(gè)最終用戶必須遷移到"SIP可用的"應(yīng)用。
因此，支持下一代網(wǎng)絡(luò)中SIP和遣留協(xié)議之間的交互工作的
方法和技術(shù)仍然是非常需要的。

發(fā)明內(nèi)容
本發(fā)明的一個(gè)目標(biāo)是提供在下一代網(wǎng)絡(luò)中SIP和遺留協(xié)議之
間交互工作的方法和技術(shù)。
因此，本發(fā)明的一個(gè)方面是，在使用會(huì)話發(fā)起協(xié)議(SIP)建 立具有承栽流的QoS處理的通信會(huì)話的通信網(wǎng)絡(luò)中，在使用不同 的帶內(nèi)信令協(xié)議在兩個(gè)端設(shè)備之間建立的通信會(huì)話內(nèi)，提供一種 承栽流的QoS處理的方法。在兩個(gè)端設(shè)備之間的帶內(nèi)信令的路徑 中提供信令交互工作功能(SIWF)。該SIWF搮作用于檢測帶 內(nèi)信令的至少一個(gè)信號(hào)狀態(tài)；以及基于檢測到的信號(hào)狀態(tài)，建立 具有承栽流的QoS處理的通信會(huì)話，該承栽流跨越(spanning ) 兩個(gè)端點(diǎn)之間的端到端路徑的至少 一 部分.
本發(fā)明并不特別針對任何具體的業(yè)務(wù)管理模型，但僅僅假定 存在多個(gè)由運(yùn)營商協(xié)定的業(yè)務(wù)類別，并且期望的承栽流的業(yè)務(wù)類 別可以作為SDP中的參數(shù)被規(guī)定.
本發(fā)明假定對于每個(gè)AG,有p-CSCF(同樣地，對于每個(gè) TBG,有p-CSCF)，它可以為經(jīng)過那個(gè)網(wǎng)關(guān)的承栽流請求QoS 處理，不管用于它們交互通信的中間PDF、節(jié)點(diǎn)和專有協(xié)議選擇 的數(shù)量(如果有的話).具體承載流的承栽片段的QoS處理可以 通過向在該片段的一端的網(wǎng)關(guān)推行策略，以單端的方式設(shè)置，或 者可以通過向在該片段的兩端的網(wǎng)關(guān)推行策略，以雙端的方式設(shè) 置.如上所定義的，網(wǎng)關(guān)是承我流的一個(gè)承載片段的端點(diǎn)和它的 下一個(gè)片段的起點(diǎn)推行到該網(wǎng)關(guān)的單個(gè)策略可以用于為兩者的 片段請求QoS資源.
本領(lǐng)域中的專業(yè)技術(shù)人員將認(rèn)識(shí)到，有幾種不同的方法用于 請求網(wǎng)關(guān)為承栽片段提供QoS:所謂的"推行(PUSH)"方法 導(dǎo)致網(wǎng)關(guān)從CSCF(或者通過策略決定功能的分層)直接接收"策略決定"來提供具有指定的QoS的承栽片段，并且網(wǎng)關(guān)然后向 CSCF回復(fù)它具有資源來"強(qiáng)制執(zhí)行"策略或者它不具有該資源， 之后的描述依照RACS的"推行"模式來闡述，但是本發(fā)明意在 使其工作與如何將QoS需求通信至網(wǎng)關(guān)無關(guān)。事實(shí)上，如本領(lǐng)域 中的專業(yè)技術(shù)人員將認(rèn)識(shí)到的，"帶寬代理"可以保持對鏈路或
但是，假定片段開始于或結(jié)束于域間邊界，則存在下列額外的理 由使網(wǎng)關(guān)具有以信號(hào)方式發(fā)送給它們的新的承栽片段的規(guī)范制 訂承栽流的策略，改變Diffserv標(biāo)記，生成記賬記錄.雖然不可 能在交換鏈路或網(wǎng)絡(luò)上需要進(jìn)行實(shí)際的資源保留，但是RAC功能 將很可能被b-CSCF調(diào)用以檢查每個(gè)管理域?qū)Σ呗缘倪B守，該策 略涉及它準(zhǔn)備從其他處接受的流的類型和數(shù)量，


本發(fā)明的其他特點(diǎn)和優(yōu)點(diǎn)將因?yàn)橐韵陆Y(jié)合所附附圖的詳細(xì)描 述而變得更顯而易見.
圖1是示意性地示出了典型的下一代網(wǎng)絡(luò)架構(gòu)的框圖，在該 下一代網(wǎng)絡(luò)架構(gòu)中可以實(shí)施本發(fā)明的方法；
圖2是示意性地示出圖1的網(wǎng)絡(luò)中的承栽流片段的框困3是示意性地示出對于包含兩個(gè)域的會(huì)話，對資源和許可 控制功能的控制的框困；
圖4是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的使用對鎖定式 (pin)承栽片段的網(wǎng)絡(luò)地址映射的框圖5是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的在包含多個(gè)承 栽偏度的網(wǎng)絡(luò)中使用對鎖定式承栽片段的網(wǎng)絡(luò)地址映射的框圖6是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的在包含多個(gè)IP 地址域的網(wǎng)絡(luò)中使用對鎖定式承栽片段的網(wǎng)絡(luò)地址映射的框圖7是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的支持非SIP客 戶端的方法的框閨；
圖8是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的在包含多個(gè)IP
而無需發(fā)送信令到處于端點(diǎn)的網(wǎng)關(guān)。地址域的網(wǎng)絡(luò)中支持非SIP客戶端的方法的框困；
圖9是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的與遺留協(xié)議交 互工作的方法的框圖10是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的RSVP到SIP 交互工作的方法的消息流圖11是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的RTSP到SIP 交互工作的方法的消息流圖12是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的支持與遣留 協(xié)議交互工作的服務(wù)器的操作的框圖13是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的用于支持 RSVP到SIP交互工作的服務(wù)器的操作的消息流圖；以及
圖14是示意性地示出根據(jù)本發(fā)明的一個(gè)方面的用于支持 RTSP到SIP交互工作的服務(wù)器的操作的消息流困。
注意，在所有附圖中，相同的特征以相同的參考數(shù)字標(biāo)識(shí)。
具體實(shí)施例方式
本發(fā)明提供在下一代網(wǎng)絡(luò)中能夠?qū)ζ胀ǔ性粤髯鱍oS處理的 方法和技術(shù)，以下參照圖4-14，僅以實(shí)例的方式描述本發(fā)明的實(shí) 施例。
總體上，本發(fā)明提供的方法和系統(tǒng)可單獨(dú)或者組合使用來擴(kuò) 展NGN的,MS/SIP系統(tǒng)，以向普通承栽流提供QoS服務(wù)。這些 方法和系統(tǒng)可以被寬泛地分成4個(gè)類別，即SIP到普通承栽流 的擴(kuò)展；把通信會(huì)話的承栽流到用于建立會(huì)話的SIP信令所經(jīng)過 的AG和TBG上的鎖定(pinning);非SIP客戶端的支持；和 用于遺留IP信令的網(wǎng)關(guān)功能性.這些類別的每一個(gè)將通過典型的 例子在以下描述中進(jìn)行解釋，
應(yīng)當(dāng)注意，本申請主要針對用于普通承栽流的遺留信令的網(wǎng) 關(guān)功能性。用于把通信會(huì)話的承栽流鎖定到被用于建立會(huì)話的S，P 信令經(jīng)過的AG和TBG上以及對非SIP客戶端的支持的技術(shù)分別 是申請人的共同未決的美國專利申請?zhí)杧x/xxx,xxx (題為Pinning the Route of IP Bearer Flows in a Next Generation Network)和yy/yyy，yyy (題為Serving Gateway Proxies for non SIP speakers in a Next Generation Network )關(guān)注的焦點(diǎn)， 這兩者隨本申請同時(shí)提交.
普通承栽流
當(dāng)前定義的SIP和IMS受限于它們只能處理作為多媒體流的 承栽流。但是如果許多其它的應(yīng)用的承栽流能夠被IMS識(shí)別，那 么它們可以利用IMS架構(gòu)。
根據(jù)本發(fā)明的一個(gè)方面，通過下列方式可以客戶該限制加 入描述普通承栽流的QOS要求的顯式業(yè)務(wù)規(guī)范(T-Spec)參數(shù) 到SIP信令中的SDP;并且擴(kuò)展IMS中的RACS機(jī)制以解釋新 的T-Spec參數(shù)，在SIP信令的SDP部分加入顯式T-Spec參數(shù) 可使得兩個(gè)SIP端點(diǎn)為下列任何任意的流請求網(wǎng)絡(luò)執(zhí)行資源分配 和/或連接許可控制普通承栽流.因此，盡管對于RTP或多媒體 承栽流，IMS功能單元從媒體編碼和其他媒體描述性SDP參數(shù)中 推導(dǎo)出資源需求，但是對于普通承栽流，CSCF將使用顯式T-Spec 參數(shù)作為資源和許可控制處理的基礎(chǔ)。
例如，考慮在其中采用ITU推薦Y.1541的服務(wù)指定類別的網(wǎng) 絡(luò).在該例中，根據(jù)RFC2327的指南，顯式T-Spec可以由兩個(gè) 媒體層面的屬性行組成， 一個(gè)指定Y.1541服務(wù)類別并且另一個(gè)指 定要求的容量或帶寬.因此
a=ITU- CLassOfService:O a=ITU- Capacity:O
上式可以被用于指定承栽流要求的100kb/s和服務(wù)類別0 (即，根據(jù)Y.1541,端到端的延時(shí)少于100毫秒等)。
如杲需要的話，可以使用其它方法來表達(dá)顯式T-Spec參數(shù). 例如，下面描述的表示方案中，運(yùn)營商可以選擇分配名稱給帶寬和業(yè)務(wù)類別的組合，其使得可以使用單個(gè)SDP屬性(即，分配的 名稱)來提供顯式T-Spec.
例子使用
一個(gè)旅游企業(yè)雇員使用VPN客戶端建立從她的膝上型計(jì)算機(jī) 返回到她的企業(yè)VPN服務(wù)器的IPSec隧道，使得她可以接入企業(yè) 網(wǎng)絡(luò)的設(shè)施，包括它的IP PBX以撥打和接收電話呼叫.如果該 IPSec隧道是在盡力而為型互聯(lián)網(wǎng)上被建立的，那么加密包的延 時(shí)、抖動(dòng)和損失比率將會(huì)不確定并且將不足以支持其膝上型計(jì)算 機(jī)上的軟客戶端和企業(yè)IP PBX之間的VolP會(huì)話.為保證QoS 對于IPSec隧道中的語音包時(shí)合適的，要求將IPSec隧道作為普 通承栽來對待。
支持普通承載的運(yùn)營商可以為每個(gè)業(yè)務(wù)類別的有限數(shù)量的帶 寬(傳輸容量)選擇收費(fèi)標(biāo)準(zhǔn)，然后對傳輸容量和業(yè)務(wù)類別的每 個(gè)組合賦予標(biāo)準(zhǔn)的名稱。例子可以是
votel=100kb/s最小延時(shí)、最小抖動(dòng)、收費(fèi)標(biāo)準(zhǔn)$0.02每分
鐘，
vidtel-1Mb/s最小延時(shí)、最小抖動(dòng)、$0.10,
sdtv-1.5Mb/s下游、保證的吞吐量、$0.03;
hdtv=8Mb/s下游、保證的吞吐量、$0.06;
它們分別用于語音電話、視頻電話、標(biāo)準(zhǔn)清晰度視頻流和高 清晰度視頻流的目的.標(biāo)準(zhǔn)名稱然后可以被用作SIP消息的SDP 部分中的獨(dú)有的T-Spec參數(shù)。在該例中，將"votel"QoS分配給 普通承栽將足以支持用戶VolP會(huì)話.
在企業(yè)現(xiàn)場的VPN服務(wù)器被連接到一些運(yùn)營商的NGN網(wǎng)絡(luò) 并且被注冊到那個(gè)域.對于本描述，假設(shè)如果VPN客戶端和VPN 服務(wù)器之間有多個(gè)管理域，那么VPN客戶端和VPN服務(wù)器之間 的IP包的正常路由行為經(jīng)過與SIP信令相同的域的鏈，并且假設(shè) 關(guān)于包使用那個(gè)TBG14沒有歧義(后面詳細(xì)描迷鎖定承栽流以使 用特定的TBG).VPN客戶端8的SIP客戶端部分22在公共IMS域中注冊. 作為結(jié)果，根據(jù)IMS的正常操作，主s-CSCF現(xiàn)在可以向客戶端 發(fā)送SIP信令消息。(注意，VPN客戶端8的SIP客戶端部分 22區(qū)別于膝上型計(jì)算機(jī)上的軟電話SIP客戶端-它們可以共享公 共編碼，但是最終，軟電話SIP客戶端將向企業(yè)IP PBX注冊。 一種可替代的實(shí)現(xiàn)是可以使用可被雙重注冊的單個(gè)SIP客戶端)。
建立VPN客戶端8和VPN服務(wù)器之間的安全機(jī)制(security association),然后使用IKE (互聯(lián)網(wǎng)密鑰交換，Internet Key Exchange)協(xié)議序列以常規(guī)方式執(zhí)行，條件是由VPN客戶端在 它的IKE消息中宣稱的身份必須可被VPN服務(wù)器翻譯成VPN客 戶端的SIP身份(URI)。這一點(diǎn)可以通過讓VPN客戶端的身份 成為它的SIP URI來確保，但是對于更強(qiáng)的保護(hù)，客戶端的SIP 地址可以作為授權(quán)過程(例如，RADIUS或DIAMETER響應(yīng)的部 分)的結(jié)果返回.
一旦VPN服務(wù)器對客戶端作了鑒權(quán)(實(shí)際上在IKE的兩個(gè)階 段完成后)，它通過在公共域中發(fā)布SIP邀請消息將"呼叫"放 至VPN客戶端。SDP中的F-Spec識(shí)別已經(jīng)協(xié)商一致的隧道端點(diǎn). (注意，標(biāo)準(zhǔn)的IPSec包在它們的報(bào)頭沒有端口號(hào)碼，但是具有 安全參數(shù)索引域，其對于給定地址對之間的每個(gè)隧道是唯一的。 該域可以被用于F-Spec，但實(shí)際上，由于網(wǎng)絡(luò)中網(wǎng)絡(luò)地址轉(zhuǎn)換 (NAT)的存在，操作的VPN接入類型的數(shù)據(jù)封裝(tunneling)的 正常模式用于在UDP數(shù)據(jù)報(bào)中封裝IPSec包，因此，正常類型的 F-Spec用于識(shí)別包的IPsec隧道流。)在操作的一種模式中， VPN客戶端的T-Spec作為授權(quán)過程的一部分返回到VPN服務(wù) 器，即，每個(gè)VPN客戶端總是具有由管理員設(shè)置的固定的QoS 級(jí)別.在該例中，T-Spec作為來自VPN服務(wù)器的邀請(INVITE) 消息中的SDP的一部分被包含在內(nèi)。
在IMS的正常形式中，SIP邀請信令消息通過公共IMS CSCF 被轉(zhuǎn)發(fā)到VPN客戶端的SIP客戶端部分。
客戶端首先需要將進(jìn)入的信令與安全關(guān)聯(lián)(securityassociation)相關(guān)聯(lián)(我們假定安全參數(shù)索引包含在SDP中， 即使不是F-Spec的一部分，見上)。在操作的模式中(其中VPN 客戶端用戶開始選擇所需的服務(wù)類別(例如，用戶可以指定他們 是否要進(jìn)行/接收語音呼叫或視頻呼叫))，VPN客戶端將為隧道 創(chuàng)建T-Spec并且將它包含在返回到VPN服務(wù)器的SIP響應(yīng)中。 (假設(shè)響應(yīng)是200OK消息)
IMS系統(tǒng)建立會(huì)話，通知AG和TBG,它的F-Spec的，PSec 隧道經(jīng)過，并且指令它們提供由T-Spec指定的QoS處理。IWIS 系統(tǒng)還將產(chǎn)生要求的記賬記錄，從而隨后可以向企業(yè)收取服務(wù)的 費(fèi)用。
VPN服務(wù)器到客戶端之間的IPSec隧道現(xiàn)在是普通承栽路 徑由客戶端或服務(wù)器發(fā)送的匹配F-spec的包被確保在它們經(jīng)過 的每個(gè)域具有指定的QoS處理，注意，由于加密隱藏了隧道中的 所有包的真正報(bào)頭，因此所有包得到統(tǒng)一的QoS處理，另外，因 為IPSec可以依賴序列的完整性，所以向IPSec包報(bào)頭傳輸原始 di付-serv標(biāo)記并且使用它們來給不同包的類別以不同的QoS處 理并不是一個(gè)好主意.相反地，如果實(shí)施方案想限制IPSec普通 承栽中的業(yè)務(wù)來調(diào)節(jié)(加密的)多媒體流，那么它將不得不為多 媒體流和盡力而為業(yè)務(wù)建立單獨(dú)的IPSec隧道一沒有必要為盡力 而為隧道使用SIP請求QoS處理，但是可以為不同的流的類型建 立不同的IPSec隧道，每一個(gè)用單獨(dú)的T-Spec消息發(fā)送信號(hào). 一旦安全建立丟失，VPN服務(wù)器立刻終止SIP會(huì)話。 本領(lǐng)域的專業(yè)技術(shù)人員將認(rèn)識(shí)到以上所述可以有各種變化。 尤其是，可以不是在隧道建立期間從網(wǎng)絡(luò)請求IPSec隧道的QoS 處理，而是僅僅當(dāng)真正發(fā)起了語音呼叫時(shí)或者甚至僅僅當(dāng)監(jiān)視的 盡力而為傳輸?shù)男阅茉诤艚衅陂g低于某閾值時(shí)。進(jìn)一步的增強(qiáng)可 以使服務(wù)器在,P-Sec隧道被發(fā)起后，立即建立具有最小QoS處 理的普通承栽流，但是然后服務(wù)器可以使用S，P重邀請來修改流 的服務(wù)類別/帶寬以響應(yīng)隧道內(nèi)的探查(snooping)消息(例如， 軟電話客戶端和IP PBX之間的SIP消息)和/或企業(yè)域內(nèi)服務(wù)器的請求。
鎖定承載流
如圖1所示，會(huì)話的端點(diǎn)可以使用用于經(jīng)過幾個(gè)域的會(huì)話的
SIP信令和承栽流被連接到不同的(核心)網(wǎng)絡(luò)，目前，在IMS 中，對于承栽流中的包所沿路徑并沒有很多關(guān)注一通常假定它們 將沿由IP路由確定的路徑，另一方面，SIP信令的路由通過一系 列的CSCF至少部分地被定義，其中CSCF互相之間是成對的對 等體。在NGN中，在每個(gè)CSCF上SIP消息的轉(zhuǎn)發(fā)選擇由策略 指定(基于轉(zhuǎn)接的商業(yè)協(xié)定等).因此，在發(fā)起者和終止者在不 同的域的情況下，由SIP信令經(jīng)過的中間域不需要完全一致于在 IP轉(zhuǎn)發(fā)規(guī)則的正常操作下，IP包從發(fā)起者發(fā)送并尋址到終止方所 經(jīng)歷的域.
但是，承栽流的路徑為何不應(yīng)僅由IP路由確定并且還應(yīng)被顯 式設(shè)定為經(jīng)過指定的域和指定的傳輸邊界網(wǎng)關(guān)(TBG)有兩個(gè)好 的理由。第一，從商業(yè)的角度，因?yàn)槿绻虿恢懒鲗儆谀膫€(gè)會(huì) 話，則它就不能為它生成記賬記錄，很可能迫切要求會(huì)話的承栽 流不要經(jīng)過未參與該會(huì)話的信令傳送的域。笫二，向承栽流的QoS 的提供經(jīng)常要求將承栽流的授權(quán)通知路徑上的網(wǎng)絡(luò)單元以接收 QoS,因此對于在核心網(wǎng)絡(luò)和/或交換鏈路上的QoS，承栽流的路 徑必須被限制為通過(被鎖定)在會(huì)話建立時(shí)由b-CSCF選擇的 TBG,因?yàn)閎-CSCF可以只發(fā)送授權(quán)到它們控制的TBG上。
除了鎖定承栽流的上述兩個(gè)原因以外，涉及建立會(huì)話的 CSCF可以確定承栽流需要經(jīng)過某種類型的媒體網(wǎng)關(guān)，由于會(huì)話 端點(diǎn)沒有相互共有的編解碼器，所以在承載流路徑中可能需要媒 體網(wǎng)關(guān)執(zhí)行媒體樣本的代碼轉(zhuǎn)換，媒體網(wǎng)關(guān)的另一個(gè)用法可能是 因?yàn)槎它c(diǎn)之一被合法偵聽(Ll)命令的控制并且會(huì)話的媒體流需 要被通過Ll網(wǎng)關(guān)，從而它們的拷貝可以被安全地轉(zhuǎn)發(fā)到相關(guān)的法 律當(dāng)局。
本發(fā)明的笫二方面是為會(huì)話的承載流提供路徑鎖定機(jī)制，使得承栽包經(jīng)過在會(huì)話建立時(shí)確定的特定的網(wǎng)關(guān)鏈。以下的描述和
閨4-6專注于將承栽流鎖定到傳輸邊界網(wǎng)關(guān)(TBG)，但是對于 本領(lǐng)域的專業(yè)技術(shù)人員來說，根據(jù)這里的描述，涵蓋到其他網(wǎng)關(guān) (媒體轉(zhuǎn)換、合法截取等)的鎖定的擴(kuò)展看來是顯然的.如前所 述以及如在困2中所描述的，承栽流可以被分割為承栽(流)片 段的串聯(lián)級(jí)聯(lián)。除了第一流片段的起點(diǎn)和最后片段的終點(diǎn)以外， 這些承栽片段在網(wǎng)關(guān)14開始和結(jié)束.當(dāng)要將承載流鎖定到TBG14 時(shí)，中間承栽片段20的起點(diǎn)和終點(diǎn)是TBG14。
注意，由于配屬網(wǎng)絡(luò)6不跟隨IP轉(zhuǎn)發(fā)，所以特定終端8或服 務(wù)器8b的業(yè)務(wù)在它們配屬到網(wǎng)絡(luò)的期間內(nèi)被鎖定在特定AG10, 也即，第一和最后的承載片段一直在適當(dāng)?shù)奈恢茫兜臋C(jī)制用 于在AG10之間鎖定承栽路徑。
網(wǎng)絡(luò)單元能力
下面分三部分披露鎖定承栽流的機(jī)制.首先描述的是當(dāng)所有 網(wǎng)絡(luò)單元位于相同IP地址域時(shí)它如何工作；然后描述當(dāng)客戶端 TE位于私有IP地址域時(shí)它如何工作；最后是當(dāng)不同的核心網(wǎng)絡(luò) 屬于不同的IP地址域時(shí)的工作。在所有三種情況下，假定相同的 能力，即
網(wǎng)關(guān)(包括TBG、 AG和特殊媒體網(wǎng)關(guān))可以對承載流包的 報(bào)頭的NAT轉(zhuǎn)換；以及
CSCF是SIP應(yīng)用層級(jí)網(wǎng)關(guān)(ALG),其可以轉(zhuǎn)換SIP消息 中的SDP中的,P地址和端口號(hào)(F-Spec)并且可以控制由它們 控制的網(wǎng)關(guān)執(zhí)行的NAT轉(zhuǎn)換。如圖1所示，p-CSCF控制AG， b-CSCF控制TBG-媒體網(wǎng)關(guān)很可能由S-CSCF或代理控制.
在網(wǎng)關(guān)中，有兩種潛在的方法來由CSCF協(xié)調(diào)F-Spec的變 化和NAT映射的設(shè)置.在第一種方法中，CSCF確定映射并且推 行它到網(wǎng)關(guān)，該網(wǎng)關(guān)安裝它或者如果該映射不可行，那么返回錯(cuò) 誤響應(yīng)(例如，轉(zhuǎn)換表滿)，代替地，CSCF可以通過提交原始 IP地址和端口向網(wǎng)關(guān)請求映射并接收完成的映射作為來自網(wǎng)關(guān)的響應(yīng).
在每一個(gè)方法中，CSCF在轉(zhuǎn)發(fā)SIP消息到下一個(gè)CSCF之 前，改變SDP中的F-spec部分，注意，安裝NAT映射可以是從 CSCF推行到網(wǎng)關(guān)的更大的一般策略的一部分(例如，安裝QoS 策略).
注意，該披露沒有解決選擇哪些特定的TBG來形成鎖定點(diǎn)的 鏈的方法(這是SIP路由問題的一部分)，但僅描迷了據(jù)此改變 正常的IP路由行為以確保承栽流的包經(jīng)過所選的TBG的機(jī)制。
基本機(jī)制
本部分披露了一種實(shí)現(xiàn)用于作為相同IP地址域的所有部分的 聯(lián)合域(例如，公共地址域，IPv4或IPv6)的承栽流鎖定的方法。 如上所述，承栽流的SDP參數(shù)隱含地包含承栽流的F-Spec，其 通過源和目標(biāo)IP地址、包類型及源和目標(biāo)端口號(hào)識(shí)別流.嚴(yán)格地 講，F(xiàn)-Spec識(shí)別單向的流，但是很明顯，反向流的F-Spec可以 從原始的F-Spec輕易地(trivially)生成，所以當(dāng)期望建立雙向 流時(shí)，我們?nèi)匀粚⒂懻搯蝹€(gè)F-Spec。在該首次實(shí)現(xiàn)中，所有 F-Spec IP地址屬于相同的IP地址域。
該方法的本質(zhì)是，SIP信令路徑上的CSCF通過改變傳輸?shù)?下一個(gè)CSCF的F-Spec,將承載流分成承載片段，從而修改的 F-Spec僅僅描述由相關(guān)的CSCF控制的網(wǎng)關(guān)之間的承栽片段。然 后，CSCF在那些網(wǎng)關(guān)中安裝雙向"交叉連接"映射，使得進(jìn)入的 承栽片段中的包被網(wǎng)關(guān)轉(zhuǎn)發(fā)到下一個(gè)承栽片段。這里描述的特定 示例中，"交叉連接"映射是NAT映射并且包到下一個(gè)承栽片段的 轉(zhuǎn)發(fā)是通過下列方式完成的，執(zhí)行進(jìn)入包的報(bào)頭中的地址和端口 的NAT轉(zhuǎn)換從而使它們成為承栽路徑的下一片段的包，并且然后 根據(jù)正常IP路由程序轉(zhuǎn)發(fā)包。
參考困4，首先對于包含兩個(gè)域的會(huì)話發(fā)起來詳細(xì)描述該機(jī) 制，為符號(hào)表示方便以左邊域和右邊域示出在困4中，會(huì)話發(fā) 起由SIP客戶端TE8在左邊域發(fā)起并且在右邊域中在SIP客戶端AS 8b終止，所以SIP邀請消息從左向右穿過并且響應(yīng)(例如200 OK)從右向左通過。描述的過程應(yīng)用于域之間的每個(gè)邊界，使得 當(dāng)包含多于兩個(gè)域時(shí)，那么左邊域是最接近發(fā)起者的一個(gè)(轉(zhuǎn)發(fā) 邀請消息到右邊域)并且右邊域是最接近終止者的一個(gè)(轉(zhuǎn)發(fā) 200OK消息到左邊域)。
在圖4中，在會(huì)話發(fā)起要建立的承栽流中，承栽流的TE端 被指定為在IP地址A和端口 a發(fā)起和終止，為其我們使用術(shù)語 Aa.在SIP會(huì)話發(fā)起開始時(shí)，承栽流的AS端的地址和端口號(hào)對 于TE8是未知的，因此由TE8發(fā)布的SIP邀請消息24的SDP 中的F-Spec是不完整的并且可以表示為Aa, 。
當(dāng)由TE8發(fā)布的SIP邀請消息到達(dá)在左邊域的邊界的 b-CSCF16時(shí)，該b-CSCF選擇TBG14來鎖定通過的承栽路徑并 且為TBG請求或生成映射(在26處)以應(yīng)用到Aa。假定結(jié)果是 映射Aa。Bb,則b-CSCF修改F-Spec，將TE的發(fā)起IP地址和 端口 Aa替換為RBG的IP和端口 Bb，并且轉(zhuǎn)發(fā)該邀請(在28 處)到右邊域的它的對等實(shí)體。當(dāng)邀請消息到達(dá)對等b-CSCF時(shí)， 該b-CSCF可以選擇在右邊域的邊緣的哪個(gè)TBG14將形成它的交 換承栽片段端(注意，在閨4中，不像其他圖，域之間的包傳輸 以交換網(wǎng)絡(luò)XN示出而不僅僅是交換鏈路，如果在對等TBG對之 間僅有單個(gè)交換鏈路，那么左邊域b-CSCF對TBG的選擇將支配 右邊域中的TBG)。
右邊域中的b-CSCF為選擇的TBG14請求或生成映射(在 30)以應(yīng)用到Bb.再一次假定結(jié)果是Bb=>Cc,那么F-Spec被 修改為[Cc, ].在圖4中僅包含兩個(gè)域的會(huì)話發(fā)起下，SIP邀 請消息然后將前進(jìn)(在32)經(jīng)過右邊域中的CSCF直到它到達(dá)目 標(biāo)SIP客戶端22 (在圖4中，以應(yīng)用服務(wù)器AS示出)，在更普 遍的情況下，SIP遨請被轉(zhuǎn)發(fā)到與下一個(gè)域?qū)Φ鹊腷-CSCF,
從AS8b的角度看，它接收的SIP邀請正在請求具有Cc端 點(diǎn)的承栽流.假定AS以200OK消息回復(fù)，則它將指定它的承栽 流的端(例如，Zz)，從而2000K消息34的SDL中的F-Spec將會(huì)是[Cc， Zz。(本領(lǐng)域中的技術(shù)人員將認(rèn)識(shí)到，攜帶目標(biāo) F-spec部分的響應(yīng)消息可以是180響鈴(Ringing )消息。)200OK 消息經(jīng)過邀請的相反路徑并且返回到達(dá)在右邊域b-CSCF。該 b-CSCF將在36請求或生成另一個(gè)映射(例如Yy仁Zz)并且然 后在TBG14中激活BboCc、 YyoZz的全部IP報(bào)頭雙向網(wǎng)絡(luò)地 址轉(zhuǎn)換，最后，b-CSCF修改200OK消息中的F-Spec以將承栽 流源地址和端口表示為Yy，并且目標(biāo)表示為Bb,并且轉(zhuǎn)發(fā)(在 38)它到它在左邊域的對等實(shí)體，在左邊域中的對等b-CSCF上， 200OK消息的接收引起了映射Xx^Yy的請求或生成，在左邊域 TBG中雙向映射AaoBb、 XxoYy的激活(在40 )以及最后具 有Aa， Xx的2000K消息向發(fā)起SIP客戶端的傳播(在42 ), 從TE SIP客戶端22的角度看，會(huì)話的承栽流的其它端點(diǎn)是Xx, 在左邊域TBG14.
以上披露的過程所做的，實(shí)際上是將承栽流分段成3個(gè)承栽 流片段并且在TBG中安裝到"重標(biāo)記"包的包，使得它們被轉(zhuǎn)發(fā)到 下一個(gè)片段，當(dāng)它發(fā)送承載包到AS8b時(shí)，TE8在它們上面放置 Xx的目標(biāo)地址，它在200OK F-Spec接收到目標(biāo)地址。Xx是由 TE的核心域中的TBG14供應(yīng)的地址和端口號(hào)第一承栽流片段 是在TE (地址A)和TBG (左邊核心網(wǎng)絡(luò)上地址X的信號(hào)裝置) 之間的配屬片段和最左核心片段的級(jí)聯(lián)。第二片段是左邊TBG(交 換網(wǎng)絡(luò)上的地址B)和右邊TBG (交換網(wǎng)絡(luò)上的地址Y)之間的 交換片段.第三片段，還是配屬片段和核心片段的級(jí)聯(lián)，位于右 邊TBG (右邊核心網(wǎng)絡(luò)上的地址C的信號(hào)裝置)和AS (地址Z) 之間。由于包報(bào)頭中的目標(biāo)地址是片段端點(diǎn)的IP地址，所以根據(jù) 正常IP路由規(guī)則，包沿著每個(gè)單獨(dú)承載片段被轉(zhuǎn)發(fā)到承載片段的 端點(diǎn)。在TBG上，包報(bào)頭被重寫以將包置于下一個(gè)承栽片段的開 始處。那些熟悉標(biāo)記交換路徑的技術(shù)人員可以認(rèn)識(shí)到這是標(biāo)記交 換的一種形式，其中標(biāo)記域是整個(gè)IP報(bào)頭源和目標(biāo)地址和端口域。 當(dāng)在發(fā)起和終止域之間有多個(gè)域時(shí)，這種觀察本機(jī)制的方法可以 被應(yīng)用于解釋其應(yīng)用的結(jié)果.圖5在圖2中增加了定義每個(gè)承栽片段的NAT映射.
還可以觀察到，當(dāng)在單個(gè)IP地址域上操作時(shí)，僅僅目標(biāo)地址 需要被重映射，這是由于包中的源地址并不影響它們的路由。但 是，由于源地址在各種安全檢查(例如在防火墻中)下被使用， 因此對于安裝QoS策略，需要一致的方法。當(dāng)包含了多個(gè)地址域 (見下)時(shí)，源地址必須被重映射，所以我們采取了始終應(yīng)該這 樣的方法。
還應(yīng)該注意到在單個(gè)IP地址域中，NAT"標(biāo)記交換"僅僅在一 些節(jié)點(diǎn)需要，在這些節(jié)點(diǎn)上可能不依賴IP轉(zhuǎn)發(fā)將包轉(zhuǎn)發(fā)到下一承 栽片段.承栽流僅僅需要在網(wǎng)關(guān)(它可能并不總在IP轉(zhuǎn)發(fā)流路徑 上)被分段。通常，域間交換鏈路包含的拓樸可以保證網(wǎng)關(guān)將始 終在IP轉(zhuǎn)發(fā)流路徑上并且因此不需要是承栽片段端點(diǎn)。例如，如 果有單對互連兩個(gè)域的TBG并且確保它們之間的最短路徑不經(jīng) 過第三個(gè)域，那么從TE到AS的單個(gè)承栽片段將足以確保那些包 總是經(jīng)過TBG對.
多IP地址域
上述的NGN組織不要求每個(gè)管理域都是同一 IP地址域的一 部分。相反，由于被叫方通過URI而不是IP地址在SIP消息中被 識(shí)別，所以CSCF鏈可以跨越IP地址域邊界向被叫方轉(zhuǎn)發(fā)SIP消 息.這要求當(dāng)b-CSCF從不在同一個(gè)地址域的它們的對等實(shí)體接 收SIP信令時(shí)，它們能使SIP信令適合于它們自己的IP地址域。 例如在圖6中，IPv6域中的b-CSCF將從在公共IPv4域中的它 的對等實(shí)體接收IPv4格式的SIP消息并且在轉(zhuǎn)發(fā)它們到它的自己 咸中的CSCF之前，將不得不將該消息重新格式化成IPv6形式， 如前所述，SIP消息在SDP部分包含了要建立的承栽流的隱含的 流規(guī)范(F-Specs).當(dāng)承栽流要經(jīng)過多個(gè)地址域時(shí)，SIP消息中 的F-spec需要在地址域邊界處被改變以反映將要對承栽流產(chǎn)生 作用的網(wǎng)絡(luò)地址和端口的轉(zhuǎn)換.重新格式化SIP消息和改變 F-Specs經(jīng)常稱為SIP ALG (應(yīng)用層網(wǎng)關(guān)，AppHcation LayerGateway )功能《
圖6描述使用3個(gè)IP地址域的兩個(gè)管理域服務(wù)于終端(TE) 的管理域?yàn)榻K端分配私有IPv4地址(可能是因?yàn)樗鼪]有足夠的公 共IPv4地址進(jìn)行分配以給每個(gè)終端一個(gè)自己的公共IP地址)， 但在核心網(wǎng)絡(luò)中使用公共地址，雖然其他管理域全部使用IPv6地 址，互連兩個(gè)NGN域的交換網(wǎng)絡(luò)在圖6中以IPv4網(wǎng)絡(luò)、部分公 共IPv4地址域示出。這是一個(gè)隨意的選擇并且交換網(wǎng)絡(luò)可以同樣 是IPv6地址域的一部分.
比較圖4與圖6，可以觀察到在左邊AG有地址域邊界。當(dāng) 這些包在連接網(wǎng)絡(luò)和核心網(wǎng)絡(luò)之間穿過時(shí)，該AG需要在包上執(zhí) 行NAT功能。因此控制AG的p-CSCF、與配屬于AG10的TE8 中的SIP客戶端22對等的p-CSCF16需要轉(zhuǎn)換SIP消息中的SDP 中的F-Spec (使得承栽流看起來是在AG發(fā)起)，并且在AG中 安裝必需的NAT映射以終止配屬承栽片段和發(fā)起核心承栽片段. 具體地，如圖6中示出的地址是私有IP地址和端口分配，而Bb 是由AGIO在核心網(wǎng)絡(luò)內(nèi)通告的公共IP地址(和端口號(hào))。再一 次，熟悉私有和公共IPv4路由和默認(rèn)路由的技術(shù)人員將注意到， 由于私有和公共IPv4地址并不重疊并且任何情況下都將包轉(zhuǎn)發(fā) 到AG,所以所示的映射Ww仁Xx不是嚴(yán)格需要的。但是不在承 載包上進(jìn)行完整的IP報(bào)頭重映射在將承載流正向和反向劃分為承 栽片段中產(chǎn)生不對稱，并且這會(huì)造成難解的維護(hù)問題。
圖6中的其它地址域邊界在右邊域TBG.該TBG具有一個(gè) 或多個(gè)運(yùn)行在IPv4地址域內(nèi)的接口，并且明確地，地址Y是這些 接口 (或這些接口之一)的IPv4地址。它還具有一個(gè)或多個(gè)運(yùn)行 在IPv6地址域中的接口，其中地址D是TBG IPv6接口地址.如 前所述，從左邊域b-CSCF到達(dá)右邊域b-CSCF的SIP消息將是 IPv4格式，具有IPv4報(bào)頭和所有嵌入IP地址的v4。 b-CSCF在 轉(zhuǎn)發(fā)消息到下一 CSCF前必須轉(zhuǎn)換這些消息以具有IPv6報(bào)頭和嵌 入的IP地址.對于SIP邀請消息的SDP中的F-Spec,轉(zhuǎn)換必須 匹配將要被要裝在TBG中的NAT映射，即與披露的路由鎖定過程比沒有改變，
在用戶范圍隱藏的NAT
知道公共VoIP服務(wù)的實(shí)際部署議題的技術(shù)人員將認(rèn)識(shí)到，在 TE和連接網(wǎng)絡(luò)(AN)之間經(jīng)常執(zhí)行NAT功能。該功能在具有私 有IP地址域的住所或企業(yè)的邊界發(fā)生，現(xiàn)今，該NAT功能并不 是SIP察覺(SIP aware)的(即，并不包含SIP應(yīng)用層網(wǎng)關(guān) (ALG)).但是，這種現(xiàn)象并不實(shí)質(zhì)上影響到上述機(jī)制；現(xiàn)今 使得VolP工作的相同的解決方案可以繼續(xù)被使用.因此，客戶端 通過確定什么NAT映射被應(yīng)用(通過首先詢問STUN (經(jīng)過NAT 的UDP的簡單歷程)服務(wù)器)來"修復(fù)"SIP信令，(見RFC 3489 ); 或者p-CSCF檢測在來自客戶端的SIP信令上已經(jīng)執(zhí)行了 NAT 轉(zhuǎn)換(由于嵌入在邀請或回復(fù)消息的SDP中的客戶端IP地址與 消息報(bào)頭中的IP源地址不匹配)，并且當(dāng)處理該承栽流時(shí)指示 AG為此做補(bǔ)償.
在將來，執(zhí)行NAT功能的用戶邊緣設(shè)備的住所網(wǎng)關(guān)可以被加 強(qiáng)為包含p-CSCF功能或者被p-CSCF控制，使得住所內(nèi)的承栽 流的片段完全在SIP會(huì)話建立過程的控制之下，
網(wǎng)絡(luò)地址轉(zhuǎn)換的(NATtinq)承載流的其他好處 以上披露的路由鎖定機(jī)制的優(yōu)勢是它使用在TBG (和AG) 中頻繁出現(xiàn)的能力(NAT)并且它不要求任何來自在核心網(wǎng)絡(luò)中 其他路由器的支持。該機(jī)制使得NAT功能被應(yīng)用于跨越管理域的 所有承栽路徑.它還使得NAT功能在AG被應(yīng)用，即使當(dāng)配屬網(wǎng) 絡(luò)與核心網(wǎng)絡(luò)位于相同的IP地址域.以下是始終作網(wǎng)絡(luò)地址轉(zhuǎn)換
的承栽流的兩種另外的好處的簡單描迷，其使得它成為IMS中的 承栽流的路由鎖定的優(yōu)選方法。
匿名
在PSTN中，呼叫方可以請求不向被叫方顯示呼叫著的電話號(hào)碼。SIP信令支持呼叫方的SIP地址的抑制但是承栽包的源IP
地址對于被叫方來說足以確定呼叫方的身份或呼叫方的位置.起 碼，擁有呼叫方的IP地址將使得被叫方易于針對呼叫者發(fā)動(dòng)拒絕 服務(wù)的攻擊或者進(jìn)行一些其他形式的互聯(lián)網(wǎng)騷擾.如杲，照例，
承栽流被破解成承栽片段并且每一方只看到它們本地AG的IP地 址，那么進(jìn)行或接收SIP呼叫將不會(huì)向任一方暴露其他方的IP地 址，也不會(huì)在完全授權(quán)方的IMS框架以外展開與那一方的任何方 式的通信.
屏蔽合法偵聽
需要方法來實(shí)現(xiàn)合法偵聽，即偵聽的目標(biāo)不能夠檢測到她的 通信正在被偵聽。實(shí)現(xiàn)合法偵聽的另一約束是除了直接負(fù)責(zé)完成 偵聽那些人以外的操作人員不能檢測到偵聽就緒，這種約束通常 導(dǎo)致在目標(biāo)的主核心網(wǎng)絡(luò)中部署特定目的的偵聽媒體網(wǎng)關(guān)。當(dāng)如 上所述使用NAT時(shí)，展示給端客戶端的SDP描述和承栽流的實(shí) 際包報(bào)頭不包含其他方的IP地址而包含中間網(wǎng)關(guān)的IP地址，然 后用戶無法辨別(從IP地址中檢查)她的承栽路徑是否已經(jīng)被轉(zhuǎn) 移到偵聽媒體網(wǎng)關(guān)以制作承栽路徑包的拷貝。
非SIP客戶端的支持
IMS的開發(fā)基于這樣的假設(shè)即會(huì)話的兩端的實(shí)體(例如， 圖1中的客戶端和應(yīng)用服務(wù)器)為了能夠建立承栽流，使用SIP 協(xié)議(懂SIP的)。以上描述的方法將IMS的應(yīng)用能力擴(kuò)展到對 于承栽流(不一定必須是多媒體流)要求有QoS處理的應(yīng)用，但 是該應(yīng)用仍然需要是有SIP能力的，雖然合理假設(shè)應(yīng)用服務(wù)器具 有SIP功能性，但是期望的是能夠建立至不懂SIP的客戶端的承 栽流。如果在應(yīng)用可以充分利用新的NGN提供的QoS傳輸之前， 應(yīng)用客戶端(其比服務(wù)器的數(shù)量多得多)必須被升級(jí)到具有SIP 功能性，那么這種能力將更快地(比起將要發(fā)生的情況)展現(xiàn)由 NGN IMS網(wǎng)絡(luò)支持的有用的服務(wù)和應(yīng)用的范圍.根據(jù)本發(fā)明的第三方面，應(yīng)用一未知客戶端代理與控制配屬
網(wǎng)關(guān)10的CSCF關(guān)聯(lián)，非SIP客戶端通過配屬網(wǎng)關(guān)10配屬到網(wǎng) 絡(luò).客戶端代理代表客戶端，響應(yīng)來自應(yīng)用服務(wù)器的SIP逸請消 息，使得可以提供經(jīng)過至少是連接片段的承栽流的QoS處理。在 以下描述的實(shí)施例中，應(yīng)用服務(wù)器可以是有SIP知覺的并且能夠 調(diào)用這里所描述的機(jī)制的服務(wù)器。替代地，可以部署具有所要求 的功能性的應(yīng)用服務(wù)器代理以代替升級(jí)應(yīng)用服務(wù)器。在任一情況 下，本技術(shù)消除了為所有可能的應(yīng)用客戶端類型部署應(yīng)用知覺的 特定代理的需要(其在多域網(wǎng)絡(luò)內(nèi)將會(huì)是非常困難的過程)。本 發(fā)明可以通過使對應(yīng)用客戶端所配屬的AG進(jìn)行控制的p-CSCF 得到加強(qiáng)來實(shí)施，以為客戶端提供一般應(yīng)用的獨(dú)立代理功能。
下面我們描述本發(fā)明的兩種典型實(shí)施例1)其中，僅確保了 承栽流的應(yīng)用客戶端端配屬片段的QoS處理，和2)其中，向整 個(gè)承栽流提供QoS處理。第一種實(shí)現(xiàn)對于許多部署來說很可能十 分有用，這是因?yàn)榕c核心網(wǎng)絡(luò)相比，在配屬網(wǎng)絡(luò)中帶寬受到更多 的限制，尤其是具有無線最后一英里的那些配屬網(wǎng)絡(luò)。
客戶端配屬承栽片段的QoS處理
在該實(shí)施例中，目標(biāo)是僅僅為應(yīng)用客戶端的配屬承栽片段提 供QoS處理(見圖7)。假定AS 8b (應(yīng)用服務(wù)器或者它的代理) 是向某個(gè)IMS域(服務(wù)器的主域)中的S-CSCF注冊的懂SIP的 實(shí)體。應(yīng)用客戶端配屬到某個(gè)域(在圖7中指示為客戶端的服務(wù) 域)的核心網(wǎng)絡(luò)，從其中它接收到NGN網(wǎng)絡(luò)的IP連接性，由于 該應(yīng)用客戶端8不是SIP知覺的，所以它沒有向任何CSCF注冊. 但是，應(yīng)用客戶端的配屬點(diǎn)被假定為在客戶端的服務(wù)域中的 p-CSCF的控制之下的AG。該AG被指示為TE的服務(wù)網(wǎng)關(guān)。
雖然圖7示出客戶端的服務(wù)域被轉(zhuǎn)接鏈路將其與服務(wù)主域隔 開0個(gè)或多個(gè)互連它們的轉(zhuǎn)接域，但是本發(fā)明還可應(yīng)用于應(yīng)用服 務(wù)器和客戶端處以相同域的網(wǎng)絡(luò).為清楚起見，以下的描述首先 假定域(服務(wù)器的主域，客戶端的服務(wù)域和任意轉(zhuǎn)接域)都是同一IP地址域的一部分，處理位于分立的IP地址域的域的其他機(jī) 制在本部分結(jié)尾披露。
由于應(yīng)用服務(wù)器8b將發(fā)送包(在承栽流中)到客戶端8,它 必須能夠?yàn)槌性粤魃蒄-Spec (否則，它將不能生成包的IP報(bào) 頭)。通常，在有需要建立承載流之前，在客戶端和服務(wù)器之間 已經(jīng)有一些交互例子在IPSec隧道建立之前的互聯(lián)網(wǎng)密鑰交換 (IKE)交互，或者在視頻片段被流向客戶端之前為選擇它的巡航。 從初始交換的IP報(bào)頭中，服務(wù)器將獲得承栽流的客戶端的端的IP 地址和端口號(hào).服務(wù)器得知的客戶端的IP地址是由AG10 (客戶 端8通過AG10配屬于核心網(wǎng)絡(luò)4)通告的地址。實(shí)際上，F(xiàn)-Spec 描述應(yīng)用服務(wù)器10到AG8b的承栽片段.AG10使用進(jìn)入包中的 客戶端IP地址來控制它們到配屬承栽片段，配屬承栽片段構(gòu)成到 客戶端8的完整的流路徑.
本發(fā)明構(gòu)思一種新的SIP URI (統(tǒng)一資源定位符)的形式， 我們將其稱作服務(wù)網(wǎng)關(guān)URI,用作邀請由應(yīng)用服務(wù)器8b生成的
sip遨請消息的目標(biāo)參數(shù)(并且被插入到"TO"語句).該um中
的標(biāo)識(shí)符是IP地址的表示該URI的希望表示的語義是由該URI 命名的目標(biāo)(被叫方)是p-CSCF16，其可以推行策略到通告該 URI中的IP地址的AGIO.
有多種機(jī)制可以被用于路由SIP邀請消息，其擁有這種新的 服務(wù)網(wǎng)關(guān)URI作為它們的目標(biāo).例如，如果b-CSCF與它們所在 其中的AS(自治子系統(tǒng))關(guān)聯(lián)，并且AS編號(hào)在它們的對等 b-CSCF的轉(zhuǎn)發(fā)表中被提供，則當(dāng)b-CSCF接收邀請消息時(shí)，它 僅需確定"下一跳"AS用于BGP-4路由到目標(biāo)IP地址，以識(shí)別轉(zhuǎn) 發(fā)該邀請到什么新的管理域和對等b-CSCF。 一旦邀請(INVITE) 到達(dá)了目標(biāo)管理域，它可以被轉(zhuǎn)發(fā)到特殊指定的S-CSCF，域中 的所有p-CSCF已經(jīng)將它們控制的網(wǎng)關(guān)的地址范圍在特殊指定的 S-CSCF上作了注冊。該指定的S-CSCF然后匹配服務(wù)網(wǎng)關(guān)URI 到地址范圍來確定轉(zhuǎn)發(fā)邀請消息到哪個(gè)p-CSCF.如杲需要，還 可以使用其他轉(zhuǎn)發(fā)方法.在上述假定下，應(yīng)用服務(wù)器和客戶端間的承載流的建立過程
如下
在第一步驟，應(yīng)用服務(wù)器8b在它的主域(通過它的p-CSCF) 中向它的S-CSCF發(fā)送SIP邀請，該SIP邀請具有的TO語句， 該TO語句包含指定客戶端的IP地址的服務(wù)網(wǎng)關(guān)URI并且在SDP 部分包含到客戶端的承栽流的F-spec和服務(wù)器想應(yīng)用的 T-spec。(由于是服務(wù)器對會(huì)話計(jì)費(fèi)，所以指定T-Spec是服務(wù) 器的特權(quán)，)
一旦S-CSCF對遨請(INVITE)執(zhí)行了正常的發(fā)起處理，它 向客戶端的服務(wù)域轉(zhuǎn)發(fā)該遨請.如果客戶端的服務(wù)域區(qū)別于服務(wù) 器的主域，那么例如使用上述的轉(zhuǎn)發(fā)決定過程，遨請將會(huì)通過 b-CSCF被轉(zhuǎn)發(fā)，可能穿過幾個(gè)域邊界直到它到達(dá)客戶端的服務(wù) 域的邊界處的b-CSCF。
一旦邀請到達(dá)客戶端服務(wù)域中的b-CSCF，它就要被轉(zhuǎn)發(fā)到 控制客戶端8實(shí)際配屬的AG10 (調(diào)用AG10的策略決定功能) 的p-CSCF。再一次，上迷的示例機(jī)制可以被使用，但是本領(lǐng)域 的專業(yè)技術(shù)人員將認(rèn)識(shí)有多種可能的機(jī)制。
在接收到邀請消息后，p-CSCF請求AG ( AG的RACF)在 配屬網(wǎng)絡(luò)中安裝QoS策略，其與為承栽流指定的T-Spec相符， 承栽流由邀請消息的SDP中的F-Spec識(shí)別。就在這一點(diǎn)， p-CSCF的修改的行為破門而入(kick in )，由包含服務(wù)網(wǎng)關(guān)URI 的TO語句和嘗試安裝QoS策略的結(jié)果觸發(fā)。在常規(guī)的系統(tǒng)中， p-CSCF將轉(zhuǎn)發(fā)邀請到客戶端8，其在本例中(該客戶端是非SIP 客戶端)將不知道如何處理它.因此，根據(jù)本發(fā)明，為客戶端8 例示的普通代理44 (或者，等價(jià)的，p-CSCF擔(dān)任普通代理的能 力)代表客戶端8發(fā)送適當(dāng)?shù)腟IP回復(fù)到應(yīng)用服務(wù)器8b。如果在 AG上安裝QoS的策略的嘗試成功了 ，那么普通代理沿著邀請的 相反路徑向應(yīng)用服務(wù)器8b發(fā)送回接受(例如，"200 OK")消息. 或者，如果QoS策略安裝請求失敗，那么來自普通代理44的返 回消息將會(huì)以再見(BYE)消息代替，以向服務(wù)器8b指示在配屬網(wǎng)絡(luò)中沒有足夠的資源來支持承栽流的T-Spec請求。將注意到， 在該操作中，QoS處理應(yīng)用于配屬承栽片段，并且SIP信令生成 以完成承載流的建立，但是b-CSCF (或者普通代理44)對該客 戶端應(yīng)用沒有任何察覺。如此，普通代理44是真正意義上的普通 的，它可以被用于為任何客戶端應(yīng)用建立具有QoS處理的承栽流。
一旦應(yīng)用服務(wù)器8b完成SIP會(huì)話建立，它發(fā)送到與F-Spec 相符的客戶端8的包將以通常的盡力而為的方式經(jīng)過各種中間 域，但將以指定的QoS經(jīng)過接入/配屬網(wǎng)絡(luò)6,
當(dāng)應(yīng)用服務(wù)器8b完成對客戶端8的服務(wù)時(shí)，它可以通過沿著 最初的遨請(INVITE)的路徑發(fā)送SIP再見(SIP BYE)消息釋 放QoS資源。當(dāng)它到達(dá)p-CSCF時(shí)，再見消息將導(dǎo)致以正常的方 式釋放承栽流的QoS策略，但是再一次，它將是p-CSCF(或者 普通代理44)而不是客戶端應(yīng)用本身，其生成SIP確認(rèn)通知。
注意當(dāng)配屬網(wǎng)絡(luò)中的QoS策略由被稱為"拉"機(jī)制安裝時(shí)，以 上披露的機(jī)制將不能與未修改的應(yīng)用客戶端工作，這是由于"拉" 機(jī)制要求客戶端被包含在處理中，并且描述的方法的本質(zhì)是在沒 有涉及客戶端的情況下在配屬網(wǎng)絡(luò)中安裝QoS策略。
處理NAT:多個(gè)IP地址域
如上所述，當(dāng)TE8和AS 8b位于不同的IP地址域時(shí)，需要 處理兩種情況。其中的第一種情況是當(dāng)TE88在私有IP地址域并 且核心網(wǎng)絡(luò)是單個(gè)公共IP地址域的一部分時(shí)，AG 8b執(zhí)行NAT 功能，轉(zhuǎn)換即將進(jìn)入核心網(wǎng)絡(luò)4的包上的IP報(bào)頭，使得來自客戶 端8的包中的源地址是由AG10在包到達(dá)應(yīng)用服務(wù)器8b時(shí)通告的 公共地址.假定應(yīng)用服務(wù)器8b使用該公共地址建立服務(wù)網(wǎng)關(guān)URI 和F-Spec (和控制包內(nèi)沒有未轉(zhuǎn)換的地址)，則該遨請消息將到 達(dá)上述的控制p-CSCF。 p-CSCF使用公共IP地址域F-spec進(jìn) 行它的RACF請求察覺到它是來自客戶端8的網(wǎng)絡(luò)地址轉(zhuǎn)換的 業(yè)務(wù)的AG10在安裝任何IP層"關(guān)"于配屬網(wǎng)絡(luò)中之前，需要映射 F-spec中的IP地址。當(dāng)核心網(wǎng)絡(luò)14之間有IP地址域邊界時(shí)，事情會(huì)變得有點(diǎn)棘 手承栽流路徑實(shí)際上在執(zhí)行內(nèi)部地址域NAT的TBG14上被分 割上了兩部分.在圖8中，示出的的左邊IP地址域和右邊IP地 址域之間的邊界位于服務(wù)器的主域(盡管它可以是在任何域的邊 界)和TBG14的邊緣，其中有一個(gè)在所有業(yè)務(wù)上執(zhí)行NAT,從 生成服務(wù)網(wǎng)關(guān)URI的應(yīng)用服務(wù)器8b的角度看，該TBG14為服務(wù) 網(wǎng)關(guān)(即，來自TE客戶端的到達(dá)的包中源地址的信號(hào)裝置，在圖 8中應(yīng)用服務(wù)器看到B的源地址，其是在右邊IP地址域中的地 址)。
使用例如與上述相同的機(jī)制，SIP邀請消息可以被路由到控 制NATTBG14的b-CSCF。如上所述，控制地址域邊界TBG的 b-CSCF必須可以執(zhí)行控制SIPALG功能.在該例中，用于感興 趣的F-Spec的NAT映射在SIP邀請消息到達(dá)控制網(wǎng)關(guān)之前將已 經(jīng)被安裝在NAT TBG中，b-CSCF的第一行動(dòng)必須是輪詢用于 NAT映射的TBG14，使得它然后可以使用TE8配屬于的AG10 的服務(wù)網(wǎng)關(guān)URI和客戶端端承栽片段的F-Spec,為客戶端側(cè)(左 邊)IP地址域構(gòu)建邀請消息。在圖8中，新的服務(wù)網(wǎng)關(guān)URI將包 含地址A,根據(jù)上述進(jìn)行的過程的這一點(diǎn)，借助b-CSCF對回復(fù) 的SIP消息執(zhí)行要求的ALG功能。
當(dāng)處理核心網(wǎng)絡(luò)之間的IP地址域邊界時(shí)有一個(gè)防止誤解的說 明.如上所述，承栽流的路由的IP路徑可能不會(huì)和SIP信令經(jīng)過 相同的域.具體來說，可能有網(wǎng)絡(luò)，在這些網(wǎng)絡(luò)中路由的IP地址 可能經(jīng)過未作為NGN中參與方的域，如果NAT轉(zhuǎn)換在不是NGN 的部分(即，不在b-CSCF的控制之下)的邊界網(wǎng)關(guān)發(fā)生，那么 上述機(jī)制將會(huì)失敗.圍繞這種情況的工作將使用全路由鎖定，在 下一部分中將描述.
例子
使用本發(fā)明的典型例子將會(huì)是用于遺留(即，先于SIP的) 流視頻服務(wù)。視頻服務(wù)供應(yīng)商可能期望以這樣的質(zhì)量等級(jí)傳遞流視頻，該等級(jí)高于大多數(shù)接入/配屬網(wǎng)絡(luò)在服務(wù)的"盡力而為"的等
級(jí)下可靠提供的服務(wù)質(zhì)量。 一旦本發(fā)明被部署在NGN中，視頻服 務(wù)供應(yīng)商將升級(jí)它的服務(wù)器到有SIP能力的(包括可以生成服務(wù) 網(wǎng)關(guān)URI)并且然后議定來自本地運(yùn)營商的IMS服務(wù)。本地運(yùn)營 商將設(shè)定一個(gè)費(fèi)率，其可以是以一部電影為單位的或基于時(shí)間的 或者以在指定的QoS類別下傳送的1兆字節(jié)為單位。這種費(fèi)率的 形式將依賴于竟?fàn)幮砸蛩夭⑶覍τ诒３?在網(wǎng)的(on-net)"(客 戶端配屬到運(yùn)營商擁有的網(wǎng)絡(luò))的會(huì)話，并且將很可能低于運(yùn)營 商必須與一個(gè)或多個(gè)其他運(yùn)營商分享費(fèi)用的會(huì)話的費(fèi)率.費(fèi)率還 可以是專門針對應(yīng)用客戶端在使用的配屬網(wǎng)絡(luò)的類型，無線的收 費(fèi)比有線的收費(fèi)高。當(dāng)會(huì)話中有失敗時(shí)，那么視頻服務(wù)供應(yīng)商和 NGN運(yùn)營商之間的SLA也將包含退款的議題.
視頻服務(wù)的潛在客戶端如往常一樣進(jìn)行，與視頻應(yīng)用服務(wù)器 交互來瀏覽并選擇電影。作為瀏覽響應(yīng)顯示的一部分，觀看電影 的價(jià)格將顯示給用戶假定視頻服務(wù)供應(yīng)商將設(shè)置價(jià)格以覆蓋傳 遞費(fèi)率的成本.可能電影以不同的分辨率、不同的價(jià)格呈現(xiàn)，適 用于不同的客戶端配屬網(wǎng)絡(luò)。 一旦用戶選擇完成，視頻服務(wù)器發(fā) 起具有邀請的TO語句的SIP會(huì)話，邀請包含具有客戶端的IP地 址的服務(wù)網(wǎng)關(guān)URI和視頻流的T-Spec。這將導(dǎo)致服務(wù)于客戶端的 AG,該客戶端在其正在使用的配屬網(wǎng)絡(luò)中安裝QoS策略，使得 從服務(wù)器到目的地為客戶端的視頻內(nèi)容包接收視頻服務(wù)器在邀請 消息中請求的QoS處理，
承載流的端到端QoS處理
如上所述，NGN網(wǎng)絡(luò)可以向承栽流的所有片段提供QoS處 理，其中承栽流被"鎖定，，盡管參與在SIP信令交換的管理域的 TBG,當(dāng)TE客戶端不懂SIP ( not SIP speaker)時(shí)，這種機(jī)制
和所得到端到端QoS能力可以與服務(wù)器網(wǎng)關(guān)um的使用結(jié)合。與
僅僅在客戶端配屬片段上傳遞QoS的機(jī)制相比，結(jié)合的機(jī)制具有 每一個(gè)p-CSCF和b-CSCF (當(dāng)服務(wù)器的邀請消息路由到控制TE的服務(wù)網(wǎng)關(guān)時(shí)對其進(jìn)行處理)還使網(wǎng)關(guān)準(zhǔn)備(prime)進(jìn)行NAT 轉(zhuǎn)換以鎖定承栽流，使得它接收請求的QoS處理量。
除了配屬片段上的QoS所需的條件和假設(shè)之外，傳遞端到端 QoS還需要一個(gè)額外的條件當(dāng)發(fā)送作為承栽流的一部分的包時(shí)， 應(yīng)用服務(wù)器必須使用來自在SIP回復(fù)"200 OK"消息中接收的最終 F-Spec的目標(biāo)地址和端口號(hào)而不是它從遺留協(xié)議(它將其放在初 始F-Spec中)得到的初始客戶端地址和端口號(hào)。
由于由CSCF生成的最終F-Spec使用它的在包報(bào)頭的地址 為應(yīng)用服務(wù)器定義了配屬承載片段確保了即使當(dāng)應(yīng)用服務(wù)器具 有在合適位置的多個(gè)網(wǎng)絡(luò)配屬鏈路時(shí)，應(yīng)用服務(wù)器將向AG轉(zhuǎn)發(fā) 承栽包，其中SIP信令使AG"作準(zhǔn)備"(primed)以傳遞QoS并 且映射包報(bào)頭，使得轉(zhuǎn)發(fā)該包到下一承栽片段；以及，當(dāng)要經(jīng)過 多于一個(gè)IP地址域時(shí)，路由鎖定操作導(dǎo)致NAT網(wǎng)關(guān)的使用，NAT 網(wǎng)關(guān)具有由控制b-CSCF設(shè)置的它們的NAT映射。
好處
本方法的好處可以從以上遺留視頻流服務(wù)的例子看出。本發(fā) 明沒有就緒(in place)的話，視頻服務(wù)供應(yīng)商確保給遺留(即， 非SIP)客戶端的QoS的唯一方法將是視頻服務(wù)供應(yīng)商與其用戶 所使用的每個(gè)配屬網(wǎng)絡(luò)供應(yīng)商建立特定的關(guān)系，使得來自他的視 頻服務(wù)器的所有業(yè)務(wù)在那些配屬網(wǎng)絡(luò)上是達(dá)成一致的增強(qiáng)的 QoS.這有一個(gè)缺點(diǎn)是該服務(wù)將被限制在地理范圍內(nèi)或者該視頻 服務(wù)供應(yīng)商必須與任何他的用戶想要使用的每一個(gè)配屬網(wǎng)絡(luò)供應(yīng) 商協(xié)商。借助本發(fā)明，視頻服務(wù)供應(yīng)商僅需與作為NGN—部分的 一個(gè)運(yùn)營商協(xié)商并且然后可以服務(wù)于配屬任何NGN運(yùn)營商的網(wǎng) 絡(luò)的用戶，還存在靜態(tài)地保存接入網(wǎng)絡(luò)中的資源的問題，為此接 入網(wǎng)絡(luò)供應(yīng)商可能合理地想得到報(bào)酬而不管視頻服務(wù)供應(yīng)商是否 使用他們。這將很可能導(dǎo)致視頻服務(wù)供應(yīng)商以保守的態(tài)度考慮他 在每個(gè)配屬網(wǎng)絡(luò)上所保留的視頻會(huì)話的容量和數(shù)量；視頻服務(wù)器 將必須根據(jù)這些保留的/分配前的資源運(yùn)行它自己的RAC以確保沒有違背SLA業(yè)務(wù)類別。
熟悉SIP操作的技術(shù)人員將認(rèn)識(shí)到，即使當(dāng)一端不是SIP察 覺的，能夠使用SIP來建立承栽路徑還有其他好處。例如，可能 發(fā)生的是，在會(huì)話過程期間，配屬網(wǎng)絡(luò)可能不再支持在會(huì)話發(fā)起 時(shí)所同意的T-Spec—例如，移動(dòng)終端可能移動(dòng)到離基站更遠(yuǎn)并且 兩者之間的可用傳輸比率已經(jīng)被減少。在RACS子系統(tǒng)的適當(dāng)操 作中，控制p-CSCF將會(huì)被通知它推行的QoS策略可能不再滿足。 它然后可以發(fā)起返回到發(fā)起者的重邀請SIP信令序列，包括發(fā)送 回反映當(dāng)前配屬鏈路特性的T-Spec。然后是重新建立較低QoS 的會(huì)話或者終止它的應(yīng)用決定。
用于遺留IP信令的網(wǎng)關(guān)
如上所述，所披露的在NGN上向不懂SIP的應(yīng)用傳遞QoS 的方法的替代方案是為客戶端和服務(wù)器開發(fā)專用的懂SIP的代 理.這種解決方案的問題是需要迎合大范圍的潛在應(yīng)用.但是， 一些應(yīng)用可能已經(jīng)使用資源保存協(xié)議(遺留IP信令)的某種形式 并且這些協(xié)議的數(shù)量十分有限.很可能僅兩種需要被考慮，它們 是RSTP[H.Schulzrinne等人，"Real Time Streaming Protocol (RTSP) ，，， RFC2326, 1998年4月J和RSVP[R.Braden (編 輯)等人，"Resource Reservation Protocol ( RSVP )，，， RFC2205, 1997年9月]。本發(fā)明的第四個(gè)方面提供了 一種網(wǎng)關(guān) 裝置，其提供遺留IP信令到SIP信令的交互工作.因此，可以提 供交互工作網(wǎng)關(guān)，其負(fù)責(zé)信令交互工作功能(SIWF),該信令交 互工作功能(SIWF)在網(wǎng)絡(luò)的邊緣終止RTSP和/或RSVP信令 并且生成經(jīng)過核心網(wǎng)絡(luò)的SIP消息以建立(QoS能力的)端到端 承栽路徑.
圖9是交互工作網(wǎng)關(guān)的部署的描述。在該圖中，信令交互工 作功能(SIWF)顯示為安置(host)在服務(wù)的AG上，該服務(wù)的 AG用于與承栽流互連起來的兩個(gè)應(yīng)用實(shí)體(TE上的客戶端和AS 上的服務(wù)器). 一直在往來端系統(tǒng)的包的路徑上的AG是用于安置(host)信令交互工作功能的優(yōu)選，這是因?yàn)槭褂蒙疃鹊陌鼨z 查(deep packet inspection)，它們可以檢測帶內(nèi)遣留信令包 ("帶內(nèi)"表示信令包與其他業(yè)務(wù)混合在一起)。但是，AG不是唯 一的可能的選擇.另一種可能的實(shí)現(xiàn)將AG的角色限制在檢測信 令包并在隧道的某種形式中轉(zhuǎn)發(fā)它們，和限制在共處于與AG的 控制p-CSCF相同平臺(tái)的信令交互工作功能。 SIWF的操作可以簡單地總結(jié)如下
每個(gè)S，WF與p-CSCF建立關(guān)聯(lián)并且將其自身注冊為它服務(wù) 的端系統(tǒng)的SIP客戶端.如在服務(wù)網(wǎng)關(guān)(發(fā)明3)的情況下，注 冊的客戶端地址可以只是由配屬其的端系統(tǒng)的AG通告 (advertise)的IP地址。或者，與商業(yè)上的考慮更一致的是， 當(dāng)由運(yùn)送者授權(quán)時(shí)，應(yīng)用服務(wù)器可以有管理程序分配的名字以使 用SIWF功能性來建立經(jīng)過NGN網(wǎng)絡(luò)的QoS能力的承載路徑。
當(dāng)它檢測到遣留信令消息(是建立發(fā)起于它所服務(wù)的端系統(tǒng) 的承栽流的請求)時(shí)，SIWF從該消息提取承栽流的F-Spec和 T-Spec兩者，并且構(gòu)建SIP邀請消息，其被尋址到與遺留消息尋 址的同一實(shí)體。但是代替使逸請請求URI的配置部分(scheme part)作為"sip:"的是，遺留信令協(xié)議的名稱可以被用作URI 的第一部分以向目標(biāo)指示邀請消息實(shí)際上來自于SIWF。初始的IP 遺留信令消息還可以作為SIP消息體的域被運(yùn)送，其方式與ISUP 消息在SIP-I (也稱為SIP-T)中被運(yùn)送的方式相同.
NGN網(wǎng)絡(luò)向注冊了它的目標(biāo)URI的名稱的SIWF轉(zhuǎn)發(fā)SIP邀 請消息(假定目標(biāo)通過支持SIWF (其注冊了自己的名稱或IP地 址)功能的AG配屬到NGN)。當(dāng)邀請消息到達(dá)注冊目標(biāo)的SIWF 時(shí)，那個(gè)SIWF就重建遺留信令消息(直接從邀請中運(yùn)送的消息 的封裝版本或者通過倒置在邀請中生成F-Spec和T-Spec的過 程)。重建的遺留消息然后被轉(zhuǎn)發(fā)到目標(biāo)實(shí)體.在本發(fā)明的一種 實(shí)現(xiàn)中，SIWF將使遺留消息的表觀源成為實(shí)際的發(fā)起實(shí)體，但在 其他實(shí)現(xiàn)中，尤其是那些發(fā)起和目標(biāo)實(shí)體在不同地址域的實(shí)現(xiàn)， SIWF將作為遺留信令消息的發(fā)起者出現(xiàn)。(后一方法使得SIWF接收遺留信令回復(fù)更簡單了 ，這是因?yàn)樗鼘?huì)被指向它，但是由
于它是NAT的一種形式，所以沒有ALG它仍可以造成應(yīng)用的破 壞)
在適當(dāng)?shù)倪M(jìn)程中，目標(biāo)實(shí)體將生成遺留協(xié)議響應(yīng).這將會(huì)被 服務(wù)AG獲取并導(dǎo)向SIWF。 SIWF將該響應(yīng)與重建的初始消息和 初始遨請匹配，SIWF將該遺留響應(yīng)轉(zhuǎn)換成SIP響應(yīng)(例如，200 O.K.)并且將它在返回信令路徑上轉(zhuǎn)發(fā)到服務(wù)于發(fā)起方的SIWF。 SIP響應(yīng)中的一些SDP域可以從遺留響應(yīng)中的域中被提取，而其 他將來自在邀請中傳遞的SDP.基于SDP中的F-Spec和 T-Spec,信令路徑上的CSCF將為承載路徑保留資源，
當(dāng)SIP響應(yīng)到達(dá)服務(wù)發(fā)起方的SIWF時(shí)，它再一次重建遺留 響應(yīng)消息并轉(zhuǎn)發(fā)它到實(shí)際的發(fā)起方上。
由于RSVP和RTSP是十分不同的協(xié)議，因此為每個(gè)協(xié)議分 別提供SIWF過程的更詳細(xì)的披露.
RSVP
現(xiàn)有操作模式
RSVP協(xié)議的目的在于保留網(wǎng)絡(luò)中的資源以支持單向承栽流 (在RSVP RFC中簡稱稱作"數(shù)據(jù)流")。雖然RSVP可以被用于 為多播流和一般任意到任意的會(huì)議會(huì)話保留資源，但本描述將它 的使用限制于單播或者僅僅兩個(gè)實(shí)體之間的點(diǎn)到點(diǎn)承栽流，例如 圖9中的AS和TE。在RSVP的操作模式下，流的源發(fā)起帶有"路 徑"消息的保留過程，"路徑"消息包括F-Spec (稱作過濾器規(guī)范， 川terspec)和T-Spec的形式。對于單播承載流，F(xiàn)-Spec是源 和目標(biāo)IP地址和端口號(hào)(和協(xié)議)的完全元組(tuple),稱作 固定過濾器，這表示在源發(fā)出"路徑"消息之前，需要知道目標(biāo)IP 地址和端口號(hào)，
"路徑"消息被尋址到承栽流的目的接收方，并且因此沿著發(fā) 送方和接收方之間的IP路由路徑.在簡單的單播情況中，"路徑" 消息的主要效果是在經(jīng)過的RSVP可行路徑中記錄先前的跳地址(hop address)以便返回的消息，即"resv"消息，可以經(jīng)過相 同的路徑從接收方返回到發(fā)送方.接收方回復(fù)"resv"消息，該消 息反向沿著"路徑"消息的每一個(gè)跳躍路徑傳送.由于它處理 "resv"消息，所以每個(gè)RSVP可行路由器基于該"resv"消息中的 T-Spec(稱作流規(guī)范(flowspec)某種程度上有點(diǎn)混亂)負(fù)責(zé)提 供(commit)承栽流的網(wǎng)絡(luò)資源.
使用RSVP到SIP SIWF網(wǎng)關(guān)
圖10是概要消息序列圖，示出了從應(yīng)用服務(wù)器(As)到客 戶端終端設(shè)備(TE)的經(jīng)過NGN的承栽流的建立中的信令交互 工作，其中As和TE兩者使用RSVP來請求網(wǎng)絡(luò)為該承栽流提供 QoS。 SIWF功能位于來自AS和TE兩者的第一 IP跳躍，就根據(jù) 圖1描述的NGN架構(gòu)而言，其暗示SIWF功能性被安置在配屬網(wǎng) 絡(luò)(AG)上，(如上所述，該第一跳躍可以通過讓AG認(rèn)識(shí)并以 隧道方式發(fā)送RSVP信令消息到另外安置在網(wǎng)絡(luò)中的SIWF功能 (例如，在與安置控制該AG的p-CSCF的相同的平臺(tái)上)被擴(kuò) 展)
假定AS提供給TE的應(yīng)用由它們之間消息的交換發(fā)起。在某 個(gè)點(diǎn)(例如，選擇了一部電影，并且列出了付款細(xì)節(jié))，AS確定 它需要向TE傳遞包流(承栽流)并且構(gòu)建規(guī)定流的源和目標(biāo)IP 地址和端口號(hào)(F-Spec)以及流的T-Spec的"路徑"消息.它 使該消息尋址到TE并且在S2將它發(fā)送出去."路徑"消息由 SIWF截獲并且轉(zhuǎn)換成SIP邀請消息S4。承栽流的F-Spec和 T-Spec被轉(zhuǎn)換成SDP參數(shù)(使用用于T-Spec的發(fā)明1)并且， 假定TE由IP地址識(shí)別，SIP目標(biāo)URI將是服務(wù)網(wǎng)關(guān)um (如上 所述).除了將F-Spec和T-Spec從RSVP格式轉(zhuǎn)換到SIP格 式，還有可能將初始RSVP消息附到SIP消息上.在SIWF機(jī)制 的一個(gè)實(shí)施例中，整個(gè)RSVP "路徑"消息可以作為邀請消息中 的不透明域(opaque field)被封裝并且運(yùn)送。在另一個(gè)實(shí)施例 中，僅僅"路徑"消息的內(nèi)部域而不是它的報(bào)頭將會(huì)在邀請消息中被運(yùn)送。如上所述，本發(fā)明的實(shí)施例可以選擇改變URI的"配 置"，得到邀請消息的弟一行，就像是
邀請rsvp:xxx.xxx.xxx.xxx SlP/2.y
其中xxx.xxx.xxx.xxx是IP (v4)地址，
NGN網(wǎng)絡(luò)將以上述方式將SIP遨請消息轉(zhuǎn)發(fā)到服務(wù)AG (服 務(wù)TE)的p-CSCF。根據(jù)SIWF已經(jīng)執(zhí)行的注冊IP地址(或者地 址范圍)的注冊功能(對于其，可以執(zhí)行它的交互工作功能)， p-CSCF將會(huì)變得可行。在URI中的配置已經(jīng)改變的實(shí)施例中， 將足以改變p-CSCF以轉(zhuǎn)發(fā)邀請到服務(wù)SIWF.
SIWF然后使用初始路徑消息的封裝(部分)(如果它們被包 含的話)，從邀請消息重新生成RSVP "路徑"消息，并且將它 自己的IP地址加入到該消息作為"先前跳躍"。它轉(zhuǎn)發(fā)該"路徑" 消息到TE8上(在S6) , TE8將使用"resv"消息S8響應(yīng)，該 消息被尋址到安置SIWF功能(它的先前跳躍)的節(jié)點(diǎn)。在接收 到邀請消息時(shí)，SIWF功能將匹配該"resp"消息(S8 )與它安 裝的狀態(tài)，并且根據(jù)那點(diǎn)，它將生成對邀請的響應(yīng)(例如，200OK 消息S10).由于RSVP規(guī)則允許TE將"resp"中的T-Spec 參數(shù)改成它在"路徑"消息中接收的不同的值，SIWF將不得不為 響應(yīng)而再生SDP的T-spec部分，而不是僅僅傳回它在遨請中接 收的相同的值。200 OK消息經(jīng)過NGN被運(yùn)送回服務(wù)AS的SIWF， 在消息的路徑上的CSCF向網(wǎng)關(guān)推行合適的策略，以便由SDP中 的F-Spec描述的承栽流將接收由SDP中的T-Spec指定的QoS 處理，在SIWF重新生成"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 能力的路由器如果當(dāng)他們沒有在"清除超時(shí)"間隔中看見這些"刷 新"消息，那么將釋放資源.明顯地，SIWF功能應(yīng)當(dāng)只將新的 RSVP消息轉(zhuǎn)換成SIP消息并且僅使用"刷新"消息來重置計(jì)時(shí)器。如果在足夠長的時(shí)間間隔內(nèi)沒有接收到"刷新"消息，那么
SIWF將發(fā)布SIP BYE消息來拆卸該會(huì)話。另外，當(dāng)SIP會(huì)話就 緒(in place)時(shí)，SIWF必須生成匹配刷新消息，以讓發(fā)送方和 接收方不會(huì)想到承栽路徑已經(jīng)丟失了它的保留.
不僅允許資源保留流逝一樣，而且RSVP提供顯式的拆卸。 在圖10中，發(fā)送方被描迷為通過發(fā)布"路徑拆卸(pathtear)" 消息S16,終止承栽路徑作為與接收方的會(huì)話的結(jié)束。當(dāng)SIWF 從RSVP發(fā)送方(或接收方)接收"路徑拆卸"(或"resv拆卸") 消息時(shí)，其發(fā)布SIP再見消息S18。再見消息被確認(rèn)(用200OK 響應(yīng)S20)，而RSVP "拆卸"消息沒有被確認(rèn)。
本領(lǐng)域中的專業(yè)技術(shù)人員將認(rèn)識(shí)到，并不要求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來描述媒體流.在語義上有相當(dāng)?shù)闹丿B.但是， 作為早于SIP開發(fā)的協(xié)議，它的目標(biāo)是SIP支持的應(yīng)用的子集。 RTSP的主要應(yīng)用范圍是多媒體表示，存儲(chǔ)的與實(shí)時(shí)的兩者。實(shí) 時(shí)網(wǎng)絡(luò)廣播和它們來自存儲(chǔ)的后續(xù)回放是RTSP的一種用途，音 頻或者視頻的互聯(lián)網(wǎng)流是其他用途。RTSP消息的語義與SIP不 直接匹配。消息的一種類型，描述(DESCR舊E)響應(yīng)消息，運(yùn) 送描迷潛在的幾個(gè)承栽流(從其中必須推導(dǎo)出每個(gè)流的T-Spec) 的表示的SDP，而其他消息類型，建立(SETUP)消息運(yùn)送一個(gè) 承栽流的F-Spec。單獨(dú)的建立(SETUP)消息是每個(gè)承栽流所 要求的.為了讓事情更糟，RSTP不要求描述消息的使用應(yīng)用 客戶端可以通過任何技術(shù)得到承栽流的媒體初始化參數(shù)。
然后，必須認(rèn)識(shí)到，難以產(chǎn)生有效的SIP-RTSP SIWF來處 理所有可能的RTSP的使用。因?yàn)?，?shí)際上非常少量的RTSP媒體服務(wù)器和播放器(即，REAL、 Quicktime、 windows)支配互 聯(lián)網(wǎng)上的RTSP的使用，被設(shè)計(jì)成處理它們的RTSP使用模式的 SIWF將會(huì)是最有益的。以下描述本發(fā)明的實(shí)施例，其針對在具有 交換的描述消息之后在會(huì)話中建立承載流的應(yīng)用。
使用RTSP到SIP SIWF網(wǎng)關(guān)
圖11描述RSTP客戶端或者播放器(安置在TE上)的消息 流，其向經(jīng)過NGN的懂RSTP的應(yīng)用服務(wù)器(AS)請求媒體流， 其中NGN在它的邊緣具有RTSP到SIP SIWF功能，該功能從 TE和AS截獲RTSP消息。
想要發(fā)起RSTP會(huì)話的RTSP客戶端將指導(dǎo)應(yīng)用服務(wù)器的 URL,所以它可以為描述請求消息生成請求-URI并且將那個(gè)消息 發(fā)送(在S22)到服務(wù)器.在圖11中，描述請求消息以直接穿過 安置SIWF功能的節(jié)點(diǎn)示出。只有響應(yīng)RTSP 200OK ( S24 )是 它們關(guān)注的，并且實(shí)際上僅服務(wù)于客戶端的SIWF需要緩存對描 述(DESCR舊E)的響應(yīng)的SDP主體部分.應(yīng)當(dāng)注意，描述會(huì)話 的媒體流的應(yīng)用服務(wù)器不必與服務(wù)媒體流的應(yīng)用服務(wù)器是相同的 實(shí)體，因此不保證服務(wù)于應(yīng)用服務(wù)器的SIWF與服務(wù)于媒體服務(wù) 器的是相同的一個(gè).
客戶端的SIWF (即，安置在TE配屬的AG上的SIWF)需 要能夠在導(dǎo)向該客戶端的消息的流中檢測RTSP200消息。具體 地，它需要檢測和緩存消息主體中運(yùn)送的媒體流的描述。亊實(shí)上， SIWF可以被指定為檢查用于"內(nèi)容-類型應(yīng)用/sdp"行的200 OK 消息的所有形式并且應(yīng)對可能的將來來自該客戶端的RTSP建立 請求而緩存該主體內(nèi)容。具體地，這將包含會(huì)話的SDP參數(shù)使用 HTTP響應(yīng)被傳送的情況，
由客戶端接收的SDP參數(shù)描述構(gòu)建會(huì)話的一個(gè)或多個(gè)媒體流 源。包含在每個(gè)源中的是它的um.因此，客戶端使用它從描述 響應(yīng)學(xué)習(xí)到的請求URI,向每個(gè)媒體流源發(fā)布建立(SETUP)請 求。(圖11示出為作為AS的媒體源發(fā)布的建立請求)。包含在設(shè)置消息中的是客戶端想要接收的承載流的端口號(hào)。(本領(lǐng)域中
的專業(yè)技術(shù)人員將認(rèn)識(shí)到，對于rtp/avp簡要承栽流，它實(shí)際上 是一對被指定的端口號(hào)，但是其中的第二個(gè)是用于RTSP業(yè)務(wù)的， 其不太可能比"盡力而為"QoS處理得到更多的益處)
當(dāng)客戶端的SIWF識(shí)別到建立請求S26時(shí)，它首先必須將它 與先前描迷響應(yīng)的緩存的SDP中的媒體流描述匹配。做到這一點(diǎn) 有兩處關(guān)鍵客戶端的IP地址，其在建立消息的包報(bào)頭源域和描 述響應(yīng)的目標(biāo)域中；以及建立消息的請求URI，其應(yīng)當(dāng)匹配來自 描述響應(yīng)的SDP的媒體流源URI。(通常僅匹配媒體流源URI 就足夠，但是有些情況下不同的客戶端被服務(wù)于不同的編碼，因 此還匹配客戶端將更安全)。當(dāng)找到匹配時(shí)，SIWF就可以為SIP 遨請消息S28構(gòu)建SDP的T-Spec部分.F-Spec的接收方端， 即，包類型和客戶端IP地址和端口也被編碼到SDP中。因?yàn)樵?建立消息中有請求URI，所以在邀請消息中有兩種選擇用于請求/ 目標(biāo)URI,即如杲媒體服務(wù)器已經(jīng)以明顯不同的URI (即SIWF 可以將其識(shí)別為可被SIP路由URI)被管理地注冊并且已經(jīng)返回 那個(gè)URI作為描述響應(yīng)的一部分，然后從建立消息拷貝的該URI 可以被用作用于邀請的請求URI;否則，可以使用建立消息的目 標(biāo)IP地址來構(gòu)建服務(wù)網(wǎng)關(guān)URK如上所述并且與上面的RSVP情 況類似)。
遨請消息以前述的方式被NGN轉(zhuǎn)發(fā)到服務(wù)器并且到達(dá)服務(wù) 器的SIWF (即，關(guān)聯(lián)于服務(wù)器配屬的AG的SIWF) *假設(shè)滿足 了策略檢查(見下)，則SIWF重新生成建立請求S30并且將它 轉(zhuǎn)發(fā)到媒體服務(wù)器，再一次，如同RSVP的情況，本發(fā)明的實(shí)施 例可以實(shí)際上傳輸封裝在遨請消息中的建立消息的拷貝，但是邀 請消息中的信息(排除這以外)將足以激活與由客戶端發(fā)送的語 義上相等的建立消息的生成。
當(dāng)服務(wù)器對建立消息發(fā)布它的響應(yīng)S32時(shí)，它將源端口號(hào)碼 包含在其中，以便當(dāng)服務(wù)器的SIWF截獲消息時(shí)，它能夠完成對 邀請消息的響應(yīng)S34中的SDL的F-Spec部分.SIP 200 OK響應(yīng)消息S34的剩余部分根據(jù)邀請消息的內(nèi)容構(gòu)建。當(dāng)200 OK響 應(yīng)在邀請的相反路徑上行進(jìn)時(shí)，各種CSCF在網(wǎng)關(guān)中安裝QoS策 略來確保由F-Spec描述的承栽路徑接收由T-Spec指定的QoS處理。
客戶端的SIWF將SIP 200 OK響應(yīng)S34轉(zhuǎn)換成對初始建立 消息(RSTP200OK響應(yīng)S36)的響應(yīng)并發(fā)送那個(gè)響應(yīng)到客戶端。 與SIP不同，RTSP還具有一組方法(命令)來控制媒體流的放 出(即，啟動(dòng)快速轉(zhuǎn)發(fā)序列)。這些命令僅僅涉及服務(wù)器并且不 需要被SIWF截獲.包含在該命令集中的是播放(PLAY)請求， 服務(wù)器實(shí)際上并不發(fā)送任何承栽流包，直到它已經(jīng)接收到了播放 請求。但是拆卸(TEARDOWN)請求S38由Sh/VF截獲并且被 轉(zhuǎn)換成SIP再見消息S40。 RTSP的拆卸和SIP的再見消息兩者 都需要確認(rèn)(200 OK) S42、 S44,
授權(quán)和記賬
IMS架構(gòu)的一個(gè)主要好處是用戶(以SIP客戶端的形式)是 經(jīng)過鑒權(quán)(在注冊(REGISTRATION)步驟期間)的并且NGN 生成記賬信息，該信息將用戶捆定到他們請求的QoS承栽流。在 NGN中提供SIWF網(wǎng)關(guān)，如上所述，減弱了這些控制，這是罔為 他們允許未注冊的端點(diǎn)請求并且使用網(wǎng)絡(luò)資源。在實(shí)際的商業(yè)部 署中，運(yùn)營商將需要提前授權(quán)承載流的一端，很可能是應(yīng)用服務(wù) 器，這是由于與他們協(xié)商收費(fèi)協(xié)定的應(yīng)用服務(wù)器的數(shù)量要少得多。 運(yùn)營商將管理地提供應(yīng)用服務(wù)器的地址到它的服務(wù)SIWF并且顯 式地激活交互工作功能.可以向SIWF提供向s-CSCF注冊的服 務(wù)器的URL,使得SIP消息可以采用該URL作為目標(biāo)-UR，而不 是服務(wù)網(wǎng)關(guān)IP地址方法被路由到該SIWF。
QoS的選擇性應(yīng)用
但是，即使當(dāng)應(yīng)用服務(wù)器被安全地識(shí)別并且達(dá)成了為它建立 的QoS承栽流收費(fèi)的商業(yè)協(xié)定時(shí)，該服務(wù)器還是不能選擇特定的客戶端對于發(fā)送到它的流，是接收QoS處理還是盡力而為的處理. (這可能依賴于客戶端用戶是否訂閱了應(yīng)用服務(wù)器供應(yīng)商)，本
發(fā)明的進(jìn)一步改進(jìn)(可應(yīng)用于遺留協(xié)議(例如通過um定義媒體
流的RTSP))將具有根據(jù)它們是否將接收QoS處理來使用不同 的URI以識(shí)別其他相等的媒體流的應(yīng)用。NGN中的所有SIWF將 必須能夠區(qū)分兩種類型的URI。參考圖11，當(dāng)建立消息到達(dá)服務(wù) 于SIWF的客戶端時(shí)，如果URI指示QoS處理是由應(yīng)用服務(wù)器"請 求"的，則它將檢查目標(biāo)URI并且僅僅將建立消息轉(zhuǎn)換到SIP遨 請消息，否則，SIWF功能忽略建立消息并且它以標(biāo)準(zhǔn)的遺留方式 進(jìn)行到應(yīng)用服務(wù)器而沒有涉及其他網(wǎng)絡(luò)，本領(lǐng)域中的有經(jīng)驗(yàn)的人 員將認(rèn)識(shí)到，有許多配置可以被用于區(qū)分URI: —個(gè)例子是使用 服務(wù)器的服務(wù)域的IMS域名作為附在該應(yīng)用服務(wù)器自己的URL 之后的URI的域部分。
在上述的本發(fā)明的第三方面中，為了建立QoS承載流，服務(wù) 器需要是懂SIP的(SIP speaker),但是服務(wù)器和客戶端之間的 協(xié)議被忽略.另一方面，在上述的第四方面中，客戶端和服務(wù)器 之間的協(xié)議被轉(zhuǎn)換成SIP,可以理解，可能結(jié)合該兩種方法.圖 12描述提供應(yīng)用服務(wù)器和客戶端之間的QoS承栽路徑的NGN實(shí) 施例，其中應(yīng)用服務(wù)器對本地SIWF網(wǎng)關(guān)使用遺留信令協(xié)議來請 求QoS,并且SIWF網(wǎng)關(guān)將該信令轉(zhuǎn)換成到(p-CSCF控制)客 戶端TE的服務(wù)網(wǎng)關(guān)的SIP消息.
有兩種情況要考慮。
在一種情況中，客戶端不懂遺留信令協(xié)議.服務(wù)器使用遺留 信令協(xié)議是因?yàn)樗萐IP的實(shí)現(xiàn)更簡單，這在圖13中RSVP的 例子中示出。注意，雖然在這種情況中，當(dāng)使用RSVP時(shí)SIWF 功能(或者至少RSVP消息的檢測)必須被安置在服務(wù)器的服務(wù) AG中，但是對于允許代理被配置(即，消息被IP尋址到代理) 的其他協(xié)議，例如RTSP, SIWF功能不需要在服務(wù)器和客戶端之 間的包的直接路徑中.具體地，SIWF功能可以被包含在服務(wù)器的 服務(wù)pCSCF中，在另一情況下，遺留信令協(xié)議在客戶端和服務(wù)器之間被交換，
但它仍然被服務(wù)器的SIWF檢查(沒有修改)。這在困14的RTSP 的例子中示出.在這種情況下，SIWF功能起著透明代理的作用 (即，RTSP包沒有被尋找到它)并且因此必須是服務(wù)AG的一 部分。
因此，這里描述的方法和系統(tǒng)克服了現(xiàn)今IMS的限制，現(xiàn)今 的IMS僅處理在懂SIP的端點(diǎn)之間的RTP上傳遞的多媒體.這 里描迷和主張權(quán)利要求的發(fā)明允許在從任何內(nèi)容源到任何目標(biāo)的 QoS承載流上傳遞任何內(nèi)容，同時(shí)維持了 IMS的安全性和收費(fèi)框 架，為運(yùn)營商打開了下一代網(wǎng)絡(luò)從客戶端和應(yīng)用服務(wù)供應(yīng)商獲取 收入的新來源。
以上描述的發(fā)明的實(shí)施例目的僅在于闡釋。因此本發(fā)明的范 圍唯一地由所附的權(quán)利要求的范圍限定。
權(quán)利要求
1.在使用會(huì)話發(fā)起協(xié)議(SIP)建立具有承載流的QoS處理的通信會(huì)話的通信網(wǎng)絡(luò)中，一種在通信會(huì)話中提供承載流的QoS處理的方法，使用不同的帶內(nèi)信令協(xié)議在兩個(gè)端設(shè)備之間建立該通信會(huì)話，該方法包括在兩個(gè)端設(shè)備之間的帶內(nèi)信令的路徑中提供信令交互工作功能(SIWF)的步驟，該SIWF操作用于檢測帶內(nèi)信令的至少一個(gè)信號(hào)狀態(tài)；以及基于檢測到的信號(hào)狀態(tài)，建立具有承載流的QoS處理的通信會(huì)話，該承載流跨越兩個(gè)端點(diǎn)之間的端到端路徑的至少一部分。
2. 如權(quán)利要求1所述的方法，其中建立通信會(huì)話的步驟包括 接收由兩個(gè)端點(diǎn)的第一個(gè)生成的帶內(nèi)信令協(xié)議消息，用于建立與兩個(gè)端點(diǎn)的第二個(gè)的通信路徑；生成一個(gè)或多個(gè)在功能上等同于接收到的帶內(nèi)信令協(xié)議消息 的SIP消息；接收建立具有QoS處理的通信會(huì)話的SIP消息；以及 生成一個(gè)或多個(gè)在功能上等同于接收到的SIP消息的帶內(nèi)信 令協(xié)議消息。
3. 如權(quán)利要求2所述的方法，其中帶內(nèi)信令協(xié)議是資源保留 協(xié)議(RSVP)和實(shí)時(shí)流協(xié)議(RTSP)中的一個(gè)。
4. 如權(quán)利要求2所述的方法，其中第一端點(diǎn)是下列中的任意 一個(gè)通過配屬網(wǎng)關(guān)(AG)配屬到網(wǎng)絡(luò)的非SIP客戶端；和 通過邊界網(wǎng)關(guān)(BG)配屬到網(wǎng)絡(luò)的遺留自治系統(tǒng)(AS)的 節(jié)點(diǎn)。
5. 如權(quán)利要求4所述的方法，其中SIWF與控制相關(guān)的網(wǎng)關(guān) 的呼叫狀態(tài)控制功能(CSCF)相關(guān)聯(lián)，
6. 如權(quán)利要求2所述的方法，其中生成一個(gè)或多個(gè)在功能上 等同于接收到的帶內(nèi)信令協(xié)議消息的SIP消息的步驟包括包含承 栽流的期望QoS處理的顯式識(shí)別的步驟。
7. 如權(quán)利要求6所述的方法，其中期望QoS處理的顯式識(shí) 別包括識(shí)別至少一個(gè)所需的帶寬的信息，
8. 如權(quán)利要求7所述的方法，其中期望QoS處理的顯式識(shí) 別進(jìn)一步包括識(shí)別所需的業(yè)務(wù)類別的信息。
9. 如權(quán)利要求7所述的方法，其中信息包括表示至少一個(gè)預(yù) 定的帶寬的標(biāo)識(shí)符。
10. 如權(quán)利要求2所述的方法，其中第二端點(diǎn)是連接到網(wǎng)絡(luò) 的懂SIP的端點(diǎn)(SIP speaker)，并且其中建立通信會(huì)話的SIP 消息由第二端點(diǎn)生成.
11. 如權(quán)利要求2所迷的方法，其中第二端點(diǎn)是通過各自的 配屬網(wǎng)關(guān)(AG)配屬到網(wǎng)絡(luò)的非SIP客戶端，并且其中建立通信 會(huì)話的SIP消息由代表第二端點(diǎn)的普通代理生成。
12. 如權(quán)利要求11所述的方法，其中普通代理與控制各自的 配屬網(wǎng)關(guān)的呼叫狀態(tài)控制功能(CSCF)相關(guān)聯(lián)。
13. 如權(quán)利要求2所迷的方法，其中第二端點(diǎn)是通過邊界網(wǎng) 關(guān)(BG)配屬到網(wǎng)絡(luò)的遺留自治系統(tǒng)(AS)的節(jié)點(diǎn)，并且其中 建立通信會(huì)話的SIP消息由對等的信令交互工作功能(SIWF)基 于從第二端點(diǎn)接收的帶內(nèi)信令消息生成。
14. 如權(quán)利要求13所述的方法，其中對等的信令交互工作功 能與控制邊界網(wǎng)關(guān)(BG)的邊界呼叫狀態(tài)控制功能(b-CSCF) 相關(guān)聯(lián)。
15. 在使用會(huì)話發(fā)起協(xié)議(SIP)建立具有承栽流的QoS處 理的通信會(huì)話的通信網(wǎng)絡(luò)中， 一種計(jì)算機(jī)可讀介質(zhì)，包括軟件代 碼，用于在通信會(huì)話中提供承栽流的QoS處理，使用不同的帶內(nèi) 信令協(xié)議在兩個(gè)端設(shè)備之間建立該通信會(huì)話，該軟件代碼實(shí)現(xiàn)在 兩個(gè)端設(shè)備之間的帶內(nèi)信令的路徑中的信令交互工作功能(SIWF),該SIWF操作用于檢測帶內(nèi)信令的至少一個(gè)信號(hào)狀態(tài)；以及 基于檢測到的信號(hào)狀態(tài)，建立具有承栽流的QoS處理的通信 會(huì)話，該承栽流跨越兩個(gè)端點(diǎn)之間的端到端路徑的至少 一 部分。
16. 如權(quán)利要求1S所述的計(jì)算機(jī)可讀介質(zhì)，其中用于建立通 信會(huì)話的軟件代碼包括步驟接收由兩個(gè)端點(diǎn)的第一個(gè)生成的帶內(nèi)信令協(xié)議消息，用于建 立與兩個(gè)端點(diǎn)的第二個(gè)的通信路徑；生成一個(gè)或多個(gè)在功能上等同于接收到的帶內(nèi)信令協(xié)議消息 的SIP消息；接收建立具有QoS處理的通信會(huì)話的SIP消息；以及 生成一個(gè)或多個(gè)在功能上等同于接收到的SIP消息的帶內(nèi)信 令協(xié)議消息。
17. 如權(quán)利要求16所述的計(jì)算機(jī)可讀介質(zhì)，其中帶內(nèi)信令協(xié) 議是資源保留協(xié)議(RSVP)和實(shí)時(shí)流協(xié)議(RTSP)中的一個(gè)，
18. 如權(quán)利要求16所述的計(jì)算機(jī)可讀介質(zhì)，其中第一端點(diǎn)是 下列中的任意一個(gè)通過配屬網(wǎng)關(guān)(AG)配屬到網(wǎng)絡(luò)的非SIP客戶端；和 通過邊界網(wǎng)關(guān)(BG)配屬到網(wǎng)絡(luò)的遺留自治系統(tǒng)(AS)的 節(jié)點(diǎn)。
19. 如權(quán)利要求4所迷的方法，其中SIWF與控制相關(guān)的網(wǎng) 關(guān)的呼叫狀態(tài)控制功能(CSCF)相關(guān)聯(lián).
20. 如權(quán)利要求16所述的計(jì)算機(jī)可讀介質(zhì)，其中生成一個(gè)或 多個(gè)在功能上等同于接收到的帶內(nèi)信令協(xié)議消息的SIP消息的步 驟包括包含承栽流的期望QoS處理的顯式識(shí)別的步驟。
21. 如權(quán)利要求20所述的計(jì)算機(jī)可讀介質(zhì)，其中期望QoS 處理的顯式識(shí)別包括識(shí)別至少一個(gè)所需的帶寬的信息.
22. 如權(quán)利要求21所述的計(jì)算機(jī)可讀介質(zhì)，其中期望QoS 處理的顯式識(shí)別進(jìn)一步包括識(shí)別需求的業(yè)務(wù)類別的信息。
23. 如權(quán)利要求21所述的計(jì)算機(jī)可讀介質(zhì)，其中信息包括表 示至少一個(gè)預(yù)定的帶寬的標(biāo)識(shí)符，
24. 如權(quán)利要求16所述的計(jì)算機(jī)可讀介質(zhì)，其中第二端點(diǎn)是 連接到網(wǎng)絡(luò)的懂SIP的端點(diǎn)，并且其中建立通信會(huì)話的SIP消息 由第二端點(diǎn)生成。
25. 如權(quán)利要求16所述的計(jì)算機(jī)可讀介質(zhì)，其中第二端點(diǎn)是 通過各自的配屬網(wǎng)關(guān)(AG)連接到網(wǎng)絡(luò)的非SIP客戶端，并且其 中建立通信會(huì)話的SIP消息由代表第二端點(diǎn)的普通代理生成.
26. 如權(quán)利要求25所述的計(jì)算機(jī)可讀介質(zhì)，其中普通代理與 控制各自的配屬網(wǎng)關(guān)的呼叫狀態(tài)控制功能(CSCF)相關(guān)聯(lián)。
27. 如權(quán)利要求16所述的計(jì)算機(jī)可讀介質(zhì)，其中第二端點(diǎn)是 通過邊界網(wǎng)關(guān)(BG)配屬到網(wǎng)絡(luò)的遺留自治系統(tǒng)(AS)的節(jié)點(diǎn)， 并且其中建立通信會(huì)話的SIP消息由對等的信令交互工作功能(SIWF)基于從第二端點(diǎn)接收的帶內(nèi)信令消息生成.
28. 如權(quán)利要求27所述的計(jì)算機(jī)可讀介質(zhì)，其中對等的信令 交互工作功能與控制邊界網(wǎng)關(guān)(BG)的邊界呼叫狀態(tài)控制功能(b-CSCF)相關(guān)聯(lián)，
全文摘要
方法和系統(tǒng)用于擴(kuò)展NGN的IMS/SIP架構(gòu)以提供QoS服務(wù)給普通承載流。支持在通信會(huì)話中提供承載流的QoS處理，使用不同的帶內(nèi)信令協(xié)議在兩個(gè)端設(shè)備之間建立該通信會(huì)話。在兩個(gè)端設(shè)備之間的帶內(nèi)信令的路徑中提供了信令交互工作功能(SIWF)。該SIWF操作用于檢測帶內(nèi)信令的至少一個(gè)信號(hào)狀態(tài)；以及基于檢測到的信號(hào)狀態(tài)，建立具有承載流的QoS處理的通信會(huì)話，該承載流跨越兩個(gè)端點(diǎn)之間的端到端路徑的至少一部分。
文檔編號(hào)H04L12/12GK101606353SQ200780051238
公開日2009年12月16日 申請日期2007年11月15日 優(yōu)先權(quán)日2006年12月14日
發(fā)明者L·凱西 申請人:北方電訊網(wǎng)絡(luò)有限公司