Acronym

PRACK-- Provisional Response ACKnowledgement method

PRACK

SIP defines two types of responses, provisional and final. Final responses convey the result of the request processing,
and are sent reliably.  Provisional responses provide information on the progress of the request processing, but are not sent reliably in RFC3261.

Provisional responses indicate that the server contacted is performing some further action and does not yet have a
definitive response. A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response. They never cause the client to send an ACK.

But in several cases reliability of provisional responses are important, including interoperability scenarios with
the PSTN. There are several reasons why a UAS might want to send a reliable provisional response. 
One reason is if the INVITE transaction will take some time to generate a final response. 
An INVITE transaction can go on for extended durations when the user is placed on hold, or when interworking with PSTN systems which allow communications to take place without answering the call. The latter is common in Interactive Voice Response (IVR)
systems. The requirement is that a proxy receive them every three minutes, but the UAS needs to send them more frequently (once a minute is recommended) because of the possibility of packet loss. 
As a more efficient alternative, the UAS can send the response reliably, in which case the UAS SHOULD send provisional responses once every two and a half minutes. 
Use of reliable provisional responses for extending transactions is RECOMMENDED.

Therefore, PRACK method was introduced to support reliable transmission of provisional responses. 

When the UAC creates a new request, it can insist on reliable delivery of provisional responses for that
request.  To do that, it inserts a Require header field with the option tag 100rel into the request. 

If the UAC does not wish to insist on usage of reliable provisional responses, but merely indicate that
it supports them if the UAS needs  to send one, a Supported header MUST be included in the request with 
the option tag 100rel. 

PRACK does not be used on 100 responses, because 100 is a hop-to-hop response, and PRACK is for achieving end-to-end
reliability.

PRACK will start a new transaction on the same dialog with the 1xx response, i.e. same dialog ID with the response
but different transaction ID.

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.

The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require
header field with the option tag 100rel.  

The provisional response to be sent reliably MUST contain a Require header field containing the option
tag 100rel, and MUST include an RSeq header field. 

The RAck header is sent in a PRACK request to support reliability of provisional responses. 
It contains two numbers and a method tag. The first number is the value from the RSeq header in the provisional response that is being acknowledged. 
The next number, and the method, are copied from the CSeq in the response that is being acknowledged.

INFO

The SIP protocol defines session control messages used during the setup and tear down stages of a SIP controlled session.

In addition, the SIP re-INVITE can be used during a session to change  
the characteristics of the session.  This is generally to change the  
properties of media flows related to the session or to update the SIP  
session timer.

However, there is no general-purpose mechanism to carry session  
control information along the SIP signaling path during the session.

The purpose of the INFO message is to carry application level  
information along the SIP signaling path.

From the definition of INFO method, it is used during a session, i.e. after a dialog is established. However I do
find in a case which INFO is used withoug a dialog. The UAS just receives an INFO and sends 200OK. Its behavior is like a proxy.

Cseq

A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number
MUST be expressible as a 32-bit unsigned integer. The CSeq header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header
fields are considered equal if the sequence number and the request method are identical.

VIA

The Via header field indicates the path taken by the request so far and indicates the path that should be followed
in routing responses. The branch ID parameter in the Via header field values serves as a transaction identifier, and is used by proxies to detect loops. the value of the branch parameter MUST start with the magic cookie “z9hG4bK”.

Reference

[1]RFC3261-- SIP: Session Initiation Protocol

[2]RFC3262-- Reliability of Provisional Responses in the Session Initiation Protocol

[3] RFC2976-- The SIP INFO Method