乱翻 之 RFC3262文档格式.docx

1、PRACK包含一个RAck头字段，表明了它所确认的临时响应的序列号。该确认不是累积的，本说明建议一次只发一个明显临时响应，以控制拥塞。3 UAS 行为当初始INVITE包含一个支持（Supported）头字段带有可选标签100rel。UAS可能发送任何非100临时响应来可靠地回应INVITE，本说明不允许除对应INVITE之外的临时可靠响应，扩展定义了新的方法来建立对话可能会使用这种机制。当初始INVITE包换一个必须（Required）头字段带有可选标签100rel。如果UAS不愿意接受，它必须使用420（错误的扩展）携带不支持的带有可选标签100Rel的头字段拒绝初始请求。UAS不允许对1

2、00临时响应进行可靠传输。只有101到199可以可靠传输。如果请求既没有Supported或Require头字段来表明这个特性，UAS不允许可靠地发送临时响应100Trying响应只能逐跳传输。因为这个原因，我们描述地端到端地可靠机制不能使用。？可以作为代理的成员（element）也能发送可靠的临时响应。这种情况下，它在这个事务中作为UAS。但是，它不能对带有一个标签的To头字段的任何请求做可靠临时响应。这意味着一个代理不能对对话中发送的请求生成可靠临时响应。不同于UAS，当代理成员（element）收到一个不匹配可靠临时响应的PRACK，该PRACK必须被代理。为什么UAS可能想发送一个可靠

3、的临时响应，有如下几个理由：第一，如果INVITE事务可能需要时间来产生最终响应。如3261中13.3.1.1章节谈论的，UAS将需要发送定期的临时响应来向代理请求一个事务的“扩展”。需求是一个代理会每隔3分钟收到请求，但是因为丢包地可能性UAS需要更频繁地发送请求（建议间隔一分钟）。作为一个更有效率的解决方案UAS可以可靠地发送响应。这样UAS应该每隔2.5分钟发送一个临时响应。在扩展事务中使用可靠临时响应是建议性地。剩余地讨论假设初始请求包换一个Supported或Require头字段列出100rel,并且有一个临时响应被可靠的传输。临时响应被可靠传输是有UAScore根据3261 8.2

4、.6章节的程序来构造的。另外，它必须包含Require头字段带有可选标签100rel和Rseq头字段。UAS可能发送任何非100临时响应来可靠地回应INVITE，事务中第一个可靠临时响应的头字段的值必须在1和2*311之间。建议从这个范围内均一地选择。Rseq编号空间用于一个单独地事务。这个意味着对于不同请求的临时响应可能使用相同的Rseq值。可靠临时响应可能包含一个包体。会话描述的用途在第五章介绍。可靠临时响应被定期地传输到事务层。间隔从T1妙开始，然后每隔双倍地时间重传一次（T1在3261中17章节定义）。一旦传输到服务层事务，它将被加到一个内部未确认可靠临时响应列表。事务层将转发每个从U

5、AScore中传过来的重传。这个和2xx响应的重传不同，2xx的间隔时间是T2秒。这是因为ACK的重传是由一个2xx接收来触发的，但PRACK的重传独立于1xx的接收。当从UACore中收到一个匹配的PRACK那么可靠临时响应的重传就结束。PRACK就像对话中的其他请求一样，UAScore 根据3261 的8.2 ，12.2.2 章节程序来处理。一个匹配的PRACK定义类似为在同一会话里的响应，它的方法，Cseqnum和 响应号在Rack头字段匹配，分别的对应于可靠临时响应的Cseq的方法，序列号和可靠临时响应中的Rseq中的序列号。如果UAcore收到一个PRACK请求不匹配任何未确认可靠临

6、时响应，UAS必须给PRACK返回一个481响应。如果PRACK匹配一个未确认可靠临时响应，那么它必须回复一个2xx响应。UAS可以通过这点来取人临时响应已被有序接收。它应当停止可靠临时响应的重传，并且必须将它从未确认临时响应列表中去掉。如果一个可靠临时响应重传了64T1秒仍未接收到匹配的PRACK，UAS应当用5xx响应拒绝初始请求。如PRACK包含一个会话描述，它将如5章节中所描述的进行处理。如果PRACk包含其他类型的消息体，这个消息体会按ACK中的消息体的方式进行处理。在请求的第一个可靠临时响应被确认后，UAS可能会发送额外的可靠临时响应。UAS必须在在第一个被确认后才能发送第二个可靠

7、临时响应。第一个可靠临时响应会有特别的处理因为它负责传递初始序列号。如果额外的可靠在第一个被确认之前发送，UAS不能确定他们是否被顺序收到。接下来的针对相同请求的每个可靠临时响应中Rseq的值必须精确地进行加一操作。Rseq序号不允许循环。因为初始第一个选择小于2*31 - 1，但是最大地值是2*32 - 1，每个请求可以有超过2*31个临时可靠响应，这个值绰绰有余。UAS可能在收到所有未确认可靠临时响应地PRACK之前发送对于这个请求的最终响应，除非最终响应是2xx并且所有的未确认可靠临时响应都包含一 个会话描述。在这种情况下，它必须在所有临时响应都被确认后才能发送最终响应。如果UAS在所有

8、可靠响应仍未确认前发送最终响应，那么它不应当继续重传未确认可靠临时响应，但是它必须准备处理针对于这些响应的PRACK请求。UAS在发送了一个对于请求的最终响应后不允许再发送新的可靠临时响应（与未确认响应的的重传相对立）。4.UAC 行为当UAC建立了一个新的请求，它可以坚持对该请求进行临时响应的可靠传送。为了实现该能力，它在请求中插入了一个带100rel可选标签的Require头字段。带100rel可选标签的Require头字段只能在INVITE请求中使用，尽管SIP的扩展可能允许其他的请求方法使用它。 Header field where PRACK _ Accept R o 2xx - 4

9、15 c Accept-Encoding Accept-Language Alert-Info 180 Allow r 405 m Authentication-Info Authorization Call-ID c Call-Info Contact 1xx 3xx 485 Content-Disposition Content-Encoding Content-Language Content-Length t Content-Type * CSeq Date Error-Info 300-699 Expires From In-Reply-To Max-Forwards Min-Exp

10、ires 423 MIME-Version Organization Table 1: Summary of header fields, A-O _ Priority Proxy-Authenticate 407 401 Proxy-Authorization Proxy-Require Record-Route 2xx,18x Reply-To Require Retry-After 404,413,480,486 500,503 600,603 Route Server Subject Supported Timestamp To Unsupported 420 User-Agent V

11、ia Warning WWW-Authenticate Table 2: Summary of header fields, P-Z如果UAC不一定要求使用可靠临时响应，但只是表明如果UAS需要发送那么它会支持，带100rel可选标签的Supported头字段必须出现在请求当中。UAC应该在所有的INVITE请求中加入该字段。如果收到了一个初始请求的临时响应，并且响应包含带100rel可选标签的Require头字段，那么响应会被可靠地传送。如果响应是一个100（trying）（非101199），那么这个可选标签必须忽略，如下的过程将不会用到。如果对话还没建立那么临时响应必须建立一个对话。假设响

12、应被可靠地传输，UAC必须建立一个PRACK的新请求。这个请求与之前的临时响应是处于同一对话中的。（事实上，这个临时响应可能已经建立了这个对话）。PRACK请求可能包含消息体，根据他们的类型和部署来说明该消息体。请注意PRACK就如对话中其他的非INVITE请求。特殊的是，一个UAC在它收到已确认的临时响应的重传是不会重传PRACK请求，尽管这样做不会产生一个协议错误。一旦收到一个可靠的临时响应，对应该响应的重传必须遗弃。当它的会话ID，Cseq和Rseq和原始的响应匹配时我们认为这个响应是个重传。UAC必须包含一个序列号来表明最近接收到的针对初始请求的顺序可靠临时响应。这个序列号将一直维持直

13、到接收到初始请求的最终响应。它的值必须用对初始请求的第一个可靠临时响应中Rseq头字段值来进行初始化。处理对于同一个初始请求的后续可靠临时响应遵循以上的规则，区别在于：可靠临时响应保证是顺序的。结果是,如果UAC接收到同一另外一个可靠临时响应，并且它的Rseq值不比前一个序列号的值高（大），那么该响应不能够用PRACK来确认。目前的实现是可能是抛弃这个响应，或者缓存该响应以期收到丢失的响应。UAC在最终响应后可能确认接收到的可靠临时响应也可能丢弃。5.Offer/Answer 模型和PRACK3261描述了在哪些消息中可以出现请求和应答。基于那些模型，本扩展提供了offer和answer模型的

14、新交互方式。如果INVITE包含一个offer，那么UAS可能在一个可靠临时响应中产生一个answer（假设UAC支持这些方法）。那么导致在完成这个电话之前就已经建立一个会话。类似的，如果一个可靠临时响应是第一个发回给UAC的可靠消息，并且INVITE不带有offer，那么offer必须在那个可靠临时响应中出现。如果UAC接收到一个可靠临时响应带了offer（发生在当UAC发送了一个不带offer的INVITE情况下，这导致第一个可靠临时响应将包含offer），它必须在PRACK中生成一个answer。如果UAC接收到了一个带有answer的可靠临时响应，它将可能在PRACK中生成一个附加的o

15、ffer。如果UAS收到带offer的PRACK，它必须在PRACK对应的2xx中携带answer。一旦收到或者发出一个answer，UA应当根据offer和answer中的参数来建立会话，就算初始的INVITE还没有被响应。如果UAS将一个会话描述放在了任何一个当INVITE接收时还没有被确认的可靠临时响应中时，UAS必须延迟发送2xx直到该临时响应被确认。否则，1xx响应的可靠性没有办法得到保证，在offer和answer交互的正常操作中需要可靠性保证。所有支持这个扩展的用户代理必须支持3261中13.2章节所描述的offer/answer交互的所有可能的规则。如基于INVITE和PRAC

16、K作为请求，2xx和可靠的1XX作为非失败的可靠响应。6. PRACK方法的定义本说明定义了一个新的SIP方法，PRACK。语意如上表述。表1，2是从3261的表2和3中针对这个新方法扩展出来的。7. 头字段定义本说明定义了两个新的头字段，RAck和RSeq。表3是从3261的表2和3中针对这俩个新头字段扩展出来的。7.1 RSeqRseq头字段是用于临时响应的可靠传输。它包含一个单一数值：1到2*32 -1.关于它的用途请参照第三章。例：RSeq：988789Header field proxy ACK BYE CAN INV OPT REG PRA _ RAck - RSeq o Tabl

17、e 3: RAck and RSeq Header Fields7.2 RAck RAck头字段在PRACK请求中发送以支持临时响应的可靠性。它包含两个数字和 一个方法标签。第一个数字是从被确认的临时响应中的RSeq头字段中获得的。 第二个数字和方法是从被确认的响应中的CSeq中获取的。RAck头字段中的方法 名是区分大小写的。 例： RAck：776656 1 INVITE8 IANA 考虑事项本说明注册了一个单一的可选标签100rel。100rel描述：本可选标签是为了保证临时响应的可靠传输。当它出现在Supported头字段的时候，表明UA可以发送或接收可靠临时响应，当出现在请求的Req

18、uire头字段时，表明UAS必须可靠地发送所有地临时响应。 当出现在一个可靠临时响应的Require头字段时，表明该响应将被可靠地传输。9 安全考虑攻击者可以注入PRACK请求来强迫可靠临时响应停止重传。因为这些响应可以传达重要的信息，PRACK消息应该可以像其他的请求那样接收认证。认证过程定义参见3261。10.收集的BNF RACKm = %x50.52.41.43.4B ; PRACK in caps Method INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / PRACKm / extension-method RAck HCOLON response-num LWS CSeq-num LWS Method response-num 1*DIGIT CSeq-numRSeq HCOLON response-num