[reSIProcate] DnsResult blacklistLast,greylistLast question.

[Byron Campen]

On 12/27/13 3:48 AM, Sergey Pavlov wrote:
> On 26 December 2013 06:28, Byron Campen <docfaraday at gmail.com 
> <mailto:docfaraday at gmail.com>> wrote:
>
>         So that's the fallback behavior that is specified. In
>     practice, however, sending a bare IP address like that means that
>     UDP will be attempted first, and if that fails for some reason
>     (maybe a NAT is blocking UDP, for example), TCP will be attempted.
>     The specifications are pretty muddy when it comes to transport
>     failover, unfortunately. For sure, if a UA does not support TCP,
>     it should be including a transport param to that effect. Now, as
>     for solving your problem, I see a couple of approaches we could take;
>
>     1) Make greylisting configurable (enable/disable).
>
>     2) Make handling of sip:<bare-ip-addr> configurable (ie; is this a
>     UDP-only URI, or is TCP a possible second candidate?) This
>     basically boils down to disallowing multiple transport protocols
>     for anything other than an FQDN.
>
> 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.

>
>         Since both of these things are in grey areas of the
>     specifications, both are reasonable things to make configurable. I
>     like the second more, since it is more granular, and I am having a
>     hard time coming up with a reasonable scenario where you'd want to
>     disable greylisting for stuff you got from DNS. Your take?
>
>
> 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).

Best regards,
Byron Campen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20131227/667681a4/attachment.htm>