[OpenSIPS-Users] Async Event route_replies

[Bogdan-Andrei Iancu]

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
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>