[reSIProcate] DnsResult blacklistLast,greylistLast question.

Sergey Pavlov sergey.pavlov at gmail.com
Fri Dec 27 05:48:28 CST 2013


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


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

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


More information about the resiprocate-devel mailing list