SIP -- Session Initiation Protocol D. Willis Working Group B. Campbell Internet-Draft dynamicsoft Inc. Expires:
August 13, 2003 FebApril 12, 2004 October 13, 2003 Session Initiation Protocol Extension to Assure Congestion Safety draft-ietf-sip-congestsafe-01draft-ietf-sip-congestsafe-02 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. This Internet-Draft will expire on August 13, 2003.April 12, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The Session Initiation Protocol allows the use of UDP for transport of SIP messages. The use of UDP inherently risks network congestion problems, as UDP itself does not define congestion prevention, avoidance, detection, or correction mechanisms. This problem is aggravated by large SIP messages which fragment at the UDP level. Transport protocols in SIP are also negotiated on a per-hop basis, at the SIP level, so SIP proxies may convert from TCP to UDP and so forth. This document defines what it means for SIP nodes to be congestion safe and specifies an extensionby which a SIP User Agent may require that its requests are treated in a congestion safe manner.not sent over UDP or other transports having congestion-related characteristics similar to those of UDP. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . .3 3. DefinitionScope of Congestion Safety for SIPWork . . . . . . . . . . . 3. . . . . . . . . . . . 4 4. Assuring Transitive Congestion SafetyCongestion-Managed Transport with Require and Proxy-Require . . . 4. . . . . . . . . . . . . . 5 5. Responsible use ofNew Behaviors at SIP over UDPNodes . . . . . . . . . . . . . . . 4. . 5 5.1 Requirements For Use of SIP Over UDPBehavior at the UAC . . . . . . . . . . . . . . . . . . . . 5 5.1.1 Sending a Request . . . . . . . . . . . . . . . . . . . . . 5 5.1.2 Receiving a 514 Response to a Request . . . . . . . . . . . 6 5.1.3 Receiving a 515 Response to a Request . . . . . . . . . . . 6 5.1.4 Receiving a 516 Response to a Request . . . . . . . . . . . 6 5.2 Pacing SIP Requests Over UDPBehavior at the Proxy . . . . . . . . . . . . . . . . . . . 6 188.8.131.52 Proxy Rejects Request That Would Require UDP FragmentationRequiring Congestion Management When Route with Congestion Management Not Available . . . . 7 5.4 Server5.2.2 Proxy Rejects Request Because Response CouldNot Be Sent SafelyRequiring Congestion Management When Forwarding That Request Would Induce Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 7 5.2.3 Forwarding of Responses . . . . . 9 6. Syntax of Extensions and Changes to SIP Specifications. . . . 9 7.. . . . . . . . . 7 5.3 Behavior at the UAS . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 109 Normative References . . . . . . . . . . . . . . . . . . . . . 1110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 1110 Intellectual Property and Copyright Statements . . . . . . . . 1211 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Background The Session Initiation Protocol RFC 3261 provides application support over multiple transport protocols, including UDP and TCP. Extensions to support SCTP are under consideration, and other transport protocols may be proposed for future use. Transport negotiation is not "end to end" with SIP. Instead, each SIP hop individually determines which transport to use.use towards the next hop. For example, a User Agent (UA)Client (UAC) may use TCP to talk to a proxy, that proxy my use UDP to talk to another proxy, and that second proxy may use SCTP to talk to a destination UA.User Agent Server (UAS). UDP has inherent issues with congestion management.management or reliability. The protocol has notno explicit mechanisms for avoiding, detecting, or adapting to network congestion. SIP attempts to deal with this in two ways: 1. Retransmission timers with exponential back offs. 2. Attempting to limit the size of transmissions over UDP to reduce the effects of fragmentation. This would appear to be an incomplete solution. One solution might be to deprecateThe fundamental problem with UDP entirely for SIP. However, thereis a large installed base using UDP, and there are legitimately places where UDP appears to be quite useful such as tiny mobile phones and in extremely high-volume proxies connecting over dedicated networks. As an alternative, this draft: 1. Defines what it means for a SIP node to be "congestion-safe". 2. Defines a mechanism whereby a congestion-safe UA may requirethat any proxy processing its requests be congestion safe. 3. Defines ait provides no feedback mechanism whereby a proxy may rejectto allow a request that it would be forcedsender to fragment, and in so doing informpace its transmissions against the originating UAreal performance of relevant sizing parameters. 4. Defines a mechanism whereby a server may reject requests that would result in responses that might not be transmitted congestion-safely ifthe request itself was not received in a congestion-safe manner. 3. Definitionnetwork. While this tends to have no significant effect on extremely low-volume sender-receiver pairs, the impact of Congestion Safety for SIP A SIP nodehigh-volume relationships on the network can be considered "congestion safe" if it never emits a request or response in a manner not known to be congestion safe. Requests may be considered congestion-safe if any one ofsevere. Consider the following criteria is met: 1. The transport toward the next SIP hop is TCP, SCTP, or other transport providing congestion control andscenario, wherein the next hoptraffic between multiple UAs is known to be either a UA or a congestion-safe proxy. 2. The transport toward the next hop is UDP, the next hop is known to be a UA or congestion-safe proxy, and the network between the two is known to support congestion management at a lower layer. Note that this is an uncomoon case in typical Internet applications. 3. If the only available transport toward the next hop is UDP and the next hop is known to be a UA or congestion-safe proxy, the request MAY be transmitted over UDP or rejected by local policy. If the request is transmitted over UDP, the procedures described under the heading "Responsible use of SIP over UDP" in this document MUST be followed. Responses may be considered congestion-safe if any one of the following criteria is met: 1. The request was congestion-safe, as defined above. 2. The response is no larger than the request. The preceding uses the phrase "the next hop is known to be either a UA or a congestion-safe proxy." Such knowledge may be derived either through administrative configuration or through use of the Proxy-Require mechanism defined herein under the heading "Assuring Transitive Congestion Safety with Proxy-Require". 4. Assuring Transitive Congestion Safety with Proxy-Require SIP provides a mechanism whereby a user agent making a request can be assured that any proxy servicing that request support a specific extension or set of behavior. To do so, the user agent includes a "Proxy-Require" header field with a value indicating a tag for the specific extension or behavior required. There is an IANA registration process for these tags. As per , proxies not recognizing a specific tag or unwilling to support the associated behavior reject a request referencing that tag with a 420 response, which has the semantic "Unsupported". We herein define a tag value of "congestion-safe". A proxy forwarding a request containing a Proxy-Require with this tag value MUST manifest the property of congestion-safety as defined by this document. 5. Responsible use of SIP over UDP The fundamental problem with UDP is that it provides no feedback mechanism to allow a sender to pace its transmissions against the real performance of the network. While this tends to have no significant effect on extremely low-volume sender-receiver pairs, the impact of high-volume relationships on the network can be severe. Consider the following scenario, wherein the traffic between multiple UAs is funnelled throughfunnelled through a single proxy-proxy relationship. Example of large-fan out/fan-in likely to encounter congestion: UA1----\ /----UA10 UA2-----\ /-----UA11 UA3------\ /------UA12 UA4-------\ /-------UA13 UA5--------P1------P2--------UA14 UA6-------/ \-------UA15 UA7------/ \------UA16 UA8-----/ \-----UA17 UA9----/ \----UA18 Figure 1 In this scenario, any requests from UA(1..9) to UA(10..18) traverse the proxy-proxy link P1<-->P2. Assuming current SIP practices, if this link is UDP and every UA emits a request simultaneously, each proxy will insert nine (one for each UA) requests, resulting in eighteen simultaneous requests on the P1<-->P2 link. Each request may require retransmissions, and large requests may require fragmentation to fit the link MTU -- at the worst case, producing more than one hundred packets per request, or approximately 2,000 simultaneously expressed packets in this scenario. If the capacity of link P1<-->P2 is inadequate to deliver these messages within the SIP retransmission window, the originating UAs (or the proxies, if acting in transaction-stateful mode) generate retransmissions, further compounding the problem into a "retransmission storm". Real-world scenarios may scale far more seriously. It is not unreasonable to assume that there may be tens of thousands of UAs on each side of the network. Clearly the best thing to do is to use a more sophisticated transport protocol (TCP, SCTP, etc.) between P1 and P2, and between each UA and its associated proxy. If this is not feasible, it may be necessary to fall back to UDP.It should be noted that the fundamental problem not just between UAs and proxies, but whenever there is a high fan-out or fan-in ratio. If in the above example, each UA were behind a "residential proxy", the problem would occur in similar fashion. 3. Scope of Work One solution might proposebe to deprecate UDP entirely for SIP. However, there is a large installed base using UDP, and there are legitimately places where UDP appears to be quite useful such as tiny mobile phones and in extremely high-volume proxies connecting over dedicated networks. As an alternative, this draft defines mechanisms whereby: 1. a UAC may require that any proxy processing its requests transmit those requests over a transport protocol providing congestion management. 2. a UAC may inform a UAS receiving its requests that those requests were transmitted over a route supporting congestion management, and require that that UAS respond in similar fashion. 3. A proxy may reject requests that SIP ALWAYS use a congestion-controlledrequire congestion-managed transport to talk to proxies, andwhen that proxy finds that the only fall backroute it has to UDP whenthe next hop is a UA. The primary problem with this approach isover transport that in general, a SIP nodedoes not and cannot know whether the next node is a UA or a proxy -- it is this ability to "insert" proxies into a sequence that provides much of the flexibility of SIP.support congestion management. 4. A secondary problem isproxy may reject requests that would be fragmented, even if the next hop isfor requests that do not indicate a UA, some UAs are sufficienty high volume, and some links sufficiently narrow,requirement for congestion-managed transport. 5. A UAS may reject requests that congestion might stillwould result from the incautious use of UDP. 5.1 Requirements For Use of SIP Over UDP The previously described problems within responses that require congestion-managed transport if the general use oforiginating request did not require congestion-managed transport. Note that SIP over UDP lead to the following two requirements for the use of UDP ashas no fundamental mechanism whereby a transport protocol for SIP: 1. Large messages MUST NOT be transmitted over UDP. The SIP specification provides basic guidanceproxy may reject a response. This precludes requiring congestion management for UAs. Congestion-safe proxies MUST follow the procedures described below under the heading "Proxy Rejects Request That Would Require UDP Fragmentation." UAs MAY also make use of the MTU feedback techniques in that section. 2. Nodes sending requests over UDP MUST pace those requestsresponses being processed by a proxy except as described underprovided by the heading "Pacing SIP requests over UDP." Response messages SHOULD be constrainedoriginal request. If, due to be smaller thanan issue of network topology change or similar event between the MTUs established for requests byprocessing of the preceding mechanisms,request and systems implementors should remain aware that SIP provides limited support for managingthe processing of the response sizes. Further experience may indicateby a need for further control over response handling. 5.2 Pacing SIP Requests Over UDP One simple wayproxy the only path available to describethe congestion problemproxy is that UDP lets us send packets without knowing whether those packets are arriving. The simplest approach to dealing with this atnot congestion managed, the application level isproxy has no choice but to send a request, then wait for some sort ofthe response indicatingover that the request was received before sending anything else. This produces an effect described by some as "ping-ponging" -- traffic bounces backpath. It's not perfect, but seems to be all we can do at this time. 4. Assuring Transitive Congestion-Managed Transport with Require and forth between two nodes likeProxy-Require SIP provides mechanisms whereby a ping-pong ball or tennis ball inuser agent making a match. Since there's only one ball in play between any two players atrequest can be assured that any given time, mostproxy servicing or UAS responding to that request support a specific extension or set of behavior. To be assured that a proxy servicing the request meets the requirements, the potentialUAC includes a "Proxy-Require" header field with a value indicating a tag for congestion cascades is eliminated. This pacingthe specific extension or behavior required. As per , proxies not recognizing a specific tag or serialization approachunwilling to support the associated behavior reject a request referencing that tag with a 420 response, which has the side-effect of significantly reducingsemantic "Bad Extension". To be assured that a UAS responding to a request meets the maximum throughput, as transmission occurs in only one direction atrequirements, the UAC includes a time and there is at least"Require" header field with a 2xRTT delay between transmissions. More sophisticated algorithms such as those in TCP and SCTP have been developed to address this, and it would be inappropriatevalue indicating a tag for the specific extension or behavior required. As per , UASs not recognizing a specific tag or unwilling to duplicate that work here. Consequently, if greater efficiency is required thansupport the associated behavior reject a request referencing that provided by this simple approach, implementors should use TCP, SCTP, or another such protocol. But if one absolutely must use UDP, this approach works, andtag with a 420 response, which has the semantic "Bad Extension". We herein define a an option-tag value of "congestion-managed". There is reasonably efficientan IANA registration process for these tags defined in , and the most likely application"IANA Considerations" of "edge proxy" to UA and other proxies with large fan-outs to individual low-volume nodes. SIP has two sortsthis document fulfills the requirements of request transactions: "invite" and "non-invite" tranactions. Invite transaction usethe IANA registration process. 5. New Behaviors at SIP Nodes 5.1 Behavior at the UAC 5.1.1 Sending a three way sequence of "request, response, acknowledgement"Request A UAC exercising this extension adds a Require header field and may includea "provisional response" betweenProxy-Require header field value including the option tag "congestion-managed" to each request. For any request and response steps. Non-invite transactions use a two-way "request, response" sequence, and may also have a provisional response althoughthat behavior has been deprecated. Congestion-safe use of SIP over UDP requires waiting for some sort of response to aexercises this extension (i.e., contains the "congestion-managed" option tags), the UAC MUST transmit the request (orusing a timeout, which has backoff properties) before sending another request toprotocol that same destination. A congestion-safe SIP node (UA or proxy) MUST NOT sendsupports congestion maangement. Any UA supporting this extension SHOULD exercise this extension on all initial requests. 5.1.2 Receiving a request514 Response to a given next-hop if there isRequest A 514 response (semantic "No available route with congestion management) indicates that an existing request tointermediate proxy found that destination which hasits only vailable routes toward the required next hop did not received some sort of response. The existing transaction MUST either receivesupport congestion management. A UA receiving a 514 response (final or provisional)has the options of giving up, trying the request without the "Proxy-Require: congestion-management" (which will likely return a 516) or time-out beforetrying a new request can be madedifferent set of proxies, presumably through using a different pre-loaded Route header field. 5.1.3 Receiving a 515 Response to that next-hop. This effectivelya Request A 515 response (semantic "Response requires congestion-safe proxiescongestion management") indicates that the response generated by the UAS responding to act in a transaction-stateful manner onthe request is larger than the UAS' understanding of path MTU and that the UAS does not know that the route indicated by the VIA headers is over congestion-managed transport. A UAC receiving a per-next-hop destination basis, at least515 to a request may either retry the extent of tracking whether some sort ofrequest is pendingin a congestion-managed manner (adding the "congestion-managed" option tag to each next-hop and correlating provisionalRequire and final responses to thatProxy-Require)) or abandon the request. Some may argue5.1.4 Receiving a 516 Response to a Request A 516 response (semantic "Proxying of request would induce fragmentation") indicates that this puts an excessive burden ontoa proxy forwarding the SIP node, and that implementationsrequest detected that are "congestion-safe" per this specification will have reduced performance when used with UDP over a shared or public network. We counterthe request was larger than the next hop link MTU from that congestion-safe transport protocols are readily available,proxy and that network users which insist on using unsafe transports (such as UDP) MUST be responsible for assuringthe transport protocol toward that they donext hop does not impedesupport congestion management. A UAS receiving a 516 response may retry the function of other users ofrequest with a "Proxy-Require: congestion-management" added (which will probably return a 514), retry the network, even atrequest using an alternate route, or abandon the expense of reducing their own efficiency. It is simply irresponsible to "blast away"request. 5.2 Behavior at the network without regard for congestion or its impact on other users of the network. 5.3Proxy Rejects Request That Would Require UDP FragmentationA proxy may be faced withforwarding a request to delivercontaining a large messageProxy-Require with this tag value MUST trasmit that request using UDP as a transport. Fragmentation of such messages is problematic in several ways. Loss of any fragment requires time-out and retransmission of the message. The fragments are commonly transmitted out the interface at local interface (usually LAN) rates, without awareness of intervening network conditions. For these reason, we believe it in generala bad practicetransport protocol (such as TCP) supporting congestion-management. All proxies SHOULD attempt to send large requests over UDP. Whilereduce fragmentation following the actual MTU ofprocedure described below. 5.2.1 Proxy Rejects Request Requiring Congestion Management When Route with Congestion Management Not Available When a link may not be known, common practice seems to indicateSIP proxy processing a request marked with a Proxy-Require header field containing the value "congestion-managed" determines that the local interface MTUnext hop is likely to bereachable only via a reasonable approximation. Wheretransport proocol not supporting congestion management (such as UDP) the actual path MTU is known,proxy MUST reject that value should be used instead.request with a 514 response. 5.2.2 Proxy Rejects Request Not Requiring Congestion Management When Forwarding That Request Would Induce Fragmentation When a congestion-safeSIP proxy supporting this extension and processing a request not marked with a Proxy-Require header field containing the value "congestion-managed" determines that the next hop is reachedreachable only via UDP,a transport protocol not supporting congestion management (such as UDP) and thatthe size of the request is larger than the effectiveMTU towardof the interface towards that hop and would consequently be fragmented,next hop, the proxy MUST reject that request with a 513516 response. The base SIP specification provides minimal guidance on dealing with oversized requests. There is an error response code, 513, with the semantic "request too large" that seems applicable. However, SIP provides no guidance on how to indicate what size might be allowed. We define here two5.2.3 Forwarding of Responses When any proxy supporting this extension header fields that may be used inforwards a 513request or response to indicate by the rejecting proxy the sizeand there is a choice of message allowed by that proxy. The extension header field "Proxy-Max-Size" may be used to indicatetransport protocols toward the largest allowable request tonext hop, the originating UA. Theproxy SHOULD choose a transport protocol supporting congestion management if one is available. When a proxy supporting this extension forwards a response containing a Proxy-Require header field "Proxy-Seen-Size" may be used to indicate the size ofwith the rejected requestoption-tag "congestion-managed" as calculated by the rejecting proxy. In both cases,a value and the sizerelevant Via header field value used indicatesallows for a choice of transport protocols, the SIP message size, which does not include IP orproxy MUST select a transport protocol overhead. A congestion-safesupporting congestion management if such a transport is available. SIP provides no mechanism whereby a proxy which rejectsmay reject a request based on size SHOULD includeresponse. Consequently, proxies may receive responses that require fragmentation over a "Proxy-Max-Size" header field withtransport not supporting congestion management. One example of a value indicating the largest size message allowed bysituation where this proxy onmight be expected to occur is as follows: A UAC not supporting this link. Ifextension makes a Proxy-Max-Size header field is sent,request via UDP. This request transits the proxy MUST also include a "Proxy-Seen-Size" header indicating the size of the request as seen at this proxy. A UA receivingin question without inducing fragmentation. The responding UAS generates a 513response hasthat is larger than the options of giving up, trying a smaller request, or trying a different set of proxies. Should it chooserequest. When the proxy prepares to try a smallersend the request, it may estimate the size of the largest messagefinds that can be sent by takingthe original request size, subtracting it from the value ofincrease in size now requires fragmentation. Discarding the Proxy-Seen-Size header field, and subtracting thatresponse would result from the value of the Proxy-max-Size header field. Note thatin a UA SHOULD NOT repeatedly downsizetimeout and retry a request. This technique is not an adequate replacement for TCP's Path MTU Discovery. Anyretransmission of the request that has been rejectedand response, thereby doing more harm than once with a 513 SHOULD eithergood. There seems to be abandoned or re-issued over congestion-safe channels. 5.4 Server Rejects Request Because Response Could Not Be Sent Safelynothing that the proxy can do to correct the situation, so it MUST forward the response as specified in . 5.3 Behavior at the UAS A user agent server server (UAS) receiving a SIP request generates a resposneresponse to that request. Delivery of this response may raise issues of congestion-safety.congestion management. Because SIP requires that responses traverse exactly the reverse of the route taken by the request (recorded in the Via: header fieldsfield values), the server has no options about routing the response. If the request was delivered in a congestion-safecongestion-managed manner, it can be safely assumedis likely that the response will also be returned in a congestion-safecongestion-managed manner, as it must traverse exactly this recorded route. However, if the request was NOT received in a congestion-safecongestion-managed manner, the server cannot negotiate a congestion-safecongestion-managed path for the response, as the response must follow the path of the request. IfWhen a UAS supporting this extension responds to a request over a route supporting congestion management (as indicated by the sizepresence of the generated response is less thancongestion-managed option tag in the size ofrequest), the received request, it may be reasonably assumed that sinceUAS MUST include the request arrived intact,congestion-managed option tag in a "Proxy-Require" header field in the response. Furthermore, it MUST transmit that response of equal or smaller sizeusing a protocol supporting congestion management. If it is likelyunable to traversetransmit the reverse of that path succesfully. However, no such assumptions can be made about responses that are larger thanresponse using a protocol supporting congestion management, it MUST reject the request and return an error response using response code 515, which has the corresponding request.semantic of "Response requires congestion management." When a congestion-safe serverUAS supporting this extension generates a response to a request that is larger than the requestUAS' understanding of path MTU and that request was not received over a congestion-safe channel,congestion-managed route (as indicated by the presence of a "Require: congestion-managed"), it cannot be assumed that the response can be safely transmitted. An unsafe response cannot be transmitted by a congestion-safe server. InsteadAs the server MUSTUAS cannot respond safely, it SHOULD reject the request and return an error response using response code 514,515, which has the semantic of "Response Could Not Be Sent Safely". A UA receiving a 514 response to arequires congestion management". Note that this does not absolutely preclude fragmentation of the response, as the request may either retrybe fragmented by intervening routers. However, this sort of fragmentation is outside of the request in a congestion-safe mannerUAS' capacity to detect or abandon the request.control. 6. Syntax of Extensions and Changes to SIP Specifications The syntax for the Proxy-Max-Size header field is: Proxy-Max-Size = "Proxy-Max-Size" HCOLON 1*DIGIT The syntax for the Proxy-Seen-Size header field is: Proxy-Seen-Size = "Proxy-Seen-Size" HCOLON 1*DIGIT 7.IANA Considerations This document defines the SIP extension header fields "Proxy-Max-Size" and "Proxy-Seen-Size" ",option tag "congestion-managed" which IANA will add to the registry of SIP header fieldsoption tags defined in . This document alsodefines the SIP option tag "congestion-safe"response code 514, with the semantic "No congestion-managed route available" which IANA will add to the registry of SIP option tagsresponse codes defined in . in the section for 5xx clase response codes. This document alsodefines the SIP response code 514,515, with the semantic "Response Cannot Be Sent Safely"requires congestion management" which IANA will add to the registry of SIP response codes defined in  in the section for 5xx clase response codes. This document defines the SIP response code 516, with the semantic "Proxying of request would induce fragmentation" which IANA will add to the registry of SIP response codes defined in  in the section for 5xx clase response codes. The following is the registration for the Proxy-Max-Size header field:congestion-managed option tag: RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of this specification.] Header Field Name: Proxy-Max-Size Compact Form: noneOption Tag: congestion-managed The following is the registration for the Proxy-Seen-Size header field:SIP response code 514: RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of this specification.] Header Field Name: Proxy-Seen-Size Compact Form: noneResponse Code: 514 No available route with congestion management The following is the registration for the congestion-safe option tag:SIP response code 515: RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of this specification.] Option Tag: congestion-safeResponse Code: 515 Response requires congestion management The following is the registration for the SIP response code 514:516: RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of this specification.] Response Code: 514 Response Cannot Be Sent Safely 8.516 Proxying of request would induce fragmentation 7. Acknowledgements Robert SparksThis document is a product of the SIP Working Group and Jonathan Rosenberg argued with us vociferously overcontains input from many contributors in that group. The named authors of this topic and contributed substantial insight.document claim no personal contribution to the content excecpt as provided in their capacity as participants in the working group. Rather, they have attempted to act only in an editorial fashion, documenting the consensus of the working group as it emerged. Somebody had to do the typing. Normative References  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. Authors' Addresses Dean Willis dynamicsoft Inc. 5100 Tennyson Parkway Suite 1200 Plano, TX 75028 US Phone: +1 972 473 5455 EMail: email@example.com URI: http://www.dynamicsoft.com/ Ben Campbell dynamicsoft Inc. 5100 Tennyson Parkway Suite 1200 Plano, TX 75028 US Phone: +1 972 473 5452 EMail: firstname.lastname@example.org URI: http://www.dynamicsoft.com/ Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. 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 assignees. 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.