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!
Kamailio by default doesn't compile on OS/X Mavericks.
$ make
generating autover.h ...
/Applications/Xcode.app/Contents/Developer/usr/bin/make --no-print-directory -wC . cfg-defs
target architecture <x86_64>, host architecture <x86_64>
making config...
CC (gcc) [kamailio] action.o
error: invalid value '9' in '-O9'
make: *** [action.o] Error 1
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
Anyone that has found an optimal way to patch the Makefile?
/O
I could not load the dialog module, because of a linking problem with the symbol destroy_dlg.
Found that it's declared "inline" twice which may cause an issue. With this change, that I don't dare to commit myself, I could load dialog and explore it. Can someone take a look at this, someone that understands dialog and stuff?
This was on OS/X.
Thanks
/O
diff --git a/modules/dialog/dlg_hash.h b/modules/dialog/dlg_hash.h
index 6994256..174ef15 100644
--- a/modules/dialog/dlg_hash.h
+++ b/modules/dialog/dlg_hash.h
@@ -214,7 +214,7 @@ static inline void unlink_unsafe_dlg(dlg_entry_t *d_entry, dlg_cell_t *dlg)
* \brief Destroy a dialog, run callbacks and free memory
* \param dlg destroyed dialog
*/
-inline void destroy_dlg(dlg_cell_t *dlg);
+void destroy_dlg(dlg_cell_t *dlg);
/*!
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#440 - CRASH: segmentation fault if there is no dispatcher available
User who did this - Nuno Miguel Reis (nmreis)
----------
Hi Daniel.
I noticed now that i'm getting: tm [tm.c:1518]: _w_t_relay_to(): ERROR: w_t_relay_to: unsupported route type: 64 a lot
By looking at source code i see that there is now handling for route type: LOCAL_ROUTE in _w_t_relay_to(...). Shouldn't we add something here at least to avoid the constant loggging?
Looking forward to here from you.
Nuno.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=440#comment1532
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.
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