sr-dev

sr-dev@lists.kamailio.org

44307 discussions

[tracker] Task closed: wrong TM response code

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#53 - wrong TM response code User who did this - Andrei Pelinescu-Onciul (andrei) Reason for closing: Not a bug Additional comments about closing: It behaves exactly as it should, according to RFC 3261. More information can be found at the following URL: 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, 10 months

[tracker] Comment added: wrong TM response code

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#53 - wrong TM response code User who did this - Andrei Pelinescu-Onciul (andrei) ---------- It's not a bug, it's intended behaviour. RFC 3261 16.7 6. Choosing the best response : .... The proxy SHOULD give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=53#comment52 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, 10 months

[tracker] Comment added: wrong TM response code

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#53 - wrong TM response code User who did this - Klaus Darilion (klaus3000) ---------- fixed the ASCII-Art: <code> client A proxy --INV A-------------> <-407---------------- --ACK---------------> --INV A-------------> <-------------INV A-- --------------482---> <-407---------------- ^^^^ bug: should be 482 </code> ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=53#comment51 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, 10 months

[tracker] Task opened: wrong TM response code (Attachment added)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Klaus Darilion (klaus3000) Attached to Project - sip-router Summary - wrong TM response code Task Type - Bug Report Category - Core Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - Linux Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - Hi! I have a strange scenario where TM forwards the wrong response code: client A proxy ---INV A----------> <--407------------- ---ACK------------> ---INV A----------> <--------INV A----- ---------482 loop-> <--407------------- ^^^^ bug: should be 482 I made same tests: It does not happen always. In the scenarios where I had this problem the caller called himself. Log is attached. I used today's kamailio-3.0 from git (2010-02-26) One or more files have been attached. More information can be found at the following URL: 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, 10 months

[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, 10 months

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, 10 months

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, 10 months

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, 10 months

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, 10 months

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, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev