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: <sip:hisham.khartabil@host1.nokia.com;max-size=1300>
   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: <sip:hisham.khartabil@host1.nokia.com;transport=tcp;max-
   size=1300>
   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: <sip:ua2@host2.nokia.com;max-size=1300>
   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: <sip:ua1@host2.nokia.com;max-size=1300>,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: <sip:ua1@host1.nokia.com;max-size=1300>
   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: <sip:ua1@host1.nokia.com;max-size=1300>
   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: <sip:ua1@host1.nokia.com;max-size=1300>
   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: <sip:ua1@host1.nokia.com;max-size=1300>
   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]