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

[Brett Nemeroff]

>
> The basic idea is that every module that "returns" a value should also
>> return some sort of primary key that was used for that value. Then it can be
>> logged into ACC. Displayed on logging "Sending call to Gateway #100"
>>
> I see your point and I agree with that - personally I had this need also
> and this is why I added in Drouting module the "attrs" field for the GWs
> definition - see
> http://www.opensips.org/html/docs/modules/devel/drouting.html#id272135.
>
> Of course, the same mechanism can be added to several other modules (like
> permissions as you suggested).
>
> In this area I intend to add support for JSON (json.org) to be able to
> structure more info in a single string value - you have a generic attr field
> that may encode multiple values, keys, etc using json scheme. So, the idea
> will be to add the json transformation to extract from the encode string a
> certain attribute.
>
That's a very interesting idea. That would certainly satisfy many needs. I
like it..I'd like to see something like this many modules. :)


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


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

Thanks again for everything, your hard work is much appreciated. :)
-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090428/d8272ba0/attachment.htm