中国电信cdma2000核心网络接口协议技术规范-SIP-I协议

保密等级：公开发放中国电信集团公司 发布2008-07-14实施2008-07-14发布中国电信cdma2000核心网络接口协议技术规范SIP-I协议规范Technical Specification of Interface&Protocol in cdma2000 Core Network of China TelecomSIP-I（V1.0）Q/CT2032-2008中国电信集团公司技术标准目录前 言41范围12引用标准13术语说明24ZZ接口涉及的网元及协议说明35通用要求36MSCE对SIP/SDP协议能力集的适配要求47音资源适配要求47.1总则要求47.2SIP消息对音资源行为的适配57.3提供Ealry Media实体的行为要求67.4接收Early media实体的行为要求67.4.1基本信令适配67.4.2特殊约定说明78编码协商说明79LMSD网络对SIP协议重叠发码的要求710会话建立后的周期更新（呼叫心跳）711MSCE基本信令行为说明811.1主叫侧MSCe811.2被叫侧网络MSCe912切换行为说明1012.1总体说明1012.2定时器描述1012.2.1目标局1012.2.2主控局1012.3切换过程实体行为说明1012.3.1主控局1012.3.2目标局1113LMSD网络中的路由心跳功能1113.1概述1113.2设备状态1213.2.1State 1状态1213.2.2State 2状态1313.3消息格式1314其他1314.1二次拨号信息传送1314.2SDP中Ptime参数约定说明13附录 A：SIP几个主要METHOD及参数要求（规范性附录）15A.1 INVITE消息15A.2 ACK15A.3 BYE16A.4 CANCEL16A.5 OPTIONS16A.6 INFO17A.7 PRACK17附录B RFC 3261：SESSION INITIATION PROTOCOL（规范性附录）18附录C RFC 3262 ：RELIABILITY OF PROVISIONAL RESPONSES IN THE SESSION INITIATION PROTOCOL（规范性附录）29附录D RFC3264：AN OFFER/ANSWER MODEL WITH THE SESSION DESCRIPTION PROTOCOL (SDP) RFC3264（规范性附录）30附录E RFC 2976：THE SIP INFO METHOD（规范性附录）32附录F RFC3311 THE SESSION INITIATION PROTOCOL (SIP) UPDATE METHOD33附录G LMSD 网络中SIP重叠发码程序技术实现（资料性附录）34附录H 信令流程示例（规范性附录）35H.1 基本呼叫35H.1.1成功呼叫建立35H.1.2 正常呼叫释放41H.1.3 失败呼叫42H.2 补充业务45H.2.1 呼叫前转（无条件前转）45H.2.2 呼叫前转（无应答前转）46H.2.3 呼叫前转（寻呼无响应前转）46H.2.4 呼叫前转（遇忙前转）47H.2.5 主叫号码显示48H.2.6 主叫号码显示限制49H.3 切换流程50H.4 会话建立后，呼叫周期更新51H.5 定时器52H.5.1 INVITE消息定时器52H.5.2 200消息的定时器（等待ACK消息）53前 言本标准是中国电信CDMA核心网络接口协议系列技术标准之一，该系列标准的结构及名称预计如下：（1） 中国电信cdma2000核心网络接口协议技术规范1x A接口协议规范（2） 中国电信cdma2000核心网络接口协议技术规范移动应用部分（MAP）（3） 中国电信cdma2000核心网络接口协议技术规范分组域协议（4） 中国电信cdma2000核心网络接口协议技术规范SIP-I协议规范（5） 中国电信cdma2000核心网络接口协议技术规范MNPG NPI接口协议规范（6） 中国电信cdma2000核心网络接口协议技术规范MNPG SPI接口协议规范（7） 中国电信cdma2000核心网络接口协议技术规范OMC北向接口协议规范（8） 中国电信cdma2000 HRPD Rev.A设备总体技术规范A接口技术分册本标准是接口协议技术规范的第4部分，主要定义了cdma2000 LMSD网络ZZ接口上各SIP实体的基本行为及通用规则。本标准主要依据中国电信软交换网络SIP一协议规范 通用要求（2007版 暂行）编制而成。本标准的附录A、B、C、D、E、F、H为规范性附录。本标准的附录G为资料性附录。本标准由中国电信集团公司提出并归口。本标准起草单位： 中国电信股份有限公司广州研究院本标准主要起草人：张鹏生1 范围本规范适用于CDMA 2000 LMSD网络。本规范定义了LMSD网络中ZZ接口对SIP协议的通用要求。LMSD与他网（如软交换网络、PSTN网络等）的互通要求，参见各互通技术规范。本规范当前只考虑协议对语音业务的支持。附录H示例了基本业务流程和几个典型补充业务流程。2 引用标准下列标准所包含的条文，通过在本技术要求中引用而构成本技术要求的条文。出版时，所示版本均为有效。所有标准都会被修订，使用本技术要求的各方应探讨使用下列标准最新版本的可能性。1） YDN 038-1997 “国内NO.7信令方式技术规范综合业务数字网用户部分（ISUP）”2） YDN 038.1-1999 “国内NO.7信令方式技术规范综合业务数字网用户部分（ISUP）（补充修改件）”3） 中国电信ISUP信令流程和消息参数设置的相关要求（2005年）4） 中国电信软交换网络SIP协议规范 通用要求（2007版 暂行）5） 3GPP2 X.S0025-0 V1.0 “Legacy MS Domain Setup 2”6） ITU-T Q.1912.5 “SIP “Interworking Between Session Initiation Protocol (SIP) and Bearer Independent Call Control Protocol or ISDN User Part”7） IETF RFC2046 “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”8） IETF RFC2327 “SDP: Session Description Protocol”9） IETF RFC2833 “RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals”10） IETF RFC2976 “The SIP INFO Method”11） IETF RFC3204 “MIME media types for ISUP and QSIG Objects”12） IETF RFC3261 “SIP: Session Initiation Protocol”13） IETF RFC3262 “Reliability of Provisional Responses in the Session Initiation Protocol (SIP)”14） IETF RFC3264 “An Offer/Answer Model with the Session Description Protocol (SDP)”15） IETF RFC3311 “The Session Initiation Protocol (SIP) UPDATE Method”16） IETF RFC3323 “A Privacy Mechanism for the Session Initiation Protocol (SIP)”17） IETF RFC3325 “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks”18） IETF RFC3326 “The Reason Header Field for the Session Initiation Protocol (SIP)”19） IETF RFC4028 “Session Timers in the Session Initiation Protocol (SIP)”20） RFC 5009“Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media3 术语说明在本规范中，以下术语具有特定意义：1） SIP-I：特指封装ISUP信息的SIP消息。SIP消息封装ISUP信息的方法参照中国电信软交换网络SIP协议规范 通用要求（2007版 暂行）附录F的要求。2） 前向网络/实体：相对本节点而言，前向网络/实体特指位于本节点前一跳的实体。在信令方向上，当前节点接受来之该实体发送的初始请求消息。3） 后向网络/实体：相对本节点而言，后向网络/实体特指位于本节点下一跳的实体。在信令方向上，当前节点向该实体发送初始请求消息4） LMSD（Legacy Mobile Station Domain）：特指cdma2000体系中的传统电路域。5） MSCe（Mobile Swicthing Center emmulation）：LMSD网络中的移动交换中心，负责SIP信令、MAP等信令的处理。6） MGW（Media Gateway）：媒体网关设备，负责媒体流的处理。7） GMSCe（Gateway MSCe）：完成与非LMSD网络互通时的MSCe设备。8） TMSCe（Tandem MSCe）：汇接层面的MSCe设备。9） Anchor Network：在切换程序中，希望将呼叫切换出的网络。本规范称之为主控网络。10） Target Network：在切换程序中，负责接收切换请求的网络。本规范称之为目标网络。11） Early media：被叫用户摘机前，主叫侧UA设备收到的语音资源，包括（后向提供的）表征振铃的资源、表征寻址失败的音资源（例如，被叫用户忙等）。12） Regular media：被叫摘机后，主被叫用户建立的真正音资源。4 ZZ接口涉及的网元及协议说明图 41：SIP协议在ZZ接口上的应用注：图2-1中的设备为逻辑设备。图2-1只罗列了与ZZ接口相关的设备。 ZZ接口适用于MSCe/TMSCEe/GMSCe之间。本规范要求ZZ接口采用SIP-I协议。SIP-I的定义及相关要求参见1.3部分的说明。如无特殊说明，本规范所述MSCe设备对SIP协议的适配将适用于所有类型的MSCe， 包括TMSCe和GMSCe。注：1） TMSCe是否存在，或是否携带MGW，需参考具体网络部署方案。2） GMSC是否需要携带MGW需参考具体网络部署方案。5 通用要求1） LMSD网络暂不考虑IETF RFC 3312所定义的SIP Precondition特性2） 如MSCe收到的消息中存在的参数（包括头部消息和消息体中的内容）满足语法规则，但MSCe不能识别时，MSCe不得由于该参数的存在而影响对于基本呼叫的正常处理。3） 根据本规范第2章节的要求，MSCe之间将采用SIP-I协议进行通信。LMSD网内的PSTN/ISDN补充业务信息将尽量通过SIP-I消息中的ISUP信息携带。4） 当MSCe收到SIP-I消息时，如其中的SIP头部信息与ISUP信息出现冲突，MSCe应以SIP头部信息作为业务信息基准。5） 被叫侧MSCe在寻呼用户时，只有当空口资源已指配完成后，才向主叫侧网络发送振铃消息（180消息）。6） LMSD用户做被叫时，该用户所在的MSCe+MGW将向主叫侧网络提供回铃音资源（注，此处未考虑增值业务提供语音资源的情况）。相关要求参照本规范第5章节的说明。7） LMSD用户做主叫时，该用户所在的MSCe+MGW根据SIP消息的相关约定决定是否本地提供回铃音。相关要求参照本规范第5章节的说明。6 MSCe对SIP/SDP协议能力集的适配要求根据业务或呼叫逻辑的需要，MSCe可能启动UA、Proxy、B2BUA等功能。其对SIP能力集的要求应满足表4-1的要求。 表 61：各实体支持的SIP及相关能力集SIP能力集 MSCe（包括GMSCe、TMSCe等）RFC2327必须RFC2046必须RFC2976必须RFC3261必须RFC3262必须RFC3264必须RFC3311必须RFC3325必须RFC3326必须RFC4028必须ITU-T Q.1912.5必须RFC 5009条件支持（注1） 注1：当业务或网络需要该实体支持本能力时，条件支持将转变为“必须”。 注2：本规范不约束MSCe具体采用何种逻辑实体实现业务。7 音资源适配要求7.1 总则要求LMSD网络中的媒体流提供存在以下约定：1） 底层媒体流的实际内容应与信令层面协商的一致。即，只有在信令协商完成的情况下，才能根据协商内容发送媒体流”2） 当LMSD用户做被叫时，该用户所处网络向主叫侧网络提供回铃音资源3） 当LMSD用户做主叫时，该用户所在的MSCe+MGW根据SIP信令的指示，决定是否由本地提供回铃音资源。7.2 SIP消息对音资源行为的适配1） 当表征被叫用户处于振铃状态时，后向网络向主叫侧网络发送180消息。并且， 如之前未与前向网络完成Offer/Answer，则本180消息中应携带SDP信息（SDP信息为提供回铃音资源的媒体设备信息）。 如之前已完成Offer/Answer，则本180消息中无须携带SDP信息 图 71：被叫侧网络向前向网络提示被叫用户处于振铃状态2） 当后向网络（相对于接收音资源的设备）提供除振铃音以外的其它资源时，例如表示呼叫处于失败状态的资源，则发送183消息。如之前该节点未与前向网络完成Offer/Answer，则本183消息中应携带SDP信息（SDP信息为提供本次音资源的媒体设备信息） 图 72：被叫侧网络向前向网络提供其他（非振铃行为）音资源3） 网络中提供音资源的某一实体，当确认本实体需对先前完成的Offer/Answer进行修改时（未应答之前），则向前向网络发送UPDATE消息完成协商修改。4） 网络中接收音资源的实体，在被叫未应答之前，如收到UPDATE消息，则应根据Offer/Answer的要求进行准确响应。7.3 提供Ealry Media实体的行为要求注：Early Media的定义参照1.3章节的说明。 如网络中的某一实体向“前向SIP实体”提供音资源，其行为应满足5.2章节第1）、2）及3）（如存在）的要求。7.4 接收Early media实体的行为要求7.4.1 基本信令适配1） 如主叫侧MSCe从后向网络收到的第一个消息为180消息，且不带SDP，则MSCe控制本地MGW向主叫用户提供回铃音，直到满足以下场景的条件： 场景1：收到第一个“带有SDP的18*消息”。或， 场景2：收到被叫应答消息。或， 场景3：收到失败消息。图 73：主叫侧MSCe初始提供回铃音2） 如主叫侧MSCe从后向网络收到的第一个消息为18*消息，且带有SDP，则MSCe只需告知MGW导通与后向网络的媒体通道即可，无需提供回铃音。图 74：主叫侧MSCe确认被叫侧网络提供音资源7.4.2 特殊约定说明当设备由“Early Media”状态转为“Regular Media”状态的过程中，为保证业务的正常进行，要求“接收Early Media的实体”通过同一IP地址+端口接收Early Media和Regular Media。注：Ealry Media与Regular Media的定义参照1.3部分的说明。当通话转为Regular media状态后，实体可根据业务需要进行端口的变化。8 编码协商说明MSCe之间通过RFC3264所定义的Offer/Answer协商程序完成MGW之间的媒体编码选择。本规范对RFC3264的遵循请参照附录D相关之规定。同时，本规范强调：1） 建议Answer方尽量顺从Offer方提供的各编解码的优先排列顺序2） 编码选择的最终决定权在于Answer方。Answer方发送的SDP信息中的编码能力集的第一个编码为当前协商所选定的编码。（注1）注1： 如SDP中存在多个m行，且每个m行都协商成功，则每个m行中的第一个编码为该m行所代表的业务选择的编码。 当存在多个有效的m=audio行时， 要求选择“第一个有效的audio行的第一个语音编码”作为当前语音业务所选择的编码。 对于语音业务，不建议Offer方发送的SDP中带有多个m=audio行9 LMSD网络对SIP协议重叠发码的要求1） LMSD网内用户发起的呼叫，无须考虑SIP协议重叠发码程序的要求。2） 对于固网用户发起的呼叫，建议由互通单元（完成固网与LMSD网络互通的实体）或互通单元之前的设备终结固定网络的重叠发码程序。互通单元将通过一次发码（Enbloc）的形式向LMSD网络中的MSCe设备发送初始请求。3） 本规范强调，只有当2）所描述的建议在实际网络部署中不可实施时，LMSD网络才考虑SIP协议重叠发码的实现（局间采用SIP-I）。其实现要求参照附录G的描述。10 会话建立后的周期更新（呼叫心跳）当LMSD网络中的UA设备支持会话周期更新时，要求UA行为需满足RFC4028所定义的Session Timer行为，并通过UPDATE（no SDP）消息对已建立的会话进行周期更新。本规范不建议UA设备通过发送re-INVITE进行会话的周期更新，但接收方UA设备（非主动发起会话更新请求的UA方）应能同时支持他网（如其他运营商网络）通过re-INVITE方式发起的会话更新行为。针对会话更新的定时器不应设置过短（不小于90秒），30分钟为系统默认时间，并可根据实际运营情况进行灵活调节。11 MSCe基本信令行为说明注：本章节只关注ZZ接口上各类MSCe的行为，MSCe与其它实体的交互，例如与媒体网关、基站、HLR等设备的交互，不在本规范的考虑范围之内。11.1 主叫侧MSCe1） 主叫侧MSCe收到用户呼叫请求时，确认需向下一跳SIP实体发送初始请求时，将生成初始INVITE消息然后发往下一跳，同时跳转至步骤2）或3）或4）或5）。该消息中至少包括以下信息， 携带SDP信息。SDP信息描述该MSCe所控制的媒体网关的相关信息。包括IP地址+端口、媒体编码信息等 消息中封装基本的IAM信息（ISUP信息的封装规则参照中国电信软交换网络SIP协议规范 通用要求（2007版 暂行）附录F的要求（以下涉及到封装ISUP信息都有此要求）。此阶段如涉及PSTN/ISDN补充业务，IAM信息中需体现。2） 如收到的第一个消息为180消息（100 Trying消息忽略，以下相同），且其中无SDP信息。MSCe将控制本地MGW向主叫用户提供回铃音。同时，跳转至步骤6） MSCe需确认是否需要把其中封装的ACM的相关信息传送到主叫用户侧（以下对于接收到的ISUP信息的处理相同，不再赘述）。3） 如收到的第一个消息为180消息，且带有SDP信息。MSCe确认被叫侧网络提供回铃音，MSCe通知MGW导通媒体通道。同时，跳转至步骤7）或步骤8）或步骤9）。4） 如收到的第一个消息为183消息，且带有SDP信息。MSCe确认被叫侧网络提供音资源（除振铃音资源外），MSCe通知MGW导通媒体通道。同时转跳至步骤7）或步骤8）或步骤9）（可能会出现）或步骤12。5） 如收到的第一个消息为183消息，且其中无SDP信息（无论是否带有ISUP信息），MSCe+MGW不会向主叫用户提供回铃音或其他音资源。6） 如后续收到的18*消息中带有SDP信息，则MSCe通知MGW停止本地回铃音的提供，同时要求MGW导通媒体通道，主叫用户接收被叫侧网络提供的音资源。同时，跳转至步骤7）或步骤8）或步骤9）7） 完成Offer/Answer后，如在被叫应答之前，收到带有SDP的UPDATE消息（1个或多个）：则MSCe回送200消息（UPDATE）。要求其中的SDP信息应与初始INVITE消息中的IP地址+端口号（SDP信息中）保持一致。跳转至步骤8）或步骤9）8） 如收到失败消息，则释放相应资源。根据本地策略决定是否向主叫用户提供相关的失败音资源。9） 收到被叫用户应答的200消息（INVITE），如MSCe之前控制MGW提供回铃音，则应停止。主、被叫用户进入通话状态。10） 通话建立后， 根据200（INVITE）消息中的约定，启动会话更新功能。相关要求参照本规范第8部分的要求。11） 通话建立后，如需发送拆线消息，则发送BYE消息（封装REL信息），该消息中可选携带Reason头域；或，针对拆线消息回送针对BYE消息的200响应（封装RLC信息）。12） 对于早释情况（收到被叫应答消息之前，主叫侧拆线），如未建立Early Dialog，则MSCe发送CANCEL消息（无需封装ISUP信息）；如Early Dialog已建立，则可发送CANCEL消息，也可发送BYE消息。11.2 被叫侧网络MSCe1） 收到初始INVITE消息后，寻呼用户。当为被叫用户指配好空口资源后，MSCe发送180消息。MSCe控制MGW向主叫侧网络提供回铃音资源。该消息中至少包括以下信息 带有SDP信息。SDP信息描述本MSCe所控制的媒体网关的相关信息。包括IP地址+端口、媒体编码信息等 消息中封装基本的ACM信息（ISUP信息的封装规则参照中国电信软交换网络SIP协议规范 通用要求（2007版 暂行）附录F的要求）。此阶段如涉及PSTN/ISDN补充业务，ACM信息中需体现。（以下涉及到封装ISUP信息都有此要求）2） 被叫用户摘机。MSCe发送200消息（INVITE）。同时， 不带SDP信息。 消息中封装ANM信息。3） 通话建立后， 根据200（INVITE）消息中的约定，启动会话更新程序。相关要求参照本规范第8部分的要求。4） 通话建立后，如需发送拆线消息，则发送BYE消息（封装REL信息）；或，针对拆线消息回送响应（封装RLC信息）。5） 当被叫侧网络向主叫侧提供失败的语音资源时（未应答之前），被叫侧MSCe发送183消息，且 带有SDP信息。SDP信息描述本MSCe所控制的媒体网关的相关信息。包括IP地址+端口、媒体编码信息等。 封装ACM信息，且必须带有BCI参数、OBCI参数、Reason参数。其中BCI参数为“无指示”；OBCI中“带内信息表示语”为“带内信息或适当的码型目前可用”；Reason参数根据当前失败的原因进行取值。12 切换行为说明12.1 总体说明MSCe之间的切换需要同时完成两个层面的信令协商，通过MAP和SIP协作来完成。关联MAP和SIP请求消息通过vCIC，vCIC用于标识切换时的IP承载，切换时的MAP消息和SIP消息使用同样的vCIC值。vCIC在MAP FACDIR2请求中，以IMSCCID格式编码。在SIP INVITE请求中，支持如下格式：INVITE SIP:vCIC-0xAAAAhost SIP/2.0其中， AAAA是用十六进制表示的IMSCCID，host为目标局MSCe的IP地址。12.2 定时器描述12.2.1 目标局对于一个成功的切换，目标局需收到MAP（FACDIR2）和SIP（INVITE）消息。目标局定义两个定时器来控制切换的过程：MAP层面的MHST和SIP层面的SHST，两个定时器的缺省值都为6秒。当目标MSCe收到其中一个请求时，需要启动定时器等待另一个请求的到来。12.2.2 主控局 同样，主控MSCe在发送MAP或SIP的请求消息后，需等待两个请求的响应facdir2（MAP）或200 OK（SIP），也分别需要定时器HOT和TB，两者定时器的缺省值为12秒。注：TB是在切换程序环境下，发送INVTIE后等待200响应的定时器，该定时器为应用层定时器。与RFC3261所规定的TB定时器（发送初始请求，等待临时响应）存在不同。12.3 切换过程实体行为说明12.3.1 主控局1） 选择一个合适的vCIC，在FACDIR2和INVITE中进行编码；2） 设置MAP和SIP的定时器，当在主控局接收到facdir2或200 OK时，表示切换承载和切换设备建立已经成功。使用定时器HOT和TB监视这两个响应的返回。3） 当接收到MSONCH时，表示切换已经成功，使用定时器MHOT监视这个消息。12.3.2 目标局1） 当目标局收到具有有效vCIC的FACDIR2和INVITE消息时，启动切换；2） 如果目标局收到的INVITE没有vCIC，则INVITE将作为SIP的普通呼叫进行处理，不启动等待FACDIR2的定时器；如果目标局接收到FACDIR2没有vCIC，则FACDIR2作为传统的MAP请求，不启动等待INVITE请求的定时器；3） 如果INVITE和FACDIR2消息中都存在有效的vCIC，但是不匹配，则当作如同MHST/SHST超时处理；4） 如果SHST超时后，INVITE还未到达，则facdir2将返回错误。错误码是“Trunck Unavailable”，解释为“Requested bearer not established”，其可能的原因是请求的中继不可用、没有中继可用、请求的承载没有成功建立等。5） 如果MHST超时，FACDIR2还没有到达，则返回404 Not Found。6） 如果facdir2返回错误，作为致命的错误。目标局已经建立的相关的任何承载和分配的无线资源，都要释放。主控局在收到响应时，也需要释放相关的资源。7） 对于切换请求时的SIP错误，目标局需要触发4*响应到主控局。当收到4*消息时，主控局用正确的ack或错误通知发到MAP。这些错误也当作致命的错误，任何已建立的资源在发送或接收方都需要被释放掉。13 LMSD网络中的路由心跳功能13.1 概述本章节定义LMSD网络中MSCe之间的路由心跳功能。实体通过该功能可即时获知指定的对端设备的存活状态，从而决定本端到目的地址的寻址路由关系。本规范采用OPTIONS消息作为LMSD网络中的路由心跳信息。同时，鉴于OPTIONS的特殊应用，应用于该场景下的OPTIONS消息，应弱化OPTIONS查询实体能力的功能，OPTIONS消息仅作为连接性信号发往对端实体。该功能独立于某一次具体的呼叫，根据本端数据配置周期性的向指定对端发送。为区分事务层的T1、T2定时器，本规范在应用层面定义2个定时器T100、T200用以规范实体发送OPTIONS消息的行为。默认情况下，T100=20秒，T200=10秒，同时T100和T200应能根据实际网络运营情况进行修改调整。为避开事务层原有的重发机制，作为心跳的OPTIONS消息应避开事务层，由应用层直接发送到传送层。13.2 设备状态遵循本规范发送路由心跳信息的各实体包括两个状态：State 1和State 2。 State 1: 连接状态。当设备处于State 1时，本端设备认为到对端设备的路由处于正常状态，后续呼叫可基于该路由进行。 State 2: 故障状态。当设备处于State 2时，本端设备认为到对端设备的路由处于故障状态。本端应禁止利用该路由进行寻址。图11-1为设备状态迁移示意图。 图 131 ： 状态迁移图在图11-1中，T100用于连接状态下心跳机制的应用层定时器，而T200用于故障状态下心跳机制的应用层定时器。在State1状态时，设备以T100的周期发送OPTIONS消息；在State2状态时，设备以T200的周期发送OPTIONS消息。本规范强调：不同周期的OPTIONS消息为非重发关系。13.2.1 State 1状态当设备处于State 1时：1） 应用层指示传输层（避开事务层）发送OPTIONS请求，并启动定时器T1002） 如果定时器T100终了前没有收到针对当前OPTIONS请求的200 OK响应消息，则计数器加1；如果收到，计数器清0；3） 定时器T100终了时，若计数器的值小于3（要求次数能够配置，默认情况下为3），应用层指示传输层发送OPTIONS请求，并重新启动定时器T100；否则转到第4）步。4） 若连续3次（即计数器的值为3）发送的OPTIONS请求消息无响应，则迁入State 2，Status参数置为“故障状态”。13.2.2 State 2状态当设备处于State 2时：1） 应用层指示传输层（避开事务层）发送OPTIONS请求，并启动定时器T2002） 定时器T200终了前若收到针对当前OPTIONS请求的200 OK响应，则计数器加1；若没有收到，则计数器清0；3） 定时器T200终了时，若计数器的值小于3（要求次数能够配置，默认情况下为3），应用层指示传输层发送OPTIONS请求，并重新启动定时器T200；否则go to 4）。4） 若连续3次（即计数器的值为3）发送的OPTIONS请求消息收到了200 OK响应，则迁入State 1，Status参数置为“连接状态”。 13.3 消息格式当OPTIONS消息作为路由心跳时，消息结构如下所示： OPTIONS Via: To: From:Call-ID: CSeq:1 OPTIONSContent-Length:014 其他14.1 二次拨号信息传送本规范暂不考虑在LMSD网络内通过SIP信令传送二次拨号信息。要求各UA设备必须支持RFC2833所定义的内容、通过带内方式传送二次拨号信息。14.2 SDP中Ptime参数约定说明完成Offer/Answer协商的双方，需按照对端设备在SDP中的Ptime参数约定进行打包。如对端设备在Offer或Answer中并未指定Ptime值，则本端按照本地策略进行打包。附录 A：SIP几个主要Method及参数要求（规范性附录）当前LMSD网络应至少支持以下几个基本的SIP Method： INVITE、PRACK、BYE、ACK、INFO、OPIONS、UPDATEA.1 INVITE消息 INVITE 头域必选取值必选头域Call-idContactCseqFrom P-Asserted-identityMax-forwordToViaSupported100 rel、timerAllowUPDATE常用可选头域AcceptAuthorizationContent-lengthContent-typeRecord-route如实体采用Proxy逻辑功能，则在初始的INVITE消息中必须加上Record-route域RouteRequireProxy-AuthorizationProxy-requireP-asserted-identityP-prefered-identityPrivacyA.2 ACK ACK头域备注必选参数Call-idCseqFromMax-forwordToVia常用可选参数 Content-lengthContent-typeRouteA.3 BYEBYE头域备注必选参数Call-idCseqFromMax-forwordToVia常用可选参数Content-lengthContent-typeRouteReasonA.4 CANCELCANCEL头域备注必选参数Call-idCseqFromMax-forwordToVia常用可选ReasonA.5 OPTIONSOPTIONS头域备注必选参数Call-idCseqFromMax-forwordToVia常用可选参数AcceptAllowSupportedA.6 INFO INFO头域备注必选参数Call-idCseqFromMax-forwordToVia常用可选参数Content-typeContent-lengthRouteA.7 PRACKPRACK头域备注必选参数Call-idCseqFromMax-forwordToViaRack常用可选参数Content-typeContent-length附录B RFC 3261：Session Initiation Protocol（规范性附录）1） 如无特殊说明，本附录的要求适用于LMSD网络中的所有MSCe实体2） 如与RFC3261的要求存在差异，将以“说明栏”的内容为实现基准。否则，本附录遵循RFC3261相关之规定。章节标题说明1Introduction2Overview of SIP Functionality3Terminology4Overview of Operation5Structure of the Protocol6Definitions7SIP Messages7.1Requests7.2Responses7.3Header Fields7.3.1Header Field Format7.3.2Header Field Classification7.3.3Compact Form7.4Bodies7.4.1Message Body Type7.4.2Message Body Length7.5Framing SIP messages8General User Agent Behavior8.1UAC Behavior8.1.1Generating the Request8.1.1.1Request-URI8.1.1.2To1） 当采用SIP-URI时，建议格式为userinfohost，user=phone的方式。2） 无特殊业务需求时，网络实体不应改变初始请求中to域的SIP URI中的userinfo部分的内容。8.1.1.3From1） 当采用SIP-URI时，建议建议格式为userinfohost，user=phone的方式。2） 无特殊业务需求时，网络实体不应改变初始请求中From域的SIP URI中的userinfo部分的内容。8.1.1.4Call-ID8.1.1.5Cseq8.1.1.6Max-Forwards8.1.1.7Via8.1.1.8Contact当设备基于B2BUA逻辑实体实现业务时，1） 该实体收到用户初始请求的Invite消息向下转发时，Contact地址（usernamehost）中的“host”部分应当变成B2BUA的地址（除非有特殊业务需求）2） B2BUA回应200消息或18*消息时，如果此时响应消息中带有contact域，此时的contact的地址（usernamehost）中的“host”部分应当变成B2BUA的地址（除非有特殊业务需求）8.1.1.9Supported and Require8.1.1.10Additional Message Components8.1.2Sending the Request8.1.3Processing Responses8.1.3.1Transaction Layer Errors8.1.3.2Unrecognized Responses8.1.3.3Vias8.1.3.4Processing 3xx Responses8.1.3.5Processing 4xx Responses8.2UAS Behavior8.2.1Method Inspection8.2.2Header Inspection8.2.2.1To and Request-URI8.2.2.2Merged Requests8.2.2.3Require8.2.3Content Processing8.2.4Applying Extensions8.2.5Processing the Request8.2.6Generating the Response8.2.6.1Sending a Provisional Response8.2.6.2Headers and Tags8.2.7Stateless UAS Behavior8.3Redirect Servers9Canceling a Request9.1Client Behavior1）如Invite消息导致early dialog的建立，主叫侧在此场景下如存在拆线需求，除可发送CANCEL消息外，还可以发送BYE消息9.2Server Behavior10Registrations暂不要求10.1Overview10.2Constructing the REGISTER Request10.2.1Adding Bindings10.2.1.1Setting the Expiration Interval of Contact Addresses10.2.1.2Preferences among Contact Addresses10.2.2Removing Bindings10.2.3Fetching Bindings10.2.4Refreshing Bindings10.2.5Setting the Internal Clock10.2.6Discovering a Registrar10.2.7Transmitting a Request10.2.8Error Responses10.3Processing REGISTER Requests11Querying for Capabilities11.1Construction of OPTIONS Request11.2Processing of OPTIONS Request12Dialogs12.1Creation of a Dialog12.1.1UAS behavior1） 如Invite中带有Record-route域，对于180消息：如带有Contact域，则必须带有Record-route域12.1.2UAC Behavior12.2Requests within a Dialog12.2.1UAC Behavior12.2.1.1Generating the Request12.2.1.2Processing the Responses12.2.2UAS Behavior1） 暂不要求网络实体间的鉴权处理2） 后续内容中与之相关的内容也采用相同的处理12.3Termination of a Dialog13Initiating a Session13.1Overview13.2UAC Processing13.2.1Creating the Initial INVITE13.2.2Processing INVITE Responses13.2.2.11xx Responses13.2.2.23xx Responses13.2.2.34xx, 5xx and 6xx Responses13.2.2.42xx Responses13.3UAS Processing13.3.1Processing of the INVITE13.3.1.1Progress13.3.1.2The INVITE is Redirected13.3.1.3The INVITE is Rejected13.3.1.4The INVITE is Accepted14Modifying an Existing Session14.1UAC Behavior14.2UAS Behavior15Terminating a Session15.1Terminating a Session with a BYE Request15.1.1UAC Behavior15.1.2UAS Behavior16Proxy Behavior16.1Overview16.2Stateful Proxy16.3Request Validation16.4Route Information Preprocessing16.5Determining Request Targets16.6Request Forwarding当MSCe基于Proxy进行业务处理时1） Outbound Proxy在处理初始invite消息时，必须增加record-route域，同时必须为Loose router方式。2） 其他消息根据业务需要而增加16.7Response Processing16.8Processing Timer C16.9Handling Transport Errors16.10CANCEL Processing16.11Stateless Proxy16.12Summary of Proxy Route Processing16.12.1Examples16.12.1.1Basic SIP Trapezoid16.12.1.2Traversing a strict-routing proxy16.12.1.3Rewriting Record-Route header field values17Transactions17.1Client Transaction17.1.1INVITE Client Transaction17.1.1.1Overview of INVITE Transaction17.1.1.2Formal Description17.1.1.3Construction of the ACK Request17.1.2Non-INVITE Client Transaction17.1.2.1Overview of the non-INVITE Transaction17.1.2.2Formal Description17.1.3Matching Responses to Client Transactions1） 暂不要求支持多播（Multicast）。2） 后续内容中与之相关的内容也采用相同的处理17.1.4Handling Transport Errors17.2Server Transaction17.2.1INVITE Server Transaction17.2.2Non-INVITE Server Transaction17.2.3Matching Requests to Server Transactions17.2.4Handling Tran