Hi,
I am trying to create concurrent calls limitations. two questions:
1. should i use dialog module? or is there a better module? 2. i was trying to work with the dialog module, but didnt understand how and where to configure the commands and which to use.... any examples or ideas?
BR, Uri
Hi Uri,
I just got done tailoring this exact concept with the dialog module (you may have just read my posts).
Here is how I am doing it, roughly, for me. I have two places where I am executing the 3rd section below (for outbound and inbound). Your mileage will vary.
modparam("auth_db", "load_credentials", "username") . . . . avp_db_query("select quota from quota where username='$avp(s:username)'", "$avp(s:quota)"); . . . .
$var(SIZE) = 0; get_profile_size("callquota", "$avp(s:username)", "$var(SIZE)"); if( $var(SIZE) >= $avp(s:quota) ){ sl_send_reply("503", "Simultaneous calls limit reached"); xlog("DEBUG: Limit of $var(SIZE) active calls has been reached for $avp(s:username)\n"); exit; } set_dlg_profile("callquota","$avp(s:username)"); get_profile_size("callquota", "$avp(s:username)", "$var(SIZE)"); xlog("DEBUG: there are now $var(SIZE) active calls for $avp(s:username)\n");
On 10/2/11 12:00 PM, "Uri Shacked" ushacked@gmail.com wrote:
Hi, I am trying to create concurrent calls limitations. two questions:
- should i use dialog module? or is there a better module?
- i was trying to work with the dialog module, but didnt understand how and
where to configure the commands and which to use.... any examples or ideas? BR, Uri
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Graham,
Good deal. The one improvement I would suggest would be to use sqlops for custom DB queries as it is more flexible, and is the canonical way to do them now as of >= 1.5.0. avp_db_query() could go away at some point.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 2, 2011, at 10:03 PM, Graham Wooden graham@g-rock.net wrote:
Hi Uri,
I just got done tailoring this exact concept with the dialog module (you may have just read my posts).
Here is how I am doing it, roughly, for me. I have two places where I am executing the 3rd section below (for outbound and inbound). Your mileage will vary.
modparam("auth_db", "load_credentials", "username") . . . . avp_db_query("select quota from quota where username='$avp(s:username)'", "$avp(s:quota)"); . . . .
$var(SIZE) = 0; get_profile_size("callquota", "$avp(s:username)", "$var(SIZE)"); if( $var(SIZE) >= $avp(s:quota) ){ sl_send_reply("503", "Simultaneous calls limit reached"); xlog("DEBUG: Limit of $var(SIZE) active calls has been reached for $avp(s:username)\n"); exit; } set_dlg_profile("callquota","$avp(s:username)"); get_profile_size("callquota", "$avp(s:username)", "$var(SIZE)"); xlog("DEBUG: there are now $var(SIZE) active calls for $avp(s:username)\n");On 10/2/11 12:00 PM, "Uri Shacked" ushacked@gmail.com wrote:
Hi,
I am trying to create concurrent calls limitations. two questions:
- should i use dialog module? or is there a better module?
- i was trying to work with the dialog module, but didnt understand how and where to configure the commands and which to use.... any examples or ideas?
BR, Uri
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
El Sun, 02 Oct 2011 21:03:38 -0500 Graham Wooden graham@g-rock.net escribió:
Hi Uri,
I just got done tailoring this exact concept with the dialog module (you may have just read my posts).
Two tips here:
Due to a couple of bugs in the dialog module I'd suggest you to run this code after the user auth has been successfull. You'll need to call dlg_manage() function first.
The other bug makes the dialog not being freed if you send a sl reply generated by the proxy. You should call t_newtran + t_reply to send a statefull reply to the user.
2011/10/3 Jon Bonilla manwe@aholab.ehu.es:
Due to a couple of bugs in the dialog module I'd suggest you to run this code after the user auth has been successfull. You'll need to call dlg_manage() function first.
The other bug makes the dialog not being freed if you send a sl reply generated by the proxy. You should call t_newtran + t_reply to send a statefull reply to the user.
Mixing two points above into a single one:
- Just call dlg_manage() after the authentication and authorization has been made.
As a recommendation, call dlg_manage() just before t_relay() and you are done (and you will avoid both bugs explained by Jon).
Am 08.10.2011 um 21:44 schrieb Iñaki Baz Castillo:
2011/10/3 Jon Bonilla manwe@aholab.ehu.es:
Due to a couple of bugs in the dialog module I'd suggest you to run this code after the user auth has been successfull. You'll need to call dlg_manage() function first.
The other bug makes the dialog not being freed if you send a sl reply generated by the proxy. You should call t_newtran + t_reply to send a statefull reply to the user.
Mixing two points above into a single one:
- Just call dlg_manage() after the authentication and authorization
has been made.
As a recommendation, call dlg_manage() just before t_relay() and you are done (and you will avoid both bugs explained by Jon).
This works around most issues w.r.t. to the dialog module. However, there's at least one case which cannot be covered: If a proxy behind the one tracking a dialog returns a status code that must not render the dialog as failed (e.g., 407), as of the current implementation the dialog *will* transition into the failure state. According to the standard, this must not occur.
As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible. Overall, I believe that dialog module usage should be more robust and work out of the box; that is, it shouldn't matter where you place dlg_manage(), things should just work and handle the tricky cases intelligently. That's something for the long run though. For the time being, the two hints you gave can definitely be considered good practice regarding the dialog module.
Cheers,
--Timo
[1] http://sip-router.org/tracker/index.php?do=details&task_id=146
On 10/8/2011 6:03 PM, Timo Reimann wrote:
As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible. Overall, I believe that dialog module usage should be more robust and work out of the box; that is, it shouldn't matter where you place dlg_manage(), things should just work and handle the tricky cases intelligently.
I'm sure the developers would welcome you to submit a patch.
On Monday 10 October 2011, Jim Lucas wrote:
As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible. Overall, I believe that dialog module usage should be more robust and work out of the box; that is, it shouldn't matter where you place dlg_manage(), things should just work and handle the tricky cases intelligently.
I'm sure the developers would welcome you to submit a patch.
Hi Jim,
Timo is the one developer which has spend the most time with the dialog module in the last months, IMHO. ;-)
Best regards,
Henning
2011/10/10 Jim Lucas lists@cmsws.com:
On 10/8/2011 6:03 PM, Timo Reimann wrote:
As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible. Overall, I believe that dialog module usage should be more robust and work out of the box; that is, it shouldn't matter where you place dlg_manage(), things should just work and handle the tricky cases intelligently.
I'm sure the developers would welcome you to submit a patch.
Humm, Time *is* the developer here ;)
On 10/10/2011 9:20 AM, Iñaki Baz Castillo wrote:
2011/10/10 Jim Lucas lists@cmsws.com:
On 10/8/2011 6:03 PM, Timo Reimann wrote:
As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible. Overall, I believe that dialog module usage should be more robust and work out of the box; that is, it shouldn't matter where you place dlg_manage(), things should just work and handle the tricky cases intelligently.
I'm sure the developers would welcome you to submit a patch.
Humm, Time *is* the developer here ;)
My apologies to Timo.
The way he said it, I read that as he was suggesting that someone else should develop it.
On 10.10.2011 19:00, Jim Lucas wrote:
On 10/10/2011 9:20 AM, Iñaki Baz Castillo wrote:
2011/10/10 Jim Lucas lists@cmsws.com:
On 10/8/2011 6:03 PM, Timo Reimann wrote:
As explained by myself in Flyspray issue #146[1], a fix to this
problem is
quite feasible. Overall, I believe that dialog module usage should
be more
robust and work out of the box; that is, it shouldn't matter where
you place
dlg_manage(), things should just work and handle the tricky cases intelligently.
I'm sure the developers would welcome you to submit a patch.
Humm, Time *is* the developer here ;)
My apologies to Timo.
The way he said it, I read that as he was suggesting that someone else should develop it.
Check the Flyspray issue linked before and see who reported and is assigned to the bug. Hint: It involves me. :)
Cheers,
--Timo
Not only that, but the fix is not trivial. Contrary to how it may appear to a non-developer, this problem cannot be solved by just making a little patch.
Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 10, 2011, at 1:00 PM, Jim Lucas lists@cmsws.com wrote:
On 10/10/2011 9:20 AM, Iñaki Baz Castillo wrote:
2011/10/10 Jim Lucas lists@cmsws.com:
On 10/8/2011 6:03 PM, Timo Reimann wrote:
As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible. Overall, I believe that dialog module usage should be more robust and work out of the box; that is, it shouldn't matter where you place dlg_manage(), things should just work and handle the tricky cases intelligently.
I'm sure the developers would welcome you to submit a patch.
Humm, Time *is* the developer here ;)
My apologies to Timo.
The way he said it, I read that as he was suggesting that someone else should develop it.
-- Jim Lucas
http://www.cmsws.com/ http://www.cmsws.com/examples/ http://www.bendsource.com/
C - (541) 408-5189 O - (541) 323-9113 H - (541) 323-4219
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Alex Balashov writes:
Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes.
one can always use sems to limit number of simultaneous calls (see cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with right tool (= sbc) than to try to twist sip proxy to do something that it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying, topology hiding, reliable accounting, anonymity, etc. with one single tool.
-- juha
In theory, this sounds appealing. But we have had a lot of problems with SEMS performance and stability with a large number of calls. We are rather fond of the proxy-based approach because it works, and works well.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 10, 2011, at 2:03 PM, Juha Heinanen jh@tutpro.com wrote:
Alex Balashov writes:
Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes.
one can always use sems to limit number of simultaneous calls (see cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with right tool (= sbc) than to try to twist sip proxy to do something that it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying, topology hiding, reliable accounting, anonymity, etc. with one single tool.
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Alex,
We've had huge performance and stability issues with SEMS in the past as well, but together with the Frafos guys we've brought version 1.4 with thread-pool enabled into a stable state for large-scale deployments.
We're running it in production in various deployments with thousands of parallel calls without issues for months now. Load tests have shown that we can run it with >100 caps and tens of thousands of parallel calls over several days without significant load or cpu usage.
Andreas
On 10/10/2011 08:56 PM, Alex Balashov wrote:
In theory, this sounds appealing. But we have had a lot of problems with SEMS performance and stability with a large number of calls. We are rather fond of the proxy-based approach because it works, and works well.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 10, 2011, at 2:03 PM, Juha Heinanen jh@tutpro.com wrote:
Alex Balashov writes:
Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes.
one can always use sems to limit number of simultaneous calls (see cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with right tool (= sbc) than to try to twist sip proxy to do something that it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying, topology hiding, reliable accounting, anonymity, etc. with one single tool.
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Andreas,
Good to know. These tens of thousands of concurrent calls are bridged signaling-only, I assume? What about RTP relay performance?
One of the reasons I've always liked rtpproxy is that it forwards quite a respectable number of streams concurrently, for a userspace process, and is easy to horizontally scale by just adding more rtpproxies to the set, and/or binding additional instances to additional CPU cores.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 10, 2011, at 3:34 PM, Andreas Granig agranig@sipwise.com wrote:
Alex,
We've had huge performance and stability issues with SEMS in the past as well, but together with the Frafos guys we've brought version 1.4 with thread-pool enabled into a stable state for large-scale deployments.
We're running it in production in various deployments with thousands of parallel calls without issues for months now. Load tests have shown that we can run it with >100 caps and tens of thousands of parallel calls over several days without significant load or cpu usage.
Andreas
On 10/10/2011 08:56 PM, Alex Balashov wrote:
In theory, this sounds appealing. But we have had a lot of problems with SEMS performance and stability with a large number of calls. We are rather fond of the proxy-based approach because it works, and works well.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 10, 2011, at 2:03 PM, Juha Heinanen jh@tutpro.com wrote:
Alex Balashov writes:
Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes.
one can always use sems to limit number of simultaneous calls (see cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with right tool (= sbc) than to try to twist sip proxy to do something that it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying, topology hiding, reliable accounting, anonymity, etc. with one single tool.
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Alex,
We use our own kernel-based mediaproxy in our systems, so I can't tell much about rtpproxy, beside that our ngcp-mediaproxy-ng uses the same control protocol (or a basic sub-set of it, e.g. no recording or stream forking etc), so you can use it as drop-in replacement of rtpproxy.
See http://deb.sipwise.com/spce/2.2/pool/main/n/ngcp-mediaproxy-ng/ , it's part of the open-source sip:provider CE system (http://www.sipwise.com/products/spce/), which uses kamailio, sems and mediaproxy-ng for SIP and RTP.
Andreas
On 10/10/2011 09:37 PM, Alex Balashov wrote:
Andreas,
Good to know. These tens of thousands of concurrent calls are bridged signaling-only, I assume? What about RTP relay performance?
One of the reasons I've always liked rtpproxy is that it forwards quite a respectable number of streams concurrently, for a userspace process, and is easy to horizontally scale by just adding more rtpproxies to the set, and/or binding additional instances to additional CPU cores.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 10, 2011, at 3:34 PM, Andreas Granig agranig@sipwise.com wrote:
Alex,
We've had huge performance and stability issues with SEMS in the past as well, but together with the Frafos guys we've brought version 1.4 with thread-pool enabled into a stable state for large-scale deployments.
We're running it in production in various deployments with thousands of parallel calls without issues for months now. Load tests have shown that we can run it with >100 caps and tens of thousands of parallel calls over several days without significant load or cpu usage.
Andreas
On 10/10/2011 08:56 PM, Alex Balashov wrote:
In theory, this sounds appealing. But we have had a lot of problems with SEMS performance and stability with a large number of calls. We are rather fond of the proxy-based approach because it works, and works well.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 10, 2011, at 2:03 PM, Juha Heinanen jh@tutpro.com wrote:
Alex Balashov writes:
Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes.
one can always use sems to limit number of simultaneous calls (see cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with right tool (= sbc) than to try to twist sip proxy to do something that it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying, topology hiding, reliable accounting, anonymity, etc. with one single tool.
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hey Alex,
On 10.10.2011 19:53, Alex Balashov wrote:
Not only that, but the fix is not trivial. Contrary to how it may appear to a non-developer, this problem cannot be solved by just making a little patch.
Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes.
Agreed that fixing the issue for locally sent responses is somewhat tricky. Apart from trying to link stateless responses to transactions, however, there are other, less perfect solutions. For instance, you could allow reusing dialogs on arrival of a subsequent INVITE if the initial INVITE wasn't forwarded yet (and therefore must have been replied to locally). It's probably not trivial to implement but keeps the required modifications to a single module.
Then again, you can work around such cases by not tracking dialogs for which you know you are going to respond statelessly to (and therefore require no tracking) in the first place. It's not perfectly elegant from a usability point of view but it works.
By the way, I came across this bug from a specific scenario where authentication takes place behind the dialog-tracking proxy; that is, a 407 was received from upstream and forwarded back to the caller. In such scenarios, the approach I devised in the bug report should do well and not involve too much work.
Cheers,
--Timo
-
Alex Balashov -
Andreas Granig -
Graham Wooden -
Henning Westerholt -
Iñaki Baz Castillo -
Jim Lucas -
Jon Bonilla -
Juha Heinanen -
Timo Reimann -
Uri Shacked