Hi Jonathan,
Thanks for the reply.
But I am still not convinced with the last paragraph of your reply. I am
pasting it here again to help our discusssion
--------------------------------------------------------------------------
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.
----------------------------------------------------------------------------
The solution proposed does not mention about the overlapping of INVITEs.
It is some thing like this
INVITE sip:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:[EMAIL PROTECTED]>
To: LittleGuy <sip:[EMAIL PROTECTED]>
Call-ID: [EMAIL PROTECTED]
CSeq: 1 INVITE
Contact: BigGuy <sip:[EMAIL PROTECTED]>
Content-Type: application/sdp
Content-Length: 147
Message-Length: xxx <-------------- New Header
Message-ID: [EMAIL PROTECTED] <---------- New Header
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
Each proxy who is going to forward this message to down stream should
recalculate the message length and update this header field, in case if it
exceeds MTU then it should fragment the message into two packets, and put
part of the headers into the first packet which are with in the MTU and
second packet will contain the remaining part of the headers. Message-ID
should be copied into both the packets, so that it informs the down stream
that both the packets add up to give the same message. Message-Length may be
copied into both the packets for better clarity.
Assume that the down stream receives the packet1(first packet) it will check
the Message-Length header if it happens to be greater than MTU then it should
wait till it receives another packet with same Message-ID as the first one.
Once it receives both the packets then it can concatenate both of them and
handle the complete SIP message.
So we are not replicating the headers in both the packets, rather we are
distributing them. Please give your comments on this.
thanks and reagards
Shashidhara S.G.
MindTree Consulting Pvt Ltd
Bangalore
-----Original Message-----
From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 12:59 PM
To: Shashidhara S G; Jonathan Lennox; Mayank Sharma
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] Sip Message with a large Message Body
> -----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
