I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thanks for the info Jan... It's good to know that it worked.
-- Daryl
On 7/8/05, Jan Janak jan@iptel.org wrote:
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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
any chance of getting a tutorial on how this works?
Daryl Sanders wrote:
Thanks for the info Jan... It's good to know that it worked.
-- Daryl
On 7/8/05, Jan Janak jan@iptel.org wrote:
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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jan Janak Sent: 08 July 2005 19:28 To: Daryl Sanders Cc: serusers@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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On 08-07-2005 21:24, Stuart Kirkwood - Jubilee Consultancy Limited 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.
We do not do it. We specialize in the core SIP infrastructure for big setups and our customers typically do not need to terminate calls (either because their users have to subscribe to the service or they have flat-rate plans).
In my opinion there is no way prepaid calling can survive in long term. Prices of PSTN calls will keep falling, more and more calls will be pure IP and the rest will be covered by flat rate monthly fees. It's happening now and it will be more and more common in the future.
Jan.
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:
In my opinion there is no way prepaid calling can survive in long term. Prices of PSTN calls will keep falling, more and more calls will be pure IP and the rest will be covered by flat rate monthly fees. It's happening now and it will be more and more common in the future.
I think the main reason prepaid exists in voip, is that there is very little control on who ur customer is, or where they are, hence collecting money from someone who has bought an account online is very hard.
Obviously if you dont sell online and sell to ur broadband customers etc, prepaid is not an issue u just bill them after the fact.
However the problem for a supplier is that upstream gateways all want prepaid,and unless this changes it is very hard for a provider to offer postpaid since cashflow just does not add up.
Also the voip business is really full of dodgy characters who run off with the money, hence postpaid again is hard...but as Jan said it is the way to go. Corporates will not prepay, they would prefer postpaid, even residential like to be billed afterwards, hence what needs to happen is that u need to limit the sales to a local community which can be controlled as opposed for going for worldwide domaination.
Ser and prepaid, I think its hard to have a tigh 100% solution for prepaid, just because SER is not designed as a B2BUA, which asterisk has included, but if u look at the additional cost incurred to scale upto 10000 users, in terms of bandwidth and hardware, and apportion some of that cost to lost billing minutes, u'll find ser a much better option. After all most of the features asterisk has are not going to be used by the majority of your customers, unless of course u target the corporate PBX market.
For prepay and SER what u need is to know the time, and then send disconnect.The time u can do a basic systems from acc, unmatched INVITES, session-timers etc etc, the disconnect use sipsak..however the latter I just cannot get to work well. I think ser could use a tighter module which would disconnect.
Iqbal
On 7/8/2005, "Bruno Lopes F. Cabral" bruno@openline.com.br wrote:
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:
In my opinion there is no way prepaid calling can survive in long term. Prices of PSTN calls will keep falling, more and more calls will be pure IP and the rest will be covered by flat rate monthly fees. It's happening now and it will be more and more common in the future.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hello there
nice feedback, Iqbal, thanks!
Iqbal wrote:
Ser and prepaid, I think its hard to have a tigh 100% solution for prepaid, just because SER is not designed as a B2BUA, which asterisk has included, but if u look at the additional cost incurred to scale upto 10000 users, in terms of bandwidth and hardware,
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?
For prepay and SER what u need is to know the time, and then send disconnect.The time u can do a basic systems from acc, unmatched INVITES, session-timers etc etc, the disconnect use sipsak..however the latter I just cannot get to work well. I think ser could use a tighter module which would disconnect.
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
Hi Bruno,
sorry but what is the conclusion of your mail? Everybody who wants to offer pre-paid VoIP services should use Asterisk instead of SER? Or something else what I missed?
Nils
On Saturday 09 July 2005 21:38, Bruno Lopes F. Cabral wrote:
Iqbal wrote:
Ser and prepaid, I think its hard to have a tigh 100% solution for prepaid, just because SER is not designed as a B2BUA, which asterisk
has included, but if u look at the additional cost incurred to scale upto 10000 users, in terms of bandwidth and hardware,
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?
For prepay and SER what u need is to know the time, and then send disconnect.The time u can do a basic systems from acc, unmatched INVITES, session-timers etc etc, the disconnect use sipsak..however the latter I just cannot get to work well. I think ser could use a tighter module which would disconnect.
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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@openline.com.br wrote:
Hello there
nice feedback, Iqbal, thanks!
Iqbal wrote:
Ser and prepaid, I think its hard to have a tigh 100% solution for prepaid, just because SER is not designed as a B2BUA, which asterisk has included, but if u look at the additional cost incurred to scale upto 10000 users, in terms of bandwidth and hardware,
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?
For prepay and SER what u need is to know the time, and then send disconnect.The time u can do a basic systems from acc, unmatched INVITES, session-timers etc etc, the disconnect use sipsak..however the latter I just cannot get to work well. I think ser could use a tighter module which would disconnect.
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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Iqbal wrote:
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.
I agree.
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.
Making a module like that will NOT make SER into a B2BUA... As I said in the previous post, it will be a hack to solve a specific problem.
g-)
See inline.
Bruno Lopes F. Cabral wrote:
Ser and prepaid, I think its hard to have a tigh 100% solution for prepaid, just because SER is not designed as a B2BUA, which asterisk has included, but if u look at the additional cost incurred to scale upto 10000 users, in terms of bandwidth and hardware,
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.
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.
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).
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.
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?
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
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?
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?
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).
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-)
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@jubileeconsultancy.com 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@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jan Janak Sent: 08 July 2005 19:28 To: Daryl Sanders Cc: serusers@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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@jubileeconsultancy.com; jan@iptel.org Cc: serusers@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@jubileeconsultancy.com 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@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jan Janak Sent: 08 July 2005 19:28 To: Daryl Sanders Cc: serusers@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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@jubileeconsultancy.com wrote:
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@jubileeconsultancy.com; jan@iptel.org Cc: serusers@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@jubileeconsultancy.com 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@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jan Janak Sent: 08 July 2005 19:28 To: Daryl Sanders Cc: serusers@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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@jubileeconsultancy.com; jan@iptel.org Cc: serusers@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@jubileeconsultancy.com wrote:
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@jubileeconsultancy.com; jan@iptel.org Cc: serusers@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@jubileeconsultancy.com 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@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jan Janak Sent: 08 July 2005 19:28 To: Daryl Sanders Cc: serusers@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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@jubileeconsultancy.com To: "'Jan Janak'" jan@iptel.org Cc: serusers@lists.iptel.org Sent: Friday, July 08, 2005 5:24 PM Subject: RE: [Serusers] Session-Timers for Prepaid
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@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jan Janak Sent: 08 July 2005 19:28 To: Daryl Sanders Cc: serusers@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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Sebastian Kühner Sent: 11 July 2005 14:45 To: serusers@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@jubileeconsultancy.com To: "'Jan Janak'" jan@iptel.org Cc: serusers@lists.iptel.org Sent: Friday, July 08, 2005 5:24 PM Subject: RE: [Serusers] Session-Timers for Prepaid
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@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jan Janak Sent: 08 July 2005 19:28 To: Daryl Sanders Cc: serusers@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:
I know there was some discussion in the recently about using session-timers as a method for doing prepaid. I'm just wondering if anyone has actually played around with this, and what your experiences were? My PSTN Gateways support session-timers, so I was thinking about trying this.
- Daryl
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
'Jan Janak' -
Bruce Ferrell -
Bruno Lopes F. Cabral -
Daryl Sanders -
Greger V. Teigre -
Iqbal -
Jan Janak
-
Nils Ohlmeier -
Sebastian Kühner -
Stuart Kirkwood - Jubilee Consultancy Limited