April 2013 - sr-dev - kamailio.org

[tracker] Assignee added: Assignment operators don't work
by sip-router 29 May '26

29 May '26

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#100 - Assignment operators don't work User who did this - Alex Hermann (axlh) http://sip-router.org/tracker/index.php?do=details&task_id=100 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.

10 9

git:master: pv: use suip2a(...) for $snd(..)
by Daniel-Constantin Mierla 04 Dec '25

04 Dec '25

Module: sip-router Branch: master Commit: e151a9e99b1fed7805eaed5d16ca3d6466e1f517 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e151a9e… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Mon Jul 18 22:37:07 2011 +0200 pv: use suip2a(...) for $snd(..) - fixes FS#140, reported by Klaus Darilion --- modules_k/pv/pv_branch.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules_k/pv/pv_branch.c b/modules_k/pv/pv_branch.c index a9dd1bc..4081429 100644 --- a/modules_k/pv/pv_branch.c +++ b/modules_k/pv/pv_branch.c @@ -395,7 +395,7 @@ int pv_get_sndto(struct sip_msg *msg, pv_param_t *param, (int)snd_inf->len); default: /* 0 - ip */ - s.s = su2a(snd_inf->to, sizeof(*snd_inf->to)); + s.s = suip2a(snd_inf->to, sizeof(*snd_inf->to)); s.len = strlen(s.s); return pv_get_strval(msg, param, res, &s); }

2 1

Outbound flow failure handling merged to master
by Hugh Waite 23 Nov '16

23 Nov '16

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.

4 11

Using t_suspend()/t_continue() multiple times on the same transaction
by Peter Dunkley 02 Jul '14

02 Jul '14

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

5 12

default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
by Iñaki Baz Castillo 19 Feb '14

19 Feb '14

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>

5 21

t_suspend and t_continue in tm module
by Richard Good 12 Jul '13

12 Jul '13

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

2 7

git:master: modules_k/uac: uac_replace_from/to AUTO mode with dialog module
by Anca Vamanu 27 Jun '13

27 Jun '13

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…

2 1

sercmd dlg.list bug
by Alex Balashov 22 May '13

22 May '13

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/

3 8

Using GRUU and outbound
by Peter Dunkley 03 May '13

03 May '13

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

5 17

rfc: accounting records time details
by Daniel-Constantin Mierla 01 May '13

01 May '13

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 *

2 2