< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] DUM SRV failover behavior


There are two things here.

1) Trying to make this transaction fail over.
2) Trying to make the _next_ transaction not use the failed RR for this one.

Jason's answering towards 1), and there's more to it than the timer he talks about below.

What we're talking about with 1) is essentially sequential forking at the UAC. It's doable, but its more than a little code, and there's some subtlety to explore.
I've seen some other implementations doing this already.

For 2), there is some DNS Blacklisting that needs refinement (and there's still disagreement in the IETF WGs about exactly what the right behavior should be). The code right now attempts to deal with failover for subsequent transactions if there is a transport error (but I'm pretty sure it's not getting it right - I'm working on a test program). It also needs some work to correctly failover based
on 503/Retry-After.

RjS

On Oct 26, 2006, at 7:38 PM, Jason Fischl wrote:

The right approach would be set a shorter timer for failure in a UDP
transaction than 64*T1. It would be a configurable timer value that
would default to 64*T1.

On 10/26/06, Shaun Dawson <scdawson@xxxxxxxxx> wrote:
Ok.

Would either of these features make sense to add?  (I'd be the one
doing the adding).  If so, which one?

It seems to me that the way things are currently implemented, SRV is
more or less useless for UDP.

Shaun

On 10/26/06, Jason Fischl <jason@xxxxxxxxxxxxxxx> wrote:
Not at this time.

On 10/26/06, Shaun Dawson <scdawson@xxxxxxxxx> wrote:
So, is there any way to either
a) instruct the DUM to go ahead and fail over to the additional SRV
targets?  or
  b) know at the application level that there are additional SRV
targets to try so that it makes sense to retry the request?

Thanks!

Shaun

On 10/26/06, Jason Fischl <jason@xxxxxxxxxxxxxxx> wrote:
If you use UDP, it will take 32 seconds for the transaction to fail which will result in a 408 response being generated and sent up to the
TU. The next time you try this transaction, it will not use the A
record that previously failed.

On 10/26/06, Shaun Dawson <scdawson@xxxxxxxxx> wrote:
Jason, resiprocate devels,

Sorry to revive this issue, but there's something that I still don't
completely understand.

Does this mean that if I am willing to wait more than 32 seconds for an SRV failure in UDP, that DUM _will_ fail over? Or is that not the
case?

It seems that in my app, I am seeing the latter behavior, when I
would expect the former.

thanks!

Shaun

On 8/7/06, Jason Fischl <jason@xxxxxxxxxxxxxxx> wrote:
Under what circumstances are you trying to failover? If you are using udp and the first server is not responding at all, the timeout will
take 32 seconds to occur so you will never fail over.

If you use a connection-oriented protocol, you will get an ICMP error when you try to connect and it will immediately failover. It would
failover with UDP if the server sent an explicit error.

We've considered changing this behavior so that UDP would failover sooner but this would imply not waiting the full 64*T1 for a timeout. Note that the DNS caching and blacklisting will ensure that the failed
server is not retried on a subsequent transaction.

Jason




On 8/7/06, Shaun Dawson <scdawson@xxxxxxxxx> wrote:
All,

I've been having trouble getting the DUM to fail over to a secondary SIP proxy using SRV records. Before I get too crazy trying to to poke further into the problem, does anyone know that this expressedly does or does not
work?

 thanks,
   Shaun

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel








_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel