PRACK简介分析和总结.docx

100rel扩展即是对中间状态响应的确认（即1xx的响应码）。原先在sip里，只有针对invite请求的200ok响应才会有ack，那么当中间状态响应携带重要的会话参数信息时，例如183响应，客户端是否收到响应就没有ack请求了，于是就定义了prack这一请求消息，即对中间状态响应的确认请求。当sip发送者支持这一扩展时，及在support头域增加这个100rel消息，当server端给与1xx响应时，可以在头域里的require字段要求这一100rel的能力。此时，sip发送者，发送prack消息。

PRACK用于保证1**（除100外）的可靠传输，如果1**响应中的的Require头部中带有100rel这个参数，那么client端收到这个1**后，就需要发PRACK保证这个1**的可靠传输，当server端收到PRACK后，说对端已经收到了这个1**,此时server需要回PRACK的200响应。

按照RFC3261,,如果请求中有100rel标志,UAS必须用可靠传输的方式发送非100的临时响应(101-199),如果UAS不愿意这样做,它必须利用420(BadExtension)拒掉这个请求.

假设UAC接收到需要可靠传输的非100临时响应后（101－199）,它必须用PRACK方法创建一新请求发送给UAS，以确认已收到此响应,UAS会回应一200OK。

有的流程有PRACK，说明它有100rel的支持，没有PRACK说明不支持100rel。

UAC发起的INVITE中含有Supported:100rel,而UAS也支持该扩展并且在183响应中有Require:100rel，说明接下来会话中，对所有100以外的1xx响应，均要有PRACK回应。

uac如果不支持100rel，但uas要求支持100rel（Require:100rel），uac发送CANCEL，切断会话。

uac如果不支持100rel，但uas也不支持或不要求支持100rel，只是在后面的过程中，uac

对应接收到的临时响应，如180，183等，不需要发送prack回应而已，与是否会出现183

没有关系。

100rel是一个任选标记，如果INVITE请求的Supported头域中包含该标记，说明发送请求的UAC支持PRACK扩展。

了解PRACK

概述

SIP定义了两种应答：临时（provisional)和最终（final）。

最终应答传送的是请求处理的结果，是可靠性的（reliably）。而临时应答传送的是处理过程的信息，由RFC3261是非可靠的。

但是由现在的情况看来，特别是与PSTN交互过程中发现：临时应答也应该是可靠的。

RFC3262定义了一种SIP可选的扩展方法——PRACK（provisionalack），用于支持临时应答的可靠性。它的实现机制如下：

借鉴了INVITE请求的2**应答的可靠性机制：通过构造新的事务来重发ACK来确认接收到了2**应答，这种可靠性是端点到端点（end-to-end）的。对于1**（除100外）的应答，使用PRACK来终止该应答的重发。PRACK是对临时应答而言，不同于ACK，是一种跟BYE一样的正常SIP消息。所以它的可靠性是点到点（hop-by-hop）的，且具有应答。

每个临时响应都有一个顺序号，在于RSeq头域中。而PRACK消息包括了RAck头域，指示回应的临时相应的顺序号，且不具有积累效果。

UAS行为

如果请求INVITE的头域Supported中包括选项100rel，UAS可能发送可靠性临时响应；如果请求INVITE的头域Require中包括选项100rel，UAS必须发送可靠性临时响应，否则发送420(BadExtension)且Unsupported头域中包括选项100rel。

但是，如果请求中不满足以上任一情况，则不能支持可靠临时相应。

UAS需要发送可靠临时相应原因：

多种原因。其中之一为根据RFC3261,如果UAS需要一段时间来处理请求，UAS需要发送临时相应消息给Proxies来“延时（extention）”，因为Proxy一般只保留请求上下文3分钟，所以为了避免丢失消息，常需要1分钟重发一次。而使用可靠临时相应只需2分半钟

重发一次。

可靠临时响应的构建：

只需在RFC3261的基础上进行一些补充：