Re: [OpenSIPS-Users] Async Event route_replies
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
Re: [OpenSIPS-Users] Async Event route_replies
Hi Brett, Yes, that is on the TODO list, to have the dialog module exporting some dialog related events. Not sure if it will make it in 2.1 as there are many other on TODO list (like the proto stack rework, adding WS, etc). If time allows, why not :) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 28.01.2015 15:14, Brett Nemeroff wrote: Hey All, An idea that I've tossed out before that is similar here is event routes that are triggered on dialog state changes. I have to admit I don't know if the 2.x already has this or not but I think especially on the context of a billing engine, tying and event to a dialog state change makes sense. I like this more than embedding the event logic into the acc module since you can do things like manage a list of connected calls with dialog events and external REST calls very easily and its a more efficient push model instead of a MI pull model, which is unwieldy for larger switches Sent from my iPhone On Jan 28, 2015, at 4:10 AM, DanB danb.li...@gmail.com 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Async Event route_replies
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
Re: [OpenSIPS-Users] Async Event route_replies
Hey All, An idea that I've tossed out before that is similar here is event routes that are triggered on dialog state changes. I have to admit I don't know if the 2.x already has this or not but I think especially on the context of a billing engine, tying and event to a dialog state change makes sense. I like this more than embedding the event logic into the acc module since you can do things like manage a list of connected calls with dialog events and external REST calls very easily and its a more efficient push model instead of a MI pull model, which is unwieldy for larger switches Sent from my iPhone On Jan 28, 2015, at 4:10 AM, DanB danb.li...@gmail.com 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Async Event route_replies
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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Async Event route_replies
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
[OpenSIPS-Users] Async Event route_replies
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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Async Event route_replies
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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Async Event route_replies
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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
