Re: [reSIProcate] (another) blacklist issue on resip 1.1
Byron,
Thanks for the response -- we're somewhat reluctant to just comment out
those calls for fear of "throwing out the baby with the bathwater"
because our application will also talk to external SIP elements. So far,
it looks like we'd like to avoid blacklisting (or use much shorter
timeouts) for internal elements. I'll look at the "greylist" branch and
see if that helps.
Thanks again,
Tom Joyner
-----Original Message-----
From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Friday, April 06, 2007 10:32 AM
To: Tom Joyner
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] (another) blacklist issue on resip 1.1
I had meant to get around to making this blacklist duration
configurable, but I never had the time. There is some code in a
branch (branches/b-DNS_greylist) that should make this problem go
away entirely. You can do this by checking out the resiprocate-1.1
tag from svn, and invoking "svn merge -r 6982:HEAD http://
svn.resiprocate.org/rep/resiprocate/branches/b-DNS_greylist ." within
your checkout of resiprocate-1.1. Note that this code hasn't been
used a whole lot lately. Your other option is to just comment out the
lines in TransactionState.cxx where the 32s blacklisting calls are made.
Best regards,
Byron Campen
> Hi,
> We upgraded our application to use resiprocate 1.1 and some of our
> automated tests started failing. These were Session Timer tests that
> simulated a network failure by shutting down a SIP server in the
> middle
> of a call. The test failures occurred because after it was
> restarted the
> server was unavailable for 32s due to blacklisting (after a 408
> with no
> response). The error logged is this:
>
> 9171 | 3013118896 | DnsResult.cxx:384 | Numeric result, but this
> result
> is currently blacklisted: [ V4 192.168.20.88:25062 UDP target
> domain=192.168.20.88 connectionId=0 ]
>
>> From looking at the code and other posts related to blacklisting we
> (hopefully) understand why this is happening, and the tests can be
> fixed
> by adding a 32 second delay in a few places, but we're wondering if
> there are other side-effects. For instance, our application is a
> cluster
> of SIP servers (all based on resiprocate) that constantly exchange
> their
> state using multicast, so there may be cases where a
> failed-and-then-restarted server reports that it's available but is
> actually unreachable for up to 32 seconds. On the other hand, our
> application also talks to external servers whose status is unknown to
> us, so blacklisting might be useful in those cases.
>
> While we consider the pros and cons of this, I was wondering if there
> were any other options available in release 1.1, or any advice from
> someone that's more familiar with what's going on here.
> Regards,
> Tom Joyner
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel