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
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>
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
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…
Hello,
I'm currently debugging a segfault in the presence module, which is
caused by it recursively calling srdb1 functions on the same db handle,
which at least under db_mysql doesn't work and causes segfault. I was
wondering what the preferred fix would be: Fix presence module so it
doesn't do that, or fix db_mysql so that recursive queries are possible.
Personally I'd prefer the second option, but AFAICS it would require
some changes to srdb1 itself. Any other options I'm not seeing?
cheers
I think we need to make a decision regarding the mediaproxy module. The development team no longer supports Kamailio and I think the module doesn't support recent releases of the mediaproxy.
Any thoughts?
/O
Hello,
I thought some people may have spare cycles and are willing to help with
the documentation. Here is some updates I would like to get for modules:
1) adding ids for parameters, functions, and other sections of the
docbook xml files. Now we generate the alphabetic indexes pointing to
the online html readmes, would be better to point directly to the exact
section. Practically, for example, sections such as next from async module:
<section>
<title><varname>workers</varname> (int)</title>
should become:
<section id="async.p.workers">
<title><varname>workers</varname> (int)</title>
To get unique ids over all files, I suggest using following pattern:
[module name] [dot] [type] [dot] [title]
The [type] should be:
- p - parameters
- f - functions
- m - mi commands
- r - rpc commands
- s - statistics
2) Add RPC commands to readmes -- some of modules already do, but many
don't. There is a perl script that should get the list of RPC commands
from source code, but it requires some patch to a perl lib, not working
on all systems. Moreover, the output is quite minimalistic, not easy to
improve the content or add examples. Last generated index is:
- http://www.kamailio.org/docs/docbooks/3.4.x/rpc_list/rpc_list.html
3) Document selects -- although their name are quite suggestive, a bit
of text around won't harm.
- http://www.kamailio.org/wiki/cookbooks/devel/selects
Because 1) and 2) requires git access, the easiest way to contribute is
to provide patches to the xml files. If anyone commits to do an
extensive work on these tasks in short term, we may eventually arrange
for git access. The 3) is in the wiki, everyone can register an account
and then update the pages.
I would recommend these guidelines to be followed from now on by
developers when adding new elements to the module documentation.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#280 - OpenBSD5.2 Crash on t_relay()
User who did this - Jody Rudolph (jrudolph)
----------
If it's possible, I cant seem to find out how. Closing this out and giving up on OpenBSD-SPARC.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=280#comment815
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.