中国电信SIP规范第一分册-总体要求.doc

中国电信SIP 初始会话协议规范(第一分册)总体要求（暂行版）2004年4月发布 2004年4月试行中国电信集团公司发布前 言SIP协议是下一代网络中的接口协议之一，属于应用控制协议。本标准是以IETF和ITU-T的相关标准为基础，结合中国电信网络的实际情况，并综合中国电信集团公司对下一代网络的实验成果制定的。它是中国电信在下一代网络建设中引进、测试和研发软交换设备、SIP终端设备以及其他基于SIP协议相关设备的规范和依据。鉴于SIP协议应用范围广泛，项目组在编写时将整个协议规范分为3个分册：第一分册：总体要求第二分册：协议细则第三分册：信令流程本分册为总体要求分册本标准由中国电信集团公司提出。本标准由中国电信集团公司归口。本标准于2004年4月首次发布。本标准由中国电信集团公司负责解释目 录1范围12术语说明13参考标准14符号及缩写35SIP网络系统结构45.1系统框架45.2实体说明55.3接口说明55.3.1NNI接口55.3.2UNI接口55.3.3其它接口56实体能力要求66.1用户终端（User Terminal UA）66.1.1协议支持66.2代理服务器（Proxy）66.2.1协议支持76.2.2路由76.2.3安全性76.3注册服务器（Registrar）86.3.1协议支持86.3.2功能要求86.3.3注册及更新86.3.4注销86.3.5其他要求96.4重定向服务器（Redirect Server）96.5SIP-ISUP互通单元97SIP网络与PSTN的互通97.1网络互通模型107.1.1PSTN用户-SIP用户107.1.2SIP用户-PSTN用户117.1.3PSTN用户-SIP网络-PSTN用户117.2SIP-ISUP互通单元能力要求138业务和应用148.1B2BUA148.1.1定义及实现148.1.2呼叫和业务控制148.2即时消息148.2.1业务体系148.2.2协议支持158.3Presence158.3.1业务体系158.3.2协议支持168.3.3与其他业务相结合178.4并行、串行寻址178.4.1串行寻址：178.4.2并行寻址178.5SIP用户的呼叫等待业务188.6应用服务器和软交换之间的SIP接口188.7SIP协议在业务控制方面的应用188.8跨域智能业务的考虑188.9软交换控制下的IAD用户对局间信令的要求198.10语音提示音的播放198.11媒体端口打开与计费点启动的考虑19图 51 SIP网络系统逻辑结构示意4图 71 PSTN用户-SIP用户10图 72 SIP用户-PSTN用户11图 73 PSTN用户-SIP网络-PSTN用户12图 81基于SIP 的Presence 业务体系15 中国电信SIP协议标准-总体要求1 范围本分册主要对SIP网络系统结构做出规定，对其中涉及到的接口以及相关实体的功能作出简要说明和要求。由于下一代网络需要融合PSTN网络，本规范对其中涉及到的互通模型作了说明，对每种模型涉及到的消息处理方式作出规定。本分册同时还对一些业务和应用，例如B2BUA、Presence、Fork等作出框架性说明。1) 本规范暂不要求支持Tel-URL，Absolute URI，SIPS-URI，TLS， S/MIME，SCTP。2) MPEG4的SDP描述顺从RFC3016的描述。3) T.38传真的SDP描述顺从T.38的Annex D4) 对会话属性进行修改的行为有如下要求：re_INVITE用在Dialog已建立的环境；UPDATE用在已建立Early Dialog或没有建立Dialog的环境5) 暂不要求支持多播（multicast）和IPv6。6) 暂不允许终端通过OPTIONS消息查询网络实体的能力。7) 暂不允许网络实体之间进行鉴权的行为。8) 暂不允许在UNI接口上出现SIP-I消息9) 如果18*消息中带有SDP信息，要求可靠传送10) 网络服务器在处理用户请求前应当确认该用户为合法用户，否则拒绝处理该用户的任何请求2 术语说明本规范中，“暂不要求”指的是某种行为或情形目前暂时不要求实现，当所涉及的行为发生时，实体可以拒绝并给予响应。“暂不允许”表明该种行为当前不允许发生，当所涉及的行为发生时，实体必须拒绝并给予响应。 在SIP域内存在一个账号下绑定多个地址的情况，即对同一个SIP账号，可寻址的终端包括多个，在本规范中将该种情况称为“同一个用户下的多个终端”本规范列出了各个SIP逻辑实体所需支持的规范，但仅仅局限于逻辑实体的基本动作，不覆盖所有业务的需求。以下术语主要有以下几个含义： 必须：表明实体必须满足相关规范之规定，如果中国电信对该规范存在修改，需满足修改后的规范之规定。由于所有标准都存在修改的可能，使用本标准的各方应当探讨使用引用标准最新版本的可能性。 可选：表明目前可能没有明确要求，但不排除以后的行为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.164 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 RFC3264 “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 RFC3489 “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)”37)38) IETF draft-ietf-impp-cpim-pidf-07.txt “Common Presence and Instant Messaging (CPIM) Presence Information Data Format39) 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 64kbit/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”47) 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封装的SIPUA：用户代理UNI：用户-网络接口 IAD：综合接入设备AG：接入网关MGC：媒体网关控制器（软交换机）MG：媒体网关B2BUA：背靠背用户代理PSTN：公共电话交换网TLS：传输层安全URI：统一资源标示符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网络系统的逻辑结构参见图 51。图 51 SIP网络系统逻辑结构示意5.2 实体说明RFC3261中定义的SIP逻辑实体包括用户代理（UA, User Agent），代理服务器（Proxy），注册服务器（Registrar），重定向服务器（Redirect Server）， B2BUA（Back-to-Back User Agent）。各逻辑实体的定义参见RFC3261。B2BUA实质上是SIP UA的一种应用，是一种特殊的SIP逻辑实体，适用于SIP网络中需要呼叫和业务控制的场合，相关分析参照8.1节。5.3 接口说明5.3.1 NNI接口下列位置的NNI接口同SIP网络的路由、SIP网络与PSTN的互通等问题密切相关，对代理服务器、B2BUA和SIP-ISUP互通单元的能力要求有着重要的影响，故将其作为关键的NNI接口识别出来。涉及到的实体与协议主要包括：1) SIP Proxy之间：SIP或 SIP-I2) SIP Proxy与SIP-ISUP互通单元之间：SIP或SIP-I3) SIP-ISUP互通单元之间：SIP-I4) SIP B2BUA之间：SIP或SIP-I5) SIP Proxy与SIP B2BUA之间：SIP或SIP-I6) SIP-ISUP互通单元与SIP B2BUA之间： SIP或SIP-I 本规范建议网络实体间建立信任关系，因而暂不要求NNI接口支持网络实体间的鉴权和授权功能。5.3.2 UNI接口 下列位置的UNI接口是连接SIP用户和SIP网络的主要接口，对SIP用户终端和相关网络实体的能力要求有着重要的影响，故将其作为关键的UNI接口识别出来：1) SIP 用户终端UA与SIP Proxy之间：SIP2) SIP 用户终端UA与SIP B2BUA之间: SIP5.3.3 其它接口 5.3.3.1 位置服务器相关接口位置服务器与注册服务器、位置服务器与代理服务器（或重定向服务器）与之间的接口为私有接口。5.3.3.2 未识别的接口根据有关实体的物理组合情况，在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终端用户之间的鉴权和授权处理。6.1.1 协议支持 用户终端所应支持的协议同它的业务能力相关，但需要支持下列通用性协议：1) RFC2327, “SDP: Session Description Protocol”（必须）2) RFC3261, “Session Initiation Protocol”（必须）3) RFC3262, “Reliability of Provisional Response in Session Initiation Protocol (SIP)”（必须）4) RFC3264, “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”（建议实现）当终端支持Presence和即时消息业务时，需要支持的协议请参见第8章“业务和应用”的相关内容。6.2 代理服务器（Proxy）代理服务器是SIP网络的中间实体，为了处理客户端的请求，它既承担服务器的角色又承担客户端的角色。对其的主要要求包括： 路由处理，即保证将请求消息发送到离目标用户更近的其它实体。 为了满足电信运营的需要，直接管理用户的代理服务器（类似于目前的5类端局）应当具备获知其下用户状态（例如忙、闲等）的功能（仅局限用户带一个SIP终端的情况，具备Fork功能的代理服务器对此功能不做强制要求），并结合用户的业务属性实现相应的业务 代理服务器还可用于管理策略的实施，比如确认某个用户是否允许发起呼叫等。 代理服务器在转发一个请求消息前需要识别和解释该消息的某些特定组成部分，并在需要的时候改写它们。 当代理服务器具备Fork功能时，功能要求参照8.4节相关之规定。本规范对无状态的代理服务器（Stateless Proxy）暂不要求。建议实现保留呼叫状态的代理服务器（Call stateful Proxy）6.2.1 协议支持代理服务器需要支持下列协议：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”（建议实现）6.2.2 路由6.2.2.1 功能代理服务器应提供多种路由方式以满足不同的路由实现需求。路由处理可以基于RFC3263所述的DNS 查询机制来完成，也可以基于本地的特定路由策略来完成。当代理服务器基于本地路由策略来完成NNI侧的路由处理时，必须支持如下两种功能:1) 基于域名的路由：根据Request-URI host部分的目标域名得到下一跳的URL或IP地址2) 基于号码的路由：根据Request-URI user部分的电话号码得到下一跳的URL或IP地址6.2.2.2 策略代理服务器要能通过管理配置的手段来提供灵活的本地路由策略。目前应支持的策略有:1) 动态策略：基于一天中不同的时间段进行下一跳的路由选择2) 静态策略：基于下一跳路由实体（代理服务器或网关等）的权重进行路由选择，也可在权重的基础上附加一定的算法3) 动静结合：动态策略和静态策略结合使用。例如，针对某一时间段内多个可选的下一跳路由实体，可以再根据它们的权重进行路由选择，等等6.2.3 安全性6.2.3.1 NNI侧 代理服务器应当通过管理配置的手段在NNI侧建立一个信任的网络实体（代理服务器，SIP-ISUP互通单元等）列表。通过与其它网络实体建立信任关系/模型，代理服务器在NNI上避免了频繁的鉴权处理，满足了RFC3323、RFC3325、Q.1912.5.等SIP相关规范的需求。 代理服务器在NNI上只能接收来自信任实体的SIP-I消息，同时也只能向信任实体发送SIP-I消息。6.2.3.2 UNI侧代理服务器和用户终端UA之间必须支持HTTP Digest鉴权过程。代理服务器在UNI侧不能向SIP用户终端发送带有ISUP封装的SIP消息，也不能接受来自SIP用户终端的带ISUP 封装的SIP消息。代理服务器应当对恶意用户建立黑名单，并支持相关的处理功能。代理服务器应当对鉴权失败的SIP用户终端建立监视列表，并根据具体情况采取相应的反攻击措施，例如拒绝来自某一用户终端的请求30分钟，如果他/她在两分钟内连续5次以上鉴权失败，等等，本规范不对具体实现作强制规定。6.3 注册服务器（Registrar）6.3.1 协议支持 注册服务器需要支持下列协议：1) RFC3261, “Session Initiation Protocol”（必须）（可选） 6.3.2 功能要求6.3.3 注册及更新由于注册请求中Contact地址的有效期过短会引起注册刷新消息的频繁，从而给网络带来沉重负担；存亡周期过长则不利于运营商对用户终端的控制，因此对于注册请求中存亡周期过短或过长的行为，注册服务器应当能够进行正确的处理。建议注册服务器允许注册请求中Contact地址有效期的下限为120秒/2分钟，上限为86400秒/24小时，但注册服务器应当具备对上限和下限取值可灵活配置的功能，根据实际运营和业务需求情况合理取值。如果注册请求中Contact地址的有效期为0或注册请求中不存在有效期的情况，应按RFC3261的具体规定处理；如果注册请求中的Contact地址的有效期小于下限，注册服务器应当回应以423错误响应，并在该响应消息的Min-Expires头域中指出服务器的建议值，在给予明确指示的情况下，如果终端仍然重发类似的请求消息，注册服务器应当判别是否属于恶意注册的行为；如果注册请求中Contact地址的有效期大于上限，则注册服务器自动将其减为上限，并在200 OK响应中包含修改后的有效期值。注册服务器应当支持由一台终端为同一用户下其他终端进行注册的行为（To、From域相同，Contact地址可能包括一个或多个），其后的更新由该终端完成。当用户发起地址查询时，注册服务器应当回应该用户所有当前注册的地址。6.3.4 注销 注册服务器应当支持由完成注册的终端发起的注销行为。如果同一个用户下有两个终端A、B，分别带有一个地址完成注册。用户通过A终端将B终端进行注销，当终端B再次发起对自己原有地址周期更新时，网络将回失败响应（可采用403 Forbidden消息），终端B收到失败响应消息后必须停止自动发送登记请求消息的行为。如果终端B发起的初始注册信息中包含多个地址，A终端对B终端的其中一个地址进行注销，对于B终端发起的周期更新消息，注册服务器应当回200 OK响应，200 OK响应消息中必须包含除被终端A注销的联络地址外的其他所有地址信息。终端B在后续的周期更新消息中必须不再带有自己已被注销的联络地址信息。 对注册服务器，如果同一终端两次发起的注册信息的Call-id不同，则认为该两次注册为两个独立的注册，不应当将其作为同一个注册的周期更新行为。 对SIP终端的要求将在中国电信SIP终端规范中体现。6.3.5 其他要求注册服务器应当具备防黑客攻击的能力，具体的实现方式本规范不作规定。暂不要求支持第三方（注册信息中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 网络互通模型根据主被叫所在的网络，SIP网络和PSTN网络的互通分以下几种情况：1) 自PSTN发起的呼叫，经过SIP-ISUP互通单元，终止在SIP用户（如SIP电话机）；2) SIP用户发起的呼叫，经过SIP-ISUP互通单元，终止在PSTN用户；3) SIP网络被作为SIP-ISUP互通单元之间的传输网络来使用，呼叫自PSTN发起，也在PSTN落地，但是中间要经过SIP网络；4) PSTN作为SIP网络之间的传输网络来使用，呼叫自SIP网络发起，也在SIP网络落地，但是中间要经过PSTN。（该情况暂不考虑） 在以下的互通模型中，假定完成互通的逻辑实体位于两个不同的物理实体，分别完成PSTN用户的接入和SIP用户的接入。同时假定中间不存在其他网络实体。 我们认为SS7信令为局间信令，不应当传送到用户侧，即在UNI接口上禁止有SS7信令的出现。接入PSTN用户的逻辑实体可以明确为SIP-ISUP互通单元，但接入SIP用户的逻辑实体可能为B2BUA也可能为Proxy，因此对接入SIP用户一侧的网络实体以物理实体进行规范要求。7.1.1 PSTN用户-SIP用户图 71 PSTN用户-SIP用户当主叫用户为PSTN用户，发端侧软交换进行路由选择时： 如果能够根据号码规则或其他方式判断出被叫用户为SIP用户，则此时NNI接口采用SIP 如果不能够判别出被叫用户为SIP用户，则此时NNI接口采用SIP-I7.1.1.1 发送端（SIP-ISUP互通单元）行为 如果NNI接口采用SIP，则SIP-ISUP互通单元需完成ISUP与SIP之间的映射。此时SIP-ISUP互通单元采用B配置 如果NNI接口采用SIP-I，则SIP-ISUP互通单元在完成ISUP与SIP映射的前提下，还应当完成ISUP消息的封装。此时SIP-ISUP互通单元采用C配置。SIP-ISUP互通单元的行为准则应当遵循C配置的要求。7.1.1.2 接收端行为 如果NNI接口采用SIP，则接收端将请求发送到被叫用户 如果NNI接口采用SIP-I，由于不允许UNI接口上出现SS7信令，因此此时接收端的软交换应当将SIP-I消息中的ISUP消息去除后，然后发送SIP消息到被叫用户。（软交换在逻辑功能上，可首先启动UA功能，然后启动Proxy功能；或启动B2BUA的逻辑功能）。为了保证前后信息的一致性，接收端软交换需要根据SIP用户发送的SIP消息生成ISUP消息后封装在SIP消息中发送到发送端。消息和参数的具体映射会在第二部分叙述，信令流程在第三部分描述。7.1.2 SIP用户-PSTN用户如图 72所示，此时代理服务器与SIP-ISUP互通单元之间的NNI采用SIP消息。消息和参数的具体映射会在第二部分叙述，信令流程在第三部分描述。图 72 SIP用户-PSTN用户7.1.2.1 发送端行为发送端SIP服务器对消息的处理应当遵从正常的SIP消息处理过程。7.1.2.2 接收端（SIP-ISUP互通单元）行为此时SIP-ISUP互通单元采用B配置。接收端的SIP-ISUP互通单元完成SIP与ISUP之间的映射。同时由SIP-ISUP互通单元发出的后向SIP消息也不需要带ISUP封装。7.1.3 PSTN用户-SIP网络-PSTN用户如图 73所示，SIP-ISUP互通单元之间的NNI采用SIP-I。消息和参