YD/T 3034-2016
基本信息
标准号： YD/T 3034-2016
中文名称：基于统一 IMS 的业务技术要求呼叫闭锁和多方通话业务(第一阶段)
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：2374214
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 3034-2016.Technical requirements of services based on the unified IMS communication barring and Multi-Party call service (Release 1).
1范围
YD/T 3034规定了基于统一IMS的呼叫闭锁业务与多方通话业务的业务描述与业务特征、业务服务终端、业务管理、业务触发、业务对功能实体和信令的要求、与其他基于统一IMS的业务间的交互作用等要求。
YD/T 3034适用于基于统一IMS的呼叫闭锁业务与多方通话业务。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
3GPP TS 29.228 IP多媒体子系Cx和Dx接口;信令流程和消息内容( IP Multimedia (IM) Subsystem Cx and Dx interfaces;Signalling flows and message contents )
3缩略语
下列缩略语适用于本文件。
AGCF Access Gateway Control Function 接入网关控制器
AS Application Server 应用服务器
CDMA Code Devision Multiple Access 码分多址接入
CSCF Call Session Control Function 呼叫会话控制功能
1范围
YD/T 3034规定了基于统一IMS的呼叫闭锁业务与多方通话业务的业务描述与业务特征、业务服务终端、业务管理、业务触发、业务对功能实体和信令的要求、与其他基于统一IMS的业务间的交互作用等要求。
YD/T 3034适用于基于统一IMS的呼叫闭锁业务与多方通话业务。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
3GPP TS 29.228 IP多媒体子系Cx和Dx接口;信令流程和消息内容( IP Multimedia (IM) Subsystem Cx and Dx interfaces;Signalling flows and message contents )
3缩略语
下列缩略语适用于本文件。
AGCF Access Gateway Control Function 接入网关控制器
AS Application Server 应用服务器
CDMA Code Devision Multiple Access 码分多址接入
CSCF Call Session Control Function 呼叫会话控制功能
标准图片预览
标准内容
ICS33.030
中华人民共和宝玉通信行标准
YD/T3034-2016
基于统一IMS的业务技术要求
呼叫闭锁和多方通话业务（第一阶段）Technical requirementsofservicesbasedontheunified IMscommunicationbarringandMulti-Partycallservice(Release1)2016-04-05发布
2016-07-01实施www.bzxz.net
中华人民共和国工业和信息化部发布前
范围·
2规范性引用文件。
3缩略语
4终端要求
5呼叫闭锁类业务
6多方通话业务·
附录A（资料性附录）消息流程示例+目
附录B（资料性附录）拨号方式实现业务配置和管理的消息流程示例附录C（资料性附录）Ut接口方式实现业务配置示例·YD/T3034-2016
YD/T3034-2016
YD/T3034《基于统一IMS的业务技术要求呼叫闭锁和多方通话业务（第一阶段）》与《基于统IMS的业务测试方法多媒体电话业务（第一阶段）第2部分：呼叫闭锁和多方通话业务》共同构成“基于统一IMS的多媒体电话业务”系列行业标准。“基于统一IMS的多媒体电话业务”系列还包括如下标准：YD/T1932-2009《基于统一IMS的业务技术要求标识显示及限制类业务（第一阶段）》；YD/T1931-2009《基于统一IMS的业务技术要求呼叫前转类业务（第一阶段）》一YD/T2011-2009《基于统一IMS的业务技术要求呼叫等待与呼叫保持业务（第一阶段）》一YD/T2013-2009《基于统一IMS的业务技术要求恶意呼叫追踪和匿名呼叫拒绝业务（第一阶段）》
YD/T2457.1-2013《基于统一IMS的业务测试方法多媒体电话业务（第一阶段）第1部分：基本业务和必选补充业务》
一《基于统一IMS的业务技术要求呼叫闭锁和多方通话业务（第一阶段）》《基于统一IMS的业务测试方法多媒体电话业务（第一阶段）第2部分：呼叫闭锁和多方通话业务》
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中国联合网络通信集团有限公司。本标准主要起草人：魏群、吕光旭、符刚。Ⅱ
HiiKANiKAca
1范围
基于统一IMS的业务技术要求
呼叫闭锁和多方通话业务（第一阶段）YD/T3034-2016
本标准规定了基于统一IMS的呼叫闭锁业务与多方通话业务的业务描述与业务特征、业务服务终端、业务管理、业务触发、业务对功能实体和信令的要求、与其他基于统一IMS的业务间的交互作用等要求。
本标准适用于基于统一IMS的呼叫闭锁业务与多方通话业务。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。3GPP TS 29.228
3缩略语
IP多媒体子系Cx和Dx接口；信令流程和消息内容（IPMultimedia（IM）SubsystemCxandDxinterfaces;Signallingflowsandmessagecontents)下列缩略语适用于本文件。
AccessGatewayControlFunctionApplication Server
Code Devision Multiple AccessCall Session Control FunctionSubscriber Identity Module
Communication Barring
Three Party Conference
CDMASubscriberIdentityModuleCDMADigital Subscriber Line
Integrated Access Device
Initial Filter Criteria
IP Multimedia Subsystem
Integrated ServicesDigital NetworkIMS Subscriber Identity ModuleLocal Area Network
MRFController
Network Determined User BusyNext Generation Network
PlainOldTelephoneService
PublicSwitchedTelephoneNetwork接入网关控制器
应用服务器
码分多址接入
呼叫会话控制功能
客户识别模块
呼叫闭锁
三方通话
用户识别模块
数字用户线路
综合接入设备
初始过滤规则
IP多媒体子系统
综合业务数字网
IMS用户识别模块
局域网
多媒体资源控制器
网络决定用户忙
下一代网络
模拟电话业务
公共电话交换网
HiiKAoiKAca
YD/T3034-2016
S-CSCF
4终端要求
Removable User Identity ModuleServing Call Session Control FunctionSubscriber Identity Module
Session Initiation Protocol
User Determined User Busy
Uniform ResourceIdentifier
Wireless Local Area Network
XML Configuration Access ProtocolExtensible Markup Language
可移动用户识别模块
服务呼叫会话控制功能
用户识别模块
会话初始协议
用户决定用户忙
统一资源标识符
无线局域网
XML配置接入协议
可扩展标记语言
基于统一IMS的呼叫闭锁业务及多方通话业务可服务于以下终端：·SIP硬终端（指支持SIP协议并且通过xDSL、WLAN、LAN接入IMS域的终端。该类型终端具有一定的物理形态，暂不要求具备ISIM卡）：·SIP软终端（指支持SIP协议并且通过xDSL、WLAN、LAN接入IMS域的一种软件客户端，通常安装在个人PC等设备上。此类型终端可以具备或不具备ISIM卡）；·移动终端（指支持SIP协议并且通过2G、3G、LTE接入IMS域的移动终端。此类型终端要求具备SIM卡/USIM卡/ISIM卡/R-UIM卡/CSIM卡，但对于cdma2000机卡合一终端，可以不具备物理实体的R-UIM卡/CSIM卡）
·SIPPON/IAD：支持SIP协议的综合接入设备，其上行端口接入IMS网络，下行提供端口连接多个模拟话机，用来提供传统POTS终端的接入。·H.248PON/IAD/AG：支持H.248协议的综合接入设备，其上行端口接入AGCF，下行提供端口连接多个模拟话机，用来提供传统POTS终端的接入。对于使用2G、3G和LTE接入方式的移动终端，要求终端具备UICC卡，可以包含SIM/USIM/ISIM；对于SIP软终端，可以具备或不具备ISIM卡；对于SIP硬终端和SIPIAD，暂不要求具备ISIM卡。
5呼叫闭锁类业务
5.1业务描述与业务特征
呼叫闭锁类业务包括呼叫限制和运营商闭锁两部分：●呼叫限制业务允许用户和运营商根据号码、媒体类型、时间等，设置限制用户呼出或呼入。例如，国内长途、国际长途呼叫限制。定制了国内长途限制业务的用户，如果进行国内长途呼叫，呼叫会被终止并听到国内长途呼叫限制提示音：定制了国际长途限制业务的用户，如果进行国际长途呼叫，呼叫会被终止并听到国际长途呼叫限制提示音；●运营商闭锁是指运营商能够对用户设置呼入或呼出闭锁。设置呼入闭锁，用户无法接听电话：设置呼出闭锁时，用户无法拨出电话，并听到限制提示音。例如，用户欠费时，运营商可以闭锁其所有呼出业务。
基于IMS的呼叫闭锁类业务至少要继承固网和移动网的闭锁业务，支持多种条件的闭锁。对于服务2
HiiKAoiKAca
器所具备的放音等媒体处理控制功能均由MRFC完成，以下AS均包含该部分功能。5.2业务管理
5.2.1概述
YD/T3034-2016
用户可以通过多种方式来对自已的呼叫闭锁业务进行配置和管理，主要包括终端拨号方式、Ut接口方式、基于SIP的用户配置等。其中，网络和终端至少应支持拨号方式和Ut接口方式。当用户通过不同的方式对业务数据进行配置时，最新的业务配置应覆盖之前的业务配置。业务配置和管理的内容主要包括：对业务进行激活和去激活操作，查询业务状态，设置配置规则等。对于拨号方式，具体业务配置和管理的编号可依据业务运营者的应用需求而定，不在此进行标准化，其拨号程序见5.2.2。对于Ut接口方式，具体业务配置和管理的操作和界面等可依据具体应用需求而定不在此进行详述。
5.2.2终端拨号方式
终端拨号实现流程参见附录B。
终端拨号程序例如：
·激活：用户激活该业务时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知；则结束挂机：
·去激活：用户去激活该业务时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知；则结束挂机：
·业务状态查询：用户查询该业务状态时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知：则结束挂机。
5.2.3Ut接口方式
呼叫闭锁类业务可以通过Ut接口进行设置和查询，具体方式示例见附录C。5.3业务触发
为了保证业务的正常实现，HSS应为每个业务用户建立相应的初始过滤规则（iFC）。对于呼叫闭锁业务，业务用户的FC应保证会话请求能够发送至相应的业务AS以进行相关的业务处理。INVITE触发规则：
·主叫侧S-CSCF收到业务用户发起的INVITE消息，将其发送至呼叫闭锁业务AS进行相关的业务处理。
·被叫侧S-CSCF收到业务用户发起的INVITE消息，将其发送至呼叫闭锁业务AS进行相关的业务处理。
5.4业务对功能实体和信令的要求5.4.1呼出闭锁业务对功能实体和信令的要求5.4.1.1主叫终端操作
将INVITE请求发送至主叫端呼出闭锁AS，基于IMS标准流程，5.4.1.2呼出闭锁AS操作
当主叫用户的呼出闭锁策略为（allow=“false”时），AS提供的呼出闭锁业务应该拒绝呼出来电。呼出闭锁机制为呼出闭锁服务器将用户携带的INVITE信息和用户配置的参数进行比较，看是否一致。
HiiKAoiKAca
YD/T3034-2016
根据号码进行呼出闭锁时，为了实现呼出闭锁的的目的，AS应将“cp：identity”，“ocp：extermal-list\条件和从Request-URI或额外从To消息头部分得到的被叫方信息进行对比，如果对比结果一致，则实现呼出闭锁。
根据在线状态实现呼出闭锁时，将“presence-status”条件和被叫用户的当前显示状态进行对比，如果对比结果一致，则实现呼出闭锁。根据媒体类型实现呼出闭锁时，将“media”条件和主叫用户INVITE请求中的media部分进行对比，如果对比结果一致，则实现呼出闭锁。根据时间实现呼出闭锁时，将“cp:validity”条件和当前时间进行对比，如果当前时间在设置的“cp:validity”条件范围内，则实现呼出闭锁。当AS提供呼出闭锁服务阻止一个通信时，AS应该向正在呼叫的用户发送一个603（decline）/403(fobbiden)响应或者向用户发送一个487（录音通知）响应来告知其呼叫被拒绝。呼出闭锁消息流程参见附录A。
5.4.2呼入闭锁业务对功能实体和信令的要求5.4.2.1业务主叫终端操作
将该INVITE请求发送至被叫端呼入闭锁AS，基于IMS标准流程。5.4.2.2呼入闭锁AS操作
当被服务用户的呼入闭锁策略为（allow=“false”时），AS提供的呼入闭锁业务应该拒绝呼入来电。呼入闭锁机制为呼入闭锁服务器将用户收到的INVITE信息和用户配置的参数进行比较，看是否一致。
根据号码实现呼入闭锁时，为了实现呼入闭锁的的目的，AS应该将“cp：identity”，“ocp：external-list”条件和P-Asserted-Identity头字段中的主叫用户标识信息或Referred-By头字段或From头字段的用户标识信息进行对比，如果对比结果一致，则实现呼入闭锁。根据媒体类型实现呼入闭锁时，将“media”条件和主叫用户INVITE请求中的media部分进行对比，如果对比结果一致，则实现呼入闭锁。根据时间实现呼入闭锁时，将“cp:validity”条件和当前时间进行对比，如果当前时间在设置的“cp:validity”条件范围内，则实现呼入闭锁。当AS提供呼入闭锁服务阻止一个通信时，AS应该向正在呼叫的用户发送一个603（decline）/403(forbidden)响应或者向用户发送一个487（录音通知）响应来告知其呼叫被拒绝。呼入闭锁消息流程参见附录A
5.5与其他基于统一IMS的业务间的交互作用5.5.1呼叫等待业务
呼叫等待业务与呼叫闭锁业务签约时无冲突关系。用户同时签约呼叫等待业务与呼入闭锁，呼叫闭锁优先于呼叫等待。
5.5.2呼叫前转类业务
呼转类业务与闭锁业务签约时无冲突关系。如果用户B激活了呼出限制到C，那么B将无法前转呼叫到C。如果用户A呼叫B，B签约前转到C，B对A进行了呼入限制，那么B将无法前转呼叫到C，即呼叫闭锁业务优先于前转。
HiiKAoNiKAca
5.5.3彩铃业务
YD/T3034-2016
彩铃与呼叫闭锁业务业务签约时无冲突关系，如果用户签约了呼入限制的情况下，则先进行限呼处理，将不会播放用户的彩铃。
5.5.4彩像业务
彩像与呼叫闭锁业务业务签约时无冲突关系，如果用户签约了呼出限制的情况下，则先进行限呼处理，将不会发送用户的彩像。
5.5.5多方通话
多方通话业务与呼叫闭锁业务签约时无冲突关系。用户同时签约多方通话业务与呼入闭锁，呼叫闭锁优先于多方通话。如果Refer-To的被叫用户被会议创始者的呼出闭锁规则屏蔽了，则AS不应该接受该REFER请求。AS应该移除掉URI列表中被呼出屏蔽掉了的用户的URI。建立的多方通话中不包括被屏蔽的用户。
6多方通话业务
6.1业务描述与业务特征
本业务允许多于两个用户同时进行语音/视频通话，支持终端混音方式和网络混音方式。其中终端混音对网络没有要求。
对于服务器所具备的混音等媒体处理控制功能均由MRFC完成，以下AS均包含该部分功能。6.2业务管理
6.2.1概述
用户可以通过多种方式来对自已的多方通话业务进行配置和管理，主要包括终端拨号方式、Web方式等。其中，网络和终端至少应支持拨号方式。当用户通过不同的方式对业务数据进行配置时，最新的业务配置应覆盖之前的业务配置业务配置和管理的内容主要包括：对业务进行激活和去激活操作，查询业务状态，设置配置规则等。6.2.2终端拨号方式
多方通话（终端混音）主要由终端实现，没有相关业务管理操作。多方通话（网络混音）终端拨号方式如下：·激活：用户激活该业务时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知；则结束挂机。
·去激活：用户去激活该业务时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知：则结束挂机。
●业务状态查询：用户查询该业务状态时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知；则结束挂机。
6.3业务触发
终端混音：没有多方通话的过滤规则，者作普通会话处理。网络混音：为了保证业务的正常实现，HSS应为每个业务用户建立相应的初始过滤规则（FC）。对于多方通话业务，业务用户的iFC应保证会话请求能够发送至相应的业务AS以进行相关的业务处理。INVITE触发规则：主叫侧S-CSCF收到业务用户发起的INVITE消息，将其发送至AS进行相关的业务处理。
HiiKAoiKAca
YD/T3034-2016
6.4业务对功能实体和信令的要求一一网络混音6.4.1用户创建一个会议
6.4.1.1业务主叫用户终端操作
当用户创建会议时，终端操作如下：a）创建Ad-hoc会议：会议创建者应建立一个初始的INVITE请求，并将INVITE请求的REQUEST-URI设置为conference-factoryURI，该URI是一个专门用来创建Ad-hoc会议的公共服务标识。用户向AS发送一个带有conference-factoryURI的INVITE请求：b）创建附带URI列表的Ad-hoc会议：若主叫用户希望会议一旦建立，其他用户就立即加入，则该用户可以在INVITE请求中附加一个用户列表，该用户列表就包括创建人希望立即邀请加入的用户。然而INVITE请求正文已经包含了SDP描述，该描述用来指明呼叫用户欲在此会议中使用的媒体。为了传输这两个正文，INVITE请求应指明自已包含了多重正文。之后用户向AS发送一个带有conference-factoryURI和URI列表的INVITE请求。
6.4.1.2S-CSCF操作
当用户创建会议时，S-CSCF操作如下：a）创建Ad-hoc会议：该INVITE请求被转发至主叫用户的S-CSCF，S-CSCF中的过滤器准则会触发相应路由，将指向conference-factoryURI的呼叫转发到AS。因此，主叫用户的S-CSCF会直接将INVITE请求发送到AS。
b）创建附带URI列表的Ad-hoc会议：该INVITE请求被转发至主叫用户的的S-CSCF，S-CSCF中的过滤器准则会触发相应路由，将指向conference-factoryURI的呼叫转发到AS。因此，主叫用户的S-CSCF会直接将INVITE请求发送到AS。6.4.1.3AS操作
当用户创建会议时，AS操作如下：a）创建Ad-hoc会议：AS收到INVITE请求后，回复用户一个200（OK）响应，在这个回复的Contact消息头中会指明会议URI。该回复还可以通过在其地址中添加“isfocus”参数来指明将该AS将作为会议的SIP锚点。
b）创建附带URI列表的Ad-hoc会议：AS收到INVITE请求后，回复用户一个200（OK）响应，在这个回复的Contact消息头中会指明会议URI。该回复还可以通过在其地址中添加“isfocus”参数来指明将该AS将作为会议的SIP锚点。之后AS根据URI-list向其他用户建立呼叫。6.4.2邀请其他用户加入一个会议6.4.2.1业务主叫用户终端操作
当邀请其他用户加入会议时，主叫终端操作如下：a）用户通过发送REFER请求给AS邀请其他用户加入会议。主叫用户设置REFER请求的REQUEST-URI为被叫用户被邀请进入的会议URI，将Refer-To消息头设为被邀请的用户的SIPURI或telURL。将Refer-To消息头中的\methodURI参数设为“INVITE”或直接省略该参数。接着主叫用户向AS发送该REFER请求，请求让被邀请的用户入会。为了避免和被邀请用户建立第二次会话，如果有一个正在进行的对话，在REFER请求Refer-to消息头的SIPURI的头部，包含Replace消息头。该Replace消息头应当参考被ad-hoc会议替代的正在进行的对话。例如：Refer-To:sip:mgcfl.homel.net；method-6
HiiKANiKAca
YD/T3034-2016
INVITE?Replaces=cb03a0s09a2sdfglkj490333%3Bto-tag%3D314159%3Bfrom-tag%3D171828&RequrieFreplaces
b）用户通过发送REFER请求给被邀请用户邀请其加入会议。主叫用户设置REFER请求的REQUEST-URI为被邀请用户的地址，将Refer-To消息头设为该会议的会议URI。将Refer-To消息头中的\method\URI参数设为“INVITE”或直接省略该参数。接着主叫用户向被邀请用户发送一个REFER请求。
6.4.2.2AS操作
当邀请其他用户加入会议时，AS操作如下：a）AS通过一个REFER请求给被邀请用户使其加入会议。AS收到主叫用户的REFER请求，检查会议URI是否被分配了。如果会议URI没有分配，AS应该拒绝该请求。如果会议URI分配了，则检查该用户是否有资格参加会议。AS既可以直接向被叫用户发送INVITE请求邀其加入会议，详见1)，也可以向被叫用户发送另一条REFER请求，以通知被叫用户建立指向AS的呼叫，详见2）。Referred-By消息头会告知被邀请的用户是哪个用户对其发出了邀请。之后AS会发送一个NOTIFY消息给发送REFER的用户。
1）AS通过发送INVITE请求邀请用户使其加入会议。AS设置INVITE请求的REQUEST-URI为被邀请用户的地址，将INVITE请求中的P-Asserted-Identity消息头设为该会议的会议URI。将Contact消息头设为该会议的会议URI，该请求包括\isfocus\参数。接着AS向被邀请用户发送一个INVITE请求。2）AS通过发送REFER请求邀请用户使其加入会议。AS设置REFER请求的REQUEST-URI为被邀请用户的地址，将REFER请求中的P-Asserted-Identity消息头设为该会议的会议URI。将REFER请求中Refer-To消息头设为该会议的会议URI，将Refer-To消息头中的\method\URI参数设为“INVITE”或直接省略该参数，接着AS向被邀请用户发送这个REFER请求。如果REFER请求的Referred-By消息头可用，AS应该检查这个Referred-By消息头是否包含了一个有效的请求用户的身份信息。如果请求中Referred-By消息头不可用，AS应该添加一个和P-Asserted-Identity消息头匹配的Referred-By消息头。b）通过创建会议时建立的URI列表邀请用户接入一个会议：一如6.4.1节所说，在接受到一个带有URI列表的INVITE请求后，AS作为存储服务器对URI列表进行存储。之后发送INVITE请求给URI列表上的SIPURI。会议的会议URI建立后AS立即对URI列表上的用户进行邀请。如果AS不能同时进行多个用户的邀请，则依次对URI列表上的用户进行邀请。一当AS是会议创建者和被邀请用户间的一个B2BUA时，如果URI列表中的URI包括一个Session-ID消息头，AS应该检查SessionID消息是否与会议锚点和会议建立者间的会话匹配。如果URI列表中的URI包括Call-ID消息头、From消息头和To消息头，那么AS应该检查CallID消息是否与会议锚点和会议建立者间的会话匹配。一如果以上参数匹配，会议锚点可能用Call-ID消息头、From消息头、To消息头和Session-ID消息头在会议错点和被邀请的用户之间的会话中发送一个re-INVITE请求，自的是连接被邀请用户接入MRFP(注：以下均为逻辑实体)。如果不匹配，会议锚点应该丢弃URI列表中组成URI的Call-ID消息头、From消息头、To消息头和Session-ID消息头。6.4.2.3业务被叫用户终端操作
当邀请其他用户加入会议时，被叫终端操作如下：YD/T3034-2016
a）被叫用户收到REFER请求。被叫用户收到REFER请求，请求中的Refer-to消息头中或包含一个设为INVITE的“method”uri参数或直接不包含该method”uri参数。之后被叫向主叫发送一个NOTIFY请求，指出其对REFER请求起作用。接着向6.4.3小节中描述的加入会议，如果接收到的REFER请求包括一个Refered-By头文件，在加入会议的INVITE请求中则加入一个Referred-by消息头。b）被叫用户收到来自服务器的INVITE请求。向6.4.3小节中描述的加入会议。6.4.3用户加入一个会议
6.4.3.1业务用户终端操作
用户设置INVITE请求的REQUEST-URI为该会议的会议URI，之后向AS发送INVITE请求6.4.3.2CSCF操作
INVITE请求到达AS所在网络的I-CSCF。I-CSCF向SLF/HSS查询请求路由的目的地址，即会议URI。HSS会直接将AS的地址回复给I-CSCF，I-CSCF将请求转发至AS地址。会话建立后，I-CSCF不再参与主叫用户的S-CSCF与AS之间的交互。6.4.3.3AS操作
AS一旦接收到了包含会议URI的INVITE请求，AS应该检查会议URI是否被分配，检查会议策略，确认主叫用户是否有资格参加该会议，以及会议现在是否处于激活状态。如果请求中有contact消息头，则将其设为会议URI。若检查通过，那么AS就像新的加入者发送如200(OK)来表明接受此呼叫。如果AS对INVITE请求产生了1xx或2xx响应，AS应该包含\isfocus\功能参数。同时AS会通过H.248/MEGACO流程来通知MRFP为该到来的呼叫预留所需的媒体资源。6.4.4用户离开一个会议
6.4.4.1从会议中移除会议参与者当用户离开会议时，终端操作如下：a）会议参与者离开一个会议。当会议参与者离开一个会议时，应该在建立的会话上发送一个BYE请求。如果会议参与者订阅了会议状态事件包则不再进行续订并让终端上的订阅计时器到期。当终端接收到服务器发送的NOTIFY请求不包含Subscription-State消息头（值设为\terminated\）时，会议参与者应该等一个执行周期，看是否能接收到一个相关的包含Subscription-State消息头（值设为\terminated\）的NOTIFY请求。如果还没有收到这样一个NOTIFY请求，则用户主动向服务器发送一个带有“Expires”（值为O）的消息头的SUBSCRIBE请求来取消订阅会议状态事件包。b）AS移除一个会议参与者。当用户收到一个从服务器发送来的BYE请求之后，尚AS发送一个200（OK）响应。如果会议参与者订阅了会议状态事件包，则不再进行续订，并让相关的订阅计时器到期。
C）从会议中移除会议参与者。如果发起者想建立一个REFER请求来从会议中移除一个会议参与者时，该发起者应该设置REFER请求的REQUEST-URI为被移除的用户所在会议的会议URI，则设置REFER请求的Refer-To消息头为被移除的会议参与者的地址，并把\method\参数设置为\BYE”。如果该会议参与者地址是一个全球telURI，它将被转换为SIPURI。如果将全部的会议参与者从会议中移除，则设置REFER请求的Refer-To消息头为会议URI，并把\method\参数设置为\BYE”。将REFER请求发送到AS，并收到来自AS的NOTIFY请求告知其移除进度。6.4.4.2AS操作
当用户离开会议时，AS操作如下：YD/T3034-2016
a）会议参与者离开一个会议。当从会议参与者处接收到一个BYE消息后，AS应该向该用户发送一个2000K响应。之后从会议混合器中释放该参与者的相关资源。b）从会议中移除一个会议参与者。AS接收到的REFER请求中包含一个会议URI和一个Refer-to消息头（包含一个有效的SIPURI和一个设为\BYE\的\method\参数。AS应该：1）先检查会议URI是否被分配了。如果会议URI没有被分配，则AS应该拒绝该请求。如果会议URI被分配了则进行下一步。
2）如果SIPURI包括一个值为\phone\的用户参数，并且Refer-To消息头中的SIPURI如果可以被转换成一个全球telURI，则将其转换为一个等价的全球telURI。检查该telURI属于当前的会议参与者。如果验证失败，则拒绝该请求。3）检查Refer-To消息头的SIPURI是否和会议URI相同或是否属于当前会议参与者。如果验证失败，则拒绝该请求。
4）检查用户身份并对该请求进行授权，只有当请求被授权时才能进行下一步操作。5）对REFER请求建立一个200OK响应。6）如果Refer-To消息头只有一个用户，则从会议中按照3)所描述的步骤删除该用户。如果Refer-Tc消息头包含会议URI，则按照3）所描述的步骤一个一个地删除所有会议参与者。7）根据移除的进度，发送一个NOTIFY消息给发送REFER请求的会议参与者。c）AS移除一个会议参与者。当从一个会议中移除一个会议参与者时，AS应该：1）使用BYE请求将与相关会议参与者的对话结束。2）从会议混合器中释放相关会议参与者的资源。6.4.5会议状态事件包
6.4.5.1业务主叫用户终端操作
每位使用SIP终端的与会者都可以订阅会议状态事件包，以获得其他与会者的更多信息。要订阅该服务，与会者需要向AS发送一条SUBSCRIBE请求，说明需要订阅会议状态事件包并指明订阅多长时间。
6.4.5.2AS操作
AS回复一条200(OK)消息，表明接受该订阅请求，从而在订阅用户与AS之间建立起一个SIP对话。随即，AS会向该用户发送一条包含目前会议状态的NOTIFY。该NOTITY消息所传输的消息有：·会议的名称：
·服务URI，在这里可以找到关于会议议题的更详细信息；·与会者的详细信息等。
一日多方通话结束或是订阅者用户离会，那么该会议状态时间服务就自动终止多方通话消息流程参见附录A。
6.5业务对功能实体和信令的要求一一终端混音（可选）用户UE-A跟UE-B正在通话，用户UE-A对用户UE-B保持通话。用户UE-A拨打用户UE-C的号码，双方通话，用户UE-A按“会议”键或进行其他操作，用户UE-A、UE-B和UE-C进入三方会议状9
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和宝玉通信行标准
YD/T3034-2016
基于统一IMS的业务技术要求
呼叫闭锁和多方通话业务（第一阶段）Technical requirementsofservicesbasedontheunified IMscommunicationbarringandMulti-Partycallservice(Release1)2016-04-05发布
2016-07-01实施www.bzxz.net
中华人民共和国工业和信息化部发布前
范围·
2规范性引用文件。
3缩略语
4终端要求
5呼叫闭锁类业务
6多方通话业务·
附录A（资料性附录）消息流程示例+目
附录B（资料性附录）拨号方式实现业务配置和管理的消息流程示例附录C（资料性附录）Ut接口方式实现业务配置示例·YD/T3034-2016
YD/T3034-2016
YD/T3034《基于统一IMS的业务技术要求呼叫闭锁和多方通话业务（第一阶段）》与《基于统IMS的业务测试方法多媒体电话业务（第一阶段）第2部分：呼叫闭锁和多方通话业务》共同构成“基于统一IMS的多媒体电话业务”系列行业标准。“基于统一IMS的多媒体电话业务”系列还包括如下标准：YD/T1932-2009《基于统一IMS的业务技术要求标识显示及限制类业务（第一阶段）》；YD/T1931-2009《基于统一IMS的业务技术要求呼叫前转类业务（第一阶段）》一YD/T2011-2009《基于统一IMS的业务技术要求呼叫等待与呼叫保持业务（第一阶段）》一YD/T2013-2009《基于统一IMS的业务技术要求恶意呼叫追踪和匿名呼叫拒绝业务（第一阶段）》
YD/T2457.1-2013《基于统一IMS的业务测试方法多媒体电话业务（第一阶段）第1部分：基本业务和必选补充业务》
一《基于统一IMS的业务技术要求呼叫闭锁和多方通话业务（第一阶段）》《基于统一IMS的业务测试方法多媒体电话业务（第一阶段）第2部分：呼叫闭锁和多方通话业务》
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中国联合网络通信集团有限公司。本标准主要起草人：魏群、吕光旭、符刚。Ⅱ
HiiKANiKAca
1范围
基于统一IMS的业务技术要求
呼叫闭锁和多方通话业务（第一阶段）YD/T3034-2016
本标准规定了基于统一IMS的呼叫闭锁业务与多方通话业务的业务描述与业务特征、业务服务终端、业务管理、业务触发、业务对功能实体和信令的要求、与其他基于统一IMS的业务间的交互作用等要求。
本标准适用于基于统一IMS的呼叫闭锁业务与多方通话业务。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。3GPP TS 29.228
3缩略语
IP多媒体子系Cx和Dx接口；信令流程和消息内容（IPMultimedia（IM）SubsystemCxandDxinterfaces;Signallingflowsandmessagecontents)下列缩略语适用于本文件。
AccessGatewayControlFunctionApplication Server
Code Devision Multiple AccessCall Session Control FunctionSubscriber Identity Module
Communication Barring
Three Party Conference
CDMASubscriberIdentityModuleCDMADigital Subscriber Line
Integrated Access Device
Initial Filter Criteria
IP Multimedia Subsystem
Integrated ServicesDigital NetworkIMS Subscriber Identity ModuleLocal Area Network
MRFController
Network Determined User BusyNext Generation Network
PlainOldTelephoneService
PublicSwitchedTelephoneNetwork接入网关控制器
应用服务器
码分多址接入
呼叫会话控制功能
客户识别模块
呼叫闭锁
三方通话
用户识别模块
数字用户线路
综合接入设备
初始过滤规则
IP多媒体子系统
综合业务数字网
IMS用户识别模块
局域网
多媒体资源控制器
网络决定用户忙
下一代网络
模拟电话业务
公共电话交换网
HiiKAoiKAca
YD/T3034-2016
S-CSCF
4终端要求
Removable User Identity ModuleServing Call Session Control FunctionSubscriber Identity Module
Session Initiation Protocol
User Determined User Busy
Uniform ResourceIdentifier
Wireless Local Area Network
XML Configuration Access ProtocolExtensible Markup Language
可移动用户识别模块
服务呼叫会话控制功能
用户识别模块
会话初始协议
用户决定用户忙
统一资源标识符
无线局域网
XML配置接入协议
可扩展标记语言
基于统一IMS的呼叫闭锁业务及多方通话业务可服务于以下终端：·SIP硬终端（指支持SIP协议并且通过xDSL、WLAN、LAN接入IMS域的终端。该类型终端具有一定的物理形态，暂不要求具备ISIM卡）：·SIP软终端（指支持SIP协议并且通过xDSL、WLAN、LAN接入IMS域的一种软件客户端，通常安装在个人PC等设备上。此类型终端可以具备或不具备ISIM卡）；·移动终端（指支持SIP协议并且通过2G、3G、LTE接入IMS域的移动终端。此类型终端要求具备SIM卡/USIM卡/ISIM卡/R-UIM卡/CSIM卡，但对于cdma2000机卡合一终端，可以不具备物理实体的R-UIM卡/CSIM卡）
·SIPPON/IAD：支持SIP协议的综合接入设备，其上行端口接入IMS网络，下行提供端口连接多个模拟话机，用来提供传统POTS终端的接入。·H.248PON/IAD/AG：支持H.248协议的综合接入设备，其上行端口接入AGCF，下行提供端口连接多个模拟话机，用来提供传统POTS终端的接入。对于使用2G、3G和LTE接入方式的移动终端，要求终端具备UICC卡，可以包含SIM/USIM/ISIM；对于SIP软终端，可以具备或不具备ISIM卡；对于SIP硬终端和SIPIAD，暂不要求具备ISIM卡。
5呼叫闭锁类业务
5.1业务描述与业务特征
呼叫闭锁类业务包括呼叫限制和运营商闭锁两部分：●呼叫限制业务允许用户和运营商根据号码、媒体类型、时间等，设置限制用户呼出或呼入。例如，国内长途、国际长途呼叫限制。定制了国内长途限制业务的用户，如果进行国内长途呼叫，呼叫会被终止并听到国内长途呼叫限制提示音：定制了国际长途限制业务的用户，如果进行国际长途呼叫，呼叫会被终止并听到国际长途呼叫限制提示音；●运营商闭锁是指运营商能够对用户设置呼入或呼出闭锁。设置呼入闭锁，用户无法接听电话：设置呼出闭锁时，用户无法拨出电话，并听到限制提示音。例如，用户欠费时，运营商可以闭锁其所有呼出业务。
基于IMS的呼叫闭锁类业务至少要继承固网和移动网的闭锁业务，支持多种条件的闭锁。对于服务2
HiiKAoiKAca
器所具备的放音等媒体处理控制功能均由MRFC完成，以下AS均包含该部分功能。5.2业务管理
5.2.1概述
YD/T3034-2016
用户可以通过多种方式来对自已的呼叫闭锁业务进行配置和管理，主要包括终端拨号方式、Ut接口方式、基于SIP的用户配置等。其中，网络和终端至少应支持拨号方式和Ut接口方式。当用户通过不同的方式对业务数据进行配置时，最新的业务配置应覆盖之前的业务配置。业务配置和管理的内容主要包括：对业务进行激活和去激活操作，查询业务状态，设置配置规则等。对于拨号方式，具体业务配置和管理的编号可依据业务运营者的应用需求而定，不在此进行标准化，其拨号程序见5.2.2。对于Ut接口方式，具体业务配置和管理的操作和界面等可依据具体应用需求而定不在此进行详述。
5.2.2终端拨号方式
终端拨号实现流程参见附录B。
终端拨号程序例如：
·激活：用户激活该业务时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知；则结束挂机：
·去激活：用户去激活该业务时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知；则结束挂机：
·业务状态查询：用户查询该业务状态时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知：则结束挂机。
5.2.3Ut接口方式
呼叫闭锁类业务可以通过Ut接口进行设置和查询，具体方式示例见附录C。5.3业务触发
为了保证业务的正常实现，HSS应为每个业务用户建立相应的初始过滤规则（iFC）。对于呼叫闭锁业务，业务用户的FC应保证会话请求能够发送至相应的业务AS以进行相关的业务处理。INVITE触发规则：
·主叫侧S-CSCF收到业务用户发起的INVITE消息，将其发送至呼叫闭锁业务AS进行相关的业务处理。
·被叫侧S-CSCF收到业务用户发起的INVITE消息，将其发送至呼叫闭锁业务AS进行相关的业务处理。
5.4业务对功能实体和信令的要求5.4.1呼出闭锁业务对功能实体和信令的要求5.4.1.1主叫终端操作
将INVITE请求发送至主叫端呼出闭锁AS，基于IMS标准流程，5.4.1.2呼出闭锁AS操作
当主叫用户的呼出闭锁策略为（allow=“false”时），AS提供的呼出闭锁业务应该拒绝呼出来电。呼出闭锁机制为呼出闭锁服务器将用户携带的INVITE信息和用户配置的参数进行比较，看是否一致。
HiiKAoiKAca
YD/T3034-2016
根据号码进行呼出闭锁时，为了实现呼出闭锁的的目的，AS应将“cp：identity”，“ocp：extermal-list\条件和从Request-URI或额外从To消息头部分得到的被叫方信息进行对比，如果对比结果一致，则实现呼出闭锁。
根据在线状态实现呼出闭锁时，将“presence-status”条件和被叫用户的当前显示状态进行对比，如果对比结果一致，则实现呼出闭锁。根据媒体类型实现呼出闭锁时，将“media”条件和主叫用户INVITE请求中的media部分进行对比，如果对比结果一致，则实现呼出闭锁。根据时间实现呼出闭锁时，将“cp:validity”条件和当前时间进行对比，如果当前时间在设置的“cp:validity”条件范围内，则实现呼出闭锁。当AS提供呼出闭锁服务阻止一个通信时，AS应该向正在呼叫的用户发送一个603（decline）/403(fobbiden)响应或者向用户发送一个487（录音通知）响应来告知其呼叫被拒绝。呼出闭锁消息流程参见附录A。
5.4.2呼入闭锁业务对功能实体和信令的要求5.4.2.1业务主叫终端操作
将该INVITE请求发送至被叫端呼入闭锁AS，基于IMS标准流程。5.4.2.2呼入闭锁AS操作
当被服务用户的呼入闭锁策略为（allow=“false”时），AS提供的呼入闭锁业务应该拒绝呼入来电。呼入闭锁机制为呼入闭锁服务器将用户收到的INVITE信息和用户配置的参数进行比较，看是否一致。
根据号码实现呼入闭锁时，为了实现呼入闭锁的的目的，AS应该将“cp：identity”，“ocp：external-list”条件和P-Asserted-Identity头字段中的主叫用户标识信息或Referred-By头字段或From头字段的用户标识信息进行对比，如果对比结果一致，则实现呼入闭锁。根据媒体类型实现呼入闭锁时，将“media”条件和主叫用户INVITE请求中的media部分进行对比，如果对比结果一致，则实现呼入闭锁。根据时间实现呼入闭锁时，将“cp:validity”条件和当前时间进行对比，如果当前时间在设置的“cp:validity”条件范围内，则实现呼入闭锁。当AS提供呼入闭锁服务阻止一个通信时，AS应该向正在呼叫的用户发送一个603（decline）/403(forbidden)响应或者向用户发送一个487（录音通知）响应来告知其呼叫被拒绝。呼入闭锁消息流程参见附录A
5.5与其他基于统一IMS的业务间的交互作用5.5.1呼叫等待业务
呼叫等待业务与呼叫闭锁业务签约时无冲突关系。用户同时签约呼叫等待业务与呼入闭锁，呼叫闭锁优先于呼叫等待。
5.5.2呼叫前转类业务
呼转类业务与闭锁业务签约时无冲突关系。如果用户B激活了呼出限制到C，那么B将无法前转呼叫到C。如果用户A呼叫B，B签约前转到C，B对A进行了呼入限制，那么B将无法前转呼叫到C，即呼叫闭锁业务优先于前转。
HiiKAoNiKAca
5.5.3彩铃业务
YD/T3034-2016
彩铃与呼叫闭锁业务业务签约时无冲突关系，如果用户签约了呼入限制的情况下，则先进行限呼处理，将不会播放用户的彩铃。
5.5.4彩像业务
彩像与呼叫闭锁业务业务签约时无冲突关系，如果用户签约了呼出限制的情况下，则先进行限呼处理，将不会发送用户的彩像。
5.5.5多方通话
多方通话业务与呼叫闭锁业务签约时无冲突关系。用户同时签约多方通话业务与呼入闭锁，呼叫闭锁优先于多方通话。如果Refer-To的被叫用户被会议创始者的呼出闭锁规则屏蔽了，则AS不应该接受该REFER请求。AS应该移除掉URI列表中被呼出屏蔽掉了的用户的URI。建立的多方通话中不包括被屏蔽的用户。
6多方通话业务
6.1业务描述与业务特征
本业务允许多于两个用户同时进行语音/视频通话，支持终端混音方式和网络混音方式。其中终端混音对网络没有要求。
对于服务器所具备的混音等媒体处理控制功能均由MRFC完成，以下AS均包含该部分功能。6.2业务管理
6.2.1概述
用户可以通过多种方式来对自已的多方通话业务进行配置和管理，主要包括终端拨号方式、Web方式等。其中，网络和终端至少应支持拨号方式。当用户通过不同的方式对业务数据进行配置时，最新的业务配置应覆盖之前的业务配置业务配置和管理的内容主要包括：对业务进行激活和去激活操作，查询业务状态，设置配置规则等。6.2.2终端拨号方式
多方通话（终端混音）主要由终端实现，没有相关业务管理操作。多方通话（网络混音）终端拨号方式如下：·激活：用户激活该业务时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知；则结束挂机。
·去激活：用户去激活该业务时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知：则结束挂机。
●业务状态查询：用户查询该业务状态时，需按键输入“相关业务码”：响应，如用户听到相应的录音通知；则结束挂机。
6.3业务触发
终端混音：没有多方通话的过滤规则，者作普通会话处理。网络混音：为了保证业务的正常实现，HSS应为每个业务用户建立相应的初始过滤规则（FC）。对于多方通话业务，业务用户的iFC应保证会话请求能够发送至相应的业务AS以进行相关的业务处理。INVITE触发规则：主叫侧S-CSCF收到业务用户发起的INVITE消息，将其发送至AS进行相关的业务处理。
HiiKAoiKAca
YD/T3034-2016
6.4业务对功能实体和信令的要求一一网络混音6.4.1用户创建一个会议
6.4.1.1业务主叫用户终端操作
当用户创建会议时，终端操作如下：a）创建Ad-hoc会议：会议创建者应建立一个初始的INVITE请求，并将INVITE请求的REQUEST-URI设置为conference-factoryURI，该URI是一个专门用来创建Ad-hoc会议的公共服务标识。用户向AS发送一个带有conference-factoryURI的INVITE请求：b）创建附带URI列表的Ad-hoc会议：若主叫用户希望会议一旦建立，其他用户就立即加入，则该用户可以在INVITE请求中附加一个用户列表，该用户列表就包括创建人希望立即邀请加入的用户。然而INVITE请求正文已经包含了SDP描述，该描述用来指明呼叫用户欲在此会议中使用的媒体。为了传输这两个正文，INVITE请求应指明自已包含了多重正文。之后用户向AS发送一个带有conference-factoryURI和URI列表的INVITE请求。
6.4.1.2S-CSCF操作
当用户创建会议时，S-CSCF操作如下：a）创建Ad-hoc会议：该INVITE请求被转发至主叫用户的S-CSCF，S-CSCF中的过滤器准则会触发相应路由，将指向conference-factoryURI的呼叫转发到AS。因此，主叫用户的S-CSCF会直接将INVITE请求发送到AS。
b）创建附带URI列表的Ad-hoc会议：该INVITE请求被转发至主叫用户的的S-CSCF，S-CSCF中的过滤器准则会触发相应路由，将指向conference-factoryURI的呼叫转发到AS。因此，主叫用户的S-CSCF会直接将INVITE请求发送到AS。6.4.1.3AS操作
当用户创建会议时，AS操作如下：a）创建Ad-hoc会议：AS收到INVITE请求后，回复用户一个200（OK）响应，在这个回复的Contact消息头中会指明会议URI。该回复还可以通过在其地址中添加“isfocus”参数来指明将该AS将作为会议的SIP锚点。
b）创建附带URI列表的Ad-hoc会议：AS收到INVITE请求后，回复用户一个200（OK）响应，在这个回复的Contact消息头中会指明会议URI。该回复还可以通过在其地址中添加“isfocus”参数来指明将该AS将作为会议的SIP锚点。之后AS根据URI-list向其他用户建立呼叫。6.4.2邀请其他用户加入一个会议6.4.2.1业务主叫用户终端操作
当邀请其他用户加入会议时，主叫终端操作如下：a）用户通过发送REFER请求给AS邀请其他用户加入会议。主叫用户设置REFER请求的REQUEST-URI为被叫用户被邀请进入的会议URI，将Refer-To消息头设为被邀请的用户的SIPURI或telURL。将Refer-To消息头中的\methodURI参数设为“INVITE”或直接省略该参数。接着主叫用户向AS发送该REFER请求，请求让被邀请的用户入会。为了避免和被邀请用户建立第二次会话，如果有一个正在进行的对话，在REFER请求Refer-to消息头的SIPURI的头部，包含Replace消息头。该Replace消息头应当参考被ad-hoc会议替代的正在进行的对话。例如：Refer-To:sip:mgcfl.homel.net；method-6
HiiKANiKAca
YD/T3034-2016
INVITE?Replaces=cb03a0s09a2sdfglkj490333%3Bto-tag%3D314159%3Bfrom-tag%3D171828&RequrieFreplaces
b）用户通过发送REFER请求给被邀请用户邀请其加入会议。主叫用户设置REFER请求的REQUEST-URI为被邀请用户的地址，将Refer-To消息头设为该会议的会议URI。将Refer-To消息头中的\method\URI参数设为“INVITE”或直接省略该参数。接着主叫用户向被邀请用户发送一个REFER请求。
6.4.2.2AS操作
当邀请其他用户加入会议时，AS操作如下：a）AS通过一个REFER请求给被邀请用户使其加入会议。AS收到主叫用户的REFER请求，检查会议URI是否被分配了。如果会议URI没有分配，AS应该拒绝该请求。如果会议URI分配了，则检查该用户是否有资格参加会议。AS既可以直接向被叫用户发送INVITE请求邀其加入会议，详见1)，也可以向被叫用户发送另一条REFER请求，以通知被叫用户建立指向AS的呼叫，详见2）。Referred-By消息头会告知被邀请的用户是哪个用户对其发出了邀请。之后AS会发送一个NOTIFY消息给发送REFER的用户。
1）AS通过发送INVITE请求邀请用户使其加入会议。AS设置INVITE请求的REQUEST-URI为被邀请用户的地址，将INVITE请求中的P-Asserted-Identity消息头设为该会议的会议URI。将Contact消息头设为该会议的会议URI，该请求包括\isfocus\参数。接着AS向被邀请用户发送一个INVITE请求。2）AS通过发送REFER请求邀请用户使其加入会议。AS设置REFER请求的REQUEST-URI为被邀请用户的地址，将REFER请求中的P-Asserted-Identity消息头设为该会议的会议URI。将REFER请求中Refer-To消息头设为该会议的会议URI，将Refer-To消息头中的\method\URI参数设为“INVITE”或直接省略该参数，接着AS向被邀请用户发送这个REFER请求。如果REFER请求的Referred-By消息头可用，AS应该检查这个Referred-By消息头是否包含了一个有效的请求用户的身份信息。如果请求中Referred-By消息头不可用，AS应该添加一个和P-Asserted-Identity消息头匹配的Referred-By消息头。b）通过创建会议时建立的URI列表邀请用户接入一个会议：一如6.4.1节所说，在接受到一个带有URI列表的INVITE请求后，AS作为存储服务器对URI列表进行存储。之后发送INVITE请求给URI列表上的SIPURI。会议的会议URI建立后AS立即对URI列表上的用户进行邀请。如果AS不能同时进行多个用户的邀请，则依次对URI列表上的用户进行邀请。一当AS是会议创建者和被邀请用户间的一个B2BUA时，如果URI列表中的URI包括一个Session-ID消息头，AS应该检查SessionID消息是否与会议锚点和会议建立者间的会话匹配。如果URI列表中的URI包括Call-ID消息头、From消息头和To消息头，那么AS应该检查CallID消息是否与会议锚点和会议建立者间的会话匹配。一如果以上参数匹配，会议锚点可能用Call-ID消息头、From消息头、To消息头和Session-ID消息头在会议错点和被邀请的用户之间的会话中发送一个re-INVITE请求，自的是连接被邀请用户接入MRFP(注：以下均为逻辑实体)。如果不匹配，会议锚点应该丢弃URI列表中组成URI的Call-ID消息头、From消息头、To消息头和Session-ID消息头。6.4.2.3业务被叫用户终端操作
当邀请其他用户加入会议时，被叫终端操作如下：YD/T3034-2016
a）被叫用户收到REFER请求。被叫用户收到REFER请求，请求中的Refer-to消息头中或包含一个设为INVITE的“method”uri参数或直接不包含该method”uri参数。之后被叫向主叫发送一个NOTIFY请求，指出其对REFER请求起作用。接着向6.4.3小节中描述的加入会议，如果接收到的REFER请求包括一个Refered-By头文件，在加入会议的INVITE请求中则加入一个Referred-by消息头。b）被叫用户收到来自服务器的INVITE请求。向6.4.3小节中描述的加入会议。6.4.3用户加入一个会议
6.4.3.1业务用户终端操作
用户设置INVITE请求的REQUEST-URI为该会议的会议URI，之后向AS发送INVITE请求6.4.3.2CSCF操作
INVITE请求到达AS所在网络的I-CSCF。I-CSCF向SLF/HSS查询请求路由的目的地址，即会议URI。HSS会直接将AS的地址回复给I-CSCF，I-CSCF将请求转发至AS地址。会话建立后，I-CSCF不再参与主叫用户的S-CSCF与AS之间的交互。6.4.3.3AS操作
AS一旦接收到了包含会议URI的INVITE请求，AS应该检查会议URI是否被分配，检查会议策略，确认主叫用户是否有资格参加该会议，以及会议现在是否处于激活状态。如果请求中有contact消息头，则将其设为会议URI。若检查通过，那么AS就像新的加入者发送如200(OK)来表明接受此呼叫。如果AS对INVITE请求产生了1xx或2xx响应，AS应该包含\isfocus\功能参数。同时AS会通过H.248/MEGACO流程来通知MRFP为该到来的呼叫预留所需的媒体资源。6.4.4用户离开一个会议
6.4.4.1从会议中移除会议参与者当用户离开会议时，终端操作如下：a）会议参与者离开一个会议。当会议参与者离开一个会议时，应该在建立的会话上发送一个BYE请求。如果会议参与者订阅了会议状态事件包则不再进行续订并让终端上的订阅计时器到期。当终端接收到服务器发送的NOTIFY请求不包含Subscription-State消息头（值设为\terminated\）时，会议参与者应该等一个执行周期，看是否能接收到一个相关的包含Subscription-State消息头（值设为\terminated\）的NOTIFY请求。如果还没有收到这样一个NOTIFY请求，则用户主动向服务器发送一个带有“Expires”（值为O）的消息头的SUBSCRIBE请求来取消订阅会议状态事件包。b）AS移除一个会议参与者。当用户收到一个从服务器发送来的BYE请求之后，尚AS发送一个200（OK）响应。如果会议参与者订阅了会议状态事件包，则不再进行续订，并让相关的订阅计时器到期。
C）从会议中移除会议参与者。如果发起者想建立一个REFER请求来从会议中移除一个会议参与者时，该发起者应该设置REFER请求的REQUEST-URI为被移除的用户所在会议的会议URI，则设置REFER请求的Refer-To消息头为被移除的会议参与者的地址，并把\method\参数设置为\BYE”。如果该会议参与者地址是一个全球telURI，它将被转换为SIPURI。如果将全部的会议参与者从会议中移除，则设置REFER请求的Refer-To消息头为会议URI，并把\method\参数设置为\BYE”。将REFER请求发送到AS，并收到来自AS的NOTIFY请求告知其移除进度。6.4.4.2AS操作
当用户离开会议时，AS操作如下：YD/T3034-2016
a）会议参与者离开一个会议。当从会议参与者处接收到一个BYE消息后，AS应该向该用户发送一个2000K响应。之后从会议混合器中释放该参与者的相关资源。b）从会议中移除一个会议参与者。AS接收到的REFER请求中包含一个会议URI和一个Refer-to消息头（包含一个有效的SIPURI和一个设为\BYE\的\method\参数。AS应该：1）先检查会议URI是否被分配了。如果会议URI没有被分配，则AS应该拒绝该请求。如果会议URI被分配了则进行下一步。
2）如果SIPURI包括一个值为\phone\的用户参数，并且Refer-To消息头中的SIPURI如果可以被转换成一个全球telURI，则将其转换为一个等价的全球telURI。检查该telURI属于当前的会议参与者。如果验证失败，则拒绝该请求。3）检查Refer-To消息头的SIPURI是否和会议URI相同或是否属于当前会议参与者。如果验证失败，则拒绝该请求。
4）检查用户身份并对该请求进行授权，只有当请求被授权时才能进行下一步操作。5）对REFER请求建立一个200OK响应。6）如果Refer-To消息头只有一个用户，则从会议中按照3)所描述的步骤删除该用户。如果Refer-Tc消息头包含会议URI，则按照3）所描述的步骤一个一个地删除所有会议参与者。7）根据移除的进度，发送一个NOTIFY消息给发送REFER请求的会议参与者。c）AS移除一个会议参与者。当从一个会议中移除一个会议参与者时，AS应该：1）使用BYE请求将与相关会议参与者的对话结束。2）从会议混合器中释放相关会议参与者的资源。6.4.5会议状态事件包
6.4.5.1业务主叫用户终端操作
每位使用SIP终端的与会者都可以订阅会议状态事件包，以获得其他与会者的更多信息。要订阅该服务，与会者需要向AS发送一条SUBSCRIBE请求，说明需要订阅会议状态事件包并指明订阅多长时间。
6.4.5.2AS操作
AS回复一条200(OK)消息，表明接受该订阅请求，从而在订阅用户与AS之间建立起一个SIP对话。随即，AS会向该用户发送一条包含目前会议状态的NOTIFY。该NOTITY消息所传输的消息有：·会议的名称：
·服务URI，在这里可以找到关于会议议题的更详细信息；·与会者的详细信息等。
一日多方通话结束或是订阅者用户离会，那么该会议状态时间服务就自动终止多方通话消息流程参见附录A。
6.5业务对功能实体和信令的要求一一终端混音（可选）用户UE-A跟UE-B正在通话，用户UE-A对用户UE-B保持通话。用户UE-A拨打用户UE-C的号码，双方通话，用户UE-A按“会议”键或进行其他操作，用户UE-A、UE-B和UE-C进入三方会议状9
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。