Thanks for the info Jan... It's good to know that it worked. -- Daryl On 7/8/05, Jan Janak <jan(a)iptel.org> wrote:

Hi Jan, My solution for disconnecting calls where the customer has run out of credit is to use SER to generate a BYE to the gateway. I use exec_dset and exec_msg from ser.cfg to store in a MySQL table some fields from the INVITE and ACK messages that setup the call. Then I have a process which runs periodically on my server that queries the table to find calls that need to be disconnected and generates, using the SER fifo, a BYE message to the Cisco gateway which disconnects the call. Not very elegant solution but it appears to work and I don't have to handle the media stream. I could also send a BYE to the phone but I don't do that at the moment. Please could you tell us about how you are solving this problem in production systems? I expect you have a more elegant and professional solution. Regards Stuart -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jan Janak Sent: 08 July 2005 19:28 To: Daryl Sanders Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] Session-Timers for Prepaid I tried this a long time ago with a Cisco gateway. It worked, SER did not let re-INVITEs through and the gateway terminated the call. We are not using it anywhere in production. Jan. On 02-07-2005 06:48, Daryl Sanders wrote: _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Hello I'm sorry but what you said could be true for first world but we from third world and other not developed countries will use pre-paid and pay-per-minute for years to come. This is a major drawback to widespread usage of SER instead of asterisk, and you could notice that by the number of ppl who asks in this list for pre-paid and charge-by-minute solutions to SER. just my $0.02, no flame war intended. Cheers !3runo from Brazil 'Jan Janak' wrote:

Hello there nice feedback, Iqbal, thanks! Iqbal wrote: everyone talks about how SER scales compared to asterisk but I must confess I have some doubts on that matter. most setups shown here in the list use any of rtpproxy or mediaproxy, which in turn will cause traffic to pass through SER host and drop scale accordling. the solutions to that (as I've read on the list) are not so "easy" setups like non standard LVS patches, multiple SER instances with some sort of memory and/or database contact replications among other creative arrangements that are not included in default SER, nor easy to install - or free (as in beer). so, how many calls a "decent" server (P4, 2.xGHz, 2GB RAM) running SER plus mediaproxy or rtpproxy can really handle? 1k simultaneous calls? and how many users connected? 2k? anyone willing to give a shot, perhaps from experience? most of the time the setups shown here are also stateless, which would at first glance increase the scalability of SER solution. as I stated above, the scalability with mediaproxy and rtpproxy drops hard, but forgetting about that for a minute, how about running SER statefull? to include some info for every running call in memory (or database) and periodically (a thread maybe) runnning the call list and sending BYEs to both parties would eat so much memory or processor power that would prevent one to use that solution at all, in our "decent" server setup? please don't take me wrong, I really think SER is a great server, and it is far less complex to install than the full featured asterisk (thanks to the well written docs and ONSIP's iniciative), but the advantages of having control of calls and callers seems a reasonable adition to me, mainly of course if it can be enabled to who needs it while mantaining the nice low footprint for the ones that want to run SER on their OPENWRT boxes. (I really liked the proposed solution of saving call info and periodically sending the BYEs through fifo interface. if it could be compiled as a module and/or perhaps a socket interface to a running "call server" instead of exec'ing the (external) perl routine at each call would increase scalability a lot while satisfing all of us that needs call control but don't know how/want to integrate an external/alien B2BUA to our SER setups). Cheers, !3runo from Brazil

The mediaproxy part is used for natting problems, and this can be separated out from the proxy itself, however there is still overhead I guess if you want the entire solution put together. If you don't have nat problems and you get ur customers to use external IP's then there is a huge benefit. the lvs part of it is about having multiple redundant ser's working together, and doing some sort of load balancing, Because ser is designed as a proxy, which makes it inherently different from asterisk, it shouldn't/cant be compared to asterisk. Asterisk is actually easier (I find :-)) than ser. A plugin module like u suggest would be great, maybe not even make it part of ser, just a module, I know people will say use some other b2bua, but the module with a tighter intergration in ser is better. The way I have it currently is ser sitting infron of everything else, i.e the gateways and asterisk (which in my case doesnt do pstn, but i just use it for pbx stuff) The mediaproxy and all can then all be pulled onto sep servers as and when required. SER + asterisk I think is very powerful, since ser can handle all the message stuff and let asterisk do the pbx part. This way users who dont need mediaproy, dont use it (some saving), those who do not need features of asterisk, dont, (again saving), and those who need both, well I have to accept that I take a hit, but why take a hit all the time. If I have 10000 users, out of that 1% is corporate using all pbx stuff, and the rest 9900 50% use nat 50% dont, I have a 50% saving, which means if I can fine tune my billing, I get prepay,postpay, with a few lost cents here and there. I concede it will never be perfect, but I am designing something for the 21st century, and my thoughts are the billing by minute will go, and flat rate per month any country to any country will be the way, so fo rthe short term, I am patching :-) Iqbal On 7/9/2005, "Bruno Lopes F. Cabral" <bruno(a)openline.com.br> wrote:

See inline. Bruno Lopes F. Cabral wrote: This is not true. A reasonable setup will at least have rtpproxy on another server than ser. With mediaproxy you can do load balancing across multiple servers, so using rtpproxy or mediaproxy does not impact the scalability of your SER server. This is true. Currently there is no good open source solution for running multiple SERs. I have in previous emails (2-3 months ago) defined in detailed the different approaches and there are many good discussions on this topic. One simple solution will be to pick up the Path module recently submitted to the experimental CVS module and use it to implement routing of calls through the correct registration server. I have this on my to-do list (set up a test scenario) and hope to include that (eventually) as an appendix to the ONsip Getting Started document, but I don't foresee this in the near future. However, I would appreciate reports on attempts of using Path module this way. As the media streams will not go through SER, the simultaneous calls measure is not really interesting. The measure used is number of call setups per second (and possible with a mix of registration requests). Your setup (how you authenticate and what kind of lookups and modules you use) will greatly impact the number of calls handled per second. Anyway, the number is BIG, if you skip authentication and do just basic call setup. You really need to stress test your own scenario: http://www.pernau.at/kd/voip/bookmarks-sip-rtp-ua.html#siptestutility Well, you can do that. Make a module! However, you should now that you are trying to make SER do something it was not intended to do. It is intended to be a stateless, high-scalability SIP server. You can probably turn it into a stateful server by creating a module, but I'm sure you will want to only implement very specific functionalities. Then people start asking: can I do this or that? Yes, you can make a module that will save info in the DB and then you can register functions that will be called on timers. Does this make SER stateful? Nope. You have just hacked a functionality that normally requires a stateful server. On the other hand, once you have a module registering info, it can probably be used for other "hacks" too. BTW, acc module can be seen as the module registering stateful info. You just need a module that can be invoked on timers. It's just that in a SER perspective, storing stuff in a DB is not good enough (due to scalability). You will need to implement a cache, export functions for other modules to use etc... And another thing, the design of SER is to handle incoming requests and react "reactively". A module should be able to submit a new message and create a new dialog, but you need to be careful not to mess of the dialog you are in... g-)

Hi Iqbal, My script runs every few minutes. I don't use a disconnect time for each call because there may be simultaneous calls using the credit from one prepaid account. I too have looked at session timers but the gateways I'm using have the minimum timer value set to 30 minutes which is too long for that to be my primary method for disconnection but it is OK as a backup. Regards Stuart -----Original Message----- From: Iqbal [mailto:iqbal@gigo.co.uk] Sent: 09 July 2005 15:00 To: stuart(a)jubileeconsultancy.com; jan(a)iptel.org Cc: serusers(a)lists.iptel.org Subject: RE: [Serusers] Session-Timers for Prepaid Stuart, doing something similar here, wanted to know your cron setup if possible, because each user would have a diff disconnect time, depending on their credit left and destination dialed. I looked at having variable session timers per user also, but havent had the time to implement it as yet. Iqbal On 7/8/2005, "Stuart Kirkwood - Jubilee Consultancy Limited" <stuart(a)jubileeconsultancy.com> wrote: credit exec_msg periodically

For each run of the script I calculate the cost of each call and a total of all the current calls for a prepaid account. I then disconnect all the calls for any account which has no credit left. I update the credit left when a call ends. Stuart -----Original Message----- From: Iqbal [mailto:iqbal@gigo.co.uk] Sent: 09 July 2005 16:12 To: stuart(a)jubileeconsultancy.com; jan(a)iptel.org Cc: serusers(a)lists.iptel.org Subject: RE: [Serusers] Session-Timers for Prepaid Do u recalculate the credit left for each user at every cron and update, or do you just have a base figure for each account, which gets updates when the customers himself hangs up EG when I start a call I have £2.00 left (assuming call is to UK), obviously the amount left depends upon the destination left (or are you doing something diff) Now after 5 mins, lets say ur cron runs, and he is left with £2.00 - 5*0.01 (assuming 1p cost) = 1.95, now do u update the credit left with 1.95, or leave it at 2.00, and then 5 mins later again do £2.00 - 10*0.01 and keep doing this until the user hangs up, at that point the £2.00 is deducted from. Iqbal On 7/9/2005, "Stuart Kirkwood - Jubilee Consultancy Limited" <stuart(a)jubileeconsultancy.com> wrote:

Hi Sebastian, I use a Perl script which runs my queries and disconnects any calls for users that have run out of credit. The script then sleeps for a time and loops back to the beginning of the script. Nothing clever! I don't set a timer at the start of each call because there may be multiple simultaneous calls using the same credit and I don't reduce the credit until the call ends. Regards Stuart -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Sebastian Kühner Sent: 11 July 2005 14:45 To: serusers(a)lists.iptel.org Subject: Re: [Serusers] Session-Timers for Prepaid Hi Stuart, I'm with the same problem at this moment. I have a billing system on my server with asterisk (credit, rates, call-cost, ...) and it works fine with ser, too (with some TRIGGERS in the postgres database). I'm also able to send "BYE" messages to the caller/callee to terminate the call... but I still have to make it manually. You wrote that have a process which runs periodically... how did you make that? You wrote your own C-program? It would be nice to have a good command line-timer in which you can put the sipsak command lines for every call... Thanks Sebastian ----- Original Message ----- From: "Stuart Kirkwood - Jubilee Consultancy Limited" <stuart(a)jubileeconsultancy.com> To: "'Jan Janak'" <jan(a)iptel.org> Cc: <serusers(a)lists.iptel.org> Sent: Friday, July 08, 2005 5:24 PM Subject: RE: [Serusers] Session-Timers for Prepaid credit exec_msg periodically _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers