[OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

[Bogdan-Andrei Iancu]

Hi Brett,

The events stuff works a bit the other way around - you do not decide 
where to send the event, but the consumer entities subscribe to you in 
order to receive events. So it is not push, but pull. The consumer 
decides (via subscription process) what event to receive, for how long 
and what backend to be used.

Regarding the ACC event, I will add it on the TODO list on 1.9 .

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/28/2012 04:37 PM, Brett Nemeroff wrote:
> On Fri, Nov 2, 2012 at 3:49 PM, Rudy <rudy at dynamicpacket.com 
> <mailto:rudy at dynamicpacket.com>> wrote:
>
>     Bogdan,
>
>      Its great to hear all these ideas for 1.9 from the community. One
>     thing that may also be useful, is some enhancements to the
>     rabbit_mq module. It would be great if this module could also
>     push/send events to a any rabbitmq queue or exchange (maybe based
>     on an avp) . Another thing that may be worth exploring is being
>     able to send ACC via a rabbitmq event. What do you think?
>
>
>
> I just wanted to throw in my $0.02 here.. And I apologize for 
> pandering. Once I got on it, I realized there's a lot around this that 
> I'd like to see..
>
> I think this is a great idea. Both being able to dynamically control 
> which rabbit queue to send and to have it native in acc.
>
> ** What about having native acc callbacks in the routing script? 
> that'd make adopting new technologies for accounting really easy. Like 
> this:
>
> on_dialog_complete {
>     new_tech_acc_write("$avp(extra_params)");
> }
>
> on_dialog_established {
>     new_tech_notify_new_call("$avp(extra_params)")
> }
>
> (these new_tech_* funcs are just examples of new modules in the 
> future, like couchbase or perhaps a REST query.
>
> I'm not entirely sure how to go about doing it. But the idea is that 
> the custom "acc callback" routes would be called on specific acc 
> events that would cause acc records to be written. I recognize what I 
> posted above is more of a dialog callback. For my cases specifically, 
> I'd use the cdr flag, and I'd like to know when a call ends. Then I'd 
> write the acc details to the "new technology" backend. So I'm not sure 
> if this is an acc feature or a dialog feature (or perhaps some 
> combination of both).
>
> I'd probably want all the dialog data in a single object (like maybe a 
> json object) or something else easily passable and parsable. A 
> $dlg_json variable would be really awesome for this purpose. I image 
> if cdr_flag was set, it'd have the duration and all in there as well 
> (all the normal stuff it'd be writing to the db).
>
> Bah, Sorry about that, I really went on.
>
> tl/dr:
> 1. new $dlg_json variable that stores all data that would normally be 
> written by a acc write (and maybe some additional dialog specific data)
> 2. new special routes to act as acc module callbacks to be called at 
> specific acc events, which should also work with the cdr_flag.
>
> Thanks!
> -Brett
>
>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121129/d4a657db/attachment-0001.htm>