Re: [reSIProcate] DUM SRV failover behavior
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
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>