Re: [reSIProcate] DUM SRV failover behavior
Why not just have the application retry the Invite if it receives a 503
error?
There is a method on the SipStack that may be useful for telling if a
record was blacklisted or not. See registerBlacklistListener. I
believe we only blacklist if there are more DNS results to try.
Scott
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Robert Sparks
> Sent: Friday, October 27, 2006 9:15 AM
> To: Jason Fischl
> Cc: resiprocate-devel
> Subject: 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
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel