Internet Engineering Task Force SIP WG Internet Draft J.Rosenberg,H.Schulzrinne draft-ietf-sip-100rel-00.txt dynamicsoft,Columbia U. January 16, 2000 Expires: July, 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 org.ietf.sip.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 January 16, 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 are delivered reliably end to end, independent of the underlying transport mechanism. The extension works for provisional responses for any method. 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 org.ietf.sip.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 header in the request indicating support for 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 determine that the response is to be transmitted reliably by the J.Rosenberg,H.Schulzrinne [Page 2]
Internet Draft 100 Reliability January 16, 2000 presence of the RSeq header. Responses which are not transmitted reliably do not contain the RSeq 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 one or more provisional responses (PRACK is a cumulative acknowledgement). 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 highest value of the RSeq among the provisional responses 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 set of provisonal responses 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 is SHOULD NOT be retransmitted when retransmissions of the provisional response are received. When the UAS receives the PRACK request, it knows that the set of provisional responses have been received. The UAS then ceases retransmission of those provisional responses. 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. Since the PRACK request is a cumulative acknowledgement, a UAC MAY send a single PRACK for several provisional responses. 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 J.Rosenberg,H.Schulzrinne [Page 3]
Internet Draft 100 Reliability January 16, 2000 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. 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 in the RAck header is also case sensitive. This document specifies the named extension org.ietf.sip.100rel. This feature name is placed in the Supported or Unsupported header in requests. 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 J.Rosenberg,H.Schulzrinne [Page 4]
Internet Draft 100 Reliability January 16, 2000 this extension. 5.1 UAC Behavior If a UAC supports this extension, it MAY include a Supported header with the name org.ietf.sip.100rel listed as a feature token. If the UAC does not insert this header in an initial request, and it receives an error response with either a Require or Proxy-Require header indicating this feature, the UAC MUST resubmit the request, and this time include the Supported header listing this feature. This behavior is specified in the server side feature extension specification [4]. The rest of this discussion assumes this header has been inserted into a request. 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 an RSeq header, the response is to be sent reliably. If the response is a 100 (as opposed to 101 to 199), the RSeq in the response 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. If the received provisional response was not a 100, and contained an RSeq header, 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 and Contact headers, the PRACK request MUST contain Route headers if the Record-Route headers were present in the provisional response. The Route header is constructed as specified in [1]. The Route header that is constructed from some provisional response MUST NOT be placed in any other request except for the PRACK for that provisional response. Since provisional responses can arrive from different UAS's, and from proxies, the routes to those entities will J.Rosenberg,H.Schulzrinne [Page 5]
Internet Draft 100 Reliability January 16, 2000 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. A UAC MUST NOT insert a Route header into a PRACK request if no Record-Route header was present in the response. 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][6]. 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 feature org.ietf.sip.100rel in the PRACK request. The usage of this method implicitly indicates support for this extension. An implementation MUST NOT send a PRACK request if this extension is not supported. 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 MAY be cancelled. However, whilst allowed for purposes of generality, usage of CANCEL with PRACK is NOT RECOMMENDED. 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, 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 J.Rosenberg,H.Schulzrinne [Page 6]
Internet Draft 100 Reliability January 16, 2000 value of the last acknowledged reliable provisional response for the duration of the transaction. If the UAC has received a sequence of reliable provisional responses, and there are no gaps in the RSeq values among those responses, and the lowest RSeq value is one higher than the last acknowledged reliable provisional response, the UAC MAY send a single PRACK request to acknowledge the entire sequence. The RAck header in the PRACK refers to the highest received RSeq value. It acknowledges receipt of all reliable provisional responses up to, and including, the one whose RSeq value is listed in the RAck. 5.2 UAS Behavior The UAS MAY send any provisional response reliably, so long as the initial request contained a Supported header indicating that this feature is understood. If the request did not include a Supported header indicating this feature, and it did not include a Unsupported 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]. In addition, the UAS MUST NOT attempt to send a 100 response reliably. Only responses numbered 101 to 199 MAY be sent reliably. The rest of this discussion assumes that the initial request contained a Supported header listing this feature, and that there is a response to be sent reliably. Note that a UAS MAY send reliable provisional responses for any request, including a PRACK request. It is anticipated that reliable provisional responses will be most useful for INVITE requests. 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 provisional responses for different requests 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. The reliable provisional response MUST contain a Contact header. J.Rosenberg,H.Schulzrinne [Page 7]
Internet Draft 100 Reliability January 16, 2000 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. If Y did not contain a tag, but X did, these do not match. If Y did contain a tag, but X does not, these do match. 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 is greater than or equal to the RSeq value in Y. Note that a single PRACK may match multiple provisional responses. Only one response is sent to the PRACK. 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 does match some provisional responses for which no PRACK has been received, the provisional response retransmissions for those responses cease. The UAS generates J.Rosenberg,H.Schulzrinne [Page 8]
Internet Draft 100 Reliability January 16, 2000 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 any non-INVITE method outlined in [1]. The UAS can be certain at this point that those provisional responses have been received in order. If a PRACK request is received that does match some provisional responses, but a different PRACK has been received for all those responses already (different meaning the PRACK had a different CSeq value), the new PRACK is responded to with a 200 OK. There is no need to stop retransmissions of those reliable provisional responses that match, since their retransmissions will have already ceased from the previous PRACK. 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 MAY be cancelled. If a UAS receives a CANCEL request for a PRACK before it has sent a final response to the PRACK, the PRACK is responded to with a 487, and the UAS acts as if the PRACK were never received. However, whilst allowed for purposes of generality, usage of CANCEL with PRACK is NOT RECOMMENDED. 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 additional reliable provisional responses 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. 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 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. J.Rosenberg,H.Schulzrinne [Page 9]
Internet Draft 100 Reliability January 16, 2000 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. 6 Examples 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: org.ietf.sip.100rel, org.ietf.sip.supported From: sip:alexander@bell-tel.com To: sip:watson@bell-tel.com J.Rosenberg,H.Schulzrinne [Page 10]
Internet Draft 100 Reliability January 16, 2000 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 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 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 Supported: org.ietf.sip.supported From: sip:alexander@bell-tel.com J.Rosenberg,H.Schulzrinne [Page 11]
Internet Draft 100 Reliability January 16, 2000 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: S->C: SIP/2.0 182 Two in the Queue Via: SIP/2.0/UDP saturn.bell-tel.com 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 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 J.Rosenberg,H.Schulzrinne [Page 12]
Internet Draft 100 Reliability January 16, 2000 The UAC then receives these both, and sends a single PRACK to acknowledge them both: C->S: PRACK sip:watson@bell-tel.com SIP/2.0 RAck: 776657 1 INVITE Via: SIP/2.0/UDP saturn.bell-tel.com Supported: org.ietf.sip.supported From: sip:alexander@bell-tel.com To: sip:watson@bell-tel.com;tag=11 Call-ID: 70710@saturn.bell-tel.com CSeq: 3 PRACK This causes retransmission of both 181 responses to be stopped, and a 200 OK to the 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 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 J.Rosenberg,H.Schulzrinne [Page 13]
Internet Draft 100 Reliability January 16, 2000 And the UAC sends an ACK for the 200 OK: 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----------> J.Rosenberg,H.Schulzrinne [Page 14]
Internet Draft 100 Reliability January 16, 2000 (PRACK 3 1 <.........200 PRACK........ retransmits cease) X<....300............... (300 class retransmits start) <........300............... -----------ACK------------> (300 retransmits cease) 7 Open Issues There are a number of open issues: 1. Is PRACK an OK name for this request? 2. Do we need cumulative acknowledgements, or is to too complex? 3. Should we simply disallow CANCEL for PRACK? 8 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. 9 Acknowledgements The authors would like to thank Jonathan Lennox and Adam Roach for the comments on this document. 10 Author's Addresses Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: jdrosen@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 J.Rosenberg,H.Schulzrinne [Page 15]
Internet Draft 100 Reliability January 16, 2000 email: schulzrinne@cs.columbia.edu 11 Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. [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 (Best Current Practice) 2119, Internet Engineering Task Force, Mar. 1997. [4] J. Rosenberg and H. Schulzrinne, "Mandating SIP extension support by servers," Internet Draft, Internet Engineering Task Force, Jan. 2000. Work in progress. [5] J. Rosenberg, H. Schulzrinne, and S. Donovan, "Establishing QoS and security preconditions for SDP sessions," Internet Draft, Internet Engineering Task Force, June 1999. Work in progress. [6] W. Marshall, K. Ramakrishnan, E. Miller, G. Russell, B. Beser, M. Mannette, K. Steinbrenner, D. Oran, J. Pickens, P. Lalwaney, J. Fellows, D. Evans, K. Kelly, and F. Andreasen, "Integration of resource management and call signaling for IP telephony," Internet Draft, Internet Engineering Task Force, Oct. 1999. Work in progress. J.Rosenberg,H.Schulzrinne [Page 16]