视频炫铃业务流程与典型问题

2021-11-19中国联通山东省分公司北部大区运营中心马翔徐延辉王昊

数字技术与应用 2021年10期

中国联通山东省分公司北部大区运营中心马翔徐延辉王昊

本文简要介绍了视频炫铃平台的业务特点、组网架构以及业务流程,分析了视频炫铃业务信令交互过程中需关注的重点消息及消息内的重点字段。通过对案例处理过程的分析,为后续业务投诉处理及问题定位提供了值得借鉴的思路。

0 概述

视频炫铃是VoLTE及5G网络的一项特色业务,此功能将“听彩铃”演进成“看彩铃”,用户在VoLTE或5G网络环境下拨打语音或者视频通话,呼叫接通前可以看到一段视频内容。开通视频彩铃的用户可以上传个性化视频,通过视频炫铃的形式分享给主叫用户,也可以在运营商的视频库中进行选择。视频炫铃业务具备了个性化、实用性的特点,呼叫建立的过程中,被叫用户可以使用更加生动、灵活的方式展现自己想要传达的信息,从而为运营商吸引更多用户,带来更加丰富的商机。

1 视频炫铃业务的网络架构

视频炫铃平台架构,主要包括以下节点:

(1)中音平台:自身实现全国性的振铃、整曲、MV、俱乐部、直播等音乐业务,并提供办理全国性炫铃业务、多媒体炫铃业务的门户通道[1];

(2)视频炫铃AS:完成炫铃用户炫铃放音、控制能力、内容/数据同步及与支撑系统的接口透传和转换;

(3)IMS S-CSCF:完成VoLTE用户视频炫铃业务触发及信令交互;

(4)HSS:完成视频炫铃用户IFC签约。

2 VoLTE视频炫铃触发流程

VoLTE域内用户签约视频炫铃业务,在核心网HSS设备上会有一条IFC签约信息,被叫用户归属的IMS域S-CSCF设备会根据用户的iFC配置信息,触发视频炫铃功能。当前中国联通IMS域炫铃信令流程遵循3GPP 24.182协议规范[1]。VoLTE域炫铃信令流程如下:

(1)主叫发起呼叫请求INVITE到被叫IMS域SCSCF。

(2)S-CSCF检查被叫归属HSS的IFC信息,发现用户签约50(基本通话)、310(视频炫铃)等功能,IFC触发按优先级排序为MMTEL AS→视频炫铃AS→SCC AS。其中MMTEL AS处理用户的基本呼叫及补充业务,SCC AS为域选服务器,用以进行被叫域选及漫游码获取。

(3)S-CSCF将INVITE消息发送至MMTEL AS,MMTEL AS完成基本呼叫及补充业务处理后将INVITE消息回送至S-CSCF。

(4)S-CSCF将INVITE消息发送至视频炫铃AS,视频炫铃AS转发该INVITE请求至S-CSCF。

(5)S-CSCF将INVITE消息发送至SCC AS,SCC AS完成被叫域选流程,S-CSCF发起被叫寻呼。

(6)被叫侧开始振铃,回复180振铃消息。

(7)视频炫铃AS收到180消息后,向主叫播放视频炫铃。

(8)被叫回200摘机消息后,视频炫铃AS发起主被叫媒体重协商流程,终止播放视频炫铃。

(9)主被叫媒体重协商结束后,开始通话。

3 视频彩铃的资源预留与媒体协商

视频炫铃的播放需要足够的带宽资源,所以呼叫接续过程中在主被叫之间预先建立一个通道,预留足够带宽,可有效避免异常振铃或掉线现象的发生。这个资源预留的过程就是Precondition流程。

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

(1)如果保证主被叫都开启了Precondition,那就是Precondition流程。

(2)通过消息头域判断,如表1所示:

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

-看主叫发的第一条INVITE消息里Supported头域是否带Precondition。如果带了,说明主叫开启了Precondition。

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

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

视频彩铃的Precondition呼叫流程如下:

主叫发出初始INVITE,被叫IMS域的彩铃AS收到INVITE消息,彩铃AS透传主被叫消息到被叫,被叫回复183。

此时如果183响应携带了Reason头域或call waiting指示,视频炫铃AS将透传后向消息和后向音,收到180后不再进行彩铃媒体协商。

主叫发出初始INVITE,被叫IMS域的彩铃AS收到INVITE消息,彩铃AS透传主被叫消息,完成主被叫资源预留。

被叫返回180,到达被叫归属域彩铃AS。

如果180响应携带了Reason头域或call waiting指示,视频炫铃AS将透传后向消息和后向音,不做彩铃媒体协商。

彩铃AS向主叫域update彩铃的SDP,此时彩铃AS需判断:(1)主叫初始INVITE消息中的contact头域是否包含video标签或SDP携带视频媒体行,如果携带,则发起视频彩铃媒体更新请求(后续协商成功后为主叫播放被叫用户视频铃音库中的铃音);若未携带,则发起音频彩铃媒体更新请求(后续协商成功后为主叫播放被叫用户音频铃音库中的铃音)。对于该判断平台需设置开关(视频彩铃协商判断开关),开关默认开启,当开关关闭时,无论主叫起呼时是否contact头域携带video标签或为视频起呼,平台均发起视频彩铃媒体更新请求。(2)若主被叫初始媒体协商为视频通话(以第6步媒体协商结果为准),则video媒体行下需要携带a=sendrecv,audio媒体行下需要携带a=sendrecv;若主被叫初始媒体协商为音频通话(以第6步媒体协商结果为准),则video媒体行下需要携带a=sendonly,audio媒体行下需要携带a=sendrecv。媒体更新消息需携带support:Precondition、conf要求,及Precondition协商所需相关参数,不可携带require:Precondition。

主叫终端根据自身能力及状态回复200update,若主叫不支持Precondition,将忽略视频炫铃ASupdate消息中的Precondition参数,视频炫铃AS应支持对该种应答的正确处理。

如果第10步中主叫终端视频资源未预留成功,待其完成资源预留后发送第11步资源确认消息,彩铃AS进行应答。若主叫终端能够在第10步中返回已确认资源的彩铃媒体(协商为视频彩铃或音频彩铃),则无11和12步骤。彩铃AS侧需设置定时器,当定时器超时还未收到终端的资源确认消息时,视频炫铃AS放弃播放彩铃,直接发送180消息,携带PEM:inactive,终端播放普通回铃音。定时器缺省设置为3秒,可进行配置。

彩铃AS根据主叫应答的媒体能力播放音频或视频彩铃(若主叫在第10步或第11步的消息中视频媒体行属性为sendrecv,则彩铃AS播放视频彩铃;若主叫在第10步或第11步的消息中视频媒体行属性为inactive或被置0,则彩铃AS播放音频彩铃),并转发180消息,携带PEM:sendrecv。

被叫UE摘机回复200 OK,彩铃AS停止彩铃播放,并回复ACK。

彩铃AS向被叫UE发送re-INVITE请求,不携带SDP信息。

被叫UE对re-INVITE消息进行应答,终端回复与主叫初始协商时相同的媒体能力或直接回复全媒体能力。另注:此处终端也可能使用200 OK进行应答,也可能使用183进行应答,视频炫铃AS应根据SIP协议,进行相应的处理。本流程图以200 OK应答为例进行说明。

视频炫铃AS将被叫对re-INVITE消息应答的媒体能力作为SDP offer向主叫进行媒体更新。此处,视频炫铃AS应将被叫SDP的媒体行类型与主叫侧当前通话类型进行匹配处理,再发给主叫侧。即,若被叫返回的SDP媒体行若同时包含音频和视频,而此时主叫侧通话类型为音频,则视频炫铃AS需要将被叫SDP中的视频媒体行置0后,再将被叫SDP发送给主叫。若被叫SDP包含的媒体行类型与主叫在初始媒体协商过程中与被叫最终协商好的媒体能力匹配,则无需任何修改,直接向主叫透传请求媒体更新。

主叫对媒体更新进行应答,返回200 OK。

视频炫铃AS向主叫转发被叫摘机200 OK。

26-27:视频炫铃AS向被叫返回re-INVITE ACK,携带主叫对第22步媒体更新消息应答的SDP信息。

4 视频炫铃业务典型问题分析

不支持视频炫铃终端视频起呼CS域视频炫铃号码流程分析:近期视频炫铃平台功能验证过程中,我们发现不支持视频炫铃终端向CS域开通视频炫铃号码发起视频呼叫时,播放视频炫铃的音频,此现象与预期播放音频炫铃不符。我们将分析重点放在振铃前的媒体协商过程。

(1)由于发起的是视频呼叫,视频炫铃AS接收到主叫侧INVITE消息contact及SDP消息体携带Video信息,端口号为27044,媒体类型包括120,118,123:视频炫铃AS将INVITE消息透传至CSCF,由于被叫登录在CS域,完成被叫域选后发送至MGCF。

(2)视频炫铃AS接收到通过CSCF转发的被叫侧回复的183消息,在SDP消息体中发现异常情况:183消息的SDP消息体包含Video媒体名称,端口号变为0,媒体类型为118,123,然而并没有关于Video媒体的属性描述内容。

(3)视频炫铃AS收到主叫发起的UPDATE消息,其中contact头域包含video字段,SDP消息体中包含video媒体名称,端口号为0,媒体类型为120,118,123,无Video媒体属性描述内容[2]。

(4)视频炫铃AS接收到被叫侧200(UPDATE),SDP消息体中包含video媒体名称,端口号为0,媒体类型为120,118,123,无Video媒体属性描述内容。

(5)视频炫铃AS接收到180消息后,发送给主叫UPDATE消息,其中Video媒体编码类型为123,125,124,122,107[2]。

(6)视频炫铃AS接收到主叫回的200(UPDATE),标识其资源预留成功,Video媒体编码为123。

(7)媒体协商成功后,视频炫铃平台下发180消息,为主叫播放视频炫铃。由此可见,问题出在主叫侧终端对于视频炫铃AS平台发起的UPDATE消息,在本身不支持播放视频炫铃的情况下,依旧回复承载建立成功的200OK所致。正常情况下,不支持视频炫铃的终端,接收到UPDATE消息后应返回491错误码,以表示承载建立不成功。接收到报错后,视频炫铃平台会发起音频炫铃放音。