Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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; ... 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. 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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 additional branches, not the main branch, which is what branch_route deals with. 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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 -- 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] event_route[tm:branch-failure] question
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-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[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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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
___
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
Re: [SR-Users] event_route[tm:branch-failure] question
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-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[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 -- 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
Re: [SR-Users] event_route[tm:branch-failure] question
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
--
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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 -- 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
Re: [SR-Users] event_route[tm:branch-failure] question
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:t...@test.tutpro.com is to local user t...@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:t...@test.tutpro.com
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7952]: INFO: Relaying to
sip:t...@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:t...@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:t...@test.tutpro.com by sip:j...@test.tutpro.com is from Proxy Itself
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[7953]: INFO: INVITE
sip:t...@test.tutpro.com is to local user t...@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
--
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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 -- 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
Re: [SR-Users] event_route[tm:branch-failure] question
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:t...@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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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:t...@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 -- 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
Re: [SR-Users] event_route[tm:branch-failure] question
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:t...@test.tutpro.com Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: INVITE sip:t...@test.tutpro.com by j...@test.tutpro.com as sip:j...@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:t...@test.tutpro.com is to local user t...@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:t...@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:t...@test.tutpro.com Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: ru before calling t_relay() is sip:t...@test.tutpro.com Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: Routing INVITE to contact sip:t...@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:t...@test.tutpro.com by sip:j...@test.tutpro.com is from Proxy Itself Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: INVITE sip:t...@test.tutpro.com is to local user t...@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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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-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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 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
Re: [SR-Users] event_route[tm:branch-failure] question
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. -- 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
Re: [SR-Users] event_route[tm:branch-failure] question
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 ___ 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
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
