Requests send with uac module's functions like uac_req_send() and remote registrations use the TM module, but don't actually do (DNS) failover when a destination is unreachable or sends a 503.
In the tm's uac.c, t_uac_prepare() function, i can already see that the dns handle is stored in a throwaway variable instead of in the transaction, but fixing the issue isn't as simple as just storing it in the transaction (print_uac_request_from_buf() needs a uas in the transaction).
Due to github not supporting attachments to issues, the sample config and debug log are inline.... :(
DNS entry:
```
$ host -t SRV _sip._udp.failover.test.speakup.nl
_sip._udp.failover.test.speakup.nl has SRV record 10 0 1111 try1.test.speakup.nl.
_sip._udp.failover.test.speakup.nl has SRV record 100 0 2222 try2.test.speakup.nl.
```
Log snippet:
```syslog
Jun 15 10:00:03 rio UACFailover[18178]: INFO: <script>: Sending OPTIONS request to sip:failover.test.speakup.nl
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:failover.test.speakup.nl>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (_sip._udp.failover.test.speakup.nl(34), 33), h=825
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [resolve.c:937]: get_record(): skipping 8 NS (p=0x9ea284, end=0x9ea3e9)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [resolve.c:952]: get_record(): parsing 9 ARs (p=0x9ea335, end=0x9ea3e9)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:1741]: dns_get_related(): (0x7f225233eb38 (_sip._udp.failover.test.speakup.nl, 33), 33, *0x7f2257baf2b8) (0)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding _sip._udp.failover.test.speakup.nl(34) 33 (flags=0) at 825
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding try1.test.speakup.nl(20) 1 (flags=0) at 310
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding try2.test.speakup.nl(20) 1 (flags=0) at 307
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:2336]: dns_srv_get_nxt_rr(): (0x7f225233eb38, 0, 0, 1597643831): selected 0/1 in grp. 0 (rand_w=0, rr=0x7f225233eba0 rd=0x7f225233ebb8 p=10 w=0 rsum=0)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (try1.test.speakup.nl(20), 1), h=310
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:2926]: dns_a_resolve(): (try1.test.speakup.nl, 0) returning 0
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:3169]: dns_srv_resolve_ip(): ("_sip._udp.failover.test.speakup.nl", 0, 0), ret=0, ip=192.168.1.245
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:3260]: dns_srv_sip_resolve(): (failover.test.speakup.nl, 0, 0), srv0, ret=0
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 54501
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:351]: t_uac_prepare(): executing event_route[tm:local-request]
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:606]: parse_msg(): SIP Request:
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): method: <OPTIONS>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): uri: <sip:failover.test.speakup.nl>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): version: <SIP/2.0>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK5e4d.47adbbf5000000000000000000000000.0>; state=16
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [22]; uri=[sip:to.example.com]
Jun 15 10:00:03 rio UACFailover[18178]: [97B blob data]
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <10> <OPTIONS>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: pv [pv_core.c:376]: pv_get_xto_attr(): no Tag parameter
Jun 15 10:00:03 rio UACFailover[18178]: INFO: <script>: [udp:172.28.4.128:6789] [10 OPTIONS] Request (cid: 6cd531e47cc63e20-18178(a)172.28.4.128 Branch: -1 ToTag: <null> len:382) To <sip:failover.test.speakup.nl> via <sip:failover.test.speakup.nl>
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil)
Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:1230]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408
Jun 15 10:00:05 rio UACFailover[18176]: WARNING: tm [t_reply.c:957]: run_failure_handlers(): Warning: run_failure_handlers: no UAC support (1, 0)
Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:2016]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0
Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:2053]: local_reply(): DEBUG: local transaction completed
```
Sample config:
```python
#------------------
# Flags
#------------------
debug=3
memdbg=5
mem_summary=5
#fork=no # This option should not be present to enable forking but disable daemonize, also -D commandline parameter is needed
log_stderror=no
sip_warning=no
listen=172.28.4.128
port=6789
children=2
shm_mem_size=64
log_name="UACFailover"
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
dns_use_search_list=no
use_dns_failover=yes
dns_srv_lb=yes
disable_tcp=yes
mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules/"
loadmodule "pv.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "xlog.so"
loadmodule "rr.so"
loadmodule "uac.so"
loadmodule "rtimer.so"
# -----------------------------------------------------------------
# Module settings
# -----------------------------------------------------------------
modparam("pv", "varset", "server=s:LOGNAME")
modparam("tm", "auto_inv_100", 0)
# Time until provisional response (eg "100 Trying") is received
modparam("tm", "fr_timer", 2000)
# Time to await final response on INVITE per branch (eg per branch ring time)
modparam("tm", "fr_inv_timer", 10000)
# Time to await final response on INVITE (eg ring time)
modparam("tm", "max_inv_lifetime", 20000)
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "failure_reply_mode", 3)
modparam("rtimer", "timer", "name=uac;interval=10;mode=1;")
modparam("rtimer", "exec", "timer=uac;route=TIMER")
route {
xlog("L_NOTICE", "[$pr:$si:$sp] [$cs $rm] Request. (cid: $ci <$fu> => <$ru> len: $ml)");
drop();
}
event_route[tm:local-request] {
xlog("L_INFO", " [$pr:$si:$sp] [$cs $rm] Request (cid: $ci Branch: $T_branch_idx ToTag: $tt len:$ml) To <$ru> via <$du>");
}
onreply_route {
xlog("L_INFO", " [$pr:$si:$sp] [$cs $rm] Reply (cid: $ci Branch: $T_branch_idx Status: $rs $rr ToTag: $tt len:$ml)");
}
route[TIMER] {
if not $var(done) == 1 {
$var(done) = 1;
$uac_req(method) = "OPTIONS";
$uac_req(ruri) = "sip:failover.test.speakup.nl";
$uac_req(furi) = "sip:from.example.com";
$uac_req(turi) = "sip:to.example.com";
xlog("L_INFO", "Sending $uac_req(method) request to $uac_req(ruri)");
uac_req_send();
}
}
```
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/210
Module: kamailio
Branch: master
Commit: b7c588dff06030a82f305b210573be5bbc961cec
URL: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2015-09-07T15:56:45+02:00
tm: store last received response code before running onreply_route
- otherwise an innapropriate cancel can happen if the current branch got
before an 1xx response, and the script writer enforces another reply
code with t_reply()
- reported by Thomas Sevestre, GH#315
---
Modified: modules/tm/t_reply.c
---
Diff: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5…
Patch: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5…
---
diff --git a/modules/tm/t_reply.c b/modules/tm/t_reply.c
index b2e6e53..8da3205 100644
--- a/modules/tm/t_reply.c
+++ b/modules/tm/t_reply.c
@@ -2286,10 +2286,21 @@ int reply_received( struct sip_msg *p_msg )
backup_xavps = xavp_set_list(&t->xavps_list);
#endif
setbflagsval(0, uac->branch_flags);
+ if(msg_status>last_uac_status) {
+ /* current response (msg) status is higher that the last received
+ * on the same branch - set it temporarily so functions in onreply_route
+ * can access it (e.g., avoid sending CANCEL by forcing another t_relply()
+ * in onreply_route when a negative sip response was received) */
+ uac->last_received = msg_status;
+ }
+
/* Pre- and post-script callbacks have already
* been executed by the core. (Miklos)
*/
run_top_route(onreply_rt.rlist[onreply_route], p_msg, &ctx);
+
+ /* restore brach last_received as before executing onreply_route */
+ uac->last_received = last_uac_status;
/* transfer current message context back to t */
if (t->uas.request) t->uas.request->flags=p_msg->flags;
getbflagsval(0, &uac->branch_flags);
I have a situation that I can't get my head around. Every so often I have a SCA seized and I need to manually release it. Here is the log of the sca and bye from the event logs.
messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7608]: ERROR: sca [sca_call_info.c:1580]: sca_call_info_bye_handler(): sca_call_info_bye_handler: sip:Mindfield@kamailio.newgarllc.com dialog leg 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;1c389191866 is not active
messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7610]: NOTICE: acc [acc.c:317]: acc_log_request(): ACC: transaction answered: timestamp=1442601328;method=BYE;from_tag=76C3EC1F-114D759A;to_tag=1c389191866;call_id=96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;code=200;reason=OK;src_user=Mindfield;src_domain=kamailio.newgarllc.com;src_ip=192.168.1.40;dst_ouser=Mindfield;dst_user=Mindfield;dst_domain=192.168.1.117
And the kamcmd showing the seize line (in this case both are seized)
sip:Mindfield@kamailio.newgarllc.com 1 active 1442601278 sip:Mindfield@192.168.1.117 sip:1030@192.168.1.40:5060 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117 76C3EC1F-114D759A 1c389191866
I am running Kamailio 4.2.6. The phones are Polycom VVX 310/410 running 5.3.1. And the PSTN gateway is an Audiocodes Mediant 1000 running 6.60A.292.001.
The call volume is light so I don't think there is a lot of traffic but there is about 16 phones one SCA. It is not happening all time. Could be a couple days that nothing happens and then there could be a couple days that it happens multiple times a day. I can't find a common element that would be causing this unless the 'bye' is closing the call before the SCA has a chance to do something with it.
Thanks
Kev
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/341
In the contact-expired event route I want to check if the expired AOR is registered elsewhere, by checking replicated location tables like "location-peer". Using the registered("location-peer", "<aor>") function causes Kamailio to go to sleep and not respond to rpc commands.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/577
I have rebooted my kamailio machine and now the value of kamailio dialogs is always 0:
KAMAILIO-MIB::kamailioCurNumDialogs.0 = Gauge32: 0
KAMAILIO-MIB::kamailioCurNumDialogsInProgress.0 = Gauge32: 0
KAMAILIO-MIB::kamailioCurNumDialogsInSetup.0 = Gauge32: 0
KAMAILIO-MIB::kamailioTotalNumFailedDialogSetups.0 = Counter32: 0
And also the status is:
KAMAILIO-MIB::kamailioDialogUsageState.0 = INTEGER: idle(0)
How can I change it to active(1)? I have dialog.so loaded as well as modparam("dialog", "dlg_flag", 4) and dlg_manage().
If I do 'kamctl stats dialog':
# kamctl stats dialog
dialog:active_dialogs = 498
dialog:early_dialogs = 57
dialog:expired_dialogs = 24
dialog:failed_dialogs = 73222
dialog:processed_dialogs = 539449
I have the same configruation of SNMPstats and kamailio in 2 other machines and it works perfectly. In this machine it worked until I rebooted the machine.
I asked this question in th emailing list and I got the following response:
"Must be something in how the SNMP module reads the data from the statistics counters."
I don't know if this could help.
Thank you.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/424
Hi devs,
The logs of our Kamailio servers are rich for such lines:
```
Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer (104)
Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading
```
The servers serve WS, WSS, UDP, TCP and TLS as connection transports. So we cannot figure what happens and if this is really a problem, but we get accused by whoever audits the servers.
What could be done to make this more trackable? Or maybe these messages should be suppressed, if there's no way to track them and they don't mean any problem?
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/385
Hi im currently using freetds via unixodbc to connect to a sql azure db which is ok but suffers from various connection busy errors. I would like to use the ms odbc driver as it supports MARS (multiple active result sets) which should stop the connection busy errors, and numerous other sql server specific enhancements However despite the odbc driver working fine with the unixodbc cli tools kamailio crashes when I try and start the service.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/501