[Kamailio-Users] Identifying branch in ONREPLY-ROUTE?

[Alex Balashov]

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

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599