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>
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…
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
Am Dienstag, 5. Februar 2013, 13:55:41 schrieb Charles Chance:
>> as the original author of the module I'd think that changing or replacing
>> the existing module would be the way to go. So far I'd not recieved that
>> much of bug reports against the existing module. And as Alex Balashov also
>> mentioned recently, there are some other issues with the current library.
>>
>> If existing users need to stay with the old module, its available in the
>> git and the existing releases, for the new release we should go with a
>> module which supports the newer library.
>>
>> It would be nice if you could stay with the existing PV API, which I
>> modelled somehow after the htable module. If you need to change something,
>> just announce it on the devel list and ask for feedback.
> We have indeed used the module in the past with no issues - so thank you for
> writing and sharing :)
>
> Very happy to stay with existing PVs if possible. The only thing I'd like to
> see different is to set value and expiry at the same time, instead of
> having to set value, then alter expiration. This has to be better than
> setting a value with some default expiry, getting that same value back
> again, then re-setting the value once more with a different expiry?
>
> Could this be implemented at PV level? Something like $mct(key:expiry) =
> value? And if expiry is omitted, we use default set in params.
Hi Charles,
thanks, good to know that you use it. :-) With regards to the expiry value,
yes I think this could be implemented like this. Just one remark, the syntax
that other PVs uses is "=>", like in
http://www.kamailio.org/wiki/cookbooks/3.3.x/pseudovariables#sht_htable_key
Then it would be $mct(key=>expiry) = value
Best regards,
Henning Westerholt
Hello,
I want to add a new function to the registrar module that will allow me
to remove a contact from the location table when I receive a 430 from an
edge proxy.
I believe I can use the get_ucontact_by_instance() function from usrloc
to remove the exact contact I want (based on contact address,
sip.instance, and reg-id). However, at the point at which I have
received a 430 from the edge proxy (in the failure_route[] on the
registrar) I am not sure how I can determine the sip.instance and
reg-id. As far as I can tell neither of these values is added to the
request when the registrar:lookup() exported function is called.
I don't want to just remove contacts based on address, or even address
and sip.instance, because when outbound is used I will have multiple
contacts with the same address and sip.instance values, with only the
reg-id different.
Does anyone have any suggestions as to how I can obtain this information
in a failure_route[]?
Regards,
Peter
Hi!
I might have missed something, but I fail to see how to set up this scenario:
I have an AOR with two registred phones. Two reg-id's per phone, four contacts in all.
I call the AOR and one phone starts ringing, the other call leg gets a 430 Flow Failed from the edge proxy.
How to I retry the next flow? We're not hitting the failure route, since one phone is ringing.
Do we need a BRANCH_FAILURE_ROUTE to handle retargeting in a branch while we're in an open transaction?
/O