Re: [OpenSIPS-Devel] [opensips] Dialplan Features/Patch Backport (#319)
I also committed code ... but I don't see it ... uuuhmm! --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/319#issuecomment-54258296___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Dialplan Features/Patch Backport (#319)
I think I'm doing confusion (sorry I'm not really handy with git)!!! I created a branch (dialplan_newfeatures) of my pull request and committed code there: https://github.com/Parantido/opensips/commit/3079aa128f8fe63831a988f13cb8c79d9ffa2930 Could you help me? --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/319#issuecomment-54258727___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] Asynchronous processing in OpenSIPS 1.12
Brett,
The timeout for the async ops will be control by the reactor (like
triggering the timouts) and set by the module starting the op - like the
rest_client module will set the timeout for the HTTP rest queries.
The processes are not suspended, just the context of an execution. So at
the end is just about memory - of course there should be a safety net to
limit the number of suspended async I/Os per type of I/O. Each type of
I/O op will have a priority in relation to other I/O ops (like timer
jobs higher than aysnc resume, async resume higher than reading from
network).
An async I/O is done during handling a SIP message, so it does not
interfere with TM timers (which are activated only when sending the
traffic out). otherwise the dialogs and transactions (with their
eco-system) are not affected at all.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 02.09.2014 19:53, Brett Nemeroff wrote:
I'm curious what the failure cases look like here..
What happens when your long running db query is excessively long? Is
there a timeout? What happens if you have 1000s of backed up
processes. Would love to see some sort of fifo command somehow
quantify the effectiveness of it being async. Not sure how to say this
right. But I'd like to be able to query a value that says either bg
tasks are being handled in a timely fashion or bg tasks are so slow
it's starting to affect performance
Of course, these are not normal cases... wondering how graceful we
can allow it to be broken. I assume that the context saving will take
X memory and eventually it will fill up? Where is that memory stored?
How is it allocated? How much memory do you need for each backgrounded
task?
Another thought.. how are dialog/transaction variables handled?
AVPs? vars? How are dialogs handled across such an operation? What
about standard (SIP) timer operations? What about dialog fr_timer and
fr_inv_timer, do they continue to run?
Thanks, really looking forward to async!
-Brett
On Tue, Sep 2, 2014 at 11:26 AM, Răzvan Crainea raz...@opensips.org
mailto:raz...@opensips.org wrote:
Hi all,
Among the last discussion of the last IRC meeting[1] was related
to Asynchronous processing in OpenSIPS script - we want to add a
new mechanism that allows you to perform asynchronous operations
(such as DB , REST or exec operations) directly from the script.
Using this feature will increase the throughput of OpenSIPS, since
the SIP processes will no longer be stuck waiting for I/O responses.
When reaching an asynchronous operation, the SIP message
processing will be stopped, and resumed in a different script
route. In the script, this should be reflected something like this:
route {
...
# other non I/O operations
async(my_resume_route) {
avp_db_query(SELECT setid from subscribers where username
= '$fU', $avp(setid));
}
# we never get here.
exit;
}
route[my_resume_route] {
xlog(The set used by the callee is $avp(setid)\n);
# continue message processing
}
Only the functions that are used in an async block will be ran
asynchronously. If the function does not support async processing,
it will block waiting for the response and resume in the route
indicated by the async block - so the scripting experience will
be the same even if the async OP could not be done.
In order to resume the processing in a different route, we need to
store a context of the message. This will be done using the
transaction module[2]. If this module is not used, the
asynchronous mechanism will not work.
lirakis suggested to have different processes that waits for the
asynchronous I/O responses and continues the processing. However,
we think having the SIP worker processes resume the operations
will behave better, since we'll have fewer processes and we won't
loose time with context switches.
How do you see this feature? How would you like to use it? Feel
free to contribute with any input you find suitable!
[1] http://www.opensips.org/Community/IRCmeeting20140827
[2] http://www.opensips.org/html/docs/modules/1.12.x/tm
Best regards,
--
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com http://www.opensips-solutions.com
___
Users mailing list
us...@lists.opensips.org mailto:us...@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
us...@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [FYI] OpenSIPS Social networks
Hi, FYI, we put together a web page with all social networks where OpenSIPS project is present and active, so people know where to find us: http://www.opensips.org/Community/Networking Regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] Message compression in OpenSIPS 1.12
On 03.09.2014 11:59, Saúl Ibarra Corretgé wrote: Hi Razvan, On 02 Sep 2014, at 18:25, Răzvan Crainea raz...@opensips.org wrote: 2)Compressing the SIP message (using gzip). The idea is to take the SDP body and several headers that are not used in the routing logic, compress them, apply a base64 transformation and add to the message's body. A use case for this is a platform that has several edge servers (SBCs) and a few core instances - when entering the platform the message compression should be applied and then sent to the core servers. Inside the core networks, the messages should be carried in the compressed format to reduce the bandwidth. When leaving the network, the message has to be decompressed and forwarded to the next gateway without any compression, since the other equipments might not understand them. There will be several functions exported in the script: a) compress_msg(1,Header1|Header2); compresses the body of the message and listed headers b) decompress_msg(); decompress both headers and body What do you think about this approach? Is this something you find useful? Since we don't have a final decision for this topic, we are looking for more input from you guys.Anybody is welcome to throw any kind of useful feedback on this matter, so don't be shy! IIRC this is not standard, and Apple uses it somewhere on their FaceTime implementation. Kamailio has it and someone was working on a patch for PJSIP, but other than that I’m not sure how useful it is, servers could use TCP between them. It is not indeed, but the main idea is to first help you with better handling traffic inside your network (which may be up to 3 or 4 OpenSIPS boxes when you have a distributed platform) ; handling means bandwidth and processing as parsing SIP messages - like headers (maybe 20) or body you do not care about and you just want to carry through without a need to parse and look. And maybe in the future it will be some progress into standardizationfor now I see the real need for it (at least for me:) ). Regards, Bogdan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [FYI] OpenSIPS Social networks
On 03 Sep 2014, at 11:44, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi, FYI, we put together a web page with all social networks where OpenSIPS project is present and active, so people know where to find us: http://www.opensips.org/Community/Networking Hi Bogdan, The Facebook page seems to be a person called “Opensips Server, not an actual page people can “like”. That was common practice before Facebook introduced “Pages”, but not anymore. Regards, -- Saúl Ibarra Corretgé AG Projects signature.asc Description: Message signed with OpenPGP using GPGMail ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] Asynchronous processing in OpenSIPS 1.12
On 03.09.2014 12:06, Saúl Ibarra Corretgé wrote:
On 02 Sep 2014, at 18:26, Răzvan Crainea raz...@opensips.org wrote:
Hi all,
Among the last discussion of the last IRC meeting[1] was related to
Asynchronous processing in OpenSIPS script - we want to add a new mechanism
that allows you to perform asynchronous operations (such as DB , REST or exec
operations) directly from the script. Using this feature will increase the
throughput of OpenSIPS, since the SIP processes will no longer be stuck waiting
for I/O responses.
When reaching an asynchronous operation, the SIP message processing will be
stopped, and resumed in a different script route. In the script, this should be
reflected something like this:
route {
...
# other non I/O operations
async(my_resume_route) {
avp_db_query(SELECT setid from subscribers where username = '$fU',
$avp(setid));
}
# we never get here.
exit;
}
route[my_resume_route] {
xlog(The set used by the callee is $avp(setid)\n);
# continue message processing
}
Only the functions that are used in an async block will be ran asynchronously. If the
function does not support async processing, it will block waiting for the response and resume in
the route indicated by the async block - so the scripting experience will be the same
even if the async OP could not be done.
I find this quite problematic. How does John Doe know a function supports async
or not? Maybe the configuration checker can know this and not let OpenSIPS
start if you are doing it wrong? Alternatively, blocking functions could be ran
in a thread pool thus giving the illusion of them being async.
First of all, the function will be documented as supporting Async and
the script parser may check it (we will export some extra flags for the
function to say it can do async).
Secondly, the script will allow you to use any combination of functions
and script macro - I mean the script will allow you to use an async
function in a non-async way (and the function will act as sync) or to
use a non-async function in an async way (the function will act as async
and with a jump to resume route).
Regards,
Bogdan
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] Asynchronous processing in OpenSIPS 1.12
On 03 Sep 2014, at 11:59, Bogdan-Andrei Iancu bog...@opensips.org wrote:
On 03.09.2014 12:06, Saúl Ibarra Corretgé wrote:
On 02 Sep 2014, at 18:26, Răzvan Crainea raz...@opensips.org wrote:
Hi all,
Among the last discussion of the last IRC meeting[1] was related to
Asynchronous processing in OpenSIPS script - we want to add a new mechanism
that allows you to perform asynchronous operations (such as DB , REST or
exec operations) directly from the script. Using this feature will increase
the throughput of OpenSIPS, since the SIP processes will no longer be stuck
waiting for I/O responses.
When reaching an asynchronous operation, the SIP message processing will be
stopped, and resumed in a different script route. In the script, this
should be reflected something like this:
route {
...
# other non I/O operations
async(my_resume_route) {
avp_db_query(SELECT setid from subscribers where username = '$fU',
$avp(setid));
}
# we never get here.
exit;
}
route[my_resume_route] {
xlog(The set used by the callee is $avp(setid)\n);
# continue message processing
}
Only the functions that are used in an async block will be ran
asynchronously. If the function does not support async processing, it will
block waiting for the response and resume in the route indicated by the
async block - so the scripting experience will be the same even if the
async OP could not be done.
I find this quite problematic. How does John Doe know a function supports
async or not? Maybe the configuration checker can know this and not let
OpenSIPS start if you are doing it wrong? Alternatively, blocking functions
could be ran in a thread pool thus giving the illusion of them being async.
First of all, the function will be documented as supporting Async and the
script parser may check it (we will export some extra flags for the function
to say it can do async).
Secondly, the script will allow you to use any combination of functions and
script macro - I mean the script will allow you to use an async function in a
non-async way (and the function will act as sync) or to use a non-async
function in an async way (the function will act as async and with a jump to
resume route).
My concern is with that last part: if a function which doesn’t support async is
called within an async block it will block but then make the jump thus
deceiving the user into believing it was async when it isn’t. We need to fail
loudly and tell users they are doing it wrong, iMHO.
Regards,
--
Saúl Ibarra Corretgé
AG Projects
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [FYI] OpenSIPS Social networks
OK, we will look into it and fix it :). Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 03.09.2014 12:50, Saúl Ibarra Corretgé wrote: On 03 Sep 2014, at 11:44, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi, FYI, we put together a web page with all social networks where OpenSIPS project is present and active, so people know where to find us: http://www.opensips.org/Community/Networking Hi Bogdan, The Facebook page seems to be a person called “Opensips Server, not an actual page people can “like”. That was common practice before Facebook introduced “Pages”, but not anymore. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Dialplan Features/Patch Backport (#319)
Checkout the master branch: git checkout master Rebase against your other branch: git rebase dialplan_newfeatures Push the changes to your forked repository. The Pull Request should update itself. git push --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/319#issuecomment-54278865___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] OpenSIPS Summit 2014 in Chicago - Post Facts
Hi everyone ! Following the requests of people who were not able to attend, we put together a nice collection of presentations, videos and photos - all are shared here: http://www.opensips.org/Community/Summit-2014Chicago Enjoy ! Thanks again to our sponsors, to the people who helped organizing and of course to our beautiful audiance ! Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] Asynchronous processing in OpenSIPS 1.12
My concern is with that last part: if a function which doesn’t support async is called within an async block it will block but then make the jump thus deceiving the user into believing it was async when it isn’t. We need to fail loudly and tell users they are doing it wrong, iMHO. Of course, we can detect that at script parsing and decide how to handle it: - ignore and do it blocking - warning and do it blocking - error and do not start. I’d say we shouldn’t start :-) Regards, -- Saúl Ibarra Corretgé AG Projects signature.asc Description: Message signed with OpenPGP using GPGMail ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] DB_MYSQL - modparam ping_interval does nothing - No pings sent ever (#320)
Tried on 1.10 and 1.11. No ping packets are being sent to keep the connection alive. I traced all mysql traffic for half an hour, and no ping was sent. Tried it with modparam set to 300, 30 and with no modparam at all which would mean 300 sec. What we can see in the code is that the modparam is being exported into a variable, but this variable is never used again. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/320___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] Asynchronous processing in OpenSIPS 1.12
On 03.09.2014 14:43, Saúl Ibarra Corretgé wrote: My concern is with that last part: if a function which doesn’t support async is called within an async block it will block but then make the jump thus deceiving the user into believing it was async when it isn’t. We need to fail loudly and tell users they are doing it wrong, iMHO. Of course, we can detect that at script parsing and decide how to handle it: - ignore and do it blocking - warning and do it blocking - error and do not start. I’d say we shouldn’t start :-) I will keep that in mind ;) ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Topology_Hiding - Preserving Non-Transport Params (#301)
Closed #301. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/301#event-160826836___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Topology_Hiding - Preserving Non-Transport Params (#301)
Is there any update on this? --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/301#issuecomment-54366621___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Topology_Hiding - Preserving Non-Transport Params (#301)
Reopened #301. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/301#event-160829528___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
