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 am having issues using uac_auth function and dialog module track_cseq_update option. The issue is related to CSeq mangling done by dialog module to keep synced CSeq in both parties involved.
It works fine when 1xx response is received for generated INVITE before retr_timer1 expires but, if not, the generated retransmission has the same CSeq as the original INVITE (the one without Authorization headers), instead of increasing CSeq by one again:
- INVITE sent by UAC (CSeq 100).
- 407 from UAS.
- INVITE generated by uac_auth (CSeq 101).
- (... no answer ...)
- Retransmission INVITE with Authorization header but with CSeq 100.
This is the minimal configuration file needed to test this behaviour:
```
loadmodule "tm.so"
loadmodule "pv.so"
loadmodule "sl.so"
loadmodule "avpops.so"
loadmodule "dialog.so"
loadmodule "uac.so"
loadmodule "rr.so"
modparam("dialog", "dlg_flag", 1)
modparam("dialog", "track_cseq_updates", 1)
modparam("uac", "auth_realm_avp", "$avp(realm)")
modparam("uac", "auth_username_avp", "$avp(provideruser)")
modparam("uac", "auth_password_avp", "$avp(secret)")
modparam("tm", "retr_timer1", 100)
request_route {
dlg_manage();
$ru = "sip:test@**SIPSERVER**";
t_on_failure("MANAGE_FAILURE");
t_relay();
exit;
}
failure_route[MANAGE_FAILURE] {
if (t_is_canceled()) {
exit;
}
if (t_check_status("(401)|(407)")) {
$avp(realm) = '';
$avp(provideruser) = 'foo';
$avp(secret) = 'bar';
uac_auth();
}
t_on_failure("MANAGE_FAILURE");
t_relay();
exit;}
```
This is the Kamailio version I am using on a amd64 machine (Debian 7):
```
version: kamailio 4.4.1 (x86_64/linux) 99e1c3
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 99e1c3
compiled on 13:37:42 Jun 20 2016 with gcc 4.7.2
```
Is something wrong on my kamailio.cfg? Do you need any extra information?
Best regards.
---
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/679
Crashes has been reported when using mongodb modules compiled with mongo-c-driver having ssl enabled. Using mongo-c-driver without ssl enabled doesn't expose the issue.
To investigate mongo-c-driver sources and see if it is messing up with the memory manager set for libssl.
---
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/660
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
Hi!
Trying to debug a case where I don’t get an event_route execution for a TCP connection.
IN my case, Kamailio opens a new TCP connection to another server in order to send an in-dialog request. When that connection
closes, there’s no event route being executed.
The tcpops module use default config, which means that the event route tcp:closed is globally enabled.
I’ve been digging in the tcp code but can’t really figure it out… ;-)
Cheers,
/O
Given that there are multiple Route sets , each with one param , check_route_param() function fails to search the proper param.s string .
The condition params.s[0]!=';' holds false and it stops the loop only when it encounters another ";" character which is not part of the Route header .
Eg: (these are not actual Route params, but this is what it is printing instead - this is part of my INVITE, and these headers are above Route ):
rr [loose.c:985]: check_route_param(): params are <;spi-s=424238335#015#012Require: sec-agree#015#012Proxy-Require: sec-agree#015#012Cont>
This patch is a functional workaround.
Note I have also seen there routed_params.s not pointing to the actual params , so perhaps there might be another issue before reaching this code.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/663
-- Commit Summary --
* rr: fix Route param search in check_route_param()
* Merge remote-tracking branch 'upstream/master' into fix-check_route_param
-- File Changes --
M modules/rr/loose.c (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/663.patchhttps://github.com/kamailio/kamailio/pull/663.diff
---
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/pull/663
Calls to cfg_get(tm, tm_cfg, default_reason) and cfg_get(tm, tm_cfg, tm_auto_inv_100_r) on Solaris/SPARC cause a bus error. Looking though some mailing list archives, it appears a similar issue was fixed in the registrar module but I couldn't find patch referenced.
---
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/655
This allows building with Solaris Studio, tested with 12.4.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/689
-- Commit Summary --
* core: fix Sun Studio build
* counters: fix return statement in void function
* dialog: remove return statement from void functions
* ctl: remove return statement from void function
* pdb: set packed attribute on enum conditionally
* uid_avp_db: remove GCC specific -Wall
-- File Changes --
M Makefile.defs (27)
M action.c (13)
M atomic/atomic_sparc64.h (3)
M io_wait.h (4)
M ip_addr.h (1)
M mem/memdbg.h (13)
M modules/counters/counters.c (5)
M modules/ctl/binrpc_run.c (2)
M modules/dialog/dlg_handlers.c (4)
M modules/pdb/common.h (12)
M modules/tls/tls_bio.c (18)
M modules/tls/tls_server.c (18)
M modules/uid_avp_db/Makefile (1)
M sr_module.h (8)
M tls_hooks.h (21)
M utils/kamcmd/parse_listen_id.c (10)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/689.patchhttps://github.com/kamailio/kamailio/pull/689.diff
---
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/pull/689