绝大多数人看IMS呼叫流程时，都容易自动忽略PRACK消息，原因是：

1) 大部分情况下，这条消息对理解呼叫流程影响不大。

2) 无法从字面看出PRACK是谁的缩写，而除了协议外，又很少有人讲PRACK，一般人又不喜欢看SIP协议，因为RFC协议属于INTERNET体系，其排版风格跟3GPP协议文档完全不一样，可读性对通信从业人员来说比较“差”，对于未知的东西，鸵鸟策略当然是“最佳”策略了。

但是有时候出问题，就是在那些非“大部分的情况下”，因此了解PRACK还是很有必要。

SIP提供两类响应消息(Response): 临时的(Provisional)和最终的(Final).

    - 最终响应消息(Final Responses, 后面简称FR)用于传达请求(比如INVITE请求)处理的结果。FR的发送过程是可靠的，也就是说FR发送出去后，要求收到确认结果(ACK). FR的一个例子是响应INVITE请求的200 OK消息。

    - 临时响应消息(Provisional Responses，后面简称PR)用于提供请求处理过程中的信息，PR的一个例子是我们熟知的180 Ringing.

在SIP主体协议RFC-3261里只要求对FR进行可靠传输，也就是要求发送出去后收到ACK，而对PR不要求可靠传输。

后来发现对于一些临时响应来说，其传输可靠性也很重要，比如180 Ringing对于决定呼叫状态(call state)非常关键，这就需要临时响应发出去后也能收到确认结果(ACK), 因此IETF专门针对这一点在SIP协议RFC-3261外进行了扩展，生成了一个新的协议：

这样就引出了本文的主人公– PRACK.

PRACK是对PR的ACK(确认收到)消息。用于PR的可靠传输，也就是，发出的PR消息要求收到PRACK，否则PR消息将被重传。

这种发出的响应消息(Response)要求ACK的机制叫做可靠性机制- Reliability Mechanism.

1)如何开启PR的可靠性传输机制

也就是，什么情况下，UAC(User Agent Client)收到UAS(User Agent Server)的PR后需要回复PRACK呢？协议规定，如果UAC发送请求(比如Invite Request)的时候携带了Supported header  field: 100rel, 那么UAS回复的PR就要求UAC回复PRACK(UAC和UAS的概念会有专门笔记讲解，现在可以简单理解为客户端(请求端)和服务端).

//RFC 3262 - 3 UAS Behavior

A UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) contained a Supported header field with the option tag 100rel.

2) Backoff机制

PR的可靠性机制和FinalResponse类似，在设定的定时器超时后如果未收到PRACK，就会重传PR，直到收到PRACK, 请看协议描述：

//RFC3262 – 1 Introduction

The reliability mechanism works by mirroring the current reliability mechanisms for 2xx final responses to INVITE. Those requests are transmitted periodically by the Transaction User (TU) until a separate transaction, ACK, is received that indicates reception of the 2xx by the UAC.  The reliability for the 2xx responses to INVITE and ACK messages are end-to-end.  In order to achieve reliability for provisional responses, we do nearly the same thing.  Reliable provisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message isreceived.  The PRACK request plays the same role as ACK, but fo provisional responses.

3) 端到端的PR可靠性机制

PR可靠性机制只用于端到端(end-to-end)，因此PRACK不能应用于“100 Trying ”，因为100 Trying是hop-to-hop消息，只有101～199 PR需要可靠传送，101～199 Provisional Response是end-to-end消息。

//RFC 3262 - 3 UAS Behavior

A UAS MUST NOT attempt to send a 100 (Trying) response reliably. Only provisional responses numbered 101 to 199 may be sent reliably. If the request did not include either a Supported or Require header field indicating this feature, the UAS MUST NOT send the provisional response reliably.

    100 (Trying) responses are hop-by-hop only.  For this reason, the reliability mechanisms described here, which are end-to-end, cannot be used.

各个关键字段的描述见右边文字，同颜色表示与左边流程图里消息里携带关键字段对应：

我们来看一个消息log例子(log中关键字段/参数/数字颜色与上面描述中提到的对应)：

---------- clip-----------

//手机接收到对端发过来的RINGING，该消息里携带Rseq

SIP Call ID=1482489267_2360040920@2409:8809:8530:857d:c575:f266:2aa0:dc24

SipMessage = SIP/2.0 180 Ringing

Via: SIP/2.0/TCP[2409:8809:8530:857D:C575:F266:2AA0:DC24]:8904;branch=z9hG4bK1019613377

Record-Route:

Call-ID:1482489267_2360040920@2409:8809:8530:857d:c575:f266:2aa0:dc24

From:;tag=1482489276

To:;tag=55116ypd

CSeq:408747442INVITE

Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,NOTIFY,MESSAGE,REFER,UPDATE

Contact:

Require:100rel

RSeq: 2

P-Early-Media: sendonly

P-Access-Network-Info: 3GPP-E-UTRAN;utran-cell-id-3gpp=46000286633BFE84;sbc-domain=sbc04.0755.gd.chinamobile.com;ue-ip=[2409:8809:8530:857D:C575:F266:2AA0:DC24];ue-port=8005;network-provided

Content-Length: 0

 //手机回复PRACK消息

SIP Call ID =1482489267_2360040920@2409:8809:8530:857d:c575:f266:2aa0:dc24

Sip Message = PRACK

sip[2409:8019:8430:4500:0000:0000:0000:0008]:9900;Hpt=8f62_16;CxtId=3;TRC=ffffffff-ffffffffSIP/2.0

i:1482489267_2360040920@2409:8809:8530:857d:c575:f266:2aa0:dc24

f:;tag=1482489276

t:;tag=55116ypd

CSeq:408747444PRACK

P-Access-Network-Info:3GPP-E-UTRAN-TDD;utran-cell-id-3gpp=46000286633BFE84

l: 0

v:SIP/2.0/TCP[2409:8809:8530:857d:c575:f266:2aa0:dc24]:8904;branch=z9hG4bK3379790848

Max-Forwards: 70

Security-Verify:ipsec-3gpp;alg=hmac-md5-96;prot=esp;mod=trans;ealg=null;spi-c=2643107290;spi-s=3412854899;port-c=9950;port-s=9900

RAck: 2 408747442 INVITE

Route:

Proxy-Require: sec-agree

Require: sec-agree

k: timer

---------- clip-----------

笔者在公众号“协议工程师笔记”定期发布5G/LTE/IMS...学习笔记, 敬请关注、订阅和分享，谢谢！

                                                                      一起努力，蒸蒸日上