24 May
2007
24 May
'07
5:37 a.m.
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
24 May
24 May
5:45 a.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6:25 a.m.
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(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
This is with a simple IP
address no DNS :(
8:26 a.m.
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(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
This is with a simple IP
address no DNS :(
9:20 a.m.
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
9:27 a.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
9:31 a.m.
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
9:40 a.m.
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
9:40 a.m.
Henning Westerholt wrote:
On Donnerstag, 24. Mai 2007, Bogdan-Andrei Iancu
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?
regards,
bogdan
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.
9:43 a.m.
Bogdan-Andrei Iancu a écrit :
Henning Westerholt wrote:
but is it possible to make a
white list to counter black list and keep
this feature ?
On Donnerstag, 24. Mai 2007, Bogdan-Andrei Iancu
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?
regards,
bogdan
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users 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.
9:52 a.m.
Bodin Bruno wrote:
Bogdan-Andrei Iancu a écrit :
no, unfortunately there is no such white list...
regards,
bogdan
Henning Westerholt wrote:
but is it possible to make a white list to counter black list and keep
this feature ?
On Donnerstag, 24. Mai 2007, Bogdan-Andrei Iancu
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?
regards,
bogdan
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.
9:49 a.m.
On Donnerstag, 24. Mai 2007, you wrote:
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
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?
10:17 a.m.
Henning Westerholt wrote:
On Donnerstag, 24. Mai 2007, you wrote:
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 ) :)
Regards,
Bogdan
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?
10:39 a.m.
On Donnerstag, 24. Mai 2007, you wrote:
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. :-)
--
Henning
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.
9:28 a.m.
thats probably the new blacklist feature in 1.2
regards
klaus
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
9:28 a.m.
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.
6427
days inactive
6427
days old
15 comments
4 participants
participants (4)
-
Bodin Bruno -
Bogdan-Andrei Iancu -
Henning Westerholt -
Klaus Darilion