Hi Dan,
Indeed, the idea is quite old and it exists since the old SER times when
a very similar mechanism was used for SER and SEMS integration - see the
t_write_fifo() function in TM - this creates a transaction, writes down
stuff to SEMS via a fifo file and puts transaction on hold. It was
waiting for SEMS to trigger via FIFO a reply back to that transaction.
Now, coming back in our days :) . Thanks for clarifying your scenario.
I guess I got the point now.
I'm not in favor of using events as by definition, the events do not
have replies. So it is a mis-usage (or a brutal forcing of the event
concept) in case of your scenario.
Nevertheless, the current async mechanism is exactly what you need - the
only missing part is a kind of protocol to talk to your application (we
have something like that scheduled for the future releases, but I do
not what to get into this topic now).
What you can easily do right now is to use of the existing ways to
perform async ops :
- use the rest_client from script and have in your app a small
REST server to answer
- use the exec() function to trigger an external script - this
script can push the communication to your app and wait for answer in
order to send it back to opensips.
Not sure which one is easier in your case, but you have my full
assistance in exploring and implementing one of the options.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 27.01.2015 19:39, DanB wrote:
Hi Bogdan,
I cannot claim IPR of the idea since we are using it already inside
CGRateS with another proxy so it was not invented by us :).
The process should be something like: when OpenSIPS sends out an event
over a connection, it should be also possible to receive data (answer
or not) over these connections.
OpenSIPS should make the events received (replies or not, depending on
the script admin to identify them) somehow available in some script
routes where we can pick up parked transactions (sharing the ids via
the replied events).
We use such scenario for call authorization inside billing (send
call_auth to billing engine and receive maximum duration for it).
Processing the answer is done in the script and whole thing would
happen asynchronously, hence not anymore depending on the time it
takes for billing to process the request.
Another usage would be for dialog kill when the funds available for
the calls are emptied on billing side. The same event_route will
receive the disconnect request from billing side, will identify there
the dialog and kill it.
If this two way communication would be not suitable for events
infrastructure which you have already developed, would it be possible
to "wake up" the transaction over MI and send it to a script route
plus setting some avps for it maybe?
Thanks for your thoughts on this!
DanB
On 27.01.2015 18:07, Bogdan-Andrei Iancu wrote:
Hi Dan,
Could you detail a bit more your idea ? I'm not sure I get the whole
concept.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 27.01.2015 13:38, DanB wrote:
Hey Guys,
Now that async script routes is an actual subject, I was wondering
if you are considering event replies in script routes (eg: have a
dedicated event_reply route where we can pick up a specific
transaction parked and continue processing it).
A particular applicability is 2 way communication with an external
application like billing engine.
Thanks in advance!
DanB
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
