RFC 3262 Reliability of Provisional Responses Reliability of provisional responses is an optional capability to support reliable transmission of provisional responses in the case such as interoperability scenarios with the PSTN. The reliability mechanism works by mirroring the current reliability mechanisms for 2xx final responses to INVITE. Reliable provisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message is received. The PRACK request plays the same role as ACK, but for provisional responses. There is an important difference, however. PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by- hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. If this were not the case, the PRACK message could not traverse proxy servers compliant to RFC 2543 [4]. The PRACK messages contain an RAck header field, which indicates the sequence number of the provisional response that is being acknowledged. The acknowledgments are not cumulative, and the specifications recommend a single outstanding provisional response at a time, for purposes of congestion control. 1 UAS Behavior It is RECOMMENDED using reliable provisional responses for extending transactions. 1.1 100rel Option Tag In this specification INVITE is the only method which allow reliable provisional responses. But this mechanism could be used in other dialog creating method. A UAS MUST NOT attempt to send a 100 (Trying) response reliably. Because 100 response is hop-by-hop only, the reliability mechanisms described here, which are end-to-end, cannot be used. If the initial request contained a Require header field with the option tag 100rel, The UAS MUST send any non-100 provisional response 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. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include an Unsupported header field containing the option tag 100rel. 1.2 Proxy Behavior A proxy can also send reliable provisional responses. But it MUST NOT attempt to do so for any request that contains a tag in the To filed. (This implies that the proxy just forwards the message after the dialog has been established.) If the proxy receives a PRACK that does not match any outstanding reliable provisional response, the PRACK MUST be proxied. 1.3 Construction of Provisional Response The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. It MUST contain a Require header field with the option tag 100rel. It MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction. This means that provisional responses for different requests MAY use the same values for the RSeq number. The reliable provisional response MAY contain a body. The usage of session descriptions is described in Section 5. 1.4 Transmission of Provisional Response Transmit the first provisional response starts T1 timer, and doubles for each retransmission. The transaction layer will forward each retransmission passed from the UAS core. Retransmissions of ACK are triggered on receipt of a 2xx, but retransmissions of PRACK take place independently of reception of 1xx. Retransmissions of the reliable provisional response cease when a matching PRACK is received by the UA core. The UAS MUST NOT send a second reliable provisional response until the first is acknowledged. The first reliable provisional response receives special treatment because it conveys the initial sequence number. If additional reliable provisional responses were sent before the first was acknowledged, the UAS could not be certain these were received in order. The value of the RSeq in each subsequent reliable provisional response for the same request MUST be greater by exactly one. RSeq numbers MUST NOT wrap around. If there is any unacknowleged reliable provisional response contained a session description, the UAS MAY send a final response except 2xx. If the UAS wish to send the 2xx final response, it MUST wait for all the offer in reliable provisional response has been acknowleged. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliable provisional responses, but it MUST be prepared to process PRACK requests for those outstanding responses. A UAS MUST NOT send new reliable provisional responses (as opposed to retransmissions of unacknowledged ones) after sending a final response to a request. 1.5 Receiving a PRACK PRACK is like any other NON-INVITE request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261. Reliable Provisional Response PRACK ----------------------------- ----- sequence number - Rseq <-> response-num - RAck sequence number - Cseq <-> Cseq-num - RAck method - Cseq <-> method - RAck Table 1: A Matching PRACK and Reliable Provisional Response If PRACK does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response. If PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response. It SHOULD cease retransmissions of the reliable provisional response, and MUST remove it from the list of unacknowledged provisional responses. If a reliable provisional response is retransmitted for 64*T1 seconds without reception of a corresponding PRACK, the UAS SHOULD reject the original request with a 5xx response. 2 UAC Behavior 2.1 Initial Request If the UAC wish to insist on usage of reliable provisional response, a Require header with the value 100rel MUST be present in the initial 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. The UAC SHOULD include this in all INVITE requests. 2.2 Receiving Reliable Provisional Response If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. The UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition. A UAC SHOULD NOT retransmit the PRACK request when it receives a retransmission of the provisional response being acknowledged, although doing so does not create a protocol error. The UAC MUST check if the first and subsequent reliable provisional response is in correct order, by examining the RSeq value. If the UAC found the reliable provisional response is out of order, it MUST stop processing further. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing response. The UAC MAY acknowledge reliable provisional responses received after the final response or MAY discard them. 3 Offer/Answer Model and PRACK If the INVITE contained an offer, the UAS MAY generate an answer in a reliable provisional response (assuming these are supported by the UAC) If the INVITE did not contain an offer, the UAS MUST generate an offer in the first reliable provisional response if it is the first reliable message. If the UAC receives a reliable provisional response with an offer it MUST generate an answer in the PRACK. (This would occur if the UAC sent an INVITE without an offer) If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK. Once an answer has been sent or received, the UA SHOULD establish the session based on the parameters of the offer and answer, even if the original INVITE itself has not been responded to. If there is any unacknowledged reliable provisional response with a session description, the UAS MUST NOT sending the 2xx to INVITE until these response has been acknowledged. User agents MUST treat INVITE and PRACK as requests, and 2xx and reliable 1xx as non-failure reliable responses.