Sip-learn about prack

Overview
SIP defines two types of responses: temporary (Provisional) and final (final ).
The final response transmits the request processing result, which is reliable ). The temporary response transmits the information of the processing process, which is unreliable by rfc3261.
However, from the current situation, especially during the interaction with the PSTN, it is found that temporary responses should also be reliable.

Rfc3262 defines an optional Extension Method for SIP-prack (provisional ACK) to support the reliability of temporary responses. Its implementation mechanism is as follows:
The reliability mechanism of the 2 ** response in the invite request is used for reference: The Ack is reissued by constructing a new transaction to confirm that 2 ** responses are received, this reliability is from the endpoint to the endpoint (end-to-end. For a 1 ** response (except 100), use prack to terminate the resend of the response. Compared with Ack, prack is a normal SIP message similar to bye. Therefore, its reliability is hop-by-hop and has a response.

Each temporary response has a sequence number in the rseq header domain. The prack message includes the rack header field, indicating the temporary sequence number of the response, and does not have the accumulation effect.


UAS Behavior
If the request invite's header field supported contains option 100rel, UAS may send a reliability temporary response; if the request invite's header field require contains option 100rel, UAS must send a reliability temporary response, otherwise, 420 (Bad extension) is sent and the unsupported header domain contains the option 100rel.
However, if the request does not meet any of the above conditions, it cannot support reliable temporary response.

UAS needs to send reliable temporary reasons:
Multiple reasons. One of them is based on rfc3261. If UAS needs to process the request for a period of time, UAS needs to send a temporary message to proxies to "extention )", because the proxy only keeps the request context for three minutes, it usually takes one minute to resend the message to avoid message loss. The use of reliable temporary response only requires 2 minutes and a half again.

Reliable temporary response construction:
You only need to add some supplements based on rfc3261: The require header field (including the 100rel option) and rseq header field (values: 1 to 2 ** 32-1, is unique in the dialog ).

Matching of prack and temporary response:
Prack must first be in the same dialog as the temporary one. Methods, CSeq-num, and response-num in rack correspond to methods in the temporary response CSeq, sequence numbers in CSeq, and rseq numbers respectively.

If the received prack cannot find a matched temporary response, the system responds to 481. Otherwise, the system responds to 2 ** and stops the temporary resend.
If prack is not received within 64 * T1, UAS responds to 5 **.
Only when the first reliable response is responded can the second reliable response be sent. For the same request, the second reliable rseq is 1 larger than the first one.

UAS can send a final response when a reliable temporary response does not receive a prack, except for the following situations: the final response is 2 ** and a temporary response contains a media description. If the final response has been sent, both the temporary resend and the new temporary message cannot be sent.


UAC Behavior
If a reliable temporary response is required, the rel option is included in the require header domain of the invite request, which cannot be included in require in other methods; if the decision on the demand for reliable temporary response is handed over to UAS, The 100rel option should be included in the invite header field supported.
When a temporary message containing 100 rel in the Request Header arrives, and the temporary message is not, it indicates that the temporary message is reliable. UAC then establishes a prack request in the conversation. Like other non-invite requests established in the conversation, UAC should not resend the prack when receiving a reliable temporary response, even if you resend the service, it will not cause a protocol error.

When a temporary response arrives, if the dialog ID, CSeq, and rseq are the same as the previous one, the response is considered as a resend, and the response must be discarded. Therefore, UAC needs to record the rseq value until the final response arrives.
If a new temporary response arrives, you need to determine whether rseq is greater than the previous value. If not, you cannot respond to prack. You can discard the temporary response or cache it to wait for the old temporary response that has not arrived.

If you receive a temporary response after the final response arrives, you can respond or discard it directly.


Offer/Answer Model and prack Method
(For details, see the article about offer/answer after rfc3262)

Note:
1) rfc3262 does not support temporary response to reliability of methods other than invite, unless it is an extension method that can establish a conversation.
2) UAS cannot send a reliable 100 temporary response. Because 100 of responses are generally hop-by-hop, that is, the reliability of messages lies in the relationship between the two ends of the hop, not between the end-to-end. The reliability achieved here is between the end-to-end, that is, the initial sender and the final receiver of the received message can successfully interact with the message. However, the reliability of the prack method is hop-by-hop, that is, the message interaction of the prack method depends on the confirmation between hops.


Reference:

Rfc3262

From http://blog.sina.com.cn/s/blog_4b839a1b010082xy.html

Also refer to http://wenku.baidu.com/view/5b291a620b1c59eef8c7b403.html