[reSIProcate] DnsResult blacklistLast,greylistLast question.

[Byron Campen]

On 12/30/13 10:24 AM, Sergey Pavlov wrote:
> On 28 December 2013 01:11, Byron Campen <docfaraday at gmail.com 
> <mailto:docfaraday at gmail.com>> wrote:
>
>     On 12/27/13 3:48 AM, Sergey Pavlov wrote:
>>     Am I understand correctly that in such case UDP transport will
>>     not be grey-listed in case of failure a transaction failure? I.e.
>>     failed transaction will not influence on other signaling with
>>     corresponding IP.
>        It would be greylisted if there is a timeout, but because there
>     are no alternatives, it would continue to be used.
>
>
> In such case it is ok. BTW I am not sure about exact scenario but as I 
> know currently the stack generates '480 Transport failure: no 
> transports left to try'  in case when there are no alternatives.
>
     That happens when stuff is blacklisted only, I think.

>
>>     In our case we will be  satisfied even with second option. 
>>     Indeed, greylisting can be really useful for results obtained
>>     from DNS lookup. But I think that ability to disable greylisting
>>     completely (or according to some predefined list) still should
>>     provided. In fact we have two conditions which may cause
>>     unanswered requests on UAS side:
>>     1) bug in SIP stack implementation  which is triggered by some
>>     specific requests;
>>     2) remote UA  overloaded, completely down or unreachable because
>>     of hardware or network malfunction.
>>
>>     Greylisting is good strategy for case (2) but can be real pain
>>     for case (1) even with results of real DNS lookups. Just imagine
>>     the case when all DNS records points to devices with the same SIP
>>     stack implementation  thus all of them can be greylisted by
>>     specific SIP request. Since there is no efficient method to
>>     distinguish (1) and (2) from UAC point of view it would be good
>>     to provide some means to control greylisting strategy for
>>     resipprocate stack user.
>        I am ok with allowing greylisting to be disabled entirely. It
>     is already a last-ditch measure; if you're observing actual
>     timeouts in the field, things are pretty bad. One thing that might
>     make sense to do is to only greylist after the tuple fails to
>     respond to a stand-alone OPTIONS request (ie; we see a transaction
>     timeout, and then send a quick OPTIONS request to test whether
>     this was a problem specific to the transaction/dialog; if that
>     OPTIONS request times out too, we greylist, or maybe even blacklist).
>
>
> Yep, it makes sense but it seems this part with additional checking is 
> completely up to you. My main goal was to understand - is there 
> something wrong from our side (e.g. incorrect resiprocate usage) or we 
> just faced with the issue when the existing mechanism (greylisting) 
> simply doesn't work well. Anyway, things are looks pretty clear 
> now.The question is - can you develop required functionality? We may 
> try to do it by ourselves but I doubt that our knowledge of stack 
> internals is good enough for proper implementation.
>

     For making greylisting configurable, it should be really easy I 
think; just wrap the greylistLast() call (and add the appropriate 
configuration call) and you should be good to go. Controlling the 
handling of sip:<bar-ip-address> should not be too hard, primarily 
finding where to add the check I think. I can look into it tonight.

Best regards,
Byron Campen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20131230/0a1b8a99/attachment.htm>