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

Daniel-Constantin Mierla wrote: 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