Internet Draft Internet Engineering Task Force SIP WG Internet Draft J.Rosenberg,H.Schulzrinne draft-ietf-sip-100rel-02.txt dynamicsoft,Columbia U. June 30, 2000 Expires: December, 2000 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 The list of Internet-Draft Shadow Directories can be accessed at 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 June 30, 2000 session progress (183) [2]. 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 a simple 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 is simple, requiring 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", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant implementations. 3 Overview 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 [4]. Note that the reliability provided is NOT hop-by-hop. Proxies do not retransmit the provisional responses; they are simply forwarded. This is similar to the way in which 200 responses for INVITE messages are handled in proxies. Note, however, that the PRACK message described here is sent reliably using the same hop-by-hop techniques for all non-INVITE requests. The provisional response is then received at the UAC. The UAC can J.Rosenberg,H.Schulzrinne [Page 2] Internet Draft 100 Reliability June 30, 2000 determine that the response is to be transmitted reliably by the presence of the Require header containing the option tag 100rel [4]. 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 that of the request whose provisional response it acknowledges. The 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, 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. 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). 4 Extension Syntax Two new header fields are defined, RSeq and RAck, in addition to a new method, PRACK. The BNF for the headers are: J.Rosenberg,H.Schulzrinne [Page 3] Internet Draft 100 Reliability June 30, 2000 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. 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 or Unsupported header in responses [4]. 5 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. 5.1 UAC Behavior J.Rosenberg,H.Schulzrinne [Page 4] Internet Draft 100 Reliability June 30, 2000 If a UAC supports this extension, it MUST include a Supported header into all requests (excepting ACK and PRACK), with the name 100rel listed as an option tag. Alternatively, 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. The rest of this discussion assumes either the Require or Supported 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. 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 the PRACK for that specific provisional response. 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 J.Rosenberg,H.Schulzrinne [Page 5] Internet Draft 100 Reliability June 30, 2000 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. A UAC MUST NOT insert a Route header into a PRACK request if (1) no Record-Route header was present in the response, and (2) no Route header was present in the request whose provisional response is being acknowledged. PRACK requests MAY contain bodies. This is useful for establishing early media sessions for tones and announcements, or for setting up security or network preconditions for call completion [5] 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. J.Rosenberg,H.Schulzrinne [Page 6] Internet Draft 100 Reliability June 30, 2000 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. 5.2 UAS Behavior 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, and the UAS wishes to send some provisional responses reliably, the UAS SHOULD reject the intitial request and include a Require header in the response, as per [4]. 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 4. 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 J.Rosenberg,H.Schulzrinne [Page 7] Internet Draft 100 Reliability June 30, 2000 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. This tag MUST also be used in the final response. The reliable provisional response MUST contain a Contact header. The reliable provisional response is retransmitted periodically, even if sent over TCP. The retransmission interval starts at 500 ms, and doubles after each retransmission, up to a maximum of 32 seconds. This mirrors the behavior of INVITE responses in [1]. If no PRACK is received for that response after 96 seconds, it is considered a network or endpoint failure. Behavior at that point is at the discretion of the implementor. 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 J.Rosenberg,H.Schulzrinne [Page 8] Internet Draft 100 Reliability June 30, 2000 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. 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 MUST be prepared to process PRACK requests for those outstanding responses. A UAS MUST NOT send reliable provisional responses after sending a final response to a request. 5.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 J.Rosenberg,H.Schulzrinne [Page 9] Internet Draft 100 Reliability June 30, 2000 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. Note that proxies MAY generate their own provisional responses to be sent reliably. When they do so, they follow the rules in Section 5.2, 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 itself as the first entry in the Record-Route header returned in the provisional response. If no Record-Route header was present in the request, and thus none copied to the response, the proxy MUST create one in the response and add itself as the only entry. 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. 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. 6 Examples J.Rosenberg,H.Schulzrinne [Page 10] Internet Draft 100 Reliability June 30, 2000 6.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 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 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 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 1 INVITE Content-Type: application/sdp v=0 J.Rosenberg,H.Schulzrinne [Page 11] Internet Draft 100 Reliability June 30, 2000 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@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 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 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 2 PRACK The UAS then sends two provisional responses in rapid succession: J.Rosenberg,H.Schulzrinne [Page 12] Internet Draft 100 Reliability June 30, 2000 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 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.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 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.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@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 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 3 PRACK C->S: PRACK sip:watson@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 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 4 PRACK This causes retransmission of both 181 responses to be stopped, and a J.Rosenberg,H.Schulzrinne [Page 13] Internet Draft 100 Reliability June 30, 2000 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 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 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 To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.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 And the UAC sends an ACK for the 200 OK: J.Rosenberg,H.Schulzrinne [Page 14] Internet Draft 100 Reliability June 30, 2000 C->S: ACK sip:watson@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 6.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 retransmits start) <.........180 3............ -------PRACK 3 1----------> (180 retransmits cease) X<....200 PRACK........ -------PRACK 3 1----------> (PRACK 3 1 <.........200 PRACK........ retransmits J.Rosenberg,H.Schulzrinne [Page 15] Internet Draft 100 Reliability June 30, 2000 cease) X<....300............... (300 class retransmits start) <........300............... -----------ACK------------> (300 retransmits cease) 7 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. 8 Acknowledgements The authors would like to thank Jonathan Lennox, Adam Roach, and Tim Schroeder for the comments on this document. 9 Author's Addresses Jonathan Rosenberg dynamicsoft 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 10 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. J.Rosenberg,H.Schulzrinne [Page 16] Internet Draft 100 Reliability June 30, 2000 [2] S. Donovan, H. Schulzrinne, J. Rosenberg, M. Cannon, and A. Roach, "SIP 183 session progress message," Internet Draft, Internet Engineering Task Force, Oct. 1999. Work in progress. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [4] J. Rosenberg and H. Schulzrinne, "The SIP supported header," Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in progress. [5] W. Marshall et al. , "Integration of resource management and SIP for IP telephony," Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in progress. J.Rosenberg,H.Schulzrinne [Page 17]