> -----Original Message-----
> From: Shashidhara S G [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 19, 2001 1:12 AM
> To: Jonathan Lennox; Mayank Sharma
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] Sip Message with a large Message Body
>
>
> Hello,
> SIP messages can become bigger as they traverse the network. Assume a
> scenario in which a SIP request has to traverse some ten
> proxis and each one
> wants to be aware of later transactions(i.e., adds record
> route headers) and
> also via headers are added. So these headers certainly
> increase the size of
> the message, and eventually it may cross the MTU, in that
> case the proposed
> solution needs to be discussed.
> wbr
> Shashidhara S.G
> MindTree Consulting Pvt Ltd
> Bangalore
There are two solutions for this. The first, is that the proxy which adds
the extra data exceeding the MTU, must do some kind of local storage or
compression of headers in order to bring the message back down below the
MTU. Not very appealing.
The other alternative in this case is just grin and bear it. Let IP fragment
the packet. The primary problem with fragmentation is the loss amplification
effect (small packet loss rates get amplified, so that the apparent loss
rate is higher), which is not a major issue with 2 packets. The other
problem with fragmentation is that fragments can't traverse most NATs,
specifically NAPTs. This shouldn't be a problem, since you really need to be
running SIP over TCP for NAT traversal, and there is no need for
fragmentation over TCP.
Regarding the issue of message length in general, if we want to continue to
use UDP, we really need to work hard to keep those message lengths below
1500 bytes (specifically, 1280 appears to be the recommended number). We may
need to develop additional guidelines on things like Via and record-route
usage to prevent very large messages. We've already specified the Call-INFO
and ALert-Info headers as mechanisms to include content via URLs rather than
directly, and I think thats a really good idea in general.
Mayank Sharma writes:
> > In general, I don't think that fragmenting SIP messages is a
> > good idea --
> > you really shouldn't be sending messages larger than the IP
> > fragmentation
> > minimum in general. If you need to send that much information, use
>
> Are'nt we puting some restrictions on sip by saying this ?
Yes. SIP puts lots of restrictions on things. Thats what protocols do.
> > external URLs and HTTP, so the client can download it or not
> > as they wish.
> > (I'd really rather have a *choice* as to whether my mobile
> > phone downloads
> > your 200MB TIFF showing who's calling...)
>
> so you wuld'nt download the TIFF on your mobile, but what if
> your sip phone
> is on your computer ^physically^ connected to the internet
> with reasonable
> bandwidth. You wuld'nt mind downloading the TIFF. Sip
> protocol has to cater
> to the needs of everyone right.
Exactly correct. So, your PC would download the tiff. This is why URLs are
nice. If you have the bandwidth and UI to download them, do it. Otherwise,
don't. Its maximally flexible.
>
> > That said, if you must do this, there's already a MIME type
> > defined for
> > fragmented messages -- message/partial. (I believe it was
> > designed for
> > posting large binaries to Usenet, back when there was a
> > maximum message
> > size.) See RFC 2046.
>
> I don't think i follow u clearly here... can u please explain in a bit
> detail.
>
rfc2046 defines this mime subtype and explains its use. Please read section
5.2.2 that defines this.
I think this is a bad route to take, and I don't think it works for SIP
anyway. Unlike mail, where a relay could receive an incoming request and
send multiple outgoing requests, each with one part, we would need a way to
send multiple sip messages. It is not possible, for example, to send an
INVITE with one half the body, and another with the other half. We don't
support overlapping INVITEs.
Plus, with partial, you need to copy the headers in each message. So, if the
SIP headers are what is causing the message to exceed MTU, it doesn't help.
-Jonathan R.
---
Jonathan D. Rosenberg 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
