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

[Daniel-Constantin Mierla]

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
>
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com