SIP -- Session Initiation Protocol                             D. Willis
Working Group                                                B. Campbell
Internet-Draft                                          dynamicsoft Inc.
Expires: August 13, 2003                                    Feb April 12, 2004                                 October 13, 2003

   Session Initiation Protocol Extension to Assure Congestion Safety
                     draft-ietf-sip-congestsafe-01
                     draft-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 extension by 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.  Definition    Scope of Congestion Safety for SIP Work  . . . . . . . . . . .  3 . . . . . . . . . . . .  4

   4.    Assuring Transitive Congestion Safety Congestion-Managed  Transport with
         Require and Proxy-Require  . . .  4 . . . . . . . . . . . . . .  5

   5.  Responsible use of    New Behaviors at SIP over UDP Nodes . . . . . . . . . . . . . . .  4 . .  5
   5.1 Requirements For Use of SIP Over UDP   Behavior 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 UDP   Behavior at the Proxy  . . . . . . . . . . . . . . . . . . .  6
   5.3
   5.2.1 Proxy Rejects Request That Would Require UDP  Fragmentation Requiring Congestion  Management
         When Route with Congestion Management Not Available  . . . .  7
   5.4 Server
   5.2.2 Proxy Rejects Request Because Response Could Not Be Sent
       Safely Requiring 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 . . . . . . . . . . . . . . . . . . . . . . . 10  9

         Normative References . . . . . . . . . . . . . . . . . . . . . 11 10

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 10

         Intellectual Property and Copyright Statements . . . . . . . . 12 11

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 [4] 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
   not no 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 deprecate

   The fundamental problem with 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:
   1.  Defines what it means for a SIP node to be "congestion-safe".
   2.  Defines a mechanism whereby a congestion-safe UA may require that
       any proxy processing its requests be congestion safe.
   3.  Defines a it provides no feedback
   mechanism whereby a proxy may reject to allow a request that it
       would be forced sender to fragment, and in so doing inform pace its transmissions against the
       originating UA
   real 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 if the request itself was not received in a
       congestion-safe manner.

3. Definition network. While this tends to have no
   significant effect on extremely low-volume sender-receiver pairs, the
   impact of Congestion Safety for SIP

   A SIP node high-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 of severe.
   Consider the following criteria is met:

   1.  The transport toward the next SIP hop is TCP, SCTP, or other
       transport providing congestion control and scenario, wherein the next hop traffic 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 [4], 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 through funnelled 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&lt-->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&lt-->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&lt-->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 propose be 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-controlled require congestion-managed
       transport to talk to proxies, and when that proxy finds that the only fall back route it has to UDP when the
       next hop is a UA.  The primary problem with this approach is over transport that in
   general, a SIP node does 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 is proxy may reject requests that would be fragmented, even if the next hop is for
       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 still would result from the incautious use of UDP.

5.1 Requirements For Use of SIP Over UDP

   The previously described problems with in responses that
       require congestion-managed transport if the general use of originating request
       did not require congestion-managed transport.

   Note that SIP over
   UDP lead to the following two requirements for the use of UDP as has no fundamental mechanism whereby a
   transport protocol for SIP:
   1.  Large messages MUST NOT be transmitted over UDP.  The SIP
       specification provides basic guidance proxy 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 requests
   responses being processed by a proxy except as
       described under provided by the heading "Pacing SIP requests over UDP."

   Response messages SHOULD be constrained
   original request. If, due to be smaller than an issue of network topology change or
   similar event between the MTUs
   established for requests by processing of the preceding mechanisms, request and systems
   implementors should remain aware that SIP provides limited support
   for managing the
   processing of the response sizes.  Further experience may indicate by a need
   for further control over response handling.

5.2 Pacing SIP Requests Over UDP

   One simple way proxy the only path available to describe the congestion problem
   proxy is that UDP lets us
   send packets without knowing whether those packets are arriving.  The
   simplest approach to dealing with this at not congestion managed, the application level is proxy has no choice but to send a request, then wait for some sort of
   the response indicating over that
   the request was received before sending anything else.  This produces
   an effect described by some as "ping-ponging" -- traffic bounces back path. 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 like
   Proxy-Require

   SIP provides mechanisms whereby a ping-pong ball or tennis ball in user agent making a
   match.  Since there's only one ball in play between any two players
   at request can be
   assured that any given time, most proxy 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 potential UAC includes a "Proxy-Require" header field with a
   value indicating a tag for congestion cascades is
   eliminated.

   This pacing the specific extension or behavior
   required. As per [4], proxies not recognizing a specific tag or serialization approach
   unwilling to support the associated behavior reject a request
   referencing that tag with a 420 response, which has the side-effect of
   significantly reducing semantic "Bad
   Extension".

   To be assured that a UAS responding to a request meets the maximum throughput, as transmission occurs
   in only one direction at
   requirements, 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
   inappropriate value
   indicating a tag for the specific extension or behavior required. As
   per [4], UASs not recognizing a specific tag or unwilling to duplicate that work here.  Consequently, if greater
   efficiency is required than support
   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, and tag with a
   420 response, which has the semantic "Bad Extension".

   We herein define a an option-tag value of "congestion-managed".
   There is reasonably
   efficient an IANA registration process for these tags defined in [4],
   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 sorts this document fulfills the
   requirements of request transactions: "invite" and "non-invite"
   tranactions.  Invite transaction use the 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 include a "provisional
   response" between
   Proxy-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 although that behavior has been
   deprecated.

   Congestion-safe use of SIP over UDP requires waiting for some sort of
   response to a exercises this extension (i.e., contains the
   "congestion-managed" option tags), the UAC MUST transmit the request (or
   using a timeout, which has backoff properties)
   before sending another request to protocol that same destination.  A
   congestion-safe SIP node (UA or proxy) MUST NOT send supports congestion maangement.

   Any UA supporting this extension SHOULD exercise this extension on
   all initial requests.

5.1.2 Receiving a request 514 Response to a
   given next-hop if there is Request

   A 514 response (semantic "No available route with congestion
   management) indicates that an existing request to intermediate proxy found that destination
   which has its only
   vailable routes toward the required next hop did not received some sort of response.  The existing
   transaction MUST either receive support
   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 before trying a new request can be made
   different 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 effectively a Request

   A 515 response (semantic "Response requires congestion-safe proxies congestion management")
   indicates that the response generated by the UAS responding to act in a
   transaction-stateful manner on the
   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
   least 515 to a
   request may either retry the extent of tracking whether some sort of request is
   pending in a congestion-managed manner
   (adding the "congestion-managed" option tag to each next-hop and correlating provisional Require and final
   responses to that
   Proxy-Require)) or abandon the request.

   Some may argue

5.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 onto a proxy forwarding the SIP node,
   and that implementations request
   detected that are "congestion-safe" per this
   specification will have reduced performance when used with UDP over a
   shared or public network.  We counter the 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
   assuring the transport protocol toward that they do next hop does
   not impede support congestion management. A UAS receiving a 516 response may
   retry the function of other users of request with a "Proxy-Require: congestion-management" added
   (which will probably return a 514), retry the
   network, even at request 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.3 Proxy Rejects Request That Would Require UDP  Fragmentation

   A proxy may be faced with forwarding a request to deliver containing a large message Proxy-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 general a bad practice transport protocol (such as
   TCP) supporting congestion-management. All proxies SHOULD attempt to send large
   requests over UDP.

   While
   reduce fragmentation following the actual MTU of procedure 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 indicate SIP proxy processing a request marked with a Proxy-Require
   header field containing the value "congestion-managed" determines
   that the local interface MTU next hop is likely to be reachable only via a
   reasonable approximation.  Where transport 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-safe SIP 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 reached reachable only
   via UDP, a transport protocol not supporting congestion management (such
   as UDP) and that the size of the request is larger than the effective MTU toward of the
   interface towards that hop and would consequently be
   fragmented, next hop, the proxy MUST reject that request
   with a 513 516 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 two

5.2.3 Forwarding of Responses

   When any proxy supporting this extension header fields that may be used in forwards a 513 request or
   response to indicate by the rejecting proxy the size and there is a choice of message
   allowed by that proxy.  The extension header field "Proxy-Max-Size"
   may be used to indicate transport protocols toward the largest allowable request to next
   hop, the
   originating UA.  The proxy 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 of with the rejected request option-tag "congestion-managed"
   as calculated by
   the rejecting proxy.  In both cases, a value and the size relevant Via header field value used indicates allows for a
   choice of transport protocols, the SIP message size, which does not include IP or proxy MUST select a transport protocol
   overhead.

   A congestion-safe
   supporting congestion management if such a transport is available.

   SIP provides no mechanism whereby a proxy which rejects may reject a request based on size
   SHOULD include response.
   Consequently, proxies may receive responses that require
   fragmentation over a "Proxy-Max-Size" header field with transport not supporting congestion management.
   One example of a value
   indicating the largest size message allowed by situation where this proxy on might be expected to occur is
   as follows: A UAC not supporting this
   link.  If extension 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 receiving in question without inducing
   fragmentation. The responding UAS generates a 513 response has that is larger
   than the options of giving up, trying a
   smaller request, or trying a different set of proxies.  Should it
   choose request. When the proxy prepares to try a smaller send the request, it may estimate the size of the
   largest message
   finds that can be sent by taking the original request size,
   subtracting it from the value of increase in size now requires fragmentation.
   Discarding the Proxy-Seen-Size header field,
   and subtracting that response would result from the value of the Proxy-max-Size
   header field.  Note that in a UA SHOULD NOT repeatedly downsize timeout and
   retry a request.  This technique is not an adequate replacement for
   TCP's Path MTU Discovery.  Any retransmission
   of the request that has been rejected and response, thereby doing more harm than once with a 513 SHOULD either good. There
   seems to be abandoned or re-issued over
   congestion-safe channels.

5.4 Server Rejects Request Because Response Could Not Be Sent Safely nothing that the proxy can do to correct the situation,
   so it MUST forward the response as specified in [4].

5.3 Behavior at the UAS

   A user agent server server (UAS) receiving a SIP request generates a resposne
   response 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 fields field values), the server has no options
   about routing the response. If the request was delivered in a
   congestion-safe
   congestion-managed manner, it can be safely assumed is likely that the response will also
   be returned in a congestion-safe congestion-managed manner, as it must traverse
   exactly this recorded route. However, if the request was NOT received
   in a congestion-safe congestion-managed manner, the server cannot negotiate a congestion-safe
   congestion-managed path for the response, as the response must follow
   the path of the request.

   If

   When a UAS supporting this extension responds to a request over a
   route supporting congestion management (as indicated by the size presence
   of the generated response is less than congestion-managed option tag in the size of request), the
   received request, it may be reasonably assumed that since UAS 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 size
   using a protocol supporting congestion management. If it is likely unable to
   traverse
   transmit the reverse of that path succesfully.  However, no such
   assumptions can be made about responses that are larger than response 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 server UAS supporting this extension generates a response to a
   request that is larger than the request UAS' 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.  Instead As the server MUST
   UAS 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 a requires congestion management". Note that this does not
   absolutely preclude fragmentation of the response, as the request may either retry
   be fragmented by intervening routers. However, this sort of
   fragmentation is outside of the
   request in a congestion-safe manner UAS' 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 fields option tags defined in [4].

   This document also defines 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 tags response codes defined in [4]. [4] in the section for 5xx
   clase response codes.

   This document also defines 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 [4] 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 [4] 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: none

      Option 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: none

      Response 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-safe

      Response 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 Sparks

   This document is a product of the SIP Working Group and Jonathan Rosenberg argued with us vociferously over contains
   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

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
        2223, October 1997.

   [4]  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.

   [5]  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: dean.willis@softarmor.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: bcampbell@dynamicsoft.com
   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.