绝大多数人看IMS呼叫流程时,都容易自动忽略PRACK消息,原因是:
1) 大部分情况下,这条消息对理解呼叫流程影响不大。
2) 无法从字面看出PRACK是谁的缩写,而除了协议外,又很少有人讲PRACK,一般人又不喜欢看SIP协议,因为RFC协议属于INTERNET体系,其排版风格跟3GPP协议文档完全不一样,可读性对通信从业人员来说比较“差”,对于未知的东西,鸵鸟策略当然是“最佳”策略了。
但是有时候出问题,就是在那些非“大部分的情况下”,因此了解PRACK还是很有必要。
1. 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外进行了扩展,生成了一个新的协议:
<RFC 3262- Reliability of Provisional Responses in the Session Initiation Protocol (SIP)>
这样就引出了本文的主人公– PRACK.
PRACK是对PR的ACK(确认收到)消息。用于PR的可靠传输,也就是,发出的PR消息要求收到PRACK,否则PR消息将被重传。
这种发出的响应消息(Response)要求ACK的机制叫做可靠性机制- Reliability Mechanism.
2. PR传输的可靠性机制
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.
3. PR/PRACK关键字段/头域(HeaderField)
各个关键字段的描述见右边文字,同颜色表示与左边流程图里消息里携带关键字段对应:
4. 一个实例
我们来看一个消息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:<sip:[2409:8019:8430:4500:0000:0000:0000:0008]:9900;transport=tcp;lr;Hpt=8f62_116;CxtId=3;TRC=ffffffff-ffffffff;X-HwB2bUaCookie=14559>
Call-ID:1482489267_2360040920@2409:8809:8530:857d:c575:f266:2aa0:dc24
From:<sip:+8613603049709@gd.ims.mnc000.mcc460.3gppnetwork.org>;tag=1482489276
To:<tel:15723177335;phone-context=ims.mnc000.mcc460.3gppnetwork.org>;tag=55116ypd
CSeq:408747442INVITE
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,NOTIFY,MESSAGE,REFER,UPDATE
Contact:<sip:[2409:8019:8430:4500:0000:0000:0000:0008]:9900;Hpt=8f62_16;CxtId=3;TRC=ffffffff-ffffffff>
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:<sip:+8613603049709@gd.ims.mnc000.mcc460.3gppnetwork.org>;tag=1482489276
t:<tel:15723177335;phone-context=ims.mnc000.mcc460.3gppnetwork.org>;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:<sip:[2409:8019:8430:4500:0000:0000:0000:0008]:9900;transport=tcp;lr;Hpt=8f62_116;CxtId=3;TRC=ffffffff-ffffffff;X-HwB2bUaCookie=14559>
Proxy-Require: sec-agree
Require: sec-agree
k: timer
---------- clip-----------
笔者在公众号“协议工程师笔记”定期发布5G/LTE/IMS...学习笔记, 敬请关注、订阅和分享,谢谢!
一起努力,蒸蒸日上