SIP H. Khartabil
Internet Draft Nokia
Expires: April 23, 2003 October 24, 2002
Congestion safety and Content Indirection
draft-khartabil-sip-congestionsafe-ci-01.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 April 23, 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 Safety and C-I October 2002
Table of Contents
1.0 Terminology...................................................3
2.0 Introduction..................................................3
3.0 Overview of Operation.........................................3
4.0 UA Behaviour..................................................4
4.1 UA Registering Desired Maximum SIP Message Size...............4
4.2 UAS Receiving A SIP Message With Large Contents...............5
4.3 UAC Assuring Congestion Safe SIP Request Path.................6
4.4 UAC Behaviour when receiving a ô413ö or ô513ö Error Response..6
5.0 Home Proxy Behaviour..........................................6
5.1 Congestion Safe Home Proxy....................................6
5.2 Home Proxy Receiving A SIP Message With Large Content.........7
5.3 Home Proxy Refusing To Handle Large SIP Requests..............8
5.4 Home Proxy Performing Content Indirection.....................9
5.5 Home Proxy Receiving ô413ö Response from UA...................9
6.0 Content Storage Server (CSS) Behaviour.......................10
7.0 Syntax for Extensions........................................10
7.1 Max-Size Header..............................................10
7.2 Max-size parameter...........................................10
8.0 Security considerations......................................10
9.0 Examples.....................................................11
9.1 Receiving A MESSAGE With Large Contents after a REGISTER, Home
Proxy Performs Content-Indirection...............................11
8.2 Receiving A NOTIFY With Large Contents, UAS Refuses To Handle
Request..........................................................14
10.0 IANA Considerations.........................................15
11.0 Acknowledgements............................................15
12.0 References..................................................15
Khartabil [Page 2]
Internet Draft Congestion Safety and C-I October 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 3]
Internet Draft Congestion Safety and C-I October 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 4]
Internet Draft Congestion Safety and C-I October 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 5]
Internet Draft Congestion Safety and C-I October 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 6]
Internet Draft Congestion Safety and C-I October 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 7]
Internet Draft Congestion Safety and C-I October 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 8]
Internet Draft Congestion Safety and C-I October 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 9]
Internet Draft Congestion Safety and C-I October 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. 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 Security considerations
The presence of Max-size header in a SIP message has a significant
effect on the ways in which the request is handled at a server. As a
result, it is especially important that messages containing this
extension be authenticated. The same holds true for registrations
with contact parameters.
Khartabil [Page 10]
Internet Draft Congestion Safety and C-I October 2002
Processing of requests and looking up criteria for message size
requires set operations and searches, which can require some amount
of computation. This enables a DOS attack whereby a user can send
requests with substantial numbers messages with large contents, in
the hopes of overloading the server. To counter this, the server
SHOULD authenticate the sender.
REGISTER requests can reveal sensitive information about a UAÆs
capabilities. If this information is sensitive, it SHOULD be
encrypted using SIP S/MIME capabilities.
Open issue: End-to-end Encryption. Does this introduce any open
issues if the whole body is stored in the CSS including the signed
and encrypted parts? How does the UA trust the CSS?
9.0 Examples
9.1 Receiving A MESSAGE With Large Contents after a REGISTER, Home
Proxy Performs Content-Indirection
UA2 CSS UA2 UA1
Home
Proxy
| | | |
| | | |
| (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)
Khartabil [Page 11]
Internet Draft Congestion Safety and C-I October 2002
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
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]
Khartabil [Page 12]
Internet Draft Congestion Safety and C-I October 2002
(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
(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
Khartabil [Page 13]
Internet Draft Congestion Safety and C-I October 2002
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 |
| | |------------------>|
| | | |
(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
Khartabil [Page 14]
Internet Draft Congestion Safety and C-I October 2002
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
CSeq: 2 NOTIFY
Max-size: 1300
Max-Forwards: 69
10.0 IANA Considerations
Once the header and parameter names have been agreed on, they will
be registered with IANA.
11.0 Acknowledgements
I would like to thank Jose Costa-Requena, Mikko Lonnfors, Pekka
Pessi and Nokia for their comments and support.
12.0 References
[1] J. Rosenberg, et al. ôSIP: Session Initiation Protocolö. RCF
3261, 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-ietf-sip-content-indirect-mech-00.txt. Internet Draft,
Internet Engineering Task Force, August 2002. Work in progress.
Khartabil [Page 15]
Internet Draft Congestion Safety and C-I October 2002
[4] D. Willis. "SIP Congestion Safety", draft-ietf-sip-congestsafe-
00.txt. Internet Draft, Internet Engineering Task Force, August
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.
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 16]