Hi,
While trying to implement prepaid solution using SER, I decided to go be a intuitive approach which is as follows.
-When the user registers, he is placed in a "voip" groups table of ser (or radius server database), i.e he can make only pc-to-pc calls.
- Later , or otherwise, when the user registers, he is shifted to a "pstn" groups table of ser , i.e noew he can make only pc-to-pstn calls.
-Henceforth, whenever the user logins and tries to make pstn call, the call is approved only if group_radius_is_user_in(username) succeds, else the call rejected by SER.
-To restrict the user from making pstn calls when his credits are zero (or beyond a threshold) , a dedicated cron job is scripted to move users from "pstn" group to "voip" when their
account_cerdit=0.
Am I right in using this approach, or are there any foreseeable problems which I might be overlooking.
Thanks.
Regards,
Ashutosh Kumar
This is the right idea.. the bigger challenge is disconnecting the call in progress after their credit has expired.
- Daryl
On 10/27/05, Ashutosh kumar ashutoshk@chetu.com wrote:
Hi,
While trying to implement prepaid solution using SER, I decidedto go be a intuitive approach which is as follows.
-When the user registers, he is placed in a "voip" groups tableof ser (or radius server database), i.e he can make only pc-to-pc calls.
- Later , or otherwise, when the user registers, he is shiftedto a "pstn" groups table of ser , i.e noew he can make only pc-to-pstn calls.
-Henceforth, whenever the user logins and tries to make pstncall, the call is approved only if group_radius_is_user_in(username) succeds, else the call rejected by SER.
-To restrict the user from making pstn calls when his creditsare zero (or beyond a threshold) , a dedicated cron job is scripted to move users from "pstn" group to "voip" when their
account_cerdit=0.Am I right in using this approach, or are there any foreseeable problems which I might be overlooking.
Thanks.
Regards,
Ashutosh Kumar
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi, We are a bit similar in implementing prepaid service. Our users are normally can call other users in our domain, and they are initially not member of the pstn group in the ser.grp table. once they bought credits they will be put in the "pstn" group and can call pstn destinations. But when they run out of credit, we sends a bye message using sipsak on both PSTN gateway and the user's IP phone.
Regards, Ryan
Ashutosh kumar wrote:
Hi,
While trying to implement prepaid solution using SER, I decided to go be a intuitive approach which is as follows.
-When the user registers, he is placed in a “voip” groups table of ser (or radius server database), i.e he can make only pc-to-pc calls.
- Later , or otherwise, when the user registers, he is shifted to a
“pstn” groups table of ser , i.e noew he can make only pc-to-pstn calls.
-Henceforth, whenever the user logins and tries to make pstn call, the call is approved only if group_radius_is_user_in(username) succeds, else the call rejected by SER.
-To restrict the user from making pstn calls when his credits are zero (or beyond a threshold) , a dedicated cron job is scripted to move users from “pstn” group to “voip” when their
account_cerdit=0.
Am I right in using this approach, or are there any foreseeable problems which I might be overlooking.
Thanks.
Regards,
Ashutosh Kumar
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi, OK, but how do you monitor the call while it is in progress?
To disconnect the call, I am planning to use the session timers set in the header prior to intitiating the call, which will offload the task of montoring the call by SER, and disconnection-on-zero-credit will be handled by our pstn gw. Am I wrong somewhere?
Regards, Ashutosh
-----Original Message----- From: Ryan Pagquil [mailto:rpagquil@philonline.com] Sent: Friday, October 28, 2005 3:33 PM To: Ashutosh kumar Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Prepaid approach
Hi, We are a bit similar in implementing prepaid service. Our users are normally can call other users in our domain, and they are initially not member of the pstn group in the ser.grp table. once they bought credits they will be put in the "pstn" group and can call pstn destinations. But when they run out of credit, we sends a bye message using sipsak on both PSTN gateway and the user's IP phone.
Regards, Ryan
Ashutosh kumar wrote:
Hi,
While trying to implement prepaid solution using SER, I decided to go be a intuitive approach which is as follows.
-When the user registers, he is placed in a voip groups table of ser (or radius server database), i.e he can make only pc-to-pc calls.
- Later , or otherwise, when the user registers, he is shifted to a
pstn groups table of ser , i.e noew he can make only pc-to-pstn calls.
-Henceforth, whenever the user logins and tries to make pstn call, the call is approved only if group_radius_is_user_in(username) succeds, else the call rejected by SER.
-To restrict the user from making pstn calls when his credits are zero (or beyond a threshold) , a dedicated cron job is scripted to move users from pstn group to voip when their
account_cerdit=0.
Am I right in using this approach, or are there any foreseeable problems which I might be overlooking.
Thanks.
Regards,
Ashutosh Kumar
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Ashutosh,
You may want to look at the thread "Detecting runaway calls" we have been discussing these type issues there.
Basically if you control the PSTN gateway and/or there is support for session timers then you are in good shape, and this should work.
- Daryl
On 10/28/05, Ashutosh kumar ashutoshk@chetu.com wrote:
Hi, OK, but how do you monitor the call while it is in progress?
To disconnect the call, I am planning to use the session timers set in the header prior to intitiating the call, which will offload the task of montoring the call by SER, and disconnection-on-zero-credit will be handled by our pstn gw. Am I wrong somewhere?
Regards, Ashutosh
-----Original Message----- From: Ryan Pagquil [mailto:rpagquil@philonline.com] Sent: Friday, October 28, 2005 3:33 PM To: Ashutosh kumar Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Prepaid approach
Hi, We are a bit similar in implementing prepaid service. Our users are normally can call other users in our domain, and they are initially not member of the pstn group in the ser.grp table. once they bought credits they will be put in the "pstn" group and can call pstn destinations. But when they run out of credit, we sends a bye message using sipsak on both PSTN gateway and the user's IP phone.
Regards, Ryan
Ashutosh kumar wrote:
Hi,
While trying to implement prepaid solution using SER, I decided to go be a intuitive approach which is as follows.
-When the user registers, he is placed in a "voip" groups table of ser (or radius server database), i.e he can make only pc-to-pc calls.
- Later , or otherwise, when the user registers, he is shifted to a
"pstn" groups table of ser , i.e noew he can make only pc-to-pstn calls.
-Henceforth, whenever the user logins and tries to make pstn call, the call is approved only if group_radius_is_user_in(username) succeds, else the call rejected by SER.
-To restrict the user from making pstn calls when his credits are zero (or beyond a threshold) , a dedicated cron job is scripted to move users from "pstn" group to "voip" when their
account_cerdit=0.
Am I right in using this approach, or are there any foreseeable problems which I might be overlooking.
Thanks.
Regards,
Ashutosh Kumar
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Ryan Pagquil Infodyne Inc. - PhilOnline.com 3603 Antel Global Corporate Center Doña Julia Vargas Ave. Ortigas Center Pasig City Tel: 687-0715 Web: www.philonline.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi all
Is it possible to run mediaproxy on a server with two nics (in different network segments of course) and let it route traffic from one nic to the other (doing a real proxying)?
Thanks for your help Frank
Not that I am aware of. rtpproxy has support for options in force_rtp_proxy() used for implementing a bridge. g-) ----- Original Message ----- From: "Frank Fischer" frank.fischer@digitalnomads.ch To: serusers@lists.iptel.org Sent: Tuesday, November 08, 2005 10:21 AM Subject: [Serusers] mediaproxy
Hi all
Is it possible to run mediaproxy on a server with two nics (in different network segments of course) and let it route traffic from one nic to the other (doing a real proxying)?
Thanks for your help Frank
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I think it is better to use a B2BUA for prepaid.
Asterisk can do this job. But I don't know the stability.
regards, Daniel
Ashutosh kumar write:
Hi, OK, but how do you monitor the call while it is in progress?
To disconnect the call, I am planning to use the session timers set in the header prior to intitiating the call, which will offload the task of montoring the call by SER, and disconnection-on-zero-credit will be handled by our pstn gw. Am I wrong somewhere?
Regards, Ashutosh
-----Original Message----- From: Ryan Pagquil [mailto:rpagquil@philonline.com] Sent: Friday, October 28, 2005 3:33 PM To: Ashutosh kumar Cc: serusers@iptel.org Subject: Re: [Serusers] Prepaid approach
Hi, We are a bit similar in implementing prepaid service. Our users are normally can call other users in our domain, and they are initially not member of the pstn group in the ser.grp table. once they bought credits they will be put in the "pstn" group and can call pstn destinations. But when they run out of credit, we sends a bye message using sipsak on both PSTN gateway and the user's IP phone.
Regards, Ryan
Ashutosh kumar wrote:
Hi,
While trying to implement prepaid solution using SER, I decided to go be a intuitive approach which is as follows.
-When the user registers, he is placed in a 搗oip?groups table of ser (or radius server database), i.e he can make only pc-to-pc calls.
- Later , or otherwise, when the user registers, he is shifted to a
損stn?groups table of ser , i.e noew he can make only pc-to-pstn calls.
-Henceforth, whenever the user logins and tries to make pstn call, the call is approved only if group_radius_is_user_in(username) succeds, else the call rejected by SER.
-To restrict the user from making pstn calls when his credits are zero (or beyond a threshold) , a dedicated cron job is scripted to move users from 損stn?group to 搗oip?when their
account_cerdit=0.
Am I right in using this approach, or are there any foreseeable problems which I might be overlooking.
Thanks.
Regards,
Ashutosh Kumar
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Ryan Pagquil Infodyne Inc. - PhilOnline.com 3603 Antel Global Corporate Center Do馻 Julia Vargas Ave. Ortigas Center Pasig City Tel: 687-0715 Web: www.philonline.com
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
yes it works in asterisk v1.0.6 and lately 1.2beta2 with a new patch released last week...
some notes:
B2BUA scenario:
|==========>(PSTN GW´s) | Nated_UA1 ===>> SER+rtpproxy <===> Asterisk B2BUA | | UA2 <======| | Prepaid System with RADIUS
1.- Get the Perl MD5 Package from: http://www.cpan.org/modules/by-module/MD5/MD5-1.X.tar.gz
Install Perl MD5 tar -zxf MD5-1.X.tar.gz cd MD5-1.X perl Makefile.PL make
2.- Get the B2BUA patch from: http://download.berlios.de/b2bua/asterisk-b2bua-0.1.2.tgz
Unapack the B2BUA: tar -zxfv asterisk-b2bua-0.1.2.tgz
3.- Get Asteriks version 1.0.6 with: cd /usr/src export CVSROOT=:pserver:anoncvs@cvs.digium.com:/usr/cvsroot cvs login ---- the password is anoncvs. cvs co -r v1-0-6 asterisk zaptel libpri
4.- Patch Asterisk cd /asterisk cp /your_download_dir/asterisk-b2bua-0.1.2/patch/asterisk-1.0.6-b2bua.patch patch -p1 < asterisk-1.0.6-b2bua.patch
--------->
Modify app_getchannelstate.c (line 44) in this way ... look
Before ...
static int get_channel_state(struct ast_channel *chan, void *data) { struct localuser *u; LOCAL_USER_ADD(u); int res = -1;
After ...
static int get_channel_state(struct ast_channel *chan, void *data) { int res = -1; struct localuser *u; LOCAL_USER_ADD(u);
----------> esto evita un error en la compilacion de asterisk.
6.- Compile and install Asterisk cd ../zaptel make clean; make install cd ../libpri make clean; make install cd ../asterisk make clean; make install
If new to Asterisk, create default configuration files:
make samples
7.- Get the Asterisk PERL AGI module from: http://asterisk.gnuinter.net/files/asterisk-perl-0.XX.tar.gz
Install with: tar -zxfv asterisk-perl-0.XX.tar.gz cd asterisk-perl-0.XX perl Makefile.PL make all make install
8.- Replace the contents of the file /etc/asterisk/extensions.conf with something like:
[general] static=yes writeprotect=no
[default] ; Internationa LD exten => _011.,1,DeadAGI(/your_download_dir/asterisk-b2bua-0.1.2/agi/agi.pl) exten => _011.,2,Hangup() ; National LD exten => _01.,1,DeadAGI(/your_download_dir/asterisk-b2bua-0.1.2/agi/agi.pl) exten => _01.,2,Hangup() ; Add other routes here
9.- Your /etc/asterisk/sip.conf file should look like:
[general] context=default port=5060 bindaddr=0.0.0.0 http://0.0.0.0 srvlookup=yes disallow=all allow=ulaw allow=alaw allow=g729
[sip_proxy] ; For incoming calls only. type=peer host=10.10.10.1 http://10.10.10.1 ; Your SIP proxy IP address canreinvite=no
Edit the file /your_download_dir/asterisk-b2bua-0.1.2/agi/config.pl In this file you specify the RADIUS and outgoing call leg parameters.
Run Asterisk /usr/sbin/asterisk -vvvvg
10.- Below is an example of how you could route between SER and B2BUA.
#************************ # We check credentials for registers #************************ if (method=="REGISTER") { if (!www_authorize("your.domain", "subscriber")) { www_challenge("your.domain", "0"); break; }; save("location"); break; };
#************************ # First we check the source of the call #************************ # If the call comes from the gateway, no authentication is # required if (src_ip==10.10.10.2 http://10.10.10.2) { log(1,"Call from pstn. \n"); # If the call comes from B2BUA, no authentication is # required. The first leg of the call has already been # authenticated. } else if (src_ip==10.10.10.4 http://10.10.10.4) { log(1,"Call from B2BUA. \n"); } else { # We check user credentials if (method=="INVITE") { if (!proxy_authorize("your.domain", "subscriber")) { proxy_challenge("your.domain", "0"); break; };
}; # Not all the users are prepaid, so we check the database # to see if the call will be routed through B2BUA. # If every call is to be routed through B2BUA the "is_user_in" # conditional is not required. if (is_user_in("From", "prep")) { rewritehost("10.10.10.4 http://10.10.10.4"); t_relay_to_udp("10.10.10.4 http://10.10.10.4", "5060"); break; };
};
#************************ # Then we check the destination of the call #************************ # We use a specific pattern to identify our SIP users. # This can be replaced with a database lookup if a pattern # is not possible. if (uri=~"^sip:666.+@.*") { # Look user in the location database if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; } else { # Try to send call to dest. if (!t_relay()) { sl_reply_error(); }; }; # Forward numeric uri's to PSTN gateways } else if (uri=~"^sip:[0-9]+@.*") { rewritehost("10.10.10.2 http://10.10.10.2"); t_relay(); # Anything else is forbidden } else { sl_send_reply("403", "Call cannot be served here"); break; };
################################################################
On 10/28/05, Daniel Liu daniel.liu@cu88.com wrote:
I think it is better to use a B2BUA for prepaid.
Asterisk can do this job. But I don't know the stability.
regards, Daniel
Ashutosh kumar write:
Hi, OK, but how do you monitor the call while it is in progress?
To disconnect the call, I am planning to use the session timers set in
the
header prior to intitiating the call, which will offload the task of montoring the call by SER, and disconnection-on-zero-credit will be
handled
by our pstn gw. Am I wrong somewhere?
Regards, Ashutosh
-----Original Message----- From: Ryan Pagquil [mailto:rpagquil@philonline.com] Sent: Friday, October 28, 2005 3:33 PM To: Ashutosh kumar Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Prepaid approach
Hi, We are a bit similar in implementing prepaid service. Our users are normally can call other users in our domain, and they are initially not member of the pstn group in the ser.grp table. once they bought credits they will be put in the "pstn" group and can call pstn destinations. But when they run out of credit, we sends a bye message using sipsak on both PSTN gateway and the user's IP phone.
Regards, Ryan
Ashutosh kumar wrote:
Hi,
While trying to implement prepaid solution using SER, I decided to go be a intuitive approach which is as follows.
-When the user registers, he is placed in a "voip?groups table of ser (or radius server database), i.e he can make only pc-to-pc calls.
- Later , or otherwise, when the user registers, he is shifted to a
"pstn?groups table of ser , i.e noew he can make only pc-to-pstn calls.
-Henceforth, whenever the user logins and tries to make pstn call, the call is approved only if group_radius_is_user_in(username) succeds, else the call rejected by SER.
-To restrict the user from making pstn calls when his credits are zero (or beyond a threshold) , a dedicated cron job is scripted to move users from "pstn?group to "voip?when their
account_cerdit=0.
Am I right in using this approach, or are there any foreseeable problems which I might be overlooking.
Thanks.
Regards,
Ashutosh Kumar
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Ryan Pagquil Infodyne Inc. - PhilOnline.com 3603 Antel Global Corporate Center Doña Julia Vargas Ave. Ortigas Center Pasig City Tel: 687-0715 Web: www.philonline.com http://www.philonline.com
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
--
rrgv
-
Ashutosh kumar -
Daniel Liu -
Daryl Sanders -
Frank Fischer -
Greger V. Teigre -
Rafael R. GV -
Ryan Pagquil