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

From: "Samir Srivastava" <[email-masked]>
Date: Sat, 4 Nov 2006 01:16:06 -0600

Hi Scott,

Sorry for the delayed response. In line.

Thx
Samir

>-----Original Message-----
>From: Scott Lawrence [mailto:[email-masked]] 
>Sent: Wednesday, October 18, 2006 6:45 AM
>To: Srivastava, Samir (SC100:8826)
>Cc: [email-masked]
>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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 06 Nov 2006 06:40:11 -0800

> In my personal opinion, all this is complex.

That's because you're trying to make it solve problems it isn't meant to
solve (indeed - it is just meant to diagnose problems, not solve them).

> there with complete PRACK, UPDATE etc... )

The system sending the large response has no new states - it sends the
141 and forgets about it.  A system that receives a 140 or 141 could
decide to remember that fact and slow or reduce retries, or change
transports, but it's not required to do so.  

> the revenue and will be forced to upgrade. My good wish :-)

It doesn't work that way.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/