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.
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
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.
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.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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
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.
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
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.