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
On May 30, 2009 at 09:16, Juha Heinanen jh@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
Andrei Pelinescu-Onciul writes:
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).
now the thousand euro question is, is failure route executed (if set), on all those cases?
-- juha
On Jun 01, 2009 at 17:34, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
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).
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
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
On Jun 01, 2009 at 18:51, Juha Heinanen jh@tutpro.com wrote:
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?
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
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
On Jun 01, 2009 at 19:11, Juha Heinanen jh@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.
so if use_dst_blacklist is "off" and tcp connection setup fails, failure_route will be always called?
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
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
On Jun 01, 2009 at 18:17, Juha Heinanen jh@tutpro.com wrote:
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?
Yes. Only the first A, no SRV and no naptr.
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
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
On Jun 01, 2009 at 19:02, Juha Heinanen jh@tutpro.com wrote:
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?
At least in doc/dns.txt.
perhaps there should be a page for s users similar to
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
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
-
Andrei Pelinescu-Onciul -
jh＠tutpro.com