19 Apr
2014
19 Apr
'14
5:57 p.m.
as per daniel's suggestion, i wrote a new tmx function t_reuse_branch(),
which can currently be called from branch-failure route:
/**
* Creates new "main" branch by making copy of branch-failure branch.
* Currently the following branch attributes are included:
* request-uri, ruid, path, instance, and branch flags.
*/
static int w_t_reuse_branch(struct sip_msg* msg, char *p1, char *p2)
{
struct cell *t;
int branch;
if (msg == NULL) return -1;
/* first get the transaction */
if (_tmx_tmb.t_check(msg, 0) == -1) return -1;
if ((t = _tmx_tmb.t_gett()) == 0) {
LM_ERR("no transaction\n");
return -1;
}
switch (get_route_type()) {
case BRANCH_FAILURE_ROUTE:
/* use the reason of the winning reply */
if ((branch = _tmx_tmb.t_get_picked_branch()) < 0) {
LM_CRIT("no picked branch (%d) for a final response"
" in MODE_ONFAILURE\n", branch);
return -1;
}
rewrite_uri(msg, &(t->uac[branch].uri));
set_ruid(msg, &(t->uac[branch].ruid));
if (t->uac[branch].path.len) {
set_path_vector(msg, &(t->uac[branch].path));
} else {
reset_path_vector(msg);
}
setbflagsval(0, t->uac[branch].flags);
set_instance(msg, &(t->uac[branch].instance));
return 1;
default:
LM_ERR("unsupported route_type %d\n", get_route_type());
return -1;
}
}
the new "main" branch does not include destination uri and socket,
because i didn't find them in struct ua_client. unless someone adds
them to struct ua_clients, they thus need to be set separately from
htable after calling t_reuse_branch().
is it ok that i commit the above function to tmx module?
in addition, i would like to add $T_reply_bf (branch flags) pv, since i
need to test some of the branch flags in other parts of branch-failure
route.
-- juha
19 Apr
19 Apr
11:24 p.m.
Hello,
the function can be committed.
For the variable, I would go for a new class, $T_branch(attr). You can
implement the part for flags as $T_branch(flags). Other attributes can
be implemented later under the same class.
Cheers,
Daniel
On 19/04/14 14:57, Juha Heinanen wrote:
as per daniel's suggestion, i wrote a new tmx
function t_reuse_branch(),
which can currently be called from branch-failure route:
/**
* Creates new "main" branch by making copy of branch-failure branch.
* Currently the following branch attributes are included:
* request-uri, ruid, path, instance, and branch flags.
*/
static int w_t_reuse_branch(struct sip_msg* msg, char *p1, char *p2)
{
struct cell *t;
int branch;
if (msg == NULL) return -1;
/* first get the transaction */
if (_tmx_tmb.t_check(msg, 0) == -1) return -1;
if ((t = _tmx_tmb.t_gett()) == 0) {
LM_ERR("no transaction\n");
return -1;
}
switch (get_route_type()) {
case BRANCH_FAILURE_ROUTE:
/* use the reason of the winning reply */
if ((branch = _tmx_tmb.t_get_picked_branch()) < 0) {
LM_CRIT("no picked branch (%d) for a final response"
" in MODE_ONFAILURE\n", branch);
return -1;
}
rewrite_uri(msg, &(t->uac[branch].uri));
set_ruid(msg, &(t->uac[branch].ruid));
if (t->uac[branch].path.len) {
set_path_vector(msg, &(t->uac[branch].path));
} else {
reset_path_vector(msg);
}
setbflagsval(0, t->uac[branch].flags);
set_instance(msg, &(t->uac[branch].instance));
return 1;
default:
LM_ERR("unsupported route_type %d\n", get_route_type());
return -1;
}
}
the new "main" branch does not include destination uri and socket,
because i didn't find them in struct ua_client. unless someone adds
them to struct ua_clients, they thus need to be set separately from
htable after calling t_reuse_branch().
is it ok that i commit the above function to tmx module?
in addition, i would like to add $T_reply_bf (branch flags) pv, since i
need to test some of the branch flags in other parts of branch-failure
route.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
20 Apr
20 Apr
3:19 p.m.
Daniel-Constantin Mierla writes:
For the variable, I would go for a new class,
$T_branch(attr). You can
implement the part for flags as $T_branch(flags). Other attributes can
be implemented later under the same class.
i looked at implementation of current classes $T_req(pv), $T_rpl(pv),
etc. looks like they make a copy of the whole environment and then
access the pv using normal pv access functions. this sounds very heavy
as compared to implementation of item functions $T_reply_ruid,
$T_branch_idx, etc. i would thus prefer to implement $T_reply_flags
the same way as the item functions is done.
-- juha
21 Apr
21 Apr
1:49 p.m.
On 20/04/14 12:19, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Those
classes of variables needed to clone the buffers in order to parse
them. But for $T_branch(flags) it is not need, you can look at how
$T(key) is implemented, or any other class with inner names ($time(key),
$branch(key)).
It is better structured as there is going to be $T_branch(uri), ... and
other attributes.
For the variable, I would go for a new class,
$T_branch(attr). You can
implement the part for flags as $T_branch(flags). Other attributes can
be implemented later under the same class.
i looked at implementation of current
classes $T_req(pv), $T_rpl(pv),
etc. looks like they make a copy of the whole environment and then
access the pv using normal pv access functions. this sounds very heavy as compared to implementation of item functions
$T_reply_ruid,
$T_branch_idx, etc. i would thus prefer to implement $T_reply_flags
the same way as the item functions is done.
I don't get the relation between
reply and branch flags to have a reason
to call this T_reply_flags.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
9:28 p.m.
as per daniel's suggestion, i added $T_branch(flags) pv. should
$T_branch_idx and $T_reply_ruid be now renamed to $T_branch(idx) and
$T_branch(ruid)?
-- juha
9:40 p.m.
On 06/05/14 16:48, Juha Heinanen wrote:
Juha Heinanen writes:
Not for $T_branch_index, in failure route it returns the index of the
new branch, not the winning failed branch, so there are different
things. Reply ruid should be renamed as it has nothing to do with the
reply, but with the branch -- however, I haven't looked at it and what
is doing in failure route and other routing blocks.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
as per daniel's suggestion, i added
$T_branch(flags) pv. should
$T_branch_idx and $T_reply_ruid be now renamed to $T_branch(idx) and
$T_branch(ruid)?
i haven;t heard anything about this. can i just go head with
renaming?
9:59 p.m.
Daniel-Constantin Mierla writes:
On 06/05/14 16:48, Juha Heinanen wrote:
> Juha Heinanen writes:
>
>> as per daniel's suggestion, i added $T_branch(flags) pv. should
>> $T_branch_idx and $T_reply_ruid be now renamed to $T_branch(idx) and
>> $T_branch(ruid)?
> i haven;t heard anything about this. can i just go head with renaming?
Not for $T_branch_index, in failure route it returns
the index of the
new branch, not the winning failed branch, so there are different
things. Reply ruid should be renamed as it has nothing to do with the
reply, but with the branch -- however, I haven't looked at it and what
is doing in failure route and other routing blocks.
ok, i'll pass, since it is more than just branch failure issue
-- juha
3653
days inactive
3670
days old
8 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen