RFC3262中文版

RFC3262中文版
1.介绍
会话发起协议（SIP）文档（RFC 3261 [1]）是使用请求－响应协议来开始并管理通信会话。

SIP 定义了两种响应：临时响应和最终响应。

最终响应传输请求处理的结果，并使用可靠传输方式。

临时响应告知正在处理请求，在RFC3261中不是可靠传输的。

后来在一些案例中发现可靠性非常重要，包括与PSTN交互的场景。

因此，一个可选的能力需要用来支持临时响应的可靠传输。

这种能力在此规范提供。

该可靠性机制模仿目前对INVITE请求的2xx最终响应的可靠性机制。

这些请求定期地由TU（事务用户）传输直到一个单独的事务，收到一个ACK表示接受到了由UAC发出的2XX响应。

对于INVITE 的2XX响应和ACK消息是端到端的可靠传输。

为了达到临时响应的可靠性，我们使用类似的方法。

可靠临时响应由TU使用指数backoff方式进行重传。

这些重传在收到PRACK后结束。

PRACK请求扮演了和ACK同样的角色，只不过是对应临时响应。

这是一个很重要的区别。

PRACK是一个普通的SIP消息，就像BYE那样。

因此，它的可靠性通过每个有状态代理服务器来保证“HOP－BY－HOP”（跳至跳）的可靠性。

和BYE一样，不同于ACK,PRACK有自己的响应。

如果不是这种情况，PRACK消息无法穿越代理服务器，兼容于RFC 2543 [4]。

每个临时响应都有一个序列号（sequence number）, 携带在响应的RSeq头字段。

PRACK包含一个RAck头字段，表明了它所确认的临时响应的序列号。

该确认不是累积的，本说明建议一次只发一个明显临时响应，以控制拥塞。

2.术语
在这份文件中，关键词“必须”，“必须不”，“要求”，“应当”，“不应”，“应该”，“不应该”，“建议”，“或许”，和“可选”是被解释为在RFC 2119 [2]和表明为实现SIP标准要求的水平。

3.UAS行为
当初始INVITE包含一个支持（Supported）头字段带有可选标签100rel。

UAS可能发送任何非100临时响应来可靠地回应INVITE，本说明不允许除对应INVITE之外的临时可靠响应，扩展定义了新的方法来建立对话可能会使用这种机制。

当初始INVITE包含一个必须（Required）头字段带有可选标签100rel。

UAS必须发送任何非100临时响应，如果UAS不愿意接受，它必须使用420（错误的扩展）携带不支持的带有可选标签100Rel 的头字段拒绝初始请求。

UAS不允许对100临时响应进行可靠传输。

只有101到199可以可靠传输。

如果请求既没有Supported或Require头字段来表明这个特性，UAS不允许可靠地发送临时响应。

100Trying响应只能hop-by-hop（跳至跳）,这个原因，这里描述的end-to-end（端到端）地可靠机制不能使用。

可以作为代理的成员（element）也能发送可靠的临时响应。

这种情况下，它在这个事务中作为UAS。

但是，它不能对带有一个标签的To头字段的任何请求做可靠临时响应。

这意味着一个代理不能对对话中发送的请求生成可靠临时响应。

不同于UAS，当代理成员（element）收到一个不匹配可靠临时响应的PRACK，该PRACK必须被代理。

为什么UAS可能想发送一个可靠的临时响应，有如下几个理由：第一，如果INVITE事务可能需要时间来产生最终响应。

如3261中13.3.1.1章节谈论的，UAS将需要发送定期的临时响应来向代理请求一个事务的“扩展”。

需求是一个代理会每隔3分钟收到请求，但是因为丢包地可能性UAS需要更频繁地发送请求（建议间隔一分钟）。

作为一个更有效率的解决方案UAS可以可靠地发送响应。

这
样UAS应该每隔2.5分钟发送一个临时响应。

在扩展事务中使用可靠临时响应是建议性地。

剩余地讨论假设初始请求包换一个Supported或Require头字段列出100rel,并且有一个临时响
应被可靠的传输。

临时响应被可靠传输是有UAScore根据3261 8.2.6章节的程序来构造的。

另外，它必须包含Require头字段带有可选标签100rel和Rseq头字段。

UAS可能发送任何非100临时响应来可靠地回应INVITE，事务中第一个可靠临时响应的头字段的值必须在1和2**31－1之间。

建议从这个范围内均一地选择。

Rseq编号空间用于一个单独地事务。

这个意味着对于不同请求的临时响应可能使用相同的Rseq值。

可靠临时响应可能包含一个包体。

会话描述的用途在第五章介绍。

可靠临时响应被定期地传输到事务层。

间隔从T1妙开始，然后每隔双倍地时间重传一次（T1在3261中17章节定义）。

一旦传输到服务层事务，它将被加到一个内部未确认可靠临时响应列表。

事务层将转发每个从UAScore中传过来的重传。

这个和2xx响应的重传不同，2xx的间隔时间是T2秒。

这是因为ACK的重传是由一个2xx接收来触发的，但PRACK的重传独立于1xx的接收。

当从UACore中收到一个匹配的PRACK那么可靠临时响应的重传就结束。

PRACK就像对话中的其他请求一样，UAScore 根据3261 的8.2 ，12.2.2 章节程序来处理。

一个匹配的PRACK定义类似为在同一会话里的响应，它的方法，Cseq－num和响应号在Rack头字段匹配，分别的对应于可靠临时响应的Cseq的方法，序列号和可靠临时响应中的Rseq中的序列号。

如果UA core收到一个PRACK请求不匹配任何未确认可靠临时响应，UAS必须给PRACK返回一个481响应。

如果PRACK匹配一个未确认可靠临时响应，那么它必须回复一个2xx响应。

UAS 可
以通过这点来取人临时响应已被有序接收。

它应当停止可靠临时响应的重传，并且必须将它从未确认临时响应列表中去掉。

如果一个可靠临时响应重传了64×T1秒仍未接收到匹配的PRACK，UAS应当用5xx响应拒绝初始请求。

如PRACK包含一个会话描述，它将如5章节中所描述的进行处理。

如果PRACk包含其他类型的消息体，这个消息体会按ACK中的消息体的方式进行处理。

在请求的第一个可靠临时响应被确认后，UAS可能会发送额外的可靠临时响应。

UAS必须在在第一个被确认后才能发送第二个可靠临时响应。

第一个可靠临时响应会有特别的处理因为它负责传递初始序列号。

如果额外的可靠在第一个被确认之前发送，UAS不能确定他们是否被顺序收到。

接下来的针对相同请求的每个可靠临时响应中Rseq的值必须精确地进行加一操作。

Rseq序号不允许循环。

因为初始第一个选择小于2**31 - 1，但是最大地值是2**32 - 1，每个请求可以有超过2**31个临时可靠响应，这个值绰绰有余。

UAS可能在收到所有未确认可靠临时响应地PRACK之前发送对于这个请求的最终响应，除非最终响应是2xx并且所有的未确认可靠临时响应都包含一个会话描述。

在这种情况下，它必须在所有临时响应都被确认后才能发送最终响应。

如果UAS在所有可靠响应仍未确认前发送最终响应，那么它不应当继续重传未确认可靠临时响应，但是它必须准备处理针对于
这些响应的PRACK请求。

UAS在发送了一个对于请求的最终响应后不允许再发送新的可靠临时响应（与未确认响应的的重传相对立）。

4.UAC行为
当UAC建立了一个新的请求，它可以坚持对该请求进行临时响应的可靠传送。

为了实现该能力，它在请求中插入了一个带100rel可选标签的Require头字段。

带100rel可选标签的Require头字段只能在INVITE请求中使用，尽管SIP的扩展可能允许其他的请求方法使用它。

Header field where PRACK
Accept R o Accept 2xx - Accept 415 c Accept-Encoding R o Accept-Encoding 2xx - Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx - Accept-Language 415 c Alert-Info R - Alert-Info 180 - Allow R o Allow 2xx o Allow r o Allow 405 m Authentication-Info 2xx o Authorization R o
Call-ID c m Call-Info - Contact R - Contact 1xx - Contact 2xx - Contact 3xx o Contact 485 o Content-Disposition o Content-Encoding o Content-Language o Content-Length t Content-Type * CSeq c m Date o Error-Info 300-699 o Expires - From c m
In-Reply-To R -
Max-Forwards R m Min-Expires 423 - MIME-Version o Organization - Table 1: Summary of header fields, A--O
Header field where PRACK
Priority R -
Proxy-Authenticate 407 m
Proxy-Authenticate 401 o
Proxy-Authorization R o
Proxy-Require R o
Record-Route R o
Record-Route 2xx,18x o
Reply-To -
Require c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R c
Server r o
Subject R -
Supported R o
Supported 2xx o
Timestamp o
To c m
Unsupported 420 m
User-Agent o
Via c m
Warning r o
WWW-Authenticate 401 m
Table 2: Summary of header fields, P--Z
如果UAC不一定要求使用可靠临时响应，但只是表明如果UAS需要发送那么它会支持，带100rel 可选标签的Supported头字段必须出现在请求当中。

UAC应该在所有的INVITE请求中加入该字段。

如果收到了一个初始请求的临时响应，并且响应包含带100rel可选标签的Require头字段，那么响应会被可靠地传送。

如果响应是一个100（trying）（非101～199），那么这个可选标签必须忽略，如下的过程将不会用到。

如果对话还没建立那么临时响应必须建立一个对话。

假设响应被可靠地传输，UAC必须建立一个PRACK的新请求，这个请求与之前的临时响应是处于同一对话中的。

（事实上，这个临时响应可能已经建立了这个对话）。

PRACK请求可能包含消息体，根据他们的类型和部署来说明该消息体。

请注意PRACK就如对话中其他的非INVITE请求。

特殊的是，一个UAC在它收到已确认的临时响应的重传是不会重传PRACK请求，尽管这样做不会产生一个协议错误。

一旦收到一个可靠的临时响应，对应该响应的重传必须遗弃。

当它的会话ID，Cseq和Rseq和原始的响应匹配时我们认为这个响应是个重传。

UAC必须包含一个序列号来表明最近接收到的针对初始请求的顺序可靠临时响应。

这个序列号将一直维持直到接收到初始请求的最终响应。

它的值必须用对初始请求的第一个可靠临时响应中Rseq头字段值来进行初始化。

处理对于同一个初始请求的后续可靠临时响应遵循以上的规则，区别在于：可靠临时响应保证是顺序的。

结果是,如果UAC接收到同一另外一个可靠临时响应，并且它的Rseq值不比前一个序列号
的值高（大），那么该响应不能够用PRACK来确认。

目前的实现是可能是抛弃这个响应，或者缓存该响应以期收到丢失的响应。

UAC在最终响应后可能确认接收到的可靠临时响应也可能丢弃。

5.Offer/Answer模型和PRACK
3261描述了在哪些消息中可以出现请求和应答。

基于那些模型，本扩展提供了offer和answer 模型的新交互方式。

如果INVITE包含一个offer，那么UAS可能在一个可靠临时响应中产生一个answer（假设UAC 支持这些方法）。

那么导致在完成这个电话之前就已经建立一个会话。

类似的，如果一个可靠临时响应是第一个发回给UAC的可靠消息，并且INVITE不带有offer，那么offer 必须在那个可靠临时响应中出现。

如果UAC接收到一个可靠临时响应带了offer（发生在当UAC发送了一个不带offer的INVITE 情况下，这导致第一个可靠临时响应将包含offer），它必须在PRACK中生成一个answer。

如果UAC 接收到了一个带有answer的可靠临时响应，它将可能在PRACK中生成一个附加的offer。

如果UAS 收到带offer的PRACK，它必须在PRACK对应的2xx中携带answer。

一旦收到或者发出一个answer，UA应当根据offer和answer中的参数来建立会话，就算初始的INVITE还没有被响应。

如果UAS将一个会话描述放在了任何一个当INVITE接收时还没有被确认的可靠临时响应中时，UAS必须延迟发送2xx直到该临时响应被确认。

否则，1xx响应的可靠性没有办法得到保证，在offer 和answer交互的正常操作中需要可靠性保证。

所有支持这个扩展的用户代理必须支持3261中13.2章节所描述的offer/answer交互的所有可能的规则。

如基于INVITE和PRACK作为请求，2xx和可靠的1XX作为非失败的可靠响应。

6.PRACK方法的定义
本说明定义了一个新的SIP方法，PRACK。

语意如上表述。

表1，2是从3261的表2和3中针对这个新方法扩展出来的。

7.头字段定义
本说明定义了两个新的头字段，RAck和RSeq。

表3是从3261的表2和3中针对这俩个新头字段扩展出来的。

7.1 RSeq
Rseq头字段是用于临时响应的可靠传输。

它包含一个单一数值：1到2**32 -1.关于它的用途请参照第三章。

例：RSeq：988789
Header field where proxy ACK BYE CAN INV OPT REG PRA
______________________________________________________
RAck R - - - - - - m
RSeq 1xx - - - o - - -
Table 3: RAck and RSeq Header Fields
7.2 RAck
RAck头字段在PRACK请求中发送以支持临时响应的可靠性。

它包含两个数字和一个方法标签。

第一个数字是从被确认的临时响应中的RSeq头字段中获得的。

第二个数字和方法是从被确认的响应中的CSeq中获取的。

RAck头字段中的方法名是区分大小写的。

例：RAck：776656 1 INVITE
8 IANA事项
本文档注册一个新的选择标记和两个新的头，建立在RFC 3261 IANA的注册过程
8.1本说明注册了一个单一的可选标签100rel。

作为注册所必需的消息，如RFC 3261指定是：
Name: 100rel
描述：本可选标签是为了保证临时响应的可靠传输。

当它出现在Supported头字段的时候，表明UA可以发送或接收可靠临时响应，当出现在请求的Require头字段时，表明UAS必须可靠地发送所有地临时响应。

当出现在一个可靠临时响应的Require头字段时，表明该响应将被可靠地传输。

8.2 IANA负责RSeq和RAck头的注册
以下是RSeq头字段的注册：
RFC Number: RFC3262
Header Name: RSeq
Compact Form: none
以下是Rack头字段的注册：
RFC Number: RFC3262
Header Name: RSeq
Compact Form: none
9 安全注意事项
攻击者可以注入PRACK请求来强迫可靠临时响应停止重传。

因为这些响应可以传达重要的信息，PRACK消息应该可以像其他的请求那样接收认证。

认证过程定义参见3261。

10 收集的BNF
给Rack和Rseq头字段和PRACK方法的BNF在这里被定义
RACKm = %x50.52.41.43.4B ; PRACK in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm / PRACKm
/ extension-method
RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method response-num = 1*DIGIT
CSeq-num = 1*DIGIT
RSeq = "RSeq" HCOLON response-num。