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