Subject: [Sip] draft-gurbani-sip-lrage-udp-response-00

From: Cullen Jennings <[email-masked]>
Date: Fri, 3 Nov 2006 18:25:44 -0800

One thing that really confused me about this draft was if seemed to  
use the term "congestion control" when what it actually meant "can  
deliver large packets". These seem to be two very separate things.

I think fragmentation reassembly actual does work thought most NATs.

The basic machoism seems broken. The advice that when a UAC gets a  
140 or 141 may later try with TCP does not make any sense to me. The  
UA might be able to use TCP to the first proxy but there is no way to  
tell that proxy to not use UDP to the next.

Since this approach does not work, on the topic of the other proposals

Section 4.1 - it seems this one fails in usual HERFP failure mode if  
one response is big and others are not. I think this problem should  
be mentioned.

Section 4.2 - I have no idea what you are talking about here. Can you  
explain how this option would work?

Section 4.3 - Here you send a single possible request and expect back  
a single response but if it forks you might get back the response  
plus *several* requests in reverse direction. The experience with  
early media has been three are a lot of complications with this. It  
might be the best approach but a generic description of it is pretty  
hard. I will point out this is exactly what we are doing on all the  
case where we do need large responses (i.e. SUB/NOT) so it might be  
that we basically already adopted this solution.

It was not clear to me who received the 140, what they did with it,  
or why they cared.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip