[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] I-D on handling large UDP responses
On Mon, 2006-10-16 at 17:37 -0400, Jonathan Rosenberg wrote:
> Thanks for startign on this problem, Vijay.
>
> I understand how the mechanism can diagnose the problem, but I don't see
> how it can fix it. In particular, when the UAC gets a 140 or 141, and
> then the transaction times out, the document says it should retry with
> congestion controlled transport. Well, that would work on the first hop.
> But nothing in the request would tell the proxy NOT to switch back to
> UDP. Unless you use sips, and thats assuming its implemented AND
> assuming its over TLS and all of that...
The retried request could be sent with a request URI that includes a url
parameter of 'transport=tcp'. That aught to cause intermediate hops to
try that first at least.
There are going to be cases, such as a proxy in the path that can only
do UDP, where it just won't be possible to make it work reliably. I
think that the most we can really achieve is a good diagnostic.
> Another problem with the mechanism you have proposed is the long delays
> involved in waiting for the transaction to timeout.
>
> You have discarded the 4xx case, and I think it has merit. You are
> correct that it may result in false positives - but so what?
I think that forcing a call to fail that might have succeeded is pretty
serious.
> There are
> no increases in call setup delays (to me, a worse result). And its
> reliable. It might help solve this problem above if the 4xx response
> contains a URI that reaches the resource that wanted to send the error
> response, but has a DNS entry only for TCP (like a TCP-only GRUU for a
> UAS). The client also retries with TCP. In the trapezoid model this
> would at least get you TCP all the way to the terminating proxy. In
> configurations with many more than that, you do still have the same
> problem of no way of explicitly requesting TCP. We can solve that with a
> Proxy-Require I suppose, though we're talking about a proxy upgrade at
> each hop.
--
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