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

[Scott Lawrence <slawrence at pingtel.com>]

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.

> 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.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:slawrence at pingtel.com
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.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 at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip