《中国移动CM-IMSSIP技术规范第4部分CM-IMS业务对SIP的要求V100资料.doc》由会员分享，可在线阅读，更多相关《中国移动CM-IMSSIP技术规范第4部分CM-IMS业务对SIP的要求V100资料.doc（16页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、Good is good, but better carries it.精益求精，善益求善。中国移动CM-IMSSIP技术规范第4部分CM-IMS业务对SIP的要求V100-中国移动通信企业标准QB-C-018.4-2011中国移动CM-IMS会话初始协议（SIP）技术规范第四部分：CM-IMS业务对SIP的要求CM-IMSSpecificationsofSessionInitiationProtocol(SIP)Part4:SIPRequirementsofCM-IMSServicesSIPProtocol版本号：1.0.02011-7-27实施2011-7-27发布中国移动通信集团公司发布
2、-目录前言II1.范围12.规范性引用文件13.术语、定义和缩略语14.概述25.CM-IMS业务对SIP消息头域及参数的要求35.1.From头域35.1.1.业务需求35.1.2.使用方式35.2.Privacy头域35.2.1.业务需求35.2.2.使用方式35.3.History-Info头域45.3.1.业务需求45.3.2.使用方式45.4.Alert-Info头域45.4.1.业务需求45.4.2.使用方式56.CM-IMS业务对SIP信令流程的要求56.1.前转流程56.1.1.业务需求56.1.2.流程描述及使用方式56.2.等待流程66.2.1.业务需求66.2.2.流程描
3、述及使用方式66.3.早媒体协商流程76.3.1.业务需求76.3.2.流程描述及使用方式76.4.REFER流程86.4.1.业务需求86.4.2.流程描述及使用方式86.5.INFO流程96.5.1.业务需求96.5.2.流程描述及使用方式96.6.没有媒体成分的媒体协商流程106.6.1.业务需求106.6.2.流程描述及使用方式107.CM-IMS业务对SIP协议的扩展原则108.编制历史11前言本标准依据IETF、3GPP以及ITU-T制定的相关标准，结合有关国内标准和中国移动相关企业标准，基于中国移动CM-IMS总体技术要求和实际需求而拟定，充分考虑了网络的平滑演进能力，为中国移动
4、CM-IMS的技术试验、网络建设和运行维护提供技术依据。本标准规定了中国移动IMS网络及业务对会话初始协议(SIP)的定制化需求。本标准是CM-IMS会话初始协议（SIP）系列标准之一，该系列标准的结构、名称或预计的名称如下：序号标准编号标准名称1QB-C-018.1-2011中国移动CM-IMS会话初始协议（SIP）规范第1部分：SIP的总体要求2QB-C-018.2-2011中国移动CM-IMS会话初始协议（SIP）规范第2部分：SIP的消息3QB-C-018.3-2011中国移动CM-IMS会话初始协议（SIP）规范第3部分：SIP的基本流程4QB-C-018.4-2011中国移动CM-
5、IMS会话初始协议（SIP）规范第4部分：CM-IMS业务对SIP的要求5QB-C-018.5-2011中国移动CM-IMS会话初始协议（SIP）规范第5部分：SIP与BICC/ISUP的互通本标准由中移技2011220号印发。本标准由中国移动通信集团公司计划建设部提出，集团公司技术部归口。本标准起草单位：中国移动通信研究院本标准主要起草人：宋月陈旭孙强1. 范围本标准规定了中国移动IMS网络及业务对会话初始协议(SIP)的定制化需求，供中国移动内部和厂商共同使用；适用于中国移动CM-IMS中包括Gm、Mw、ISC、Mg、Mj在内的所有SIP接口；适用于中国移动CM-IMS核心网设备、接入设备
6、及终端设备的研发、引入和运行维护。2. 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。序号标准编号标准名称发布单位1中国移动CM-IMS统一Centrex业务总体技术要求中国移动通信集团公司2中国移动CM-IMS多媒体电话业务总体技术要求中国移动通信集团公司3中国移动CM-IMS多媒体彩铃业务总体技术要求中国移动通信集团公司4中国移动CM-IMS融合一号通总体技术要求中国移动
7、通信集团公司3. 术语、定义和缩略语下列术语、定义和缩略语适用于本标准：词语解释B2BUA背靠背用户代理（B2BUA）是一个逻辑功能实体，它作为UAS接收请求消息并处理该消息，同时也作为UAC来发送请求消息，B2BUA也可分别作为UAC发起两个会话.B2BUA需要维护两个会话的对应关系CPIMCommonPresenceandInstantMessaging，参加RFC3862FQDNFullQualifiedDomainName，全称域名GRUUGloballyRoutableUseragentURI，全局可路由用户代理标识iFCInitialFilterCriteria，初始过滤规则IMP
8、IIMSPrivateIdentity，IMS用户私有标识IMPUIMSPublicIdentity，IMS用户公有标识IPSec一种开放标准的框架结构，通过使用加密的安全服务以确保在IP网络上进行保密而安全的通讯PLMNPublicLandMobileNetwork，公共移动电话网ProxySIP逻辑实体，用于转发SIP消息PSIPublicServiceIdentity，公共业务标识PSTNPublicSwitchedTelephoneNetwork，公共交换电话网SASecurityAssociation，安全关联SDPSessionDescriptionProtocol，会话描述协议T
9、LSTransportLayerSecurity，传输层安全UA用户代理，SIP逻辑实体，是SIP消息的发起和终结方UAC用户代理客户端，SIP逻辑实体，产生SIP请求消息，并终结SIP响应消息。UAS用户代理服务器，SIP逻辑实体，终结SIP请求消息，并返回SIP响应消息。UEUserEquipment，用户设备URIUniformResourceIdentifier，统一资源标识符XMLeXtensibleMarkupLanguage，可扩展标记语言对话对话是两个UA之间持续一段时间的点对点的SIP连接，它使UA之间的消息变得有序，同时给出请求消息的正确的路由会话会话是通信参与方及它们之间
10、的媒体流的集合4. 概述CM-IMS为用户提供丰富的多媒体通信业务，包括多媒体电话业务、Centrex、多媒体彩铃、一号通多媒体彩铃、即时消息、点击拨号等。本部分根据CM-IMS业务规范系统梳理了现有业务对于SIP消息、头域以及信令流程提出的定制化需求，重点说明了各项要求满足的业务需求及其使用方式。本部分内容为CM-IMS业务流程设计提供了常用SIP头域使用方式及通用SIP流程。本部分明确了业务开发阶段的业务流程设计中，应根据业务需求充分考虑应用已纳入本规范的定制化要求，并提出SIP协议扩展应遵循的原则。5. CM-IMS业务对SIP消息头域及参数的要求5.1. From头域5.1.1. 业务
11、需求CM-IMS业务中包含号码显示特性，如主叫号码显示、号码显示限制、群内呼叫显示短号等。在国际规范的描述中使用P-Asserted-Identity头域进行主叫号码显示。P-Asserted-Identity头域用于网络对用户身份的标识，其内容必须是准确的、已经进行过注册的用户公有身份标识，考虑到CM-IMS业务中的号码显示逻辑比较复杂，显示内容也不全是合法的用户公有身份标识，因此CM-IMS中不能使用P-Asserted-Identity头域进行号码显示。From头域中的URI部分不用于会话路由，也不用于标识用户身份，其内容可以根据需要进行修改，因此CM-IMS使用From头域进行主叫号码
12、显示。5.1.2. 使用方式使用From头域的URI参数进行号码显示(display-name参数不用于号码显示），其内容可以是SIPURI也可以是TelURI，如：From:From:在进行主叫号码显示限制业务时，From头域内容需要表示匿名，其格式为：From:”Anonymous”其他号码显示类业务须参照本部分要求进行实现。5.2. Privacy头域5.2.1. 业务需求CM-IMS网络会提供一些匿名类业务，如主叫号码显示限制业务。在进行这类业务时，需要向被叫UE隐藏能揭示主叫用户身份的SIP消息头域和参数，如From、P-Asserted-Identity，因此需要有一种机制指示后续
13、网元将上述头域进行隐藏。5.2.2. 使用方式CM-IMS使用Priavcy头域表示匿名类业务。需要进行主叫号码显示限制时，在INVITE消息中添加Privacy头域，该头域取值为”id”，如：Privacy:id在主叫号码显示限制流程中，主叫AS在INVITE消息中添加”privacy:id”，同时将From头域修改为5.1.2中描述的匿名形式；被叫P-CSCF收到包含”privacy:id”的INVITE消息后将P-Asserted-Identity头删除。其他匿名类业务须参照本部分要求实现。5.3. History-Info头域5.3.1. 业务需求在一些CM-IMS业务场景中，呼叫在到
14、达最终的被叫之前会经过一些中间用户，如呼叫前转业务。为了业务逻辑的实现以及话务统计的需要，要求SIP协议能够记录呼叫到达最终被叫的路径和原因。RFC4244定义History-Info头域用于记录呼叫历史信息，CM-IMS使用History-Info头域实现上述功能。5.3.2. 使用方式History-Info头域的格式参见CM-IMS会话初始协议第2部分。不同业务场景中History-Info头域的使用方法如下：l 前转类业务如果本次前转为第一次前转（INVITE消息中不包含History-Info头域），AS应在INVITE消息中插入History-Info头域，并包含两个hi-entr
15、y条目：u 第一个hi-entry条目的hi-targeted-to-uri参数为初始被叫的URI；u 第二个hi-entry条目的hi-targeted-to-uri参数为前转目的地的URI，cause参数为相应的前转原因代码。如果本次前转不是第一次前转，AS应在History-Info头域中插入一个hi-entry条目，其中hi-targeted-to-uri参数为前转目的地的URI，cause参数为相应的前转原因代码。不同前转业务场景下hi-entry条目中cause参数对应的原因代码如下表所示：表5-1cause参数的原因代码前转类型原因代码无条件前转302遇忙前转486无应答前转40
16、8未注册前转404其他使用History-Info头域的业务须参照本部分要求实现。5.4. Alert-Info头域5.4.1. 业务需求在提供铃音类业务时有两种方式实现：一种是网络侧为用户播放定制铃音，另一种是终端自行播放特定的铃音。当采用第二种方式时，需要SIP消息能够指示终端需要播放的铃音。CM-IMS采用Alert-Info头域携带终端需要播放的铃音信息。5.4.2. 使用方式Alert-Info头域格式参见CM-IMS会话初始协议第2部分。Alert-Info头域中的URL参数为终端需要播放的媒体资源地址。在向被叫用户播放定制的振铃音时，需要在初始INVITE消息中包含Alert-I
17、nfo头域；在向主叫用户播放定制的回铃音时，需要在180响应中包含Alert-Info头域。在进行群内外区别振铃业务时，需要在Alert-Info头域中添加info参数，该参数取值为alert-internal表示群内，或者为alert-external表示群外。6. CM-IMS业务对SIP信令流程的要求6.1. 前转流程6.1.1. 业务需求CM-IMS提供多种前转类业务，在发生前转时，有必要通知主叫网络及终端本次呼叫正在被前转，采用播放提示音的方式不能被网络及终端设备识别，因此需要在SIP消息中表明发生前转。6.1.2. 流程描述及使用方式CM-IMS使用181响应通知呼叫被前转，流程如
18、图6-1所示：图6-1前转流程触发前转流程时，若已经与初始被叫建立earlydialog，则需要将该对话结束。结束对话的方式可以是被叫UE直接返回4xx响应（如流程4a所示），也可以是网络侧主动发CANCEL请求结束对话（如流程4b所示）。之后被叫侧向主叫返回181Forwarding响应。消息7与消息2（前转前后的INVITE消息）中的route头含有相同的OriginDialogID参数。在进行前转类业务时，应参照上述方式通知主叫侧呼叫发生前转。6.2. 等待流程6.2.1. 业务需求在一些业务场景中，当被叫用户处在通话状态时有新的呼叫呼入，此时需要将该呼叫放入等待队列中，典型业务为呼叫等
19、待业务。在进行这类业务时，需要通知主叫网络及终端本次呼叫被加入等待队列，因此需要在SIP消息中表明呼叫正在等待状态。6.2.2. 流程描述及使用方式CM-IMS使用182Queued响应消息通知呼叫正处于等待状态，流程如图6-2所示：图6-2等待流程在进行呼叫等待业务时，被叫业务在通话过程中收到新的呼叫后应返回182Queued响应，返回该响应后被叫终端仍可以返回180响应。6.3. 早媒体协商流程6.3.1. 业务需求在很多业务场景中，需要为用户提供早媒体，即在呼叫最终建立之前终端能够与网络进行临时的媒体交互。典型应用场景有彩铃业务、呼叫建立前向用户播放提示音等。因此SIP协议应支持早媒体协
20、商流程，同时在呼叫建立后切换至实际通话媒体。6.3.2. 流程描述及使用方式CM-IMS中使用18x临时响应进行早媒体协商，使用UPDATE流程进行呼叫建立前的媒体切换，如图6-3所示：图6-3早媒体协商流程消息1：初始INVITE消息携带主叫SDP；消息2：若需要建立早媒体则被叫侧通过18x临时响应携带响应的SDP完成媒体协商，由于该18x响应携带SDP，因此需要保证可靠传输，18x消息中包含”require：100rel”消息34：主叫对消息2进行确认消息58：被叫应答后，通过UPDATE流程进行第二次媒体协商将媒体切换至实际通话媒体，媒体协商完成后被叫侧返回对初始INVITE请求的200
21、OK响应。若早媒体播放后需要直接结束对话，则可在媒体播放完成后返回4xx响应，如图6-4所示：图6-4早媒体播放后直接结束对话早媒体流程用于所有需要建立早媒体的业务场景，这类业务的实现须参照本部分规定。6.4. REFER流程6.4.1. 业务需求在一些业务场景中需要通知对方对第三方进行会话控制，如会议业务中要求添加或删除与会者、呼叫转接业务等。SIP协议采用REFER请求消息实现这类功能。6.4.2. 流程描述及使用方式REFER消息流程如图6-5所示：图6-5RERER流程REFER消息可以在INVITE消息建立的对话内发送，也可以在对话外发送，当REFER消息在对话外发送时REFER消息
22、本身会建立一个对话。REFER消息中包含refer-to头域，该头域内容为需要对其进行控制的第三方的URI，该URI中可包含method参数表示要求采用何种请求消息进行控制。在呼叫转接业务中，URI中需包含replaces参数携带需要替换的对话标识。对REFER请求的成功响应消息为202Accept。当REFER消息所要求的第三方控制功能完成后，可以通过NOTIFY消息向REFER消息的发出方进行通知。6.5. INFO流程6.5.1. 业务需求在一些业务场景中，需要传递会话相关的控制信息。re-INVITE机制通常用于对媒体属性的修改，INFO流程则可以用于更广泛的应用层控制消息的传递，IN
23、FO流程不一定会影响已有的会话状态。6.5.2. 流程描述及使用方式INFO流程如图6-6所示：图6-6INFO流程INFO消息传递会话相关的控制信息，必须在INVITE消息建立的对话内发送。INFO消息可以携带不同类型的消息体（如MSML脚本）用以完成不同的控制功能。在会议业务中，AS对媒体服务器进行控制时(如放音、收号、增加/删除与会者等)采用INFO流程。6.6. 没有媒体成分的媒体协商流程6.6.1. 业务需求在一些应用场景中需要两个网元间建立一个对话，该对话仅用于进行控制信令的传送，不需要建立媒体连接（如会议业务中AS与MRF建立会议控制对话）。在这种情况下，若其中一方发送不携带SD
24、P的INVITE请求，则对方通常会在200OK响应中携带SDPoffer进行媒体协商，无法达到目的。因此需要一种不包含媒体成分的媒体协商流程。6.6.2. 流程描述及使用方式没有媒体成分的媒体协商流程如图6-7所示：消息1和消息2中的SDP中都不包含媒体成分，如：v=0o=Alice456981216781226INIP410.10.10.40s=SipCallc=INIP410.10.10.407. CM-IMS业务对SIP协议的扩展原则CM-IMS业务的实现除需要开发业务逻辑外，在一些情况下还需要借助对SIP协议的相应扩展以满足业务需求。CM-IMS业务对SIP协议的扩展需要遵循如下原则：1 在满足业务需求的前提下，应充分考虑应用已纳入本规范的定制化要求；2 在满足业务需求的前提下，应按如下顺序考虑扩展方式：a) 在不违反本系列规范基本原则的前提下扩展SIP信令流程b) 对现有SIP头域或参数的取值进行扩展c) 扩展新的SIP头域或参数d) 在通常情况下不应考虑增加新的SIP消息。8. 编制历史版本号更新时间主要内容或重大修改1.0.02011-6-2规定了中国移动IMS网络及业务对会话初始协议(SIP)的定制化需求1.0.0版本；编号：QB-C-018.4-2011