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

[Iñaki Baz Castillo]

El Monday 11 August 2008 18:40:50 Alex Balashov escribió:
> 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

Is not useful for you $T_reply_code?

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

-- 
Iñaki Baz Castillo
ibc at in.ilimit.es