Subject: [SIP] RE: [Sip-implementors] Sip Message with a large Message Body

From: "Mayank Sharma" <[email-masked]>
Date: Mon, 19 Mar 2001 11:26:17 +0530

hi Lennox,

> 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 ?
I very much agree that we shuld'nt be sending messages larger than IP
fragmentation but in some case that just can't be helped.

> 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.

> 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.

Regards,
Mayank

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Shashidhara S G" <[email-masked]>
Date: Mon, 19 Mar 2001 11:41:40 +0530

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

-----Original Message-----
From: Jonathan Lennox [mailto:[email-masked]]
Sent: Monday, March 19, 2001 11:03 AM
To: Mayank Sharma
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip-implementors] Sip Message with a large Message Body

On Sunday, March 18 2001, "Mayank Sharma" wrote to
"<[email-masked]>, <[email-masked]>" saying:

> 	If the sip message to be sent is larger than the mtu provided by the
> lower layer packet, We can fragment the packet into a number of packets and
> send it across. We fragment the message in the following way. 

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
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...)

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.

-- 
Jonathan Lennox
[email-masked]
_______________________________________________
Sip-implementors mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Mar 2001 02:29:15 -0500

> From: Shashidhara S G [mailto:[email-masked]]
> Sent: Monday, March 19, 2001 1:12 AM
> To: Jonathan Lennox; Mayank Sharma
> Subject: RE: [Sip-implementors] Sip Message with a large Message Body
> 
> 
> Hello,

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.

> Are'nt we puting some restrictions on sip by saying this ?

Yes. SIP puts lots of restrictions on things. Thats what protocols do.

> 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.

> I don't think i follow u clearly here... can u please explain in a bit

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-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Shashidhara S G" <[email-masked]>
Date: Tue, 20 Mar 2001 18:12:36 +0530

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-masked] SIP/2.0
   Via: SIP/2.0/UDP here.com:5060
   From: BigGuy <sip:[email-masked]>
   To: LittleGuy <sip:[email-masked]>
   Call-ID: [email-masked]
   CSeq: 1 INVITE
   Contact: BigGuy <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: 147
   Message-Length: xxx	<-------------- New Header
   Message-ID: [email-masked] <---------- 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-masked]]
Sent: Tuesday, March 20, 2001 12:59 PM
To: Shashidhara S G; Jonathan Lennox; Mayank Sharma
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip-implementors] Sip Message with a large Message Body

-Jonathan R.

---