Daniel-Constantin Mierla wrote:

you found a good solution and with transformations should be easy to get. honestly I had no need so far and I think the right approach is to ma $T_branch_index return the branch of the processed reply.

The problem is that $T_branch_idx has no validity outside of a BRANCH-ROUTE.

Also, as far as transformations, I can't seem to get the following to work with textops:

if(search("^Via:.*branch=([a-zA-Z0-9.-_]+)")) { xlog("L_INFO", " Via: \1 \n"); }

It matches, but, how do I display the matched regex atom? \1 works in substitutions, but not here evidently?

Daniel,

Well, for now I am processing $hdr(Via) in my Perl middleware to get the branch ID out.

The problem then becomes that the topmost Via visible to the initial REQUEST-ROUTE (as well as any corresponding BRANCH-ROUTEs resulting from lookup & stateful relay) during processing is from the call source, not the outgoing call leg.

So:

SBC --> its Via and a certain branch param --> registrar --> branches to contacts

At the point at which the registrar is processing the request, the Via from the SBC is what is visible. Only once the request is forwarded does the new Via stamped on by the proxy become visible, with the corresponding branch parameters.

As a result, I have no way of identifying the same branches from the REQUEST-ROUTE (or BRANCH-ROUTE) as later in the ONREPLY-ROUTE.

What would you suggest as my other options? I suppose it is possible to append some custom headers, but these do not come back in replies. I would hate to use add_rr_param() for this purpose or something equally nefarious, as well; that does not seem RFC-kosher.

I suppose I *could* store the branch= parameter of the incoming leg and then collate the subsequent branches with it, but it seems like there really ought to be a better way.

-- Alex

Daniel-Constantin Mierla wrote:

maybe you you tell what you need to do with this branches I can find a solution. So far I don't get exactly the logic you want to implement. I thought you need the branch id in the onreply route and that is all.

A branch ID that is visible in the onreply route would suffice.

What I am doing is monitoring call state in order to enforce per-user concurrent session limits, somewhat akin to what a billing application that generates CDRs from passively inspecting dialogs passing through OpenSER would do. I am doing it myself rather than using the dialog module. So, I log INVITEs, BYEs, CANCELs, OKs, 183s, into a table associated with a user and then count open calls.

The problem is that the registrar also supports multiple contacts, and when forking occurs as a result of a lookup(), this mechanism breaks down because the reply routes aren't branch-aware in any way.

For instance, my logic simply deletes a call from the call state table if it receives an error (4/5/6xx) in the onreply route. But if I have two branches, what if one of them passes back an error and the other one succeeds with 200 OK? From the onreply route's point of view, there is only one call going on here, and so the state entry is deleted by GUID (Call-ID) and any subsequent developments in other branches never get logged.

Obviously, what I need is to track call state by branch <--> Call-ID, not just Call-ID. But in order to do that, I need more than just a branch route; I need to know what branch feedback belongs to in the replies and in new requests.

I can get it using the topmost Via header stamped by the proxy, which appears in replies as well as in new in-dialog requests (i.e. BYE). But Kamailio appears to offer no options for extracting the branch= parameter from these Vias in an elegant, high-level way. Furthermore, these branch IDs are not known in the initial INVITE that establishes the branches, so I have to somehow collate them with the incoming call leg.

So, what I'd really be looking for to graetly simplify this endeavour is twofold:

1. $T_branch_idx ought to be lexically valid outside of a branch route, and reveal the pertinent branch wherever possible, including in request routes and reply routes. I do not know if the way 'tm' works makes structurally possible.

2. Some way to determine branch IDs at their onset. I don't expect to know branch IDs in the initial request route, before I even call t_relay(), but I think it is reasonable for a branch route to know its own branch ID. It does, in the form of $T_branch_idx, but as per #1, that is something that has no meaning outside of a branch route, making correlation impossible.

If #1 could be addressed #2 would go away.

-- Alex

Iñaki Baz Castillo wrote:

Is not useful for you $T_reply_code?

http://www.kamailio.org/docs/modules/1.3.x/tm.html#AEN576

Unless I am missing something, no, because it does not tell me anything about the individual branch on which the reply occurred.

Parece un poco inutil.

Hello,

On 08/11/08 19:40, Alex Balashov wrote:

Daniel-Constantin Mierla wrote:

...

maybe you you tell what you need to do with this branches I can find a solution. So far I don't get exactly the logic you want to implement. I thought you need the branch id in the onreply route and that is all.

A branch ID that is visible in the onreply route would suffice.

What I am doing is monitoring call state in order to enforce per-user concurrent session limits, somewhat akin to what a billing application that generates CDRs from passively inspecting dialogs passing through OpenSER would do. I am doing it myself rather than using the dialog module. So, I log INVITEs, BYEs, CANCELs, OKs, 183s, into a table associated with a user and then count open calls.

The problem is that the registrar also supports multiple contacts, and when forking occurs as a result of a lookup(), this mechanism breaks down because the reply routes aren't branch-aware in any way.

For instance, my logic simply deletes a call from the call state table if it receives an error (4/5/6xx) in the onreply route. But if I have two branches, what if one of them passes back an error and the other one succeeds with 200 OK? From the onreply route's point of view, there is only one call going on here, and so the state entry is deleted by GUID (Call-ID) and any subsequent developments in other branches never get logged.

Obviously, what I need is to track call state by branch <--> Call-ID, not just Call-ID. But in order to do that, I need more than just a branch route; I need to know what branch feedback belongs to in the replies and in new requests.

I can get it using the topmost Via header stamped by the proxy, which appears in replies as well as in new in-dialog requests (i.e. BYE). But Kamailio appears to offer no options for extracting the branch= parameter from these Vias in an elegant, high-level way. Furthermore, these branch IDs are not known in the initial INVITE that establishes the branches, so I have to somehow collate them with the incoming call leg.

So, what I'd really be looking for to graetly simplify this endeavour is twofold:

1. $T_branch_idx ought to be lexically valid outside of a branch route,

and reveal the pertinent branch wherever possible, including in request routes and reply routes. I do not know if the way 'tm' works makes structurally possible.

2. Some way to determine branch IDs at their onset. I don't expect to

know branch IDs in the initial request route, before I even call t_relay(), but I think it is reasonable for a branch route to know its own branch ID. It does, in the form of $T_branch_idx, but as per #1, that is something that has no meaning outside of a branch route, making correlation impossible.

If #1 could be addressed #2 would go away.

hope I understood what you want to achieve. By using reply routes you get a bit more complex data structure and operations. Isn't it enough to use failure route? Even if is parallel forking, only one branch wins or all fail. If one win, then you don't delete, if all fail then you delete the record.

This should work unless you want to see also branches in you table.

Cheers, Daniel

-- Alex