[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] MAJOR Open Issue #184: Message size limitations



At 7:18 pm +0200 28/12/01, Juha Heinanen wrote:
>  > anyone who is concerned with reliability or with Internet congestion
>  > should also prefer "MUST use TCP for packets larger than 1500" - it
>  > will be hard to convince the IESG that it is OK for the Internet
>  > to not have this a MUST
>
>scott,
>
>i'm wasting too much bandwidth on this, but my point att the time has
>been that someone already has convinced IESG not to have MUST there,
>because it is SHOULD in rfc2543.  in some other occasions people on this
>list have said that iesg requires the bis to be backwards compatible
>with rfc2543, but looks like we are now relaxed from that obligation.
>
>-- juha
>

Don't think so - the difference is that SIP has gained weight since then,
(look at the 3GPP flows in TS 24.228 :) and with SIMPLE, it also gains as
a source of congestion.

IMHO: In summary, SHOULD -> MUST (or use some sunny company's zero loss net :).

And that reminds me...[Flashes of "I told you so" on forehead]
1) There was some concern during PINT finalization that we would be forced to
implement UDP on PINT systems when our messages could be large (and we were
going to use TLS anyway). However, "mainstream" SIP messages would fit into
a single datagram, so we re-implemented to fit. Hey ho...

2) I -knew- there was a reason for SigComp - suggest that anyone who thinks
that they NEED a "standard" SIP message to exceed 1500 octets looks at the
ROHC work; you will end up implementing this sooner or later.

3) Seems to me that including attachments on IM traffic is a major cause of
BIG messages (i.e ones that even SigComp can't fix). We had similar problems
with PINT (see point 1), hence we allowed both "inline" and URL references to
content. If someone wants to include a MP3, why does this need to be inline
in the IM ? -- but that's another list. Reason for mentioning it here is that,
with New Year at hand and everyone promising to diet, we CAN solve the minor
bloat problems and still use UDP. For those cases (i.e. IM) where this won't
suffice, other solutions can be found (see point 2), or we can use TCP or SCTP.
No big deal, as long as we don't add even more poundage to the messages.

all the best,
   Lawrence

-- 
lwc@roke.co.uk: +44 1794 833666::<my opinions>:

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip