13 Apr
2014
13 Apr
'14
9:52 p.m.
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");
};
and i get to syslog:
Apr 13 21:44:07 siika /usr/sbin/sip-proxy[17475]: INFO: Routing INVITE
<sip:test-0x11107b0@192.98.102.30:5064> to contact
Apr 13 21:44:11 siika /usr/sbin/sip-proxy[17437]: INFO: Got 486 response to
<sip:test@test.tutpro.com>
why has $ru in branch_failure route changed from $ru of the branch to
original request uri (aor)?
i would expect to see in $ru of branch_failure route the $ru of the
branch. is this a bug? if not, is there any means in branch_failure
route to get access to the branch that failed.
-- juha
14 Apr
14 Apr
9:29 a.m.
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
<sip:test@test.tutpro.com> is to local user <test(a)test.tutpro.com>
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[8001]: INFO: Routing INVITE
<sip:test@192.98.102.30:5054> to contact
in branch route these two statements are executed:
t_on_branch_failure("contact");
xlog("L_INFO", "Routing $rm <$ru> to contact\n");
uas replies with 488 which causes this branch-failure route to be
executed:
event_route [tm:branch-failure:contact] {
if (t_check_status("488")) {
xlog("L_INFO", "Got 488 response to <$ru>\n");
append_branch();
xlog("L_INFO", "Relaying to <$ru>\n");
route(RELAY_TO_CONTACTS);
exit;
};
};
and i get to syslog:
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7952]: INFO: Got 488 response to
<sip:test@test.tutpro.com>
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7952]: INFO: Relaying to
<sip:test@test.tutpro.com>
note that in above $ru is aor, not contact uri, of the callee, which is
the same problem that i described in previous message. for that reason,
route(RELAY_TO_CONTACTS) causes the request to be routed back to the
proxy itself:
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7952]: INFO: Routing INVITE to
contact <sip:test@test.tutpro.com> to proxy itself
proxy reports that it receives the request and is processes it exactly
the same way as previously, except that this time magic happens and $ru
in branch_failure route is not aor like it was before but it is the
contact uri like it should have been already during the first iteration:
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7953]: INFO: INVITE
<sip:test@test.tutpro.com> by <sip:jh@test.tutpro.com> is from Proxy Itself
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7953]: INFO: INVITE
<sip:test@test.tutpro.com> is to local user <test(a)test.tutpro.com>
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7953]: INFO: Routing INVITE
<sip:test@192.98.102.30:5054> to contact
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7951]: INFO: Got 488 response to
<sip:test@192.98.102.30:5054>
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7951]: INFO: Relaying to
<sip:test@192.98.102.30:5054>
can someone explain how/why behavior changes and why during the first
execution of branch_failure route, $ru is not what it should be?
-- juha
11:08 a.m.
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, to be sure is what I guessed or not.
Cheers,
Daniel
On 14/04/14 08:29, Juha Heinanen wrote:
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
<sip:test@test.tutpro.com> is to local user <test(a)test.tutpro.com>
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[8001]: INFO: Routing INVITE
<sip:test@192.98.102.30:5054> to contact
in branch route these two statements are executed:
t_on_branch_failure("contact");
xlog("L_INFO", "Routing $rm <$ru> to contact\n");
uas replies with 488 which causes this branch-failure route to be
executed:
event_route [tm:branch-failure:contact] {
if (t_check_status("488")) {
xlog("L_INFO", "Got 488 response to <$ru>\n");
append_branch();
xlog("L_INFO", "Relaying to <$ru>\n");
route(RELAY_TO_CONTACTS);
exit;
};
};
and i get to syslog:
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7952]: INFO: Got 488 response to
<sip:test@test.tutpro.com>
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7952]: INFO: Relaying to
<sip:test@test.tutpro.com>
note that in above $ru is aor, not contact uri, of the callee, which is
the same problem that i described in previous message. for that reason,
route(RELAY_TO_CONTACTS) causes the request to be routed back to the
proxy itself:
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7952]: INFO: Routing INVITE to
contact <sip:test@test.tutpro.com> to proxy itself
proxy reports that it receives the request and is processes it exactly
the same way as previously, except that this time magic happens and $ru
in branch_failure route is not aor like it was before but it is the
contact uri like it should have been already during the first iteration:
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7953]: INFO: INVITE
<sip:test@test.tutpro.com> by <sip:jh@test.tutpro.com> is from Proxy Itself
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7953]: INFO: INVITE
<sip:test@test.tutpro.com> is to local user <test(a)test.tutpro.com>
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7953]: INFO: Routing INVITE
<sip:test@192.98.102.30:5054> to contact
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7951]: INFO: Got 488 response to
<sip:test@192.98.102.30:5054>
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7951]: INFO: Relaying to
<sip:test@192.98.102.30:5054>
can someone explain how/why behavior changes and why during the first
execution of branch_failure route, $ru is not what it should be?
-- juha
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
11:35 a.m.
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 append_branch() is executed, all
the same attributes would exist in the newly added branch that were
there when corresponding branch_route was executed.
Perhaps you should look inside tm module at execution
of branch
route/failure route to see how they take the branch attributes and
compare, to be sure is what I guessed or not.
i could try to do that, but first i would like to get $ru issue
resolved, i.e., why $ru in branch-failure route sometimes is aor uri and
sometimes contact uri. $ru in branch-failure route should always be the
same as it is in corresponding branch_route. i didn't understand what
your explanation to that was.
-- juha
11:39 a.m.
On 14/04/14 10:35, 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 specific routing blocks when such route block handles the incoming
request (what is stored in t->uas).
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 append_branch() is executed, all
the same attributes would exist in the newly added branch that were
there when corresponding branch_route was executed.
Perhaps you should look inside tm module at
execution of branch
route/failure route to see how they take the branch attributes and
compare, to be sure is what I guessed or not.
i could try to do that, but first i
would like to get $ru issue
resolved, i.e., why $ru in branch-failure route sometimes is aor uri and
sometimes contact uri. $ru in branch-failure route should always be the
same as it is in corresponding branch_route. i didn't understand what
your explanation to that was.
11:50 a.m.
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 route block handles the incoming
request (what is stored in t->uas).
in this test, when invite request is routed back to the proxy, its
request uri is exactly the same (sip:test@test.tutpro.com) as it was
when proxy received the invite request the first time. during the
second processing of the invite, a new transaction is created and my
understanding is the proxy process that does that has no knowledge of
the earlier transaction that is still pending in some other process.
so why in branch-failure route $ru is aor in in the first transaction
and contact uri in the second transaction?
-- juha
12:12 p.m.
On 14/04/14 10:50, Juha Heinanen wrote:
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, perhaps Hugh (iirc) can share
more on what he wanted to achieve. Maybe it is what he needed, although
my expectation would be different, so at least a config option should be
introduced to select between the two behaviours.
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 route block handles the incoming
request (what is stored in t->uas).
in this test, when invite request is routed
back to the proxy, its
request uri is exactly the same (sip:test@test.tutpro.com) as it was
when proxy received the invite request the first time. during the
second processing of the invite, a new transaction is created and my
understanding is the proxy process that does that has no knowledge of
the earlier transaction that is still pending in some other process.
so why in branch-failure route $ru is aor in in the first transaction
and contact uri in the second transaction?
12:49 p.m.
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, perhaps Hugh (iirc) can share
more on what he wanted to achieve. Maybe it is what he needed, although
my expectation would be different, so at least a config option should be
introduced to select between the two behaviours.
this is what i got. when invite comes from uac, t_newtran() is called
before authorization:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: ru before calling t_newtran() is
<sip:test@test.tutpro.com>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: INVITE
<sip:test@test.tutpro.com> by <jh(a)test.tutpro.com> as
<sip:jh@test.tutpro.com> from <192.98.102.30> is authorized
then proxy figures out that the request is for registered local aor,
does lookup and after that calls t_relay() on contact uri:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: INVITE
<sip:test@test.tutpro.com> is to local user <test(a)test.tutpro.com>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: ru before calling t_relay() is
<sip:test@192.98.102.30:5054>
before request is sent out, branch route is executed (that also sets
branch-failure route):
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: Routing INVITE
<sip:test@192.98.102.30:5054> to contact
uas replies with 488 and branch-failure route is executed, where $ru is aor
not contact uri:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: Got 488 response to
<sip:test@test.tutpro.com>
after append_branch() and t_relay() in branch-failure route, request
gets routed back to proxy according to aor in r-uri:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: Relaying to
<sip:test@test.tutpro.com>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: ru before calling t_relay() is
<sip:test@test.tutpro.com>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: Routing INVITE to contact
<sip:test@test.tutpro.com> to proxy itself
then proxy gets the request from itself and determines that request is
to local registered aor:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: INVITE
<sip:test@test.tutpro.com> by <sip:jh@test.tutpro.com> is from Proxy Itself
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: INVITE
<sip:test@test.tutpro.com> is to local user <test(a)test.tutpro.com>
during this iteration, t_newtrans() call is skipped, because there is no
authorization (which could take some time). instead, after lookup
t_relay() is called directly (on contact uri like during the first iteration):
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: ru before calling t_relay() is
<sip:test@192.98.102.30:5054>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: Routing INVITE
<sip:test@192.98.102.30:5054> to contact
$ru before t_relay() is thus exactly the same contact uri as it was
during the first iteration.
but by magic this time when uas replies with 488, $ru in branch-failure
route is not aor, but contact uri:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9980]: INFO: Got 488 response to
<sip:test@192.98.102.30:5054>
the only difference between these two iterations is that during the
second iteration, t_newtrans() is not called before t_relay().
-- juha
12:59 p.m.
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
1:05 p.m.
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 nice to get it fixed.
t_newtran() before t_relay() doesn't
break branch-failure. The fact is
that branch-failure is executed with the sip request from the moment
when transaction is created.
In your case, for first iteration of request, the transaction is created
by t_newtran() having the aor in r-uri. For second iteration, looped
request, the transaction is created by t_relay(), after location lookup,
thus r-uri is the contact of the target.
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).
Hope is more clear now.
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
1:45 p.m.
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-failure route should
match those of the branch. could you hugh as author of branch-failure
route comment on this?
also, when append_branch() is executed in branch-failure route, are all
attributes (dst_uri, flags, send_socket, etc) of the branch included in
the new branch?
-- juha
3:43 p.m.
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 blocks when such route block handles the incoming
request (what is stored in t->uas).
Isn't the stored state (from t_newtran()) updated on t_relay()? Iirc, at least
some fields seem to have the values from t_relay() time, not t_newtran();
--
Greetings,
Alex Hermann
3:57 p.m.
On 14/04/14 14:43, Alex Hermann wrote:
On Monday 14 April 2014, Daniel-Constantin Mierla
wrote:
Can you
give some examples of such fields?
avp/xavp lists are the same before and after transaction was created --
they are available in the tm routing blocks.
Flags needs to be re-sync'ed on the other hand:
http://kamailio.org/docs/modules/stable/modules/tmx.html#idp24432
SIP message content is cloned in transaction structure at the moment
transaction is created.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 route block handles the incoming
request (what is stored in t->uas).
Isn't the stored state (from
t_newtran()) updated on t_relay()? Iirc, at least
some fields seem to have the values from t_relay() time, not t_newtran();
4:11 p.m.
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 attributes, which
may be a separate issue. as i have mentioned earlier, attributes in
branch-failure route should be identical to the corresponding branch
route. anything else makes no sense to me.
-- juha
4:18 p.m.
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
5:20 p.m.
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 look in the code, caught by other tasks. I
just
guessed what can happen.
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 a branch structure.
I expect both routing blocks are executed from somewhere inside tm/t_reply.c
Once these attributes are from the branch, the append_branch() should
work as you need.
Maybe you have a chance to look at it sooner than I get time for it.
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
10:15 p.m.
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 a branch structure.
the code in t_reply.c for branch failure handling already looks very
similar to failure handling. run_failure_handlers() use branch
on_failure = t->uac[picked_branch].on_failure;
whereas run_branch_failure_handlers() use branch
on_branch_failure = t->uac[picked_branch].on_branch_failure;
then both create faked request environment, run the route handler, and
restore the original environment.
why the faked request in case of branch failure does not include correct
$ru goes beyond my knowledge of tm module.
-- juha
15 Apr
15 Apr
12:56 a.m.
On 14/04/14 21:15, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
indeed, looking at the code, the
failure-route and branch-failure events
are using only the request in the uas side of the transaction. It will
require writing some c code to get the attributes from uac structure.
Most of them are stored there (uri, branch flags, path, ...) but some
are not (dst_uri) ...
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 a branch structure.
the code in
t_reply.c for branch failure handling already looks very
similar to failure handling. run_failure_handlers() use branch
on_failure = t->uac[picked_branch].on_failure;
whereas run_branch_failure_handlers() use branch
on_branch_failure = t->uac[picked_branch].on_branch_failure;
then both create faked request environment, run the route handler, and
restore the original environment.
why the faked request in case of branch failure does not include correct
$ru goes beyond my knowledge of tm module. 
16 Apr
16 Apr
7:07 p.m.
Hello,
Sorry for being slow to join the discussion.
The requirements I had for the branch-failure route was to be able to run
t_next_contact_flow() etc. and also to retrieve the usrloc RUID so that the
entry could be de-registered. The latter can be done with $T_reply_ruid.
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 $T_req($ru) give something different in this situation?
Regards,
Hugh
-----Original Message-----
From: sr-users-bounces(a)lists.sip-router.org
[mailto:sr-users-bounces@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[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, 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 a branch
structure.
the code in t_reply.c for branch failure handling
already looks very
similar to failure handling. run_failure_handlers() use branch
on_failure = t->uac[picked_branch].on_failure;
whereas run_branch_failure_handlers() use branch
on_branch_failure = t->uac[picked_branch].on_branch_failure;
then both create faked request environment, run the route handler, and
restore the original environment.
why the faked request in case of branch failure does not include
correct $ru goes beyond my knowledge of tm module.
indeed, looking at the code, the
failure-route and branch-failure events are
using only the request in the uas side of the transaction. It will require
writing some c code to get the attributes from uac structure.
Most of them are stored there (uri, branch flags, path, ...) but some are
not (dst_uri) ...
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:29 p.m.
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 $T_req($ru) give something different in this situation?
hugh,
i tried with
event_route [tm:branch-failure:contact] {
if (t_check_status("488")) {
xlog("L_INFO", "Got 488 response to <$T_req($ru)>\n");
and got:
Apr 16 19:22:52 siika /usr/sbin/sip-proxy[16206]: INFO: Got 488 response to
<<null>>
but even if i could get access to branch route $ru, it would not be
enough, since i would also need the branch flags, send socket, $du,
etc., so that after append_branch(); t_relay() would do the right thing.
-- juha
7:33 p.m.
On 16/04/14 18:29, Juha Heinanen wrote:
Hugh Waite writes:
Some of
these attributes are lost, not stored in the branch at all. Next
hop (which can be from $du) is resolved in some dns structure.
See my previous email for a possible way of accessing existing
attributes stored in the branch.
Why would you need all attributes of the branch that just failed, do you
want to send the request to the same destination again?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 $T_req($ru) give something different in this situation?
hugh,
i tried with
event_route [tm:branch-failure:contact] {
if (t_check_status("488")) {
xlog("L_INFO", "Got 488 response to
<$T_req($ru)>\n");
and got:
Apr 16 19:22:52 siika /usr/sbin/sip-proxy[16206]: INFO: Got 488 response to
<<null>>
but even if i could get access to branch route $ru, it would not be
enough, since i would also need the branch flags, send socket, $du,
etc., so that after append_branch(); t_relay() would do the right thing.
7:46 p.m.
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 would behave
the right way.
-- juha
9:07 p.m.
On 16/04/14 18:46, 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 function t_reuse_branch() -- create a new branch from
current one so you can just relay
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 branch.
But avps are per transaction, not per branch, so if you add one, will be
visible to all branches (same should be in branch_route).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 would behave
the right way.
17 Apr
17 Apr
9:31 a.m.
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 new branch from
current one so you can just relay
The latter would, of course, be very user friendly, but $T_branch(attr)
would be ok too.
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;
I tried without luck. In branch route I set:
$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru) = $ru;
xlog("L_INFO", "Set htable value
<$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru)>\n");
but
xlog("L_INFO", "Got 488 response to
<$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru)>\n");
in branch-failure route produces null:
Apr 17 09:27:52 siika /usr/sbin/sip-proxy[19529]: INFO: Set htable value
<sip:jh@192.98.102.30:5054;transport=tcp>
Apr 17 09:27:52 siika /usr/sbin/sip-proxy[19583]: INFO: Got 488 response to
<<null>>
-- juha
4:09 p.m.
On 17/04/14 08:31, Juha Heinanen wrote:
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.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 new branch from
current one so you can just relay
The latter would, of course, be very user
friendly, but $T_branch(attr)
would be ok too.
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;
I tried
without luck. In branch route I set:
$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru) = $ru;
xlog("L_INFO", "Set htable value
<$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru)>\n");
but
xlog("L_INFO", "Got 488 response to
<$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru)>\n");
in branch-failure route produces null:
Apr 17 09:27:52 siika /usr/sbin/sip-proxy[19529]: INFO: Set htable value
<sip:jh@192.98.102.30:5054;transport=tcp>
Apr 17 09:27:52 siika /usr/sbin/sip-proxy[19583]: INFO: Got 488 response to
<<null>>
5:07 p.m.
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=>84813434::63952::1::ru
Apr 17 17:06:23 siika /usr/sbin/sip-proxy[5957]: INFO: Set htable value
<sip:jh@192.98.102.30:5054;transport=tcp>
Apr 17 17:06:23 siika /usr/sbin/sip-proxy[5957]: INFO: Key in branch-failure is:
t=>84813434::63952::-1::ru
so looks like $T(branch_index) is not properly set in branch-failure route.
-- juha
6:03 p.m.
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
<jh(a)tutpro.com> wrote:
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=>84813434::63952::1::ru
Apr 17 17:06:23 siika /usr/sbin/sip-proxy[5957]: INFO: Set htable value
<sip:jh@192.98.102.30:5054;transport=tcp>
Apr 17 17:06:23 siika /usr/sbin/sip-proxy[5957]: INFO: Key in branch-failure is:
t=>84813434::63952::-1::ru
so looks like $T(branch_index) is not properly set in branch-failure route.
-- juha
18 Apr
18 Apr
6:37 p.m.
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 branch.
i'm making good progress with the above approach except that there seems
to be no way to set ruid of the new branch nor get or set path and
instance.
-- juha
6:57 p.m.
On 18/04/14 17:37, 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.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 branch.
i'm making good progress with the
above approach except that there seems
to be no way to set ruid of the new branch nor get or set path and
instance.
7:03 p.m.
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 branch, which is what branch_route deals with.
-- juha
7:11 p.m.
On 18/04/14 18:03, Juha Heinanen wrote:
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 safe overall
and not working with r-uri branch is a limitation.
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 branch, which is what branch_route deals with.
8:29 p.m.
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 safe overall
and not working with r-uri branch is a limitation.
i tried in branch-failure route to assign ruid of the branch like this:
$branch(ruid) = $T_reply_ruid;
and it resulted in errors:
Apr 18 20:19:21 siika /usr/sbin/sip-proxy[31962]: ERROR: <core> [lvalue.c:363]:
lval_pvar_assign(): setting pvar failed
Apr 18 20:19:21 siika /usr/sbin/sip-proxy[31962]: ERROR: <core> [lvalue.c:416]:
lval_assign(): assignment failed at pos: (2737,25-2737,37)
then i tried
$(branch(ruid)[$T(branch_index)]) = $T_reply_ruid;
with the same result.
any other suggestions or is new code needed?
-- juha
16 Apr
16 Apr
7:30 p.m.
Hello,
by looking at the code, I would say that keeping the same behaviour as
now is the easiest way to go. Changing the attributes in the request
would require a lot of backups and restores of values.
It might be easier to add a special class of pvs to access branch
attributes, like:
$T_branch(uri)
$T_branch(flags)
...
Cheers,
Daniel
On 16/04/14 18:07, Hugh Waite wrote:
Hello,
Sorry for being slow to join the discussion.
The requirements I had for the branch-failure route was to be able to run
t_next_contact_flow() etc. and also to retrieve the usrloc RUID so that the
entry could be de-registered. The latter can be done with $T_reply_ruid.
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 $T_req($ru) give something different in this situation?
Regards,
Hugh
-----Original Message-----
From: sr-users-bounces(a)lists.sip-router.org
[mailto:sr-users-bounces@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[tm:branch-failure] question
On 14/04/14 21:15, Juha Heinanen wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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 a branch
structure.
the code in t_reply.c for branch failure handling
already looks very
similar to failure handling. run_failure_handlers() use branch
on_failure = t->uac[picked_branch].on_failure;
whereas run_branch_failure_handlers() use branch
on_branch_failure = t->uac[picked_branch].on_branch_failure;
then both create faked request environment, run the route handler, and
restore the original environment.
why the faked request in case of branch failure does not include
correct $ru goes beyond my knowledge of tm module.
indeed, looking at the code,
the failure-route and branch-failure events are
using only the request in the uas side of the transaction. It will require
writing some c code to get the attributes from uac structure.
Most of them are stored there (uri, branch flags, path, ...) but some are
not (dst_uri) ...
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
14 Apr
14 Apr
5:16 p.m.
On 14/04/14 15:11, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
If someone needs something similar, of course new functions can be
added. Anything particular in mind?
Daniel
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 attributes, which
may be a separate issue. as i have mentioned earlier, attributes in
branch-failure route should be identical to the corresponding branch
route. anything else makes no sense to me.
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
3877
days inactive
3882
days old
34 comments
4 participants
participants (4)
-
Alex Hermann -
Daniel-Constantin Mierla -
Hugh Waite -
Juha Heinanen