Hey Bogdan,
Thanks for your input, I think we are on the same page here. Maybe I was
the one forcing events to be the solution just because we already
implemented the protocol for it :). The perfect solution would be as you
said, a 2 way protocol (I was calling them events since I imagined them
to be async).
Just one more idea, would it be possible to do some automatic call_start
and call_stop event generation over http (events over http)? The reason
I am asking is to avoid having that many ports opened between OpenSIPS
and CGRateS.
I am travelling these days but will ping you starting of next week to
sync each other and have a phone call if possible on your side.
Thanks again!
DanB
On 29.01.2015 14:42, Bogdan-Andrei Iancu wrote:
Hi Dan,
The event mechanism is by definition an one way communication system.
I understand what you are looking for, but the event system is not the
answer for it (at least not anymore if you do look to get a sort of
replies back).
You can get CDRS or others via events, but for auth purposes, the
events are not the way to do it.
Do not get me wrong, but (1) as concept, events do not have replies
and (2) the whole implementation is done in this regards. So, let's
not try to have "one solution fits all". Events are limited to one way
direction.
What would be the perfect answer for you is a kind on protocol to
interact with an external app - to be able to push to an external app
various data and to wait for an answer (something like AAA does, but
this is limited to couple of scenarios).
Now, for a current solution : why considering a complex approach with
parking transactions, triggering unpark events via MI, having special
routs and so, when you simply use the script async functions to
execute, suspend and resume the INVITE processing - it is a much
simpler and straight forward approach. What is needed is to
encapsulate the interaction with your billing (request + reply) under
one of the supported async functions (exec, REST, mysql).
Let me know if doing a short call will help in shorting this out.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 28.01.2015 12:10, DanB wrote:
Hey Bogdan,
Thank you for your input and support!
Regarding existing mechanisms, I would still prefer the event part as
it works now since it generates automated CDR vs http rest or exec
where I need to make up my own one. Http would be my second choice if
you ask me.
On the other hand, what about the idea of unparking a transaction
over the MI commands? Would that be possible? In that way I could get
the call authorization event generated manually and park the request
right after. When billing answers, I could unpark it (and set maximum
dialog timeout) over mi.
Thanks,
DanB
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
