Subject: [SIP] Session Information

From: [email-masked]
Date: Tue, 10 Oct 2000 09:58:50 +0300

>> sk> The maximum size of the SIP message , including the 
>> content data MUST
>> be within
>> sk> the bounds of 1500 bytes, inorder to prevent 
>> fragmentation of packets.
>> Please
>> sk> refer Section 3, of the August 6, SIP draft.
>> 
>> 
>> No, that is not true, The draft mentions that it as a SHOULD 
>> and I think
>> that is hardly
>> true now. Even 'typical' SIP messages cross well over 2000 bytes,
>> especially with all these
>> new extensions chipping into the message.
>
>Correct. In fact, I think this 1500 limit needs to be qualified or changed.
>
>> 
>> Afaik, there is no MUST limit (maybe except the max size 
>> allocated to a n/w
>> read kernel buffer - usually 64k ? )
>
>Maximum IP packed size is 64K, so this represents the absolute upper bound
>on a SIP message.

True for UDP, but in SIP over TCP there isn't 64k limitation.
This max size definition should be dropped from the spec (or kept as a
SHOULD), 
since there are many situations in which TCP can be used 
end-to-end and the SIP message size may exceed 64k (or any other fixed
limit).

Or course, this is less friendly approach and may cause 
problems if used in some environments. 
Anyway, this should not be forbidden by the spec.

--
Petri

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Oct 2000 10:54:37 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2000 5:09 AM
> To: [email-masked]'
> Subject: RE: [SIP] Session Information
> 
> 
> 
> 
> 
> Some protocols do infact provide for a segmentation feature 
> which allows
> segmented messages to
> be sent, received and assembled. For example, some versions 
> of SS7  provide this
> at an ISUP
> level (which is similar to the level at which SIP is). So I 
> guess, if there is a
> real need to support
> messages above 64 K (now or in future) then the segmentation 
> facility should be
> provided in the
> protocol - independent of the transport (TCP/UDP). Ofcourse 
> this also requires
> the protocol to
> specify how to handle lost/duplicated segments and so on....

There is no need for such large messages. We are not seeing anything near
that size today. The discussion was motivated by the need to describe any
remote possible case in the spec.

Furthermore, adding segmentation at the app level to SIP would completely
break it right now, so there is no way we are doing that. Other fine
protocols like TCP do this already for us.

-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