RE: [Sip] I-D on handling large UDP responses

["Samir Srivastava" <samirsr at nortel.com>]

Hi Scott,

Sorry for the delayed response. In line.

Thx
Samir

>-----Original Message-----
>From: Scott Lawrence [mailto:slawrence at pingtel.com] 
>Sent: Wednesday, October 18, 2006 6:45 AM
>To: Srivastava, Samir (SC100:8826)
>Cc: sip at ietf.org
>Subject: RE: [Sip] I-D on handling large UDP responses
>
>On Mon, 2006-10-16 at 03:25 -0500, Samir Srivastava wrote:
>
>> The proposed mechanism can be used only for REQ/RSP. How can we 
>> address the problems caused in 200 OK (Offer) and ACK 
>(Answer) due to 
>> UDP between some proxies ? In the current model,  UAC gets the 
>> complete Large 200 OK (with delayed arrival of 140/141 or you change 
>> the current solution w.r.t. 140/141), but ACK follows the 
>different IP hops etc...
>
>Are you asking how this helps to detect a lost ACK?  If so, I 
>don't think that it does, but a lost ACK will cause the final 
>response to be resent, so you'll know anyway.  Eventually the 
>14x should arrive, providing a hint as to the possible 
>problem.  Besides, the only time the ACK is likely to be lost 
>due to UDP fragmentation is if it has the SDP answer and is 
>itself large, which the sender already knows.
>

Due to UDP hops etc in between, ACK can be lost... How can you enforce
ACK not to be lost. Then you can either add Proxy-Require in ACK.. But
This will contradict the 3261
Proxy-Require rule, as ACK should have the same Proxy-Require as that of
INVITE...
In my personal opinion, all this is complex.

Additional Running code question, how many states it will introduce to
all ready complex state m/c's (170, If I remember correctly are already
there with complete PRACK, UPDATE etc... )


>> We might be doing congestion handling in SIP for UDP transports in 
>> future, where some of it is provided by other transports. In 
>my purist 
>> mind, SIP messages are becoming huge, so UDP is no more 
>relevant. UDP 
>> was taken initially, as it was simple to transport short SIP message 
>> at that time.
>
>I'm hoping that providing better diagnostics that show how UDP 
>fails will cause end users to put pressure on vendors to 
>support TCP and/or TLS.

With Proxy-Require (tcp), providers using only UDP will start loosing
the revenue and will be forced to upgrade. My good wish :-)


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