sr-dev April 2013

sr-dev@lists.kamailio.org

38 participants
401 discussions

Outbound flow failure handling merged to master

by Hugh Waite

Hello, As you will see I have merged my branch back into master. These changes add a new event route [tm:branch-failure] to the tm module which is run when any failure response is received on a transaction. The event_route uses a new route type BRANCH_ROUTE which limits the functions that can be run in the route. The functions t_check_status(), t_next_contact_flow(), t_relay() and unregister() can be used in this route. A new pv $T_reply_ruid is accessible in this route which can be used to unregister a single contact entry. The following example route can be used on a registrar to handle failed or invalid flows: event_route[tm:branch-failure] { xlog("L_INFO", "event_route[tm:branch-failure]\n"); if (t_check_status("430|403")) { if (!unregister("location", "$tu", "$T_reply_ruid")) { xlog("L_WARN", "failed to unregister $tu with ruid $T_reply_ruid\n"); } if (!t_next_contact_flow()) { xlog("L_INFO", "No more flows\n"); } else { xlog("L_INFO", "Next flow\n"); t_relay(); } } } Any bugs, memory leaks etc. let me know! Hugh -- Hugh Waite Principal Design Engineer Crocodile RCS Ltd.

7 years, 7 months

Using t_suspend()/t_continue() multiple times on the same transaction

by Peter Dunkley

Hi, I am trying to use t_suspend()/t_continue() multiple times on the same transaction. Calling t_suspend() more than once works, but the second time I call t_continue() the transaction is killed and a 500 response is sent. It is the "if (branch == t->nr_of_outgoings)" check from the code fragment below (from t_suspend.c:t_continue()) that results in the transaction being killed - you can see the debug/error line I added to determine this in the fragment. Is using t_suspend()/t_continue() multiple times something that should work? Thanks, Peter if (t->uas.status < 200) { /* No final reply has been sent yet. * Check whether or not there is any pending branch. */ for ( branch = 0; branch < t->nr_of_outgoings; branch++ ) { if ((t->uac[branch].request.buffer != NULL) && (t->uac[branch].last_received < 200) ) break; } if (branch == t->nr_of_outgoings) { /* There is not any open branch so there is * no chance that a final response will be received. */ ret = 0; LM_ERR("branch == t->nr_of_outgoings\n"); goto kill_trans; } } -- Peter Dunkley Technical Director Crocodile RCS Ltd

10 years

default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665

by Iñaki Baz Castillo

Hi, the new RFC 6665 mandates that the subscription dialog is made *after* the first NOTIFY from the UAS (rather than after the 200 to the initial SUBSCRIBE). This means that the UAC MUST take the route set from the *first* received NOTIFY (instead of taking it from the 200 to the initial SUBSCRIBE). Therefore a proxy compliant with RFC 6665 MUST always add RR to in-dialog NOTIFY requests and thus, I propose that the default SR script file implements it. Regards. -- Iñaki Baz Castillo <ibc(a)aliax.net>

10 years, 4 months

t_suspend and t_continue in tm module

by Richard Good

Hi We are using the t_suspend and t_continue functionality to asynchronously send Diameter messages. This works nicely when we suspend and resume on a SIP request. However in some circumstances we want to send a Diameter message on a SIP response. I have found that the SIP responses continue to be relayed despite being suspended and returning 0 to the cfg file. I am investigating the cause but before I get any deeper does anyone know if the t_suspend and t_continue functionality in the tm module can be used on a SIP response? Regards Richard. This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer

11 years

git:master: modules_k/uac: uac_replace_from/to AUTO mode with dialog module

by Anca Vamanu

Module: sip-router Branch: master Commit: 0f702f6e236eb0cbb238bf83a0c4ae94d7b3cad8 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0f702f6… Author: Anca Vamanu <anca.vamanu(a)1and1.ro> Committer: Anca Vamanu <anca.vamanu(a)1and1.ro> Date: Thu Jul 19 17:49:13 2012 +0300 modules_k/uac: uac_replace_from/to AUTO mode with dialog module Added a implementation for uac_replace_from/to() that uses the dialog module for AUTO mode. In this mode the URIs are stored as dialog variables. The change in tm module fixes a bug: if uac_replace_to() was called, the URI was not changed accordingly in Cancel. --- modules/tm/t_cancel.c | 5 +- modules_k/dialog/dialog.c | 2 + modules_k/dialog/dlg_load.h | 6 + modules_k/uac/README | 111 +++++++++++----- modules_k/uac/doc/uac_admin.xml | 68 +++++++++- modules_k/uac/replace.c | 292 ++++++++++++++++++++++++++++++--------- modules_k/uac/uac.c | 17 ++- 7 files changed, 393 insertions(+), 108 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=0f7…

11 years

sercmd dlg.list bug

by Alex Balashov

Hello, When I run this: kamctl fifo dlg_list | grep '^dialog' | wc -l I get 38 dialogs. When I run this: sercmd -s unixs:/tmp/kamailio_ctl dlg.list | egrep '^hash' | wc -l I get 8 dialogs, rain or shine. Has anyone heard of this bug? Running the latest 3.3 pull... Thanks, -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

11 years, 1 month

Using GRUU and outbound

by Peter Dunkley

Based on the discussions about outbound and in-dialog routing it seems like we need to use GRUU and live with the fact that the route-set changes (in breach of RFC 3261). Can anyone share a Kamailio registrar configuration that uses GRUU to look-up in-dialog requests (preferably one that makes use of t_load_contacts(), t_next_contact(), and t_next_contact_flow())? Regards, Peter

11 years, 2 months

rfc: accounting records time details

by Daniel-Constantin Mierla

Hello, there were old and recent discussions about the representation of time in accounting records. At this moment the acc module stores the unix timestamp as datetime value. In some countries is required to store more accuracy, beyond the seconds. Also, the datetime gives some troubles with converting back to unix timestamp, specifically with time zones and daylight saving times. I want to open a discussion that is visible for all users and devs, being something affecting probably everyone, input from anyone that is interested being relevant to select the right approach. Here are some suggestions presented so far. 1) store seconds.miliseconds as double - there is a patch (which probably needs some tunings itself) on tracker. The precision is shifted from seconds to milliseconds. Internally computed from microseconds from timeval structure. The other modules might need updates (iirc dbtext has only 2 decimals precisions for double, while miliseconds will require at least three -- could be the case for flatstore or other modules). Advantage is the computing of duration directly by subtraction of two values. 2) store seconds and microseconds as two separate values. Should be no issues with existing modules. Even more accuracy than above, no issues with other modules, but will require to use two columns (thus four values to compute the duration) Any other suggestions? Personally, at this moment, I will go with 2), but that might not meet everyone's needs. So a solution can be to make it configurable, as a bitmask of what time representation to store. Say, there will be a new parameter timestamp_mode for acc module: - bit one set - store seconds timestamp as for now (default) - bit two set - store seconds and microseconds in separate integer columns - bit three set - store seconds.miliseconds as double value in one column I could add the parameter and tune acc for bit one and two. For bit three a deeper review is needed for other modules, probably the developer that submitted to the tracker can do it. More suggestions? Pro or cons opinions? Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24016, 2013 * http://asipto.com/u/katu *

11 years, 2 months

[tracker] Comment added: usrloc: Add missing RPC commands (Attachment added)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#290 - usrloc: Add missing RPC commands User who did this - Víctor Seva (linuxmaniac) ---------- ul.add patch reworked. Fetch all parameters at once. Use doble temp var for q param. Use double2q function to convert value. ---------- 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=290#comment865 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.

11 years, 2 months

[tracker] Comment added: usrloc: Add missing RPC commands (Attachment added)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#290 - usrloc: Add missing RPC commands User who did this - Víctor Seva (linuxmaniac) ---------- Fix q param type on ul.add RPC command. Thanks Juha Heinanen <jh(a)tutpro.com> ---------- 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=290#comment864 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.

11 years, 2 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2013