SIP H. Khartabil Internet Draft Nokia Expires: January 24, 2003 July 25, 2002 Congestion safety and Content Indirection draft-khartabil-sip-congestionsafe-ci-00.txt 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 a 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. This Internet Draft will expire on January 28, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The Session Initiation Protocol allows the use of UDP for transport of SIP messages. Baseline SIP does not allow congestion control for messages larger than MTU of a certain link nor does it allow end points to specify their maximum acceptable message size, regardless of the underlying transport protocol. This document combines two, namely congestion safely and Content- Indirection Mechanism into the one document and presents scenarios where the 2 could be combined. It also introduces extensions to SIP that allows end points to specify their maximum acceptable message size. Khartabil [Page 1] Internet Draft Congestion Safely and C-I July 2002 1.0 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 [5]. 2.0 Introduction The Session Initiation Protocol [1] allows the use of UDP for transport of SIP messages. The use of UDP with large payloads risks network congestion problems, as UDP itself does not define congestion prevention, detection, or correction mechanisms. Large SIP messages may cause UDP datagram fragmentation, something not desired by a network of SIP entities. The root of the problem lies with the SIP proxies. SIP proxies are able to convert the transport protocol from reliable to unreliable on hop-by-hop basis, therefore end-to end congestion-safe path for SIP messages cannot be guaranteed. Conventional SIP payloads carry signalling information about media, but not media itself. There is potential that when a SIP infrastructure is shared between call signalling and instant messaging [2], the IM traffic will interfere with call signalling traffic. This also applies to other types of SIP Requests that have potential to carry large contents (NOTIFY is an example). Furthermore, mobile terminals might want to limit the size of a SIP message received regardless of the underlying transport protocol (e.g. TCP). This may be due to memory limitations or the fact that the radio link that the terminal is accessing at this instant is very slow and the user wants to postpone collecting data until a better link is acquired. 3.0 Overview of Operation The basic scenario is when a SIP request is being sent from a UA1 to a UA2 that has a home proxy. That SIP request could carry large contents. --- +---------+ // \\ +-------+ | UA2 | / \ +-------+ |UA2 |--------| Home |-------Internet -------| UA1 | | | | Proxy | | | | | +-------+ | | \ / +-------+ +---------+ \\ // --- Khartabil [Page 2] Internet Draft Congestion Safely and C-I July 2002 UA2 earlier has registered at the registrar co-located with the home proxy. UA2 may have indicated its maximum acceptable message size using the extensions defined in this document. Upon the home proxy receiving the request with the large contents, it has the option of rejecting the request with a ô513 Message Too Largeö error response (congestion safety) or forwarding it to a Content Storage Server (CSS). The home proxy learns the maximum acceptable message size from registration by UA2 (regardless of transport protocol) or through configuration. The home proxy, unaware of the limitations, can forward the large message to UA2, who consequently, can reject the message with error response ô413 Request Entity Too Largeö. UA2 can indicate its maximum acceptable message size using extension in this document. The home proxy receiving the ô413ö response can either just forward that response upstream or act as a B2BUA and resend the requested with content-indirection to the CSS. 4.0 UA Behaviour 4.1 UA Registering Desired Maximum SIP Message Size Having learnt its capabilities and limitations (by user input or other means), a SIP UA issuing a REGISTER request MAY indicate its acceptable maximum size for a SIP message (including headers and body). This section introduces a new SIP-URI parameter ômax-sizeö. A SIP UA registering its address will include this SIP-URI parameter in the contact-header supplied with the REGISTER request. If the transport parameter is present in the SIP URI of the contact header, then this max-size applies to that particular transport protocol. If transport parameter is not present, then this max-size applies to the default transport protocol used (UDP). Example REGISTER Request: REGISTER sip:registrar.nokia.com SIP/2.0 Via: SIP/2.0/UDP host1.nokia.com;branch=z9hG4bK346434r From: sip:hisham.khartabil@nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:hisham.khartabil@nokia.com Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 REGISTER Max-Forwards:70 Example REGISTER Request where the max-size applies to TCP: Khartabil [Page 3] Internet Draft Congestion Safely and C-I July 2002 REGISTER sip:registrar.nokia.com SIP/2.0 Via: SIP/2.0/UDP host1.Nokia.com;branch=z9hG4bK346434r From: sip:hisham.khartabil@nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:hisham.khartabil@nokia.com Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 REGISTER Max-Forwards:70 4.2 UAS Receiving A SIP Message With Large Contents A SIP UAS may not have indicated its willingness or capabilities in receiving large message content with the REGISTER request. This may be due to lack of knowledge by the UA, at the time of registration, of its memory or radio link constraints. A SIP UAS receiving a SIP Request it is unable to handle due to size, regardless of the underlying transport protocol, MAY reject the request with ô413 Request Entity Too Largeö. The UAS MAY close the connection, if the transport protocol was a reliable connection oriented one, to prevent the sender from continuing the request. If the condition is temporary, the UAS SHOULD include a Retry-After header field to indicate that this condition is temporary and after what time the sender can try to send the same request again. The UAS MAY also indicate its acceptable message size capabilities. Here we introduce a new SIP header ôMax-Sizeö. The ô413ö response sent back by the UAS MAY contain this header. This header contains the maximum acceptable message size by this UAS. The ô413ö response MAY also include an Accept-header with value message/external-body indicating its capability to handle content- indirection. Example response: SIP/2.0 413 Request Entity Too Large Via: SIP/2.0/UDP proxy.nokia.com;branch=z9hG4bK4kl5jr0iui0giu09df43 Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:markus.isomaki@nokia.com;tag=4jk123vxbc96 To: sip:hisham.khartabil@nokia.com;tag=fsad98754b6b64m Call-Id: j4lk2j35879cvx7b CSeq: 1 MESSAGE Max-Size: 1300 Retry-After: 180 Max-Forwards:70 Accept: message/external-body A SIP Response with large contents that exceeds the limitations is discarded. If the transport protocol is connection-oriented, the connection MAY be closed to stop further sending of the response. Khartabil [Page 4] Internet Draft Congestion Safely and C-I July 2002 4.3 UAC Assuring Congestion Safe SIP Request Path A UAC sending a SIP Request and wants to make sure that all proxies on the path are congestion-safe proxies MUST insert a ôProxy- Requireö header with the tag ôcongestion-safeö as described in [3]. 4.4 UAC Behaviour when receiving a ô413ö or ô513ö Error Response The max-size header MAY prompt the UAC of the request to send a newly formulated request immediately with either smaller contents or with content-indirection. If the Retry-After header is also present, the UAC MUST either wait for that time before sending the same request, or it immediately sends the newly formulated request. It SHOULD NOT resend exactly the same request within the retry-after period. The Retry-After value MAY be used as an indication of how long this Max-Size constraint is valid for. Max-size header indicates the SIP message size the UAS can handle for the transport protocol used to send the request. This constraint SHOULD NOT be applied to the same Request sent on different transport protocol. If an Accept-header is present without the value message/external- body, the UAC MUST NOT send the new message with content-type: message/external-body. The UAC MAY use this Max-size value to send new, unrelated Requests to the same URI within the duration indicated by the retry-after header. For example: UserA sends a SIP MESSAGE with large content to userB. UserB rejects the request with ô413 Request Entity Too Largeö with a max-size header of value 1300 bytes and a Retry-After value of 80 seconds. UserA now needs to send an unrelated NOTIFY to userB, due to an earlier SUBSCRIBE. This NOTIFY will be sent within the 80 seconds specified. UseA MAY use the 1300 byte constraint to send the NOTIFY. This has to be done with care since the UAS receiving the NOTIFY could be different that the one that received the MESSAGE. The UAC has to be certain that UAS receiving the requests are the same. 5.0 Home Proxy Behaviour Home proxy in this context means the inbound proxy closest to the UA where the UA has registered. In 3GPP terms, it is the S-CSCF closest to the UA. 5.1 Congestion Safe Home Proxy Khartabil [Page 5] Internet Draft Congestion Safely and C-I July 2002 A congestion safe home proxy MUST be complaint with this specification as well as [3] and [4]. This home proxy MUST understand the option tag ôcongestion-safeö. A congestion safe proxy MUST be able to handle content-indirection if it is configured with a Content Storage Server (CSS) as described in section 4.2. If not configured with CSS, the proxy behave as described in [3] 5.2 Home Proxy Receiving A SIP Message With Large Content Typically, this proxy is co-located with a Registrar. It handles incoming requests for a domain it services. This home proxy MAY also be a congestion-safe proxy as defined in [3]. The home proxy MAY be configured with a maximum allowable SIP message size that is destined to a recipient on a certain interface. This value is typically network configured with the lowest Maximum Transfer Unit (MTU) en route to the recipient (UAS) on that interface. The proxy server MUST only use the value when the recipient (UAS) is using UDP as the transport protocol. How this configuration is performed is out side the scope of this document. It is RECOMMENDED that dynamic discovery and configuration is performed. A proxy configured with this value is considered to be congestion-safe. The proxy MAY also learn the maximum size of a particular UA by means of registration as described in section 3.1 (Note in this case, the value may possibly not be the MTU). The smaller of the two values is used if both are present and the registered URI uses UDP as the transport protocol. If the registered URI uses connection- oriented protocol (such as TCP), then the configured value MUST be ignored. When the home proxy receives a request for a user in its domain, it examines the message size as follows: Note: This assumes that the user has registered and that the proxy has already contacted the registrar and retrieved the registered URI. Note: This also assumes that the proxy server, after fetching the registered contact has accepted to handle a request with size larger than the configured MTU or larger than the registered max-size for that recipient. If the proxy is not willing to do so, it simply rejects the request with ô513 Message Too Largeö. See section 4.3 for more details. 1. The proxy examines the SIP URI searching for host and transport to send the request to. Khartabil [Page 6] Internet Draft Congestion Safely and C-I July 2002 2. The proxy also searches for the max-size parameter and for the configured maximum allowable message size. 3. If the transport protocol is TCP, there are 2 cases (since configured value is not used for TCP): a. Registered URI does not contain max-size parameter. In this case, processing proceeds as described in [3]. b. Registered URI does contain max-size parameter. In this case, content-indirection MAY be applied. See section 4.4 for more details. 4. If the transport protocol is UDP, there are 4 cases: Proxy is not configured with this value and registered URI does not contain max-size parameter. In this case, processing proceeds as described in [3]. a. Proxy is configured with this value and registered URI does not contain max-size parameter. In this case, the message size is compared to the configured value. If the message size is smaller, then processing proceeds as normal. If the message size is greater, content-indirection MAY be applied. See section 4.4 for more details. b. Proxy is not configured with this value and registered URI does contain max-size parameter. In this case, the message size is compared to the registered URI max-size parameter value. If the message size is smaller, then processing proceeds as normal. If the message size is greater, content- indirection MAY be applied. See section 4.4 for more details. c. Proxy is configured with this value and registered URI does contain max-size parameter. In this case, the message size is compared to the smaller value of the two. If the message size is smaller, then processing proceeds as normal. If the message size is greater, content-indirection MAY be applied. See section 4.4 for more details. d. A SIP Response with large contents that exceeds the maximum acceptable size is discarded. If the transport protocol is connection-oriented, the connection MAY be closed to stop further sending of the response. 5.3 Home Proxy Refusing To Handle Large SIP Requests There are circumstances where the home proxy refuses to perform content-indirection on a received SIP Request destined to a recipient where a maximum message size constraint has been imposed. These circumstances may include the user not paying for this service or simply that the proxy does not know how to perform content- indirection (see section 4.1 about a congestion safe proxy). The Khartabil [Page 7] Internet Draft Congestion Safely and C-I July 2002 definitions of these circumstances are outside the scope of this document. In any case, when the home proxy refused to handle this situation or it is not a congestion safe proxy (does not understand the option tag ôcongestion-safeö), it returns a ô513 Message Too Largeö response. Reference [3] shows how a proxy SHOULD handle this situation. The ô513ö response SHOULD NOT include an Accept-header with message/external-body. This is because content indirection would have been performed at this point if the home proxy was capable and willing to do so. 5.4 Home Proxy Performing Content Indirection A home proxy that is a congestion safe proxy MUST handle content indirection. Here we define a new functional SIP entity called ôContent Storage Server (CSS). A congestion safe proxy MUST be configured with the CSS address. Once the home proxy has accepted to perform content indirection on a SIP Request, it forwards the message to the CSS. Section 16.6 of [1] defines the steps to follow. Pay special attention to step 6 where it discusses how a proxy may divert a SIP Request to a specific next hop. Below is a rewrite of that section tailored to the terminology used in this document: A Home proxy MAY mandate that a request visit a CSS before being delivered to the destination. This is to accommodate content indirection. A home proxy MUST ensure that CSS is a loose router. Generally, this can only be known with certainty if the CSS is within the same administrative domain. The CSS is represented by a URI (which contains the lr parameter). This URI MUST be pushed into the Route header field ahead of any existing values, if present. If the Route header field is absent, it MUST be added, containing that URI. 5.5 Home Proxy Receiving ô413ö Response from UA Open issue: should we just choose to forward the response upstream? A UA refusing to handle a large SIP Request may reject the request with ô413ö error response as describe in section 3.2. When the home proxy receives this response, it MAY choose to handle the request itself. It does so by reissuing the request, but this time, it sends it via the CSS using the route-header, as described Khartabil [Page 8] Internet Draft Congestion Safely and C-I July 2002 in section 4.4. The home server MAY also send a ô181 Call Is Being Forwardedö provisional response back to the sender. There are situations where the home proxy refuses the handle the request itself and alternatively just forward the ô413ö response to sender. See section 4.3 for more details. 6.0 Content Storage Server (CSS) Behaviour The CSS behaves as a SIP Back To Back User Agent (B2BUA). When it receives a SIP Request performs the following steps: 1. Extracts the body of the Request and stores it in an HTTP server. 2. Responds to the sender with a ô202 Acceptedö response. 3. Formulates a new request that includes the URL where the content can be retrieved from. This procedure is described in [4]. 4. Sends the new request to the destination, maintaining any tags in the To and From headers sent in the original request. This is to accommodate for SIP requests within dialogs being delivered to the right dialog. 7.0 Syntax for Extensions 7.1 Max-Size Header Max-Size = ôMax-Sizeö HCOLON delta-seconds Additions to SIP Table 3: Header field where proxy ACK BYE CAN INV OPT REG ----------------------------------------------------------- Max-Size 413 a - - - - - - 7.2 Max-size parameter Max-size-param = ômax-size=ö 1*DIGIT 8.0 Examples 8.1 Receiving A MESSAGE With Large Contents after a REGISTER, Home Proxy Performs Content-Indirection UA2 CSS UA2 UA1 Home Proxy Khartabil [Page 9] Internet Draft Congestion Safely and C-I July 2002 | | | | | | | | | (F1) REGISTER | | | |-------------------------------------->| | | | | | | | (F2) 200 Ok | | |<--------------------------------------| | | | | | | | | | | | | | | | | (F3) MESSAGE | | | |<------------------| | | (F4) MESSAGE | | | |<------------------| | | | | | | | | | | | (F5) 202 Accepted | | | |------------------>| | | (F7) MESSAGE | | (F6) 202 Accepted | |<------------------| |------------------>| | | | | | | | | | (F8) 200 Ok | | | |------------------>| | | | | | | | | | | | | | | (F1) REGISTER sent from UA2 to Home Proxy (Registrar) REGISTER sip:registrar.nokia.com SIP/2.0 Via: SIP/2.0/UDP host2.somewhere.com;branch=z9hG4bKue73jhhdue From: sip:ua2@somewhere.com;tag=48er8fdjkcfnciue9843ifj To: sip:ua2@somewhere.com Call-Id: 3mkejdc9e9834judjd CSeq: 1 REGISTER Expires: 3600 Contact: Max-Forwards: 70 (F2) 200 Ok from Home proxy to UA2 SIP/2.0 200 Ok Via: SIP/2.0/UDP host2.somewhere.com;branch=z9hG4bKue73jhhdue From: sip:ua2@somewhere.com;tag=48er8fdjkcfnciue9843ifj To: sip:ua2@somewhere.com;tag=393k3lmn3n3934 Call-Id: 3mkejdc9e9834judjd CSeq: 1 REGISTER Contact: ,expires=3600 Max-Forwards: 70 (F3) Message sent from UA1 to UA2 with very large content Khartabil [Page 10] Internet Draft Congestion Safely and C-I July 2002 MESSAGE sip:ua2@nokia.com SIP/2.0 Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 70 Content-type: text/html Content-length: 20000 [Large Body] (F4) MESSAGE is directed by UA2's home proxy to CSS. Home proxy accepts to content-indirect MESSAGE sip:ua2@nokia.com SIP/2.0 Via: SIP/2.0/TCP homeproxy.nokia.com;branch=z9hG4bKewrlkjdfkjl Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Route: sip:css.nokia.com Max-Forwards: 69 Content-type: text/html Content-length: 20000 [Large Body] (F5) CCS returns a 202 Accepted SIP/2.0 202 Accepted Via: SIP/2.0/TCP homeproxy.nokia.com;branch=z9hG4bKewrlkjdfkjl Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com;tag=5nixucvzo3241bqewmn Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 70 (F6) Home proxy forwards response to UA1 SIP/2.0 202 Accepted Via: SIP/2.0/UDP host1.somewhere.com;branch=z9hG4bK346434r From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com;tag=5nixucvzo3241bqewmn Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 69 Khartabil [Page 11] Internet Draft Congestion Safely and C-I July 2002 (F7) CCS sends the content-indirected MESSAGE to UA2 with the URL MESSAGE sip:ua2@nokia.com SIP/2.0 Via: SIP/2.0/UDP css.nokia.com;branch=z9hG4bK342kj5klj43klndsm From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 70 Content-Type: message/external-body; access-type=URL; url="http://131.228.13.2/im/9207807c03d4a5e0e6907b0dc89c9067"; Content-Length: 32 Content-Type: text/html (F8) 200 Ok is returned by UA2 SIP/2.0 200 Ok Via: SIP/2.0/UDP css.nokia.com;branch=z9hG4bK342kj5klj43klndsm From: sip:ua1@somewhere.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua1@nokia.com;tag=dfjkla43kjl5ldskfj Contact: Call-Id: vjn86732nv4fgiofd CSeq: 1 MESSAGE Max-Forwards: 70 8.2 Receiving A NOTIFY With Large Contents, UAS Refuses To Handle Request This example assumes that a subscription has been established. It also assumes that UA2 has not registered a max-size limit and that the home proxy configured max-size is less than the size of the NOTIFY. UA2 CSS UA2 PS Home Proxy | | | | | | | (F1) NOTIFY | | | |<------------------| | | | | | (F2) NOTIFY | | | |<--------------------------------------| | | | | | | | (F3) 413 | | |-------------------------------------->| | | | | (F4) 413 | | | |------------------>| | | | | Khartabil [Page 12] Internet Draft Congestion Safely and C-I July 2002 (F1) NOTIFY sent from PS to UA2, via home proxy with very large content NOTIFY sip:ua2@host2.nokia.com SIP/2.0 Via: SIP/2.0/TCP ps.nokia.com;branch=z9hG4bK346434r From: sip:ps.nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua2@nokia.com;tag=eqwriuo423nf Call-Id: vjn86732nv4fgiofd CSeq: 2 NOTIFY Route: sip: homeproxy.nokia.com Max-Forwards: 70 Content-Type: application/cpim-pidf+xml Content-length: 20000 [Large Body] (F2) NOTIFY forwarded from home proxy to UA2 with very large content. Home proxy checked its max-size configuration and found that this message passes. NOTIFY sip:ua2@host2.nokia.com SIP/2.0 Via: SIP/2.0/TCP homeproxy.nokia.com;branch=z9hG4bKre78re89jfdkj Via: SIP/2.0/TCP ps.nokia.com;branch=z9hG4bK346434r From: sip:ps.nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua2@nokia.com;tag=eqwriuo423nf Call-Id: vjn86732nv4fgiofd CSeq: 2 NOTIFY Max-Forwards: 69 Content-Type: application/cpim-pidf+xml Content-length: 20000 [Large Body] (F3) UA2 refuses the request due to its large content and returns a 413 response SIP/2.0 413 Message Too Large Via: SIP/2.0/TCP homeproxy.nokia.com;branch=z9hG4bKre78re89jfdkj Via: SIP/2.0/TCP ps.nokia.com;branch=z9hG4bK346434r From: sip:ps.nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua2@nokia.com;tag=eqwriuo423nf Call-Id: vjn86732nv4fgiofd CSeq: 2 NOTIFY Max-size: 1300 Max-Forwards: 70 (F4) 413 passed by home proxy to PS. Home proxy did not content- indirect. SIP/2.0 413 Message Too Large Via: SIP/2.0/TCP ps.nokia.com;branch=z9hG4bK346434r From: sip:ps.nokia.com;tag=31jrlkejrq3kl3jkl879defje3 To: sip:ua2@nokia.com;tag=eqwriuo423nf Call-Id: vjn86732nv4fgiofd Khartabil [Page 13] Internet Draft Congestion Safely and C-I July 2002 CSeq: 2 NOTIFY Max-size: 1300 Max-Forwards: 69 9.0 IANA Considerations 10.0 Acknowledgements I would like to thank Jose Costa-Requena, Mikko Lonnfors, Pekka Pessi and Nokia for their comments and support. 11.0 References [1] J. Rosenberg, et al. ôSIP: Session Initiation Protocolö. RCF 326, Internet Engineering Task Force, June 2002. [2] B. Campbell et al. "SIP Extensions for Instant Messaging", draft-ietf-sip-message-05.txt. Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [3] S. Olson. "A Mechanism for Content Indirection is SIP Messages", draft-olson-sip-content-indirect-mech-00.txt. Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [4] D. Willis. "SIP Congestion Safety", draft-willis-sip- congestsafe-00.txt. Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [5] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. Authors' Addresses Hisham Khartabil Nokia P.O. Box 321 FIN-00045 NOKIA GROUP FINLAND Email: Hisham.Khartabil@nokia.com Tel: + 358 7180 76161 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. Khartabil [Page 14] Internet Draft Congestion Safely and C-I July 2002 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Khartabil [Page 15]