28 May
2009
28 May
'09
8:23 p.m.
when i try to use my kamailio.cfg with sip-router, the first place where
it fails is this:
dns_try_ipv6=no
sip-router says that the config var is unknown.
sip-router core cookbook lists the variable, but does not say anything
about it.
is there a replacement or what should i do about it?
-- juha
28 May
28 May
10:01 p.m.
On May 28, 2009 at 20:23, Juha Heinanen <jh(a)tutpro.com> wrote:
when i try to use my kamailio.cfg with sip-router, the
first place where
it fails is this:
dns_try_ipv6=no
sip-router says that the config var is unknown.
That's strange. It works for me with and without USE_IPV6.
sip-router core cookbook lists the variable, but does not say anything
about it.
is there a replacement or what should i do about it?
It should work as it is. Are you sure you haven't mispelled it somehow?
Could you send me the output of ser -cf your.cfg ?
Andrei
10:09 p.m.
On 05/28/2009 10:01 PM, Andrei Pelinescu-Onciul wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/
On May 28, 2009 at 20:23, Juha Heinanen
<jh(a)tutpro.com> wrote:
it works for me as well.
Cheers,
Daniel
when i try to use my kamailio.cfg with
sip-router, the first place where
it fails is this:
dns_try_ipv6=no
sip-router says that the config var is unknown.
That's strange. It works for me with and without USE_IPV6.
sip-router
core cookbook lists the variable, but does not say anything
about it.
is there a replacement or what should i do about it?
It should work as it is. Are you sure you haven't mispelled it somehow?
Could you send me the output of ser -cf your.cfg ?
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
10:15 p.m.
Andrei Pelinescu-Onciul writes:
It should work as it is. Are you sure you haven't
mispelled it somehow?
Could you send me the output of ser -cf your.cfg ?
sorry, i rechecked and the line sip-router is complaining is the next
one:
rev_dns=no
dns_use_search_list=no
dns_try_ipv6=no
disable_dns_blacklist=yes ********** this one
# sip-router -cf /etc/sip-router/sip-router.cfg
0(8340) : <core> [cfg.y:2915]: parse error in config file, line 231, column 22:
syntax error
0(8340) : <core> [cfg.y:2915]: parse error in config file, line 231, column 22:
unknown config variable
0(8340) : <core> [cfg.y:2912]: parse error in config file, line 231, column 23-25:
ERROR: bad config file (3 errors)
0(8340) DEBUG: <core> [mem/shm_mem.c:261]: shm_mem_destroy
according to cookbook there are these dnsblacklist related variables:
dst_blacklist_expire|dst_blacklist_ttl
dst_blacklist_gc_interval
dst_blacklist_init
dst_blacklist_mem
perhaps one of those can be used to get the same effect as k
disable_dns_blacklist=yes?
-- juha
10:24 p.m.
On May 28, 2009 at 22:15, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
dst_blacklist_init=off if you want it disabled without the possibility
to enable it later ar runtime.
use_dst_blacklist=off, if you want to start with it disabled, but with
the possibility to enable it later at runtime via rpcs
(e.g. $ sercmd cfg.set_int_now core use_dst_blacklist 1 ).
Note however that the blacklist in sr is ip based and not dns based
(I don't know how the blacklist worked in k).
Andrei
It should work as it is. Are you sure you
haven't mispelled it somehow?
Could you send me the output of ser -cf your.cfg ?
sorry, i rechecked and the line sip-router is complaining is the next
one:
rev_dns=no
dns_use_search_list=no
dns_try_ipv6=no
disable_dns_blacklist=yes ********** this one
# sip-router -cf /etc/sip-router/sip-router.cfg
0(8340) : <core> [cfg.y:2915]: parse error in config file, line 231, column 22:
syntax error
0(8340) : <core> [cfg.y:2915]: parse error in config file, line 231, column 22:
unknown config variable
0(8340) : <core> [cfg.y:2912]: parse error in config file, line 231, column 23-25:
ERROR: bad config file (3 errors)
0(8340) DEBUG: <core> [mem/shm_mem.c:261]: shm_mem_destroy
according to cookbook there are these dnsblacklist related variables:
dst_blacklist_expire|dst_blacklist_ttl
dst_blacklist_gc_interval
dst_blacklist_init
dst_blacklist_mem
perhaps one of those can be used to get the same effect as k
disable_dns_blacklist=yes?
10:32 p.m.
Andrei Pelinescu-Onciul writes:
dst_blacklist_init=off if you want it disabled without
the possibility
to enable it later ar runtime.
use_dst_blacklist=off, if you want to start with it disabled, but with
the possibility to enable it later at runtime via rpcs
(e.g. $ sercmd cfg.set_int_now core use_dst_blacklist 1 ).
Note however that the blacklist in sr is ip based and not dns based
(I don't know how the blacklist worked in k).
i think i was mixing things up again. sr variables are dst, not dns.
perhaps they are not same thing at all. in k,
disable_dns_blacklist
The DNS resolver, when configured with failover, can automatically store
in a temporary blacklist the failed destinations. This will prevent (for
a limited period of time) openser to send requests to destination known
as failed. So, the blacklist can be used as a memory for the DNS
resolver.
The temporary blacklist created by DNS resolver is named ??dns?? and it
is by default selected for usage (no need use the use_blacklist())
function. The rules from this list have a life time of 4 minutes - you
can change it at compile time, from blacklists.h .
Can be 'yes' or 'no'. By default the blacklist is disabled (Default
value is 'yes').
if sip-router does not include dns blacklisting, then i can just delete
the line, because i was turning dns black listing off in k config.
-- juha
10:42 p.m.
On May 28, 2009 at 22:32, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
In sr/ser we have dns cache which caches also negative replies.
dst_blacklist_init=off if you want it disabled
without the possibility
to enable it later ar runtime.
use_dst_blacklist=off, if you want to start with it disabled, but with
the possibility to enable it later at runtime via rpcs
(e.g. $ sercmd cfg.set_int_now core use_dst_blacklist 1 ).
Note however that the blacklist in sr is ip based and not dns based
(I don't know how the blacklist worked in k).
i think i was mixing things up again. sr variables are dst, not dns.
perhaps they are not same thing at all. in k,
disable_dns_blacklist
The DNS resolver, when configured with failover, can automatically store
in a temporary blacklist the failed destinations. This will prevent (for
a limited period of time) openser to send requests to destination known
as failed. So, the blacklist can be used as a memory for the DNS
resolver.
The temporary blacklist created by DNS resolver is named ??dns?? and it
is by default selected for usage (no need use the use_blacklist())
function. The rules from this list have a life time of 4 minutes - you
can change it at compile time, from blacklists.h .
Can be 'yes' or 'no'. By default the blacklist is disabled (Default
value is 'yes').
In this case, try dns_cache_negative_ttl=0 (or you could disable the
entire dns cache with ude_dns_cache=off, but that will disable also dns
failover and in general I wouldn't recommend it).
if sip-router does not include dns blacklisting, then i can just delete
the line, because i was turning dns black listing off in k config.
Andrei
11:02 p.m.
Andrei Pelinescu-Onciul writes:
In this case, try dns_cache_negative_ttl=0 (or you
could disable the
entire dns cache with ude_dns_cache=off, but that will disable also dns
failover and in general I wouldn't recommend it).
thanks. i tried to document these two in sr core cookbook.
-- juha
11:31 p.m.
On May 28, 2009 at 23:02, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
They are documented in:
doc/dns.txt
doc/dst_blacklist.txt
and in NEWS (just grep after the name).
In fact almost all config variables and new script commands are briefly
documented in NEWS.
Andrei
In this case, try dns_cache_negative_ttl=0 (or
you could disable the
entire dns cache with ude_dns_cache=off, but that will disable also dns
failover and in general I wouldn't recommend it).
thanks. i tried to document these two in sr core cookbook.
10:35 a.m.
On May 29, 2009 at 09:50, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
It might be, but I prefer to have it along the code. It doesn't require
starting a browser or internet access to update it and it's easy to spot
if a new feature is not documented.
Andrei
They are documented in:
doc/dns.txt
doc/dst_blacklist.txt
and in NEWS (just grep after the name).
good that docs exist somewhere. however, it would be more user friendly
if core documentation would be in the wiki. 
1:30 p.m.
On 29-05 09:35, Andrei Pelinescu-Onciul wrote:
On May 29, 2009 at 09:50, Juha Heinanen
<jh(a)tutpro.com> wrote:
How about adopting the dokuwiki syntax for plain-text documentation files in
the repository? It is readable and easy to remember and we can then come up
with a way how to synchronize them with the wiki.
Jan.
Andrei Pelinescu-Onciul writes:
It might be, but I prefer to have it along the code. It doesn't require
starting a browser or internet access to update it and it's easy to spot
if a new feature is not documented. They are documented in:
doc/dns.txt
doc/dst_blacklist.txt
and in NEWS (just grep after the name).
good that docs exist somewhere. however, it would be more user friendly
if core documentation would be in the wiki.
1:52 p.m.
On May 29, 2009 at 12:30, Jan Janak <jan(a)iptel.org> wrote:
On 29-05 09:35, Andrei Pelinescu-Onciul wrote:
Is there an easy way to generate a .html or plain txt from them or to do
some syntax checking?
Andrei
On May 29, 2009 at 09:50, Juha Heinanen
<jh(a)tutpro.com> wrote:
How about adopting the dokuwiki syntax for plain-text documentation files in
the repository? It is readable and easy to remember and we can then come up
with a way how to synchronize them with the wiki. Andrei Pelinescu-Onciul writes:
It might be, but I prefer to have it along the code. It doesn't require
starting a browser or internet access to update it and it's easy to spot
if a new feature is not documented. They are documented in:
doc/dns.txt
doc/dst_blacklist.txt
and in NEWS (just grep after the name).
good that docs exist somewhere. however, it would be more user friendly
if core documentation would be in the wiki.
2:15 p.m.
On 29-05 12:52, Andrei Pelinescu-Onciul wrote:
On May 29, 2009 at 12:30, Jan Janak
<jan(a)iptel.org> wrote:
They are plain text, I don't think you can do syntax checking and I don't
think it is needed, because the format is very simple:
====== Heading ======
* List item one
* List item two
- Numbered list item
paragraps separated by spaces
Links with description [[http://usenix.org|USENIX]]
**bold** //italic// __underlined__ ''monospace''
That's all you need, I think.
If we people stick to this format in text files in the git repository then we
can easily make them visible in the wiki. Synchronization git->dokuwiki is
easy.
For the opposite direction (i.e. when somebody modifies the wiki page), I am
not yet sure, but I guess it should not be hard to make dokuwiki send a diff
to the mailing list when somebody modifies a wiki page that originates from
the git repository.
Jan.
On 29-05 09:35, Andrei Pelinescu-Onciul wrote:
Is there an easy way to generate a .html or plain txt from them or to do
some syntax checking? On May 29, 2009 at 09:50, Juha Heinanen
<jh(a)tutpro.com> wrote:
How about adopting the dokuwiki syntax for plain-text documentation files in
the repository? It is readable and easy to remember and we can then come up
with a way how to synchronize them with the wiki. Andrei Pelinescu-Onciul writes:
> They are documented in:
> doc/dns.txt
> doc/dst_blacklist.txt
> and in NEWS (just grep after the name).
good that docs exist somewhere. however, it would be more user friendly
if core documentation would be in the wiki.
It might be, but I prefer to have it along the code. It doesn't require
starting a browser or internet access to update it and it's easy to spot
if a new feature is not documented.
6:25 p.m.
Jan Janak writes:
How about adopting the dokuwiki syntax for plain-text
documentation files in
the repository? It is readable and easy to remember and we can then come up
with a way how to synchronize them with the wiki.
that is what i was also thinking. we could then keep the docs in the
source tree and autogenerate core cookbook wiki page.
-- juha
6:34 p.m.
On 05/29/2009 06:25 PM, Juha Heinanen wrote:
Jan Janak writes:
there has to be two-way update. Kamailio wiki was built with large
contribution of community, anonymous users without devel access -- more
details, examples, spell fixes.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
How about adopting the dokuwiki syntax for
plain-text documentation files in
the repository? It is readable and easy to remember and we can then come up
with a way how to synchronize them with the wiki.
that is what i was also thinking. we could then keep the docs in the
source tree and autogenerate core cookbook wiki page.
6:39 p.m.
Daniel-Constantin Mierla writes:
there has to be two-way update. Kamailio wiki was
built with large
contribution of community, anonymous users without devel access -- more
details, examples, spell fixes.
my understanding is that we are here only talking about core cookbook,
not the whole wiki.
if information is in two places, one of them is always out of sync,
which is very bad. perhaps it would be possible to get the core
definitions from source tree to which people could add comments,
example. etc. like online php manual.
-- juha
6:47 p.m.
On 05/29/2009 06:39 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
does not matter, if something is kept in git and wiki at same time, has
to be sync'ed in both ways, otherwise we lose information.
In K we went for wiki because devels were not very diligent in writing
docs and there were good results.
Cheers,
Daniel
there has to be two-way update. Kamailio wiki was
built with large
contribution of community, anonymous users without devel access -- more
details, examples, spell fixes.
my understanding is that we are here only talking about core cookbook,
not the whole wiki.
if information is in two places, one of them is always
out of sync,
which is very bad. perhaps it would be possible to get the core
definitions from source tree to which people could add comments,
example. etc. like online php manual.
-- juha
--
Daniel-Constantin Mierla
http://www.asipto.com/
5659
days inactive
5660
days old
17 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com