返回首页

会话初始协议ISP技术要求-中国通信行业标准

时间:2008-10-19 来源: 作者: 点击:
中华人民共和国通信行业标准 会话初始协议技术要求 第一部分基本的会话初始协议 Technical Requirements for Session Initiation Protocol Part1 Basic Session Initiation Protocol 中华人民共和国信息产业部发布 前言 本标准以RFC3261 等文档为依据,针对我国具体要求
  中华人民共和国通信行业标准
会话初始协议技术要求
第一部分基本的会话初始协议
Technical Requirements for Session Initiation Protocol Part1 Basic Session Initiation Protocol
中华人民共和国信息产业部发布


前言
本标准以RFC3261 等文档为依据,针对我国具体要求制定而成。
本标准规定了会话初始协议的技术要求,包括SIP 消息、用户代理基本行为、请求取消、查询能力、对话、会话发起过程、会话更改过程、代理服务器行为、SIP 事务层、传输、普通消息成分、头字段、响应代码、HTTP 鉴权使用、S/MIME 、SIP 协议的扩展BNF 、安全、IANA 考虑等要求。本标准主要依据IEEE 标准与RFC 文档,随着IP 技术的不断发展,需要对本标准不断补充和完善。
本标准由中国通信标准化协会提出并归口。
本标准起草单位:
本标准主要起草人:
会话初始协议技术规范第一部分基本的会话初始协议
1 范围
本标准规定了会话初始协议。本标准适用于国内采用SIP 的软交换、应用服务器、SIP 终端的研制、生产、引进和购买。在本标准中: 必须:表示该条目是本标准必须。违反这样的要求是原则性错误。必须实现:表示该要求必须实现,但不要求缺省使能。不允许(不可以): 标识该条目绝对禁止。应当(建议): 表示在某些特定条件下存在忽视该条目的理由,但是忽视或违反该条目时必须
仔细衡量。应当(建议)实现:与应当(建议)类似,实现时不必要缺省使能。不应当(不建议): 表示在某些特定条件下存在所描述行为可接受或有效的理由,但实现该行
为时必须仔细衡量。可以: 标识该条目确实可选。某些厂商可能出于市场或其它原因实现该选项, 另一厂商可能出于类似理由不实现该选项。
2 规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准, 然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。
RFC3261(2002) SIP:会话初始协议
RFC3262(2002) SIP 协议临时应答的可靠性
RFC3263(2002) 会话初始协议:定位服务器
RFC2279
RFC2822

3 SIP 消息
SIP 协议是采用UTF-8 字符集来进行编码的文本协议,UTF8 的相关内容参见RFC2279 。
SIP 协议消息分请求和响应两类,其中请求消息由客户机发往服务器, 响应消息由服务器发往客户机。除选用的字符集以及语法定义外,请求和响应消息均采用RFC2822 定义的基本格式进行编码。请求和响应消息格式由一个起始行、若干个头字段,以及一个可选的消息体组成。其中消息体为可选项, 头字段与消息体之间用空行进行分隔。请求和响应消息格式如下:
SIP 消息=起始行
*消息头部(1 个或多个头部)
CRLF (空行)
[消息体]

起始行=请求行/状态行
如上消息格式定义,“*” 表示该消息头部可包含一个或多个,“[]” 表示该参数为可选项。本规范规定起始行、每一个消息头部以及空行都必须使用回车换行字符(CRLF )来表示行终结,即使消息中未包含消息体可选项空行也不能省略。
除了以上字符集不同之外,SIP 消息和头字段语法定义与HTTP 1.1 的语法定义一致,HTTP/1.1 的语法定义参见RFC2612 。消息语法定义与HTTP 类似, SIP 协议并不是HTTP 的扩展协议。
3.1 请求(Request)
请求消息的起始行为请求行(Request-Line)。请求行的格式如下所示,由方法名、请求URL 和协议版本组成,各部分之间均用一个空格字符进行分隔。除此之外,请求行必须用回车换行(CRLF )字符表示行终结。
Request-Line = Method[ ] Request-URI [] SIP-Version CRLF
1)Method: 本规范共定义了6 个方法,INVITE 、ACK、CANCEL 、OPTIONS 、BYE 和REGISTER 。REGISTER 消息用于发送注册请求信息,INVITE 、ACK、CANCEL 用于建立会话连接,BYE 用于终结会话连接,OPTIONS 用于查询服务器能力。本协议规定方法名必须使用大写字母。除以上6 类主要消息外,SIP 协议在其他文档中还定有若干方法实现协议扩展。
2)Request-URL :指示被邀请用户的当前地址,本协议规定Request-URL 中不允许出现空格或其他控制字符且不能包含于“<>”符号之内。
除使用“sip”和“sips”之外,Request-URI 还可以使用“tel”的URI 定义机制,有关“tel”的URI 定义机制参见RFC2806 。SIP 实体可使用任何可选方法将非SIP URL 翻译成SIP URI 、SIPS URI 或其他URI 定义。
3)SIP-Version: 用于定义协议的当前版本号,本协议的版本号为SIP/2.0。
3.2 响应(Response)
响应消息的起始行为状态行(Status-Line),状态行由协议版本、状态码和与状态码相关的文本描述组成,各个部分之间用一个空格字符进行分隔。状态行的格式如下所示:
Status-Line = SIP-Version [ ]Status-Code [ ] Reason-Phrase CRLF
除状态行的尾部可使用回车换行CRLF 字符之外,状态行内不允许出现CRLF 字符。
1) Status-Code (状态码):该参数为一个3 位的十进制整数,用于指示请求消息的执行响应结果。
2) Reason-Phrase (原因):该参数用于对Status-Code 参数进行简单的文本描述。客户机不必检查或
显示Reason-Phrase 参数。尽管本规范建议使用特定字符表示Reason-Phrase ,具体实现过程中
Reason-Phrase 仍可使用其他的文本字符。
本协议共定义6 类状态码,其中状态码的第1 位数字用于指示响应类型,后两位数字表示具体响应。本协议规定状态码为“100—199 ”之间的响应用“1XX” 进行标识,“200—299”之间的响应用“2XX ”进行标识,依此类推。
1) 1XX :临时响应,表示请求消息正在被处理。
2) 2XX: 成功响应, 表示请求已被成功接收,完全理解并被接受。
3) 3XX: 重定向响应, 表示需采取进一步以完成该请求。
4) 4XX: 客户机错误, 表示请求消息中包含语法错误信息或服务器无法完成客户机请求。
5) 5XX: 服务器错误, 表示服务器无法完成合法请求。
6) 6XX: 全局故障, 表示任何服务器无法完成该请求。
响应分类描述以及具体的响应码参见本规范第17 章。。
3.3 头字段
SIP 头字段的语法和语义定义与HTTP 头字段定义基本相同, 有关HTTP 头字段的定义和SIP 头字段多行扩展的定义规则参见RFC 2616 。RFC 2616 中定义的多行扩展可使用隐含的空格和折叠字符(folding),而本规范定义的多行扩展规则只能使用显式空格和折叠字符(folding),且空格和折叠字符(folding) 作为消息的组成部分。
同样,RFC 2616 也定义了将具有多个参数值的同一字段扩展为具有相同字段名称的多个字段行的规则。该规则同样适用于本协议, 但具体应用时规则会有所不同。SIP 协议定义的头字段语法规则如下所示:
header = "header-name" HCOLON header-value *(COMMA header-value)
如上所示,SIP 头字段允许一个头字段可以定义多个参数值, 且多个参数值之间用“,” 字符进行分隔。当属性值不为“*”时,Contact 头字段允许属性值之间用“,”字符进行分隔。
3.3.1 头字段格式
SIP 消息的头字段格式遵循RFC2822 第2.2 节所定义的通用头字段格式定义规则。头字段格式如下所示,头字段名和字段值之间用字符“:”进行分隔。
field-name: field-value
如本规范第25 节定义,消息头字段中允许出现多个空格字符。但是, 在具体实现过程中,本规范建议字段头部右侧,即字段名和“:”字符之间应避免出现空格字符, 而字段头部左侧,即字段值和“:
” 之间用一个空格字符进行分隔,如下所示:
field-name:[]field-value
头字段部分可以通过增加多个空白字符或者TAB 字符而扩展成多行,本规范规定扩展行首位的多个空白字符以及分行字符都应作为一个空白字符对待。依照以上规则,以下两个头字段是相同的。
Subject: I know you're there, pick up the phone and talk to me!
Subject: I know you're there,
pick up the phone
and talk to me! 消息头字段内不同头字段名的顺序可任意排列, 但是,本规范建议与代理服务器处理相关的字段名( 如Via 、Route 、Record-Route 、Proxy-Require 、Max-Forwards 、Proxy-Authorization 等)等应尽可能排在消息头字段的前几位以加快代理服务器对消息的处理速度。相同头字段名的排列顺序也非常重要,本规范规定,当且仅当字段值为多个字段值列表且字段值列表遵循7.3 节定义的语法规则即多个字段值之间用“,” 分割时,则一个消息内允许同时存在多个相同的字段名行。同理,多个相同字段名的字段行可以组成一个单一的字段行,其字段值为一个用“,”字符分隔的值列表。WWW-Authenticate 、Authorization 、Proxy-Authenticate 和Proxy-Authorization 字段不能遵循以上规则。由于以上字段值不允许出现列表值, 因此当消息中出现多个以上字段行时,多个字段行不能组成一个字段行。
具体实现过程中, 消息接收实体应按照同样的规则处理字段名相同的多个字段行或一个包含字段列表的组合字段行。按照以上规则,以下两个字段行是等价的。
1)Route: <sip:alice@atlanta.com>
Subject: Lunch
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>


2)Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Subject: Lunch
3)Subject: Lunch
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,

<sip:carol@chicago.com>
以下几个例子符合消息定义规则,但彼此并不等价。
1)Route: <sip:alice@atlanta.com>
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>

2)Route: <sip:bob@biloxi.com>
Route: <sip:alice@atlanta.com>
Route: <sip:carol@chicago.com>

3)Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
<sip:bob@biloxi.com>

本规范中, 头字段值由头字段名进行标识。通常头字段名由UTF8 字符集所包含的文本字符组成。除此之外,头字段还允许包含空格、破折号、分隔符和引号字符。多数头字段名和头字段属性值之间用“:”进行分隔,且头字段中还可包含参数名和参数值,格式如下所示:
field-name: field-value *(;parameter-name=parameter-value)
本规范对头字段中所包含的参数名数目不作限制,但规定在一个头字段内,同一参数名能且仅能出现一次。
本协议规定,头字段名对大小写字符不敏感,即相同字段名不区分大小写字符。如未特别指出,头字段中所包含的字段参数值, 参数名和参数值也对大小写字符不敏感, 除此之外, 头字段名中所包含的破折号“-”字符对大小写字符不敏感,但是引号字符内的字符内容对大小写字符敏感。例如,以下头字段分别相同:
1) Contact: <sip:alice@atlanta.com>;expires=3600
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
2) Content-Disposition: session;handling=optional
content-disposition: Session;HANDLING=OPTIONAL

以下头字段则不同:
3)Warning: 370 devnull "Choose a bigger pipe"
Warning: 370 devnull "CHOOSE A BIGGER PIPE"

3.3.2 头字段分类
SIP 消息某些头字段仅当存在于请求或响应中的时候才有意义。只能存在于请求消息中的字段称为请求字段, 只能存在于响应消息中的字段称为响应字段。当消息头字段出现了不匹配的字段类型, 则消息接收实体应忽略该字段,有关字段类型分类参见本规范第20 章。
3.3.3 压缩格式
本协议提供了一种压缩机制用于将头字段名相同的字段进行压缩传送,这种压缩机制可以避免消息传输过程中产生大量消息拆分(例如,当使用UDP 进行传输时,如果消息的字节长度超过了MTU, 则需要对消息进行拆分传送)。压缩格式参加本规范第20 章。采用压缩并不会导致消息语义的改变。本协议规定同一头字段名可出现在压缩头部或非压缩头部中,在具体实现过程中,消息接收实体应能识别并正确处理这两种不同格式的消息。
3.4 消息实体
本协议规定SIP 请求消息可包含消息实体部分,消息实体部分的解释应与消息请求方法相一致。对于SIP 响应消息, 请求方法和响应状态码可以识别消息实体的类型。本协议规定所有SIP 响应消息应包含一个消息实体部分。
4
3.4.1 消息实体类型
消息实体的类型必须由“Content-Type” 字段进行定义,且如果消息实体采用了压缩编码方式,则相应地应在“Content-Encoding ”字段中定义其所采用的压缩编码算法。否则,如果消息实体未采用了压缩编码方式,则“Content-Encoding ”字段的内容应被忽略。在具体应用过程中,消息接收实体应将消息实体的内容作为“Content-Type ”头字段值来对待。
本协议规定消息实体可以承载使用“multipart”MIME 方式进行编码的信息单元, 有关MIME 参见RFC2046 。具体实现中, 当请求发送方需要发送消息实体部分包含MIME 信息单元的请求消息时,且消息接收方在“Accept ” 头字段指示其不能接受MIME 消息实体,则消息请求发送方应在消息中附加一个SDP 部分作为非MIME 消息实体进行发送。SIP 消息可以包含二进制编码的消息实体。如果未明确指出,本规范中缺省的消息文本编码类型是UTF-8 。
3.4.2 消息实体长度
消息实体的长度由“Content-Length” 头字段进行定义,单位为字节。有关“Content-Length ”头字段参见本规范第20.14 节。
本协议规定SIP 消息实体不能采用HTTP1.1 中所定义的“chunked ”传送编码机制。在“chunked” 传送编码机制中,每一块消息实体的长度由相应的标识符进行标识。
3.5 SIP消息帧
SIP 协议可以使用UDP 或者其他不可靠的报文协议进行承载传送,且每一个报文携带一个请求或响应消息。关于SIP 协议以不可靠协议传送有关要求参见本规范第18 章。
具体实现时,如果SIP 消息采用面向流的方式进行传送,则SIP 消息起始行前的任何CRLF 字符应忽略。
“Content-Length ” 头字段值用于定义一个SIP 消息在流中的结束位置。当SIP 消息采用面向流的方式进行传送时,该头字段不能被省略。
4 用户代理(UA) 的基本行为
用户代理(UA) 表示一个终端系统。它包括两部分,用户代理客户端(UAC) 和用户代理服务器端(UAS), 前者产生请求,后者产生对应的响应。UAC 可以根据某些外部激励产生请求消息并且处理这些请求的响应消息。外部激励可以是用户在某一图形界面上的按钮点击、也可以是某一PSTN 链路上的信令信号等。UAS 能够接收请求消息并产生响应消息。
当UAC 发出请求, 请求消息会通过一些代理服务器被转发到UAS 。而UAS 产生一个响应后, 响应消息会以同样的方式被转发到UAC。
UAC 和UAS 的处理过程与两个因素有关,即被处理的请求或响应消息是否属于某个对话(dialog) 以及请求的方法。对话是一种UA 之间的端到端对等关系, 它由特定的SIP 消息,如INVITE 消息建立。关于对话定义参见本规范第12 章。
对话之外的请求或响应消息的安全性处理参见本规范第26 章。另外,UAC 和UAS 之间存在着相互鉴权机制。消息体可以通过S/MIME 进行加密。
4.1 UAC基本行为
本节讨论在对话之外的UAC 行为。
4.1.1 请求消息的产生
本规范规定,由UAC 产生的一个有效的SIP 请求消息必须至少包含下列头字段:To、From 、CSeq 、Call-ID 、Max-Forwards 和Via 头字段,它们在所有的SIP 请求消息都是必选的。这六个头字段是构建SIP 消息的基本单元, 它们共同提供了大部分的关键的消息路由服务,包括消息的寻址、响应的路由、消息传播距离限制、消息排序,以及事务交互的唯一性标识等。另外,请求行(request line )也是必选的,它包含了请求方法、Request-URI 、SIP 版本信息。
在对话外发送的请求消息包括:用INVITE 消息建立起一个会话(参见本规范第13 章),用OPTIONS 消息进行能力查询(参见本规范第11 章)等。
4.1.1.1 Request-URI
除REGISTER 请求, 本协议中所有的请求消息的初始Request-URI 都应被设为To 头字段中的URI 值。关于设置REGISTER 请求中的Request-URI 参见本规范第10 章。另外, 出于安全性考虑,UA 有时可能不希望将这两个头字段设为同样的值,尤其是当发端UA 知道Request-URI 可能会在传输中改变。
某些情况下,预设路由集的存在能影响到消息的Request-URI 。预设路由集是一个有序的URI 集合,它标识了一个服务器链,UAC 向这个服务器链发出对话外请求消息。预设路由集通常由用户或服务供应商在UA 上手工配置, 或者通过某些其它的非SIP 机制配置。本规范建议, 在给某个UA 配置一个外拨代理服务器时服务供应商所提供的预设路由集中只有一个URI ,即外拨代理服务器的URI 。
当存在预设路由集时,必须遵循本规范12.2.1.1 节中描述的过程来设置Request-URI 和Route 头字段,其Request-URI 作为远端目标URI 。
4.1.1.2 To头字段
To 头字段指定请求消息的逻辑接收者或者是用户或资源的注册地址,该地址同样是作为请求消息的目标地址。To 头字段所指示的不一定为请求消息的最终接收者。它可能包含一个SIP 或SIPS URI, 或其它的URI 方案( 如RFC2806 中的tel URL)。本协议规定,所有的具体实现过程都必须支持SIP URI 方案,任何支持TLS 的实现必须支持SIPS URI 方案。To 头字段中允许包含一个显示名称。
UAC 可通过多种方式来构造一个请求消息的To 头字段。通常经过人机接口,由用户输入或者从地址簿中选取。用户通常不会输入一个完整的URI ,而只是提供一个由数字或字母组成的字符串(比如”bob”),由UA 判断并解释该字符串。如果这个字符串被用来构造一个SIP URI 的用户部分,则用户名称在@符号右侧所示的主域中被解析;如果这个字符串被用来构造一个SIPS URI 的用户部分,则用户希望进行安全的通信,同时用户名将在@符号右侧所示的主域中被解析。SIP URI 中@符号右侧通常是请求发起方的主域,它使本地主域能够处理外发请求。此外,如果用户输入的是一个电话号码,且UA 不会指定由某个主域来解释该号码,这时可以使用tel URL ,从而使请求消息所经过的每一个主域都可以处理它。例如: 一个来到机场的用户可能登录机场的外拨代理服务器并通过它发送请求, 如果用户输入”411”( 美国本地电话查号台号码), 那么该号码应由机场的外拨代理服务器来分析和处理,而不是用户的本地主域。此时正确构造的URI 应该是“tel:411”。
请求消息的To 标签标识了一个对话中的对端,如果对话没有建立,标签就不应当出现。对话之外的请求消息中不可以包含To 标签(tag)。
关于To 头字段参见本规范20.39 节。下例是一个有效的To 头字段:
To:Carol <sip:carol@chicago.com>
4.1.1.3 From头字段
From 头字段是指示请求发起方的逻辑标识, 它可能是用户的注册地址。From 头字段包含一个URI 和一个可选的显示名称。SIP 实体用它来决定如何处理一个请求(如呼叫自动拒绝)。由于不是逻辑名称,因此From URI 不包含IP 地址或UA 所在主机的全称域名(FQDN)。
From 头字段中允许包含一个显示名称。如果一个UAC 需要隐藏自己的身份,它可以使用“Anonymous” 作为显示名称和一个语法正确但没有任何意义的URI 。(如sip:this@anonymous.invalid)
通常,某个UA 产生的请求消息中的From 头字段值是由用户或用户本地主域的服务器预先设置的。如果UA 被多个用户所共用,那么它可以有多个可切换的用户配置文件,每一文件中含有某一用户的URI。请求消息的接收者要对发送者进行鉴权,以确认发送者身份与From 头字段相一致。关于鉴权参见本规范第22 章。
From 头字段中必须包含一个新的由UAC 选定的“tag”参数。
关于From 头字段参见本规范20.20 节。例如:
From: ”Bob” <sips:bob@Biloxi.com>; tag=a48s
From: sip:+12125551212@phone2net.com; tag=887s
From: Anonymous <sip:c8oqz84zk7z@privacy.org>; tag=hyh8

4.1.1.4 Call-ID 头字段
Call-ID 头字段是用来将消息分组的唯一性标识。本协议规定, 在一个对话中,UA 发送的所有请求消息和响应消息都必须有同样的Call-ID 。一个UA 每次注册所用的Call-ID 也应是一样的。
当UAC 产生一个新的对话外请求时,除非被某些方法指定, 否则它必须为这个请求消息选择一个在空间上和时间上都是全局唯一的Call-ID 头字段。所有的SIP UA 都必须保证它所产生的Call-ID 不会与其它UA 所产生的相同。当UA 收到某些失败的响应后, 请求会根据响应的内容修改并重发,这些重发的请求不作为新请求处理,因而也就不需要新的Call-ID 头字段。
本规范建议使用RFC1750 中的加密随机标识符生成方法来生成Call-ID 。具体实现可采用localid@host 的形式。Call-ID 对大小写敏感,需逐字节的进行比较。
加密随机标识符方法在一定程度上能防范黑客的会话攻击,并降低了无意中产生Call-ID 冲突的可能性。
Call-ID 的选择不需要通过人机接口和预先设定值来实现。
关于Call-ID 头字段参见本规范20.8 节。下例是一个有效的Call-Id:
Call-ID:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
4.1.1.5 Cseq头字段
CSeq 头字段用于标识事务并对事务进行排序。它由一个请求方法和一个序列号组成,请求方法必须与对应的请求消息类型一致。对话外的非REGISTER 请求,序列号值可以是任意的。但它必须可被表示成一个32 位的无符号整数,且小于231。只要符合以上规则,客户端可以用任何方式来选择Cseq 头字段值。
关于如何构造在对话中发送的请求消息的CSeq 头字段参见本规范12.2.1.1 节。下例是Cseq 头字段:CSeq:4711 INVITE
4.1.1.6 Max-Fowords 头字段
Max-Fowords 头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。它包含一个整数值,每经过一跳, 这个值就被减一。如果在请求消息到达目的地之前该值变为零,那么请求将被拒绝并返回一个483( 跳数过多)错误响应消息。
UAC 必须在它发起的每个请求中都插入Max-Fowords 头字段,值为70。在任何不出现回路的SIP 网络中,选择该值为70 足够大的保证一个请求消息不被丢弃,且在有回路的情况下,这个值也不会太大而过分浪费代理服务器的资源。UA 只有知道网络的拓扑结构时,才可以谨慎地选择更小的跳数值。
4.1.1.7 Via头字段
Via 头字段定义SIP 事务的下层(传输层) 传输协议, 并标识响应消息将要被发送的位置。只有当到达下一跳所用的传输协议被选定后,才能在请求消息中加入Via 头字段值。
本协议规定,当UAC 生成请求消息时,它必须在其中插入一个Via 头字段。Via 头字段的协议名称和协议版本必须分别为“SIP ”和“2.0”。Via 头字段中必须包含一个“branch ”参数,该参数用来标识由当前请求所建立的事务。该参数既用在客户端也用在服务器端。
对于某个UA 发出的所有请求,它们的branch 参数值在空间和时间上必须全局唯一的。但有两种情况例外:一是CANCEL 请求,以后会说明CANCEL 请求的branch 参数与它所要取消的那个请求的branch 参数是一样的; 另一个是对非2xx 响应的ACK 请求, 参见本规范17.1.1.3 节,这种情况下ACK 请求与相关的INVITE 请求有着同样的branch ID, 它所要确认的就是该INVITE 的响应。
branch ID 参数的唯一性特点使它能被用作事务的ID,但并不在RFC2543 的讨论范围之内。
SIP 实体在插入branch ID 时,必须以”z9hG4bK” 开头。这7 个字符是“magic cookie”
(7 个字符足以保证不会与旧的RFC2543 实体的选取值相同),这样SIP 服务器在收到请求消息时, 就能确定现在的branch ID 是全局唯一。另外,branch ID 参数的准确格式由具体的实现定义。
Via 头的maddr 、ttl、以及sent-by 部分在传输层对请求消息进行处理时进行设置,参见本规范第18 章。
关于代理服务器对Via 头字段的处理参见本规范16.6 节和16.7 节。
4.1.1.8 Contact 头字段
Contact 头字段指定一个SIP 或SIPS URI ,后续请求可以用它来联系到当前UA。任何能够建立对话的请求消息中都必须有Contact 头字段, 并且该头字段中只能含有一个SIP 或SIPS URI 。在本规范定义的请求方法中, 只有INVITE 能建立对话。对这些能建立对话的请求,Contact 的作用范围是全局的。也就是说,Contact 头字段值中包含的URI 是UA 希望用来接收请求的地址,即使用在任何对话外的后续请求消息中,该URI 也必须有效。
如果请求消息的Request-URI 或顶端Route 头字段值中包含了SIPS URI, 那么在Contact 头字段中也必须包含一个SIPS URI 。
关于Contact 头字段参见本规范20.10 节。
4.1.1.9 Supported 和Require 头字段
如果UAC 支持某些SIP 协议的扩展,并且这些扩展可被服务器用来构成请求的响应,那么UAC 应在请求消息中包含一个Supported 头字段,列出这些扩展的选项标签。
只有在RFC 规范中定义的扩展所对应的选项标签能够在Supported 头字段中列出。在实验性和信息性RFC 中定义的扩展禁止在Supported 头字段中使用。
如果UAC 要求UAS 必须理解某项扩展以便处理它所发出的请求,它必须在请求消息中插入一个Require 头字段,并列出此扩展的选项标签。如果UAC 希望在请求中使用某项扩展,并要求请求消息经过的所有代理服务器都能理解此扩展,它必须在请求消息中插入一个Proxy-Require 头字段,并列出此扩展的选项标签。
同Supported 头字段一样,Require 和Proxy-Require 头字段中的选项标签所对应的扩展也必须是在标准RFC 的后续规范中定义的。
4.1.1.10 消息的其它部分
在新的请求消息生成且上述头字段被正确构造之后,可加入任何其它的可选头字段和请求方法所要求的特定头字段。
SIP 请求消息中可包含一个按MIME 格式编码的消息体。无论请求中包含的消息体类型如何,都必须构造某些头字段以表征消息体的内容。这部分头字段的内容参见本规范20.11 节到20.15 节。
4.1.2 请求消息的发送
首先确定请求消息的发送目的地。除非另有本地策略,目的地址必须按照RFC3263 中的DNS 过程确定:如果Route 头字段中路由集的第一个实体是个严格的路由器,(请求消息按本规范12.2.1.1 节所述构造),RFC3263 中的过程必须被应用于请求消息的Request-URI ;否则,RFC3263 中的过程应用于请求消息中的第一个Route 头字段值,若没有Route 头字段出现则RFC3263 中的过程仍然应用于请求消息的Request-URI 。其输出结果是个可以发送的目标地址有序集,其中每一项是个由地址、端口号以及传输协议构成的三元组。不论用哪个URI 作为RFC3263 过程的输入,如果Request-URI 指定一个SIPS 资源,UAC 就必须把这个URI 当作SIPS URI 来解析。
本地策略可指定其它目标地址集。如果Request-URI 中包含的是SIPS URI,那么同该地址集中的任何目的地址联系都必须使用TLS 。此外,如果请求消息中不含Route 头字段, 那么对该地址集中的地址没有其它限制。当指定一个外拨代理服务器时, 这样做比预设路由集简单。但是,本规范建议用只含单个URI 的预设路由集来指定外拨代理服务器。如果请求消息中含有Route 头字段,那么请求消息应当发送到最顶端Route 头字段值所指示的位置; 也可发送到任何其它的服务器。只要UA 确认这些服务器遵循本规范中对Route 和Request-URI 的处理策略。本规范建议,配置了外拨代理服务器的UAC 应该尝试将请求发往第一个Route 头字段值所指的位置,而不是将所有消息都发往外拨代理服务器。
这保证了那些不向请求消息中加入Record-Route 头字段值的外拨代理服务器能从后续请求的传输路径上离开。使那些不能解析第一个Route URI 的终端可以将此任务委托给外拨代理服务器。
对于有状态SIP 实体,UAC 应当遵循RFC3263 中定义的过程尝试目标地址集中的每个地址,直到联系上某个服务器。每次尝试都会建立新的事务,因而每个新请求的最顶端Via 头字段值都不同, 其中包含着新的branch 参数。此外,Via 头字段中的transport 值也要根据不同的目标服务器来设置。
4.1.3 响应消息处理
响应消息先由传输层处理, 然后上传到事务层。经事务层处理后再将其上传给事务用户(TU)。TU 对响应消息的处理主要依赖于请求方法,但是一些基本处理方法则同具体的请求方法无关。
4.1.3.1 事务层错误
某些情况下, 从事务层返回的并不是SIP 消息,而是事务层错误消息。当TU 从事务层收到超时错误消息时,对该消息的处理必须同408(请求超时)状态码。如果事务层报告的是严重错误,通常是UDP 方式下的严重ICMP 错误或TCP 连接失败所致,则该消息的处理同503(业务不可用)状态码。
4.1.3.2 无法识别的响应消息
对无法识别的最终响应,UAC 必须将之等价于所属响应类别的x00 响应码,且UAC 必须能够处理所有响应类别的x00 响应码。例如:如果UAC 收到了一个无法识别的响应码431,那么它能断定自己发出的请求消息出错,因而对该431 码的处理同400(错误请求)响应码。但对于任何无法识别的非100 临时响应的处理必须同183 响应(会话处理中)。UAC 必须能够处理100 和183 响应。
4.1.3.3 多Via 头字段值
如果某个响应消息中出现了多个Via 头字段值,UAC 应当丢弃该响应。
在标识请求发起者的Via 头字段值之前出现了其它的Via 头字段值,表明消息在传送过程中发生了路由错误,或者已被破坏。
4.1.3.4 3xx响应码处理
客户端在收到重定向响应时,应基于相应的重定向的请求消息的Contact 头字段中的URI 来构造一个或多个新的请求消息。这同在16.5 和16.6 节中代理服务器递归处理3xx 类响应的过程类似。客户端的目标地址集中最初只有一个URI,即初始请求的Request-URI 。如果客户端要根据初始请求的一个3xx 类响应构造新的请求消息, 它应把可能的URI 放入目标地址集中。UAC 在遵循本规范定义的限制条件下,可以选择Contact 头字段中一些URI 放入目标地址集。同代理服务器进行递归处理时一样, 客户端在处理3xx 类响应时不可以将任何URI 多次加入到目标地址集中。如果初始请求消息的Request-URI 为SIPS URI, 客户端可选择到非SIPS URI 地址的递归处理, 同时应当通知用户其请求被重定向到不安全的URI 。
任何新请求的发出都可能收到3xx 响应,这些响应的又包含了原始请求的Request-URI 。这是因为两个地址有可能被配置成互为重定向目标。所以为了防止出现重定向循环,规定任何URI 只能在目标地址集中放置一次。
随着地址集中条目的增长,客户端可按任何次序来产生到这些URI 地址的新请求。通常是按Contact 头字段值中q 值的大小对地址集中的条目进行排序。请求消息可以串行或并行生成。一种做法是按q 值的降序分组后串行处理, 同组的URI 并行处理。另一种方法是只按q 值的降序串行处理,q 值相等的则次序任选。
如果与目标地址集中的某个地址联系失败,UA 应继续试下一条地址, 直到所有的地址都用完。如果所有的地址都已用完,即告请求失败。
请求失败应当通过失败响应码来检测, 响应码应大于399。对于网络错误,客户端事务将向事务用户(TU)报告传输层失败。有些响应码指示请求可以重发,重发的请求不应视为失败。
当客户端与一个地址的联系失败后,它应继续联系下一个地址。这将创建一个新的事务来发送新的请求。
如果UAC 基于3xx 响应码中的某个Contact 地址来创建新请求,就必须从目标地址集中把相应的URI 除了method-param 和header 外全部拷贝到Request-URI 中。Header 参数可以用于创建新请求的某些头字段值并重写重定向请求的某些头字段值,具体规则参见本规范19.1.5 。
某种情况下,Contact 地址中所携带的头字段可附于最初的重定向请求的现有头字段之后。本协议规定,如果某个头字段能接受逗号分隔的值列表,那么新的头字段值可被附于原始请求的现有值之后; 如果某个头字段不接受多值,则原始请求的现有值可被Contact 地址中携带的头字段值重写。例如: 如果3xx 响应码中返回的Contact 地址带有下列值:
sip:user@host?Subject=foo&Call-Info= 〈http://www.foo.com 〉
那么原始请求的每个Subject 头字段都将被重写,但那个HTTP URI 只是被附加到现有的Call-Info 头字段值之后。
本规范建议,UAC 可以重用原始请求的To、From 和Call-ID 头字段。
如果新的请求消息构建完成,它将在一个新的事务中发送。顶端Via 字段中必须有一个新的branch ID 参数。
本协议规定,对于所有未述及部分,在收到重定向响应之后发送的新请求应重用原始请求的头字段和消息体。
某种情况下,UAC 会根据收到的响应码以及Contact 头字段的有效期来临时或永久地缓存某些Contact 头字段值。具体规则参见本规范21.3.2 和21.3.3 节。
4.1.3.5 4xx响应消息处理
某些4xx 响应码需要特定UA 的处理,处理方法与请求方法无关。
本协议规定,UAC 在收到401 (未授权)或者407(代理服务器需要鉴权)响应码时应按22.2 和
22.3 中的授权过程来重发携带鉴权证书的请求。
如果收到的是413 (请求消息过大) 响应( 参见21.4.11 节), 说明请求中包含的消息体超过了UAS 所能接受的长度。在可能的情况下,UAC 应当去掉消息体或减小它的长度。
如果收到的是415( 不支持的媒体类型)响应(参见21.4.13 节),说明请求中包含了UAS 不能支持的媒体类型。UAC 应重发请求,并只用响应消息的Accept 头字段中列出的类型、Accept-Encoding 头字段中列出的编码方式和Accept-Language 头字段中列出的语言种类。
如果收到的是416 (不支持的URI 方案)响应(参见21.4.14 节), 说明请求中的Request-URI 使用了UAS 不支持的URI 方案。UAC 应当将其改为SIP URI 后重发该请求。
如果收到的是420 (错误的扩展)响应( 参见21.4.15 节), 说明请求的Require 或Proxy-Require 头字段中列出了某个选项标签,该标签所对应的扩展特性不能被UAS 或代理服务器所支持。此时,UAC 应当去掉在响应消息的Unsupported 头字段中列出的所有不支持的扩展,然后重发请求。
所有上述情况下,请求消息重发都是通过对原请求作适当修改之后创建一个新请求来完成的。新请求建立了一个新的事务,并且与原请求有相同的Call-ID 、To 和From 。但CSeq 应当包含一个新序列号值,它比原请求中CSeq 的序列号大一。
对其它4xx 响应,包括那些将要定义的,请求消息重发是否可能要依赖于具体的请求方法和应用场合。
4.2 UAS基本行为
UAS 处理会话外请求时, 其处理规则与请求方法无关。
请求消息的处理具有原子性。如果请求被接受,那么与之相关的所有状态改变都必须被执行;如果请求被拒绝,则所有状态变化全部禁止。
UAS 应当按下述步骤处理请求:即从鉴权开始,然后检查请求方法,检查各个头字段等。
4.2.1 请求方法检查
在请求的鉴权完成后,UAS 必须检查请求的方法。如果UAS 认识但不支持某个请求方法, 它必须产生一个405( 不允许的请求方法)响应,响应产生的过程参见本规范8.2.6。UAS 还必须在此405 响应中加入一个Allow 头字段,其中列出所有它所支持的请求方法。关于Allow 头字段参见本规范20.5 节。
如果UAS 能够支持请求的类型,处理继续进行。
4.2.1.1 消息头检查
如果UAS 不理解请求消息中的某个头字段(即该头字段未在本规范或任何它所支持的扩展中定义), 它必须忽略这个头字段并继续进行处理。此外,UAS 应当忽略任何不影响请求处理的格式错误的头字段。
4.2.1.2 To和Request-URI 头字段
To 头字段标识了请求消息的原始接收者,它由From 头字段所标识的用户指定。由于呼叫转发或其它代理服务器操作,请求的原始接收者不一定是最终处理该请求的UAS。当To 头字段所标识的接收者不是自己时,UAS 可应用任何策略来决定是否接受该请求。本规范建议, 即使UAS 不能识别请求消息中To 头字段的URI 编码方案, 或不知道该头字段所要寻址的用户, 或该用户并非它的当前用户,UAS 仍然要接收这些请求消息。另外,如果UAS 决定拒绝某个请求,那么它应当产生一个403 (禁止)响应,并将该响应传递给服务器端的事务发送。
请求消息的Request-URI 标识了将要处理该请求的UAS 。如果请求消息的Request-URI 使用了UAS 所不支持的URI 方案,UAS 应用一个416 响应(不支持的URI 方案)拒绝该请求。如果请求消息的Request-URI 标识的不是UAS 想要用来接收请求的地址,UAS 应当用一个404( 未找到) 响应拒绝该请求。一般来说,UA 用REGISTER 请求把自己的注册地址与某个特定的联系地址绑定到一起, 其后的请求消息的Request-URI 等于该联系地址。另外,Request-URI 也源于UA 建立或更新对话时所发出的请求或响应中的Contact 头字段。
4.2.1.3 请求消息的合并
如果请求消息的To 头字段中没有标签, 此时,UAS 必须针对该请求检查正在进行的事务。如果请求的From 标签、Call-ID 和Cseq 与某个正在进行的事务的有关信息相匹配,但依据本规范17.2.3 节所述的匹配规则,该请求又确实与该事务不匹配, 则UAS 应产生一个482(检测到路由循环)响应并传递给服务器端的事务进行处理。
同一个请求沿着不同的路径多次到达某个UAS,最大的可能是发生了分叉代理现象。这时UAS 正常处理第一个请求,其余的回送482 响应。
4.2.1.4 Require 头字段
12
当UAS 认为自己可以处理某一请求时,它将检查请求消息中出现的Require 头字段。
UAC 用Require 头字段来通知UAS 它所希望该UAS 能够支持的SIP 扩展,以便UAS 能正确处理它所发出的请求消息。有关Require 头字段的格式参见本规范20.32 节。如果UAS 不能理解Require 头字段中所列出的扩展选项标签,它必须回以420( 错误的扩展)响应。同时必须在该响应中加入一个Unsupported 头字段,以列出请求的Require 头字段中它不支持的那些扩展选项。
本协议规定,Require 头字段和Proxy-Require 头字段不能用在CANCEL 请求中,也不可用在非2xx 响应的ACK 请求中。如果这些请求中出现了这两个头字段,该请求必须被忽略。
2xx 响应的ACK 请求中只能包含对应的原始请求中出现的那些Require 和Proxy-Require 值。
例如:
UAC->UAS: INVITE sip:Watson@bell-telphone.com SIP/2.0

Require: 100rel

UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 100rel

UAS 的这种处理方式保证了当会话双方都能理解所有的扩展选项时,客户与服务器间交互可以无延迟地顺利进行,而如果扩展选项不被理解则会导致交互过程减慢(如上例所示)。对于一个配合良好的客户机—服务器对,理解扩展选项之后省去了能力协商机制,因而交互可以快速进行。此外,当 UAC 对UAS 提出其不支持的特性时,它使双方的交互和表达能够准确清晰地进行。
4.2.2 消息内容处理
如果UAS 理解客户端要求的任何扩展,它将检查消息体和描述消息体内容的消息头字段。如果UAS 不理解消息体中任何由Content-Type 指示的类型、由Content-Language 指示的语言或由Content-Encoding 指示的编码, 且对该部分消息体的处理是必选的( 如Content-Disposition 头字段所示),那么UAS 必须用一个415( 不支持的媒体类型)响应拒绝请求。如果请求中包含了UAS 不支持的消息体类型,响应消息中必须包含一个Accept 头字段,其中列出它能理解的所有消息体类型。如果请求中包含了UAS 不理解的编码方式,响应消息中必须包含一个Accept-Encoding 头字段,其中列出它能理解的编码方式。如果请求中包含了UAS 不理解的语言,响应消息中必须包含一个Accept-Language 头字段,其中列出它能理解的语言。除此之外, 消息体的处理和请求的方法以及消息体的类型有关。关于同消息体内容相关的头字段的处理参见本规范7.4 节及20.11 节到20.15 节。
4.2.3 扩展的应用
如果UAS 在响应时要应用某些扩展,那么相应的请求的Supported 头字段中必须已指明客户端支持这些扩展。如果客户端不支持需要的扩展,UAS 只能依赖基本的SIP 协议和客户端支持的扩展来达到目的。极个别情况下如果没有所需的扩展支持则请求无法处理,此时UAS 可发出421(需要扩展支持)响应。该响应指出如果不支持某一特定扩展就无法产生正确的响应, 该响应的Require 头字段中必须包含需要支持的扩展选项。由于起可能破坏互操作性,因此本规范不建议采用这种方式。
对非421 响应要用的任何扩展也必须在该421 响应的Require 头字段中列出, 并且不能使用请求的Supported 头字段中未列出的扩展。这样,响应消息的Require 头字段将只能包含标准RFC 的后续规范中定义的扩展选项标签。
4.2.4 请求的处理
如果上述检查全部通过, 接下来UAS 的处理就与具体的请求方法相关了。第十章为REGISTER 请求的处理,第十一章为了OPTIONS 请求的处理,第十三章为了INVITE 请求的处理,第十五章为了BYE 请求的处理。
4.2.5 产生响应
当UAS 要遵循下列章节的流程来要构造某个请求的响应,可能还需要某些特定响应码相关的处理,但本节不作描述。
UAS 在完成创建响应的所有流程之后,应把响应消息传递给发起请求的服务器端的事务。
4.2.5.1 发送临时响应
UAS 不应考虑对非INVITE 请求发送临时响应, 而是应尽快对其产生最终响应。
当100(正在尝试)响应产生后,请求消息中出现的任何Timestamp 头字段都必须被复制到该响应中去。如果响应产生时出现了延迟,UAS 应当在响应的Timestamp 值上附加一个延迟值。这个延迟值必须是从收到请求开始到发出响应为止的以秒计算的时间间隔。
4.2.5.2 头字段和标签
响应消息的From 头字段、Call-ID 头字段和Cseq 头字段必须分别与被响应的请求的From 头字段、Call-ID 头字段和Cseq 头字段相等。本规范要求,Via 头字段不但值必须要相等,各个值之间的顺序也必须保持一致。
如果请求消息中包含To 标签,那么响应消息的To 头字段必须与请求消息的To 头字段相等。然而,如果请求消息的To 头字段不包含标签,那么响应消息中To 头字段的URI 必须与请求消息中To 头字段的URI 相等;此外,UAS 必须在响应消息的To 头字段中添加一个标签(100 响应例外, 因为100 响应中可以没有标签), 这是为了标识正在应答的UAS, 也许会成为一个对话ID 的组成部分。同一个请求的所有响应必须使用同一个标签,包括临时响应和最终响应(100 响应仍然例外)。关于产生标签的过程参见本规范19.3 节。
4.3 重定向服务器
代理服务器负责请求消息的路由。某些体系结构下可能需要降低它们的负荷,并提高信令传输通道的鲁棒性,这时可依靠请求重定向来达到目的。
重定向即服务器用响应消息将某一请求的路由信息返回给客户端,从而使服务器既起到了帮助选路的功能, 又可以不用处理由该请求所导致的更多消息往来。当请求的发起者收到重定向响应后, 它将基于收到的URI 发送新的请求。重定向通过把URI 信息从网络的核心传递到边缘而使网络获得了相当大的扩展升级能力。
重定向服务器逻辑上由一个服务器端事务层和一个能够访问某种定位服务的事务用户组成。有关注册服务器及定位服务参见本规范第10 章。定位服务器实质上是一个数据库,它包含单个URI 到一个或多个联系地址之间的映射,通过这些联系地址就能找到URI 所对应的用户或实体。
重定向服务器自己不发送任何SIP 请求。在收到除CANCEL 以外的请求时,重定向服务器可以拒绝它,或者通过定位服务获得一个可选地址列表并返回一个3xx 最终响应。对格式正确的CANCEL 请求, 重定向服务器应返回2xx 响应。该响应将结束被取消请求的SIP 事务。重定向服务器维护整个SIP 事务的状态。客户端检测重定向服务器之间发生的转发循环。
当重定向服务器返回某个请求的3xx 响应时,它在Contact 头字段中装入一个地址列表( 含一个或多个可选地址)。Contact 头字段值中还可能提供“expires ”参数,以指明Contact 数据的有效期。
Contact 头字段包含了可供发送的URI ,这些URI 给出了新的目标位置或新的用户名, 或者只简单地指定了一些其它的传输参数。301( 永久移动)或302(临时移动)响应可能会给出与初始请求一样的目标位置和用户名,同时又指定另外的传输参数,比如一个不同的服务器地址或多播地址,或者将SIP 消息的传输方式从UDP 改为TCP 或从TCP 改为UDP,等等。
然而,重定向服务器决不能将请求重定向到一个与请求的Request-URI 相同的URI 地址。如果重定向的目的地URI 所指并非当前重定向服务器, 它可能将请求向重定向目的地转发, 或用一个404 (未找到)响应来拒绝请求。
如果客户端在使用一个外拨代理服务器,而该外拨代理实际上在重定向请求,这时就可能出现无限重定向循环。
Contact 头字段值也可能指示与原始被叫不同的资源位置。例如,一个连接到PSTN 网关的SIP 呼叫可能需要发送一个特定的录音通知。
响应消息的Contact 头字段可能包含任何指示被叫位置的URI 类型, 而并不仅限于SIP URI 。例如,它可能包含电话、传真、或irc (如果它们已被定义)URI,或一个“mailto:(RFC2368[32] 中定义)
”URL。
Contact 头字段值的expires 参数指出了该值中包含的URI 地址的有效期。这个参数的值是以秒为单位计算的。如果没有提供该参数, 那么URI 地址的有效期由Expires 头字段值来确定。格式错误的有效期值应被视为3600 来处理。
这是为了适度提供对RFC2543 的后向兼容性,因为在RFC2543 中允许Expires 头字段包含绝对时间。如果收到了用绝对时间表示的有效期值,它将被认为格式错误并缺省地用3600 代替。
如果请求中包含不能理解的内容(包括不可识别的头字段,Require 中任何未知的选项标签,甚至请求方法名等),重定向服务器必须忽略它们并继续进行重定向处理。
5 请求的取消
CANCEL 用于取消客户端发送的前一个请求。特别是当要求UAS 终止对被取消请求的处理,并对那个请求产生一个错误响应。对于UAS 已经给出了最终响应的请求,CANCEL 是无效的。因此,CANCEL 主要用于取消服务器端需要长时间才能给出响应的请求。CANCEL 请求最适合于INVITE 请求,因为它会需要很长的时间来产生响应。在这种情况下, 如果UAS 收到了针对INVITE 的CANCEL 请求, 但还没有为之发出最终响应,则UAS 将”停止振铃”,然后用一个特定的错误响应(一个487)来应答INVITE 。
代理服务器和UAC 都可以产生并发送CANCEL 请求。这两部分内容分别参见本规范第15 章和
16.10 节。
有状态的代理服务器应当应答收到的CANCEL, 而不是简单地转发从下游实体收到的响应。因此, 由于CANCEL “跳”到每一个有状态的代理服务器时都会被应答,所以它是个“逐跳”(hop-by-hop)
15
的请求。
5.1 客户端行为
CANCEL 请求不应当用于取消非INVITE 请求。
非INVITE 请求会立刻被响应,发出CANCEL 来取消一个非INVITE 请求通常将会产生竞争。
下列过程用于构造一个CANCEL 请求消息:CANCEL 请求的Request-URI,Call-ID, To, CSeq 的数字部分,以及From 头字段,包括各个标签,都必须与被取消请求的对应部分相同。客户端产生的CANCEL 必须只能有一个Via 头字段值,并与被取消请求的顶端Via 值相匹配。这些头字段值的一致性使得CANCEL 请求能与被取消的请求相匹配。但是,Cseq 头字段中“method” 部分的值必须是”CANCEL”, 以保证CANCEL 请求能够被识别并在一个它自己的事务中被处理。
如果被取消请求包含一个Route 头字段,CANCEL 请求中必须包含此Route 头字段的值。
这个要求是为了让无状态代理服务器能够正确地路由CANCEL 请求。
CANCEL 请求不能包含任何Require 或Proxy-Require 头字段。
一旦CANCEL 请求构造完毕,客户端应当检查是否已收到了被取消请求(下文将统称为原请求)的任何响应消息(临时的或最终的)。
如果还没有收到临时响应消息,那么CANCEL 请求不能发送,而是一直等待,直到一个临时响应到来。如果原请求已经产生了一个最终响应,由于CANCEL 对已经产生了最终响应的请求是无效的, 那么CANCEL 请求也不应当发送, 既然。当客户端决定要发送CANCEL 时,它为该请求创建一个客户端事务, 并将CANCEL 消息和目的地址、端口、以及传输方式一起传递给新创建的事务。CANCEL 请求的目的地址、端口和传输方式必须与原请求的相同。
如果允许在收到响应消息之前发送CANCEL 请求,那么服务器端有可能在收到原请求之前先收到CANCEL 请求。
对应于原请求的事务和CANCEL 请求的事务都将独立完成。但是,一个执行请求取消的UA 不能依赖于收到原请求的487 响应消息来进行后续处理, 因为遵从RFC2543 标准,UAS 将不会产生487 响应。如果在64*T1 秒(T1 在17.1.1.1 节中定义)内没有收到原请求的最终响应,那么UAC 应认为原请求已经被取消,并终止原请求的事务处理。
5.2 服务器端行为
CANCEL 方法请求服务器端的事务用户(TU) 取消一个未决的事务。事务用户假定原请求的方法是除了CANCEL 或ACK 之外的任何一个,并进行事务匹配,匹配到的事务将被取消。匹配规则参见本规范17.2.3 节。
服务器如何处理CANCEL 请求依赖于服务器的类型。无状态代理服务器将简单地转发请求;有状态代理服务器会对其做出应答并产生自己的CANCEL 请求;UAS 将对CANCEL 请求做出应答。关于代理服务器对CANCEL 的处理方式参见本规范16.10 节。
UAS 首先按8.2 节所述的基本规则对CANCEL 进行处理。由于CANCEL 请求是逐跳处理的并且不
YD ××××—×××× 能重传,所以UAS 不能对它们发出质询(Challenge )来得到在Authorization 头字段中携带的证书(Credentials)。CANCEL 请求不包含Require 头字段。
然后,UAS 对CANCEL 请求进行事务匹配。如果依据上述的过程没有找到匹配的事务,那么UAS 应当用一个481 响应(事务或呼叫方不存在) 来应答CANCEL 请求。如果匹配到了原请求的事务, 那么UAS 的处理行为将取决于是否已经发送了对原请求的最终响应。如果响应已经发送, 那么CANCEL 请求不影响对原请求的处理,也不影响任何会话状态和原请求的响应。如果最终响应没有发送,那么UAS 的处理方式将取决于原请求的类型。如果原请求是一个INVITE,UAS 应立即对它发送487 (请求终止)响应。而对本规范中定义的任何其它的请求方法,CANCEL 请求对它们的事务处理都不起作用。
不管原请求的类型是什么,只要CANCEL 匹配到了一个现存的事务,UAS 都要用一个200(OK) 响应来应答CANCEL 请求。这个响应要遵循8.2.6 节中的过程构造,注意CANCEL 响应的To 标签应当与原请求响应的To 标签相同。CANCEL 的响应消息被传递给一个服务器端事务以便发送。
9、10 章没有
6 注册(暂缺) 7 查询能力
OPTIONS 用于一个UA 向另外一个UA 或者代理服务器查询对方的能力。这让客户机不必向对方“振铃”就可以获得对方地下列信息:包括支持的方法、内容类型、扩展名、以及编解码方法等等。例如,客户机要在INVITE 中插入Require 头字段之前,并不确定目的地UAS 是否支持Require 中所列的选项,则客户机就可以使用OPTIONS 方法看目的地UAS 回应的Supported 字段中是否包括这个选项以确定对方是否支持它。所有的用户代理都应支持OPTIONS 方法。
OPTIONS 请求的目标由Request-URI 来指定,它可以指定另外一个UA 或者SIP 服务器。
如果OPTIONS 发送到一个代理服务器,那么Request-URI 的设置方法就如同REGISTER 请求,其中没有用户部分。服务器收到的OPTIONS 请求中的Max-Forwards 头字段的值是0,那么它可以响应这个请求,而不必考虑Request-URI 的值。这种处理如同HTTP/1.1, 可以用作“路径”功能,通过发送一系列包含递增的Max-Forwards 值的OPTIONS 请求来来查询路径中每个服务器的能力。
如果OPTIONS 没有响应,事务层就返回一个超时错误来表明目标不可达。
发送OPTIONS 请求也可以作为已建立的对话的一部分, 可以询问对等体的能力以备将来的对话所用。
7.1 OPTIONS 请求的构造
如何构造OPTIONS 请求参见本规范 8.1.1 中构建SIP 请求的规则。
OPTIONS 请求中可以包括一个Contact 头字段。
YD ××××—××××
OPTIONS 请求中应包括一个Accept 头字段,该字段指明在所收到的响应中,UAC 支持的消息体的类型。一般情况下,该字段被设置成用来描述UA 媒体能力的格式,例如SDP (application/sdp) 。
OPTIONS 的响应的范围是初始请求的Request-URI 。然而,只有OPTIONS 请求作为已建立的对话的一部分发送时,后续的请求才能够被产生OPTIONS 响应的服务器收到。
OPTIONS 请求的例子如下:
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 0
7.2 OPTIONS 请求的处理
如何构造OPTIONS 响应参见本规范 8.2.6 中SIP 响应的构造方法。响应码的选择同INVITE 请求。即,当UAS 准备接受呼叫时返回响应200 (OK),,UAS 忙时返回响应486 (正忙)。这样,用OPTIONS 来确定UAS 的基本状态并指出该UAS 是否接受INVITE 请求。
在对话中收到OPTIONS 请求时发送响应200 (OK)响应,这等同于在对话之外构建响应,并对该对话没有任何影响。
代理服务器处理OPTIONS 和INVITE 的不同导致OPTIONS 的使用限制。由于代理服务器使用non-INVITE 的方法处理OPTION 请求,一个分叉代理的INVITE 请求可以有多个200 (OK) 响应,而分叉代理的OPTIONS 请求只能有一个200 (OK) 响应, 具体内容参见本规范16.7 。
如果OPTIONS 请求消息的响应是由代理服务器发出的,并列出该服务器的能力,例如响应200 (OK) 。该响应不包括消息体。
响应码200 (OK) 中应该包括以下头字段:Allow, Accept, Accept-Encoding, Accept-Language 和Supported 。如果该响应是由代理服务器发出, 由于代理服务器不能识别方法,因此Allow 头字段就应被忽略。响应200 (OK)中可包括Contact 头字段,并且与3xx 响应中的语义完全相同。也就是说它们可以列出一组可选择的名字和方法。该响应中也可以包括Warning 头字段。
YD ××××—××××
可被发送的消息体的类型由OPTIONS 的Accept 字段指定(缺省为application/sdp)。如果该类型能够描述媒体能力,UAS 就应该在响应中构建一个消息体。在application/sdp 情况下构建这样一个消息体的细节参见RFC3264 。
下面是UAS 发出OPTIONS 响应的例子(对应于11.1 中的请求):
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
;received=192.0.2.4
To: <sip:carol@chicago.com>;tag=93810874

From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Contact: <mailto:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Content-Length: 274
(SDP not shown)

8 对话(dialog)
对话是两个UA 之间持续一段时间的点对点的SIP 连接,它使UA 之间的消息变得有序, 同时给出请求消息的正确的路由。对话包括一个解释SIP 消息的上下文。有关对话外独立UA 处理请求和响应的方法参见本规范第8 章。本章将规定如何使用那些请求和响应去建立一个对话,以及在对话过程中如何发送后续的请求和响应。
任何UA 上的对话都是由对话ID 来标识的,这个对话ID 包含一个Call-ID ,一个本地标签和一个远端标签。对话中的每个UA 的对话ID 是不同的。另外,一个UA 的本地标识符与对端UA 的远端标识符相等。标签(tags)在唯一的对话ID 的生成过程中是不透明的。
对话ID 与其To 头字段中包含一个标签(tag) 的所有响应和请有关。某个消息中的对话ID 的计算规则取决于SIP 实体是UAC 还是UAS 。对于UAC,对话ID 中的Call-ID 由消息的Call-ID 头字段设置, 远端标签(tag )由To 头字段的tag 设置,本地标签由于From 头字段的tag 设置。对于UAS ,对话ID
19
中的Call-ID 由消息中的Call-ID 头字段设置,远端标签由消息From 头字段的tag 设置,本地标识符于消息To 头字段的tag 设置;
对话中包括一些对话中的后续消息所需的状态,包括:对话ID、本地序列号、远端序列号、本地URI、远端URI 、远端目的、布尔型标记“secure” 和路由集,其中路由集是一个顺序的URI 集,指定发送一个请求到对端所需遍历的服务器地址。
临时的响应被创建时,对话处于“初始状态”, 当一个2xx 的最终响应到达时转为“ 确认状态”, 如果是其他响应或无响应到达,“初始状态”终止。
8.1 对话的创建
对话在请求消息得到了明确的非失败的响应之后才被创建。
依此规则,当INVITE 请求消息收到包含To 标签的2xx 响应和101-199 响应时,对话被创建。当一次对话随着一个非终止的响应被创建的时候,它处于“初始”状态,也可称其为初始对话。扩展中可以定义其他的对话创建方法。有关INVITE 方法的定义参见本规范第13 章,本章所及的对话状态创建的过程是不依赖于此方法的。
用户代理必须指定对话ID 各部分的值。
8.1.1 UAS 行为
UAS 对一个请求消息作出响应从而建立对话时,它必须将请求消息中的Record-Route 头字段拷贝到响应中去, 包括URI,URI 参数和任何Record-Route 头字段参数,并必须保持所有值的顺序。另外, UAS 必须在响应中添加一个Contact 头字段。该Contact 头字段包括了一个地址,在该地址上,UAS 可以接收该对话中的后续请求消息。通常,URI 的主机部分是IP 地址或者主机的全资格域名(FQDN)。在Contact 头字段中提供的URI 必须是SIP 或者SIPS URI 。如果一个请求消息开始一个对话,该消息的Request-URI 或Record-Route 头字段值中存在一个SIPS URI,或者如果该请求没有Record-Route 头字段而在Contact 头字段中包括SIPS URI, 则其响应中的Contact 头字段必须是SIPS URI 。而且该URI 必须是全局的。同样INVITE 方法中Contact 头字段里URI 的作用范围也不仅仅局限于该对话中, 它也可以在该对话外的发往UAC 的消息中使用。
然后UAS 构建对话的状态,在整个对话持续过程中,状态必须保持。
如果请求基于TLS( 传输层安全协议) 传送,同时Request-URI 中包含一个SIPS URI, “secure” 标签置为“TRUE”。路由集必须设置为请求消息的Record-Route 头字段中的URI 列表, 并保留顺序和URI 参数。如果在请求消息中无Record-Route 头字段,路由集必须为空。路由集即使为空也必须覆盖该对话的后续请求消息的现有的路由集。远端目的必须设置为来请求消息的Contact 头字段的URI 。
远端序列号必须设置为请求消息的CSeq 头字段中的序列号值,本地序列号为空;
对话ID 中的呼叫标志符必须设置为请求消息的Call-ID 值;
本地标签必须设置为该请求的响应消息的To 头字段的tag 值;
远端标签必须设置为请求消息的From 头字段的tag 值;
另外,UAS 必须能够接收一个在From 头字段中没有标签的请求消息,这种情况下标签值认为为空。
注:这种情况的存在保证了RFC2543 的后向兼容性,在它当中,不要求From 中有tag 字段。
远端URI 必须设置为From 头字段的URI;
本地URI 必须设置为To 头字段的URI 。
8.1.2 UAC 行为
当UAC 发送一个建立对话的请求, 如INVITE 请求,来建立对话时,该请求消息的Contact 头字段必须有一个全局的SIP 或SIPS URI ,如果请求消息中存在一个Request-URI 或者在Record-Route 头字段的顶部包含一个SIPS URI ,那么Contact 头字段必须包含一个SIPS URI 。
UAC 在接收到一个建立对话的响应消息后构建对话的状态。这个状态在整个的对话过程中必须保持不变。
20
如果请求基于TLS 传送,同时Request-URI 中包含一个SIPS URI,“secure”标签应设置为“TRUE”

路由集必须设置为响应消息的Record-Route 头字段的URI 列表,保持相反的顺序并保留所有的URI 参数。如果在响应消息中无Record-Route 头字段, 路由集必须设置为空,空路由集即使为空,也必须重写该对话的后续请求消息的现有的路由集。;
远端目的必须设置为响应消息Contact 头字段的URI;
本地序列号必须设置为请求消息的CSeq 头字段的序列号值;
远端序列号必须为空,当远端UA 发送一个本次对话中的请求后该值才可确定;
呼叫标识符必须设置为请求消息的Call-ID 值;
本地标签必须设置为请求From 头字段的标签值;
远端标签必须设置为响应To 头字段的标签值;
另外,UAC 必须可以接收一个To 头字段中不含标签值的响应,这种情况下标签值为空。
注:这种情况的存在保证了RFC2543 的后向兼容性,在它当中,不要求To 中有tag 字段。
远端URI 必须设置为To 头字段的URI 值;
------分隔线----------------------------
顶一下
(2)
100%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容
  • VoIP的配置选择

    前面,我们已经围绕Vo I P 讨论了一些问题。现在,让我们讨论几种Vo I P 的配置和拓扑...

  • SIP协议介绍

    介绍 通信提供商及其合作伙伴和用户越来越渴求新一代基于 IP 的服务。现在有了 SIP协...

  • IP电话协议H.323协议 MGCP协议 SIP协议比较

    随着IP电话应用的普及,建立终端设备和网关的可扩展网络已成为业界面临的一大技术挑战...