[reSIProcate] DUM SRV failover behavior

[Robert Sparks]

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 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel