YD T 1522.1-2006 会话初始协议(SIP)技术要求.第1部分 基本的会话初始协议.pdf

《YD T 1522.1-2006 会话初始协议(SIP)技术要求.第1部分 基本的会话初始协议.pdf》由会员分享，可在线阅读，更多相关《YD T 1522.1-2006 会话初始协议(SIP)技术要求.第1部分 基本的会话初始协议.pdf（174页珍藏版）》请在麦多课文档分享上搜索。

1、日中华人民共和国通信行业标准YD厅1522.1-2006会话初始协议(SIP )技术要求第1部分:基本的会话初始协议Technical Requirments for Session Initiation Protocol Part 1 :Basic Session Initiation Protocol (IETF RFC 3261,2002,SIP:Session Initiation Protocol,NEQ) 2006斗2-11发布200701一01实施中华人民共和国信息产业部发布012345678901 A削123456789111111111122yorr 1522.1-2006

2、目录言. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .II 范围.I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 规范性引用文件. . . . . . . . . . 术语、定义和缩略i吾. . . .

3、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . t . . . . . . . . . . . . . . . . . . . . . . . .2 SIP协议结构. . . . . . . . -3 SIP消息. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4、. . . . . . . . . . . . . .4 用户代理(UA)的基本行为. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 请求的取消. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 注册.17能力查询. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

6、对话(Dialog)n会话发起过程.26会话更改过程.28会话结束过程.28代理服务器的行为.29SIP事务层4传输. . . . . . . . . . . . . . . . . . . . . . . . . . -. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . t . . . . . . . . . .49 普通的消息组成. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 头宇段. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ . . . . . . . . . . . . . . . . . . . . . . . . . .

8、. . . . . . . . .56 响应代码. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 SIP协议的鉴权机制. . . . . . .71 安全/多用途因特网邮件扩展(SIM1ME)(可选)7422 SIP协议的扩

9、展BNF语法.79 附录A(资料性附录)安全:威胁模式和安全建议. . . . . . . . . . . . . . . . . . . . . . . . 0- . . . . . . . . . . . . . . 92 附录B(资料性附录)IANA定义. . -. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 附录C(规范

10、性附录)SIP协议中临时响应的可靠性. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 附录D(规范性附录)SIP的定位过程. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 附录E(规施性附录)SDP的提供/应答(Offer/ Answer )模式. . . . .

11、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -117 附录F(规范性附录)特定事件的通知. . . . . . . . . . . . . . . .130 附录G(规范性附录)SIP卧o方法. . . . . . 146 附录H(规范性附录)即时消息. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -.150 附录1(规范性附录)UPDA:四消息. . . . . . . . . . . . .

12、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 附录J(规范性附录)阻四R方法. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .- . . . . . . . . . . . . .161 I YD厅1522.1时2006目。自会话初始协议(SIP)技术要求旗计分为5个部分:一一千第1部分:基本的会话初始协议;一一第2部分:基于会话初始协议(SIP)的呼叫控制的应用;一一第3部分:ISDN

13、用户部分(ISUP)和会话初始协议(SIP)的互通;一一第4部分:软交换网络中基于呼叫控制的会话初始协议(SIP)技术要求;一一第5部分:支持移动应用部分。本部分为会话初始协议(SIP)技术要求的第1部分。本部分对应于IE1F盯C3261(22) ，与盯C3261(2002)的一致性程度为非等效。本部分是会话初始协议(SIP)系列标准之一。该系列挥准的预计结构为:1.会话初始协议(SIP)技术要求一一第1部分:基本的会话初始协议;一一第2部分:基于会话初始协议(SIP)的呼叫控制的应用;一一第3部分:ISDN用户部分(ISUP)和会话初始t协议(SIP)的互通;一一第4部分:软交换网络中基于呼

14、叫控制的会话初始协议(SIP)技术要求;一一第5部分:支持移动应用部分。2. 符号之内。4 YD厅1522.1-2006除使用sip和sipsURI之外，还可以使用telURI定义机制，有关tel的U固定义机制见RFC2806。SIP实体可将非SIPURI翻译成SIPURI、SIPSURI或其他URI定义。3)版本号(SIP-Version):用于定义协议的当前版本号。本协议的版本号为SIP/2儿5.2 晌应(Response) 响应消息的起始行为状态行(Status-Line )，状态行由协议版本、状态码和与状态码相关的文本描述组成，各个部分之间用一个空格字符进行分隔。状态行的格式如下所示:

15、Sta归s-L挝le= SIP-Version Status-Code Reason回，PhraseCRLF 除状态行的尾部可使用回车换行CRLF字符之外，状态行内不允许出现C阻F字符。1 ) Status-Code (状态码):该参数为一个3位的十进制整数，用于指示请求消息的执行响应结果。2) Reason-Phrase (原因):该参数用于对Status-Code参数进行简单的文本描述。客户机不必检查或显示Re出on-Phr础e参数。尽管本标准建议使用特定字符表示Re础。n-Phrase，具体实现过程中Reason-Phrase仍可使用其他的文本字符。本协议共定义6类状态码，其中状态码的第

16、1位数字用于指示响应类型，后2位数字表示具体响应。本协议规定状态码为100时199之间的响应用IXX进行标识，200-299之间的响应用2XX进行标识，依此类推。1) lXX:临时响应，表示请求消息正在被处理。2) 2XX:成功响应，表示请求已被成功接收，完全理解并被接收。3) 3XX:重定向响应，表示需采取进一步以完成该请求。4)4双:客户机错误，表示请求消息中包含语法错误信息或服务器无法完成客户机请求。5) 5XX:服务器错误，表示服务器元法完成合法请求。的6XX:全局故障，表示任何服务器元法完成该请求。5.3 头字段SIP头字段的语法和语义定义与HIIP头字段定义基本相同。H口?中定义多

17、行扩展可使用隐含的空格和折叠字符(folding)，而本标准定义的多行扩展规则只能使用显式空格和折叠字符(folding)，且空格和折叠字符(folding)作为消息的组成部分。同样，H?中也定义了将具有多个参数值的同一字段扩展为具有相同字段名称的多个字段行的规则。该规则同样适用于本协议，但具体应用时规则会有所不同。SIP协议定义的头宇段语法规则如下:header , = header-name HCOLON header-value * (COMMA header-value ) 如上所示，SIP头宇段允许一个头字段可以定义多个参数值，且多个参数值之间用，字符进行分隔。当属性值不为*时，Co

18、ntact头字段允许属性值之间用，字符进行分隔。5.3.1 头宇段格式SIP消息的头宇段格式遵循盯C2822所定义的通用头字段格式定义规则。头宇段格式如下所示，头字段名和宇段值之间用字符:进行分隔ofield-n缸ne:field-value 消息头宇段中允许出现多个空格字符。但是在具体实现过程中，本标准建议字段头部右侧，即字段名和:字符之间应避免出现空格字符，而宇段头部左侧，即字段值和:之间用一个空格字符进行分隔，如下所示:5 YD厅1522.1-2006fi.eld-name: 在巳ld-value头宇段部分可以通过增加多个空白字符或者TAB字符而扩展成多行，本标准规定扩展行首位的多个空白

19、字符以及分行字符都应作为一个空白字符对待。消息头字段内不同头宇段名的顺序可任意排列，但是本标准建议与代理服务器处理相关的字段名(如Via、Route、Record-Route、Proxy-Require、M缸-Forw缸ds、Proxy-Authorization等)等，应尽可能排在消息头宇段的前几位以加快代理服务器对消息的处理速度。相同头字段名的排列顺序也非常重要，本标准规定，当且仅当字段值为多个宇段值列表且宇段值列表遵循多个字段值之间用，分割的规则，则一个消息内允许同时存在多个相同的字段名行。同理，多个相同字段名的字段行可以组成一个单一的字段行，其字段值为一个用，字符分隔的值列表。WWW-

20、Authen咀cate、Authorization.Proxy-Authenticate和Proxy-Authorization宇段不遵循以上规则。由于以上宇段值不允许出现列表值，因此当消息中出现多个以上宇段行时，多个字段行不能组成一个字段行。具体实现过程中，消息接收实体应按照同样的规则处理宇段名相同的多个字段行或一个包含宇段列表的组合宇段行。本标准中，头字段值由头宇段名进行标识。通常头宇段名由UTF8字符集所包含的文本字符组成。除此之外，头宇段还允许包含空格、破折号、分隔符和引号字符。多数头宇段名和头宇段属性值之间用:进行分隔，且头字段中还可包含参数名和参数值，格式如下所示:field-na

21、me: field-value * ( ;parameter-name=parameter-value) 本标准对头字段中所包含的参数名数目不作限制，但规定在一个头字段内，同一参数名能且仅能出现一次。本协议规定，头宇段名对大小写字符不敏感，即相同字段名不区分大小写字符。如未特别指出，头宇段中所包含的字段参数值，参数名和参数值也对大小写字符不敏感，除此之外，头字段名中所包含的破折号飞一一字符对大小写字符不敏感，但是引号字符内的字符内容对大小写字符敏感。5.3.2头宇段分类SIP消息某些头字段仅当存在于请求或响应中的时候才有意义。只能存在于请求消息中的字段称为请求头字段，只能存在于响应消息中的字段

22、称为响应头字段。当消息头宇段出现了不匹配的字段类型时，则消息接收实体应忽略该字段。5.3.3压缩格式本协议提供了一种压缩机制用于将头宇段名相同的宇段进行压缩传送，这种压缩机制可以避免消息传输过程中产生大量消息拆分。采用压缩并不会导致消息语义的改变。本协议规定同一头宇段名可出现在压缩头部或非压缩头部中，在具体实现过程中，消息接收实体应能识别并正确处理这两种不同格式的消息。5.4 消息体本协议规定SJP请求消息可包含消息体部分，消息体部分的解释应与消息请求方法相一致。对于SIP响应捕息，请求方法和响应状态码可以识别消息体的类型。本协议规定所有SIP响应消息应包含一个消息体部分。5.4.1 消息体类

23、型消息体的类型必须由Content-可pe字段进行定义，且如果消息体采用了压缩编码方式，则相应地应在Content蝇Encoding字段中定义其所采用的压缩编码算法。否则，如果消息体未采用了压缩编码方6 YDIT 1522.1-:-2006 式，则Content-Encoding字段的内容应被忽略。在具体应用过程中，消息接收实体应将消息体的内容作为Content-飞机头宇段值来对待。本协议规定消息体可以承载使用multipartMIME方式进行编码的信息单元。具体实现中，当请求发送方需要发送消息体部分包含MTh但信息单元的请求消息时，旦消息接收方在Acc叩t头字段指示其不能接受MIME消息体，

24、则消息请求发送方应在消息中附加一个SDP部分作为非MIME捎息体进行发送。S1P消息可以包含二进制编码的消息体。如果未明确指出，本标准中缺省的消息文本编码类型是u亨:805.4.2 消息体长度消息体的长度由Content-LmgM头字段进行定义，单位为字节。有关Content-kngk头字段见本部分第18章。本协议规定SIP消息体不能采用HIlP1.1中所定义的分块(chunked)传送编码机制。在分块传送编码机制中，每一块消息体的长度由相应的标识符进行标识。5.5 SIP消息帧SIP协议可以使用UDP或者其他不可靠的报文协议进行承载传送，且每一个报文携带一个请求或响应消息。具体实现时，如果S

25、1P消息采用面向流的方式进行传送，则SIP消息起始行前的任何C虹F字符应忽略。Content-IElgth头宇段值用于定义一个SIP消息在流中的结束位置。当SIP消息采用面向流的方式进行传送时，该头字段不能被省略。6 用户代理(UA)的基本行为当UAC发出请求，请求消息会通过一些代理服务器被转发到UAS。而UAS产生一个响应后，响应消息会以同样的方式被转发到UACoUAC和UAS的处理过程与两个因素有关，即被处理的请求或响应消息是否属于某个对话(dialog)以及请求的方法。对话是一种UA之间的端到端对等关系，它由特定的SIP消息，如的VITE消息建立。关于对话定义见本标准第10章。对话之外的

26、请求或响应消息的安全性处理参见本部分附录A。另外，UAC和UAS之间存在着相互鉴权，机制。消息体可以通过SIMIME进行加密。6.1 UAC基本行为本节讨论对话之外的UAC行为06.1.1 请求消息的产生本标准规定，由UAC产生的一个有效的SIP请求消息必须至少包含下列头字段:To、From、CSeq、Call-ID、Max-Forw缸ds和Via头字段，这些头宇段在所有的SIP请求消息都是必选的。这6个头字段是构建S1P消息的基本单元，它们共同提供了大部分的关键的消息路由服务，包括消息的寻址、响应的路是由、消息传播距离限制、消息排序，以及事务交互的惟一性标识等。另外，请求行(request

27、line )也是必选的，它包含了请求方法、Request-UR1，S1P版本信息。在对话外发送的请求消息包括:用的VE消息建立起一个会话，用OPTIONS消息进行能力查询等。6.1.1.1 Request-URI 7 YD厅1522.1-2006除阻GISTER请求，本协议中所有的请求消息的初始Request-URI都应被设为To头字段中的URI值。另外，出于安全性考虑，UA有时可能不希望将这两个头宇段设为同样的值，尤其是当发端UA知道Re伊est-URI可能会在传输中改变。某些情况下，预设路由集的存在能影响到消息的Request-URlo预设路由集是一个有序的URI集合，它标识了一个服务器链

28、，UAC向这个服务器链发出对话外请求消息。预设路由集通常由用户或服务供应商在UA上手工配置，或者通过某些其他的非SIP机制配置。本部分建议，在给某个UA配置一个外拨代理服务器时服务供应商所提供的预设路由集中只有一个URI，即外拨代理服务器的URI。当存在预设路由集时，必须遵循本标准12.2节中描述的过程来设置Requ臼t-URI和Route头字段，其Request-URI作为远端目标U阳。6.1.1.2 To头宇段To头宇段指定请求消息的逻辑接收者或者是用户或资源的注册地址，该地址同样是作为请求消息的目标地址。To头字段所指示的不一定为请求消息的最终接收者。它可能包含一个SIP或SIPSU阻，

29、或其他的URI方案。本标准规定，所有的具体实现过程都必须支持SIPURI方案，任何支持TLS的实现必须支持SIPSURI方案。To头宇段中允许包含一个显示名称。UAC可通过多种方式来构造一个请求消息的To头宇段。通常经过人机接口，由用户输入或者从地址簿中选取。用户通常不会输人一个完整的URI，而只是提供一个由数字或字母组成的字符串，由UA判断并解释该字符串。如果这个字符串被用来构造一个SIPURI的用户部分，则用户名称在符号右侧所示的主域中被解析;如果这个字符串被用来构造一个SIPSU阳的用户部分，则用户希望进行安全的通信，同时用户名将在符号右侧所示的主域中被解析。SIPURI中符号右侧通常是

30、请求发起方的主域，它使本地主域能够处理外发请求。此外，如果用户输入的是一个电话号码，且UA不会指定由某个主域来解释该号码，这时可以使用telURL，从而使请求消息所经过的每一个主域都可以处理它。请求消息的To标签标识了一个对话中的对端，如果对话没有建立，标签就不应当出现。对话之外的请求消息中不可以包含To标签(tag)。关于To头宇段见本标准18章。6.1.1.3 From头宇段From头字段是指示请求发起方的逻辑标识，它可能是用户的注册地址。From头宇段包含一个URI和一个可选的显示名称。SIP实体用它来决定如何处理一个请求(如呼叫自动拒绝)。由于不是逻辑名称，因此FromURI不包含E地

31、址或UA所在主机的全称域名(FQDN)。From头字段中允许包含一个显示名称。如果一个UAC需要隐藏自己的身份，它可以使用Anonymous作为显示名称和一个语法正确但没有任何意义的URIo通常，某个UA产生的请求消息中的From头字段值是由用户或用户本地主域的服务器预先设置的。如果UA被多个用户所共用，那么它可以有多个可切换的用户配置文件，每一文件中含有某一用户的URIo请求消息的接收者要对发送者进行鉴权，以确认发送者身份与From头字段相一致。From头字段中必须包含一个新的由UAC选定的ug参数。关于From头宇段见本标准18章。6.1.1 .4 Call-ID头宇段Call咱m头宇段是

32、用来将1肖息分组的惟一性标识。本协议规定，在一个对话中，UA发送的所有请求8 YD厅1522.1-2006消息和响应消息都必须有同样的Call-IDo在注册生存期内，一个UA每次注册所用的Call-ID也应是一样的。当UAC产生一个新的对话外请求时，除非被某些方法指定，否则它必须为这个请求消息选择一个在空间上和时间上都是全局惟一的Call-ID头宇段。所有的SIPUA都必须保证它所产生的Call-ID不会与其他UA所产生的相同。当UA收到某些失败的响应后，请求会根据响应的内容修改并重发，这些重发的请求不作为新请求处理，因而也就不需要新的Call蝴D头字段。本标准建议使用RFC1750中的加密随

33、机标识符生成方法来生成C创l-ID。具体实现可采用localidhost的形式。Call-ID对大小写敏感，需逐字节的进行比较。加密随机标识符方法在一定程度上能防范黑客的会话攻击，并降低了无意中产生Call-即冲突的可能性。Call-ID的选择不需要通过人机接口和预先设定值来实现。关于Call-ID头字段见本标准18章。6.1 ;1.5 Cseq头字段CSeq头字段用于标识事务并对事务进行排序。它由一个请求方法和一个序列号组成，请求方法必须与对应的请求消息类型一致。对话外的非阻GISTER请求，序列号值可以是任意的。但它必须可被表示成一个32位的无符号整数，且2310只要符合以上规则，客户端可

34、以用任何方式来选择Cs吨头宇段值。6.1.1.6 Max-Fowo时s头字段Max-Fowords头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。它包含一个整数值，每经过一跳，这个值就被减一。如果在请求消息到达目的地之前该值变为0，那么请求将被拒绝并返回一个483(跳数过多)错误响应消息。UAC必须在它发起的每个请求中都插入Max-Fowords头字段，值为70。在任何不出现回路的SIP网络中，选择该值为70足够大的保证一个请求消息不被丢弃，且在有回路的情况下，这个值也不会太大而过分浪费代理服务器的资源。UA只有知道网络的拓扑结构时，才可以谨慎地选择更小的跳数值。6.1.1.7 Vi

35、a头宇段Via头宇段定义SIP事务的下层(传输层)传输协议，并标识响应消息将要被发送的位置。只有当到达下一跳所用的传输协议被选定后，才能在请求消息中加入Via头宇段值。本协议规定，当UAC生成请求消息时，它必须在其中插入一个Via头字段。Via头宇段的协议名称和协议版本必须分别为SIP和2.。V1a头宇段中必须包含一个branch参数，该参数用来标识由当前请求所建立的事务。该参数既用在客户端也用在服务器端。对于某个UA发出的所有请求，它们的branch参数值在空间和时间上必须全局惟一的。但有两种情况例外:一是CANCEL请求，以后会说明CANCEL请求的branch参数与它所要取消的那个请求的

36、branch参数是一样的;另一个是对非2xx.响应的ACK请求，这种情况下ACK请求与相关的时VITE请求有着同样的branchID，它所要确认的就是该INVlTE的响应。SIP实体在插入branchID时，必须以z9hG4bK开头。这7个字符是magiccMe，这样SIP服务器在收到请求消息时，就能确定现在的branchID是全局惟一的。另外，branchID参数的准确格式由具体的实现定义。Via头的maddr、国以及sent-by部分在传输层对请求消息进行处理时进行设置，几本标准第16章。关于代理服务器对Via头宇段的处理见本标准13章。9 YD厅i522.1-2006 6.1.1.8 C

37、ontact头字段Contact头宇段指定一个SIP或SIPSURI，后续请求可以用它来联系到当前UA。任何能够建立对话的请求消息中都必须有Contact头字段，并且该头字段中只能含有一个SIP或SIPSURI。在本标准定义的请求方法中，只有剖VITE能建立对话。对这些能建立对话的请求，Contact的作用范围是全局的。也就是说，Contact头宇段值中包含的URI是UA希望用来接收请求的地址，即使用在任何对话外的后续请求消息中，该URI也必须有效。如果请求消息的Request-URI或顶端Rout巳头字段值中包含了SIPSU阳，那么在Contact头宇段中也必须包含一个SIPSURIo 关于

38、Contact头宇段几本标准18章。6.1.1.9 Supported和Require头宇段如果UAC支持某些SIP协议的扩展，并且这些扩展可被服务器用来构成请求的响应，那么UAC应在请求消息中包含一个Supported头宇段，列出这些扩展的选项标签。.只有在本标准和后续扩展所对应的选项标签能够在Supported头字段中列出。如果UAC要求UAS必须理解某项扩展以便处理它所发出的请求，它必须在请求消息中插人一个R吨uire头字段，并列出此扩展的选项标签。如果UAC希望在请求中使用某项扩展，并要求请求消息经过的所有代理服务器都能理解此扩展，它必须在请求消息中插人一个Proxy-Require头

39、宇段，并列出此扩展的选项标签。6.1.1.10消息的其他部分在新的请求消息生成且上述头宇段被正确构造之后，可加人任何其他的可选头宇段和请求方法所要求的特定头宇段。SIP请求消息中可包含一个按MIME格式编码的消息体。无论请求中包含的消息体类型如何，都必须构造某些头字段以表征消息体的内容。这部分头字段的内容见本标准18章。6.1.2 请求消息的发送首先确定请求消息的发送目的地。除非另有本地策略，目的地址必须按照DNS定位过程确定:如果Route头宇段中路由集的第一个实体是个严格的路由器，DNS的过程必须被应用于请求消息的R叫uest-URI;否则，该过程应用于请求消息中的第一个Rou也头字段值，

40、若没有Route头宇段出现则该DNS过程仍然应用于请求消息的R叫u四;-URI。其输出结果是个可以发送的目标地址有序集，其中每一项是由地址、端口号以及传输协议构成的三元组。不论用哪个URI作为DNS寻址过程的输入，如果R叫uest-URI指定一个SIPS资源，UAC就必须把这个URI当作SIPSURI来解析。具体定位过程见附录Do本地策略可指定其他目标地址集。如果Request-URI中包含的是SIPSURI，那么同该地址集中的任何目的地址联系都必须使用TLS。此外，如果请求消息中不含Route头宇段，那么对该地址集中的地址没有其他限制。当指定一个外拨代理服务器时，这样做比预设路由集简单。但是

41、，本部分建议用只含单个U阳的预设路由集来指定外拨代理服务器。如果请求消息中含有Route头字段，那么请求消息应当发送到最顶端Route头字段值所指示的位置;也可发送到任何其他的服务器。只要UA确认这些服务器遵循本部分中对Route和Request-URI的处理策略。本标准建议，配置了外拨代理服务器的UAC应该尝试将请求发往第一个Route头宇段值所指的位置，而不是将所有消息都发往外拨代理服务器。UAC应当尝试连接目标地址集中的每个地址，直到联系上某个服务器。每次尝试都会建立新的事务，10 YD厅1522.1-2006因而每个新请求的最顶端Via头字段值都不同，其中包含着新的branch参数。此

42、外，Via头字段中的位朋sport值也要根据不同的目标服务器来设置。6.1.3 晌应消息处理响应消息先由传输层处理，然后上传到事务层。经事务层处理后再将其上传给事务用户(TU)oTU 对响应消息的处理主要依赖于请求方法，但是一些基本处理方法则同具体的请求方法无关。6.1.3.1 事务屡错误某些情况下，从事务层返回的并不是SIP消息，而是事务层错误消息。当TU从事务层收到超时错误消息时，对该消息的处理必须同408(请求超时)状态码。如果事务层报告的是严重错误，通常是UDP方式下的严重ICMP错误或TCP连接失败所致，贝。该消息的处理同503(业务不可用)状态码。6.1.3.2 无法识别的晌应消息对无法识别的最终响应，UAC必须将之等价于所属响应类别的x响应码，且UAC必须能够处理所有响应类别的xOO响应码。例如，如果UAC收到了一个无法识别的响应码431，那么它能断定自己发出的请求消息出错，因而对该431码的处理同400(错误请求)响应码。但对于任何元法识别的非1临时响应的处理必须同183响应(会话处理中)0UAC必须能够处理100和183响应。6.1.3.3 多Via头宇段值如果某个响应消息中出现了多个Via头字段值，UAC应当丢弃该响应。在标识请求发起者的Via头宇段值之前出现了其他的Via头宇段值，表明消息在传送过程中发生