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
[OpenSIPS-Users] Ghost
Will OpenSIPS be susceptible to the GHOST vulnerability (recently found in glibc)? John Quick Smartvox Limited ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Ghost
If you use a glibc version that is affected ... yes. See resolve.c, opensips makes use of gethostbyname(). -Eric On 01/29/2015 07:28 AM, John Quick wrote: Will OpenSIPS be susceptible to the GHOST vulnerability (recently found in glibc)? John Quick Smartvox Limited ___ 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
[OpenSIPS-Users] MSILO Module can't work
Hi, I am use opensips 1.11.3 on centos5.11,it's everything is ok . I want to deploy the MSILO Module ,loadmodulećadd route script in the cfg the user A send message to B who was offline;the message save to the server; when the user B online,the message didn't from server sent to B user,why? thanks cfg Description: Binary data ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users