6 Aug
2008
6 Aug
'08
3:53 a.m.
Daniel-Constantin,
Good morning. Thanks for the early morning opinion. How about some
really late night followup? :)
Daniel-Constantin Mierla wrote:
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. ]
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
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. 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.