maybe a long taking TCP handshake? maybe accounting with slow accounting backend (database, radius server)?

Bodin Bruno wrote:

Klaus Darilion a écrit :

...

Maybe a long taking DNS lookup?

Bodin Bruno wrote:

...

Hi, I don't now why, but when call is cancel or unavaible t_relay is endless and never return anything. anyone know why ?

Thank

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

This is with a simple IP address no DNS :(

Hi Bodin,

that's because of the blacklists - openser "learns" the failed destinations (like the 503 replied) and block them for some time (4 minutes) to prevent useless processing.

You can disable this auto-learning for blacklists: disable_dns_blacklist=yes

regards, bogdan

Bodin Bruno wrote:

I found a part of problem. it's a call to a IPBX When there is an unavailability of number then I get this from IPBX : 503 Service Unavailable

That seem to work correctly. But when I recall a number to this IPBX (same or another number ), openser don't try to call IPBX and only send it to user : 473 Filtered destination (473/TM)

thank for your light

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

I agree

Henning Westerholt wrote:

On Donnerstag, 24. Mai 2007, Bogdan-Andrei Iancu wrote:

...

Hi Bodin,

that's because of the blacklists - openser "learns" the failed destinations (like the 503 replied) and block them for some time (4 minutes) to prevent useless processing.

You can disable this auto-learning for blacklists: disable_dns_blacklist=yes

To warm-up an old discussion about this feature:

i think this should be really disabled by default, because of user confusion and possible security issues.

Cheers,

Henning

Bogdan-Andrei Iancu a écrit :

Henning Westerholt wrote:

...

On Donnerstag, 24. Mai 2007, Bogdan-Andrei Iancu wrote:

...

Hi Bodin,

that's because of the blacklists - openser "learns" the failed destinations (like the 503 replied) and block them for some time (4 minutes) to prevent useless processing.

You can disable this auto-learning for blacklists: disable_dns_blacklist=yes

To warm-up an old discussion about this feature:

i think this should be really disabled by default, because of user confusion and possible security issues.

I agree it confuses a bit (maybe because of the lack of docs), but other other hand it is useful as it spears a lot of resources without any deep knowledge from the user. Anyhow, what security issues do you see here?

regards, bogdan

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

but is it possible to make a white list to counter black list and keep this feature ?

On Donnerstag, 24. Mai 2007, you wrote:

...

To warm-up an old discussion about this feature:

i think this should be really disabled by default, because of user confusion and possible security issues.

I agree it confuses a bit (maybe because of the lack of docs), but other other hand it is useful as it spears a lot of resources without any deep knowledge from the user. Anyhow, what security issues do you see here?

Haven't look deeper into the code, but if somebody spoof some 503 packets to the server (easy with UDP), then he could easily disable all outbound destinations.

Henning

On Donnerstag, 24. Mai 2007, you wrote:

...

...

I agree it confuses a bit (maybe because of the lack of docs), but other other hand it is useful as it spears a lot of resources without any deep knowledge from the user. Anyhow, what security issues do you see here?

Haven't look deeper into the code, but if somebody spoof some 503 packets to the server (easy with UDP), then he could easily disable all outbound destinations.

Well...I think this not something specific to blacklists, but to all features/functionalities (like faking byes/replies to close or prevent dialogs, etc ) :)

Sure, you're right. But inherent security issues from the protocol are more understandable and manageable then the automagically disabling of connections.

It in my opionion not the right thing to simply disable connections for several minutes after one problem occured, especially in a production environment.

The documentation in the wiki talks only about dns based blacklisting. Causes '503s' now also a blacklist entry? Then the documentation should be updated. :-)

Another important thing :

that my SIP conversation :

User --------> OpenSER --------> Asterisk

User -INVITE-> OpenSER OpenSER-INVITE->Asterisk Asterisk -Trying-> OpenSER Asterisk -Session progress-> OpenSER OpenSER -Session progress-> User Asterisk -service unavailable-> OpenSER OpenSER-ACK->Asterisk OpenSER -service unavailable-> User User -ACK-> OpenSER

My endless t_relay is this ACK user to openser.