sr-dev August 2014

sr-dev@lists.kamailio.org

25 participants
195 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.

8 years

TM possible deadlock

by Jason Penton

Hi All, I have been experiencing a deadlock when a timeout occurs on a t_relayed() INVITE. Going through the code I have noticed a possible chance of deadlock (without re-entrant enabled). Here is my thinking: t_should_relay_response() is called with REPLY_LOCK when the timer process fires on the fr_inv_timer (no response from the INVITE that was relayed, other than 100 provisional) and a 408 is generated. However, from within that function there are calls to run_failure_handlers() which in turn *could* try and lock the reply (viz. somebody having a t_reply() call in the cfg file - in failure route block). This would result in another lock on the same transaction's REPLY_LOCK.... Has anybody else experienced something like this? this is on master btw. Cheers Jason

9 years, 7 months

Fw: query related to NOTIFY message size

by Piyush.Bansal＠relianceada.com

please help ----- Forwarded by Piyush Bansal/RCOM/RelianceADA on 10/10/2013 10:51 AM ----- From: Piyush Bansal/RCOM/RelianceADA To: serusers(a)iptel.org, serdev(a)iptel.org Date: 10/09/2013 12:14 PM Subject: query related to NOTIFY message size Hi there, I have certain queries regarding batch SUBSCRIBE and NOTIFY. I have a user who has 100 buddies in his buddy list. If any of his buddy changes his/her presence status, that user gets a NOTIFY message with presence status of all the 100 buddies. In that case, the message size is exceeding 500 KB. Thats quite a higher value for a UDP packet. Can anybody suggest- 1. If there is any way to restrict the size of the packet. 2. How to ensure that the packet is received correctly by the client. Thanks and Regards, --Piyush Bansal The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.

10 years, 1 month

RFC: updating default values

by Daniel-Constantin Mierla

Hello, I am opening this discussion to decide if there is need to adjust some of the default values we have in Kamailio. Many of them were set even like 10 years ago, so they might not be very actual anymore. The main goal is to get the best possible settings for common usage. To start with, here are some values that should be reviewed: - default private memory is 4MB - if the config is not that small, it might not be sufficient free pkg to play with (e.g., for sql_query() result, storage of $var(...) values). Should it be increased to 8MB or other value? Debian/Centos have startup script that sets its value to 8 via command line - default shared memory is 32MB - for a decent deployment with tm, location, lcr/dispatcher, permissions, and anti-flood, it might leave not much free space. Should we double it or set to a different value - usrloc - db_ops_ruid should enabled (1) - seems stable, without it there are problems updating/deleting location records when UA changes the call-id for same contact address. - usrloc - hash_size - now is 9, which results in 512 slots, meaning is ok for few thousands of registered users, for more, performance will decrease when doing save/lookup location -- should it be made 10 (1024 slots for internal hash table)? - auth_db - load_credentials defaults to 'rpid', meaning that the query to get the password will retrieve also the rpid column. I haven't see rpid being used that much lately (replaced by PAI/PPI). I would make this parameter empty by default to avoid querying for an extra column that is likely to be empty. Perhaps there are more, I just wanted to get started. Reply with your comments to above list as well as add new items you thinks their default values should be adjusted. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

10 years, 1 month

Is there a sense in calling run_onsend() after the msg_send() function?

by Lucian Balaceanu

Hi, I am currently trying to understand some kamailio code and came across this construct inside do_forward_reply() function (code in italics is not part of upstream kamailio): *do_forward_reply(struct sip_msg* msg, int mode){* ... ... apply_force_send_socket(&dst, msg); if (msg_send(&dst, new_buf, new_len)<0) { STATS_RPL_FWD_DROP(); goto error; } /* ... dst.send_sock=get_send_socket(msg, &dst.to, dst.proto); ... run_onsend(msg, &dst, new_buf, new_len);*/ *}* Is there really a sense in calling run_onsend() after the msg_send() function? In my understanding (based on onsend_route uasge) run_onsend() is used to make some last minute changes before a message is sent to a destination. Thank you, Lucian Balaceanu

10 years, 1 month

invalid auth.xml docbook reference

by Juha Heinanen

file modules/auth/auth.xml reference docbook file http://www.oasis-open.org/docbookid/id/g/4.5/docbookx.dtd which does not exist. could it be changed to, for example, reference http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd which does exist? -- juha

10 years, 2 months

How to uniquely identify SIP WS / WSS endpoint

by Muhammad Shahzad

Sorry for putting this question on both dev and user mailing lists, as it is a rather theoretical question and i hope some SIP guru on either mail list will answer. For non-WS endpoints which use TCP or UDP for SIP transport, each upstream request has top most VIA header pointing to the previous hop which forwarded the request to current hop while each downstream request has top most VIA header pointing to next hop to which it will be forwarded from current hop. But for WS endpoints, the top most VIA has dummy static value, so there is no way to identify who sent this request or to whom the reply is going to. Please note that i am not specifically interested in network address of remote endpoint (though VIA header is suppose to provide it), i only need to match requests and responses from / to a specific device using SIP v2.0 standard. Any help is highly appreciated. Thank you.

10 years, 2 months

Roadmap to next major release - v4.2.0

by Daniel-Constantin Mierla

Hello, during the last devel meeting on IRC, done before the summer, we set the 4.2.0 release time frame for this autumn. As planned by that moment, we have to decide the development freezing date and more accurate milestones at the end of summer, therefore it is about the time. My proposal is to freeze development by end of September 10, 2014, have about one month of testing and release sometime around mid of October. If anyone has constraints to meet this date, just send here another proposal and we can decide together which one fits most of us. This one gives about 2 weeks and a half for new features development. Therefore, if you plan to include a new module (many were announced at the IRC devel meeting, hopefully some are ready), hurry up. It is also a good time to start filling the wiki page with what is new in upcoming release: - http://www.kamailio.org/wiki/features/new-in-devel Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

10 years, 2 months

accessing database from a child forked process

by Luis Azedo

Hi, i have a module that creates 1 extra process where it processes stuff in a loop. on some condition i fire a route_event with a fakemsg and its up to the user of the module to take action, it tries to work like dispatcher module or htable (mod-init) events. the problem that i have is that, if i call some function on some module that performs a database action, the connection is null when it calls use_table. in this case i'm making this call event_route[my_module:my_event] { $var(my_uri) = <<result of some operations>>; pres_refresh_watchers("$var(my_uri)", "dialog", 1); } presence module makes the call to use_table but this call fails because the connection is null. presence module is working fine besides this. if i make this call inside event_route[dispatcher:dst-up] it works. i think that dispatcher fires the event inside a callback from a registered timer, so, i think (may be wrong) that it comes from a different process ? i wonder if i'm missing something from child_init ? need to register something ? thanks for your help.

10 years, 2 months

git:master: cdp: removed empty functions sections from docs

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: f096ee13ca09d79d3f0e8fa5c73a6e14987d8317 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=f096ee1… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Aug 29 23:14:19 2014 +0200 cdp: removed empty functions sections from docs --- modules/cdp/README | 26 ++++++++++++++++++-------- modules/cdp/doc/cdp_admin.xml | 9 --------- 2 files changed, 18 insertions(+), 17 deletions(-) diff --git a/modules/cdp/README b/modules/cdp/README index a2e4ff4..882b004 100644 --- a/modules/cdp/README +++ b/modules/cdp/README @@ -33,9 +33,10 @@ Richard Good 4.1. config_file (string) 4.2. latency_threshold (int) - 5. Functions + 5. RPC Commands - 5.1. + 5.1. cdp.disable_peer + 5.2. cdp.enable_peer 6. Configuration Examples @@ -138,9 +139,10 @@ Chapter 1. Admin Guide 4.1. config_file (string) 4.2. latency_threshold (int) - 5. Functions + 5. RPC Commands - 5.1. + 5.1. cdp.disable_peer + 5.2. cdp.enable_peer 6. Configuration Examples @@ -225,12 +227,20 @@ modparam("cdp", "config_file", "/etc/kamailio/diametercfg.xml") modparam("cdp", "latency_threshold", 1000) ... -5. Functions +5. RPC Commands - 5.1. + 5.1. cdp.disable_peer + 5.2. cdp.enable_peer - No functions available from configuration. See API for internal - functions. + exported RPC commands. + +5.1. cdp.disable_peer + + instantly disable a particular diameter peer. + +5.2. cdp.enable_peer + + enabe/re-enable a diameter peer 6. Configuration Examples diff --git a/modules/cdp/doc/cdp_admin.xml b/modules/cdp/doc/cdp_admin.xml index 904b193..cdf65d2 100644 --- a/modules/cdp/doc/cdp_admin.xml +++ b/modules/cdp/doc/cdp_admin.xml @@ -129,15 +129,6 @@ modparam("cdp", "latency_threshold", 1000) </section> <section> - <title>Functions</title> - - <section> - <para>No functions available from configuration. See API for internal - functions.</para> - </section> - </section> - - <section> <title>RPC Commands</title> <para>exported RPC commands.</para>

10 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 August 2014