Internet Engineering Task Force SIP WG Internet Draft J.Rosenberg,H.Schulzrinne draft-ietf-sip-100rel-04.txt dynamicsoft,Columbia U. September 19, 2001 Expires: March 2002 Reliability of Provisional Responses in SIP STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel. 1 Introduction The Session Initiation Protocol (SIP) [1] is a request-response protocol for initiating, maintaining, and terminating multimedia sessions. Each SIP request is followed by one or more provisional responses, followed by a one or more definitive responses. These provisional responses, also called informational responses, have status codes within the 100-199 range. They are most commonly used for responses to an INVITE request. They provide information on call progress, such as trying (100), alerting (180), queueing (182), and J.Rosenberg,H.Schulzrinne [Page 1]
Internet Draft 100 Reliability September 19, 2001 session progress (183). However, when run over UDP, SIP does not guarantee that these messages are delivered reliably, or in order. However, a number of applications require reliability and in-order delivery of provisional responses to INVITE. These include gateway applications, wireless phones, ACD servers, and call queueing systems. Generally, these applications make use of the provisional responses to drive state machinery. This is especially true for the 180 Ringing provisional response, which maps to the Q.931 ALERTING message. This document provides an extension to SIP for ensuring that provisional responses to all SIP requests can be delivered reliably end to end, independent of the underlying transport mechanism. The extension works for provisional responses for any method (excepting ACK, of course, which have no responses, and PRACK, defined here). The extension requires two new header fields, and one new method. The extension does not require support in proxies. The extension is indicated with the option tag 100rel. 2 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations. 3 Basic Overview The reliability mechanism works by mirroring the current reliability mechanisms for 200 class final responses to INVITE. As specified in RFC 2543, 200 class final responses to INVITE are retransmitted with an exponential backoff until an ACK is received, at which point, they stop. The reliability for the final responses and the ACK messages are end-to-end (that is, neither is retransmitted by intermediate proxies). In order to achieve reliability for provisional responses, we do nearly the same thing. Provisional responses are retransmitted with an exponential backoff. Those retransmisions 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. Provisional responses, like 200 class responses, are forwarded end-to-end without local retransmissions in proxies. However, unlike ACK, which is end-to-end, PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by-hop through each stateful proxy. Similarly, PRACK has its own response. If this were not the case, the PRACK message could not traverse existing proxy servers. J.Rosenberg,H.Schulzrinne [Page 2]
Internet Draft 100 Reliability September 19, 2001 Each provisional response is given a sequence number, carried in a new header, RSeq, in the response. The PRACK messages contain an RAck header, which indicates the sequence number of the provisional response which is being acknowledged. To keep things simple, the acknowledgements are not cumulative, and the specifications recommend a single outstanding provisional response at a time, for purposes of congestion control. 4 Detailed Overview of Operation The reliability mechanism is based on the standard windowed acknowledgement technique. When a server generates a provisional response which is to be delivered reliably, it places a sequence number (via the RSeq header field) in the provisional response. These sequence numbers are chosen with a random initial value, for security reasons. The provisional response is then retransmitted with an exponential backoff, in a fashion that is identical to final responses to INVITE. Note that a UAS MUST NOT send a response reliably unless there was a Supported or Require header in the request indicating this extension [3]. Proxies forward these provisional responses as they are received. There are no local retransmissions or processing of any other kind. Each provisional response received by a proxy is forwarded upstream. This is standard behavior in RFC2543 compliant proxies. Strictly speaking, RFC2543 makes forwarding of provisionals upstream optional. However, to our knowledge all existing proxies forward all provisional responses upstream. The provisional response is then received at the UAC. The UAC can determine that the response is to be transmitted reliably by the presence of the Require header containing the option tag 100rel [3]. Responses which are not transmitted reliably do not contain this tag in a Require header. For a provisional response which is to be sent reliably, the UAC creates a new request, with a method of PRACK, used to acknowledge the provisional response. The PRACK request is like any other non- INVITE request sent within a call. The PRACK request contains the same Call-ID as the provisional response it is acknowledging. The CSeq number in the PRACK is higher than the last request sent by the UAC. PRACK also contains a header, called RAck, which contains the value of the RSeq header for the provisional response being acknowledged. The RAck header also contains the contents of the CSeq field in the response being acknowledged. The combination of Call-ID, J.Rosenberg,H.Schulzrinne [Page 3]
Internet Draft 100 Reliability September 19, 2001 CSeq, and RAck allow the PRACK request to be matched to a specific provisonal response within a specific transaction within a specific call. Like any other non-INVITE request, the PRACK request is retransmitted periodically up to a maximum of a four second interval. Note that the PRACK request SHOULD NOT be retransmitted when retransmissions of the provisional response are received. When the UAS receives the PRACK request, it knows that the provisional response has been received. The UAS then ceases retransmission of that provisional response. It also generates a 200 OK response to the PRACK, and sends it to the UAC. As with any other non-INVITE request, the 200 response to the PRACK request MUST be retransmitted when retransmissions of the PRACK request are received. When the UAC receives the 200 response (or any other final response) to the PRACK, it stops retransmitting the PRACK. This is standard behavior for non-INVITE requests. The UAS MUST NOT generate an additional reliable provisional response until the first is acknowledged. This is because the first reliable provisional response establishes the initial sequence number. If the UAS sent two reliable provisional responses, one right after the other, the UAC might receive the second one, accept it, and then receive the first, after having incorrectly accepted the other one. After the first is acknowledged, the UAS MAY send subsequent reliable provisional responses without waiting for acknowledgements of the previous. However, for purposes of congestion control, it is RECOMMENDED that a UAS wait for the acknowledgement of a provisional response before sending the next. This effectively means that reliable provisional responses can be sent at a rate of at most per one per RTT (it may be less if there is loss). 5 Extension Syntax Two new header fields are defined, RSeq and RAck, in addition to a new method, PRACK. The BNF for the headers are: RSeq = "RSeq" ":" response-num RAck = "RAck" ":" response-num CSeq-num Method response-num = 1*DIGIT CSeq-num = 1*DIGIT RSeq is a response header field. RAck is a request header field. J.Rosenberg,H.Schulzrinne [Page 4]
Internet Draft 100 Reliability September 19, 2001 The RSeq number in any reliable provisional response MUST be between 1 and 2**32 - 1. The value in the first reliable provisional response is randomly chosen by the UAS. It 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 request. This means that provisional responses for different requests MAY use the same values for the RSeq number. Reliable provisional responses for the same request MUST contain RSeq values which increment by exactly one for each response. RSeq numbers MUST NOT wrap around. Because the initial one is chosen to be less than 2**31 - 1, but the maximum is 2**32 - 1, there can be up to 2**31 reliable provisional responses per request, which is more than sufficient. The RAck header 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. The method specified here is called PRACK. Prack = "PRACK" As with other methods, the PRACK method name is case sensitive. The method name in the RAck header is also case sensitive. This document specifies the named extension 100rel This feature name is placed in the Supported or Require header in requests, or the Require, Supported or Unsupported header in responses [3]. 6 Detailed Protocol Semantics In this section, we discuss the detailed behavior required from user agent clients, user agent servers, and proxies, in order to implement this extension. 6.1 UAC Behavior If the UAC wishes to insist that all provisional responses are delivered reliably, it MUST include a Require header into the request containing the option tag 100rel. Otherwise, if a UAC supports this extension, it SHOULD include a Supported header into all requests (excepting ACK and PRACK), with the name 100rel listed as an option tag. The rest of this discussion assumes either the Require or Supported J.Rosenberg,H.Schulzrinne [Page 5]
Internet Draft 100 Reliability September 19, 2001 header has been inserted into a request containing the option tag 100rel. The request whose provisional response is being reliably sent is referred to as the initial request. If a provisional response is received for the initial request, and that response contains a Require header containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (as opposed to 101 to 199), this option tag is ignored. The reliability mechanisms defined here MUST NOT be used on 100 responses. 100 responses are hop by hop only. For this reason, the reliability mechanisms described here, which are end to end, cannot be used. Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. The Call-ID in this request MUST match that of the provisional response. The CSeq in this request MUST be larger than the last request (PRACK or otherwise) sent by this UAC for this call leg. The To, From, and Via headers MUST be present, and MUST be constructed as they would be for a re-INVITE or BYE as specified in [1]. In particular, if the provisional response contained a tag in the To field, this tag MUST be mirrored in the To field of the PRACK. If the provisional response contained a Timestamp header, this is copied into the PRACK. Since reliable provisional responses MAY contain Record-Route headers (if the request was an initial INVITE, for example), the PRACK request MUST contain Route headers according to the procedures specified in [1], as if the PRACK were a BYE. The Route header that is constructed from some provisional response MUST NOT be placed in any other request except for a PRACK for all provisional responses with the same tag in the To field. For reliable provisional responses to a request that contained Route headers, the PRACK MUST contain the same Route headers as the request. Since provisional responses can arrive from different UAS's, and from proxies, the routes to those entities will all be different. This means a Record-Route in one response may be different from the Record-Route in another. To make sure the PRACK request gets to the right place, it has to contain the Route header that comes from the Record-Route header in the response it acknowledges. PRACK requests MAY contain bodies. This is useful for establishing early media sessions for tones and announcements, or for setting up J.Rosenberg,H.Schulzrinne [Page 6]
Internet Draft 100 Reliability September 19, 2001 security or network preconditions for call completion. If the initial request was sent with credentials, the PRACK request SHOULD contain those credentials as well. It is not neccesary to include the Supported header listing the option tag 100rel in the PRACK request. That is because a UAS MUST NOT generate reliable provisional responses to PRACK. An implementation MUST NOT send a PRACK request if this extension is not supported. Furthermore, an implementation MUST NOT include a Require header in the PRACK with the option tag 100rel, as reliable provisional responses to PRACK are forbidden. Once the PRACK request is created, it is sent by the UAC. It is sent as would any other non-INVITE request for a call. In particular, when sent over UDP, the PRACK request is retransmitted with an exponentially increasing interval, starting at 500 milliseconds and increasing to 4 seconds. Note that 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. As with any other non-INVITE request, the UAC continues to retransmit the PRACK request until it receives a final response. A reliable provisional response for which a PRACK request has been sent is called an acknowledged reliable provisional response. A PRACK request MUST NOT be cancelled - that is, a UAC MUST NOT ever send a CANCEL for a PRACK request. Handling of subsequent reliable provisional responses for the same request follows the same rules as above, with the following difference. Reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives a reliable provisional response, and its RSeq value isn't one higher than the previous acknowledged reliable provisional response within the same call leg (defined as the combination of To, From and Call-ID headers, including tags), that response MUST NOT be acknowledged with a PRACK. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. Note that this requires the UAC to store the RSeq value of the last acknowledged reliable provisional response for the duration of the transaction. Note that the UAC MUST acknowledge a reliable provisional response as described above, even after a final response to the request has arrived. 6.2 UAS Behavior J.Rosenberg,H.Schulzrinne [Page 7]
Internet Draft 100 Reliability September 19, 2001 The UAS MAY send any non-100 provisional response reliably, so long as the initial request contained a Supported header indicating that this feature is understood. The UAS MUST send any non-100 response reliably if the initial request contained a Require header indicating that the feature is mandatory for all provisional responses. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include a Unsupported header containing the option tag 100rel. A UAS MUST NOT attempt to send a 100 response reliably. Only responses numbered 101 to 199 may be sent reliably. A UAS MUST NOT send a reliable provisional response to a PRACK request, in order to avoid provisional/PRACK loops. If the request did not include either a Supported or Require header indicating this feature, the UAS SHOULD send the provisional response unreliably. The rest of this discussion assumes that the initial request contained a Supported or Require header listing this feature, and that there is a provisional response to be sent reliably. Note that a UAS can send reliable provisional responses for any request, excepting a PRACK request and ACK. It is anticipated that reliable provisional responses will be most useful for INVITE requests. The provisional response to be sent reliably MUST include a Require header containing the option tag 100rel The provisional response to be sent reliably MUST include an RSeq header. The numeric value of this header is chosen randomly for the first provisional response for a given request as described in section 5. The value in each subsequent reliable provisional response for the same request MUST be greater by exactly one. The RSeq numbering space is within a single request. This means that provisional responses for different requests (where different is defined in [1]) MAY use the same values for the RSeq number. Reliable provisional respones MAY contain a body. If the initial request contained Record-Route headers, the provisional response MUST contain a copy of those headers, as if the response were a 200 OK to the initial request. As with any other response, reliable provisional responses MUST mirror the From, Call-ID, CSeq, Via, and To fields from the request. The UAS MUST insert a tag into the To field of the provisional response, if none was present already. This tag MUST also be used in the final response. The reliable provisional response MUST contain a Contact header. J.Rosenberg,H.Schulzrinne [Page 8]
Internet Draft 100 Reliability September 19, 2001 Reliable provisional responses MAY contain a Timestamp header, which will be mirrored in the PRACK. This allows for RTT estimation. See section 7. The reliable provisional response is retransmitted periodically, even if sent over TCP. Computation of this retransmission interval is discussed in Section 7. The UAS then waits for a PRACK request. It matches the PRACK request to a reliable provisional response through the Call-ID, To, and From, which identify the call-leg of the PRACK, and through the RAck header, which identifies the particular request and provisional response within the call leg. Specifically, a PRACK request X matches a provisional response Y if all of the following are true: o The Call-ID in X matches the Call-ID in Y. o The From in X matches the From in Y, including the tag, if present. o The To in X matches the To in Y, including the tag, if present. o The method in the RAck of X matches the method in the CSeq of Y. o The CSeq-num in the RAck matches the CSeq number in Y. o The response-num in the RAck matches the RSeq value in Y. If a PRACK request is received that does not match any reliable provisional response, the UAS responds to the PRACK with a 481 response. PRACK requests MAY be authenticated. If the UAS requires authentication of the requestor, and the PRACK does not contain credentials, or contains bad credentials, the UAS MAY respond to the PRACK with a 401, as outlined in [1], and include a challenge in the response. If a PRACK request is received that matches a provisional response for which no PRACK has been received, the provisional response retransmission ceases. The UAS generates a 200 OK response to the PRACK, and sends it. The rules for generation of the 200 OK for the PRACK, and for its transmission, follow those for the response to any non-INVITE request outlined in [1]. The UAS can be certain at this point that the provisional response has been received in order. J.Rosenberg,H.Schulzrinne [Page 9]
Internet Draft 100 Reliability September 19, 2001 If the PRACK contained a body, the body is treated in the same way a body in an ACK is treated. As with any other non-INVITE request, if a retransmission of the PRACK request is received, the response to the PRACK is retransmitted. There is no need to retransmit the reliable provisional response when a PRACK is received. A PRACK request MUST NOT be cancelled. If a UAS receives a CANCEL request for a PRACK, it MUST respond to the CANCEL with a 405 (Method Not Allowed). After the first reliable provisional response for a request has been acknowledged, the UAS MAY send additional reliable provisional responses. The UAS MUST NOT send a second reliable provisional response until the first is acknowledged. After the first, it is RECOMMENDED that the UAS not send an additional reliable provisional response until the previous is acknowledged. The first reliable provisional response receives special treatment because it conveys the intitial sequence number. If additional reliable provisional responses were sent before the first is acknowledged, the UAS could not be certain these were received in order. Note that the UAS MAY send a final response to the initial request before having received PRACKs for all outstanding reliable provisional responses. However, it SHOULD continue to retransmit those outstanding responses, and 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 outstanding ones) after sending a final response to a request. 6.3 Proxy Behavior This extension does not require active participation from proxies. As far as they are concerned, the PRACK is just another request to be forwarded. In most cases, the PRACK will have Route headers to indicate its proxy path. If there is no Route header, the PRACK is forwarded as any other request without a Route header. Rules for forking of a PRACK follow those for any non-INVITE request; the best response is forwarded upstream. The only requirement for proxies is that they MUST pass all provisional responses upstream. RFC 2543 does not mandate that provisional responses are forwarded, although most proxy implementations do. Note that proxies MAY generate their own provisional responses to be sent reliably. When they do so, they follow the rules in Section 6.2, J.Rosenberg,H.Schulzrinne [Page 10]
Internet Draft 100 Reliability September 19, 2001 playing the role of the UAS, with the following exceptions. PRACK requests which do not match a provisional response sent reliably by the proxy are forwarded, rather than responded to with a 481. A PRACK that does match a provisional response sent by the proxy MUST NOT be forwarded. To ensure that the PRACK request is routed to the right proxy, a proxy MUST copy the Record-Route header from the received initial request into the reliable provisional response. Furthermore, the proxy MUST then add a Contact header into the provisional response, pointing to itself (in essence, the proxy is a UAS for the purposes of the reliable provisional response). Note that it is not required for the proxy to insert itself into the Record-Route header of the request that is forwarded downstream. This allows a proxy to receive PRACK requests for its own responses, but not be on the signaling path for subsequent requests. Note that a proxy MUST insert a tag in the To field of the provisional response if none is present. A proxy MUST NOT generate reliable provisional responses for requests with tags in the To field, since it cannot insert a tag into requests that already have one. This ensures that PRACK requests for provisional responses generated by different proxies can be processed at the right proxy. The reliable provisional responses from two different proxies, for the same request, differ only in their tag in the To field. Therefore, to match the PRACK request to a provisional response, the tag in the To header MUST be used. The tag must also be present to define a separate RSeq space for reliable provisional responses generated by different proxies. Finally, note that a proxy that wishes to send a non-100 provisional response, MUST do so reliably if the Require header (NOT the Proxy- Require header) is present in the request. This is because the proxy is acting effectively as a user agent, and is thus bound by the Require header instead of the Proxy-Require. 7 Retransmit Interval Computation The retransmission interval for reliable provisional responses starts at 500 ms, and doubles after each retransmission, up to a maximum of 16 seconds. This mirrors the behavior of INVITE requests in [1]. If no PRACK is received for that response after 40 seconds, it is considered a network or endpoint failure. Behavior at that point is at the discretion of the implementor. More information is needed here on using the RTT estimates J.Rosenberg,H.Schulzrinne [Page 11]
Internet Draft 100 Reliability September 19, 2001 measured with the Timestamp. 8 Examples 8.1 Message Formatting In this example, a UAC sends an INVITE to a UAS directly. The UAS sends a 183 response reliably. The initial request looks like: C->S: INVITE sip:watson@bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com Supported: 100rel From: sip:alexander@bell-tel.com;tag=736ad7789 Contact: sip:alexander@host33.bell-tel.com To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 INVITE Subject: Come here Watson The server first responds with a 100: S->C: SIP/2.0 100 Trying Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 INVITE and then with a 183 that is sent reliably: S->C: SIP/2.0 183 Proceeding Require: 100rel Via: SIP/2.0/UDP saturn.bell-tel.com RSeq: 776655 From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 J.Rosenberg,H.Schulzrinne [Page 12]
Internet Draft 100 Reliability September 19, 2001 Call-ID: 70710@saturn.bell-tel.com Contact: sip:watson@mypc.bell-tel.com CSeq: 1 INVITE Content-Type: application/sdp v=0 s=Let's talk b=CT:128 c=IN IP4 north.east.isi.edu m=audio 3456 RTP/AVP 5 0 7 m=video 2232 RTP/AVP 31 This response is retransmitted with an exponential backoff. When the UAC receives the response, it sends a PRACK: C->S: PRACK sip:watson@mypc.bell-tel.com SIP/2.0 RAck: 776655 1 INVITE Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 2 PRACK Content-Type: application/sdp v=0 s=Let's talk b=CT:128 c=IN IP4 machine.bell-tel.com m=audio 3456 RTP/AVP 5 0 7 m=video 2232 RTP/AVP 31 Upon receiving this, the UAS stops retransmitting the 183, and sends a 200 OK to the PRACK: S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 2 PRACK J.Rosenberg,H.Schulzrinne [Page 13]
Internet Draft 100 Reliability September 19, 2001 The UAS then sends two provisional responses in rapid succession: S->C: SIP/2.0 182 Two in the Queue Via: SIP/2.0/UDP saturn.bell-tel.com Require: 100rel RSeq: 776656 From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com Contact: sip:watson@mypc.bell-tel.com CSeq: 1 INVITE S->C: SIP/2.0 182 One in the Queue Via: SIP/2.0/UDP saturn.bell-tel.com Require: 100rel RSeq: 776657 From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com Contact: sip:watson@mypc.bell-tel.com CSeq: 1 INVITE The UAC then receives these both, and sends a two PRACK requests to acknowledge them both: C->S: PRACK sip:watson@mypc.bell-tel.com SIP/2.0 RAck: 776656 1 INVITE Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 3 PRACK C->S: PRACK sip:watson@mypc.bell-tel.com SIP/2.0 RAck: 776657 1 INVITE Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 J.Rosenberg,H.Schulzrinne [Page 14]
Internet Draft 100 Reliability September 19, 2001 Call-ID: 70710@saturn.bell-tel.com CSeq: 4 PRACK This causes retransmission of both 181 responses to be stopped, and a 200 OK to each PRACK to be sent: S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 3 PRACK S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 4 PRACK Finally, the UAS sends a final response to the INVITE: S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com;tag=736ad7789 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com Contact: sip:watson@mypc.bell-tel.com CSeq: 1 INVITE Content-Type: application/sdp v=0 s=Let's talk b=CT:128 c=IN IP4 north.east.isi.edu m=audio 3456 RTP/AVP 5 0 7 J.Rosenberg,H.Schulzrinne [Page 15]
Internet Draft 100 Reliability September 19, 2001 m=video 2232 RTP/AVP 31 And the UAC sends an ACK for the 200 OK: C->S: ACK sip:watson@mypc.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:alexander@bell-tel.com To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 1 INVITE 8.2 Message Flows This section illustrates an example message flow using this extension. We abbreviate a PRACK request with a RAck header value of M N INVITE as "PRACK M N", an INVITE with a CSeq of N as "INV N", a provisional response with a RSeq header value of M as "1xx M", and a 200 OK response to a PRACK as "200 PRACK". Packets which are lost are shown with an "X" in front of them. The ladder diagram considers the case of a direct request between a UAC and UAS. The UAS sends a 100 response first, and then a 180 reliably. It then responds with a final response of 300. UAC UAS (request -------INV 1---------------> retransmits start) X<.......100......... -------INV 1---->X -------INV 1--------------> (request <..........100............. retransmissions cease) X<...180 3............ (180 retransmits start) <.........180 3............ (PRACK -------PRACK 3 1---->X J.Rosenberg,H.Schulzrinne [Page 16]
Internet Draft 100 Reliability September 19, 2001 retransmits start) <.........180 3............ -------PRACK 3 1----------> (180 retransmits cease) X<....200 PRACK........ -------PRACK 3 1----------> (PRACK 3 1 <.........200 PRACK........ retransmits cease) X<....300............... (300 class retransmits start) <........300............... -----------ACK------------> (300 retransmits cease) 9 Security Considerations The PRACK request can be injected by attackers to force retransmissions of reliable provisional responses to cease. As these responses can convey important information, PRACK messages SHOULD be authenticated as any other request. 10 Acknowledgements The authors would like to thank Jonathan Lennox, Adam Roach, and Tim Schroeder for the comments on this document. 11 Changes since -03 o Removed references to expired or otherwise not important drafts. o Updated transmission timer limits. o Fixed usage of route sets to be consistent with bis. Specifically, a proxy now inserts a Contact into a reliable provisional response, since it is effectively a UAS for the purposes of the early call leg it is creating. Also, route sets persist for a call leg, rather than for a particular provisional response. 12 Author's Addresses Jonathan Rosenberg dynamicsoft J.Rosenberg,H.Schulzrinne [Page 17]
Internet Draft 100 Reliability September 19, 2001 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu 13 Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [2] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [3] J. Rosenberg and H. Schulzrinne, "The SIP supported header," Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in progress. J.Rosenberg,H.Schulzrinne [Page 18]