[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] MAJOR Open Issue #184: Message size limitations
Hi,
Just a small comment on point (1). A case where the response may be much
bigger than the request is when we send an INVITE without SDP, and
receive a 200 with SDP. Now, I am NOT saying this is a problem, and it
could probably also be classified as "in most cases it won't happen".
At least I can't remember when I would have seen it in a real-life
scenario. But, maybe people doing SIP/H.323 interworking have some info
on this?
Regards,
Christer Holmberg
Ericsson Finland
Jonathan Rosenberg wrote:
>
> I've been working through the various possibilities with Henning. Our
> conclusion is that any of these redirect-to-tcp mecahnisms are frought
> with problems.
>
> Therefore, the proposal is the following:
>
> 1. if the request is larger than some threshold (1000 or somehting), you
> MUST use TCP (after compression, of course). If the path MTU is known,
> you need to use TCP if the request is greater than that value - 300 or so.
>
> 2. It is RECOMMENDED to use TCP to communicate with a server when you
> know a NAT is in the way.
>
> Point (1) is based on the observation that in most cases, the response
> is not substanially larger than the request. This is certainly true for
> MESSAGE, BYE. It is not true for OPTIONS, admittedly, but those are not
> record-routed and the requests are also ususally small. The main item
> will be record-routes, which can be many hundreds of bytes. Therefore,
> we leave a bit of buffer space in the threshold to account for that.
> Thus, we should be OK. The second point ensures that, if fragmentation
> of the response does happen, there hopefully isn't a nat in the way,
> since that is the really bad case.
>
> A refinement on this is what will go into bis-06 unless someone has a
> really big beef with it.
>
> -Jonathan R.
>
> Henning G. Schulzrinne wrote:
>
> > Dorgham Sisalem wrote:
> >
> >>Hello,
> >> looking at all the complexity of 499 and UDP to TCP transition I am
> >> wondering if fragmentation is really worth the trouble. For the case
> >> of signaling I hardly imagine the messages will get big enough so as
> >> to worry about congestion due to retransmission (just because a SIP
> >>
> >
> > I think the congestion aspect deserves an additional sentence or two.
> > Effectively, SIP behaves like TCP with a window size of 1 segment and
> > only time-out based retransmission, i.e., the most conservative
> > operational mode of TCP. Depending on the RTT estimate, the SIP timers
> > will obviously differ, but their growth behavior is also similar.
> >
> > The main problem is that with fragmentation, SIP may fail completely if
> > various NATs and firewalls get in the way. That, in my view, is the
> > bigger issue.
> >
>
> --
> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue
> Chief Scientist First Floor
> dynamicsoft East Hanover, NJ 07936
> jdrosen@dynamicsoft.com FAX: (973) 952-5050
> http://www.jdrosen.net PH: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sip mailing list https://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
_______________________________________________
Sip mailing list https://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