視頻炫鈴業(yè)務流程與典型問題

中國聯(lián)通山東省分公司北部大區(qū)運營中心 馬翔 徐延輝 王昊

本文簡要介紹了視頻炫鈴平臺的業(yè)務特點、組網(wǎng)架構(gòu)以及業(yè)務流程,分析了視頻炫鈴業(yè)務信令交互過程中需關(guān)注的重點消息及消息內(nèi)的重點字段。通過對案例處理過程的分析,為后續(xù)業(yè)務投訴處理及問題定位提供了值得借鑒的思路。

0 概述

視頻炫鈴是VoLTE及5G網(wǎng)絡的一項特色業(yè)務,此功能將“聽彩鈴”演進成“看彩鈴”,用戶在VoLTE或5G網(wǎng)絡環(huán)境下?lián)艽蛘Z音或者視頻通話,呼叫接通前可以看到一段視頻內(nèi)容。開通視頻彩鈴的用戶可以上傳個性化視頻,通過視頻炫鈴的形式分享給主叫用戶,也可以在運營商的視頻庫中進行選擇。視頻炫鈴業(yè)務具備了個性化、實用性的特點,呼叫建立的過程中,被叫用戶可以使用更加生動、靈活的方式展現(xiàn)自己想要傳達的信息,從而為運營商吸引更多用戶,帶來更加豐富的商機。

1 視頻炫鈴業(yè)務的網(wǎng)絡架構(gòu)

視頻炫鈴平臺架構(gòu),主要包括以下節(jié)點:

(1)中音平臺:自身實現(xiàn)全國性的振鈴、整曲、MV、俱樂部、直播等音樂業(yè)務,并提供辦理全國性炫鈴業(yè)務、多媒體炫鈴業(yè)務的門戶通道[1];

(2)視頻炫鈴AS:完成炫鈴用戶炫鈴放音、控制能力、內(nèi)容/數(shù)據(jù)同步及與支撐系統(tǒng)的接口透傳和轉(zhuǎn)換;

(3)IMS S-CSCF:完成VoLTE用戶視頻炫鈴業(yè)務觸發(fā)及信令交互;

(4)HSS:完成視頻炫鈴用戶IFC簽約。

2 VoLTE視頻炫鈴觸發(fā)流程

VoLTE域內(nèi)用戶簽約視頻炫鈴業(yè)務,在核心網(wǎng)HSS設備上會有一條IFC簽約信息,被叫用戶歸屬的IMS域S-CSCF設備會根據(jù)用戶的iFC配置信息,觸發(fā)視頻炫鈴功能。當前中國聯(lián)通IMS域炫鈴信令流程遵循3GPP 24.182協(xié)議規(guī)范[1]。VoLTE域炫鈴信令流程如下:

(1)主叫發(fā)起呼叫請求INVITE到被叫IMS域SCSCF。

(2)S-CSCF檢查被叫歸屬HSS的IFC信息,發(fā)現(xiàn)用戶簽約50(基本通話)、310(視頻炫鈴)等功能,IFC觸發(fā)按優(yōu)先級排序為MMTEL AS→視頻炫鈴AS→SCC AS。其中MMTEL AS處理用戶的基本呼叫及補充業(yè)務,SCC AS為域選服務器,用以進行被叫域選及漫游碼獲取。

(3)S-CSCF將INVITE消息發(fā)送至MMTEL AS,MMTEL AS完成基本呼叫及補充業(yè)務處理后將INVITE消息回送至S-CSCF。

(4)S-CSCF將INVITE消息發(fā)送至視頻炫鈴AS,視頻炫鈴AS轉(zhuǎn)發(fā)該INVITE請求至S-CSCF。

(5)S-CSCF將INVITE消息發(fā)送至SCC AS,SCC AS完成被叫域選流程,S-CSCF發(fā)起被叫尋呼。

(6)被叫側(cè)開始振鈴,回復180振鈴消息。

(7)視頻炫鈴AS收到180消息后,向主叫播放視頻炫鈴。

(8)被叫回200摘機消息后,視頻炫鈴AS發(fā)起主被叫媒體重協(xié)商流程,終止播放視頻炫鈴。

(9)主被叫媒體重協(xié)商結(jié)束后,開始通話。

3 視頻彩鈴的資源預留與媒體協(xié)商

視頻炫鈴的播放需要足夠的帶寬資源,所以呼叫接續(xù)過程中在主被叫之間預先建立一個通道,預留足夠帶寬,可有效避免異常振鈴或掉線現(xiàn)象的發(fā)生。這個資源預留的過程就是Precondition流程。

如何判斷呼叫流程是否是Precondition流程:

(1)如果保證主被叫都開啟了Precondition,那就是Precondition流程。

(2)通過消息頭域判斷,如表1所示:

表1 Precondition流程參照表Tab.1 Precondition process reference table

-看主叫發(fā)的第一條INVITE消息里Supported頭域是否帶Precondition。如果帶了,說明主叫開啟了Precondition。

Supported:timer,tdialog,100rel,histinfo,join,norefersub,precondition,replaces

-看被叫回復的183消息里是否帶:Require:Precondition,100rel如果帶,說明被叫支持Precondition,主被叫都支持Precondition,說明是Precondition流程。

視頻彩鈴的Precondition呼叫流程如下:

主叫發(fā)出初始INVITE,被叫IMS域的彩鈴AS收到INVITE消息,彩鈴AS透傳主被叫消息到被叫,被叫回復183。

此時如果183響應攜帶了Reason頭域或call waiting指示,視頻炫鈴AS將透傳后向消息和后向音,收到180后不再進行彩鈴媒體協(xié)商。

主叫發(fā)出初始INVITE,被叫IMS域的彩鈴AS收到INVITE消息,彩鈴AS透傳主被叫消息,完成主被叫資源預留。

被叫返回180,到達被叫歸屬域彩鈴AS。

如果180響應攜帶了Reason頭域或call waiting指示,視頻炫鈴AS將透傳后向消息和后向音,不做彩鈴媒體協(xié)商。

彩鈴AS向主叫域update彩鈴的SDP,此時彩鈴AS需判斷:(1)主叫初始INVITE消息中的contact頭域是否包含video標簽或SDP攜帶視頻媒體行,如果攜帶,則發(fā)起視頻彩鈴媒體更新請求(后續(xù)協(xié)商成功后為主叫播放被叫用戶視頻鈴音庫中的鈴音);若未攜帶,則發(fā)起音頻彩鈴媒體更新請求(后續(xù)協(xié)商成功后為主叫播放被叫用戶音頻鈴音庫中的鈴音)。對于該判斷平臺需設置開關(guān)(視頻彩鈴協(xié)商判斷開關(guān)),開關(guān)默認開啟,當開關(guān)關(guān)閉時,無論主叫起呼時是否contact頭域攜帶video標簽或為視頻起呼,平臺均發(fā)起視頻彩鈴媒體更新請求。(2)若主被叫初始媒體協(xié)商為視頻通話(以第6步媒體協(xié)商結(jié)果為準),則video媒體行下需要攜帶a=sendrecv,audio媒體行下需要攜帶a=sendrecv;若主被叫初始媒體協(xié)商為音頻通話(以第6步媒體協(xié)商結(jié)果為準),則video媒體行下需要攜帶a=sendonly,audio媒體行下需要攜帶a=sendrecv。媒體更新消息需攜帶support:Precondition、conf要求,及Precondition協(xié)商所需相關(guān)參數(shù),不可攜帶require:Precondition。

主叫終端根據(jù)自身能力及狀態(tài)回復200update,若主叫不支持Precondition,將忽略視頻炫鈴ASupdate消息中的Precondition參數(shù),視頻炫鈴AS應支持對該種應答的正確處理。

如果第10步中主叫終端視頻資源未預留成功,待其完成資源預留后發(fā)送第11步資源確認消息,彩鈴AS進行應答。若主叫終端能夠在第10步中返回已確認資源的彩鈴媒體(協(xié)商為視頻彩鈴或音頻彩鈴),則無11和12步驟。彩鈴AS側(cè)需設置定時器,當定時器超時還未收到終端的資源確認消息時,視頻炫鈴AS放棄播放彩鈴,直接發(fā)送180消息,攜帶PEM:inactive,終端播放普通回鈴音。定時器缺省設置為3秒,可進行配置。

彩鈴AS根據(jù)主叫應答的媒體能力播放音頻或視頻彩鈴(若主叫在第10步或第11步的消息中視頻媒體行屬性為sendrecv,則彩鈴AS播放視頻彩鈴;若主叫在第10步或第11步的消息中視頻媒體行屬性為inactive或被置0,則彩鈴AS播放音頻彩鈴),并轉(zhuǎn)發(fā)180消息,攜帶PEM:sendrecv。

被叫UE摘機回復200 OK,彩鈴AS停止彩鈴播放,并回復ACK。

彩鈴AS向被叫UE發(fā)送re-INVITE請求,不攜帶SDP信息。

被叫UE對re-INVITE消息進行應答,終端回復與主叫初始協(xié)商時相同的媒體能力或直接回復全媒體能力。另注:此處終端也可能使用200 OK進行應答,也可能使用183進行應答,視頻炫鈴AS應根據(jù)SIP協(xié)議,進行相應的處理。本流程圖以200 OK應答為例進行說明。

視頻炫鈴AS將被叫對re-INVITE消息應答的媒體能力作為SDP offer向主叫進行媒體更新。此處,視頻炫鈴AS應將被叫SDP的媒體行類型與主叫側(cè)當前通話類型進行匹配處理,再發(fā)給主叫側(cè)。即,若被叫返回的SDP媒體行若同時包含音頻和視頻,而此時主叫側(cè)通話類型為音頻,則視頻炫鈴AS需要將被叫SDP中的視頻媒體行置0后,再將被叫SDP發(fā)送給主叫。若被叫SDP包含的媒體行類型與主叫在初始媒體協(xié)商過程中與被叫最終協(xié)商好的媒體能力匹配,則無需任何修改,直接向主叫透傳請求媒體更新。

主叫對媒體更新進行應答,返回200 OK。

視頻炫鈴AS向主叫轉(zhuǎn)發(fā)被叫摘機200 OK。

26-27:視頻炫鈴AS向被叫返回re-INVITE ACK,攜帶主叫對第22步媒體更新消息應答的SDP信息。

4 視頻炫鈴業(yè)務典型問題分析

不支持視頻炫鈴終端視頻起呼CS域視頻炫鈴號碼流程分析:近期視頻炫鈴平臺功能驗證過程中,我們發(fā)現(xiàn)不支持視頻炫鈴終端向CS域開通視頻炫鈴號碼發(fā)起視頻呼叫時,播放視頻炫鈴的音頻,此現(xiàn)象與預期播放音頻炫鈴不符。我們將分析重點放在振鈴前的媒體協(xié)商過程。

(1)由于發(fā)起的是視頻呼叫,視頻炫鈴AS接收到主叫側(cè)INVITE消息contact及SDP消息體攜帶Video信息,端口號為27044,媒體類型包括120,118,123:視頻炫鈴AS將INVITE消息透傳至CSCF,由于被叫登錄在CS域,完成被叫域選后發(fā)送至MGCF。

(2)視頻炫鈴AS接收到通過CSCF轉(zhuǎn)發(fā)的被叫側(cè)回復的183消息,在SDP消息體中發(fā)現(xiàn)異常情況:183消息的SDP消息體包含Video媒體名稱,端口號變?yōu)?,媒體類型為118,123,然而并沒有關(guān)于Video媒體的屬性描述內(nèi)容。

(3)視頻炫鈴AS收到主叫發(fā)起的UPDATE消息,其中contact頭域包含video字段,SDP消息體中包含video媒體名稱,端口號為0,媒體類型為120,118,123,無Video媒體屬性描述內(nèi)容[2]。

(4)視頻炫鈴AS接收到被叫側(cè)200(UPDATE),SDP消息體中包含video媒體名稱,端口號為0,媒體類型為120,118,123,無Video媒體屬性描述內(nèi)容。

(5)視頻炫鈴AS接收到180消息后,發(fā)送給主叫UPDATE消息,其中Video媒體編碼類型為123,125,124,122,107[2]。

(6)視頻炫鈴AS接收到主叫回的200(UPDATE),標識其資源預留成功,Video媒體編碼為123。

(7)媒體協(xié)商成功后,視頻炫鈴平臺下發(fā)180消息,為主叫播放視頻炫鈴。由此可見,問題出在主叫側(cè)終端對于視頻炫鈴AS平臺發(fā)起的UPDATE消息,在本身不支持播放視頻炫鈴的情況下,依舊回復承載建立成功的200OK所致。正常情況下,不支持視頻炫鈴的終端,接收到UPDATE消息后應返回491錯誤碼,以表示承載建立不成功。接收到報錯后,視頻炫鈴平臺會發(fā)起音頻炫鈴放音。

5 結(jié)語

伴隨VoLTE網(wǎng)絡的推廣及5G網(wǎng)絡的逐步應用,我們的通信網(wǎng)絡可為用戶提供越來越豐富的應用,而靈活豐富的應用勢必帶來各功能之間的交互配合。如何能夠快速、穩(wěn)妥的完成新業(yè)務調(diào)測及業(yè)務交互,是對平臺維護人員的艱巨考驗。各級維護人員應做好日常知識儲備及經(jīng)驗積累,為營造匠心網(wǎng)絡提供有力保障。

引用

[1] 中國聯(lián)通個性化回鈴音業(yè)務技術(shù)規(guī)范V4.1(1113)[Z].2019.

[2] 中國聯(lián)通音樂平臺接口規(guī)范V3.0 20190605[Z].2019.