[Kamailio-Users] Question about registrar lookup() and branching.

[Alex Balashov]

Daniel-Constantin,

Good morning.  Thanks for the early morning opinion.  How about some 
really late night followup?  :)

Daniel-Constantin Mierla wrote:

>> 1. Stop using lookup() and do my own URI rewrites and branch forking 
>> (if the contact URIs are identical) with attention to the contact.
>>   
> This is a bit more complex if you still want to use registrar to save 
> location entries. Perhaps by using selects in the location table, you 
> can achieve directly in the script.  or using a shell/perl script.

That was the idea.  I already have extensive call logic outboarded to a 
Perl script, so I would just replace lookup() with my own intelligent, 
contact header-aware database dip.

I ultimately elected to go with the second option, not the first.

[ BTW, slightly unrelated:  Whatever the cause of script methods being 
largely inaccessible from the Perl module API (i.e. 
OpenSER::rewrite_uri()) is (I was told a memory leak) it is a source of 
vexation and disappointment.

It means that I really can't do anything with my Perl scripts--of which 
there is a plethora--other than get and set AVPs and read custom 
pseudovariables and parse messages and URIs.  I can't really move any of 
the logic I have from script to Perl at all, so instead I have to use 
countless AVPs as a message-passing mechanism and end up with big, 
nasty, ugly chunks of script that look like:

if($avp(S:translation_status) == "1") {
      # do a bunch of things

      avp_delete("$avp(S:translation_status)");
}

My number one wish for the project is that someone would give some 
attention to the neglected Perl module and get it all fixed up so I can 
get a lot of logic out of the route plan. ]

>> I also need to build in some other logic, such that for example if a 
>> user has only one contact registered and it does not match the DID, or 
>> none of the contacts match the DID, proceed as normal anyway.
>>   
> Here you get back in complexity. Perhaps if you play with $bR, 
> transformations and script operations you will achieve that. As I 
> understood it is about selecting the branches to be dropped. You can go 
> through the addresses returned by $bR, test your conditions and 
> accumulate what branches are to be dropped in AVP, checking again in 
> branch route for actually dropping.

The route I decided to go is to check all the conditions in the branch 
route;  it keeps things simple and prevents me from having to iterate 
over any AVP arrays.

The real headache I'm facing now has to do with call statekeeping.  I 
keep call state in a database using custom logic in order to try -- as 
much as the reliability of SIP signaling can allow -- to enforce 
simultaneous session limits.

The problem is that none of this stuff is branch-aware, but now I'm 
getting into a situation where a branch that is cancelled triggers a 
reply (and therefore, for that call leg, an ONREPLY-ROUTE) like 487 
Transaction Terminated that has to be handled in a branch-aware way. 
Previously, in unitary branch mode, I would just delete the call from 
the state table upon encountering a >= 300 cause code in the reply.  Now 
I have to make sure I only delete that branch, and handle a bunch of 
other contingencies that come with that.   Oof.

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