30 May
2009
30 May
'09
2:16 a.m.
this line
if (!t_relay("0x01")) {
gives error
0(6768) DEBUG: <core> [sr_module.c:515]: find_export_record: <t_relay> not
found
0(6768) DEBUG: <core> [sr_module.c:515]: find_export_record: <t_relay> not
found
0(6768) : <core> [cfg.y:2921]: parse error in config file, line 2884, column 21:
unknown command, missing loadmodule?
how can i achieve the same effect in sr, i.e., do not generate
provisional response. also, how can the other flag values mapped? in
case of failure, does t_relay always return -1 or are the other negative
values as well?
-- juha
1 Jun
1 Jun
6:03 a.m.
On May 30, 2009 at 09:16, Juha Heinanen <jh(a)tutpro.com> wrote:
this line
if (!t_relay("0x01")) {
gives error
0(6768) DEBUG: <core> [sr_module.c:515]: find_export_record: <t_relay> not
found
0(6768) DEBUG: <core> [sr_module.c:515]: find_export_record: <t_relay> not
found
0(6768) : <core> [cfg.y:2921]: parse error in config file, line 2884, column 21:
unknown command, missing loadmodule?
how can i achieve the same effect in sr, i.e., do not generate
provisional response.
modparam("tm", "auto_inv_100", 0) (globally)
or
t_set_auto_inv_100(0) (per transaction)
E.g.:
t_set_auto_inv_100(0);
t_relay();
also, how can the other flag values mapped?
0x02 - in sip-router the negative reply is generated at the end of the
script (and not internal inside t_relay()) and only if no reply from
script was generated. So one could always use t_reply() to change the
reply code, or t_release() to skip generating a reply.
I'm not sure if this is completely equivalent to the k 0x02.
0x04 - no equivalent, dns failover can be turned off only globally and
not per transaction.
in
case of failure, does t_relay always return -1 or are the other negative
values as well?
It can return other negative values, when called form a request route
(e.g.: E_BAD_ADDRESS, E_SEND, E_ADM_PROHIBITED, E_OUT_OF_MEM a.s.o,
see error.h for the negative values).
Andrei
10:34 a.m.
Andrei Pelinescu-Onciul writes:
now the thousand euro question is, is failure route executed (if set),
on all those cases?
-- juha
0x02 - in sip-router the negative reply is generated
at the end of the
script (and not internal inside t_relay()) and only if no reply from
script was generated. So one could always use t_reply() to change the
reply code, or t_release() to skip generating a reply.
I'm not sure if this is completely equivalent to the k 0x02.
this sounds fine.
in
case of failure, does t_relay always return -1 or are the other negative
values as well?
It can return other negative values, when called form a request route
(e.g.: E_BAD_ADDRESS, E_SEND, E_ADM_PROHIBITED, E_OUT_OF_MEM a.s.o,
see error.h for the negative values).
11:44 a.m.
On Jun 01, 2009 at 17:34, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
now the thousand euro question is, is failure route executed (if set),
on all those cases?
No, if t_relay() returns negative, the failure route is not executed
(since the transaction was not created in the first place).
Andrei
0x02 - in sip-router the negative reply is
generated at the end of the
script (and not internal inside t_relay()) and only if no reply from
script was generated. So one could always use t_reply() to change the
reply code, or t_release() to skip generating a reply.
I'm not sure if this is completely equivalent to the k 0x02.
this sounds fine.
in
case of failure, does t_relay always return -1 or are the other negative
values as well?
It can return other negative values, when called form a request route
(e.g.: E_BAD_ADDRESS, E_SEND, E_ADM_PROHIBITED, E_OUT_OF_MEM a.s.o,
see error.h for the negative values).
11:51 a.m.
Andrei Pelinescu-Onciul writes:
No, if t_relay() returns negative, the failure route
is not executed
(since the transaction was not created in the first place).
so do we have the same problem as in k that if udp destination is
unreachable, but packet can be sent out, failure route is executed, but
if tcp destination is unreachable, failure route is not executed?
-- juha
12:01 p.m.
On Jun 01, 2009 at 18:51, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
Yes, but with the added twist that most of the time the failure route
will be called for unreachable tcp destinations if tcp_async is on
(default) and the destination is not yet in the blacklist.
Andrei
No, if t_relay() returns negative, the failure
route is not executed
(since the transaction was not created in the first place).
so do we have the same problem as in k that if udp destination is
unreachable, but packet can be sent out, failure route is executed, but
if tcp destination is unreachable, failure route is not executed?
12:11 p.m.
Andrei Pelinescu-Onciul writes:
Yes, but with the added twist that most of the time
the failure route
will be called for unreachable tcp destinations if tcp_async is on
(default) and the destination is not yet in the blacklist.
so if use_dst_blacklist is "off" and tcp connection setup fails,
failure_route will be always called?
-- juha
12:22 p.m.
On Jun 01, 2009 at 19:11, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
In most cases. It depends on the tcp stack and if a non-blocking connect
returns pending or the remote responds so fast that it would return and
error (e.g. connect to localhost).
So you shouldn't rely on this behaviour.
Andrei
Yes, but with the added twist that most of the
time the failure route
will be called for unreachable tcp destinations if tcp_async is on
(default) and the destination is not yet in the blacklist.
so if use_dst_blacklist is "off" and tcp connection setup fails,
failure_route will be always called?
11:17 a.m.
Andrei Pelinescu-Onciul writes:
0x04 - no equivalent, dns failover can be turned off
only globally and
not per transaction.
NEWS tells:
use_dns_failover = on | off (default off)
does "off" mean that, for example, if a domain name has two A records,
only one of them is tried?
if so, why is default "off"? i don't remember that kind of default in
any other application.
-- juha
11:57 a.m.
On Jun 01, 2009 at 18:17, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
Yes. Only the first A, no SRV and no naptr.
0x04 - no equivalent, dns failover can be turned
off only globally and
not per transaction.
NEWS tells:
use_dns_failover = on | off (default off)
does "off" mean that, for example, if a domain name has two A records,
only one of them is tried?
if so, why is default "off"? i don't remember that kind of default in
any other application.
Same behaviour as old versions, performance/memory (less memory used
since transactions die quicker).
I'm not against changing the default provided that more people want it
and someone takes care of changing all the doc references.
Andrei
12:02 p.m.
Andrei Pelinescu-Onciul writes:
I'm not against changing the default provided that
more people want it
and someone takes care of changing all the doc references.
in k, dsn failover is on by default. i can change the NEWS file, no
problem. where else it is documented? perhaps there should be a page
for s users similar to
http://sip-router.org/wiki/migration/kamailio-tips
-- juha
3 Jun
3 Jun
1:17 p.m.
On Jun 01, 2009 at 19:02, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
At least in doc/dns.txt.
I'm not against changing the default provided
that more people want it
and someone takes care of changing all the doc references.
in k, dsn failover is on by default. i can change the NEWS file, no
problem. where else it is documented? perhaps there should be a page
for s users similar to
http://sip-router.org/wiki/migration/kamailio-tips
There is: doc/config_migration.txt and
https://sip-router.org/wiki/admin_guide/migrate links it.
There are other dns related defaults you should be aware off:
dns_srv_lb - default off. With it on the srv failover will do load
balancing (as in rfc2782), wihtout it will only do simple failover
based on priority and weight (will try all the A records in order
instead of load balancing between records witht he same priority based
on weights). With it on -> slight performance hit.
dns_try_naptr - default off.
dns_udp_pref, dns_tcp_pref, dns_tls_pref, dns_sctp_pref - preference of
the corresp. protocol when doing NAPTR lookups. Allow overriding the
preference listed in the NAPTR record with a local preference.
-1 completely disables a protocol.
Default: udp=30, tcp=20, tls=10, sctp=20 (prefer udp, then sctp or tcp
and then tls). To obey the rfc one would have to set all of them to the
same value (e.g. 100), but in general udp is preferable (lighter
weight).
For more info see doc/dns.txt.
Andrei
2:28 p.m.
Andrei Pelinescu-Onciul writes:
There are other dns related defaults you should be
aware off:
dns_srv_lb - default off. With it on the srv failover will do load
balancing (as in rfc2782), wihtout it will only do simple failover
based on priority and weight (will try all the A records in order
instead of load balancing between records witht he same priority based
on weights). With it on -> slight performance hit.
i need to look this more carefully, but in my opinion default behavior
should be what "rfc 3263 locating sip servers" says.
-- juha
5690
days inactive
5694
days old
12 comments
2 participants
participants (2)
-
Andrei Pelinescu-Onciul -
jh＠tutpro.com