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 the new
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:
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
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
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 be
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 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
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:
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 j...@tutpro.com wrote:
Daniel-Constantin Mierla writes:
Can you print also the htable key to see which
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
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
Subject: Re: [SR-Users] event_route
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.
Does
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 failure_route. In failure_route
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
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 route
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
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,
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
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
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: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
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,
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
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
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
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 routing
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
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
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
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
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
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 with
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
33 matches
Mail list logo
