Hmmm, pardon my humble question, but why would you want to that, if
the UDP/IP can do it for you automagically? You can send up to (65535
- 8) bytes of UDP datagram. In terms of packet lost amplification,
there're the same. Well, with IP fragments, at least it's the OS that
handles that, not us, we're just mere mortals SIP coders.
--
cheers,
Bennylp
Shashidhara S G wrote:
>
> 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
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
