[reSIProcate] DUM SRV failover behavior

[Jason Fischl]

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 at gmail.com> 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 at counterpath.com> wrote:
> > Not at this time.
> >
> > On 10/26/06, Shaun Dawson <scdawson at gmail.com> 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 at counterpath.com> 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 at gmail.com> 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 at counterpath.com> 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 at gmail.com> 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 at list.sipfoundry.org
> > > > > > > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>