中国电信SIP规范第三分册

1、中国电信SIP 初始会话协议规范(第三分册)信令流程（暂行版）2004年4月发布 2004年4月试行中国电信集团公司发布前 言SIP协议是下一代网络中的接口协议之一，属于应用控制协议。本标准是以IETF和ITU-T的相关标准为基础，结合中国电信网络的实际情况，并综合中国电信集团公司对下一代网络的实验成果制定的。它是中国电信在下一代网络建设中引进、测试和研发软交换设备、SIP终端设备以及其他基于SIP协议相关设备的规范和依据。鉴于SIP协议应用范围广泛，项目组在编写时将整个协议规范分为3个分册：第一分册：总体要求第二分册：协议细则第三分册：信令流程本分册为信令流程分册。本标准由中国电信集团公司提

2、出。本标准由中国电信集团公司归口。本标准于2004年4月首次发布。本标准由中国电信集团公司负责解释目 录1.编制说明11.1范围11.2参考文献12.环境说明13.用户注册23.1成功的注册23.1.1基本注册过程23.1.2注册信息的更新43.1.3注销43.2不成功的注册44.鉴权认证54.1注册鉴权54.2呼叫鉴权（假定对Invite消息的鉴权）55.基本呼叫55.1SIP用户-SIP用户55.1.1成功呼叫55.1.2不成功的呼叫建立115.1.3定时器检验135.2SIP用户-PSTN用户(采用Profile B)165.2.1成功的呼叫165.2.2不成功的呼叫建立185.3PST

3、N用户-SIP用户(采用Profile B)215.3.1成功的呼叫215.3.2不成功的呼叫建立235.4PSTN用户-PSTN用户(Profile C，要求临时性响应可靠传送)255.4.1成功的呼叫255.4.2不成功的呼叫建立276.业务控制296.1SIP用户-SIP用户296.1.1Presence296.1.2Fork应用336.1.3通过重定向实现的业务（类似呼叫前转）416.1.4呼叫保持456.1.5呼叫等待476.1.6主叫显示禁止（CLIR）496.2SIP用户-PSTN用户(SIP-ISUP互通，Profile B)496.2.1呼叫前转（包括立即前转、无应答前转、遇

4、忙前转）496.2.2呼叫保持526.2.3呼叫等待536.2.4主叫显示禁止（CLIR）536.3PSTN用户-SIP用户(SIP-ISUP互通，Profile B)536.3.1通过重定向实现的业务（类似于呼叫前转业务）536.3.2呼叫保持536.3.3呼叫等待546.3.4主叫显示禁止（CLIR）546.4PSTN用户-PSTN用户(SIP-ISUP互通，Profile C)556.4.1呼叫前转（包括立即前转、无应答前转、遇忙前转）556.4.2呼叫保持586.4.3呼叫等待586.4.4主叫显示禁止（CLIR）59 中国电信SIP协议标准-信令流程1. 编制说明1.1 范围1) 本

5、分册对基本语音业务、典型补充业务的实现作了流程说明，同时做出规定的还包括Presence、并行/串行的呼叫流程，涉及的用户包括PSTN用户、SIP用户等。2) 对于IAD用户参与的呼叫流程，其局间信令的处理可参照PSTN用户参与呼叫的情形。3) 当涉及到呼叫建立的情形，都以2个交换机的情形进行说明。4) 在本分册中，为了说明上的方便，软交换充当呼叫、路由实体时，以Proxy的行为进行说明，但并不表明必须通过Proxy实现。当实体以B2BUA的形式实现时，其行为应当满足第一分册、第二分册对B2BUA的行为要求。5) T7、T9定时器参照原有PSTN网络的定义6) T1、T2定时器参照RFC326

6、1的定义1.2 参考文献1) 中国电信SIP企业规范第一分册2) 中国电信SIP企业规范第二分册2. 环境说明表 2-1 环境说明网络实体说明IP地址号码分配所属域软交换 1及其下的相关资源（软交换同时具备注册服务器功能）软交换 -GSIP用户 A00801-020-800001PSTN用户 B-020-900001媒体资源服务器M50-软交换 2及其下面的用户（软交换同时具备注册服务器功能）软交换 -BSIP用户 C00801-010-600002PSTN用户 D-010-700002媒体资源服务器M

7、50-3. 用户注册3.1 成功的注册3.1.1 基本注册过程图3-1 基本注册1) SIP用户A向所属域的注册服务器发起注册请求 REGISTER sip: SIP/2.0From: sip:80102080000;tag=25486 To: sip: 80102080000 CSeq: 1 REGISTER Call-ID: 1000000000 Via: SIP/2.0/UDP 00:5060;branch=z9hG4bK1063644978 Maxforward:70 Contact: sip: 80102080

8、00000:5060 Expires: 3600 Content-Length: 02) 注册服务器要求用户进行鉴权 SIP/2.0 401 Unauthorized From: sip:80102080000;tag=25486 To: sip:80102080000；tag=254863455 Via: SIP/2.0/UDP 00:5060;branch=z9hG4bK1063644978 CSeq: 1 REGISTER Call-ID: 1000000000 WWW-Authenticate:Digest r

9、ealm="",nonce="ca019edffb7551683c2136eb2dd10537",stale=FALSE,algorithm=MD5 Content-Length:03) 带有鉴权信息的注册请求 REGISTER sip: SIP/2.0From: sip:80102080000;tag=25ER486 To: sip: 80102080000 CSeq: 2 REGISTER Call-ID: 1000000000 Via: SIP/2.0/UDP

10、0:5060;branch=z9hG4bK1063644978 Maxforward:70 Contact: sip: 8010208000000:5060 Expires: 3600WWW-Authorization:Digest username="801020800001",realm="",nonce="ca019edffb7551683c2136eb2dd10537",uri=“sip: 80102080000”，response=“dffb7551683c2136e” Cont

11、ent-Length: 04) 注册成功 SIP/2.0 200 OKFrom: sip:80102080000;tag=25ER486 To: sip: 80102080000;tag=2343244332 CSeq: 2 REGISTER Call-ID: 100000000 Via: SIP/2.0/UDP 0:5060;branch=z9hG4bK1063644978 Contact: sip: 8010208000000:5060 Expires: 3600流程说明：1) 建议第2个Register消息与第1

12、个Register消息Call-id相同，Cseq增加3.1.2 注册信息的更新图3-1-2 注册更新流程说明：1) 假定注册周期为1个小时，终端在1个小时之内发起注册更新的消息2) 要求周期更新中带有注册鉴权信息3) 注册更新请求时，要求Call-id不变，Cseq增加3.1.3 注销1) 参照3.1.1流程2) 注销请求中,expire值为0。3.2 不成功的注册1) 参照3.1.1的流程,此时针对第二次的注册请求,注册服务器将会回应4*消息2) 不成功的注册包括：没有通过认证或注册请求的expire值太小4. 鉴权认证4.1 注册鉴权 参见3.1.1的流程4.2 呼叫鉴权（假定对Invi

13、te消息的鉴权）图4-2 呼叫鉴权用户鉴权通过后的流程，参照的流程5. 基本呼叫5.1 SIP用户-SIP用户Ø 根据第一分册的要求，当被叫用户为SIP用户时，此时主叫侧提供回铃音，因此临时响应的可靠传送不是必须的。Ø 在5.1所示的各流程中，不要求临时响应的可靠传送，因此没有PRACK流程的出现。5.1.1 成功呼叫 基本呼叫，主叫释放1) 用户A向软交换1发起请求 INVITE sip: 80101060000:5060 SIP/2.0 Via: SIP/2.0/UDP 00:5060;branch= z9hG4

14、bK020836764600000 From: 801020800001<sip: 80102080000:5060>tag=22af9be9d1eac27 To: sip:80101060000:5060 Call-ID: e9aedcb152bbe1903ddd5eed2b111a700 CSeq: 1 INVITE Max-foward:70 Contact: 801020800001 <sip: 8010208000000:5060> Content-Type: application/sdp Co

15、ntent-Length: 222 v=0 o=801020800001 2890844526 2890844526 IN IP4 00 s=- c=IN IP4 00 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 2) 软交换1接收到请求后向用户A发送确认信号，表示正在对收到的请求进行处理SIP/2.0 100 TryingVia: SIP/2.0/UDP 00:5060;branch= z9hG4bK020836764600000 From: 801020800001<sip: 8010

16、2080000:5060>tag=22af9be9d1eac27 To: sip:80101060000:5060 Call-ID: e9aedcb152bbe1903ddd5eed2b111a700 CSeq: 1 INVITE Content-Length: 03) 软交换1经过路由分析，将请求转发到软交换2 INVITE sip: 80101060000:5060 SIP/2.0 Via: SIP/2.0/UDP :5060; branch=gdasdd00023324334 Via: SIP/2.0/U

17、DP 00:5060; branch=z9hG4bK020836764600000 From: 801020800001<sip: 80102080000:5060>tag=22af9be9d1eac27 To: sip:80101060000:5060 Call-ID: e9aedcb152bbe1903ddd5eed2b111a700 CSeq: 1 INVITE Max-forward:69 Contact: 801020800001 <sip: 8010208000000;5060>

18、Record-route: <sip:;lr> Content-Type: application/sdp Content-Length: 222 v=0 o=801020800001 2890844526 2890844526 IN IP4 00 s=- c=IN IP4 00 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/80004) 软交换2向软交换1发送确认消息（表示已经接收到请求消息），同时将请求转发到用户C INVITE sip:8010106000000:5060

19、SIP/2.0 Via: SIP/2.0/UDP :5060; branch=sdfasdfsdf9898709 Via: SIP/2.0/UDP :5060; branch=gdasdd00023324334 Via: SIP/2.0/UDP 00:5060; branch=z9hG4bK020836764600000 From: 801020800001<sip: 80102080000:5060>tag=22af9be9d1eac27 To: sip:80101060000:5060 Call-ID:

20、e9aedcb152bbe1903ddd5eed2b111a700 CSeq: 1 INVITE Max-forward:68 Contact: 801020800001 <sip: 8010208000000;5060> Record-route: <sip:;lr> Record-route: <sip:;lr> Content-Type: application/sdp Content-Length: 222 v=0 o=801020800001 2890844526 2890844526 I

21、N IP4 00 s=- c=IN IP4 00 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/80005) 用户C振铃（回铃音由主叫方本地放送） SIP/2.0 180 Ringing Via: SIP/2.0/UDP :5060; branch=sdfasdfsdf9898709 Via: SIP/2.0/UDP :5060; branch=gdasdd00023324334 Via: SIP/2.0/UDP 00:5060; branch=z9hG4bK0208367646

22、00000 From: 801020800001<sip: 80102080000:5060>tag=22af9be9d1eac27 To: sip:80101060000:5060 Call-ID: e9aedcb152bbe1903ddd5eed2b111a700 CSeq: 1 INVITE Content-Length: 06) 软交换2向软交换1转发此信号7) 软交换1向用呼A转发此信号8) 用户C摘机 SIP/2.0 200 OK Via: SIP/2.0/UDP :5060; branch=sdfasdfs

23、df9898709 Via: SIP/2.0/UDP :5060; branch=gdasdd00023324334 Via: SIP/2.0/UDP 00:5060; branch=z9hG4bK020836764600000 From: 801020800001<sip: 80102080000:5060>tag=22af9be9d1eac27 To: sip:80101060000:5060;tag=568549reter9998 Call-ID: e9aedcb152bbe1903ddd5eed2b111a711.

24、1.1.100 CSeq: 1 INVITE Contact: 801010600002 <sip: 8010106000000:5060> Record-route: <sip:;lr> Record-route: <sip:;lr> Content-Type: application/sdp Content-Length: 200 v=0 o=801010600002 2890844526 2890844526 IN IP4 00 s=- c=IN IP4 00 t=0 0 m=au

25、dio 9000 RTP/AVP 0 a=rtpmap:0 PCMU/80009) 用户A接收到200消息后发送确认信号ACK 8010106000000:5060 SIP/2.0Via: SIP/2.0/UDP 00:5060; branch=z9hG4bK020836764600000From: 801020800001<sip: 80102080000:5060>tag=22af9be9d1eac27 To: sip:80101060000:5060;tag=568549reter9998 Call-ID: e9a

26、edcb152bbe1903ddd5eed2b111a700 CSeq: 1 ACK Maxforward:70 Contact: 801020800001 <sip: 80102080000:5060> Route：<sip:;lr> Route：<sip:;lr> Content-Length: 010) 软交换1、软交换2将此信号转发到用户C11) 主叫用户挂机，软交换将拆线信号转发到被叫用户C处BYE 8010106000000:5060 SIP/2.0Via: SIP/2.

27、0/UDP 00:5060; branch=z9hG4bK020836764600000From: 801020800001<sip: 80102080000:5060>tag=22af9be9d1eac27 To: sip:80101060000:5060;tag=568549reter9998 Call-ID: e9aedcb152bbe1903ddd5eed2b111a700 CSeq: 2 BYE Maxforward:70 Route：<sip:;lr> Route：<sip:2

28、.2.2.2;lr> Content-Length: 012) 被叫用户发送确认信号表示收到拆线信号SIP/2.0 200 OKVia: SIP/2.0/UDP :5060; branch=sdfasdfsdf9898709Via: SIP/2.0/UDP :5060; branch=gdasdd00023324334Via: SIP/2.0/UDP 00:5060; branch=z9hG4bK020836764600000From: 801020800001<sip: 80102080000:5060>tag=22

29、af9be9d1eac27To: sip:80101060000:5060;tag=568549reter9998Call-ID: e9aedcb152bbe1903ddd5eed2b111a700CSeq: 2 BYEContent-Length: 0流程说明：Ø 对SIPSIP之间的呼叫，由于回铃音由主叫侧提供，因此本流程没有要求支持18*消息的可靠传送Ø 当网络实体为Proxy实现时1) 为了确保后续的请求消息不旁路网络中的服务器，要求服务器增加Record-route域，同时需要支持Loose router方式2) 由于UAS收到的I

30、nvite中带有Record-route域，因此对于180消息：如果带有Contact域，则必须带有Record-route域Ø 当软交换按照B2BUA的逻辑实现时1) ACK响应200消息（以及Bye响应200消息）时为Hop by Hop的过程2) 其Via、From、To、Contact应当根据第二分册-协议细则的要求生成，以能够保证呼叫的所有消息都经过该网络实体 基本呼叫，被叫释放 流程说明：Ø 拆线信号由被叫发出，BYE消息中的From、to域与初始Invite消息中的From、To域发生颠倒Ø Cseq的取值应当比本终端发送的初始请求消息

31、的Cseq值增加15.1.2 不成功的呼叫建立 建立阶段，后向释放.1 被叫用户忙 流程说明：Ø 用户C下只带有1个终端，因此不考虑Fork情况的存在Ø 失败新号由被叫处的网络服务器发出，本规范建议此种方式.2 久叫不应流程说明：Ø 任何网络服务器都会启动业务层面的定时器保护，此时假定拆线信号由被叫侧网络服务器发出 建立阶段，被叫应答前，前向释放5.1.3 定时器检验 INVITE消息的定时器（没有收到任何响应消息） 流程说明：Ø 本例说明的是软交换机发送Invite消息后没有收到任何

32、响应的情况，同时假定不考虑业务层面的定时器存在。Ø 假定T1=500毫秒，如果网络服务器同时存在业务层面保护器，INVITE的次数可能少于7个。根据网络实际运营的需要，可对T1进行修改Ø 对终端而言，当发送Invite消息后没有任何消息时，其重发行为也参照该流程 200消息的定时器（等待ACK消息） 流程说明： Ø 本例说明的是软交换机发送200消息后没有收到ACK响应的情况。Ø 当终端发送200消息没有接收到ACK消息时，其重发行为参照该流程Ø 假定T1=500毫秒，T2=4秒。可根据实际运营的需要对T1进行修改

33、BYE消息的定时器（等待200消息） 流程说明：Ø 本例说明的是软交换机发送BYE消息后没有收到200响应的情况。Ø 当终端发送BYE消息没有接收到200消息时，其重发行为参照该流程Ø 假定T1=500毫秒，T2=4秒。可根据实际运营的需要对T1进行修改5.2 SIP用户-PSTN用户(采用Profile B)Ø 根据第一分册的要求，当被叫用户为PSTN用户时，由被叫端局提供回铃音，因此要求临时响应可靠传送。Ø 此时主叫用户发送的INVITE的Supported域中，必须带有100 rel参数Ø 被叫用户发送的18*消息的Requir

34、e域中，必须带有100 rel参数5.2.1 成功的呼叫 基本呼叫，主叫释放（要求临时响应可靠传送）流程说明：Ø 软交换2处的SIP-ISUP互通单元采用B配置Ø 根据第一分册的要求，此时的回铃音由被叫端局播放。因此180信号中带有SDP，建立后向通道。为了保证18*信号的可靠传送，要求必须支持RFC3262。Ø 按照协议要求，被叫应答时的200响应，不应当带有SDP描述。如果在被叫应答前，需要对媒体资源地址进行修改，通过Update进行修改 基本呼叫，被叫释放（要求临时响应可靠传送）流程说明：Ø 呼叫建立过程参见5.2.1.

35、15.2.2 不成功的呼叫建立 建立阶段，后向释放.1 被叫用户忙（被叫端局播放语音通知音） 流程说明：Ø 根据第一分册、第二分册的要求，软交换2将会根据收到的ACM消息映射成183消息，并且183消息中带有SDP，建立后向通道Ø 主叫用户听到语音通知后，如果挂机，将会发送Cancel消息Ø 如果主叫用户没有挂机，被叫端局在一定时限后将会发送拆线信号，软交换2根据接收到的REL消息发送失败消息到主叫侧，结束本次呼叫.2 等待PSTN域的ACM信号流程说明：Ø 由于PSTN网络本身存在T7定时器，因此此时的拆线信号

36、可能由PSTN网络中的任何一个局发出，本流程假设被叫侧的软交换发出拆线信号Ø 软交换2根据Q.1912的要求生成相应的4*消息.3 久叫不应 流程说明：Ø 由于PSTN网络本身存在T9定时器，因此此时的拆线信号可能由PSTN网络中的任何一个局发出，本项目假设由被叫侧的软交换发出拆线信号 建立阶段，被叫应答前，前向释放5.3 PSTN用户-SIP用户(采用Profile B)Ø 根据第一分册的呼叫模型,此时NNI接口上可采用SIP也可采用SIP-I，本流程假定NNI接口上采用SIPØ 根据第一分册的要求，当被叫用户为SIP用户时

37、，此时主叫侧提供回铃音，因此临时响应的可靠传送不是必须的。Ø 在5.3所示的各流程中,没有PRACK流程的出现。5.3.1 成功的呼叫 基本呼叫，主叫挂机流程说明：Ø 本流程假定所有SIP用户的号码为特殊号码。当软交换1接收到呼叫后，通过号码分析，确定为被叫为SIP用户，软交换1与软交换2之间的NNI接口采用SIP信令Ø 由于被叫用户为SIP用户，回铃音由主叫侧提供。因此当软交换1收到180消息后（没有SDP），软交换1通过控制其下的媒体资源服务器向主叫用户播放回铃音。 基本呼叫，被叫挂机5.3.2 不成功的呼叫建立 建立

38、阶段，后向释放.1 被叫用户忙流程说明：Ø 用户C下只带有1个终端，因此不考虑fork情况的存在Ø 失败信号由被叫处的网络服务器发出，本规范建议此种方式.2 久叫不应流程说明：Ø 任何网络设备都会启动T9定时器，本例假设由软交换2发出拆线信号 建立阶段，被叫应答前，前向释放流程说明：Ø 本例假定180消息不带有tag参数,即此时没有建立Early Dialog。Ø 根据Q.1912的规定，如果软交换1接收到的180消息的to域带有tag参数，则软交换1应当发送Bye消息5.4 PSTN用户-PSTN用户

39、(Profile C，要求临时性响应可靠传送)Ø 根据第一分册的要求，当被叫用户为PSTN用户时，由被叫端局提供回铃音，因此要求临时响应的可靠传送。5.4.1 成功的呼叫 基本呼叫，主叫释放流程说明：1) PSTN网络侧发送IAM消息到软交换1，请求路由2) 软交换1通过号码分析，不能够判别被叫用户为SIP用户，因此NNI接口上采用SIP-I信令。此时初始发送的Invite消息中除了封装PSTN发送的IAM消息外，还带有主叫侧媒体网关SDP信息。3) 软交换1将INVITE消息发送到软交换24) 软交换2通过号码分析，确认被叫用户为PSTN用户。软交换2提取出封装在In

40、vite消息中的IAM消息并结合相应的本地策略生成新的IAM消息发送到PSTN网络5) 被叫用户空闲。6) 软交换2根据接收到的ACM消息，映射成180消息，由于此时的回铃音由被叫端局提供，因此此时180消息中除了封装ACM消息外，还带有被叫侧媒体网关SDP信息。7) 软交换2将此消息发送到软交换18) 软交换1根据接收到的180消息，提取出ACM消息并结合本地策略，生成新的ACM消息，发送到主叫侧的PSTN网络9) 由于媒体资源由后向提供，需要临时响应信号（18*）消息的可靠传送。因此软交换1在向主叫侧发送ACM的同时向软交换2发送确认消息，表明已收到18*消息。10) 被叫用户应答11)

41、软交换2接收到被叫侧PSTN网络发送的ANM消息后，由于主、被叫双方已建立的通道不需要修改，此时发送的200中只需封装ANM消息而不需要带有SDP信息12) 软交换1接收到200消息后，提取出ANM消息并结合本地策略，发送到主叫侧的PSTN网络13) 软交换1向软交换2发送ACK消息，表示已收到软交换2发送的200消息14) 主、被叫用户间建立通话15) 一定时间后，会话结束，主叫用户挂机。主叫侧PSTN网络向软交换1发送REL消息16) 软交换1接收到REL消息后，向主叫侧发送RLC消息；同时将REL消息封装在BYE消息中，发送到软交换217) 软交换2接收到BYE消息后，向软交换1发送封装

42、RLC的200消息；同时向被叫侧PSTN网络发送REL消息，同时接受被叫侧PSTN网络发送的RLC消息 基本呼叫，被叫释放（要求临时性响应的可靠传送） 呼叫成功建立前的流程与的相同，只是此时的拆线信号由被叫侧发起。5.4.2 不成功的呼叫建立 建立阶段，后向释放.1 被叫用户忙.2 久叫不应流程说明：Ø 由于PSTN网络本身存在T9定时器，因此此时的拆线信号可能由PSTN网络中的任何一个局发出，本项目假设由被叫侧的软交换发出拆线信号 建立阶段，在早期对话建立后，前向释放流程说明：Ø 由于18

43、0消息已经建立了媒体通道，如果主叫方在被叫应答前拆线，软交换1发送Bye消息Ø BYE消息中应当封装REL消息6. 业务控制6.1 SIP用户-SIP用户6.1.1 Presence 体系结构SIP终端1和SIP终端2互为Watcher和Presentity。软交换作为呈现业务代理，主要有以下作用：Ø 作为SIP终端的呈现业务代理，收集SIP终端的注册和注销状态信息，并向呈现业务服务器发布此信息。Ø 作为其他终端的呈现业务代理，收集其他终端的状态信息，并向呈现业务服务器发布此信息。.1 信令流程.2 呈现业务服务器启动流程

44、说明：Ø 呈现业务服务器启动时，会根据自身管理的信息向软交换机发送Subscribe消息请求软交换机当SIP或其他终端注册或注销时，由软交换机将此状态信息通知呈现业务服务器。Ø 如果软交换机和呈现业务服务器存在互信关系，软交换机将终端的状态信息（注册或者注销）通知呈现业务服务器。.3 用户登录流程说明：Ø SIP终端1向软交换机发送注册请求，通过鉴权后软交换机回送200 OK响应。Ø 软交换机发现呈现业务服务器已经订阅了此终端的状态通知，就发送Notify(reg)消息通知呈现业务服务器。Ø SIP终端1发送Subscibe（wi

45、nfo）消息请求订阅watcher的信息。Ø 呈现业务服务器通过Notify（winfo）消息将订阅者（watcher）的信息发送给SIP终端。Ø SIP终端1按照一定的鉴权策略（可参考XCAP）对于订阅者鉴权后发送Notify（authwinfo）消息给呈现业务服务器，呈现业务服务器将根据鉴权结果决定是否发送终端1的状态信息给订阅者。Ø SIP终端通过一定的方式（可参考XCAP）获取Presentity的信息后，发送Subscribe（presence）消息给呈现业务服务器订阅Presentity的状态信息。Ø 呈现业务服务器通过终端2和其他Prese

46、ntity的授权后会发送终端2和其他Presentity的状态信息给终端1。.4 增加Presentity流程说明：Ø SIP终端1发送Subscribe（presence）请求呈现业务服务器订阅终端2的状态信息。Ø 如果终端2已经登录，则呈现业务服务器发送Nofity（winfo）消息通知终端2订阅者的信息。Ø 终端2按照一定的鉴权策略鉴权通过后发送Notity（authwinfo）通知呈现业务服务器鉴权结果。Ø 呈现业务服务器发送Notify（presence）消息通知终端1关于终端2的状态信息。.5 状态改变通知流程说明

47、：Ø 用户状态改变后，终端1发送Publish消息通知呈现业务服务器状态改变信息。Ø 呈现业务服务器发送Notify（presence）消息给所有终端1的订阅者通知终端1的状态信息。6.1.2 Fork应用 并行寻址.1 成功呼叫，只有一个200信号 流程说明：Ø 在软交换2上，对于用户E，有两个地址，分别是终端1、终端2。当软交换2接收到对用户E的寻址请求时，将同时向终端1、终端2的两个地址发送请求消息Ø 根据第一分册的要求，此时软交换2并没有保留用户E下所有终端的状态信息。以下示例也是如此。Ø 对“注1”处180

48、消息的处理上1. 根据第一分册的要求，此处的180消息由软交换2生成，180消息的to域中不应当带有tag参数。但软交换2需要缓存接收到所有18*消息。2. 软交换2在生成180消息的时间上，存在两种选择。选择一，在已知被叫用户的状态下发送，此时接收到被叫用户发送的180信号；选择二，未知被叫用户状态的情况下发送180消息，即软交换2在向被叫方转发请求的同时向主叫侧发送180消息，提示向用户播放振铃音，类似于现在的Early Acm。本例显示的为后一种情况3. 主叫用户听到的回铃音由主叫侧提供。即如果主叫用户为SIP或IAD（AG）用户，则回铃音由主叫用户自己提供；如果主叫用户为PSTN用户，

49、则回铃音由主叫侧的媒体网关提供Ø 对“注2”处200消息的处理上1. 根据第一分册的要求，软交换2只向前向发送一个200消息。即当接收到一个200消息后，将向后向的被叫侧其他地址发送拆线信息2. 软交换2根据缓存的18*消息和接收到200消息，向主叫侧发送带有被叫用户SDP信息的200消息。Ø 从整个流程看，虽然寻址方式为点对多点，但会话最终仍然建立在点对点的情形下。Ø 对于200-ACK与BYE-200的处理上，软交换2也可以是一种Hop By Hop的行为。对6.1.3节有关200-ACK与BYE-200的处理都遵循此原则.2 成功呼叫，存在失败

50、信号 流程说明：Ø “注1”处的180消息生成原则，参照.1Ø 软交换2接收到后向发送的失败信号后，不应当立即向前向转发Ø 软交换2接收到200与失败信号（4*、5*或6*消息）情况下，向前向转发200消息，因此“注2”处生成的200消息为终端1的SDP信息.3 不成功呼叫.3.1 代理服务器取消请求（例如久叫不应） 流程说明：Ø 本例示例的情况为，用户E终端1处为空闲状态，但久叫不应；终端2处于忙的状态Ø 软交换2根据实际呼叫的情况，向主叫用户发送失败信号。（此时发送486较好，表明已知用户的状态）6

51、..2 主叫方取消请求 串行寻址.1 成功呼叫，第一个地址成功Ø 在软交换2上，对于用户E，有两个地址，分别是终端1、终端2。当软交换2接收到对用户E的寻址请求时，将首先向终端1所在的地址发送请求Ø 图例中“注1”处的180消息由软交换2生成,180消息中不应当带有tag参数。相应的放音信号由主叫侧提供。180信号的产生存在两种情况，参见.1的说明。本例说明的是软交换2未知被叫状态的情况下向主叫侧发送振铃提示Ø 当有地址应答后，软交换2将不会向其他地址发送呼叫请求.2 成功呼叫，存在失败信号流

52、程说明：Ø 本例所示的情况是，用户终端1处被叫用户忙，软交换2接到失败信号后，并没有后向发送，而是对此失败原因进行了缓存；软交换2同时向终端2进行呼叫，终端进行应答，用户C与终端2处的用户建立了通话。.3 不成功呼叫流程说明：Ø 用户终端1处被叫用户忙，软交换2接到失败信号后，并没有后向发送，而是对此失败原因进行了缓存；软交换2同时向终端2进行呼叫，终端2处的用户也处于忙的状态。软交换2与已经缓存的失败信号进行比较，选择一合适的失败码发送到主叫侧。本例发送486信号。6.1.3 通过重定向实现的业务（类似呼叫前转） 无条件重定向 流程说明：1)

53、本例所示的业务由终端实现Ø 用户终端E通过数据配置，当有呼叫请求时，通过发送重定向消息到网络服务器，由网络服务器将呼叫路由到其他地址Ø 该业务类似于原有的无条件呼叫转移业务2) 如果由网络实现无条件呼叫转移业务，则用户需要通过一定的手段进行业务配置，例如通过网页配置，由网络服务器直接实现呼叫的路由 遇忙重定向 流程说明：1) 该流程所示的业务由终端实现Ø 如果没有启动新业务，根据第一分册的要求，在用户或终端忙的情况下，网络将不会透传请求消息到终端。因此该业务需要用户通过某种方式告知网络，此时启动特殊业务Ø 终端启动该业务时，需要考虑由终端实

54、现的呼叫等待业务的相关性Ø 该业务类似于原有的遇忙呼叫转移业务2) 2）如果由网络实现遇忙重定向业务，则用户需要通过一定的手段进行业务配置，例如通 过网页配置，由网络服务器直接实现呼叫的重定向业务由终端实现终端需要启动自己的业务判别,在遇忙的情况下,发送302消息给软交换2,由软交换2重新发起路由请求终端不能启动呼叫等待业务该业务类似于原有的遇忙呼叫转移业务如果由网络实现无条件呼叫转移业务，则用户需要通过一定的手段进行业务配置，例如通过网页配置，由网络服务器直接实现呼叫的路由 无应答重定向 流程说明：1) 该流程所示业务由终端实现Ø 终端需要启动自己的业务判别,在无应答的情况下,发送302消息给软交换2,由软交换2重新发起路由请求。Ø 终端启动的无应答定时器应当小于网络服务器的T9定时器，以免网络服务器发生拆线的情况Ø 该业务类似于原有的无应答呼叫转移业务2) 如果由网络实现无条件呼叫转移业务，则用户需要通过一定的手段进行业务配置，例如通过网页配置，由网络服务器直接实现呼叫的路由6.1.4 呼叫保持 6.1.5 呼叫等待Ø 本业务由终端实现，要求终端提供相应的业务选择界面。Ø 要求终端通过某种手段在网络服务器上进行业务配置，例如通过网页配置Ø 网络服务器在已知被叫用户处于通话状态，