2826人阅读
网络相关（68）
From: 如果一个SIP消息中没有Contact或者Record-Route头域，那么callee就会根据From头域产生后续的Request。比如：如果Alice打一个电话给Bob，From头域的内容是&From:Alice&sip:alice@example.org&。那么Bob打给Alice时就会使用
sip:alice@example.org作为To头域和Request-URI头域的内容。&
Contact: 后续Request将根据Contact头域的内容决定目的地的地址，同时将Contact头域的内容放到Request-URI中。它还可以用来指示没有在Record-Route头域中记录的Proxies的地址。同时它还可以被用在Redirect servers和REGISTER requests 和responses。&
Record-Route:Record-Route字段实际上用于帮助UA建立Route Set，当UA发送Request时会用Route Set来设置上面提到的Route字段。当一个Request消息经过Proxy Server时，如果该Proxy Server希望通知UA相关的后续消息都能通过它来转发，此时它就会在消息中添加Record-Route字段，内容为自己的地址信息。当UAS发送Resposne消息时它将复制Request中的Record-Route字段，而UAC在Response消息中检测到Record-Route字段时，它就会用该字段的路由信息更新自己的Route
Via头域是被服务器插入request中，用来检查路由环的，并且可以使response根据via找到返回的路。它不会对未来的request 或者是response造成影响。&
总的来说，如果有Route，request就应该根据Route发送，如果没有就根据Contact头域发送，如果连Contact都没有，就根据From头域发送。
Service-Route:Service-Route在S-CSCF向UE发送REGISTER成功应答时设置，作用和Record-Route类似，用于帮助UE建立Route Set，这样UE注册后的消息（例如INVITE）通过设置Route字段无需经过I-CSCF可直接送达S-CSCF。
Path :只能用于用户向注册服务器发送的Register请求。
& && && & 1如果某代理服务器希望发往用户的任何后续请求仍能经过自己，就可以在Register请求中插入一个Path字段并赋值为自身的URI。
& && && & 2如果要求拓扑隐藏，经过I-CSCF的时候要把这个 I 添加到Path字段中&
To&字段总是包含被呼叫方的地址（通过sip代理时是公用地址，点对点时是真实ip），要注意的是区别该标题头和sip消息请求行中的Request-URI。To在信令路径中不会被代理改变，然而Request-URI包含的是信令路径中下一跳的地址，因此在路途中被每个代理改变。
总的来说，SIP中存在两种路由场景：
1，请求消息的路由
2，响应消息的路由
其中，响应消息的路由非常简单，就是完全依靠Via来完成的。
【说明】一个SIP消息每经过一个Proxy（包括主叫），都会被加上一个Via头域，当消息到达被叫后，Via头域就记录了请求消息经过的完整路径。被叫将这些Via头域原样copy到响应消息中（包括各Via的参数，以及各Via的顺序），然后下发给第一个Via中的URI，每个Proxy转发响应消息前都会把第一个Via（也就是它自己添加的Via）删除，然后将消息转发给新的第一个Via中的URI，直到消息到达主叫。
下面谈SIP请求消息的路由。
首先我们要搞清楚什么是严格路由和松散路由。
严格路由（Strict&Routing）：
可以理解为比较“死板”的理由机制，这种路由机制在SIP协议的前身RFC&2534中定义，其机制非常简单。
要求接收方接收到的消息的request-URI必须是自己的URI(即发送方的Request-URI always
contained URI of the next hop)，然后它会把第一个Route头域“弹”出来，并把其中的URI作为新的request-RUI，然后把该消息路由给该URI。
松散路由（Louse&Routing，lr）：
该路由机制较为灵活，也是SIP路由机制的灵魂所在，在RFC&3261中定义。
下面介绍一下一个松散路由的Proxy的路由决策过程：
1，Proxy首先会检查消息的request-URI是不是自己属于自己所负责的域。如果是，它就会通过定位服务将该地址“翻译”成具体的联系地址并以此替换掉原来的request-URI；否则，它不会动request-URI。
2，Proxy检查第一个Route头域中的URI是不是自己的，如果是，则移除之。
3、Loose Router首先会检查Request URI是否为自己：如果不是，则不作处理；如果是，则取出Route字段的最后一个地址作为Request URI地址，并从Route字段中删去最后一个地址。
4、Loose Router其次会检查下一跳是否为Strict Router：如果不是，则不作处理；如果是，则将Request URI添加为Route的最后一个字段，并用下一跳Strict Router的地址更新Request URI。
可以看到步骤3、4其实是Loose Router为了兼容Strict Router而做的额外工作。
前面都是准备工作，下面该进行真正的路由了。如果还有Route头域，则Proxy会把消息路由给该头域中的URI，否则就路由给request-URI。
对于前面的规则，可以简单总结为一句话：Route的优先级高于request-URI的。
好，了解了两种路由机制，我们再来了解一下Route和Record-Route。
如果说Via是为了给一个请求消息的响应消息留后路，那么Record-Route就是为了给该请求消息之后的请求消息留后路。
&&&&而在一个请求消息的传输过程中，Proxy也可能（纯粹自愿，如果它希望还能接收到本次会话的后续请求消息的话）会添加一个Record-Route头域，这样当消息到达被叫后里面就有会有0个或若干个Record-Route头域。被叫会将这些Record-Route头域并入路由集，并并入自己的路由集，随后被叫在发送请求消息时就会使用该路由集构造一系列Route头域，以便对消息进行路由。
&&&&然后，被叫会像上面对待Via头域一样，将Record-Route头域全部原样copy到响应消息中返回给主叫。
&&&&主叫收到响应消息后也会将这些Record-Route头域并入路由集，只是它会将其反序。该会话中的后续请求消息的Route头域就会通过路由集构造。
【注意】Record-Route头域不用来路由，而只是起到传递信息的作用。
Record-Route头域不是路由集的唯一来源，路由集还可以通过手工配置等方式得到。
只是描述还是比较抽象，下面就以RFC&3261中的两个实例来解释一下。
路由示例1：
场景： & & & & & & & &&&
两个UE间有两个Proxy，U1&-&&P1&-&&P2&-&&U2，并且两个Proxy都乐意添加Record-Route头域。
&　　　　　　　　　　　&　　　
【说明】由于我们在此只关心SIP路由机制，因此下面消息中跟路由机制无关的头域都省略了。
U1发出一个INVITE请求给P1（P1是U1的外拨代理服务器）：
&&&&&&INVITE&sip:&SIP/2.0
&&&&&&Contact:&sip:caller@
P1不负责域，消息中也没有Route头域，因此通过DNS查询得到负责该域的Proxy的地址并且把消息转发过去。这里P1在转发前就添加了一个Record-Route头域，里面有一个lr参数，说明P1是一个松散路由器，遵循RFC3261中的路由机制。
&&&&&&INVITE&sip:&SIP/2.0
&&&&&&Contact:&sip:caller@
&&&&&&Record-Route:&&sip:;lr&
P2负责域，因此它通过定位服务得到&对应的设备地址是callee@&，因此用新的URI重写request-URI。消息中没有Route头域，因此它就把该消息转发给request-URI中的URI，转发前它也增加了一个Record-Route头域，并且也有lr参数。
&&&&&&INVITE&sip:callee@&SIP/2.0
&&&&&&Contact:&sip:caller@
&&&&&&Record-Route:&&sip:;lr&
&&&&&&Record-Route:&&sip:;lr&
位于的被叫收到了该INVITE消息，并且返回一个200&OK响应。其中就包括了INVITE中的Record-Route头域。
&&&&&&SIP/2.0&200&OK
&&&&&&Contact:&sip:callee@
&&&&&&Record-Route:&&sip:;lr&
&&&&&&Record-Route:&&sip:;lr&
被叫此时也就有了自己的路由集：
&&&&&&(&sip:;lr&,&sip:;lr&)
并且它本次会话的远端目的地址设置为INVITE中Contact中的URI：，此后被叫在该会话中的请求消息就发到这个URI。同样，被叫在200&OK响应中也携带了自己的联系地址，主叫收到该响应消息后也会把本次会话的远端目的地址设置为：，此后主机在该会话中的请求消息就发到这个URI。
同样，主叫也有了自己的路由集，只是跟被叫的是反序的：
&&&&&&(&sip:;lr&,&sip:;lr&)
通话完毕后，我们架设主叫先挂机，则主叫发出BYE请求：
&&&&&&BYE&sip:callee@&SIP/2.0
&&&&&&Route:&&sip:;lr&,&sip:;lr&
可以看到，BYE的Route头域正是主机的路由集构造来的。
由于p1在第一个Route中，因此BYE首先发给P1。
P1收到该消息后，发现request-URI中的URI不属于自己负责的域，而消息有Route头域，并且第一个Route头域中的URI正是自己，因此删除之，并且把消息转发给新的第一个Route头域中的URI，也就是P2：
&&&&&&BYE&sip:callee@&SIP/2.0
&&&&&&Route:&&sip:;lr&
P2收到该消息后，发现request-URI中的URI不属于自己负责的域（P2负责的是，而不是），第一个Route头域中的URI正是自己，因此删除之，此时已经没有Route头域了，因此就转发给了request-URI中的URI。
被叫就会收到BYE消息：
&&&&&&BYE&sip:callee@&SIP/2.0
路由示例2：
如果说上面的示例主要关注的是路由流程，那么本示例关注的则是严格路由与松散路由的区别。
U1-&P1-&P2-&P3-&P4-&U2
其中，P3是严格路由的，其余Proxy都是松散路由的，并且4个Proxy都很乐意增加Record-Route头域。
我们直接给出了到达被叫的INVITE消息：
&&&&&&INVITE&sip:callee@&SIP/2.0
&&&&&&Contact:&sip:caller@
&&&&&&Record-Route:&&sip:;lr&
&&&&&&Record-Route:&&sip:&
&&&&&&Record-Route:&&sip:;lr&
&&&&&&Record-Route:&&sip:;lr&
这中间的其他消息我们就不过问了，直接看一下被叫最后发出的BYE消息大概是什么样子：
&&&&&&BYE&sip:caller@&SIP/2.0
&&&&&&Route:&&sip:;lr&
&&&&&&Route:&&sip:&
&&&&&&Route:&&sip:;lr&
&&&&&&Route:&&sip:;lr&
因为P4在第一个Route里，因此被叫将BYE消息发给了P4。
P4收到该消息后，发现自己不负责域，但是第一个Route头域中的URI正是自己，因此删除之。P4还发现新的第一个Route头域中的URI是一个严格路由器，因此它把request-URI中的URI添加到最后一个Route的位置，并且将第一个Route“弹出”并且覆盖原来的request-URI。然后将消息转发给当前的request-URI，也就是P3。
&&&&&&BYE&sip:&SIP/2.0
&&&&&&Route:&&sip:;lr&
&&&&&&Route:&&sip:;lr&
&&&&&&Route:&&sip:caller@&
P3收到该消息后，直接把消息作出如下变换并且发给P2：
&&&&&&BYE&sip:;lr&SIP/2.0
&&&&&&Route:&&sip:;lr&
&&&&&&Route:&&sip:caller@&
P2收到该消息后，发现消息中的request-URI是自己的，因此在进一步处理先首先对消息做如下变换：
&&&&&&BYE&sip:caller@&SIP/2.0
&&&&&&Route:&&sip:;lr&
然后，P2发现自己不负责域，第一个Route中的URI也不是自己的，因此将消息转发给该URI，也就是P1。
P1收到该消息后，发现自己不负责域，但是第一个Route头域中的URI正是自己，因此删除之。消息变成下面的样子：
&&&&&&BYE&sip:caller@&SIP/2.0
转自：/my_life/articles/2282364.html
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：543350次
积分：5428
积分：5428
排名：第4890名
转载：450篇
评论：21条
(1)(1)(2)(6)(10)(2)(2)(8)(6)(7)(1)(7)(15)(4)(1)(1)(2)(1)(23)(25)(41)(38)(24)(9)(11)(14)(34)(13)(8)(9)(15)(8)(2)(3)(7)(12)(8)(2)(15)(17)(21)(3)(12)您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
volte基本原理及信令流程.pdf 47页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：200 &&
volte基本原理及信令流程
你可能关注的文档：
··········
··········
1------------------------------VoLTE 基本原理及信令流程
2------------------------------目录
IMS网络架构
IMS网元功能
VoLTE无线关键技术
SIP协议消息
VoLTE信令流程
VoLTE典型案例
3------------------------------LTE网络架构
4------------------------------IMS网络架构
业务配置代
2G/3G电路域
VoLTE SBC Mw/I2
正在加载中，请稍后...中国移动融合通信测试用例SDK 0.0.1
中 国 移 动 通 信融合通信测试要求 （ SDK 分 册 ）Next-Generation Converged Communication Test Specification (for SDK)V0.0.1中国移动通信集团公司前言本文档对中国移动通信集团公司融合通信 SDK 测试涉及的相关内容进行规定， 是 SDK 验收 测试实施的依据。I目1 2 3 4录范围........................................................................................................................................... 1 引用标准................................................................................................................................... 1 术语与缩略语解释................................................................................................................... 1 测试环境和方法....................................................................................................................... 2 4.1 4.2 4.3 4.4 测试设备................................................................................................................... 2 测试方法................................................................................................................... 2 测试结构................................................................................................................... 2 测试阶段及测试配置 ............................................................................................... 35测试用例................................................................................................................................... 4 5.1 业务发放................................................................................................................... 4 5.1.1 5.1.2 5.1.3 5.1.4 5.2 自动业务发放 ................................................................................................... 4 异常流程 1：短信验证码下发失败 ................................................................ 7 异常流程 2：短信验证码输入错误 ................................................................ 7 异常流程 3：短信验证码超时 ...................................... 错误！未定义书签。注册注销................................................................................................................... 8 5.2.1 5.2.2 注册................................................................................................................... 8 注销................................................................................................................. 135.3网络接入................................................................................................................. 14 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 网络状态监控 ................................................................................................. 14 SIP 协议承载 .................................................................................................. 14 链路保活 ......................................................................................................... 15 DNS 解析 ........................................................................................................ 15 NAT 穿越 ........................................................................................................ 16 防火墙穿越 ..................................................................................................... 165.4安全接入................................................................................................................. 17 5.4.1 5.4.2 信令安全 ......................................................................................................... 17 消息类媒体安全 ............................................................................................. 19II5.4.3 5.5语音类媒体安全 ............................................................................................. 20VoWiFi .................................................................................................................... 21 5.5.1 5.5.2 5.5.3 5.5.4 5.5.5 RCS 域类呼叫 ................................................................................................ 21 RCS 域类多方呼叫 ........................................................................................ 31 VoWiFi 与 VoLTE 互通 .................................................................................. 41 VoWiFi 与 VoLTE 多方互通 .......................................................................... 42 VoWiFi 音视频媒体要求 .............................................................................. 435.6消息类业务............................................................................................................. 44 5.6.1 5.6.2 5.6.3 5.6.4 一对一消息 ..................................................................................................... 44 一对多群发消息 ............................................................................................. 57 群聊................................................................................................................. 61 消息管理 ......................................................................................................... 765.7VoLTE 和 RCS 业务交互 ....................................................................................... 78 5.7.1 5.7.2 VoLTE 和 IM 交互.......................................................................................... 78 VoLTE 和发送图片交互................................................................................. 785.8能力发现................................................................................................................. 79 5.8.1 进入聊天界面发起能力查询 ......................................................................... 795.9SIM 卡更换检测..................................................................................................... 79 5.9.1 SIM 卡更换............................................................................................................ 79 5.9.2 无 SIM 卡.............................................................................................................. 805.10 5.11 5.12 5.13 6个人 Profile ............................................................................................................. 80 公众账号................................................................................................................. 82 稳定性测试............................................................................................................. 86 SDK MTBF 测试 .................................................................................................... 90编制历史................................................................................................................................. 92III1范围本文档对融合通信 SDK 测试相关要求进行了规定。 主要依据 SDK 相关技术要求规定的 范围进行测试。 2 引用标准 本文档引用了下列标准所包含的条文。 1、 Rich Communication Suite 5.1 Advanced Communications Services and Client Specification v2.0 2、 3、 4、 5、 6、 7、 8、 3 Rich Communication Suite 5.1 Endorsement of OMA CPM 1.0 Conversation Functions Rich Communication Suite 5.1 Endorsement of OMA CPM 1.0 Message Storage GSMA IR.64 &IMS Service Centralization and Continuity Guidelines& GSMA PRD IR.74 - “Video Share Interoperability Specification” GSMA PRD IR.79 - “Image Share Interoperability Specification” 1.4 GSMA IR.92 IMS Profile for Voice and SMS GSMA IR.94 IMS Profile for Conversational Video Service 术语与缩略语解释 必选：本文档中规定的“必选”字段要求设备必须实现的功能。 可选：本文档中规定的“可选”字段是指对相关内容不做硬性规定。缩略语 AKA AS CS GBA HSS HTTP I-CSCF IM IMPI IMPU IMS IMSI MMS MSRP NAB OTP PSI英文 Authentication and Key Agreement Application Server Circuit Switched General Bootstrapping Architecture Home Subscriber Server Hypertext Transfer Protocol Interrogating-CSCF Instant Message IM Private Identity IM Public Identity IP Multimedia Core Network Subsystem International Mobile Subscriber Identifier Multi-media Message Service The Message Session Relay Protocol Network Address Book One-time Password Public Service Identity1中文 认证和密钥协商 应用服务器 电路交换 通用认证机制 归属用户服务器 超文本传输协议 查询-CSCF 即时消息 IP 多媒体私有标示 IP 多媒体公有标示 IP 多媒体网络子系统 国际移动用户标识 多媒体短消息 消息会话传递协议 网络地址簿 动态密码 公共业务标识RCS SDP SIP SMS UE XCAP XDM XML 4 4.1Rich Communication （Suite） Session Description Protocol Session Initiation Protocol Short Message Service User Equipment XML Configuration Access Protocol XML Document Management eXtensible Markup Language富通信 会话描述协议 会话发起协议 短消息服务 用户设备 XML 配置接入协议 XML 文件管理 扩展标记语言测试环境和方法 测试设备 结合融合通信业务推进策略，本次参测的SDK需提供测试用APP（使用SDK开发），应使用支持中国移动2/3G/4G及WiFi方式接入，且以APP方式提供RCS服务。 本规范需要的测试工具为信令分析仪、协议分析工具Ethereal和自动化测试工具等。 4.2 测试方法 对SDK提供的业务能力进行测试，通过测试用例验证相应的功能，对无界面呈现的业务 功能采用监视性测试方法： 捕获接口上的所有信令消息数据， 以检验消息流程和参数是否正 确。 4.3 测试结构 测试组网图如图 4-1 所示。2RCS网络 业务管 理模块 公众账号 新联系模 模块 块 新通话模块 新消息模 块CS网络SMSC会话控制功能1/ 接入控制功能CS核心网2\3\4G无线WiFi2/3G无线UE图 4-1：RCS 业务测试组网图说明： 上图中表示的是逻辑实体，可以据自身实现选择物理设备合设或分设。 4.4 测试阶段及测试配置 主要验证 SDK 的业务功能和接口，参测 SDK 与采购的融合通信平台对接调测。35 5.1测试用例 业务发放 自动业务发放 基于PS接入的自动开户5.1.1 5.1.1.1测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 业务发放 基于 PS 接入的自动开户 验证基于 PS 接入场景下，用户能自动开户。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧完成自动开户相关配置。 3、UE A 具备 PS 接入能力。 4、UE A 没有在 RCS 网络开户。 1、UE A 首次启动 APP 2、UE A 完成开户。 1、UE A成功开户并登录网络。 2、APP启动时读取mnc,mcc信息组装业务管理平台的URL并发起http get请求， URL为http://config.rcs.mnc&MNC&.mcc&MCC&.pub.3gppnetwork.org。 3、业务管理平台通过BOSS向HSS、RCS AS和TAS等各个网元开户并返回开户 响应给APP。 无测试步骤 检查点参考流程5.1.1.2基于PS接入的自动开户―用户已开户测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 业务发放 基于 PS 接入的自动开户―用户已开户 验证基于 PS 接入场景下，用户已开户的场景下不再重复开户。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧完成自动开户相关配置。 3、UE A 具备 PS 接入能力。 4、UE A 已经通过 PS 在 RCS 网络开户。 5、UE A 注销。4测试步骤 检查点 参考流程1、UE A 启动 APP。 2、观察消息跟踪。 1、UE A登录网络成功。 2、 业务管理平台判断用户已开户， 不发起到BOSS的开户请求， 直接下发配置。 无5.1.1.3基于PS接入的自动开户失败测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 业务发放 基于 PS 接入的自动开户失败 验证基于 PS 接入场景下，用户自动开户失败。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧完成自动开户相关配置。 3、UE A 具备 PS 接入能力。 4、UE A 没有在 RCS 网络开户。 5、业务管理平台到 BOSS 间的网络连接中断。 1、UE A 首次启动 APP。 1、UE A提示开户失败。 2、业务管理平台给UE A返回HTTP 500错误。 无测试步骤 检查点 参考流程5.1.1.4基于WiFi接入的自动配置测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 业务发放 基于 WiFi 接入的自动配置 验证基于 WiFi 接入场景下，用户能自动配置。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧完成自动开户相关配置。 3、UE A 已经通过 PS 在 RCS 网络开户。 1、UE A 切换到 WiFi 网络后启动 APP。 2、UE A 输入 CS 网络下发的短信 OTP。测试步骤5检查点1、UE A成功登录网络。 2、UE A在启动时发现是WiFi接入则发起HTTPS消息给业务管理平台，HTTPS 消息中未携带Token信息。 3、业务管理平台检测到Token为空，则通过CS短信发送OTP给UE A用户。 4、UE A收到OTP之后输入OTP，并发起HTTPS请求给业务管理平台，其中携 带Cookie和OTP信息。 无参考流程5.1.1.5基于WiFi接入的自动配置（TOKEN未过期）测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 业务发放 基于 WiFi 接入的自动配置（TOKEN 未过期） 验证 TOKEN 未过期场景下，用户能基于 WiFi 接入 RCS 网络。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧完成自动开户相关配置。 3、UE A 已经通过 PS 在 RCS 网络开户。 4、UE A 获取的 TOKEN 在有效期内。 1、UE A 通过 WiFi 登录。 2、观察消息跟踪 1、UEA 不需要输入验证信息即可登陆成功。 2、UE A发起的https get请求中携带token，业务管理平台判断token有效直接返 回200，APP完成注册流程。 无测试步骤 检查点参考流程5.1.1.6基于WiFi接入的自动配置（TOKEN已过期场景）测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 业务发放 基于 WiFi 接入的自动配置（TOKEN 已过期场景） 验证 TOKEN 已过期场景下，用户能基于 WiFi 接入 RCS 网络。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧完成自动开户相关配置。 3、UE A 已经通过 PS 在 RCS 网络开户。 4、UE A 获取的 TOKEN 已过期。6测试步骤检查点1、UE A 通过 WiFi 登录。 2、UE A 输入 CS 网络下发的短信 OTP。 3、观察消息跟踪 1、UE A成功登录网络。 2、UE A登录时判断TOKEN已失效，发起的HTTPS消息中携带的TOKEN为空， ver为业务管理平台所下发的值。 3、业务管理平台检测到Token为空，通过CS短信发送OTP给UE A。 4、UE A收到OTP之后输入OTP，并发起HTTPS请求给业务管理平台，其中携 带Cookie和OTP信息。 无参考流程5.1.2异常流程 1：短信验证码下发失败测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 业务发放 短信验证码下发失败 验证 APP 未收到短信验证码，无法基于 WiFi 接入 RCS 网络。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧完成自动开户相关配置。 3、UE A 已经通过 PS 在 RCS 网络开户。 4、UE A 获取的 TOKEN 已过期。 1、UE A 通过 WiFi 登录。 2、UE A 未收到 CS 网络下发的短信 OTP。 1、UE A成功登录网络。 2、UE A登录时判断TOKEN已失效，发起的HTTPS消息中携带的TOKEN为空， ver为业务管理平台所下发的值。 3、业务管理平台检测到Token为空，通过CS短信发送OTP给UE A。 4、UE A未收到网络下发的短信OTP。 5、未发起HTTPS请求给业务管理平台。 无测试步骤 检查点参考流程5.1.3异常流程 2：短信验证码输入错误测试编号 测试项目 业务发放7测试子项 目 测试目的 测试依据 预置条件短信验证码输入错误 短信验证码输入错误的情况下，无法基于 WiFi 接入 RCS 网络。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧完成自动开户相关配置。 3、UE A 已经通过 PS 在 RCS 网络开户。 4、UE A 获取的 TOKEN 已过期。 1、UE A 通过 WiFi 登录。 2、UE A 输入 CS 网络下发的短信 OTP。 3、观察消息跟踪 1、UE A成功登录网络。 2、UE A登录时判断TOKEN已失效，发起的HTTPS消息中携带的TOKEN为空， ver为业务管理平台所下发的值。 3、业务管理平台检测到Token为空，通过CS短信发送OTP给UE A。 4、UE A收到OTP之后多次输入错误的OTP，自动配置失败。 无测试步骤检查点参考流程5.2 5.2.1注册注销 注册 注册5.2.1.1测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 注册 验证注册业务正常。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧配置 APP 接入的传输协议类型为 TCP。 3、RCS 用户已经在系统中完成开户。 1、UE A 发起注册。 验收标准： 1、UE A发起注册成功。 2、信令流程符合要求。 3、检查REGISTER消息中，expire头域不为0（注册间隔时间） 4、检查200 OK消息中，expire头域不为0。 无测试步骤 检查点参考流程85.2.1.2SIP Digest鉴权测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 SIP Digest 鉴权 验证 IMS Core 支持采用 SIP Digest 鉴权对用户鉴权。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧配置 APP 接入的传输协议类型为 TCP。 3、RCS 用户 UE A 已经在系统中完成开户，且 UE A 开户的鉴权方式为 SIP Digest 鉴权。 1、UE A 发起注册成功。 2、观察消息跟踪。 验收标准： 1、UE A登录正常，UE A采用SIP Digest鉴权方式。 无测试步骤 检查点 参考流程5.2.1.3密码错误（Digest）测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 密码错误（Digest） 验证用户输入错误密码时 SIP Digest 鉴权失败。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧配置 APP 接入的传输协议类型为 TCP。 3、RCS 用户 UE A 已经在系统中完成开户，且 UE A 开户的鉴权方式为 SIP Digest 鉴权。 1、UE A 输入错误的密码，并发起注册。 2、观察消息跟踪。 验收标准： 1、UE A登录失败，提示“用户名或者密码错误” 。 2、 检查消息跟踪， UE A采用SIP Digest鉴权方式， 网络侧判断密码错误返回403。 无测试步骤 检查点参考流程95.2.1.4AKA鉴权测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 AKA 鉴权 验证 IMS Core 支持采用 AKA 鉴权对用户鉴权。 中国移动融合通信系列规范 1、SDK 可以获取 AKA 鉴权所需的 USIM 卡相关信息。 2、网络中各网元系统及操作维护台运行正常。 3、网络侧配置 APP 接入的传输协议类型为 TCP。 4、RCS 用户 UE A 已经在系统中完成开户，且 UE A 开户的鉴权方式为 AKA 鉴权。 1、UE A 发起注册成功。 2、观察消息跟踪。 验收标准： 1、UE A登录正常，UE A采用AKA鉴权方式。 无测试步骤 检查点 参考流程5.2.1.5卡失效(AKA)测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 卡失效(AKA) 验证卡失效的情况下登陆失败。 中国移动融合通信系列规范 1、SDK 可以获取 AKA 鉴权所需的 USIM 卡相关信息。 2、网络侧配置 APP 接入的传输协议类型为 TCP。 3、RCS 用户 UE A 已经在系统中完成开户。 4、UE A 所登记的 SIM/USIM 失效。 1、UE A 发起注册。 2、观察消息跟踪。 验收标准： 1、UE A注册失败。 2、 检查消息跟踪， HSS给I-CSCF返回UAA （携带原因值： USER UNKNOWN） ； I-CSCF给UE_A返回的403 Forbidden指示“Invalid User”。测试步骤 检查点参考流程无105.2.1.6GBA鉴权测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 非 SIP 业务 GBA 鉴权 非 SIP 业务 GBA 鉴权 验证 IMS Core 支持采用 GBA 鉴权对用户鉴权。 1、SDK 可以获取 GBA 鉴权所需的 USIM 卡相关信息。 2、网络侧配置 APP 接入的传输协议类型为 TCP。 3、RCS 用户 UE A 已经在系统中完成开户。 1、UE A 发起非 SIP 业务。 2、观察消息跟踪。 1、 UE A 业务操作成功。 2、 UE A 采用 GBA 鉴权方式。 无测试步骤 检查点 参考流程5.2.1.7周期性注册测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 周期性注册 验证 IMS Core 支持周期性注册。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧配置 APP 接入的传输协议类型为 TCP。 3、RCS 用户 UE A 已经在系统中完成开户。 4、在网络侧配置注册的有效时长为 30 分钟。 1、UE A 发起注册成功。 3、UE A 在注册完成后等待超过 30 分钟。 验收标准： 1、UE发起业务注册成功。 2、信令流程符合要求。 3、 检查消息跟踪， 在UE A完成注册后30分钟之内发起重注册， 检查REGISTER 消息中， contact 头域包含 ‘+g.oma.*’ 内容， expire头域不为0 （注册间隔时间） 。 4、检查200 OK消息中，expire头域不为0。 无测试步骤 检查点参考流程115.2.1.8网络切换测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 网络切换 验证在注册后，发生网络切换，SDK 触发自动重注册。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、RCS 用户 UE A 和 UE B 已经在系统中完成开户。 3、RCS 用户 UE A 和 UE B 已经连接 RCS 网络。 1、UE A 发起注册成功。 2、UE A 注册成功后，发生网络切换（WiFi 间切换或者 3G-WiFi 切换） 。 3、切换完成后，UE A 发送 1-1 消息给 UE B。 验收标准： 1、信令流程符合要求。 2、网络切换后，APP能够自动发起到网络侧的注册。 3、网络切换后，UE A给UE B发送消息成功。 无测试步骤检查点参考流程5.2.1.9断网重连测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 断网重连 验证在注册后，发生断网重连，SDK 触发自动重注册。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、RCS 用户 UE A 和 UE B 已经在系统中完成开户。 3、RCS 用户 UE A 和 UE B 已经连接 RCS 网络。 1、UE A 发起注册成功。 2、UE A 注册成功后，发生断网重连（例如：网络断网 30 秒后恢复） 。 3、网络恢复后，UE A 发送 1-1 消息给 UE B。 验收标准： 1、信令流程符合要求。 2、网络断开后，SDK能够检测到网络断连并通知UE A。 3、网络恢复后，UE A给UE B发送消息成功。 无测试步骤检查点参考流程125.2.2 5.2.2.1注销 注销测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 注销 验证注销业务正常。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧配置 APP 接入的传输协议类型为 TCP。 3、手机已经连接 RCS 网络。 4、RCS 用户已经在系统中注册并且没有超时。 1、用户退出 RCS 注册 验收标准： 1、UE发起注销成功。 2、信令流程符合要求。 3、检查REGISTER消息中，expires头域为0。 无测试步骤 检查点参考流程 5.2.2.2异常流程1：网络侧注销测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 注册注销 网络侧注销 验证注销业务正常。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧配置 APP 接入的传输协议类型为 TCP。 3、手机已经连接 RCS 网络。 4、RCS 用户已经在系统中注册并且没有超时。 1、UE A 注册到网络。 2、网络侧将 UE A 去注册。 3、检查消息跟踪，查看 UE A 在线状态。 验收标准： 1、信令流程符合要求。 2、查看UE A的在线状态为离线。 无13测试步骤 1、 2、 3、 检查点参考流程5.3 5.3.1网络接入 网络状态监控测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 网络接入 网络状态监控 验证网络状态监控。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、UE A 和 UE B，通过 WIFI 接入。 3、RCS 用户 UE A 和 UE B 注册成功。 1、UE A 发起注册成功。 2、UE A 注册成功后，发生网络切换（WiFi 间切换或者 3G-WiFi 切换） 。 3、UE B 查看 UE A 状态； 验收标准： 1、UE A注册正常， 。 2、检查REGISTER消息中，expire头域不为0（注册间隔时间） 3、检查200 OK消息中，expire头域不为0。 4、UE B查看UE A状态为在线。测试步骤检查点参考流程5.3.2SIP 协议承载测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 网络接入 SIP 协议承载 验证 RCS 用户在网络接入场景下，SIP 协议承载方式。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、UE A 和 UE B，通过 WIFI 接入。 3、网络侧配置 APP 接入的传输协议类型为 TCP。 4、RCS 用户 UE A 和 UE B 注册成功。 1、网络侧配置 APP 接入的传输协议为 TCP。 2、UE A 注册成功。 3、UE A 发送消息 UE B。测试步骤14检查点验收标准： 1、传输协议更改成功。 2、UE A注册正常。 3、UE A 和SBC之间的SIP消息均基于TCP传输。 4、UE B 收到UE A发送的会话消息，内容与发送内容一致。 无参考流程5.3.3链路保活测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 网络接入 链路保活 验证链路保活。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、UE A 和 UE B，通过 WIFI 接入。 3、网络侧配置 APP 接入的传输协议类型为 TCP。 4、RCS 用户 UE A 和 UE B 注册成功。 1、UE A 注册成功。 2、UE B 查看 UE A 状态。 3、UE A 发送会话。 4、UE B 查看 UE A 发送的消息。 5、等待一个 Keep-Alive 周期时间。 6、UE A 发送消息给 UE B。 验收标准： 1、UE A发送成功， 。 2、UE B收到UE A发送的消息，内容与发送一致。 3、等待一个Keep-Alive周期时间。 4、UE B收到UE A发送的会话消息，内容与发送一致。测试步骤 4、 5、 6、 7、 8、 9、 检查点参考流程5.3.4DNS 解析测试编号 测试项目 测试子项 目 测试目的 测试依据 网络接入 DNS 解析 验证 DNS 解析。 中国移动融合通信系列规范15预置条件测试步骤检查点1、网络中各网元系统及操作维护台运行正常。 2、UE A 和 UE B，通过 WIFI 接入。 3、RCS 用户 UE A 和 UE B 注册成功。 1、UE A 注册成功后，修改 DNS 对应的 IP 地址。 2、UE A 重新注册； 3、UE A 发送会话消息给 UE B； 验收标准： 1、UE A注册正常。 2、检查REGISTER消息中，expire头域不为0（注册间隔时间） 3、检查200 OK消息中，expire头域不为0。 4、UE B成功收到会话消息，内容与发送的消息一致。参考流程5.3.5NAT 穿越测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 网络接入 NAT 穿越 验证 RCS 用户在 NAT 设备接入场景下，SIP 信令和媒体支持穿越。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、UE A 和 UE B 在 NAT 设备下，通过 WIFI 接入。 3、RCS 用户 UE A 和 UE B 注册成功。 4、系统支持 Keep-Alive 机制。 1、UE A 发起注册。 2、等待一个 Keep-Alive 周期时间。 2、UE A 向 UE B 发起 1 对 1 聊天，双方相互发送一个消息。 验收标准： 1、UE A注册正常。 2、Keep-Alive正常。 3、UE A发起的1对1聊天成功。 无测试步骤检查点参考流程 5.3.6防火墙穿越测试编号 测试项目 测试子项 目 测试目的 测试依据 可靠接入 防火墙穿越 验证 SDK 具备 STG 防火墙穿越能力。 中国移动融合通信系列规范16预置条件 测试步骤 检查点1、网络中各网元系统及操作维护台运行正常。 2、 UE A 和 UE B 到 STG Server 之间的存在防火墙， 防火墙仅开放 80/443 端口。 1、UE A 和 UE B 发起注册。 2、UE A 给 UE B 发送图片。 验收标准： 1、UE A 和 UE B 注册成功。 2、UE B收到对方发送的图片，接收的内容和发送的一致。 4、观察消息跟踪，UE A和UE B都通过STG的方式接入网络。 无参考流程5.3.6.1 测试编号 测试项目根据优先级选择SBC网络接入 动态 SBC 选择 验证 RCS 用户注册时，当高优先级 SBC 故障时，选择低优先级 SBC 注册。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、业务管理平台上配置 IP 地址段和对应的 SBC 列表关系。 3、列表中的高优先级的 SBC 设备运行异常。 4、RCS 用户 UE A 和 UE B 注册成功。 1、UE A 发起注册。 2、UE A 向 UE B 发送图片。 验收标准： 1、业务管理平台返回匹配的SBC列表。 2、UE A选择SBC列表中的第一个SBC地址发起注册失败。 3、UE A选择SBC列表中的第二个SBC地址发起注册成功。 4、UE A发送图片成功。 无测试子项 目 测试目的 测试依据 预置条件测试步骤 检查点参考流程5.4 5.4.1安全接入 信令安全 采用HTTPS和业务管理平台进行业务交互5.4.1.1 测试编号 测试项目安全接入 信令安全17测试子项 目测试目的 测试依据 预置条件测试步骤 检查点参考流程验证 APP 支持 HTTPS 和业务管理平台交互。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、UE A 新开户，未发起注册。 3、配置业务管理平台支持 HTTPS。 1、UE A 发起注册。 验收标准： 1、UE A 注册成功。 2、UE A 和业务管理平台之间的业务消息，均基于 HTTPS 加密进行传输。 无5.4.1.2 测试编号 测试项目APP基于SIP over TLS注册安全接入 APP 基于 SIP over TLS 注册 验证 RCS 支持 SIP 信令使用 TLS 安全传输。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、配置 UE A 支持 SIP over TLS, 配置 SBC 支持 TLS。 3、用户 UE A 已经在系统中完成开户，且开户的鉴权方式为 SIP Digest 鉴权。 1、UE A 发起注册。 2、观察消息跟踪。 验收标准： 1、UE A 注册成功，注册采用 SIP Digest 方式鉴权。 2、UE A 和 SBC 之间的注册消息，均基于 TLS 进行加密传输，UE A 采用 SIP Digest 鉴权方式。 无测试子项 目 测试目的 测试依据 预置条件测试步骤 检查点参考流程5.4.1.3基于TLS的AKA鉴权测试编号 测试项目 测试子项 目 测试目的 测试依据 安全接入 基于 TLS 的 AKA 鉴权 验证 IMS Core 支持基于 TLS 的 AKA 鉴权。 中国移动融合通信系列规范18预置条件测试步骤 检查点1、SDK 可以获取鉴权所需的 SIM 卡信息。 2、网络侧配置 APP 接入的传输协议类型为 TLS。 3、用户 UE A 已经在系统中完成开户，且开户的鉴权方式为 AKA 鉴权。 1、UE A 发起注册。 2、观察消息跟踪。 验收标准： 1、UE A登录正常，采用AKA方式鉴权。 2、UE A 和SBC之间的SIP消息均基于TLS进行加密传输。 无参考流程5.4.2 5.4.2.1消息类媒体安全 文件传输基于MSRP over TLS测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 安全接入 文件传输基于 MSRP over TLS 验证文件传输业务使用 MSRP over TLS。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、配置 UE A 使用 MSRP over TLS, 配置 SBC 使用 MSRP over TLS。 3、UE A 和 UE B 均注册成功。 1、UE A 发送图片给 UE B。 2、UE B 点击下载并查看。 验收标准： 1、UE A 发送图片成功，UE B 查看图片成功。 2、查看消息，UE A/ B 和 SBC 间的 MSRP 消息均通过 MSRP over TLS 进行加 密传输。 无测试步骤 检查点参考流程5.4.2.2 测试编号IM基于MSRP over TLS测试项目 测试子项 目 测试目的 测试依据安全接入 IM 基于 MSRP over TLS 验证 IM 业务能够使用 MSRP over TLS。 中国移动融合通信系列规范19预置条件测试步骤 检查点参考流程1、网络中各网元系统及操作维护台运行正常。 2、UE A 均配置支持 MSRP over TLS, SBC 配置支持 MSRP over TLS。 3、配置消息发送为 Pager/Large 模式。 4、UE A 和 UE B 均注册成功。 1、UE A 发送超大消息(建议超过 1300 字节)给 UE B。 验收标准： 1、UE A 发送成功，UE B 接收查看成功。 2、查看消息，UE A/ B 和 SBC 间的 MSRP 消息均通过 MSRP over TLS 进行加 密传输 无5.4.3 5.4.3.1语音类媒体安全 基于SRTP的语音呼叫测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 安全接入 基于 SRTP 的语音呼叫 验证语音媒体通过 SRTP 加密传输。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、UE A 配置支持 SRTP, SBC 配置支持 SRTP。 3、UE A 和 UE B 均注册成功。 1、UE A 发起到 UE B 的语音呼叫。 2、UE B 接听成功。 验收标准： 1、呼叫接听成功，语音清晰。 2、查看消息，UE A 和 UE B 的媒体包均通过 SRTP 进行加密传输。 无测试步骤 检查点参考流程5.4.3.2 测试编号基于SRTP的视频呼叫测试项目 测试子项 目 测试目的 测试依据安全接入 基于 SRTP 的视频呼叫 验证语音媒体通过 SRTP 加密传输。 中国移动融合通信系列规范20预置条件测试步骤 检查点参考流程 5.5 5.5.1 5.5.1.11、网络中各网元系统及操作维护台运行正常。 2、UE A 均配置支持 SRTP, SBC 配置支持 SRTP。 3、UE A 和 UE B 均注册成功。 1、UE A 发起到 UE B 的视频呼叫。 2、UE B 接听成功。 验收标准： 1、呼叫接听成功，视频清晰。 2、查看消息，UE A 和 UE B 的媒体包均通过 SRTP 进行加密传输。 无VoWiFi RCS 域类呼叫 语音业务5.5.1.1.1 VoWiFi 基本语音呼叫 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 新通话业务功能 一对一语音 VoWiFi 验证基于 WiFi 的语音呼叫能够成功。 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 为 UE A 和 UE B 成功开通融合通信。 3、 配置 UE A 和 UE B 支持基于 WiFi 的语音呼叫。 4、 UE A 和 UE B 均已成功接入 WiFi 网络。 5、 UE A 和 UE B 均注册成功。 1、 UE A 发起到 UE B 的 VoWiFi 语音呼叫。 2、 UE B 接听成功。 3、 通话持续 3 分钟以上。 4、 UE B 挂断通话。 5、 UE B 发起到 UE A 的 VoWiFi 语音呼叫。 6、 UE A 接听成功。 7、 通话持续 3 分钟以上。 8、 UE B 挂断通话。 验收标准： 1、 两次通话均建立成功。 2、 两次通话各持续 3 分钟以上，双方能正常通话：通话过程中语音连续、无 掉线。 3、 两次通话均能正常挂断。测试步骤检查点参考流程215.5.1.1.2 正常语音通话回铃音 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 新通话业务功能 正常语音通话回铃音 正常语音通话回铃音 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、为 UE A 和 UE B 成功开通融合通信。 3、配置 UE A 和 UE B 支持基于 WiFi 的语音呼叫。 4、UE A，UE B 成功接入 WiFi 网络。并注册成功。 5、UE A，UE B 没有签约回铃音相关业务 1、UE A 发起到 UE B 的 VoWiFi 语音呼叫。 2、UE B 振铃，UE A 听回铃音，UE B 摘机后通话接续 3、通话持续 3 分钟以上。 4、UE B 挂断通话。 验收标准： 1、通话建立成功。 2、UE A 在收到 UE B 的 180 响应后，终播放回铃音 3、通话能正常挂断。测试步骤检查点参考流程5.5.1.1.3 失败语音通话回铃音测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件5.1.1.7.3 新通话业务功能 失败语音通话回铃音 失败语音通话回铃音 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、为 UE A 和 UE B 成功开通融合通信。 3、配置 UE A 和 UE B 支持基于 WiFi 的语音呼叫。 4、UE A，UE B 成功接入 WiFi 网络。并注册成功。 5、UE A，UE B 没有签约回铃音相关业务 1、UE A 发起到 UE B 的 VoWiFi 语音呼叫。UE B 拒接。 2、UE A 听忙音或相应的语音通知。 3、UE A 挂断通话。测试步骤22检查点验收标准： 1、呼叫不能接续，UE A 听忙音或语音通知 2、语音通知由新通话平台播放参考流程5.5.1.1.4 拒绝 VoWiFi 音频来电 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 拒绝 VoWiFi 音频来电 验证基于 WiFi 的语音呼叫能够成功拒绝。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、配置 UE A 和 UE B 支持基于 WiFi 的语音呼叫。 3、UE A 和 UE B 均注册成功。 1、UE A 发起到 UE B 的语音呼叫。 2、UE B 拒绝 UE A 的语音来电； 验收标准： 1、 UE B 拒绝成功，语音呼叫结束； 无测试步骤 检查点 参考流程5.5.1.1.5 结束 VoWiFi 音频来电 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 结束 WiFi 音频来电 验证基于 WiFi 的语音呼叫能够成功结束。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、配置 UE A 和 UE B 支持基于 WiFi 的语音呼叫。 3、UE A 和 UE B 均注册成功。 1、 UE A 发起到 UE B 的语音呼叫。 2、 UE B 接听语音呼叫； 3、 UE B 结束语音通话；测试步骤23检查点 1、参考流程验收标准： 1、UE B 收到 UE A 的语音来电呼叫； 2、UE B 接听成功，保持通话； 3、UE B 结束音频来电，语音通话结束； 无5.5.1.1.6 VoWiFi 音频来电屏显 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi VoWiFi 音频来电屏显 验证基于 WiFi 的语音呼叫能够成功获取屏显。 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 UE A 和 UE B 均开通主叫号码显示业务 3、配置 UE A 和 UE B 支持基于 WiFi 的语音呼叫。 4、UE A 和 UE B 均注册成功。 1、 UE A 发起到 UE B 的语音呼叫。 2、 UE A 通讯录中存在 UE B； 验收标准： 1、UE B 收到 UE A 的语音来电呼叫； 2、屏显为用户 UE B 为 UE A 设置的通讯录名称； 无测试步骤 检查点 3、 4、 参考流程5.5.1.1.7 异常流程：被叫方号码为空号 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 被叫号码不存在 验证被叫号码为空时，网络处理正确。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、RCS 域和 CS 域互通配置完成，CS 域异常放音配置完成。 3、配置 UE A 支持基于 WiFi 的语音呼叫。 4、UE A 注册成功。 5、UE B 号码为空号码。 1、UE A 发起到 UE B 的语音呼叫。测试步骤24检查点参考流程验收标准： 1、呼叫失败。 2、UE A 听异常放音，提示被叫号码不存在。 无5.5.1.1.8 异常流程：被叫方号码状态异常（如停机保号） 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 被叫号码停机 验证被叫号码为停机时，网络处理正确。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、RCS 域和 CS 域互通配置完成，CS 域异常放音配置完成。 3、配置 UE A 支持基于 WiFi 的语音呼叫。 4、UE A 注册成功。 5、UE B 号码为停机号码。 1、UE A 发起到 UE B 的语音呼叫。 验收标准： 1、呼叫失败。 2、UE A 接听异常，提示被叫号码已停机。 无测试步骤 检查点参考流程5.5.1.1.9 异常流程：VoWiFi 通话中，其中一方异常（网络切换） 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi VoWiFi 通话中，其中一方异常 验证 VoWiFi 通话中，其中一方异常时，网络处理正确。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、RCS 域和 CS 域互通配置完成，CS 域异常放音配置完成。 3、配置 UE A、B 支持基于 WiFi 的语音呼叫。 4、UE A、B 注册成功。 1、 UE A 发起到 UE B 的语音、视频呼叫。 2、 UE B 接听语音、视频呼叫。 3、 UE B 网络切换测试步骤25检查点参考流程验收标准： 1、UE B 出现网络切换，平台侧将 UE A 的呼叫挂断。 2、UE B 正常挂断呼叫。 无5.5.1.2视频业务5.5.1.2.1 VoWiFi 基本视频 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 测试步骤 VoWiFi 视频呼叫 一对一视频 VoWiFi 验证基于 WiFi 的视频呼叫能够成功。 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 为 UE A 和 UE B 成功开通融合通信。 3、 配置 UE A 和 UE B 支持基于 WiFi 的视频呼叫。 4、 UE A 和 UE B 均已成功接入 WiFi 网络。 5、 UE A 和 UE B 均注册成功。 1、 UE A 发起到 UE B 的 VoWiFi 视频呼叫。 2、 UE B 接听成功。 3、 视频通话持续 3 分钟以上。 4、 UE B 挂断通话。 5、 UE B 发起到 UE A 的 VoWiFi 视频呼叫。 6、 UE A 接听成功。 7、 视频通话持续 3 分钟以上。 8、 UE B 挂断通话。 无检查点参考流程5.5.1.2.2 正常视频通话回铃音 测试编号 测试项目 测试子项 目 测试目的 测试依据 新通话业务功能 正常视频通话回铃音 正常视频通话回铃音 中国移动融合通信系列规范26预置条件测试步骤检查点1、网络中各网元系统及操作维护台运行正常。 2、为 UE A 和 UE B 成功开通融合通信。 3、配置 UE A 和 UE B 支持基于 WiFi 的语音和视频呼叫。 4、UE A，UE B 成功接入 WiFi 网络。并注册成功。 5、UE A，UE B 没有签约回铃音相关业务 1、UE A 发起到 UE B 的 VoWiFi 视频呼叫。 2、UE B 振铃，UE A 听回铃音，UE B 摘机后通话接续 3、通话持续 3 分钟以上。 4、UE B 挂断通话。 验收标准： 1、通话建立成功。 2、UE A 在收到 UE B 的 180 响应后，APP 自己播放回铃音 3、通话能正常挂断。参考流程 5.5.1.2.1 接听 VoWiFi 视频来电 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 接听 VoWiFi 视频来电 验证基于 WiFi 的视频呼叫能够成功接听。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、配置 UE A 和 UE B 支持基于 WiFi 的视频呼叫。 3、UE A 和 UE B 均注册成功。 1、UE A 发起到 UE B 的视频呼叫。 验收标准： 1、UE B 收到 UE A 的视频来电呼叫； 无测试步骤 检查点 参考流程5.5.1.2.2 失败语音通话回铃音 测试编号 测试项目 测试子项 目 测试目的 测试依据 新通话业务功能 失败语音通话回铃音 失败语音通话回铃音 中国移动融合通信系列规范27预置条件测试步骤检查点1、网络中各网元系统及操作维护台运行正常。 2、为 UE A 和 UE B 成功开通融合通信。 3、配置 UE A 和 UE B 支持基于 WiFi 的语音呼叫。 4、UE A，UE B 成功接入 WiFi 网络。并注册成功。 5、UE A，UE B 没有签约回铃音相关业务 1、UE A 发起到 UE B 的 VoWiFi 语音呼叫。UE B 拒接。 2、UE A 听忙音或相应的语音通知 3、UE A 挂断通话。 验收标准： 1、呼叫不能接续，UE A 听忙音或语音通知 2、语音通知由新通话平台播放参考流程5.5.1.2.3 拒绝 VoWiFi 视频来电 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 拒绝 VoWiFi 视频来电 验证基于 WiFi 的视频呼叫能够成功拒绝。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、配置 UE A 和 UE B 支持基于 WiFi 的视频呼叫。 3、UE A 和 UE B 均注册成功。 1、 UE A 发起到 UE B 的视频呼叫。 2、UE B 拒绝 UE A 的视频呼叫； 验收标准： 2、 UE B 拒绝成功，视频呼叫结束； 无测试步骤 检查点 参考流程5.5.1.2.4 结束 VoWiFi 视频来电 测试编号 测试项目 测试子项 目 测试目的 测试依据 VoWiFi 结束 WiFi 视频来电 验证基于 WiFi 的视频呼叫能够成功结束。28预置条件测试步骤检查点 2、参考流程1、网络中各网元系统及操作维护台运行正常。 2、配置 UE A 和 UE B 支持基于 WiFi 的视频呼叫。 3、UE A 和 UE B 均注册成功。 4、 UE A 发起到 UE B 的视频呼叫。 5、 UE B 接听视频呼叫； 6、 UE B 结束视频通话； 验收标准： 1、UE B 收到 UE A 的视频来电呼叫； 2、UE B 接听成功，保持通话； 3、UE B 结束视频来电，视频通话结束； 无5.5.1.2.5 VoWiFi 视频来电屏显 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi VoWiFi 视频来电屏显 验证基于 WiFi 的视频呼叫能够成功获取屏显。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、配置 UE A 和 UE B 支持基于 WiFi 的视频呼叫。 3、UE A 和 UE B 均注册成功。 1、 UE A 发起到 UE B 的视频呼叫。 验收标准： 1、UE B 收到 UE A 的视频来电呼叫； 2、屏显为用户 UE B 为 UE A 设置的通讯录名称； 无测试步骤 检查点 2、 3、 参考流程5.5.1.2.6 使用音频方式接听 VoWiFi 视频通话 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 使用音频方式接听 VoWiFi 视频通话 验证基于 WiFi 的视频呼叫能够成功接听。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、配置 UE A 和 UE B 支持基于 WiFi 的视频呼叫。 3、UE A 和 UE B 均注册成功。29测试步骤 检查点 2、 参考流程1、 UE A 发起视频呼叫。 2、 UE B 接听以语音方式接听； 验收标准： 1、UE B 成功使用音频方式接听视频通话，语音通话清晰。 无5.5.1.2.7 异常流程：被叫方号码为空号 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 被叫号码不存在 验证被叫号码为空时，网络处理正确。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、CS 域异常放音配置正确。 3、配置 UE A 支持基于 WiFi 的视频呼叫。 4、UE A 注册成功。 5、UE B 号码为空号码。 1、UE A 发起到 UE B 的视频呼叫。 验收标准： 1、视频呼叫失败。 2、UE A 听异常放音，提示被叫号码不存在。 无测试步骤 检查点参考流程5.5.1.2.8 异常流程：被叫方号码状态异常（如停机保号） 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 被叫号码停机 验证被叫号码为停机时，网络处理正确。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、RCS 域和 CS 域互通配置完成，CS 域异常放音配置完成。 3、配置 UE A 支持基于 WiFi 的视频呼叫。 4、UE A 注册成功。 5、UE B 号码为停机号码。 1、UE A 发起到 UE B 的视频呼叫。测试步骤30检查点参考流程验收标准： 1、呼叫失败。 2、UE A 接听异常，提示被叫号码已停机。 无5.5.2 5.5.2.1RCS 域类多方呼叫 VoWiFi多方语音通话建立测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi VoWiFi 多方语音通话建立 支持 VoWiFi 多方语音业务能力 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 支持 VoLTE 业务能力； 3、UE A，UE B，UE C 注册成功。 1、 UE A 选择通讯录联系人 UE B，UE C； 2、 UE A 发起多人语音会话； 3、 UE B，UE C 收到多方通话邀请并接受 4、 UE B，UE C 查看多方语音通话已建立； 验收标准： 1、成功发起多人语音会话。 2、多人语音通话建立成功，语音清晰。 无测试步骤检查点参考流程5.5.2.2 测试编号 测试项目多方通话加人VoWiFi 多方通话加人 支持 VoWiFi 多方语音业务能力 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 支持 VoLTE 业务能力； 3、UE A，UE B，UE C，UE D 注册成功。测试子项 目 测试目的 测试依据 预置条件31测试步骤检查点参考流程1、 UE A 选择通讯录联系人 UE B，UE C； 2、 UE A 发起多人语音会话； 3、 UE B，UE C 查看多方语音通话已建立； 4、 UE A 选择 UE D 加入多方语音通话，UED 收到并接受邀请； 验收标准： 1、成功发起多人语音会话。 2、多人语音通话建立成功，语音清晰； 3、UE D 成功收到 UE A 的邀请； 4、UE D 成功加入多方语音通话，语音清晰； 无5.5.2.3多方通话结束测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件VoWiFi 多方通话结束 支持 VoWiFi 多方语音业务能力 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 支持 VoLTE 业务能力； 3、UE A，UE B，UE C 注册成功。 1、 UE A 选择通讯录联系人 UE B，UE C； 2、 UE A 发起多人语音会话； 3、 UE A 结束通话。 验收标准： 1、成功发起多人语音会话。 2、多人语音通话建立成功，语音清晰； 3、UE A 结束多方语音通话，多方通话成功结束； 无测试步骤检查点参考流程5.5.2.4 测试编号 测试项目多方通话来电显示VoWiFi 多方通话来电显示 支持 VoWiFi 多方语音业务能力 中国移动融合通信系列规范32测试子项 目 测试目的 测试依据预置条件测试步骤检查点参考流程1、 网络中各网元系统及操作维护台运行正常。 2、 支持 VoWiFi 业务能力； 3、UE A，UE B，UE C，UE D 注册成功。 1、 UE A 选择通讯录联系人 UE B，UE C； 2、 UE A 发起多人语音会话； 3、 接收方查看发起方姓名和头像及多方通话标示 4、 UE B，UE C 查看多方语音通话已建立； 验收标准： 1、 成功发起多人语音会话。 2、 UE B，UE C，UE D 查看 UE A 的姓名和头像为通讯录中保存的信息； 3、多人语音通话建立成功，语音清晰； 无5.5.2.5 测试编号 测试项目通话过程中各方状态显示VoWiFi 通过过程中各方状态显示 支持 VoWiFi 多方语音业务能力 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 支持 VoLTE 业务能力； 3、UE A，UE B，UE C 注册成功。 1、 UE A 选择通讯录联系人 UE B，UE C； 2、 UE A 发起多人语音会话； 3、 UE B 接听多方来电，UE C 未接听多方来电 验收标准： 1、 成功发起多人语音会话。 2、UE A 查看接听方状态 UE B 已接听，UE C 未接听； 3、UE B 查看接听方状态 UE A 已接听，UE C 未接听；测试子项 目 测试目的 测试依据 预置条件测试步骤检查点参考流程4、UE C 无法查看接听方状态； 无5.5.2.6 测试编号 测试项目多方通话中某个参与方接听，通话中发起方即时获取其接续状态新通话业务功能33测试子项 目 测试目的 测试依据 预置条件发起方即时获取参与方的接续状态 验证参与方接听时发起方能即时获取参与方的接续状态 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常 1. 为 UE A、UE B 和 UE C 成功开通融合通信。 2. 配置 UE A、UE B 和 UE C 支持基于 WiFi 的语音呼叫。 3. UE A、UE B 和 UE C 均已成功接入 WiFi 网络。 4. UE A、UE B 和 UE C 均注册成功。 5. UE A 已开通多方通话权限。 1. 用户 A 在 APP 选择 B，C 用户，选择多方通话按键。 2. 用户 A 发起会议订阅 Subscribe 3. 用户 B 接听。 4. AS 发送 Notify 给用户 A，通知用户 B 已经进入会议。 5. 用户 C 接听。 6. AS 发送 Notify 给用户 A，通知用户 C 已经进入会议 7. 通话持续 3 分钟以上。 8、用户 A 挂机，用户 A、B 和 C 释放呼叫。 验收标准： 1. 三方通话建立成功。 2. 成员加入时，AS 能够发送 Notify 通知主席 3、通话持续 3 分钟以上，会议能正常通话：通话过程中语音连续、无掉线， 多方通话各方可以相互交流，音频清晰无杂音。 4、用户 A 挂机后，会议释放，BC 能正常挂断。测试步骤检查点参考流程5.5.2.7 测试编号 测试项目多方通话中某个参与方挂断，通话中发起方即时获取其接续状态新通话业务功能 发起方即时获取参与方的接续状态 验证参与方挂断时发起方能即时获取参与方的接续状态 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常 2. 为 UE A、UE B 和 UE C 成功开通融合通信。 3. 配置 UE A、UE B 和 UE C 支持基于 WiFi 的语音呼叫。 4. UE A、UE B 和 UE C 均已成功接入 WiFi 网络。 5. UE A、UE B 和 UE C 均注册成功。 6. UE A 已开通多方通话权限。测试子项 目 测试目的 测试依据 预置条件34测试步骤1. 2. 3. 4. 5. 6. 7. 8.用户 A 在 APP 选择 B，C 用户，选择多方通话按键。 用户 A 发起会议订阅 Subscribe 用户 A、B 和 C 进入会议。 用户 B 挂断。 AS 发送 Notify 给用户 A，通知用户 B 已经退出会议。 用户 C 挂断。 AS 发送 Notify 给用户 A，通知用户 C 已经退出会议 会议释放。检查点验收标准： 1. 三方通话建立成功。 2. 成员退出时，AS 能够发送 Notify 通知主席 3、通话持续 3 分钟以上，会议能正常通话：通话过程中语音连续、无掉线， 多方通话各方可以相互交流，音频清晰无杂音。 4、成员都退出后，会议释放。参考流程5.5.2.8 测试编号 测试项目查看多方通话记录VoWiFi 查看多方通话记录 支持 VoWiFi 多方语音业务能力 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 支持 VoWiFi 业务能力； 3、UE A，UE B，UE C 注册成功。 1、 UE A 选择通讯录联系人 UE B，UE C； 2、 UE A 发起多人语音会话； 3、 UE B，UE C 接听多方语音通话； 4、 UE A 通话列表中存在与 UE B 和 UE C 的通话记录； 验收标准： 1、 成功发起多人语音会话。 2、 UE B，UE C 接听多方来电； 3、 UE A 查看多方通话记录，包括通话状态，参与方，发起时间和通话时长； 4、 UE B 查看多方通话记录，记录内容显示正确； 无测试子项 目 测试目的 测试依据 预置条件测试步骤检查点参考流程355.5.2.9 测试编号 测试项目保存所有多方通话参与方为群或联系人分组新通话业务功能 保存所有多方通话参与方为联系人或联系人分组 验证能够保存所有多方通话参与方为联系人或联系人分组 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常 2、 为 UE A、UE B 和 UE C 成功开通融合通信。 3、 配置 UE A、UE B 和 UE C 支持基于 WiFi 的语音呼叫。 4、 UE A、UE B 和 UE C 均已成功接入 WiFi 网络。 5、 UE A、UE B 和 UE C 均注册成功。 6、 UE A 已开通多方通话权限。 1、 用户 A 在 APP 选择 B，C 用户，选择会议按键。 2、 用户 A 发起会议订阅 Subscribe 3、 用户 B 接听。 4、 AS 发送 Notify 给用户 A，通知用户 B 已经进入会议。 5、 用户 C 接听。 6、 AS 发送 Notify 给用户 A，通知用户 C 已经进入会议 7、 通话持续 3 分钟以上。 4、 用户 A 挂机，用户 A、B 和 C 释放呼叫。 5、 A 将参与多方通话的 B、C 保存为联系人或分组 验收标准： 1、 三方通话建立成功。 2、B、C 可以被用户保存成联系人或者分组。测试子项 目 测试目的 测试依据 预置条件测试步骤检查点参考流程5.5.2.10 多方通话放音 5.5.2.10.1 正常多方通话回铃音 测试编号 测试项目 测试子项 目 测试目的 测试依据 新通话业务功能 正常多方通话回铃音 验证有正常多方通话回铃音。 中国移动融合通信系列规范36预置条件测试步骤1、网络中各网元系统及操作维护台运行正常 2、 为 UE A、UE B 和 UE C 成功开通融合通信。 3、 配置 UE A、UE B 和 UE C 支持基于 WiFi 的语音呼叫。 4、 UE A、UE B 和 UE C 均已成功接入 WiFi 网络。 5、 UE A、UE B 和 UE C 均注册成功。 6、 UE A 已开通多方通话权限。 1、 用户 A 在 APP 选择 B，C 用户，选择会议按键。 2、 用户 B 和 C 振铃。 3、 用户 A 进入会议，A 听回铃音，由平台播放。 4、 用户 B 摘机，B 进入会议。AB 通话。 5、 用户 C 摘机，C 进入会议。ABC 通话 6、通话持续 3 分钟以上。 7、用户 A 挂机，用户 A、B 和 C 释放呼叫。 验收标准： 1、 三方通话建立成功。 2、用户 A 建立会议后、有参与方接听前，A 听回铃音。 3、通话持续 3 分钟以上，三方能正常通话：通话过程中语音连续、无掉线， 多方通话各方可以相互交流，音频清晰无杂音。 4、用户 A 挂机后，会议释放，B、C 能正常挂断。检查点参考流程5.5.2.10.2 失败多方通话回铃音 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 新通话业务功能 失败多方通话回铃音 验证失败多方通话回铃音。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常 2、 为 UE A、UE B 和 UE C 成功开通融合通信。 3、 配置 UE A、UE B 和 UE C 支持基于 WiFi 的语音呼叫。 4、 UE A、UE B 和 UE C 均已成功接入 WiFi 网络。 5、 UE A 注册成功，UE B 和 UE C 都未注册。 6、 UE A 已开通多方通话权限。 1、 用户 A 在 APP 选择 B，C 用户，选择会议按键。 2、 用户 A 进入会议，A 听回铃音，由平台播放。 3、 用户 B 和 C 接续失败。 4、 用户 A 听呼叫失败提示音，由 APP 本地播放。 5、用户 A 挂机。测试步骤37检查点验收标准： 1、 多方通话建立失败。 2、用户 A 增加成员失败后听失败提示音。 3、用户 A 挂机后，会议释放。参考流程5.5.2.10.3 通话中参与方接续状态变化提示音 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 新通话业务功能 通话参与方接续状态变化提示音 验证参与方进入和退出会议时有提示音。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常 2、 为 UE A、UE B 和 UE C 成功开通融合通信。 3、 配置 UE A、UE B 和 UE C 支持基于 WiFi 的语音呼叫。 4、 UE A、UE B 和 UE C 均已成功接入 WiFi 网络。 5、 UE A、UE B 和 UE C 均注册成功。 6、 UE A 已开通多方通话权限。 1、 用户 A 在 APP 选择 B，C 用户，选择会议按键。 2、 用户 B 和 C 振铃。 3、 用户 B 摘机，B 进入会议。A 听到提示音。 4、 用户 C 摘机，C 进入会议。A 听到提示音 5、 通话持续 3 分钟以上。 6、 用户 B 挂机，B 退出会议。A 听到提示音。 7、用户 A 挂机，C 释放呼叫。 验收标准： 1、 多方通话建立成功。 2、成员进入或退出会议时，有提示音 3、通话持续 3 分钟以上，参与方能正常通话：通话过程中语音连续、无掉线， 多方通话各方可以相互交流，音频清晰无杂音。 参考流程测试步骤检查点5.5.2.11 异常流程：被叫方号码为空 测试编号 测试项目 RCS 域类多方呼叫38测试子项 目 测试目的 测试依据 预置条件被叫号码为空 验证被叫号码为空时，网络处理正确。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、CS 域异常放音配置正确。 3、配置 UE A 支持基于 WiFi 的音频呼叫。 4、UE A 注册成功。 5、UE B 号码为空号码。 1、UE A 发起到多人通话给 UE B。 验收标准： 1、视频呼叫失败。 2、UE A 听异常放音，提示被叫号码不存在。 无测试步骤 检查点参考流程5.5.2.12 异常流程：被叫方号码状态异常（如停机保号） 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 RCS 域类多方呼叫 被叫号码停机 验证被叫号码为停机时，网络处理正确。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、RCS 域和 CS 域互通配置完成，CS 域异常放音配置完成。 3、配置 UE A 支持基于 WiFi 的音频呼叫。 4、UE A 注册成功。 5、UE B 号码为停机号码。 1、UE A 发起到多人通话给 UE B 呼叫。 验收标准： 1、呼叫失败。 2、UE A 接听异常，提示被叫号码已停机。 无测试步骤 检查点参考流程5.5.2.13 异常流程：最后一个参与方挂机 测试编号 测试项目 测试子项 目 测试目的 RCS 域类多方呼叫 最后一个参与方挂机 支持 VoWiFi 多方语音业务能力39测试依据 预置条件测试步骤检查点参考流程中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 支持 VoLTE 业务能力； 3、UE A，UE B，UE C 注册成功。 1、 UE A 选择通讯录联系人 UE B，UE C； 2、 UE A 发起多人语音会话； 3、 UE B，UE C 查看多方语音通话已建立； 4、 UE B，UE C 相继挂断通话； 验收标准： 1、成功发起多人语音会话。 2、多人语音通话建立成功，语音清晰。 3、UE B，UE C 成功挂断通话。 4、UE A 结束多方语音通话，多方通话成功结束。 无5.5.2.14 异常流程：参与方网络中断 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 测试步骤 RCS 域类多方呼叫 参与方网络中断 支持 VoWiFi 多方语音业务能力 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、UE A，UE B，UE C 通过 WiFi 注册成功。 1、 UE A 选择通讯录联系人 UE B，UE C； 2、 UE A 发起多人语音会话； 3、 UE B，UE C 查看多方语音通话已建立； 4、 UE B 网络中断； 验收标准： 1、成功发起多人语音会话。 2、多人语音通话建立成功，语音清晰。 3、UE B 网络中断，UE B 退出多方通话。 4、UE A 与 UE C 多方通话正常。 无检查点参考流程5.5.2.15 异常流程：参与方人数达上限 测试编号 测试项目 VoWiFi40测试子项 目 测试目的 测试依据 预置条件参与方人数达上限 支持 VoWiFi 多方语音业务能力 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 支持 VoLTE 业务能力； 3、 UE A 注册成功。 1、 UE A 选择通讯录联系人； 2、 UE A 发起多人语音会话，参与方人数超过上限（6 人） ； 3、 UEA 的提示参与方超过上限。UE B，UE C 查看多方语音通话已建立； 验收标准： 1、提示多方通话发起方重新进行筛选发起呼叫。 2、多人语音通话建立失败； 无测试步骤检查点参考流程5.5.3 5.5.3.1VoWiFi 与 VoLTE 互通 语音业务5.5.3.1.1 VoWiFi 语音呼叫 VoLTE 用户 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 与 VoLTE 互通 VoWiFi 与 VoLTE 语音互通 验证基于 WiFi 的语音呼叫能够和 VoLTE 用户互通。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络中 VoWiFi 网络和 VoLTE 网络互通正常。 3、UE A 为 RCS 用户，支持 VoWiFi 业务。 4、UE B 为 VoLTE 用户。 5、UE A 在 RCS 注册成功，UE B 在 VoLTE 注册成功。 1、UE A 发起到 UE B 的 VoWiFi 语音呼叫。 2、UE B 用 LTE 终端接听。 3、通话结束，UE A 或者 UE B 释放呼叫。 验收标准： 1、UE A 发起呼叫后，听回铃音正常。UE B 的 VoLTE 终端振铃正常，并且号 码显示正确。 2、UE B 使用 VoLTE 接听后，语音清晰。 3、查看消息跟踪，消息流程正确 无测试步骤检查点参考流程415.5.3.2视频业务5.5.3.2.1 VoWiFi 视频呼叫 VoLTE 用户 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 与 VoLTE 互通 VoWiFi 与 VoLTE 视频互通 验证基于 WiFi 的视频呼叫能够和 VoLTE 用户互通。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络中 VoWiFi 网络和 VoLTE 网络互通正常。 3、UE A 为 RCS 用户，支持 VoWiFi 业务。 4、UE B 为 VoLTE 用户。 5、UE A 在 RCS 注册成功，UE B 在 VoLTE 注册成功。 1、UE A 发起到 UE B 的 VoWiFi 视频呼叫。 2、UE B 用 LTE 终端接听。 3、通话结束，UE A 或者 UE B 释放呼叫。 验收标准： 1、UE A 发起呼叫后，听回铃音正常。UE B 的 VoLTE 终端振铃正常，并且号 码显示正确。 2、UE B 使用 VoLTE 接听后，视频清晰。 无测试步骤检查点参考流程 5.5.4 5.5.4.1VoWiFi 与 VoLTE 多方互通 语音业务5.5.4.1.1 VoWiFi 语音呼叫 VoLTE 用户 测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 与 VoLTE 多互通 VoWiFi 与 VoLTE 语音互通 验证 VoWiFi 与 VoLTE 语音互通，融合通信用户通过 VoWiFi 发起多方通话，参 与方以 VoLTE 接听。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络中 VoWiFi 网络和 VoLTE 网络互通正常。 3、UE A 为 RCS 用户，支持 VoWiFi 业务。 4、UE B 为 VoLTE 用户。 5、UE C 为 RCS 用户，支持 VoWiFi 业务。 。 6、UE A、UE C 在 RCS 注册成功。UE B 在 VoLTE 均注册成功。42测试步骤检查点参考流程1、 UE A 选择通讯录联系人 UE B，UE C； 2、 UE A 发起多人语音会话； UE B，UE C 接听； 验收标准： 1、 UE A 发起呼叫后，听回铃音正常。 2、 UE B 的 VoLTE 终端振铃正常，并且号码显示正确。 3、UE B 使用 VoLTE 接听后，音频清晰。 无5.5.5 5.5.5.1VoWiFi 音视频媒体要求 VoWiFi音频通话编解码要求测试编号 测试项目 测试子项 目 测试目的 测试依据 预置条件 VoWiFi 音视频媒体要求 VoWiFi 音频通话编解码要求 验证 VoWiFi 音频编码通话能够符合编解码要求 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、UE A 为 RCS 用户，支持 VoWiFi 业务（编解码要求优先顺序从左到右 AMR-WB,G.729，G.711,Opus,Ilbc,AMR-NB） 。 3、UE B 为融合通信用户。 4、UE B 配置 RCS 用户被叫在线时，接听成功。 5、UE A 在 RCS 注册成功。UE B 在 RCS 和 VoLTE 均注册成功。 1、UE B 在 RCS 注册成功。 2、UE A 发起到 UE B 的音频。 3、UE B 用 VoWiFi 接听。 4、通话结束，UE A 或者 UE B 释放呼叫。 验收标准： 1、 UE A 发起呼叫后，听回铃音正常。 2、UE B 使用 VoWiFi 接听后，语音清晰。 3、查看消息跟踪，编解码正确。 无测试步骤检查点参考流程5.5.5.2 测试编号 测试项目VoWiFi视频通话编解码要求VoWiFi 音视频媒体要求43测试子项 目 测试目的 测试依据 预置条件VoWiFi 视频通话编解码要求 验证 VoWiFi 视频编码通话能够符合编解码要求 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、 UE A 为 RCS 用户， 支持 VoWiFi 业务 （编解码要求优先顺序从左到右 H.264， H.263，VP8） 。 3、UE B 为融合通信用户。 4、UE B 配置 RCS 用户被叫在线时，接听成功。 5、UE A 在 RCS 注册成功。UE B 在 RCS 和 VoLTE 均注册成功。 1、UE B 在 RCS 注册成功。 2、UE A 发起到 UE B 的音频。 3、UE B 用 VoWiFi 接听。 4、通话结束，UE A 或者 UE B 释放呼叫。 验收标准： 2、 UE A 发起呼叫后，听回铃音正常。 2、UE B 使用 VoWiFi 接听后，视频清晰。 3、查看消息跟踪，编解码正确。 无测试步骤检查点参考流程5.6 5.6.1消息类业务 一对一消息 一对一文本消息（&=900字节）5.6.1.1 测试编号 测试项目消息类业务 一对一文本消息（&=900 字节） 验证 1-1 发送文本业务功能。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、主被叫 RCS 用户注册成功。 1、UE A 向 UE B 发一个 IM&=900 字节的文本消息。UE B 收到消息并查看。 2、UE B 向 UE A 发一个 IM&=900 字节的文本消息。UE A 收到消息并查看。 验收标准： 1、 UE A和UE B都能收到对方发送的文本消息。 2、 接收的内容和发送的一致。 无测试子项 目 测试目的 测试依据 预置条件 测试步骤 检查点参考流程445.6.1.2 测试编号 测试项目一对一文本消息（&900字节）消息类业务 一对一文本消息（&900 字节） 验证 1-1 发送文本业务功能 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、主被叫 RCS 用户注册成功。 1、UE A 向 UE B 发一个 IM&900 字节的文本消息。UE B 收到消息并查看。 2、UE B 向 UE A 发一个 IM&900 字节的文本消息。UE A 收到消息并查看。 验收标准： 1、 UE A和UE B都能收到对方发送的文本消息。 2、 接收的内容和发送的一致。 无测试子项 目 测试目的 测试依据 预置条件 测试步骤 检查点参考流程5.6.1.3 测试编号 测试项目Session Mode基本一对一消息消息类业务 Session Mode 基本一对一消息 Sessoion Mode 一对一消息。 中国移动融合通信系列规范 1、 网络中各网元系统及操作维护台运行正常。 2、 网络侧 （接入控制功能） 、 终端侧配置 APP 接入的 SIP 信令传输协议类型为 TCP。 3、 新消息模块、APP 上配置一对一消息传输使用 Session Mode。 4、 UE A、UE B 开户成功，且均融合通信在线。 1、 UE A 向 UE B 发一个 IM 文本消息（中英文字符混发） ，UE B 收到文本消 息并查看。 2、 UE B 向 UE A 发一个 IM 文本消息（中英文字符混发） ，UE A 收到文本消 息并查看。测试子项 目 测试目的 测试依据 预置条件测试步骤45检查点验收标准： 1、 UE A 和 UE B 都能收到对方发送的 IM 文本消息，接收的内容和发送的一 致。 2、 UE A、UE B 与业务接入模块之间采用 TCP 传输协议。 3、 检查 Session 建立是否成功。 4、 第一个 IM 文本消息使用 INVITE 建立会话，并通过 INVITE 消息中的 message/cpim 消息体携带该消息内容。 新消息模块发送给 UE B 的消息也同 样通过 INVITE 携带。第二个文本内容通过 MSRP 协议传递。 5、 UE A 和 UE B 发送的 INVITE 消息中携带 CPIM，Content-Type 头域携带 message/cpim ； Accept-Contact 携 带 +g.3gpp.icsi-ref=&urn%3Aurn-7%3A3gpp-service.ims.icsi.oma.cpm.session& ， 新消息模块下发给被叫的 INVITE 中也携带此 feature tag。 6、 UE A 发送的 INVITE 消息中包含 Conversation-ID、Contribution-ID 头域， 新 消 息 模 块 下 发 给 UE B 的 INVITE 中 也 携 带 Conversation-ID 和 Contribution-ID，且值和 UE A 发送的 INVITE 中的保持一致。参考流程5.6.1.4 测试编号 测试项目1-1图片消息（压缩方式）消息类业务 1-1 发送图片 验证用户使用缩略图模式发送 1-1 图片成功。 中国移动融合通信系列规范 1、网络中各网元系统及操作维护台运行正常。 2、网络侧配置发送图片采用缩略图方式。 3、RCS 用户 UE A 和 UE B 注册成功。 1、UE A 向 UE B 发送图片业务。 2、UE B 收到缩略图后点击缩略图下载并查看图片内容。 验收标准： 1、UE B