Daniel-Constantin Mierla writes:
> well, $branch is actually not dealing with r-uri branch in
> request_route. branch_route deals with current branch in tm, which can
> be an additional branch to the r-uri and $branch() with proper index
> should work to retrieve the details. But it might not b
On 18/04/14 18:03, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The $branch(...) var might need to be extended for instance. Also, not
sure it gets the right values in branch_route... but it is a way to try
if you haven't done it already.
according to wiki, $branch only deals with add
Daniel-Constantin Mierla writes:
> The $branch(...) var might need to be extended for instance. Also, not
> sure it gets the right values in branch_route... but it is a way to try
> if you haven't done it already.
according to wiki, $branch only deals with additional branches, not the
main bran
On 18/04/14 17:37, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
As an option to implement now, try using hash table to store attributes
using keys like:
$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru) = $ru;
$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::du) = $du;
.
Daniel-Constantin Mierla writes:
> As an option to implement now, try using hash table to store attributes
> using keys like:
>
> $sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru) = $ru;
> $sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::du) = $du;
> ...
>
> Then use them to create
Daniel-Constantin Mierla writes:
> I pushed a patch to mater, can you try it? If ok, you can backport it
> as you need.
i tried and now $T(branch_index) is ok also in branch-failure route.
thanks,
-- juha
___
SIP Express Router (SER) and Kamailio (Op
I pushed a patch to mater, can you try it? If ok, you can backport it as you
need.
Cheers,
Daniel
Daniel-Constantin Mierla
http://www.asipto.com
> On 17 Apr 2014, at 16:07, Juha Heinanen wrote:
>
> Daniel-Constantin Mierla writes:
>
>> Can you print also the htable key to see which of its va
Daniel-Constantin Mierla writes:
> Can you print also the htable key to see which of its values are not
> set? Like:
>
> xlog("key is: t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru\n");
>
> in both places.
Apr 17 17:06:23 siika /usr/sbin/sip-proxy[5957]: INFO: Key in branch route is:
t=
On 17/04/14 08:31, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It would require C coding to get it nicely, I see three options:
- try to get the values as in branch_route -- seems complex at first look
- try to get the values via $T_branch(attr) -- sounds simpler now
- try to get a f
Daniel-Constantin Mierla writes:
> It would require C coding to get it nicely, I see three options:
> - try to get the values as in branch_route -- seems complex at first look
> - try to get the values via $T_branch(attr) -- sounds simpler now
> - try to get a function t_reuse_branch() -- create a
On 16/04/14 18:46, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Why would you need all attributes of the branch that just failed, do you
want to send the request to the same destination again?
that is exactly the requirement. the idea is to assign some avps/branch
flags differently
Daniel-Constantin Mierla writes:
> Why would you need all attributes of the branch that just failed, do you
> want to send the request to the same destination again?
that is exactly the requirement. the idea is to assign some avps/branch
flags differently so that mediaproxy-offer in branch rout
On 16/04/14 18:29, Juha Heinanen wrote:
Hugh Waite writes:
As you and Daniel saw from the code, I replicated the behaviour of the
'failure-route' but with the current branch index. I didn't deliberately
choose the behaviour of $ru etc. so I'm happy with it being classed as a bug
if that's what
: 14 April 2014 22:56
To: Juha Heinanen
Cc: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] event_route[tm:branch-failure] question
On 14/04/14 21:15, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
To get the branch attributes, the code should be similar to execution
of failur
Hugh Waite writes:
> As you and Daniel saw from the code, I replicated the behaviour of the
> 'failure-route' but with the current branch index. I didn't deliberately
> choose the behaviour of $ru etc. so I'm happy with it being classed as a bug
> if that's what's expected in this situation.
>
>
ve something different in this situation?
Regards,
Hugh
-Original Message-
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of
Daniel-Constantin Mierla
Sent: 14 April 2014 22:56
To: Juha Heinanen
Cc: Kamailio (SER) - Users Mailing List
Subje
On 14/04/14 21:15, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
To get the branch attributes, the code should be similar to execution of
failure_route. In failure_route, the attributes are taken from winning
branch. In branch-failure, the attributes should be taken from current
branch
Daniel-Constantin Mierla writes:
> To get the branch attributes, the code should be similar to execution of
> failure_route. In failure_route, the attributes are taken from winning
> branch. In branch-failure, the attributes should be taken from current
> branch. But in both cases is dealing wi
On 14/04/14 15:18, Juha Heinanen wrote:
daniel,
what would it take to make append_branch() call in branch-failure route
to re-create the branch of the corresponding branch route? is that
currently possible by any means? if not, what new stuff would need to
be introduced?
I haven't had time to
On 14/04/14 15:11, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Flags needs to be re-sync'ed on the other hand:
http://kamailio.org/docs/modules/stable/modules/tmx.html#idp24432
could that function be used as a model to re-sync also other transaction
attributes?
If someone needs some
daniel,
what would it take to make append_branch() call in branch-failure route
to re-create the branch of the corresponding branch route? is that
currently possible by any means? if not, what new stuff would need to
be introduced?
-- juha
___
SIP Ex
Daniel-Constantin Mierla writes:
> Flags needs to be re-sync'ed on the other hand:
> http://kamailio.org/docs/modules/stable/modules/tmx.html#idp24432
could that function be used as a model to re-sync also other transaction
attributes?
on the other hand, we have been discussing here branch attri
On 14/04/14 14:43, Alex Hermann wrote:
On Monday 14 April 2014, Daniel-Constantin Mierla wrote:
Incoming request is stored in transaction with all the changes done in
request_route until the transaction is created. A matter of what was the
r-uri at the moment of creating transaction, you will r
On Monday 14 April 2014, Daniel-Constantin Mierla wrote:
> Incoming request is stored in transaction with all the changes done in
> request_route until the transaction is created. A matter of what was the
> r-uri at the moment of creating transaction, you will retrieve it in the
> tm specific routi
Daniel-Constantin Mierla writes:
> The fix (or a new option to run if the current behavior was wanted by
> developer) is to run branch-failure with the attributes from outgoing
> request of the branch (not the incoming request, as it is now).
i got it now. in my opinion, attributes of branch-f
On 14/04/14 11:59, Juha Heinanen wrote:
i called t_newtran() also when request came from proxy itself and after
that $ru was aor, not contact uri, in branch-failure route also during
the second iteration.
so somehow calling t_newtran() before t_relay() breaks branch-failure
route. it would be n
i called t_newtran() also when request came from proxy itself and after
that $ru was aor, not contact uri, in branch-failure route also during
the second iteration.
so somehow calling t_newtran() before t_relay() breaks branch-failure
route. it would be nice to get it fixed.
-- juha
___
Daniel-Constantin Mierla writes:
> Print $ru before the function that creates the transaction (t_relay() or
> t_newtran() in config) and see if they are the same for the two cases.
> If yes, then you have to look inside tm code for this event route -- I
> am not the developer of this features,
On 14/04/14 10:50, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Incoming request is stored in transaction with all the changes done in
request_route until the transaction is created. A matter of what was the
r-uri at the moment of creating transaction, you will retrieve it in the
tm s
Daniel-Constantin Mierla writes:
> Incoming request is stored in transaction with all the changes done in
> request_route until the transaction is created. A matter of what was the
> r-uri at the moment of creating transaction, you will retrieve it in the
> tm specific routing blocks when such
On 14/04/14 10:35, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I guess the event route is executed with the incoming request. I would
expect to have there the branch attributes, but I haven't developed the
feature.
it would be important to get access to branch attributes in
branch-fa
Daniel-Constantin Mierla writes:
> I guess the event route is executed with the incoming request. I would
> expect to have there the branch attributes, but I haven't developed the
> feature.
it would be important to get access to branch attributes in
branch-failure event route so that when appe
I guess the event route is executed with the incoming request. I would
expect to have there the branch attributes, but I haven't developed the
feature.
Perhaps you should look inside tm module at execution of branch
route/failure route to see how they take the branch attributes and
compare, t
i did some more tests and got very puzzling result. this time i tested
with 488 response, but response code does not matter.
sip proxy forwards invite based on location lookup to contact of
registered local user:
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[8001]: INFO: INVITE
is to local user
A
in branch route i execute:
t_on_branch_failure("contact");
xlog("L_INFO", "Routing $rm <$ru> to contact\n");
and in branch_failure route i have:
event_route [tm:branch-failure:contact] {
if (t_check_status("486")) {
xlog("L_INFO", "Got 486 response to <$ru>\n");
35 matches
Mail list logo
