中国电信ＳＩＰ规范第一部分
总体要求
中国电信广州研发中心
２００３年１１月
前言
本标准是以互联网工程任务组、国际电联制定的相关标准为基础，结合国内网络的实际情况和国内相关标准制定的。是软交换、基于ＳＩＰ的终端设备以及其他基于ＳＩＰ协议的设备（例如Ｐｒｅｓｅｎｃｅ ｓｅｒｖｅｒ）研制、开发和生产的主要依据。
本协议规范主要涉及了ＳＩＰ协议的框架结构、基于ＳＩＰ的某些应用、业务实现流程、规范对相应国际规范的顺从力度。
根据实际情况，项目组在编写时将整个协议规范分为３个分册：
第一分册：《总体要求》 第二分册：《协议细则》 第三分册：《业务流程》
由于本规范引用的相关标准在不断发展，相应的中国国家标准并没有推出，因此，当国家标准推出时，如果与本规范存在原则性分歧的地方，应当顺从中国国家标准。
本标准由中国电信广州研发中心提出 本标准由中国电信广州研发中心归口 本标准由中国电信广州研发中心起草
目录
1. 术语说明.................................................................................................................4 2. 范围.........................................................................................................................4 3. 参考标准.................................................................................................................5 4. 符号及缩写.............................................................................................................6 5. SIP网络系统结构..................................................................................................7
5.1 5.2 5.3 5.3.1 5.3.2 5.3.3
系统框架.....................................................................................................7 实体说明.....................................................................................................8 接口说明.....................................................................................................8 NNI接口.....................................................................................................8 UNI接口.....................................................................................................9 其它接口.....................................................................................................9
6. 实体能力要求.........................................................................................................9
6.1 6.1.1 6.2 6.2.1 6.2.2 6.2.3 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.4 6.5
用户终端（User Terminal UA）....................................................................9 协议支持.....................................................................................................9 代理服务器（Proxy）................................................................................10 协议支持...................................................................................................10 路由...........................................................................................................11 安全性.......................................................................................................11 注册服务器（Registrar）............................................................................11 协议支持....................................................................................................11 功能要求...................................................................................................12 注册及更新...............................................................................................12 注销..........................................................................................................12 其他要求...................................................................................................12 重定向服务器（Redirect Server）...............................................................12 SIP-ISUP互通单元....................................................................................13
7. SIP网络与PSTN的互通....................................................................................13
7.1 7.1.1 7.1.2 7.1.3 7.2
网络互通模型............................................................................................13 PSTN用户-SIP用户..................................................................................14 SIP用户-PSTN用户..................................................................................14 PSTN用户-SIP网络-PSTN用户................................................................15 SIP-ISUP互通单元能力要求......................................................................17
8. 业务和应用...........................................................................................................17
8.1 8.1.1 8.1.2 8.2 8.2.1
B2BUA.....................................................................................................17 定义及实现...............................................................................................17 呼叫和业务控制........................................................................................17 即时消息...................................................................................................18 业务体系...................................................................................................18
8.2.2 8.3 8.3.1 8.3.2 8.3.3 8.4 8.4.1 8.4.2 8.5 8.6 8.7 8.8 8.9 8.10
图 图 图 图 图
协议支持...................................................................................................18 Presence....................................................................................................18 业务体系...................................................................................................19 协议支持...................................................................................................20 与其他业务相结合.....................................................................................21 并行、串行寻址........................................................................................21 串行寻址：...............................................................................................21 并行寻址...................................................................................................21 SIP用户的呼叫等待业务...........................................................................21 应用服务器和软交换之间的SIP接口.........................................................22 SIP协议在业务控制方面的应用.................................................................22 跨域智能业务的考虑.................................................................................22 软交换控制下的IAD用户对局间信令的要求.............................................22 语音提示音的播放.....................................................................................23
5-1 SIP网络系统逻辑结构示意.............................................................................8 7-1 PSTN用户-SIP用户.....................................................................................14 7-2 SIP用户-PSTN用户.....................................................................................15 7-3 PSTN用户-SIP网络-PSTN用户....................................................................15 8-1基于SIP 的Presence 业务体系.....................................................................19
1. 术语说明
本规范中，“暂不要求”指的是某种行为或情形目前暂时不要求实现，当所涉及的行为发生时，实体可以拒绝并给予响应。
“暂不允许”表明该种行为当前不允许发生，当所涉及的行为发生时，实体必须拒绝并给予响应。
本规范列出了各个SIP逻辑实体所需支持的规范，但仅仅局限于逻辑实体的基本动作，不覆盖所有业务的需求。以下术语主要有以下几个含义：
必须：表明实体必须满足相关规范之规定，如果中国电信对该规范存在修改，需满足修改后的规范之规定。由于所有标准都存在修改的可能，使用本标准的各方应当探讨使用引用标准最新版本的可能性。
可选：表明目前可能没有明确要求，但不排除以后的行为
2. 范围
本分册主要对SIP网络系统结构做出规定，对其中涉及到的接口以及相关实体的功能作出简要说明和要求。
由于下一代网络需要融合PSTN网络，本规范对其中涉及到的互通模型作了说明，对每种模型涉及到的消息处理方式作出规定。
同时还对一些业务和应用例如B2BUA、Presence、Fork等作出了框架性说明。
本规范暂不要求支持Tel-URL，AbsoluteURI，SIPS-URI，TLS， S/MIME，SCTP。 MPEG4的SDP描述顺从RFC3016的描述。
T.38传真的SDP描述顺从T.38的Annex D 暂不要求支持多播（multicast）和IPv6。
暂不允许终端通过OPTIONS消息查询网络实体的能力。 暂不允许网络实体之间进行鉴权的行为。 暂不允许在UNI接口上出现SIP-I消息
网络服务器在处理用户请求前应当确认该用户为合法用户，否则拒绝处理该用户的任何请求
3. 参考标准
1. YDN 038-1997 “国内NO.7信令方式技术规范综合业务数字网用户部分（ISUP）” 2. YDN 038.1-1999 “国内NO.7信令方式技术规范综合业务数字网用户部分（ISUP）（补
充修改件）” 3. ITU-T TRQ.BICC/ISUPSIP “Requirements for Interworking BICC/ISUP Network with Originating/Destination Networks based on Session Initiation Protocol and Session Description Protocol” 4. ITU-T Q.1912.SIP “Interworking Between Session Initiation Protocol (SIP) and Bearer
Independent Call Control Protocol or ISDN User Part” 5. IETF RFC2046 “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types” 6. IETF RFC2327 “SDP: Session Description Protocol”
7. IETF RFC2617 “HTTP Authentication: Basic and Digest Access Authentication” 8. IETF RFC2778 “A Model for Presence and Instant Messaging” 9. IETF RFC2779 “Instant Messaging / Presence Protocol Requirements” 10. IETF RFC2806 “URLs for Telephone Calls”
11. IETF RFC2833 “RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals” 12. IETF RFC2916 “E.1 number and DNS” 13. IETF RFC2976 “The SIP INFO Method” 14. IETF RFC3204 “MIME media types for ISUP and QSIG Objects” 15. IETF RFC3219 “Telephony Routing over IP (TRIP)” 16. IETF RFC3261 “SIP: Session Initiation Protocol” 17. IETF RFC3262 “Reliability of Provisional Responses in the Session Initiation Protocol
(SIP)”
18. IETF RFC3263 “Session Initiation Protocol (SIP): Locating SIP Servers”
19. IETF RFC32 “An Offer/Answer Model with the Session Description Protocol (SDP)” 20. IETF RFC3265 “Session Initiation Protocol (SIP)-Specific Event Notification” 21. IETF RFC3303 “Middlebox communication architecture and framework” 22. IETF RFC3304 “Middlebox Communications (midcom) Protocol Requirements” 23. IETF RFC3311 “The Session Initiation Protocol (SIP) UPDATE Method” 24. IETF RFC3312 “Integration of Resource Management and Session Initiation Protocol (SIP)” 25. IETF RFC3323 “A Privacy Mechanism for the Session Initiation Protocol (SIP)” 26. IETF RFC3325 “Private Extensions to the Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks” 27. IETF RFC3326 “The Reason Header Field for the Session Initiation Protocol (SIP)”
28. IETF RFC3372 “Session Initiation Protocol for Telephones (SIP-T): Context and
Architectures” 29. IETF RFC3398 “Integrated Services Digital Network (ISDN) User Part (ISUP) to Session
Initiation Protocol (SIP) Mapping” 30. IETF RFC3428 “Session Initiation Protocol (SIP) Extension for Instant Messaging” 31. IETF RFC34 “STUN - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)” 32. IETF RFC3515 “The Session Initiation Protocol (SIP) Refer Method” 33. IETF draft-ietf-sip-session-timer-09.txt “Session Timers in the Session Initiation Protocol
(SIP)”
34. IETF draft-ietf-avt-rtp-mime-06.txt “MIME Type Registration of RTP Payload Formats” 35. IETF draft-ietf-sipping-reg-event-00.txt “A Session Initiation Protocol (SIP) Event Package
for Registrations”
36. IETF draft-ietf-simple-presence-09.txt “A Presence Event Package for the Session Initiation
Protocol (SIP)””
38. IETF draft-ietf-impp-cpim-pidf-07.txt “Common Presence and Instant Messaging (CPIM)
Presence Information Data Format
39. IETF draft-ietf-sipping-mwi-01.txt “A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)” 40. IETF draft-ietf-sipping-overlap-04.txt “Mapping of ISUP Overlap Signaling to SIP”
41. IETF draft-avt-rtp-clearmode-00.txt “RTP Payload format for a kbit/s voice band data call” 42. draft-rajeshkumar-mmusic-gpmd-03.txt，“SDP attribute for qualifying Media Formats with
Generic Parameters”
43. IETF draft-ietf-sipping-3pcc-03.txt, “IETF Draft for 3rd party call control”
44. draft-ietf-simple-event-list-04.txt, “A Session Initiation Protocol (SIP) Event Notification
Extension for Resource Lists”
45. draft-ietf-simple-winfo-package-05.txt, “A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)”
46. draft-ietf-simple-winfo-format-04.txt, “An Extensible Markup Language (XML) Based
Format for Watcher Information” ４７． draft-ietf-simple-publish-reqs-00.txt, “SIMPLE Presence Publication Requirements” 48. draft-ietf-simple-publish-01, “Session Initiation Protocol (SIP) Extension for Presence Publication”
4. 符号及缩写
NGN：下一代网络 ISUP：ISDN用户部分 NAT：网络地址翻译 NNI：网络-网络接口 SDP：会话描述协议 SIP：会话初始协议
SIP-I：带有ISUP封装的SIP UA：用户代理
UNI：用户-网络接口 IAD：综合接入设备 AG：接入网关
MGC：媒体网关控制器（软交换机） MG：媒体网关
B2BUA：背靠背用户代理 PSTN：公共电话交换网 TLS：传输层安全
5. SIP网络系统结构
5.1 系统框架
SIP（Session Initiation Protocol）是一个应用层控制协议，它用来创建、修改和终结会话。会话的类型包括Internet电话呼叫、多媒体会议和多媒体传输等，会话的参与者可以是一方或多方。
SIP用INVITE请求消息携带会话描述信息，允许会话的参与者就会话所采用的媒体方式、类型等进行协商。SIP通过代理服务器（Proxy）将请求消息路由到被叫用户的当前位置，对用户的业务请求进行鉴权和授权，实现一定的路由策略，以及向用户提供某些业务特性等。SIP还提供注册功能，使得用户能够更新他们当前位置信息，以便代理服务器能够根据最新位置信息查找用户。
当SIP网络和PSTN互通时，为了在SIP网络中透明传送PSTN信息，需要将ISUP消息封装在SIP消息体中。此时又将SIP称作SIP-I，即带ISUP封装的SIP（SIP with Encapsulated ISUP）。
SIP网络系统的逻辑结构参见图4-1。
图 5-1 SIP网络系统逻辑结构示意
5.2 实体说明
RFC3261中定义的SIP逻辑实体包括用户代理（UA, User Agent），代理服务器（Proxy），注册服务器（Registrar），重定向服务器（Redirect Server）， B2BUA（Back-to-Back User Agent）。各逻辑实体的定义参见RFC3261。
B2BUA实质上是SIP UA的一种应用，是一种特殊的SIP逻辑实体，适用于SIP网络中需要呼叫和业务控制的场合，相关分析参照7.1节。
5.3 接口说明
５．３．１ ＮＮＩ接口
下列位置的NNI接口同SIP网络的路由、SIP网络与PSTN的互通等问题密切相关，对代理服务器、B2BUA和SIP-ISUP互通单元的能力要求有着重要的影响，故将其作为关键的NNI接口识别出来。涉及到的实体与协议主要包括：
1. SIP Proxy之间：SIP或 SIP-I
2. SIP Proxy与SIP-ISUP互通单元之间：SIP或SIP-I 3. SIP-ISUP互通单元之间：SIP-I 4. SIP B2BUA之间：SIP或SIP-I
5. SIP Proxy与SIP B2BUA之间：SIP或SIP-I
6. SIP-ISUP互通单元与SIP B2BUA之间： SIP或SIP-I
本规范建议网络实体间建立信任关系，因而暂不要求NNI接口支持网络实体间的鉴权和授权功能。
５．３．２ ＵＮＩ接口
下列位置的UNI接口是连接SIP用户和SIP网络的主要接口，对SIP用户终端和相关网络实体的能力要求有着重要的影响，故将其作为关键的UNI接口识别出来： 1. SIP 用户终端UA与SIP Proxy之间：SIP 2. SIP 用户终端UA与SIP B2BUA之间: SIP
５．３．３ 其它接口
５．３．３．１ 位置服务器相关接口
位置服务器与注册服务器、位置服务器与代理服务器（或重定向服务器）与之间的接口为私有接口。
５．３．３．２ 未识别的接口
根据有关实体的物理组合情况，在5.3.1，5.3.2，5.3.3.1节中未识别或未提及之接口根据具体情况可以是SIP或SIP-I, 也可以是私有接口。
6. 实体能力要求
6.1 用户终端（User Terminal UA）
从应用的角度，基于SIP的用户终端可分为3种：SIP软终端、SIP硬终端、基于SIP的IAD或AG设备。
由于IAD或AG设备在下一代网络中将作为5类端局使用，主要完成语音业务，因此从可运营、可管理的角度出发，不建议IAD或AG设备与软交换之间的协议采用SIP协议。 除非特殊说明，本规范中所指的用户终端主要指的是SIP软终端、SIP硬终端。 SIP终端应当满足《中国电信SIP终端规范》的要求。 暂不要求SIP终端用户之间的鉴权和授权处理。
６．１．１ 协议支持
用户终端所应支持的协议同它的业务能力相关，但需要支持下列通用性协议：
1. RFC2327, “SDP: Session Description Protocol”（必须） 2. RFC3261, “Session Initiation Protocol”（必须） 3. RFC3262, “Reliability of Provisional Response in Session Initiation Protocol (SIP)”（必
须）
4. RFC32, “An Offer/Answer Model with the Session Description Protocol (SDP)”（必
须）
5. RFC 3311, “The Session Initiation Protocol UPDATE Method”（必须）
6. RFC3265, “Session Initiation Protocol (SIP)-Specific Event Notification”（可选） 7. RFC3323, “A Privacy Mechanism for the Session Initiation Protocol”（可选） 8. RFC3325 “Private Extensions to the Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks” （必须） 9. RFC3326, “The Reason Header Field for Session Initiation Protocol (SIP)”（可选） 10. RFC3515, “The Session Initiation Protocol (SIP) Refer Method”（可选） 11. draft-ietf-sipping-3pcc-03.txt, “IETF Draft for 3rd party call control”（可选） 12. draft-ietf-sip-session-timer-12.txt, “Session Initiation Protocol Extension for Session
Timer”（建议实现）
当终端支持Ｐｒｅｓｅｎｃｅ和即时消息业务时，需要支持的协议请参见第７章“业务和应用”的相关内容。
6.2 代理服务器（Proxy）
代理服务器是SIP网络的中间实体，为了处理客户端的请求，它既承担服务器的角色又承担客户端的角色。对其的主要要求包括：
Ø 路由处理，即保证将请求消息发送到离目标用户更近的其它实体。
Ø 为了满足电信运营的需要，直接管理用户的代理服务器（类似于目前的5类端局）
应当具备获知其下用户状态（例如忙、闲等）的功能（仅局限用户带一个SIP终端的情况，具备Fork功能的代理服务器对此功能不做强制要求），并结合用户的业务属性实现相应的业务
Ø 代理服务器还可用于管理策略的实施，比如确认某个用户是否允许发起呼叫等。 Ø 代理服务器在转发一个请求消息前需要识别和解释该消息的某些特定组成部分，并
在需要的时候改写它们。
Ø 当代理服务器具备Fork功能时，功能要求参照8.4节相关之规定。 本规范对无状态的代理服务器（Stateless Proxy）暂不要求。 建议实现保留呼叫状态的代理服务器（Call stateful Proxy）
６．２．１ 协议支持
代理服务器需要支持下列协议：
1. RFC3261, “Session Initiation Protocol”（必须）
2. RFC3325, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks” （必须） 3. RFC2806，“URLs for Telephone Calls”（可选） 4. RFC3263, “Session Initiation Protocol (SIP): Locating SIP Servers”（可选） 5. RFC3323, “A Privacy Mechanism for the Session Initiation Protocol”（可选） 6. RFC3326, “The Reason Header Field for Session Initiation Protocol (SIP)”（可选） 7. draft-ietf-sip-session-timer-12.txt, Session Initiation Protocol Extension for Session
Timer”（建议实现）
６．２．２ 路由
６．２．２．１ 功能
代理服务器应提供多种路由方式以满足不同的路由实现需求。路由处理可以基于RFC3263所述的DNS 查询机制来完成，也可以基于本地的特定路由策略来完成。
当代理服务器基于本地路由策略来完成ＮＮＩ侧的路由处理时，必须支持如下两种功能： １． 基于域名的路由：根据Request-URI host部分的目标域名得到下一跳的ＵＲＬ或ＩＰ
地址
2. 基于号码的路由：根据Request-URI user部分的电话号码得到下一跳的ＵＲＬ或ＩＰ
地址
６．２．２．２ 策略
代理服务器要能通过管理配置的手段来提供灵活的本地路由策略。目前应支持的策略有:
1． 动态策略：基于一天中不同的时间段进行下一跳的路由选择
2． 静态策略：基于下一跳路由实体（代理服务器或网关等）的权重进行路由选择，也
可在权重的基础上附加一定的算法
3． 动静结合：动态策略和静态策略结合使用。例如，针对某一时间段内多个可选的下
一跳路由实体，可以再根据它们的权重进行路由选择，等等
６．２．３ 安全性
６．２．３．１ ＮＮＩ侧
代理服务器应当通过管理配置的手段在NNI侧建立一个信任的网络实体（代理服务器，SIP-ISUP互通单元等）列表。通过与其它网络实体建立信任关系/模型，代理服务器在NNI上避免了频繁的鉴权处理，满足了RFC3323、RFC3325、Q.1912.5.等SIP相关规范的需求。 代理服务器在NNI上只能接收来自信任实体的SIP-I消息，同时也只能向信任实体发送SIP-I消息。
６．２．３．２ ＵＮＩ侧
代理服务器和用户终端UA之间必须支持HTTP Digest鉴权过程。
代理服务器在UNI侧不能向SIP用户终端发送带有ISUP封装的SIP消息，也不能接受来自SIP用户终端的带ISUP 封装的SIP消息。
代理服务器应当对恶意用户建立黑名单，并支持相关的处理功能。 代理服务器应当对鉴权失败的SIP用户终端建立监视列表，并根据具体情况采取相应的击措施，例如拒绝来自某一用户终端的请求30分钟，如果他/她在两分钟内连续5次以上鉴权失败，等等，本规范不对具体实现作强制规定。
6.3 注册服务器（Registrar）
６．３．１ 协议支持
注册服务器需要支持下列协议：
1. RFC3261, “Session Initiation Protocol”（必须）
６．３．２ 功能要求 ６．３．３ 注册及更新
由于注册请求中Contact地址的有效期过短会引起注册刷新消息的频繁，从而给网络带来沉重负担；存亡周期过长则不利于运营商对用户终端的控制，因此对于注册请求中存亡周期过短或过长的行为，注册服务器应当能够进行正确的处理。
建议注册服务器允许注册请求中Contact地址有效期的下限为120秒/2分钟，上限为800秒/24小时，但注册服务器应当具备对上限和下限取值可灵活配置的功能，根据实际运营和业务需求情况合理取值。
如果注册请求中Contact地址的有效期为0或注册请求中不存在有效期的情况，应按RFC3261的具体规定处理；如果注册请求中的Contact地址的有效期小于下限，注册服务器应当回应以423错误响应，并在该响应消息的Min-Expires头域中指出服务器的建议值，在给予明确指示的情况下，如果终端仍然重发类似的请求消息，注册服务器应当判别是否属于恶意注册的行为；如果注册请求中Contact地址的有效期大于上限，则注册服务器自动将其减为上限，并在200 OK响应中包含修改后的有效期值。
注册服务器应当支持由一台终端为同一用户下其他终端进行注册的行为（To、From域相同，Contact地址可能包括一个或多个），其后的更新由该终端完成。
当用户发起地址查询时，注册服务器应当回应该用户的所有地址。
６．３．４ 注销
注册服务器应当支持由完成注册的终端发起的注销行为。
如果同一个用户下有两个终端A、B，分别带有一个地址完成注册。用户通过A终端将B终端进行注销，当终端B再次发起对自己原有地址周期更新时，网络将回失败响应（可采用403 Forbidden消息），终端B收到失败响应消息后必须停止自动发送登记请求消息的行为。
如果终端B发起的初始注册信息中包含多个地址，A终端对B终端的其中一个地址进行注销，对于B终端发起的周期更新消息，注册服务器应当回200 OK响应，200 OK响应消息中必须包含除被终端A注销的联络地址外的其他所有地址信息。终端B在后续的周期更新消息中必须不再带有自己已被注销的联络地址信息。
对注册服务器，如果同一终端两次发起的注册信息的Call-id不同，则认为该两次注册为两个的注册，不应当将其作为同一个注册的周期更新行为。 对SIP终端的要求将在《中国电信SIP终端规范》中体现。
６．３．５ 其他要求
注册服务器应当具备防黑客攻击的能力，具体的实现方式本规范不作规定。
暂不要求支持第三方（注册信息中To、From域不同）注册。 暂不要求注册服务器支持对Register请求消息的重定向处理。
6.4 重定向服务器（Redirect Server）
重定向服务器首先要能根据SIP请求消息中Request-URI所指实体的当前位置信息，用
3xx类响应消息对SIP请求进行重定向。
重定向服务器对消息的处理应当遵照RFC3261第8.3节之规定， 重定向服务器应当支持在SIP代理服务器之间的载荷分配功能，从而为网络提供良好的可升级性。
在进行SIP代理服务器之间的路由载荷分配时，重定向服务器要能提供灵活的分配策略。目前应支持的策略有:
1. 基于一天中不同的时间段进行分配
2. 基于代理服务器的路由处理权重进行分配
6.5 SIP-ISUP互通单元
从SIP侧看，SIP-ISUP互通单元实质上是一种特殊的UA。 SIP-ISUP互通单元必须支持ITU-T的TRQ.2815和Q.1912.5。 暂不要求SIP-ISUP互通单元在SIP网络侧提供UNI接口； 暂不要求SIP-ISUP互通单元支持注册功能。 对SIP网络和PSTN互通的支持请参见第7章。
7. SIP网络与PSTN的互通
SIP是实现VoIP的关键协议之一，对基于SIP的网络来说，必须要实现与传统PSTN的互通。目前只考虑SIP协议与PSTN中ISUP信令的互通。
当被叫为PSTN用户时，如没有特殊业务需求，对18*消息需要提供可靠传输。
7.1 网络互通模型
根据主被叫所在的网络，ＳＩＰ网络和ＰＳＴＮ网络的互通分以下几种情况：
１． 自ＰＳＴＮ发起的呼叫，经过ＳＩＰ－ＩＳＵＰ互通单元，终止在ＳＩＰ用户（如ＳＩＰ电话机）； ２． ＳＩＰ用户发起的呼叫，经过ＳＩＰ－ＩＳＵＰ互通单元，终止在ＰＳＴＮ用户；
３． ＳＩＰ网络被作为ＳＩＰ－ＩＳＵＰ互通单元之间的传输网络来使用，呼叫自ＰＳＴＮ发起，也
在ＰＳＴＮ落地，但是中间要经过ＳＩＰ网络；
４． ＰＳＴＮ作为ＳＩＰ网络之间的传输网络来使用，呼叫自ＳＩＰ网络发起，也在ＳＩＰ网络
落地，但是中间要经过ＰＳＴＮ。（该情况暂不考虑）
在以下的互通模型中，假定完成互通的逻辑实体位于两个不同的物理实体，同时不考虑中间存在其他物理实体的行为（例如中间存在Proxy，完成消息的转发）。
７．１．１ ＰＳＴＮ用户－ＳＩＰ用户
NNI ISUP SIP-ISUP 互通实体 SIP 代理 服务器* TDM IP
图 7-1 PSTN用户-SIP用户
此时NNI接口上可能存在SIP或SIP-I，由于我们禁止SIP终端能够接受SS7消息，因此如果NNI采用SIP-I，对Proxy行为动作的要求将会违背RFC3261的规定，同时某些消息的产生（例如INFO消息）可能并不能指导实体的具体行为，因此，在该种情况下，建议NNI接口上采用SIP，此时需要中国电信对SIP用户号码做一个全网的规划，以便初始局的SIP-ISUP互通单元接收到请求后能够判别出此用户为SIP用户，然后向前向发送SIP消息。
因此对于主叫为PSTN用户的情况，如果主叫侧SIP-ISUP互通单元能够分析出被叫用户为SIP用户，则NNI接口上采用SIP消息，否则NNI接口上将采用SIP-I消息。
基于该种前提，对PSTN—SIP的情况下的发端、接受端行为，我们做如下规定：
７．１．１．１ 发送端（ＳＩＰ－ＩＳＵＰ互通单元）行为
SIP-ISUP互通单元需完成ISUP与SIP之间的映射。
７．１．１．２ 接收端（Ｐｒｏｘｙ）行为
Proxy能够正确处理SIP消息
消息和参数的具体映射会在第二部分叙述，信令流程在第三部分描述。
７．１．２ ＳＩＰ用户－ＰＳＴＮ用户
如图6-2所示，此时代理服务器与SIP-ISUP互通单元之间的NNI采用SIP消息。
消息和参数的具体映射会在第二部分叙述，信令流程在第三部分描述。
NNI
代理 服务器 SIP SIP-ISUP 互通实体 ISUP IP TDM
图 7-2 SIP用户-PSTN用户
７．１．２．１ 发送端（代理服务器）行为
发送端的代理服务器对消息的处理应当遵从正常的SIP消息处理过程。
７．１．２．２ 接收端（ＳＩＰ－ＩＳＵＰ互通单元）行为
接收端的SIP-ISUP互通单元完成SIP与ISUP之间的映射。同时由SIP-ISUP互通单元发出的后向SIP消息也不需要带ISUP封装。
７．１．３ ＰＳＴＮ用户－ＳＩＰ网络－ＰＳＴＮ用户
如图6-3所示，SIP-ISUP互通单元之间的NNI采用SIP-I。
消息和参数的具体映射会在第二部分叙述，信令流程在第三部分描述。
NNI ISUP SIP-ISUP 互通实体 SIP-I SIP-ISUP 互通实体 ISUP TDM IP IP TDM
图 7-3 PSTN用户-SIP网络-PSTN用户
SIP-ISUP互通单元在收到ISUP消息之后，首先完成ISUP到SIP的映射，然后还要对ISUP消息进行封装，最后发送SIP-I消息到SIP网络。
SIP-ISUP互通单元在收到SIP-I消息后，要终止SIP-I消息，从其消息体中取出ISUP消息；若ISUP的某些参数与SIP消息的头部信息不一致，应根据SIP的头部信息对这些ISUP参数进行修改；SIP-ISUP互通单元还可能进一步修改ISUP消息；最后发送相应的ISUP消息到PSTN。
７．１．３．１ 发送端（ＳＩＰ－ＩＳＵＰ互通单元）行为
1. 发送初始请求消息（SIP-I消息）
1) 对收到的IAM消息进行分析映射，生成Invite消息的头部字段，以便完成选路。同时对ISUP消息进行封装。 2. 呼叫建立过程中的消息
1) 如果接收到的响应消息为18*、200，需要根据接收到SIP-I消息中封装的ISUP消息生成相应的ISUP消息；
2) 如果接收到的响应消息为4**、5**、6**消息，则根据接收到SIP-I消息中封装的ISUP消息生成相应的ISUP消息。 3) 如果在收到200 OK响应前，接收到了PSTN侧的CPG消息（启动呼叫保持业务），应映射成UPDATE 消息，并对CPG进行封装。 3. 呼叫成功后的行为
1) 如果收到CPG消息（启动呼叫保持业务），则生成INVITE消息，并对CPG进行封装。
2) 如果收到封装有CPG消息的INVITE消息，则生成相应的CPG消息 4. 挂机行为
1) 如果主叫用户在被叫没有应答的情况下挂机，如果接受到的18*消息没有建立Early media，则REL消息映射成Cancel消息，此时Cancel消息中不带有REL封装；否则REL消息映射成BYE消息，并对REL消息进行封装。
2) 如果呼叫成功，主叫用户挂机，需要将REL消息对应到SIP的BYE消息，并对REL消息进行封装。
3) 如果被叫用户挂机，发送端的SIP-ISUP互通单元根据BYE消息生成REL消息；同时作为响应，将生成的带有RLC封装的200消息发送到对端 5. 特殊情况的处理
1) 涉及到一些中间信令需要生成INFO消息；接收到对端的INFO消息后能够生成相应的ISUP消息
2) 从PSTN侧接收到类似于拆线的其他信号（RSC或面向硬件的CBG消息），根据呼叫状态生成相应的SIP消息；或根据收到的SIP消息生成拆线信号
７．１．３．２ 接收端（ＳＩＰ－ＩＳＵＰ互通单元）行为
1． 生成初始请求消息（ISUP消息）
1) 接收端的SIP-ISUP互通单元接收到Invite消息后，生成IAM消息。 2． 呼叫建立过程产生的响应消息
1) 由于网络问题或其他问题产生4**、5**、6**消息，发送到对端，并在响应中封
装REL消息。
2) 根据PSTN网络中产生的后向消息（ACM、ANM、CPG），生成相应的带ISUP
封装的SIP-I消息 3． 呼叫成功后的行为
1) 如果收到CPG消息（启动呼叫保持业务），则生成INVITE消息，并对CPG进行封装。
2) 如果收到封装有CPG消息的INVITE消息，则生成相应的CPG消息 4． 挂机行为
1) 如果主叫用户挂机，接收端的SIP-ISUP互通单元根据BYE或CANCEL消息，生
成REL消息，发送到PSTN侧；如果接收到BYE消息，需要同时向对端回应带有RLC封装的200消息。 2) 如果被叫用户挂机，接收端的SIP-ISUP互通单元根据REL消息，生成带REL封
装的BYE消息。 5． 特殊情况处理
1) 涉及到一些中间信令需要生成INFO消息；接收到对端的INFO消息后能够生成相应的ISUP消息
2) 从PSTN侧接收到类似于拆线的其他信号（RSC或面向硬件的CBG消息），根据呼叫状态生成相应的SIP消息；或根据收到的SIP消息生成拆线信号
7.2 SIP-ISUP互通单元能力要求
由网络互通模型可以看出，在信令控制方面，SIP-ISUP互通单元要完成ISUP信令和SIP/SIP-I信令的转换；在媒体方面，它要完成基于TDM的语音流与基于IP的语音流的转换。该参考模型只是逻辑模型，在实际中，信令转换的功能可以由媒体网关控制器（MGC）完成，媒体流转换的功能通常是由的媒体网关（MG）完成，MGC通过MGCP或H.248来控制MG，具体内容参见其它相关规范。
根据SIP-ISUPSIP-ISUP互通单元SIP域一侧的具体情况，SIP-ISUP互通单元有三种能力集配置：
－ 配置A：适用于ISUP与3GPP中的SIP的互通 － 配置B：适用于ISUP与普通SIP的互通 － 配置C：适用于ISUP与SIP-I的互通
8. 业务和应用
8.1 B2BUA
８．１．１ 定义及实现
B2BUA是一个逻辑实体，它可以接收SIP请求并像UAS那样处理它们。为了决定如何应答一个请求，B2BUA又向别的实体发送请求，此时它扮演了UAC的角色。B2BUA需要维护对话（Dialog）的状态，并处理所有在它所建立的对话中发送的请求消息。
为了尽可能地实现业务的透明传输，建议除非业务和应用控制（例如安全性的考虑或网间接口局）的需要，原则上B2BUA不能改变From域和To域的SIP URI部分、以及其它有可能影响业务透明传输的消息组成部分。
８．１．２ 呼叫和业务控制
由于B2BUA保留了呼叫状态，并且可以象UA那样灵活处理消息，所以它可以用来实现呼叫控制和一些需要呼叫状态信息的业务控制。
当SIP B2BUA用于实现呼叫和业务控制功能时，它的能力同它所能支持的具体业务和应用相关，但B2BUA应当支持下列通用性协议:
1． RFC3261, “Session Initiation Protocol”（必须） 2． RFC3262, “Reliability of Provisional Response in Session Initiation Protocol (SIP)”（必
须）
3． RFC32, “An Offer/Answer Model with the Session Description Protocol (SDP)”（必
须）
4． RFC 3311, “The Session Initiation Protocol UPDATE Method”（必须） 5． RFC3325, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks”（必须）
6． RFC 3312, “Integration of Resource Management and Session Initiation Protocol (SIP)”（可选） 7． RFC3265, “Session Initiation Protocol (SIP)-Specific Event Notification”（可选） 8． RFC3323, “A Privacy Mechanism for the Session Initiation Protocol”（可选） 9． RFC3326, “The Reason Header Field for Session Initiation Protocol (SIP)”（可选） 10． draft-ietf-sipping-3pcc-03.txt, “IETF Draft for 3rd party call control”（可选） 11． Session Timer”（建议实现） 8.2 即时消息 ８．２．１ 业务体系 基于SIP协议的即时消息应当支持RFC3428协议所规定之功能。具体实现时，可包括 单纯的基于文字形式的即时消息，也可与其他业务相结合，如Presence业务。 ８．２．２ 协议支持 提供基本的即时消息时，系统应当支持以下通用协议： 1. RFC3261, “Session Initiation Protocol” 2. RFC3428，“Session Initiation Protocol (SIP) Extension for Instant Messaging” 3. RFC2778 “A Model for Presence and Instant Messaging” 8.3 Presence ８．３．１ 业务体系 Presence Server 软交换 Presence Agent Presence Agent Registar SIP终端 SIP终端 其他终端 watcher Presentity watcher Presentity 图 8-1基于SIP 的Presence 业务体系 Presence业务是一种辅助通讯手段，通过Presence业务，一方面Presence业务用户可以使自己的状态被选定的联系对象所知道，另一方面Presence业务用户也可以知道自己的联系对象的状态，从而选择合适的通信手段或者时段和对方通信。 如图所示，基于SIP 的Presence业务逻辑实体主要包括：Watcher, Presentity, Presence Agent. Watcher：通过呈现业务向Presentity获取呈现状态信息的逻辑实体，一般驻留在客户终端侧。 Presentity：为呈现业务提供呈现状态信息的逻辑实体，一般驻留在客户终端侧。 Presence Agent：呈现业务代理，可以接受和发送呈现业务消息，收集Presentity的呈现状态信息，发送呈现状态信息给相应的Watcher。 基于SIP 的Presence 物理实体结构一般包括SIP用户终端、软交换、Presence服务器和其他终端。 SIP用户终端包含Watcher和Presentity两类逻辑实体。 Presence服务器包含Presence Agent逻辑实体，起到用户的Presence代理作用。 软交换在Presence业务体系下包含Presence Agent逻辑实体。 其他终端主要是指软交换下的非SIP终端。 除了其他终端和软交换之间外，Presence业务体系中各逻辑实体之间都是标准的SIP接口。 Presence业务主要拥有以下业务特征： 1. Presence业务用户需要进行鉴权、订阅的过程方可使用该业务 2. 用户可以管理和维护自己的联系对象名单 a) 可以在联系对象中可以进行分组设定 b) 可以在联系对象中的某个组中增加、删除某个联系对象 c) 可以在黑名单中添加或删除某一个联系对象 d) 可以根据一定的筛选条件查询符合条件的联系对象 注：此功能的部分内容已经超出了SIP协议规范的范畴，建议可考虑SIP协议结合XCAP协议的实现方式。 3. 可以设定自己的昵称和其他信息 4. 可以设定自己为屏蔽状态或从屏蔽状态恢复正常，在屏蔽状态下，用户的联系对象 将无法获得其状态信息。 5. 在非屏蔽状态下，当Presence业务用户状态发生改变时，应该可以通知其联系对 象 6. 处于非屏蔽状态下的联系对象状态发生改变时，应该可以通知Presence业务用户 7. 用户可以选择自己的状态信息，用户除了基本的状态信息（如离线、忙、闲）外， 还可以从系统已定义的状态列表中选择自己的状态信息，并通知其联系对象。 ８．３．２ 协议支持 基于SIP的Presence业务需要支持下列协议： 1. 2. 3. 4. RFC3261, “Session Initiation Protocol” RFC3265, “Session Initiation Protocol (SIP)-Specific Event Notification” RFC2278，“A Model for Presence and Instant Messaging” draft-ietf-simple-presence-09.txt, “A Presence Event Package for the Session Initiation Protocol (SIP)” 5. draft-ietf-simple-event-list-04.txt, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists” 6. draft-ietf-simple-winfo-package-05.txt, “A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)” 7. draft-ietf-simple-winfo-format-04.txt, “An Extensible Markup Language (XML) Based Format for Watcher Information” ８． draft-ietf-simple-publish-reqs-00.txt, “SIMPLE Presence Publication Requirements” 9. draft-ietf-simple-publish-01, “Session Initiation Protocol (SIP) Extension for Presence Publication” 10. draft-ietf-simple-xcap-00，“The Extensible Markup Language (XML) Configuration Access Protocol(XCAP)” 11. IETF draft-ietf-sipping-reg-event-00.txt “A Session Initiation Protocol (SIP) Event Package for Registrations” 12. draft-ietf-impp-cpim-pidf-07.txt “Common Presence and Instant Messaging (CPIM) Presence Information Data Format” ８．３．３ 与其他业务相结合 在提供Presence业务的基础上，Presence业务用户之间或与其他终端用户可以发送即时消息、拨打电话等。 当Presence业务A用户被Presence业务B用户列为黑名单后，此时B用户将无法与A用户通话，同时B用户发送的即时消息将不会发送到A用户。其他情况，将不会影响即时消息业务。 8.4 并行、串行寻址 在SIP网络中，网络服务器接收到一个请求后，可通过串行或并行的形式向用户发送请求，业务表现上为串行振铃或并行振铃。本规范对实现该功能的网络服务器作如下功能要求： ８．４．１ 串行寻址： Ø 18*信号由网络服务器产生，并仅向主叫方发送一次。 Ø 根据实际运营的需要，18*信号可在未知用户状态的情况下发送（类似于Early Acm），也可在已知用户状态的情况下发送 Ø 回铃音由主叫用户或主叫侧媒体资源服务器提供 Ø 如果与目标地址集中的某一地址建立联系失败，服务器不应当后向发送失败消息 （接收到6**消息的情形除外），而应继续尝试与下一个地址建立联系，直到成功或全部失败。 ８．４．２ 并行寻址 Ø 18*信号由网络服务器产生，并仅向主叫方发送一次，在发送200消息前，网络服 务器需要对接收到的18*信号进行缓存。 Ø 根据实际运营的需要，18*信号可在未知用户状态的情况下发送（类似于Early Acm），也可在已知用户状态的情况下发送 Ø 回铃音由主叫用户或主叫侧媒体资源服务器提供。 Ø 如果其中任意一个地址接受呼叫，该网络服务器应当向其他地址发送Cancel消息， 如果由于网络时延而导致在网络服务器（实现Fork处）处接收到多个200消息，网络服务器应当将后续的200消息拒绝掉，不应当向后向转发。 实现该业务的用户可包括SIP用户、IAD用户、PSTN用户、手机用户。 建议从业务的层面实现该功能，用户可根据自己的意愿定义各个终端的优先级别（而不是单单依靠终端注册时的q值），体现业务的灵活性。 8.5 SIP用户的呼叫等待业务 对于可运营的网络，需要网络对用户或终端具有可控性、可管理性，因此用户的呼叫状态（例如通话状态、空闲状态等）应当在网络设备上有所表现。 基于以上前提，如果用户启动呼叫等待业务，需要通过某种方式告知网络设备。由于SIP终端触发业务的方式并不能像原有PSTN终端通过“*”、“#”的方式实现，因此假定用户通过网页登记的方式实现业务的登记，对呼叫等待业务有如下要求： 1. 目前要求该业务通过终端实现 2. 业务属性的描述应当满足以下要求（用户A、B处于通话状态，C用户呼叫A用户）： Ø 用户A拒绝C用户的呼叫 Ø 用户A保持与B用户的通话，改与C用户通话 Ø 用户A结束与B用户的通话，改与C用户通话 8.6 应用服务器和软交换之间的SIP接口 建议应用服务器和软交换之间能够提供SIP接口，使应用服务器能够通过SIP对软交换进行呼叫或会话控制。 8.7 SIP协议在业务控制方面的应用 SIP协议通常与SDP协议配合用来在两个或多个端点间建立语音或多媒体会话。由于SIP协议清晰地将会话建立和会话描述区分开来，利用SIP协议在两个或多个端点间所建立的“会话”，并不局限于控制语音媒体流，也可用SIP协议创建和管理各种用于业务控制的“会话”。具体业务应用可包括： 1. 用SIP协议完成对会议的管理，包括创建会议，结束会议，添加或删除会议成员，保 持会议中的成员。 2. 第三方通过SIP协议控制服务器完成其他端点间的接续。具体业务包括：Click to dial、 Click to conference、Click to Fax、POP screen及其控制（如，Call hold、Call Forward、Forward to voice mail等）、Click to listen voice mail； 8.8 跨域智能业务的考虑 当软交换控制下的用户通过SIP网络中的业务平台实现智能业务（例如200智能业务）时，且主、被用户处于不同的软交换控制时，其基本要求如下： 1. 主叫用户首先与业务平台建立会话 2. 负责业务控制的SIP网络实体，在向真正的被叫用户发起呼叫路由时，To域中的 地址为真正的用户地址 3. 负责业务控制的SIP网络实体应当充当UA的功能，根据被叫侧发送的消息采取 相应的动作： Ø 当接收到的第一个可靠响应中带有SDP时，负责业务控制的SIP网络实体应 当告知主叫用户完成媒体地址的切换（如果主叫用户为SIP用户，通过发送re-INVITE消息；如果主叫用户为PSTN或IAD用户，通过相应的H.248或MGCP协议） Ø 当收到被叫侧的拆线信号时且不需要向主叫侧播放语音通知时，负责业务控 制的SIP网络实体向主叫侧发送拆线信号。 8.9 软交换控制下的IAD用户对局间信令的要求 在NGN中，软交换携带的用户除了SIP用户外，还有可能为IAD或AG用户。由于IAD或AG在将来可能提供类似于目前Class 5交换局的功能，为了确保对原有传统业务的支持，软交换在进行信令处理时，应当将IAD或AG用户作为一个PSTN用户看待，并根据第7 章中描述的互通模型，决定与其它软交换之间的NNI接口采用SIP还是SIP-I。 以下说明的用户分别位由两个软交换控制： 1. SIP与IAD用户之间的互通，NNI接口采用SIP 2. IAD与PSTN用户的互通，NNI接口采用SIP-I 3. IAD与IAD用户之间的互通，NNI接口采用SIP-I 8.10 语音提示音的播放 假定网络架构为两个软交换，两个软交换之间采用SIP或SIP-I。 由于振铃音或其他提示音的播放位置不同，对整个流程的影响将不同。鉴于这种情况，对语音资源的播放位置作如下原则性规定： Ø 180信号指示本地或远端播放振铃音，通过183信号建立后向通道播放被叫方提供 的语音资源 Ø 如果被叫用户为PSTN用户 1. 回铃音由被叫端局提供。当被叫软交换接收到ACM的BCI为“用户空”或CPG 的Event indicator为“提示”时，后向发送180信号（如果此前没有建立媒体通道，此时需要建立后向媒体通道） 2. 当SIP-ISUP互通单元采用A或B配置，如果ACM中BCI非“用户空”且OBCI 为“带内音或适当的码型目前可用”（对CPG，Event indicator为“带内音或适当的码型目前可用”）时，后向发送183信号（带有被叫软交换控制下的媒体网关地址） 3. SIP-ISUP互通单元采用C配置的行为准则参照Q.1912的描述 Ø 如果被叫用户为SIP或IAD用户 1. 回铃音或其他失败音信号（例如忙音等普通的音信号）由主叫方处理 2. 根据业务需要，如果被叫处需要播放语音资源音（例如，被叫用户忙等语音资 源）的情况，通过183向主叫侧播放该语音通知 Ø 如果在被叫用户应答之前，主、被叫之间建立媒体通道，后续发生需要更改媒体连 接地址的情况，此时通过UPDATE的方式对媒体地址进行修改 Ø 根据以上原则，如果被叫为PSTN用户，必须支持RFC3262（特殊业务需求除外） 被叫用户 PSTN用户 主叫用户 回铃音 PSTN用户 被叫端局 （带有ＳＤＰ的１８０消息） 语音资源播放位置 失败情况下的语音通知 失败情形可以分为３大类：被叫ＰＳＴＮ网络处直接发送ＲＥＬ拆线信号、被叫ＰＳＴＮ网络处播放相关的语音提示呼叫失败、作为承载功能的ＳＩＰ网络发起拆线信号： １． 如果被叫ＰＳＴＮ网络发出ＲＥＬ拆线２． 如果被叫端局通过ＡＣＭ或ＣＰＧ信号发送相关语音通知（例如当前用户不在服务区内等），则被叫侧通过带有ＳＤＰ的１８３（主要根据ＡＣＭ或ＣＰＧ中的ＢＣＩ和ＯＢＣＩ参数的判别）信号建立后向通 备注 此时主、被叫软交换相当于四类局，因此如果出现失败，没有考虑通过主叫侧媒音通知的情况 信号，相关的语音通知由主叫端局发送 体网关发送语 道 ３． 如果拆线由作为承载的ＳＩＰ网络发起，此时语音通知或失败信号可由主叫端局提供 SIP用户 被叫端局 （通过带有ＳＤＰ的 失败情形可以分为３大类：被叫ＰＳＴＮ网络处直接发送ＲＥＬ拆线信号、被叫ＰＳＴＮ网络处播放相关的语音提示呼叫线信号： １． 如果被叫ＰＳＴＮ网络发起ＲＥＬ拆线信 号，网络服务器可仅仅透传失败消息到主叫用户，也可由主叫侧媒体资源服务器向主叫用户播放相关的语音通知（通过１８３信号） ２． 如果被叫端局通过ＡＣＭ信号发送相 关语音通知（例如当前用户不在服务区内等），则被叫侧通过带有ＳＤＰ的１８３信号（主要根据ＡＣＭ或ＣＰＧ中的ＢＣＩ和ＯＢＣＩ参数的判别）建立后向通道 ３． 如果拆线原因由作为承载的ＳＩＰ网 络发起，网络服务器可仅仅透传失败消息到主叫用户，也可由主叫侧媒体资源服务器向主叫用户播放相关的语音通知（通过１８３信号） IAD用户 被叫端局 （带有ＳＤＰ的１８０消息） 失败情形可以分为３大类：被叫ＰＳＴＮ网络处直接发送ＲＥＬ拆线信号、被叫ＰＳＴＮ网络处播放相关的语音提示呼叫失败、作为承载功能的ＳＩＰ网络发起拆线信号： １． 如果被叫ＰＳＴＮ网络发出ＲＥＬ拆线信 号，相关的语音动作可由主叫侧进行处理 ２． 如果被叫端局通过ＡＣＭ信号发送相 关语音通知（例如当前用户不在服务区内等），被叫侧软交换发送带有ＳＤＰ的１８３信号（主要根据ＡＣＭ或ＣＰＧ中的ＢＣＩ和ＯＢＣＩ参数的判别）建立后向通道 ３． 如果拆线由作为承载的ＳＩＰ网络发 起，，相关的语音动作可由主叫侧进行处理 SIP用户 PSTN用户 主叫侧媒体网关。 呼叫失败的语音通知或语音信号（失败原因由被叫用户引起或网络设备引起） 此时主叫叫软交换相当于四 如果允许主叫侧媒体资源服务器播放语音通知，可能导致播放两次语音的情况 １８０消息） 失败、作为承载功能的ＳＩＰ网络发起拆 此时被叫 软交换相当于四类局，因此如果出现失败情况，没有考虑通过被叫侧媒体网关发送语音通知的情况 （180消息） 可由主叫侧或被叫侧提供： 1． 如果语音通知由被叫侧提供，被叫 侧软交换发送带有SDP的183信号建立后向通道（183信号可为其下的媒体资源服务器的地址） 2． 否则失败音信号由主叫端局提供 类局，没有考虑通过主叫侧媒体网关发送语音通知的情况 SIP用户 主叫用户 （180消息） 1． 如果语音通知由被叫侧提供，被叫 侧软交换发送带有SDP的183信号建立后向通道（183信号可为其下的媒体资源服务器的地址） 2． 否则可由主叫用户本端发送相应的 失败音信号 IAD用户 主叫用户 （180消息） 1． 如果语音通知由被叫侧提供，被叫 侧软交换发送带有SDP的183信号建立后向通道（183信号可为其下的媒体资源服务器的地址） 2． 否则由主叫侧进行处理 在失败的情况下，可能导致主叫侧、被叫侧两次播放语音通知 IAD用户 （假设回铃音不由被叫侧提供） PSTN用户 主叫侧媒体网关 （180消息） 呼叫失败的语音通知或音信号（失败原因由被叫用户引起或网络设备引起）可由主叫侧或被叫侧提供： 1． 如果语音通知由被叫侧提供，被叫 侧软交换发送带有SDP的183信号建立后向通道（183信号可为其下的媒体资源服务器的地址） 2． 否则失败音信号由主叫端局提供 此时主叫叫软交换相当于四类局，没有考虑通过主叫侧媒体网关发送语音通知的情况 SIP用户 主叫用户 （180消息） 呼叫失败的语音通知或音信号（失败原因由被叫用户引起或网络设备引起）可由主叫侧或被叫侧提供： 1． 如果语音通知由被叫侧提供，被叫 侧软交换发送带有SDP的183信号建立后向通道（183信号可为其下的媒体资源服务器的地址） 2． 否则由主叫侧进行处理 IAD用户 主叫用户 （180消息） 呼叫失败的语音通知或音信号（失败原因由被叫用户引起或网络设备引起）可由主叫侧或被叫侧提供： 1． 如果语音通知由被叫侧提供，被叫 侧软交换发送带有SDP的183信号建立后向通道（183信号可为其下的媒体资源服务器的地址） 2． 否则由主叫侧进行处理
因篇幅问题不能全部显示，请点此查看更多更全内容
Copyright © 2019- 517ttc.cn 版权所有 赣ICP备2024042791号-8
违法及侵权请联系：TEL:199 18 7713 E-MAIL:2724546146@qq.com
本站由北京市万商天勤律师事务所王兴未律师提供法律服务