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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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-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.

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

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 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?

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

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:

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

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 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();

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,

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

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

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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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'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.

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

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 so that mediaproxy-offer in branch route would behave the right way.

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

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 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>>

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

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@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

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

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

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

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 something similar, of course new functions can be added. Anything particular in mind?

Daniel

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.