sr-dev March 2010

sr-dev@lists.kamailio.org

24 participants
359 discussions

[tracker] Assignee added: wrong TM response code

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#53 - wrong TM response code User who did this - Klaus Darilion (klaus3000) http://sip-router.org/tracker/index.php?do=details&task_id=53 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 1 month

git:master: kamailo.cfg: fixed typo

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 7a1e96b69de685ad4b4562d8ddde31106d9cd437 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7a1e96b… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Mar 26 10:48:41 2010 +0100 kamailo.cfg: fixed typo - typo in the hints of missed_calls table update for accouting (cherry picked from commit 6087434f2ddfbe07767d5a4eeb739b72b7c27a93) --- etc/kamailio.cfg | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/etc/kamailio.cfg b/etc/kamailio.cfg index 637602d..ee63ec8 100644 --- a/etc/kamailio.cfg +++ b/etc/kamailio.cfg @@ -56,7 +56,7 @@ ALTER TABLE missed_calls ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; - ALTER TABLE missed_call ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; + ALTER TABLE missed_calls ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; #!endif

14 years, 1 month

git:kamailio_3.0: kamailo.cfg: fixed typo

by Daniel-Constantin Mierla

Module: sip-router Branch: kamailio_3.0 Commit: 6087434f2ddfbe07767d5a4eeb739b72b7c27a93 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6087434… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Mar 26 10:48:41 2010 +0100 kamailo.cfg: fixed typo - typo in the hints of missed_calls table update for accouting --- etc/kamailio.cfg | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/etc/kamailio.cfg b/etc/kamailio.cfg index 637602d..ee63ec8 100644 --- a/etc/kamailio.cfg +++ b/etc/kamailio.cfg @@ -56,7 +56,7 @@ ALTER TABLE missed_calls ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; - ALTER TABLE missed_call ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; + ALTER TABLE missed_calls ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; #!endif

14 years, 1 month

Why is any bflag visible under failure_route?

by Iñaki Baz Castillo

Hi, using Kamailio 1.5.4. I've detected a possible error: - INVITE received. - It's routed to gw-1 (branch-1). - Branch-1 replies some final non 2XX reply and in on_reply_route I set a bflag. - In failure_route I check the value of such bflag and it's set (OK). - Still in failure_route I create a new branch (Branch-2). - Branch-2 replies some final non 2XX reply and in on_reply_route I *DONT* set the bflag for this second branch. - In failure_route I check the value of such bflag and it's set (WHY??). Why is such bflag set when inspecting it in failure_route for the second branch? the branch creating such negative final response (Branch-2) hasn't such bflag active. Is it the expected behaviour due to something I miss? or is it a posible bug? Regards. -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 1 month

new dialog module design: tm trigger for dialog management

by Timo Reimann

Hello, the new dialog module proposal seems to imply that dialog_out management (and thereby, implicitly, dialog_in management) is to be carried out when responses arrive at a proxy, i.e., on execution of the tm callback type TMCB_RESPONSE_IN. However, as the comment to this callback type in modules/tm/t_hooks.h illustrates, such callbacks will also be run on retransmissions. This means that the dialog module will have to take precautions and either - check whether the response being observed is a retransmission, for instance by means of checking whether a dialog_out entry corresponding to the response already exists, or - ignore retransmissions and stupidly (over-)write the dialog_out entry, i.e., in case of a retransmission re-write the same entry. The first option induces some delay for CPU cycles and memory accesses, and adds some complexity w.r.t. correct retransmission checking which must not miss possible corner cases. The second option, in addition to wasting even more resources (maybe even I/O when persistent storage of dialog data is enabled), requires that overwriting of dialog state does not have any side-effects. I am not sure if this is always the case. Instead of thinking about which option to prefer and what needs to be taken care of, I'd rather re-propose a different approach that I have brought forward before in a slightly different context: Instead of using TMCB_RESPONSE_IN, run the dialog state machinery on TMCB_RESPONSE_PRE_OUT. It's guaranteed to be retransmission-free and should cover everything we have discussed so far. Moreover, it will render dialog_out state needless and ease state keeping: As long as provisional responses are being forwarded (either by a local or remote proxy), the dialog_in state must be "early" because the proxy would only stop informing the UAC about provisional responses when it received a final response, either due to exhaustion of all branches or a positive OK response. Once the forking proxy decides to forward a response with code 200+, all other early dialogs can be safely deleted and the dialog_in state set accordingly. Consequently, step 2 of the algorithm that changes dialog_in state ("Algorithm for dialog_in state") given in the proposal boils down to a simple matching rule as follows: Set dialog_in state to the state corresponding to the return code of the forwarded message. That is, if the response code is * greater than 100, but smaller than 200: set it to "early" (may be skipped if there is a dialog_out entry already as this implies that another early branch has already been established and the dialog_in state set to "early"), * 200: set it to "confirmed" (step 1 will have deleted the remaining branches), * greater than 200: set it to "terminated" (step 1 will have deleted the remaining branches). In-dialog BYE requests will just have to set the dialog_in state to "terminated", trimming down the state machine further. Considering the corner case of two branches' 200 responses arriving at exactly the same time (let's name them concurrently confirmed dialogs), I believe that this should yield two completely independent dialog entries, with one dialog_in and dialog_out each. Managing them under the same dialog_in as two dialog_outs gives the impression that they are somewhat related but this is not true as each carries a unique dialog identifier. Furthermore, under the current proposal, I believe that callbacks registered for the yet non-confirmed dialog will be effective for the concurrently confirmed dialog too because both OK responses should be forwarded by the same transaction, resulting in the same dialog callbacks being run for both dialogs. If the transaction module handles simultaneously forwarded OK responses differently, then there will be no callbacks at all for one of the dialogs which is equally bad. Instead, there should be a clean separation of the two dialogs supported by a new dialog callback type (e.g., DLGCB_CONCURRENTLY_CONFIRMED) which allows the user to decide whether he wants to track the additionally confirmed dialog as well, and how long he wants to track it based on further dialog callbacks he chooses. For example, he may register DGLCB_TERMINATED on the additional dialog or opt that getting to know about its generation is sufficient. Generally, in-dialog requests will be mapped to the respective dialogs (which may involve some more effort because dialog hashes are stored in the route headers during processing of the initial request, but it's doable) and managed individually. Concluding, this modified approach will keep the new dialog module from doing unnecessary and hard-to-do duplicate checks, eases state management, and keeps concurrently confirmed dialogs cleanly separated. Opinions? Cheers, --Timo

14 years, 1 month

git:kamailio_3.0: core: fix return not working inside a while() loop

by Andrei Pelinescu-Onciul

Module: sip-router Branch: kamailio_3.0 Commit: 4a280caf2a8fd452f9df44ad8cf39dd40e06c1e7 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4a280ca… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Thu Mar 25 22:04:44 2010 +0100 core: fix return not working inside a while() loop Reported-by: Juha Heinanen jh tutpro com Closes: FlySpray#46. (cherry picked from commit 0581efe06a8fb0ffe15542c343ae7ac0bc20cbbb) --- action.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/action.c b/action.c index ddbf445..4edf023 100644 --- a/action.c +++ b/action.c @@ -1116,7 +1116,7 @@ match_cleanup: flags=0; rve=(struct rval_expr*)a->val[0].u.data; ret=1; - while(!(flags & BREAK_R_F) && + while(!(flags & (BREAK_R_F|RETURN_R_F|EXIT_R_F)) && (rval_expr_eval_int(h, msg, &v, rve) == 0) && v){ i++; if (unlikely(i > cfg_get(core, core_cfg, max_while_loops))){ @@ -1131,7 +1131,7 @@ match_cleanup: ret=run_actions(h, (struct action*)a->val[1].u.data, msg); flags|=h->run_flags; h->run_flags &= ~BREAK_R_F; /* catch breaks, but let - returns passthrough */ + returns pass-through */ } } break;

14 years, 1 month

git:sr_3.0: core: fix return not working inside a while() loop

by Andrei Pelinescu-Onciul

Module: sip-router Branch: sr_3.0 Commit: f90397b76e48f33386175d298326143311be48cb URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=f90397b… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Thu Mar 25 22:04:44 2010 +0100 core: fix return not working inside a while() loop Reported-by: Juha Heinanen jh tutpro com Closes: FlySpray#46. (cherry picked from commit 0581efe06a8fb0ffe15542c343ae7ac0bc20cbbb) --- action.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/action.c b/action.c index ddbf445..4edf023 100644 --- a/action.c +++ b/action.c @@ -1116,7 +1116,7 @@ match_cleanup: flags=0; rve=(struct rval_expr*)a->val[0].u.data; ret=1; - while(!(flags & BREAK_R_F) && + while(!(flags & (BREAK_R_F|RETURN_R_F|EXIT_R_F)) && (rval_expr_eval_int(h, msg, &v, rve) == 0) && v){ i++; if (unlikely(i > cfg_get(core, core_cfg, max_while_loops))){ @@ -1131,7 +1131,7 @@ match_cleanup: ret=run_actions(h, (struct action*)a->val[1].u.data, msg); flags|=h->run_flags; h->run_flags &= ~BREAK_R_F; /* catch breaks, but let - returns passthrough */ + returns pass-through */ } } break;

14 years, 1 month

git:sr_3.0: makefile: presence_mwi added to excluded list

by Andrei Pelinescu-Onciul

Module: sip-router Branch: sr_3.0 Commit: be2ab41f8a87861a8cfd10cb33103191680b2a79 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=be2ab41… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Wed Mar 24 22:44:49 2010 +0100 makefile: presence_mwi added to excluded list - patch by Ovidiu Sas, tracker FS#45 - makes no sense to build it out of presence group - kpresence group includes it and makes easier packaging (cherry picked from commit d91a9b021c494678cd20bc3fd444f9d4d565ec65) --- Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 52f98f8..7a4f7ce 100644 --- a/Makefile +++ b/Makefile @@ -278,7 +278,7 @@ else perl perlvdb purple seas \ snmpstats xmpp \ carrierroute misc_radius peering \ - dialplan lcr utils presence \ + dialplan lcr utils presence presence_mwi \ presence_dialoginfo presence_xml pua pua_bla \ pua_dialoginfo pua_usrloc pua_xmpp \ regex xcap_client

14 years, 1 month

git:sr_3.0: makefile: fix install utils

by Andrei Pelinescu-Onciul

Module: sip-router Branch: sr_3.0 Commit: 7a3daa1752056891739c8a9e60e41e1009af9505 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7a3daa1… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Mon Mar 22 16:33:04 2010 +0100 makefile: fix install utils - previous commit broke installation of utils by a c&p error to non-empty test to utils variable (r => ut) - extra check for directory existence - credits to Federico M. and Nathaniel L Keeling III for reporting (cherry picked from commit 641a41b6e9cf1387c24dd9f863db978c8018df80) --- Makefile | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 0132d71..52f98f8 100644 --- a/Makefile +++ b/Makefile @@ -986,8 +986,10 @@ install-utils: utils $(bin_prefix)/$(bin_dir) fi ; \ done; true @for ut in $(C_INSTALL_UTILS) "" ; do \ - if [ -n "$$r" ]; then \ - $(call try_err, $(MAKE) -C "$${ut}" install-if-newer ) ;\ + if [ -n "$$ut" ]; then \ + if [ -d "$$ut" ]; then \ + $(call try_err, $(MAKE) -C "$${ut}" install-if-newer ) ;\ + fi ;\ fi ; \ done; true

14 years, 1 month

git:master: core: fix return not working inside a while() loop

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: 0581efe06a8fb0ffe15542c343ae7ac0bc20cbbb URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0581efe… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Thu Mar 25 22:04:44 2010 +0100 core: fix return not working inside a while() loop Reported-by: Juha Heinanen jh tutpro com Closes: FlySpray#46. --- action.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/action.c b/action.c index e39b539..ef33814 100644 --- a/action.c +++ b/action.c @@ -1134,7 +1134,7 @@ match_cleanup: flags=0; rve=(struct rval_expr*)a->val[0].u.data; ret=1; - while(!(flags & BREAK_R_F) && + while(!(flags & (BREAK_R_F|RETURN_R_F|EXIT_R_F)) && (rval_expr_eval_int(h, msg, &v, rve) == 0) && v){ i++; if (unlikely(i > cfg_get(core, core_cfg, max_while_loops))){ @@ -1149,7 +1149,7 @@ match_cleanup: ret=run_actions(h, (struct action*)a->val[1].u.data, msg); flags|=h->run_flags; h->run_flags &= ~BREAK_R_F; /* catch breaks, but let - returns passthrough */ + returns pass-through */ } } break;

14 years, 1 month

← Newer
1
...
5
6
7
8
9
10
11
...
36
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2010