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

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

I have some additional initial comment 
 
What will you do when 140/141 is lost? PRACK ? 
As 141 is sent just before sending the final response , so cross over ?
Forking with 141/140 in one branch, should CANCEL come into picture?

Thx
Samir

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel at zonnet.nl]
> Sent: Tuesday, October 03, 2006 1:18 PM
> To: Vijay K. Gurbani; IETF SIP List
> Subject: Re: [Sip] I-D on handling large UDP responses
> 
> Three initial comments:
> 
> 1) I would expect the main source of large responses to be the UAS
sending
> a
> large response body. A transport switch does not necessarily imply
that a
> large response will follow, in general I think those 140 responses
will
> often be a waste of bandwidth. You could instead consider sending it
just
> before the proxy is about to forward a response >MTU (1500 if unknown)
> over
> UDP, and then preferrably only when no 140/141 response from some
> downstream
> node was forwarded already (only possible to detect this for stateful
> proxies).
> 
> 2) The current draft can result in cases where both a 140 and a 141
> response
> are sent, this seems wasteful. When the UAS sends a response >1500
bytes
> over non-UDP, it does not necessarily imply that there will be a
response
>  >1500 bytes using UDP at some point. So if the proxy forwarding rule
is
> changed per (1)above, the UAS should only send a 141 when it is
sending
> over
> UDP itself (i.e. no inspection of the via chain needed). If there is a
> transition to UDP in the path beyond, a proxy will send 140 instead.
This
> avoids duplicate 140/141 responses
> 
> 3) Given the above, it could probably be done with only 1 response
code.
> Proxies should then set the to-tag to the to-tag of the large response
> 
> Regards,
> 
> Jeroen
> 
> ----- Original Message -----
> From: "Vijay K. Gurbani" <vkg at lucent.com>
> To: "IETF SIP List" <sip at ietf.org>
> Sent: Tuesday, October 03, 2006 8:45 PM
> Subject: [Sip] I-D on handling large UDP responses
> 
> 
> > Folks: An I-D on handling large UDP response has just been
> > submitted to the I-D editor.  Until it appears in the archives, a
> > copy can be obtained from:
> >
> > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-
> response/draft-gurbani-sip-large-udp-response-00.txt
> > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-
> response/draft-gurbani-sip-large-udp-response-00.html
> >
> > The draft suggests the use of 1xx-class responses to solve this
> > problem.
> >
> > Please look at the draft and provide comments and/or concerns.
> >
> > Thank you.
> >
> > - vijay
> > --
> > Vijay K. Gurbani  vkg at {lucent.com,research.bell-labs.com,acm.org}
> > Bell Laboratories, Lucent Technologies, Inc.
> > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> >
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> 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

_______________________________________________
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