[reSIProcate] DnsResult blacklistLast,greylistLast question.

[Sergey Pavlov]

On 28 December 2013 01:11, Byron Campen <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.



>
>
> 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.

--
Best regards,
Sergey Pavlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20131230/1ff8ee3b/attachment.htm>