了解PRACK

了解PRACK


概述
SIP定义了两种应答:临时(provisional)和最终(final)。
最终应答传送的是请求处理的结果,是可靠性的(reliably)。而临时应答传送的是处理过程的信息,由RFC3261是非可靠的。
但是由现在的情况看来,特别是与PSTN交互过程中发现:临时应答也应该是可靠的。

RFC3262定义了一种SIP可选的扩展方法――PRACK(provisional ack),用于支持临时应答的可靠性。它的实现机制如下:
借鉴了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 (Bad Extension)且Unsupported头域中包括选项100rel。
但是,如果请求中不满足以上任一情况,则不能支持可靠临时相应。

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

可靠临时响应的构建:
只需在RFC3261的基础上进行一些补充:必须包括Require头域(包括100rel选项)和RSeq头域(值为1到2**32-1,是对话中是唯一的)。

PRACK和临时响应的匹配:
PRACK首先必须和临时相应在同一个对话之中,RAck中的方法、CSeq-num和response-num分别对应于临时响应CSeq中的方法、CSeq中的序号和RSeq的序号。

如果接受到的PRACK无法找到相匹配的临时相应,则回应481;否则回应2**,并停止该临时相应的重发。
如果在64*T1时间内没有接收到PRACK,则UAS回应5**。
在第一个可靠响应得到回应,才可以发送第二个可靠相应。对于同一个请求,第二个可靠相应的RSeq比第一个大1。

UAS可以在可靠临时响应未收到PRACK情况下发送最终应答,除了以下情况:最终响应为2**且其中一个临时相应中有媒体描述。如果最终响应已经发送,则临时相应的重发和新的临时消息发送都不能进行。


UAC行为
如果需要可靠临时应答,则在INVITE请求的Require头域中包含100rel选项,而其他方法中的Require中不能包含该选项;如果将可靠临时应答的需求的决定权交给UAS,则应在INVITE的头域Supported中包含100rel选项。
当头域Require中包含100rel的临时消息到来时,且临时消息非100,说明临时消息是可靠的。UAC接下来在对话中建立PRACK请求,跟其它在对话中建立的非INVITE请求一样,UAC不应在接收到重发的可靠临时应答时重发PRACK,即使重发不会引起协议错误。

一个临时应答到来时,如果dialog ID、CSeq、和RSeq跟之前的一样时,该应答视为重发,该应答必须被丢弃。所以,UAC需要记录RSeq值直到最终应答的到来。
如果新的一个临时应答到来时,需要判断RSeq是否比之前的值大。如果不是的话,则不能回应PRACK,可以丢弃该临时应答或缓存起来以等待没有到来的老的临时应答。

如果在最终应答到来之后收到临时应答,可以回应或直接丢弃。


Offer/Answer模型和PRACK方法
(详见RFC3262或之后的关于Offer/Answer的文章)


1)RFC3262中不支持除INVITE外其它方法的可靠性临时响应,除非是能建立对话的扩展方法。
2)UAS不能发送可靠的100临时相应。因为100响应一般是hop-by-hop的,即消息的可靠性在于hop的两端之间,而不在于端到端之间;而这里实现的可靠性是端到端之间的,即接受消息初始发送和最终接受方,能满足消息真正交互成功。但是PRACK的可靠性又是hop-by-hop的,即PRACK方法的消息交互依靠的是hop之间的确认。


参考


你可能感兴趣的:(信息,可靠性)