繆永生　倪明

摘要：認(rèn)為VoLTE技術(shù)能夠提供高清語音、視頻等多媒體業(yè)務(wù)，是LTE下唯一的、端到端的目標(biāo)語音解決方案。針對(duì)號(hào)碼攜帶的國(guó)家/地區(qū)中各運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間互通，提出了4種方案以及部署建議，從而實(shí)現(xiàn)了不同運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間互通，對(duì)全球VoLTE網(wǎng)絡(luò)互通有較強(qiáng)的借鑒和指導(dǎo)意義。

關(guān)鍵詞：VoLTE；IMS；互通；號(hào)碼攜帶

演進(jìn)到第4代無線數(shù)據(jù)網(wǎng)絡(luò)對(duì)運(yùn)營(yíng)商來說是大勢(shì)所趨[1]，基于LTE的語音業(yè)務(wù)（VoLTE）能夠提供高清語音業(yè)務(wù)與消息、高清視頻等多媒體業(yè)務(wù)，以及同互聯(lián)網(wǎng)業(yè)務(wù)進(jìn)行融合，符合電信網(wǎng)絡(luò)演進(jìn)方向。全球移動(dòng)通信系統(tǒng)協(xié)會(huì)（GSMA）和下一代移動(dòng)通信網(wǎng)絡(luò)聯(lián)盟（NGMN）都已經(jīng)宣布將VoLTE作為業(yè)界長(zhǎng)期演進(jìn)/（LTE）下唯一的、端到端的目標(biāo)語音解決方案[2]。而目前只有同一個(gè)運(yùn)營(yíng)商的客戶才能夠使用VoLTE業(yè)務(wù)，為了應(yīng)對(duì)過頂傳球（OTT）的競(jìng)爭(zhēng)，給客戶更好的業(yè)務(wù)體驗(yàn)，不同電信運(yùn)營(yíng)商之間的VoLTE互通的需求尤為緊迫。

文章在深入研究VoLTE網(wǎng)絡(luò)架構(gòu)和流程基礎(chǔ)上，重點(diǎn)研究了支持號(hào)碼攜帶業(yè)務(wù)的國(guó)家和地區(qū)的不同運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間的互通要求，提出了一些解決方案和部署建議。

1 VoLTE網(wǎng)絡(luò)互通概況

1.1 VoLTE系統(tǒng)架構(gòu)

在VoLTE系統(tǒng)架構(gòu)中，由LTE和演進(jìn)的分組網(wǎng)（EPC）系統(tǒng)提供承載，由IP多媒體子系統(tǒng)（IMS）系統(tǒng)提供業(yè)務(wù)控制，實(shí)現(xiàn)端到端的基于分組域的語音、視頻業(yè)務(wù)。IMS作為控制核心，可以提供和電路域類似的語音業(yè)務(wù)及其補(bǔ)充業(yè)務(wù)，包括號(hào)碼顯示、呼叫轉(zhuǎn)移、呼叫 等待、會(huì)議電話等。VoLTE網(wǎng)絡(luò)典型系統(tǒng)架構(gòu)如圖1所示。圖1中主要包括終端（UE）、LTE（eNodeB）、EPC（移動(dòng)性管理實(shí)體（MME）、服務(wù)網(wǎng)關(guān)（S-GW）、PDN網(wǎng)關(guān)（P-GW））、IMS（接入會(huì)話邊界控制（A-SBC）、代理呼叫會(huì)話控制（P-CSCF）、接入轉(zhuǎn)換控制功能（ATCF）、查詢呼叫會(huì)話控制（I-CSCF）、服務(wù)呼叫會(huì)話控制（S-CSCF）、應(yīng)用服務(wù)器（AS）、電話號(hào)碼映射工作組（ENUM）、媒體網(wǎng)關(guān)控制功能（MGCF）、簽約位置功能/歸屬簽約用戶服務(wù)器（SLF/HSS））等網(wǎng)元。其中呼叫會(huì)話控制（CSCF）實(shí)現(xiàn)了呼叫控制，AS實(shí)現(xiàn)了類似2G/3G的多媒體電話補(bǔ)充業(yè)務(wù)[3-5]。

1.2 VoLTE與VoLTE網(wǎng)絡(luò)互通

如果主、被叫用戶均采用VoLTE業(yè)務(wù)，LTE和EPC網(wǎng)絡(luò)對(duì)于VoLTE業(yè)務(wù)來說相當(dāng)于接入網(wǎng)，并不參與網(wǎng)絡(luò)互通。真正實(shí)現(xiàn)運(yùn)營(yíng)商間的VoLTE網(wǎng)絡(luò)互通的是IMS系統(tǒng)，也可以說VoLTE網(wǎng)絡(luò)的互通要求其實(shí)就是IMS網(wǎng)間的互通要求[6]。

通常對(duì)于不支持號(hào)碼攜帶的國(guó)家/地區(qū)，跨運(yùn)營(yíng)商的VoLTE互通，能夠根據(jù)被叫號(hào)碼的信息，獲知被叫用戶所歸屬的運(yùn)營(yíng)商，從而實(shí)現(xiàn)不同運(yùn)營(yíng)商之間的互通。目前不同運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間互通有如下的幾種方案：

（1）主叫IMS網(wǎng)絡(luò)完成主叫業(yè)務(wù)后，主叫IMS網(wǎng)絡(luò)的S-CSCF，根據(jù)被叫號(hào)碼的號(hào)段信息，路由業(yè)務(wù)請(qǐng)求到被叫號(hào)碼歸屬的IMS網(wǎng)絡(luò)[7-10]。

（2）出于安全考慮，跨運(yùn)營(yíng)商之間都會(huì)部署邊界網(wǎng)關(guān)。主叫IMS網(wǎng)絡(luò)完成主叫業(yè)務(wù)后，主叫IMS網(wǎng)絡(luò)的互連邊界控制功能（IBCF）根據(jù)被叫號(hào)碼的號(hào)段信息，選擇被叫號(hào)碼歸屬的IMS網(wǎng)絡(luò)，并將業(yè)務(wù)請(qǐng)求路由到被叫歸屬的IBCF網(wǎng)元。其中，信令面的互通網(wǎng)元是IBCF，互通協(xié)議采用會(huì)話發(fā)起協(xié)議（SIP）；媒體面的互通網(wǎng)元是轉(zhuǎn)換網(wǎng)關(guān)（TrGW），互通協(xié)議采用實(shí)時(shí)傳輸協(xié)議（RTP）。

（3）由于電路交換域（CS）網(wǎng)絡(luò)是各移動(dòng)運(yùn)營(yíng)商成熟的網(wǎng)絡(luò)，VoLTE與VoLTE 網(wǎng)絡(luò)可以通過主叫IMS網(wǎng)絡(luò)的S-CSCF將業(yè)務(wù)請(qǐng)求路由到MGCF，由主叫電路域網(wǎng)絡(luò)路由到被叫電路域網(wǎng)絡(luò)，再由被叫電路域網(wǎng)絡(luò)路由到被叫IMS網(wǎng)絡(luò)。這種方案的好處是通過電路域來路由保護(hù)了已有的投資，缺點(diǎn)是無法實(shí)現(xiàn)跨運(yùn)營(yíng)商的VoLTE高清語音、視頻業(yè)務(wù)。

方案1和方案2類似，可以實(shí)現(xiàn)不支持號(hào)碼攜帶的國(guó)家/地區(qū)不同運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間互通，方案3缺點(diǎn)是無法實(shí)現(xiàn)跨運(yùn)營(yíng)商的VoLTE高清語音、視頻業(yè)務(wù)。

1.3 號(hào)碼攜帶下VoLTE網(wǎng)絡(luò)之間互通

在網(wǎng)絡(luò)支持號(hào)碼攜帶業(yè)務(wù)后，用戶的號(hào)碼和運(yùn)營(yíng)商不再具有簡(jiǎn)單對(duì)應(yīng)關(guān)系，現(xiàn)有網(wǎng)間互通根據(jù)被叫用戶號(hào)碼選路的方式被顛覆。號(hào)碼攜帶可以是攜入或者攜出，號(hào)碼攜帶業(yè)務(wù)開展后，對(duì)語音業(yè)務(wù)路由的判斷采用被叫號(hào)碼+路由號(hào)碼（RN）綜合判斷的方式進(jìn)行，對(duì)于簽約號(hào)碼攜帶業(yè)務(wù)的被叫用戶則代之以RN為依據(jù)進(jìn)行后續(xù)接續(xù)路由。對(duì)移動(dòng)網(wǎng)絡(luò)需要由主叫網(wǎng)絡(luò)通過與號(hào)碼攜帶數(shù)據(jù)庫（NPDB）交互信息來判斷用戶是否簽約號(hào)碼攜帶業(yè)務(wù)以及RN信息，以便主叫網(wǎng)絡(luò)根據(jù)RN信息選擇正確的歸屬運(yùn)營(yíng)商網(wǎng)絡(luò)。移動(dòng)網(wǎng)絡(luò)通常部署移動(dòng)號(hào)碼攜帶（MNP），MNP中保存了號(hào)碼以及攜入攜出和RN等信息。

支持號(hào)碼攜帶的國(guó)家和地區(qū)，跨運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間的互通，就無法簡(jiǎn)單通過被叫號(hào)碼進(jìn)行路由。雖然電路域是成熟網(wǎng)絡(luò)，支持查詢MNP并針對(duì)被叫號(hào)碼+RN完成路由，但是如果VoLTE網(wǎng)絡(luò)之間通過傳統(tǒng)電路域互通，由于承載的限制，則無法實(shí)現(xiàn)高清語音、視頻業(yè)務(wù)。

在移動(dòng)互聯(lián)網(wǎng)時(shí)代，面對(duì)OTT的市場(chǎng)競(jìng)爭(zhēng)，很多移動(dòng)運(yùn)營(yíng)商正在加緊部署VoLTE網(wǎng)絡(luò)，不同移動(dòng)運(yùn)營(yíng)商也在加強(qiáng)合作，2014年AT&T和Verizon共同宣布2015年正式實(shí)現(xiàn)VoLTE跨網(wǎng)兼容和互通。其他國(guó)家和地區(qū)如香港CSL、HKT、數(shù)碼通等運(yùn)營(yíng)商之間也在進(jìn)行VoLTE互通測(cè)試或商用。因此號(hào)碼攜帶的國(guó)家/地區(qū)各運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間互通方案顯得尤為重要和緊迫，必須能夠?qū)崿F(xiàn)支持號(hào)碼攜帶的不同運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間互通，從而實(shí)現(xiàn)VoLTE高清語音、視頻業(yè)務(wù)。

2 VoLTE互通方案分析

2.1 兩個(gè)VoLTE網(wǎng)絡(luò)間互通方案

2.1.1 方案1

對(duì)于支持號(hào)碼攜帶的國(guó)家和地區(qū)，如果不同的運(yùn)營(yíng)商之間進(jìn)行VoLTE網(wǎng)絡(luò)之間互通，那么就需要VoLTE和VoLTE直接互通，以保證高清語音、視頻業(yè)務(wù)的正常開展。如果僅有兩個(gè)運(yùn)營(yíng)商之間VoLTE互通，則可以采用下面提供的ENUM互查解決方案。假設(shè)運(yùn)營(yíng)商1的VoLTE用戶呼叫運(yùn)營(yíng)商2的VoLTE用戶，信令和媒體流向可參考圖2。

（1）運(yùn)營(yíng)商1的主叫IMS網(wǎng)絡(luò)完成主叫業(yè)務(wù)后，主叫S-CSCF查詢主叫網(wǎng)絡(luò)的ENUM。

（2）運(yùn)營(yíng)商1的ENUM在本地查找被叫用戶，如果查詢不到則向運(yùn)營(yíng)商2的ENUM查詢。

（3）運(yùn)營(yíng)商2的ENUM返回查詢結(jié)果給運(yùn)營(yíng)商1的ENUM，然后運(yùn)營(yíng)商1的ENUM將查詢結(jié)果返回給S-CSCF。

（4）主叫IMS網(wǎng)絡(luò)的S-CSCF/IBCF根據(jù)ENUM返回的結(jié)果，將業(yè)務(wù)請(qǐng)求路由到運(yùn)營(yíng)商2的IMS網(wǎng)絡(luò)，實(shí)現(xiàn)兩個(gè)運(yùn)營(yíng)商之間的VoLTE互通。

由于支持號(hào)碼攜帶業(yè)務(wù)，號(hào)碼無法區(qū)分不同的運(yùn)營(yíng)商，運(yùn)營(yíng)商1的ENUM在本地查詢后，在對(duì)方開放ENUM查詢接口的前提下，再去嘗試查詢運(yùn)營(yíng)商2的ENUM，這樣就能確認(rèn)被叫是否是運(yùn)營(yíng)商2的VoLTE用戶，實(shí)現(xiàn)兩個(gè)VOLTE網(wǎng)絡(luò)的互通。

2.1.2 方案2

方案1需要ENUM在本地查找無果后，再去對(duì)端IMS網(wǎng)絡(luò)查詢ENUN。在方案1的基礎(chǔ)上還有一種類似的解決方案2，需要S-CSCF定制處理邏輯，即S-CSCF首先查詢本地ENUM，如果查詢不到則再查詢運(yùn)營(yíng)商2的ENUM，S-CSCF根據(jù)運(yùn)營(yíng)商2的ENUM返回結(jié)果，將業(yè)務(wù)請(qǐng)求路由到運(yùn)營(yíng)商2的IMS網(wǎng)絡(luò)，能達(dá)到方案1同樣的效果。方案2的如圖3所示。這兩個(gè)方案都需要運(yùn)營(yíng)商給對(duì)方IMS網(wǎng)絡(luò)開放ENUM查詢接口。

2.2 多個(gè)VoLTE網(wǎng)絡(luò)間互通方案

2.2.1 方案1

通常一個(gè)國(guó)家/地區(qū)，移動(dòng)運(yùn)營(yíng)商會(huì)多于兩個(gè)，不同運(yùn)營(yíng)商之間的VoLTE互通會(huì)存在更多的困難。在支持號(hào)碼攜帶的國(guó)家/地區(qū)，如果借鑒兩個(gè)VoLTE互通方案，本地的ENUM需要不斷地嘗試其他運(yùn)營(yíng)商的ENUM，但效率低、時(shí)延大，方案不可行。

另外，傳統(tǒng)的電路域移動(dòng)網(wǎng)絡(luò)，為了解決號(hào)碼攜帶下的互通，通常必須部署移動(dòng)號(hào)碼攜帶（MNP），電路域網(wǎng)元查詢MNP得到號(hào)碼和RN信息，以便路由到正確的歸屬運(yùn)營(yíng)商。IMS網(wǎng)絡(luò)目前和MNP網(wǎng)元沒有直接的接口，如果IMS網(wǎng)絡(luò)定制MAP接口直接查詢MNP，一方面會(huì)增加IMS的復(fù)雜度；另一方面則會(huì)增加現(xiàn)網(wǎng)MNP的負(fù)荷。

假設(shè)電路域后續(xù)不再查詢MNP，直接由IMS域查詢MNP，但是這樣對(duì)現(xiàn)網(wǎng)改動(dòng)較大，且不利于保護(hù)運(yùn)營(yíng)商已有投資。因此在VoLTE網(wǎng)絡(luò)建設(shè)初期階段，我們提出了一種新的解決方案，實(shí)現(xiàn)了支持號(hào)碼攜帶的國(guó)家/地區(qū)的多VoLTE網(wǎng)絡(luò)之間的互通。

如圖4所示，新方案需要部署一套共享ENUM，該邏輯網(wǎng)元可以和IMS中ENUM網(wǎng)元進(jìn)行合設(shè)或者分設(shè)。共享ENUM從MNP中通過文件傳輸協(xié)議（FTP）同步文件方式，得到號(hào)碼/號(hào)段歸屬運(yùn)營(yíng)商RN信息。當(dāng)運(yùn)營(yíng)商1的主叫IMS網(wǎng)絡(luò)完成主叫業(yè)務(wù)后，主叫S-CSCF查詢主叫網(wǎng)絡(luò)的ENUM。如果本地ENUM無查詢的用戶信息，則本地ENUM進(jìn)一步查詢共享 ENUM，共享ENUM根據(jù)從MNP得到的用戶歸屬運(yùn)營(yíng)商RN信息，決定去相應(yīng)運(yùn)營(yíng)商的ENUM查詢。假設(shè)被叫號(hào)碼現(xiàn)在歸屬運(yùn)營(yíng)商3，那么共享ENUM直接查詢運(yùn)營(yíng)商3的ENUM，并返回相應(yīng)的查詢結(jié)果，主叫IMS網(wǎng)絡(luò)通過查詢結(jié)果將業(yè)務(wù)請(qǐng)求路由到運(yùn)營(yíng)商3。通過上述架構(gòu)，實(shí)現(xiàn)了多VoLTE網(wǎng)絡(luò)的互通，保證了高清語音、視頻業(yè)務(wù)的正常開展。具體流程說明如下：

（1）MNP定時(shí)向共享 ENUM同步FTP數(shù)據(jù)文件。

（2）共享ENUM根據(jù)從MNP同步的數(shù)據(jù)，得到號(hào)碼/號(hào)段對(duì)應(yīng)的運(yùn)營(yíng)商信息，即根據(jù)同步數(shù)據(jù)中RN信息獲知?dú)w屬運(yùn)營(yíng)商信息。

（3）主叫IMS網(wǎng)絡(luò)S-CSCF針對(duì)被叫號(hào)碼，查詢本地ENUM，ENUM在本地查找無果后，進(jìn)一步查找共享ENUM。

（4）共享ENUM根據(jù)從MNP得到的號(hào)碼歸屬運(yùn)營(yíng)商信息，查詢用戶歸屬運(yùn)營(yíng)商開放的ENUM，并返回查詢結(jié)果給本地ENUM。

（5）主叫IMS網(wǎng)絡(luò)S-CSCF/IBCF根據(jù)本地ENUM返回的結(jié)果，將業(yè)務(wù)請(qǐng)求路由到被叫歸屬的IMS網(wǎng)絡(luò)。

通過該方案可以實(shí)現(xiàn)不同VoLTE之間的互通，并且可以實(shí)現(xiàn)VoLTE用戶通過IMS網(wǎng)絡(luò)的互通，非VoLTE用戶不增加IMS網(wǎng)絡(luò)的信令負(fù)荷，仍然通過傳統(tǒng)電路域與其他運(yùn)營(yíng)商互通，這樣保護(hù)了運(yùn)營(yíng)商的已有投資，與此同時(shí)還可以減少運(yùn)營(yíng)商對(duì)IMS網(wǎng)絡(luò)的投資。

該方案要求互通的運(yùn)營(yíng)商之間，開放ENUM查詢接口。對(duì)于個(gè)別運(yùn)營(yíng)商，出于安全等因素考慮，如果不愿意開放接口又想實(shí)現(xiàn)VoLTE互通，可以采用本方案。本方案可以通過共享 ENUM上靜態(tài)預(yù)配置，然后直接給查詢請(qǐng)求的本地ENUM構(gòu)造成功響應(yīng)，響應(yīng)結(jié)果的SIP統(tǒng)一資源標(biāo)識(shí)符（SIP URI）組成包括：userpart部分為號(hào)碼，domain部分為歸屬運(yùn)營(yíng)商的域名，如再添加user=phone參數(shù)，這樣主叫IMS網(wǎng)絡(luò)同樣可以根據(jù)ENUM返回的SIP URI路由并實(shí)現(xiàn)VoLTE互通。無論被叫是否是VoLTE用戶，都會(huì)通過IMS網(wǎng)絡(luò)路由到歸屬運(yùn)營(yíng)商網(wǎng)絡(luò)，這樣就會(huì)增加運(yùn)營(yíng)商IMS網(wǎng)絡(luò)的信令負(fù)荷，不利于保護(hù)運(yùn)營(yíng)商已有的電路域投資。

2.2.2 方案2

在VoLTE網(wǎng)絡(luò)不斷發(fā)展的后期，IMS用戶不斷增加，CS域用戶不斷減少，此時(shí)不光有VoLTE互通需求，還有IMS網(wǎng)絡(luò)承接非IMS號(hào)碼路由的需求。那么可以通過AS直接查詢MNP的方案實(shí)現(xiàn)VoLTE與VoLTE的互通。圖5是該方案的示意圖，主要流程如下：

（1）主叫IMS網(wǎng)絡(luò)S-CSCF網(wǎng)元在做完主叫業(yè)務(wù)后，主叫側(cè)最后再次觸發(fā)AS，如多媒體電話（MMTEL）AS。

（2）AS通過MAP接口直接查詢MNP，根據(jù)MNP返回的號(hào)碼攜帶RN信息，能夠在被叫號(hào)碼前面插入不同的前綴。

（3）S-CSCF/IBCF可以根據(jù)號(hào)碼前綴將業(yè)務(wù)請(qǐng)求路由到不同的歸屬運(yùn)營(yíng)商。

通過該方案同樣可以實(shí)現(xiàn)VoLTE互通，且實(shí)現(xiàn)了非IMS用戶由IMS網(wǎng)絡(luò)路由的功能。電路域網(wǎng)元無需再查詢MNP，對(duì)于MNP沒有增加負(fù)荷消耗。如果歸屬運(yùn)營(yíng)商不支持VoLTE網(wǎng)絡(luò)，那么S-CSCF根據(jù)號(hào)碼前綴路由到MGCF，然后由電路域路由到歸屬網(wǎng)絡(luò)。

3 VoLTE互通部署建議

對(duì)于不支持號(hào)碼攜帶業(yè)務(wù)的國(guó)家/地區(qū)，通過號(hào)碼/號(hào)段信息能夠知道被叫號(hào)碼所歸屬的運(yùn)營(yíng)商信息，現(xiàn)有方案能夠?qū)崿F(xiàn)不同運(yùn)營(yíng)商之間的VoLTE互通。

對(duì)于支持號(hào)碼攜帶業(yè)務(wù)的國(guó)家和地區(qū)，我們提出了幾種有效解決方案，能夠?qū)崿F(xiàn)支持號(hào)碼攜帶的不同運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間互通。各種方案優(yōu)、缺點(diǎn)和部署建議，見表1。

4 結(jié)束語

我們重點(diǎn)研究了支持號(hào)碼攜帶業(yè)務(wù)的國(guó)家和地區(qū)中不同運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間的互通要求，并提出了4種有效解決方案，實(shí)現(xiàn)了不同運(yùn)營(yíng)商VoLTE網(wǎng)絡(luò)之間互通。目前部分方案已經(jīng)在香港地區(qū)進(jìn)行了驗(yàn)證，方案可行，用戶業(yè)務(wù)體驗(yàn)良好。這對(duì)于全球VoLTE網(wǎng)絡(luò)互通有較強(qiáng)的借鑒意義。

參考文獻(xiàn)

[1] 李中科， 梁斌， 廖芳芳. VoLTE和CS語音補(bǔ)充業(yè)務(wù)一致性方案研究[J]. 郵電設(shè)計(jì)技術(shù)， 2014（2）： 6-10

[2] 朱斌， 文濤， 符剛. VoLTE部署關(guān)鍵問題研究[J]. 郵電設(shè)計(jì)技術(shù)， 2014（2）： 1-5

[3] 劉揚(yáng)， 張秀瑩. 號(hào)碼攜帶業(yè)務(wù)對(duì)IMS網(wǎng)絡(luò)互通影響分析[J]. 郵電設(shè)計(jì)技術(shù)， 2012（5） ： 29-32

[4] 王志松， 劉冬梅， 張林林. VoLTE中的業(yè)務(wù)域部署方案[J]. 移動(dòng)通信， 2014（3）： 57-62

[5] 繆永生. 通用引導(dǎo)架構(gòu)在IMS網(wǎng)絡(luò)中應(yīng)用研究[J]. 中興通訊技術(shù)， 2014， 20（4）： 40-43.doi： 10.3969/j.issn.1009-6868.2014.04.010

[6] 許慕鴻. LTE語音目標(biāo)解決方案_VoLTE技術(shù)[J]. 現(xiàn)代電信科技， 2013（11） ： 33-45

[7] 3GPP TS 23.228 IP Multimedia Subsystem （IMS） [S]

[8] 3GPP TS 24.229 IP Multimedia Call Control based on SIP and SDP[S]

[9] 3GPP TS 23.221 Architectural Requirements Stage 1 [S]

[10] 3GPP TS 22.228 Service Requirements for the IP Multimedia Core Network Subsystem Stage 1 [S]