[OpenSIPS-Users] [Request for Brain[storming]] New types of routes in config

[Bogdan-Andrei Iancu]

Brett,

Brett Nemeroff wrote: 
>
>         2. Native combined CDR format. One row, start, answer, end,
>         duration. Yes, I know, not a B2BUA.. It'll have limitations,
>         and a bit fat disclaimer and I'm sure we'll have "that talk"
>         again. :)
>
>     you mean to get directly CDRs, instead of acc events?
>
> Yes, exactly. I've asked this directly on the list, but no one has 
> answered. For me, combining ACC events into real CDR is a pain. it's 
> really the single biggest wrench for the overall architecture. I have 
> to use external scripts that make assumptions about SIP to combine the 
> records. For example, as my rating scripts process the ACC events, it 
> makes assumptions on weather the dialog has been destroyed yet or not 
> to determine if it's time to rate it, or if it's still in progress. I 
> don't know about you, but I'd much rather the SIP Stack track that, 
> rather than duplicate that kind of logic on the rating engine. I feel 
> that with all of the fancy dialog stuff going on, it should be able to 
> easily identify events like start, pdd, ring, stop and gracefully 
> handle events like reinvites. I don't work much on the core, but I bet 
> there is a lot of this logic already in there for other purposes.
have you tried the mysql procedure used by opensips-cp for creating CDR? 
the CP is consuming the ACC data to create CDRs in a different table via 
a mysql procedure that is triggered by cron. So far even with large CDR 
volume, I got good results with this.

But making opensips to directly generate CDRs is complicated as in many 
case you do not have a dialog info, so you never know if a START is 
already there or not (in order to do an UPDATE or INSERT for BYE).
>  
>
>
>
>         3. New DRouting fifo commands: route lookup, route count,
>         route last reload, route table dump (ek?). Sometimes it's good
>         to know that what's in memory is really what you expected.
>         However, that's not very useful in production.
>
>     maybe this can be split between stat vars (for counting rules and
>     GW) and MI commands (like triggering a routing request from outside).
>
> Sounds good to me. :)
>  
>
>         5. Memcache: full cache purge fifo option (not just 1 object,
>         but everything)
>
>     like a command to purge the entire content?
>
> Yeah: 100% destroy all cached objects (ie: I want you to suck up new 
> data from the database). Of course, usage of this command is highly 
> dependent on good scriptwriting. Else you may end up breaking a lot of 
> stuff.
>  
>
>         6. Memcache: partial cache purge (not sure how to do this.
>         Idea is "Purge all accountcodes" or "Purge all account limits"
>         (to force loading new ones)
>
>     but how do you suggest to identify the attributes to be purges as
>     they have different names? regexp matching ?
>
> You know, I'm not sure how this should be done.. regex sounds neat, 
> but could just lead to a bunch of sloppy scripting. I *hate* to borrow 
> ideas from asterisk, but caching families may be a neat idea.. 
> examples of caching families are:
> 1. Account Limits
> 2. Destination Rates
> 3. Account Codes
>
> It would require some tweaking of the caching functions, but I imagine 
> something like:
> cache_store_family("local","account_limits","10000001","24","3600")
> (translation: store to local cache,in the account_limits family, 
> account 10000001 has 24 channels. remember this for 3600 seconds)
>
> Then you can issue a fifo:
> cache_purge_family account_limits
>
> And then all account_limits are all *gone*. but "Account Codes" and 
> "Destination Rates" still remain.
I have nothing against borrowing ideas, as time as they are useful and 
applicable. I found really interesting the idea of "families" or 
"classes" for memcache support  and it shouldn't be too difficult to 
use. We can keep the current format for the functions for a default 
"Generic" class and create a new set of functions to take an extra one 
parameter, the name of the class.

Regards,
Bogdan