PRACK简介.docVIP

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(Bad Extension)拒掉这个请求.假设UAC接收到需要可靠传输的非100临时响应后（101－199）,它必须用PRACK方法创建一新请求发送给UAS，以确认已收到此响应,UAS会回应一200OK。有的流程有PRACK，说明它有100rel的支持，没有PRACK说明不支持100rel。 UAC发起的INVITE中含有Supported: 100 rel,而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扩展。 SIP 中临时响应的可靠性本文档定义了SIP中提供可靠临时响应消息的一个扩展方法。该扩展使用一个可选的标签100rel且定义了临时响应告知（PRACK）方法。RFC3261使用请求－响应协议来开始并管理通信会话。SIP定义了两种响应：临时响应和最终响应。最终响应传输请求处理的结果，并使用可靠传输方式。临时响应告知正在处理请求，在3261中不是可靠传输的。后来在某些情况下发现可靠性非常重要，包括与PSTN交互的场景。因此，一个可选的能力需要用来支持临时响应的可靠传输。该可靠性机制模仿目前对INVITE请求的2xx最终响应的可靠性机制。这些请求定期地由TU（事务用户）传输直到一个单独的事务，收到一个ACK表示接受到了由UAC发出的2XX响应。对于INVITE的2XX响应和ACK消息是端到端的可靠传输。为了达到临时响应的可靠性，我们使用类似的方法。可靠临时响应由TU使用指数backoff方式进行重传。这些重传在收到PRACK后结束。PRACK请求扮演了和ACK同样的角色，只不过是对应临时响应。这是一个很重要的区别。PRACK是一个普通的SIP消息，就像BYE那样。因此，它的可靠性通过每个有状态代理服务器来保证“HOP－BY－HOP”（跳至跳）的可靠性。和BYE一样，不同于ACK,PRACK有自己的响应。每个临时响应都有一个序列号（sequence number）, 携带在响应的RSeq头字段。PRACK包含一个RAck头字段，表明了它所确认的临时响应的序列号。该确认不是累积的，本说明建议一次只发一个明显临时响应，以控制拥塞。3 UAS 行为当初始INVITE包含一个支持（Supported）头字段带有可选标签100rel。UAS可能发送任何非100临时响应来可靠地回应INVITE，本说明不允许除对应INVITE之外的临时可靠响应，扩展定义了新的方法来建立对话可能会使用这种机制。当初始INVITE包换一个必须（Required）头字段带有可选标签100rel。如果UAS不愿意接受，它必须使用420（错误的扩展）携带不支持的带有可选标签100Rel的头字段拒绝初始请求。UAS不允许对100临时响应进行可靠传输。只有101到199可以可靠传输。如果请求既没有Supported或Require头字段来表明这个特性，UAS不允许可靠地发送临时响应100Trying响应只能逐跳传输。因为这个原因，