[OpenSIPS-Devel] [OpenSIPS-Users] [Request for Brain[storming]] New types of routes in config
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Tue Apr 28 18:38:16 CEST 2009
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
More information about the Devel
mailing list