【通信行业标准(YD)】 基于统一IMS的业务技术要求 呼叫等待与呼叫保持业务（第一阶段）

ICS33.030
中华人民共和国通信行业标准
YD/T 2011-2009
基于统一 IMS 的业务技术要求
呼叫等待与呼叫保持业务（第一阶段）Technical Requirements of Services based on the Unified IMSCall Waiting(CW)and Call HOLD(HOLD)Services(Release 1)
2009-12-11 发布
2010-01-01实施
中华人民共和国工业和信息化部?发 布前
范围·
2规范性引用文件
3术语、定义和缩略语
3.1术语和定义·
3.2缩略语…
业务描述与业务特征·
4.1呼叫等待
4.2呼叫保持…
5业务服务终端·
6业务管理…·
6.1概述
6.2终端拨号方式.
6.3Ut接口方式，
7业务触发
8业务对功能实体和信令的要求·8.1呼叫等待业务…·
8.2呼叫保持业务
9与其他基于统一IMS 的业务间的交互作用9.1呼叫等待业务，
附录A（资料性附录）呼叫等待消息流程示例附录B（资料性附录）呼叫保持消息流程示例次
附录C（资料性附录）拨号方式实现业务配置和管理的消息流程示例·附录D（资料性附录）呼叫等待业务XMLSchema附录E（资料性附录）
参考文献
呼叫等待指示消息体示例
YD/T 2011-2009
YD/T2011-2009
本标准是基于统一IMS的业务系列标准之一，该系列标准的名称及结构预计如下：基于统一IMS的业务技术要求标识显示及限制类业务（第一阶段）；基于统一IMS的业务技术要求呼叫前转类业务（第一阶段)；一基于统一IMS的业务技术要求呼叫等待与呼叫保持业务（第一阶段）；一基于统一IMS的业务技术要求恶意呼叫追踪和匿名呼叫拒绝业务（第一阶段）；一基于统一IMS的业务技术要求IPCENTREX业务（第一阶段）；一基于统一IMS的业务技术要求点击拨号业务（第一阶段）；一基于统一IMS的业务技术要求多媒体彩铃业务（第一阶段）；一基于统一IMS的业务技术要求个性化振铃音业务（第一阶段)；一基于统一IMS的业务技术要求多媒体会议业务（第一阶段）。随着技术的发展，还将制定后续的相关标准。在本标准的制定过程中还注意了与以下标准的协调统一：统一IMS的需求（第一阶段）；
统一IMS的功能体系架构（第一阶段）;统一IMS组网总体技术要求（第一阶段）。本标准的附录A、附录B、附录C、附录D和附录E为资料性附录。本标准由中国通信标准化协会提出并归口。本标准起草单位：工业和信息化部电信研究院、华为技术有限公司、中兴通讯股份有限公司、上海贝尔股份有限公司。
本标准主要起草人：杨海涛、减磊、刘文宇、李振东、李新颜、周惠琴。I
1范围
基于统一IMS 的业务技术要求
呼叫等待与呼叫保持业务（第一阶段）YD/T2011-2009
本标准规定了基于统一IMS的呼叫等待业务与呼叫保持业务的业务描述与业务特征、业务服务终端、业务管理、业务触发、业务对功能实体和信令的要求、与其他基于统一IMS的业务间的交互作用等要求。本标准适用于基于统一IMS的呼叫等待业务与呼叫保持业务。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。3GPPTS24.623使用模拟业务的Ut接口上可扩展标识语言(XML)配置访问协议(XCAP）V8.1.0 (2008-09)
(ExtensibleMarkupLanguage(XML)Configuration AccessProtocol (XCAP)overtheUtinterfaceforManipulatingSimulationServices）3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本标准。临近NDUBapproachingNDUB
在临近NDUB情况下，网络对每个用户都配置有最大可用资源，同时，网络对每个用户还配置有临近NDUB预设可用资源，限制可用资源的值应小于最大可用资源。临近NDUB形成的条件需要满足下列任意一项：
a）语音会话情况下，用户正在进行的通话数量已达到临近NDUB预设可用资源，并且没有达到最大可用资源；
b）多媒体会话情况下，用户已经占用的多媒体流数量已达到临近NDUB预设可用资源的上限，并且没有达到最大可用资源：
c）用户已占用的多媒体带宽已达到临近NDUB预设可用资源的上限，并且没有达到最大可用资源。3.2缩略语
下列缩略语适用于本标准。
Application Server
Digital Subscriber Line
Integrated Access Device
Initial Filter Criteria
IP Multirnedia Subsystem
应用服务器
数字用户线路
综合接入设备
初始过滤规则
IP 多媒体子系统
YD/T 2011-2009
Integrated Services Digital NetworkLocal Area Network
NetworkDeterminedUserBusy
Next Generation Network
PublicSwitchedTelephoneNetworkSessionInitiationProtocol
Uniform Resource Identifier
Wireless Local Area Network
XML Configuration Access ProtocolExtensibleMarkup Language
4业务描述与业务特征
4.1呼叫等待
综合业务数字网
局域网
网络决定用户忙
下一代网络
公共电话交换网
会话初始协议
统一资源标识符
无线局域网
XML配置接入协议
可扩展标记语言
呼叫等待业务是指当呼叫等待业务用户B正与用户A通话时，用户C试图与用户B建立通话连接，此时呼叫等待业务用户B可以接收到呼叫等待指示，表示另有用户等待通话，同时，被呼叫等待用户C可以接收到呼叫等待指示，指示呼出通话正在被呼叫等待。呼叫等待业务用户B对被呼叫等待的呼叫可以选择接受、拒绝或不理躲等操作。
4.2呼叫保持
呼叫保持业务是指用户在一个IP多媒体会话中，暂时中断单个或所有媒体流，并能够将中断的媒体流恢复的业务。
5业务服务终端
在统一IMS的第一阶段，呼叫等待与呼叫保持业务可服务于以下终端：a）SIP硬终端（指支持SIP协议并且通过xDSL、WLAN、LAN接入IMS域的终端。该类型终端具有一定的物理形态。此类型终端暂不要求具备ISIM卡）；b）SIP软终端（指支持SIP协议并且通过xDSL、WLAN、LAN接入IMS域的一种软件客户端，通常安装在个人PC等设备上。此类型终端可以具备或不具备ISIM卡）；c）移动终端（指支持SIP协议并且通过2G、3G接入IMS域的移动终端。此类型终端要求具备SIM卡/USIM卡/ISIM卡/R-UIM卡/CSIM卡，但对于cdma2000机卡合一终端，可以不具备物理实体的R-UIM卡ICSIM卡）。
6业务管理
6.1概述
用户可以通过多种方式来对自已的呼叫等待与呼叫保持业务进行配置和管理，主要包括终端拨号方式、Ut接口方式、Web方式等。其中，网络和终端至少应支持拨号方式和Ut接口方式（未包含呼叫保持业务）。当用户通过不同方式对业务数据进行配置时，最新的业务配置应覆盖之前的业务配置。业务配置和管理的内容主要包括：对呼叫等待与呼叫保持业务进行激活和去激活操作，查询业务状态等。
YD/T2011-2009
对于拨号方式，具体业务配置和管理的编号可依据业务运营者的应用需求而定，不在此进行标准化，其拨号程序可参考6.2节。
对于Ut接口方式，具体业务配置和管理的操作和界面等可依据具体应用需求而定，不在此进行标准化。对于Web方式，是指统一IMS为用户提供基于互联网的个人信息助理功能，每个终端用户都有自己的用户名和密码，在登录业务提供者提供的网站并通过鉴权后，可以在线进行呼叫等待与呼叫保持业务的配置管理。具体实现方式可由业务提供者根据自己的需求来设置。6.2终端拨号方式
6.2.1概述
拨号方式实现业务配置和管理的消息流程示例参见附录C。6.2.2呼叫等待
激活：按“相关业务码”；响应，如听到相应的录音通知；结束。去激活：按“相关业务码”；响应，如听到相应的录音通知；结束。业务状态查询：按“相关业务码”；响应，如听到相应的录音通知；结束。6.2.3呼叫保持
激活：按“相关业务码”；响应，如听到相应的录音通知；结束。去激活：按“相关业务码”：响应，如听到相应的录音通知：结束。业务状态查询：按“相关业务码”：响应，如听到相应的录音通知；结策。6.3Ut接口方式
呼叫等待业务可以通过Ut接口进行设置，具体XMLSchema格式参见附录D。7业务触发
为了保证业务的正常实现，HSS应为每个业务用户建立相应的初始过滤规则（iFC）。对于呼叫等待业务和呼叫保持业务，业务用户的iFC应保证会话请求能够发送至相应的业务AS以进行相关的业务处理：a）对于呼叫等待业务，S-CSCF应将向该业务用户发起的INVITE请求，发送至呼叫等待业务AS进行相关的业务处理；
b）对于呼叫保持业务，S-CSCF应将该业务用户发起的INVITE请求，发送至呼叫保持业务AS进行相关的业务处理。
8业务对功能实体和信令的要求
8.1呼叫等待业务
8.1.1概述
本节只对业务相关的处理进行描述。呼叫等待消息流程示例参见附录A。8.1.2呼叫等待业务用户终端操作8.1.2.1呼叫等待业务用户终端基本能力当收到包含呼叫等待指示的INVITE消息，并且呼叫等待业务用户未达到最大呼叫等待数时，呼叫等待业务用户终端应具备下列能力：a）启动TuE-Cw定时器（TuE-Cw定时器可以在呼叫等待业务用户终端上设置呼叫等待时长，此操作为可选操作）；
YD/T2011-2009
b）向业务用户提供呼叫等待指示（例如，带内呼叫等待提示音、在终端屏幕上提示呼叫等待等）；c）对INVITE消息发送180（Ringing）响应。在用户决定呼叫等待的情况下，终端应在180响应中插入Alert-Info头字段，Alert-Info的值为“urn:alert:service:call-waiting”。INVTTE消息中包含的呼叫等待指示的内容见8.1.3.2节，呼叫等待指示消息体示例参见附录E。8.1.2.2呼叫等待业务用户终端对呼叫等待来话进行操作的场景场景一：呼叫等待业务用户接听被呼叫等待用户来话，释放原通话，TuE-Cw定时器未超时，呼叫等待业务用户终端应进行如下操作：a）停止TuE-cw定时器（可选操作）；b）停止向呼叫等待业务用户提供呼叫等待指示；c）释放当前正在进行的呼叫：
d）接听呼叫等待的呼叫。
场景二：呼叫等待业务用户接听被呼叫等待用户来话，保持原通话，TuE-CW定时器未超时，呼叫等待业务用户终端应进行如下操作：a）停止TuE-cw定时器（可选操作）；b）停止向呼叫等待业务用户提供呼叫等待指示；c）当前正在进行的呼叫进行呼叫保持操作：d）接听呼叫等待的呼叫。
场景三：呼叫等待业务用户继续原通话，不对被呼叫等待用户来话进行任何操作，启动TuE-Cw定时器（可选操作），并且TuE-Cw定时器超时，呼叫等待业务用户终端应进行如下操作：a）停止向呼叫等待业务用户提供呼叫等待指示；b）向正在呼叫等待的用户发送480（Temporarilyunavailable）响应，480中的Reason头字段原因值设置为19。
8.1.2.3呼叫等待业务用户终端收到释放呼叫消息的场景场景一：呼叫等待业务用户终端在呼叫等待状态下，收到了被呼叫等待的主叫用户终端发送的CANCEL或BYE消息，呼叫等待业务用户终端应进行如下操作：a）停止TuE-cw定时器（可选操作）；b）停止向呼叫等待业务用户提供呼叫等待指示：c）对CANCEL或者BYE消息发送响应。场景二：呼叫等待业务用户终端在呼叫等待状态下，收到了原通话用户发送的CANCEL或BYE消息，呼叫等待业务用户终端应进行如下操作：：a）停止TuE-cw定时器（可选操作）；b）停止向呼叫等待业务用户提供呼叫等待指示；c）对CANCEL或者BYE消息发送响应；d）接听呼叫等待用户的来话。
场景三：呼叫等待业务用户在呼叫等待状态下，拒绝被呼叫等待用户的来话，呼叫等待业务用户终端应进行如下操作：
a）停止TuE-Cw定时器（可选操作）；4
b）停止向呼叫等待业务用户提供呼叫等待指示；c）向正在被呼叫等待的用户发送486响应。8.1.3呼叫等待业务用户归属S-CSCF操作YD/T2011-2009
S-CSCF应将向该业务用户发起的INVITE请求，发送至呼叫等待业务AS进行相关的业务处理。8.1.4呼叫等待业务AS操作
8.1.4.1AS判定发生呼叫等待
临近NDUB情况下，AS收到INVITE请求，AS判定发生呼叫等待。用户决定呼叫等待情况下，AS收到有Alert-Info头字段的180响应，Alert-Info头字段赋值为“urn:alert:service:call-waiting”，AS判定发生呼叫等待。8.1.4.2AS插入参数操作处理
在临近NDUB情况下，呼叫等待业务AS判定发生呼叫等待，则呼叫等待业务AS应进行如下处理：a）呼叫等待业务AS在INVITE请求中插入MIME消息体作为呼叫等待指示，MIME消息体中的参数设置如下：在“call-waiting-indication”元素中应包含“ims-cw”根元素；Content-Type头字段应赋值为“application/3gpp-cw+xml”；b）呼叫等待业务AS收到呼叫等待业务用户返回的180响应后，在180响应内插入Alert-Info头字段，Alert-Info头字段赋值为“urn:alert:service:call-waiting”。8.1.4.3向被呼叫等待用户发送呼叫等待指示临近NDUB情况下，INVITE请求发送至呼叫等待呼叫等待业务用户，呼叫等待业务AS收到呼叫等待业务用户返回的180响应后，在180响应内插入Alert-Info头字段，Alert-Info头字段赋值为“urn:alert:service:call-waiting”，并将插入Alert-Info头字段的180响应发送至被呼叫等待用户，向被呼叫等待用户提供呼叫等待指示。
用户决定呼叫等待情况下，AS收到的呼叫等待呼叫等待业务用户返回的180响应带有Alert-Info头字段，Alert-Info头字段赋值为“urn:alert:service:call-waiting”，AS应将带有Alert-Info头字段的180响应转发至被呼叫等待用户，向被呼叫等待用户提供呼叫等待指示。8.1.4.4TAS-CW定时器超时操作处理在呼叫等待业务发生时，呼叫等待业务AS收到180(Ringing)消息后，启动TAs-cw定时器，当TAs-cw定时器超时后，AS应该发送CANCEL请求至呼叫等待业务用户终端，该CANCEL中应包含Reason头字段，Reason头字段协议段设置为“SIP”，原因值设置为“408”，并发送480(Temporarilyunavailable)至被呼叫等待用户，480中的Reason头字段原因值设置为19。TAs-cw定时器由呼叫等待业务AS进行控制。TAs-cw定时器规定了呼叫等待业务用户向被呼叫等待业务用户做出响应的时长，时长范围可由系统自行配置，在此范围内，可自由定制呼叫等待时长。8.1.5被呼叫等待用户终端操作
被呼叫等待用户终端收到启用Alert-Info头字段的180(Ringing）响应，Alert-Info的值为“urn:alert:service:call-waiting”，被呼叫等待用户终端应向用户指示呼出通话正在被呼叫等待。8.2呼叫保持业务
8.2.1概述
本节只对业务相关的处理进行描述。呼叫保持消息流程示例参见附录B。5
YD/T2011-2009
8.2.2呼叫保持业务用户终端操作呼叫保持终端应发送包含SDP信息的re-INVITE消息进行呼叫保持操作，并应具备对一个会话中的单个媒体流分别进行呼叫保持和对一个会话中的所有媒体流同时进行呼叫保持的能力。对单个媒体流进行呼叫保持和恢复时，进行如下操作：a）呼叫保持终端对一个会话中的单个媒体流分别进行呼叫保持时，呼叫保持业务用户终端应生成一个新的SDP，对SDP中单个媒体流属性media-descriptions之后的attribute-fields属性行进行修改，具体修改内容如下：
一若之前为“a=recvonly”，则设置为“a=inactive”；一若之前为“a=sendrecv”，则设置为“a=sendonly”。b）呼叫保持终端对一个会话中的单个媒体流分别进行呼叫保持恢复时，呼叫保持业务用户终端应生成一个新的SDP，对SDP中单个媒体流属性media-descriptions之后的attribute-fields属性行进行修改，具体修改内容如下：
一若之前为“a=inactive”，则设置为“a=recvonly”；一若之前为“a=sendonly”，则设置为“a=sendrecv”或者a的值缺省。对所有媒体流进行呼叫保持恢复时，进行如下操作：c）呼叫保持终端对所有媒体流进行呼叫保持时，呼叫保持业务用户终端应生成一个新的SDP，对SDP中session-name-field头字段之后的attribute-fields属性行进行修改，具体修改内容如下：一若之前为“a=recvonly”，则设置为“a=inactive”；一若之前为“a=sendrecv”，则设置为“a=sendonly”。d）呼叫保持终端对所有媒体流进行呼叫保持恢复时，呼叫保持业务用户终端应生成一个新的SDP，对SDP中session-name-field头字段之后的attribute-fields属性行进行修改，具体修改内容如下：一若之前为“a=inactive”，则设置为“a=recvonly”；一若之前为“a=sendonly”，则设置为“a=sendrecy”或者a的值缺省。8.2.3呼叫保持业务AS操作
呼叫保持业务AS应处理所有呼叫保持业务用户发起的INVITE消息。呼叫保持业务AS可以向被呼叫保持用户终端发送呼叫保持业务指示。9与其他基于统一IMS的业务间的交互作用9.1呼叫等待业务
9.1.1与无条件呼叫前转业务的交互作用无条件呼叫前转业务优先于呼叫等待业务。9.1.2与退忙呼叫前转业务的交互作用遇忙呼叫前转业务优先于呼叫等待业务。9.1.3与无应答呼叫前转业务的交互作用如果无应答呼叫前转定时器先于呼叫等待业务定时器超时，则执行无应答呼叫前转业务。如果呼叫等待业务定时器先于无应答呼叫前转定时器超时，则执行呼叫等待业务定时器超时的流程。9.1.4与多媒体彩铃业务的交互作用呼叫等待业务优先于多媒体彩铃业务。6
附录A
（资料性附录）
呼叫等待消息流程示例
A.1临近NDUB情况下，呼叫等待消息流程示例临近NDUB情况下的呼叫等待消息流程示例如图A.1所示。被叫S-CSCF
2a.AS判定为临近NDUB
情况，在INVITE请求中
插入呼叫等待指示
[呼叫等待指示
[呼叫等待指示
7.180Ringing
-8.180 Ringing—
8a.AS在180响应中插入
Alert-Info头字段
8b.CW定时器启动
9.180 Ringing
Alert-Info:
10.180 Ringing
AlertInfa
urn:alertservice
call-waiting
urn:alertservice
call-waiting
13.200OK-
13a.CW定时器停止
P-CSCF
[呼叫等待指示
6.180Ringing
图A.1临近NDUB情况下的呼叫等待消息流程示例流程说明如下：
1~2．发起对UE-B的呼叫。
2a。AS判定为临近NDUB情况，在INVITE请求中插入呼叫等待指示。3~4.INVITE请求转发至UE-B。
5.UE-B识别呼叫等待指示，向呼叫等待业务用户指示呼叫等待业务。6.UE-B发送180响应。
7~8．180响应发送至AS。
YD/T2011-2009
8a.AS在180响应中插入带有Alert-Info头字段，Alert-Info头字段赋值为“urn:alert:service:call-waiting”。8b.CW定时器启动。
9~10.带有Alert-Info头字段的180响应发送至被呼叫等待业务用户。7
YD/T2011-2009
11~15．UE-B发送200OK响应。
13a.CW定时器停止。
A.2用户决定呼叫等待情况下，呼叫等待消息流程示例用户决定呼叫等待情况下的呼叫等待消息流程示例如图A.2所示。被叫S-CSCF
7.183Sesslon
progress
8.183Session
progress
9.183Session
1a.183Session
progress
15.180Ringing
AlertHnfo:
urn:alert:service:
call-waiting
20.200OK-
progress
12180Ringing
AlertHnfo:
urrtalert:service:
cali-waking
13.180Ringing
Alert-Infa
urrtalert:service:
call-wakting
13a.CW定时器启动
14. 180 Ringing
Alert-Infa
urrtalert:servioa:
call-waiting
17.200OK-
18a.CW定时器停止bzxz.net
P-CSCF
5.INVITE-
6.183Session
progress
11.180 Ringing
AlertHnfo:
urrtalert:service:
call-waiting
—16.200OK-
图A.2用户决定呼叫等待情况下的呼叫等待消息流程示例流程说明如下：
1~5．发起对UE-B的呼叫。
6~10.UE-B向主叫用户发送临时响应。11~15.UE-B发送180响应，同时，UE-B在180响应中插入带有Alert-Info头字段，Alert-Info头字段赋值为“urn:alert:service:call-waiting”。13a.CW定时器启动。
16~20.UE-B发送200OK响应。
18a.CW定时器停止。
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。