lets say that invite is parallel forked to two contacts. if the call is answered, i would like to set in reply route an accounting avp that contains the request uri of answering branch. i have tried $T_req($ru), but that gives the original request uri. any suggestions?
-- juha
Juha Heinanen writes:
lets say that invite is parallel forked to two contacts. if the call is answered, i would like to set in reply route an accounting avp that contains the request uri of answering branch. i have tried $T_req($ru), but that gives the original request uri. any suggestions?
it might be possible to store in branch route request uris to an avp and then select the correct one based on the last field of top via branch, but that is a far too complicated solution for such a simple task as finding out the request uri of replied request. therefore, i must be missing something.
-- juha
Juha Heinanen writes:
it might be possible to store in branch route request uris to an avp and then select the correct one based on the last field of top via branch, but that is a far too complicated solution for such a simple task as finding out the request uri of replied request. therefore, i must be missing something.
another one would be to store $ru in branch route to htable using transaction and branch index as key and then get it from there in onreply route. still too complicated.
would it be possible to define $T(request_uri)?
-- juha
On 01/12/14 02:23, Juha Heinanen wrote:
Juha Heinanen writes:
it might be possible to store in branch route request uris to an avp and then select the correct one based on the last field of top via branch, but that is a far too complicated solution for such a simple task as finding out the request uri of replied request. therefore, i must be missing something.
another one would be to store $ru in branch route to htable using transaction and branch index as key and then get it from there in onreply route. still too complicated.
I think indeed that would be an option. Looks like nobody needed this value so far ...
would it be possible to define $T(request_uri)?
I think the best way is to extend $T_branch(...) class of pvs to have $T_branch(ruri), or maybe even $T_branch($pv) and have $T_branch($ru) for what you need.
Cheers, Daniel
On 01 Dec 2014, at 10:42, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 01/12/14 02:23, Juha Heinanen wrote:
Juha Heinanen writes:
it might be possible to store in branch route request uris to an avp and then select the correct one based on the last field of top via branch, but that is a far too complicated solution for such a simple task as finding out the request uri of replied request. therefore, i must be missing something.
another one would be to store $ru in branch route to htable using transaction and branch index as key and then get it from there in onreply route. still too complicated.
I think indeed that would be an option. Looks like nobody needed this value so far ...
would it be possible to define $T(request_uri)?
I think the best way is to extend $T_branch(...) class of pvs to have $T_branch(ruri), or maybe even $T_branch($pv) and have $T_branch($ru) for what you need.
Do you mean the "winning" branch?
If we end up in failure route, there can be multiple branches ending up with the same answer, like two phones sending 486. How do we handle finding the ruri's of those?
/O
On 01/12/14 10:45, Olle E. Johansson wrote:
On 01 Dec 2014, at 10:42, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 01/12/14 02:23, Juha Heinanen wrote:
Juha Heinanen writes:
it might be possible to store in branch route request uris to an avp and then select the correct one based on the last field of top via branch, but that is a far too complicated solution for such a simple task as finding out the request uri of replied request. therefore, i must be missing something.
another one would be to store $ru in branch route to htable using transaction and branch index as key and then get it from there in onreply route. still too complicated.
I think indeed that would be an option. Looks like nobody needed this value so far ...
would it be possible to define $T(request_uri)?
I think the best way is to extend $T_branch(...) class of pvs to have $T_branch(ruri), or maybe even $T_branch($pv) and have $T_branch($ru) for what you need.
Do you mean the "winning" branch?
If we end up in failure route, there can be multiple branches ending up with the same answer, like two phones sending 486. How do we handle finding the ruri's of those?
For a parallel forking, indeed, there can be such case with same code in many branches. We have to look at tm code, I guess Jiri Kuthan or Andrei Pelinescu implemented it long time ago (as I don't remember any work recently on that area) and perhaps in this case it selects the first or the last with the same code ... Cheers, Daniel
Daniel-Constantin Mierla writes:
I think the best way is to extend $T_branch(...) class of pvs to have $T_branch(ruri), or maybe even $T_branch($pv) and have $T_branch($ru) for what you need.
$T_branch(ruri) or $T(ruri) would be fine to me.
it is very strange that no-one has so far been interested in where calls get routed to.
-- juha
On 01/12/14 11:04, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I think the best way is to extend $T_branch(...) class of pvs to have $T_branch(ruri), or maybe even $T_branch($pv) and have $T_branch($ru) for what you need.
$T_branch(ruri) or $T(ruri) would be fine to me.
it is very strange that no-one has so far been interested in where calls get routed to.
I most of the case I need the source ip and port of the reply, all related to the r-uri is handled in branch_route.
And indeed, give that you are one of the first people using SER, it took a long time for someone to need this attribute while processing the reply...
Daniel
Daniel-Constantin Mierla writes:
I most of the case I need the source ip and port of the reply, all related to the r-uri is handled in branch_route.
how can you set translated request uri accounting attribute in branch route when the call is parallel forked? ip and port of the reply do not tell which aor the call went.
And indeed, give that you are one of the first people using SER, it took a long time for someone to need this attribute while processing the reply...
i had a bug in my config. it didn't set translated request uri accounting attribute correctly when call is parallel forked. when i started to investigate, it turned out that there was no easy way to fix the bug.
-- juha
On 01/12/14 11:22, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I most of the case I need the source ip and port of the reply, all related to the r-uri is handled in branch_route.
how can you set translated request uri accounting attribute in branch route when the call is parallel forked? ip and port of the reply do not tell which aor the call went.
And indeed, give that you are one of the first people using SER, it took a long time for someone to need this attribute while processing the reply...
i had a bug in my config. it didn't set translated request uri accounting attribute correctly when call is parallel forked. when i started to investigate, it turned out that there was no easy way to fix the bug.
Accounting module takes the r-uri from winning branch, afaik -- if you account $ru via acc *_extra parameter.
Daniel
On 01/12/14 11:37, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Accounting module takes the r-uri from winning branch, afaik -- if you account $ru via acc *_extra parameter.
you are correct. i tested and that indeed is the case.
I just committed a patch to master to get the r-uri in config when handling a reply via tm onreply_route block:
- https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables?&#t_branch... Should be useful when one needs the value in config file.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson