21 Mar
2007
21 Mar
'07
7:57 a.m.
Hello All,
Its really feels nice to have joined the list. I'm in the process of
deploying a SER based solution for prepaid users. We're using a FreeRadius
based billing solution from a provider. If I'm not mistaken, SER is not
aware of the call state, what this means to me is, in case the user account
on the radius runs out of credit, SER will not know about it and will not be
able to disconnect the call. Am I correct on this?
If I am correct, I would like to know what would be the workaround for this?
I'm I am wrong, then I would like to know on how we could get the call
disconnection working?
I have a Nextone which would be sitting in front of the SER and acting as a
Mirror Proxy for SER. The purpose of this is to overcome NAT traversal
issues and free SER from that. Nextone doesn't understand or talk radius.
SER will be the registrar and handle AAA. The user call will be sent back
into the Nextone and then terminated from there. SER will not be handling
media. If to get my disconnect upon credit exhaust scenario working, what
changes should I introduce into my existing network model?
Thank you.
Shaf.
21 Mar
21 Mar
12:37 p.m.
You are correct. There are several workarounds for this, but for the most part, what you
need is some sort of B2BUA functionality. Essentially, the call needs to go through a UAS
that DOES keep track. The new SEMS is supposed to have some of this functionality,
although I don't know much about it. Some people use Asterisk (with Asterisk B2BUA).
We ended up writing our own Asterisk B2BUA as the Asterisk B2BUA code from sourceforge had
things in it we neither wanted nor used and their patches never seem to be up to date on
the later versions of Asterisk (current code out there works in a guaranteed way only for
Asterisk 1.2.1, though it wasn't until after 1.2.9.1 that we had to seriously rewrite
the patch). The sourceforge code works, though, for earlier versions of Asterisk, and is
an excellent starting place if you've little desire to write the whole thing
yourself.
The concept of using Asterisk is pretty simple: call gets forwarded from SER to an
Asterisk AGI program (C, Perl, etc) that does all the magic. The easiest way is to do a
balance check when the call comes in to determine the cost of the outgoing call and check
how much time a person has left on the call based on how much money is in their account.
Then, just set up an Asterisk Dial command with the appropriate timeout and let the server
take care of the rest. There are tricks to this, of course. Unless you're somehow
updating call credit and call timeout on the fly, you'll need to limit the incoming
calls to one at a time for each account, or it's easy for someone to call with
multiple phones and rob you of cash.
N.
On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote
Hello All,
Its really feels nice to have joined the list. I'm in theprocess of deploying a SER
based solution for prepaid users. We're using aFreeRadius based billing solution from
a provider. If I'm not mistaken, SER isnot aware of the call state, what this means to
me is, in case the user accounton the radius runs out of credit, SER will not know about
it and will not beable to disconnect the call. Am I correct on this?
If I am correct, I would like to know what would be theworkaround for this? I'm I am
wrong, then I would like to know on how we couldget the call disconnection working?
I have a Nextone which would be sitting in front of theSER and acting as a Mirror Proxy
for SER. The purpose of this is to overcomeNAT traversal issues and free SER from that.
Nextone doesnt understandor talk radius. SER will be the registrar and handle AAA. The
user call will besent back into the Nextone and then terminated from there. SER will not
behandling media. If to get my disconnect upon credit exhaust scenario working,what
changes should I introduce into my existing network model?
Thank you.
Shaf.
22 Mar
22 Mar
8:30 a.m.
Thank you for the information.
As a B2BUA, can I use Vovida? Anybody has successfully deployed Vovida with
SER for a Prepaid scenario? Or Vovida is a bad idea?
I am having second thoughts about Asterisk B2BUA, as the resource
consumption is gonna be much higher and I'm not gonna make use of all the
features. All I want is just make SIP to PSTN calls and Bill them properly.
Also, when it comes to scalability, Asterisk is not the best isn't it?
Any other alternative solution compared to the above 2 solutions? Can I do
something using SEMS? Or is there any recommended commercial, not so
expensive B2BUA products out there? Any advise would be much appreciated ;)
From: sip [mailto:sip@arcdiv.com]
Sent: Wednesday, March 21, 2007 5:08 PM
To: Shafraz Thawfeek; serusers(a)lists.iptel.org
Cc: serusers(a)iptel.org
Subject: Re: [Serusers] SER + Prepaid with Radius AAA.
You are correct. There are several workarounds for this, but for the most
part, what you need is some sort of B2BUA functionality. Essentially, the
call needs to go through a UAS that DOES keep track. The new SEMS is
supposed to have some of this functionality, although I don't know much
about it. Some people use Asterisk (with Asterisk B2BUA). We ended up
writing our own Asterisk B2BUA as the Asterisk B2BUA code from sourceforge
had things in it we neither wanted nor used and their patches never seem to
be up to date on the later versions of Asterisk (current code out there
works in a guaranteed way only for Asterisk 1.2.1, though it wasn't until
after 1.2.9.1 that we had to seriously rewrite the patch). The sourceforge
code works, though, for earlier versions of Asterisk, and is an excellent
starting place if you've little desire to write the whole thing yourself.
The concept of using Asterisk is pretty simple: call gets forwarded from
SER to an Asterisk AGI program (C, Perl, etc) that does all the magic. The
easiest way is to do a balance check when the call comes in to determine the
cost of the outgoing call and check how much time a person has left on the
call based on how much money is in their account. Then, just set up an
Asterisk Dial command with the appropriate timeout and let the server take
care of the rest. There are tricks to this, of course. Unless you're
somehow updating call credit and call timeout on the fly, you'll need to
limit the incoming calls to one at a time for each account, or it's easy for
someone to call with multiple phones and rob you of cash.
N.
On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote
Hello All,
Its really feels nice to have joined the list. I'm in the process of
deploying
a SER based solution for prepaid users. We're using a FreeRadius
based billing solution from a provider. If I'm not mistaken, SER is not
aware of the call state, what this means to me is, in case the user account
on the radius runs out of credit, SER will not know about it and will not be
able to disconnect the call. Am I correct on this?
If I am correct, I would like to know what would be the workaround for
this?
I'm I am wrong, then I would like to know on how we could get the call
disconnection working?
I have a Nextone which would be sitting in front of the SER and acting as
a Mirror
Proxy for SER. The purpose of this is to overcome NAT traversal
issues and free SER from that. Nextone doesn't understand or talk radius.
SER will be the registrar and handle AAA. The user call will be sent back
into the Nextone and then terminated from there. SER will not be handling
media. If to get my disconnect upon credit exhaust scenario working, what
changes should I introduce into my existing network model?
Thank you.
Shaf.
12:57 p.m.
The problem with Vovida's B2BUA is that it has been a dead project for over two years
now. It's no longer maintained, and doesn't mesh well with the current state of
SIP.
As for Asterisk B2BUA, it's a perl-based AGI script. It's not the world's
fastest because of that, but it's not slow by any stretch, and because it's a
relatively simple language, you could probably modify it (or find a cheap perl coder who
could modify it) to suit your needs rather easily. While Asterisk is not known for its
huge numbers of concurrent calls, we use it with a canreinvite=yes and ensure that the RTP
traffic never really buffers through the server (which is where the only slowdown actually
occurs). You could, if you needed an RTP proxy, conceivably somehow fit RTPproxy into the
mix and get more concurrent calls than Asterisk would handle.
As for Asterisk B2BUA, it's two things. A patch to the Asterisk code (the patch
consists of two additions to the code -- one which allows you to set a variable to only
send ONE codec choice through Asterisk (and that portion of the patch doesn't actually
work correctly, so it can be scrapped), and one which adds a variable that stores the SIP
error code for use in the LCR portion of the Asterisk B2BUA code -- something you could
also conceivably do away with if you weren't doing LCR), and the AGI script. If you
want to speed things up, you could rewrite either or both or just use them as a template
for your own ideas.
The new SEMS code is... well... new. This isn't to say it's bad. Even the old SEMS
code worked well in production for its intended purposes, but as of yet, I don't know
anyone who uses the new SEMS code in a large-scale production environment.
You might be able to jury-rig some sort of solution out of a modified Media Proxy, but
I've no idea.
There's another solution I know nothing at ALL about which uses Asterisk called
AstBill that handles prepaid.
There are commercial solutions available. Alepo is one of them, but it's very
expensive. It does EVERYthing, but it's very expensive. VPS-43 by the OpenSER people
can supposedly do prepaid. Again, I know little about it other than its name.
There are probably at least a half dozen others available if you look about.
Good luck. :)
The trickiest part is actually finding a PSTN terminations provider that understands the
concept of customer service. I actually had one the other day tell us, when we informed
them they were in breach of contract, that if we were having so many problems, to please
find another carrier... so I wish you all the best with your endeavor.
N.
On Thu, 22 Mar 2007 13:00:18 +0530, Shafraz Thawfeek wrote
Thank you for the information.
As a B2BUA, can I use Vovida? Anybody has successfully deployedVovida with SER for a
Prepaid scenario? Or Vovida is a bad idea?
I am having second thoughts about Asterisk B2BUA, as theresource consumption is gonna be
much higher and Im not gonna make useof all the features. All I want is just make SIP to
PSTN calls and Bill themproperly. Also, when it comes to scalability, Asterisk is not the
best isntit?
Any other alternative solution compared to the above 2solutions? Can I do something using
SEMS? Or is there any recommendedcommercial, not so expensive B2BUA products out there?
Any advise would be muchappreciated ;)
From: sip[mailto:sip@arcdiv.com]
Sent: Wednesday, March 21, 2007 5:08 PM
To: Shafraz Thawfeek; serusers(a)lists.iptel.org
Cc: serusers(a)iptel.org
Subject: Re: [Serusers] SER + Prepaid with Radius AAA.
Youare correct. There are several workarounds for this, but for the most part,what you
need is some sort of B2BUA functionality. Essentially, the callneeds to go through a UAS
that DOES keep track. The new SEMS is supposedto have some of this functionality,
although I don't know much about it. Some people use Asterisk (with Asterisk B2BUA).
We ended up writing ourown Asterisk B2BUA as the Asterisk B2BUA code from sourceforge had
things in itwe neither wanted nor used and their patches never seem to be up to date on
thelater versions of Asterisk (current code out there works in a guaranteed wayonly for
Asterisk 1.2.1, though it wasn't until after 1.2.9.1 that we had toseriously rewrite
the patch). The sourceforge code works, though, for earlierversions of Asterisk, and is an
excellent starting place if you've littledesire to write the whole thing yourself.
The concept of using Asterisk is pretty simple: call gets forwarded fromSER to an
Asterisk AGI program (C, Perl, etc) that does all the magic. The easiest way is to do a
balance check when the call comes in to determinethe cost of the outgoing call and check
how much time a person has left on thecall based on how much money is in their account.
Then, just set up an AsteriskDial command with the appropriate timeout and let the server
take care of therest. There are tricks to this, of course. Unless you're somehow
updatingcall credit and call timeout on the fly, you'll need to limit the
incomingcalls to one at a time for each account, or it's easy for someone to call
withmultiple phones and rob you of cash.
N.
On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote
Hello All,
Its really feels nice to have joined the list. I'm in the process ofdeploying a SER
based solution for prepaid users. We're using a FreeRadiusbased billing solution from
a provider. If I'm not mistaken, SER is not awareof the call state, what this means to
me is, in case the user account on theradius runs out of credit, SER will not know about
it and will not be able todisconnect the call. Am I correct on this?
If I am correct, I would like to know what would be the workaround forthis? I'm I am
wrong, then I would like to know on how we could get the calldisconnection working?
I have a Nextone which would be sitting in front of the SER and acting asa Mirror Proxy
for SER. The purpose of this is to overcome NAT traversal issuesand free SER from that.
Nextone doesnt understand or talk radius. SERwill be the registrar and handle AAA. The
user call will be sent back into theNextone and then terminated from there. SER will not
be handling media. If toget my disconnect upon credit exhaust scenario working, what
changes should Iintroduce into my existing network model?
Thank you.
Shaf.
4:33 p.m.
New subject: Re[2]: [Serusers] SER + Prepaid with Radius AAA.
Hello,
There is an updated version of *B2BUA code for Asterisk 1.4 that
currently in testing stage.
Who like to test can contact me in *B2BUA mailing list, any feedback
is welcome.
Thursday, March 22, 2007 1:57:31 PM, you wrote:
s>
s> The problem with Vovida's B2BUA is that it has been a dead
s> project for over two years now. It's no longer maintained, and
s> doesn't mesh well with the current state of SIP.
s>
s> As for Asterisk B2BUA, it's a perl-based AGI script. It's not the
s> world's fastest because of that, but it's not slow by any stretch,
s> and because it's a relatively simple language, you could probably
s> modify it (or find a cheap perl coder who could modify it) to suit
s> your needs rather easily. While Asterisk is not known for its huge
s> numbers of concurrent calls, we use it with a canreinvite=yes and
s> ensure that the RTP traffic never really buffers through the server
s> (which is where the only slowdown actually occurs). You could, if
s> you needed an RTP proxy, conceivably somehow fit RTPproxy into the
s> mix and get more concurrent calls than Asterisk would handle.
s>
s> As for Asterisk B2BUA, it's two things. A patch to the Asterisk
s> code (the patch consists of two additions to the code -- one which
s> allows you to set a variable to only send ONE codec choice through
s> Asterisk (and that portion of the patch doesn't actually work
s> correctly, so it can be scrapped), and one which adds a variable
s> that stores the SIP error code for use in the LCR portion of the
s> Asterisk B2BUA code -- something you could also conceivably do away
s> with if you weren't doing LCR), and the AGI script. If you want to
s> speed things up, you could rewrite either or both or just use them
s> as a template for your own ideas.
s>
s> The new SEMS code is... well... new. This isn't to say it's bad.
s> Even the old SEMS code worked well in production for its intended
s> purposes, but as of yet, I don't know anyone who uses the new SEMS
s> code in a large-scale production environment.
s>
s> You might be able to jury-rig some sort of solution out of a
s> modified Media Proxy, but I've no idea.
s>
s> There's another solution I know nothing at ALL about which uses
s> Asterisk called AstBill that handles prepaid.
s>
s> There are commercial solutions available. Alepo is one of them,
s> but it's very expensive. It does EVERYthing, but it's very
s> expensive. VPS-43 by the OpenSER people can supposedly do prepaid.
s> Again, I know little about it other than its name.
s>
s> There are probably at least a half dozen others available if you look about.
s>
s> Good luck. :)
s>
s> The trickiest part is actually finding a PSTN terminations
s> provider that understands the concept of customer service. I
s> actually had one the other day tell us, when we informed them they
s> were in breach of contract, that if we were having so many
s> problems, to please find another carrier... so I wish you all the best with your
endeavor.
s>
s>
s> N.
s>
s> On Thu, 22 Mar 2007 13:00:18 +0530, Shafraz Thawfeek wrote
> Thank you for the information.
> As a B2BUA, can I use Vovida? Anybody has successfully deployed Vovida with SER for
a Prepaid scenario? Or Vovida is a bad idea?
> I am having second thoughts about Asterisk B2BUA, as the resource consumption is
gonna be much higher and I?m not gonna make use of all the features. All I want is just
make SIP to PSTN calls and Bill them properly. Also, when it comes to scalability,
Asterisk is not the best isn?t it?
> Any other alternative solution compared to the above 2 solutions? Can I do something
using SEMS? Or is there any recommended commercial, not so expensive B2BUA products out
there? Any advise would be much appreciated ;)
>
>
> From: sip [mailto:sip@arcdiv.com]
> Sent: Wednesday, March 21, 2007 5:08 PM
> To: Shafraz Thawfeek; serusers(a)lists.iptel.org
> Cc: serusers(a)iptel.org
> Subject: Re: [Serusers] SER + Prepaid with Radius AAA.
>
> You are correct. There are several workarounds for this, but for the most part, what
you need is some sort of B2BUA functionality. Essentially, the call needs to go through
a UAS that DOES keep track. The new SEMS is supposed to have some of this functionality,
although I don't know much about it. Some people use Asterisk (with Asterisk
B2BUA). We ended up writing our own Asterisk B2BUA as the Asterisk B2BUA code from
sourceforge had things in it we neither wanted nor used and their patches never seem to
be up to date on the later versions of Asterisk (current code out there works in a
guaranteed way only for Asterisk 1.2.1, though it wasn't until after 1.2.9.1 that we
had to seriously rewrite the patch). The sourceforge code works, though, for earlier
versions of Asterisk, and is an excellent starting place if you've little desire to
write the whole thing yourself.
>
> The concept of using Asterisk is pretty simple: call gets forwarded from SER to
an Asterisk AGI program (C, Perl, etc) that does all the magic. The easiest way is to do
a balance check when the call comes in to determine the cost of the outgoing call and
check how much time a person has left on the call based on how much money is in their
account. Then, just set up an Asterisk Dial command with the appropriate timeout and let
the server take care of the rest. There are tricks to this, of course. Unless you're
somehow updating call credit and call timeout on the fly, you'll need to limit the
incoming calls to one at a time for each account, or it's easy for someone to call
with multiple phones and rob you of cash.
>
> N.
>
>
> On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote
> > Hello All,
> >
> > Its really feels nice to have joined the list. I'm in the process of
deploying a SER based solution for prepaid users. We're using a FreeRadius based
billing solution from a provider. If I'm not mistaken, SER is not aware of the call
state, what this means to me is, in case the user account on the radius runs out of
credit, SER will not know about it and will not be able to disconnect the call. Am I
correct on this?
> >
> > If I am correct, I would like to know what would be the workaround for this?
I'm I am wrong, then I would like to know on how we could get the call disconnection
working?
> >
> > I have a Nextone which would be sitting in front of the SER and acting as a
Mirror Proxy for SER. The purpose of this is to overcome NAT traversal issues and free
SER from that. Nextone doesn?t understand or talk radius. SER will be the registrar and
handle AAA. The user call will be sent back into the Nextone and then terminated from
there. SER will not be handling media. If to get my disconnect upon credit exhaust
scenario working, what changes should I introduce into my existing network model?
> >
> > Thank you.
> > Shaf.
> >
> >
>
>
s>
s>
s>
s>
--
Mike Tkachuk
27 Mar
27 Mar
9:55 a.m.
Hello All,
Thank you for the replies again. I would like to know, in case I decide to
go with Asterisk B2BUA, how would the performance, stability be? and most
importantly, how would the scalability be? I'm not planning to route media
via the *box, in that case, how many simultaneous calls would I be able to
get considering my hardware is of high spec.
Also, I would like to know, has anyone tried using Yate for such a scenario?
Perhaps as a B2BUA, or Standonle with or without SER to do prepaid?
Regards
Shaf.
From: sip [mailto:sip@arcdiv.com]
Sent: Wednesday, March 21, 2007 5:08 PM
To: Shafraz Thawfeek; serusers(a)lists.iptel.org
Cc: serusers(a)iptel.org
Subject: Re: [Serusers] SER + Prepaid with Radius AAA.
You are correct. There are several workarounds for this, but for the most
part, what you need is some sort of B2BUA functionality. Essentially, the
call needs to go through a UAS that DOES keep track. The new SEMS is
supposed to have some of this functionality, although I don't know much
about it. Some people use Asterisk (with Asterisk B2BUA). We ended up
writing our own Asterisk B2BUA as the Asterisk B2BUA code from sourceforge
had things in it we neither wanted nor used and their patches never seem to
be up to date on the later versions of Asterisk (current code out there
works in a guaranteed way only for Asterisk 1.2.1, though it wasn't until
after 1.2.9.1 that we had to seriously rewrite the patch). The sourceforge
code works, though, for earlier versions of Asterisk, and is an excellent
starting place if you've little desire to write the whole thing yourself.
The concept of using Asterisk is pretty simple: call gets forwarded from
SER to an Asterisk AGI program (C, Perl, etc) that does all the magic. The
easiest way is to do a balance check when the call comes in to determine the
cost of the outgoing call and check how much time a person has left on the
call based on how much money is in their account. Then, just set up an
Asterisk Dial command with the appropriate timeout and let the server take
care of the rest. There are tricks to this, of course. Unless you're
somehow updating call credit and call timeout on the fly, you'll need to
limit the incoming calls to one at a time for each account, or it's easy for
someone to call with multiple phones and rob you of cash.
N.
On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote
Hello All,
Its really feels nice to have joined the list. I'm in the process of
deploying
a SER based solution for prepaid users. We're using a FreeRadius
based billing solution from a provider. If I'm not mistaken, SER is not
aware of the call state, what this means to me is, in case the user account
on the radius runs out of credit, SER will not know about it and will not be
able to disconnect the call. Am I correct on this?
If I am correct, I would like to know what would be the workaround for
this?
I'm I am wrong, then I would like to know on how we could get the call
disconnection working?
I have a Nextone which would be sitting in front of the SER and acting as
a Mirror
Proxy for SER. The purpose of this is to overcome NAT traversal
issues and free SER from that. Nextone doesn't understand or talk radius.
SER will be the registrar and handle AAA. The user call will be sent back
into the Nextone and then terminated from there. SER will not be handling
media. If to get my disconnect upon credit exhaust scenario working, what
changes should I introduce into my existing network model?
Thank you.
Shaf.
10:27 a.m.
New subject: Re[2]: [Serusers] SER + Prepaid with Radius AAA.
Hello Shafraz,
I'm able to reach ~ 200 concurrent calls with RTP proxied on such hardware:
Dell 860, Xeon 3060, 2G RAM
Freebsd 6.2, Asterisk 1.4
If you will use SER dispatcher module you can add virtually unlimited
amount of *B2BUA machines.
Tuesday, March 27, 2007 10:55:46 AM, you wrote:
ST>
ST>
ST>
ST>
ST> Hello All,
ST>
ST>
ST>
ST> Thank you for the replies again. I would like to know, in case I
ST> decide to go with Asterisk B2BUA, how would the performance,
ST> stability be? and most importantly, how would the scalability be?
ST> I’m not planning to route media via the *box, in that case, how
ST> many simultaneous calls would I be able to get considering my hardware is of high
spec.
ST>
ST>
ST>
ST> Also, I would like to know, has anyone tried using Yate for such
ST> a scenario? Perhaps as a B2BUA, or Standonle with or without SER to do prepaid?
ST>
ST>
ST>
ST> Regards
ST>
ST>
ST> Shaf.
ST>
ST>
ST>
ST>
ST>
ST> From: sip [mailto:sip@arcdiv.com]
ST> Sent: Wednesday, March 21, 2007 5:08 PM
ST> To: Shafraz Thawfeek; serusers(a)lists.iptel.org
ST> Cc: serusers(a)iptel.org
ST> Subject: Re: [Serusers] SER + Prepaid with Radius AAA.
ST>
ST>
ST>
ST>
ST>
ST> You are correct. There are several workarounds for this, but for
ST> the most part, what you need is some sort of B2BUA functionality.
ST> Essentially, the call needs to go through a UAS that DOES keep
ST> track. The new SEMS is supposed to have some of this
ST> functionality, although I don't know much about it. Some people
ST> use Asterisk (with Asterisk B2BUA). We ended up writing our own
ST> Asterisk B2BUA as the Asterisk B2BUA code from sourceforge had
ST> things in it we neither wanted nor used and their patches never
ST> seem to be up to date on the later versions of Asterisk (current
ST> code out there works in a guaranteed way only for Asterisk 1.2.1,
ST> though it wasn't until after 1.2.9.1 that we had to seriously
ST> rewrite the patch). The sourceforge code works, though, for
ST> earlier versions of Asterisk, and is an excellent starting place
ST> if you've little desire to write the whole thing yourself.
ST>
ST> The concept of using Asterisk is pretty simple: call gets
ST> forwarded from SER to an Asterisk AGI program (C, Perl, etc) that
ST> does all the magic. The easiest way is to do a balance check when
ST> the call comes in to determine the cost of the outgoing call and
ST> check how much time a person has left on the call based on how
ST> much money is in their account. Then, just set up an Asterisk Dial
ST> command with the appropriate timeout and let the server take care
ST> of the rest. There are tricks to this, of course. Unless you're
ST> somehow updating call credit and call timeout on the fly, you'll
ST> need to limit the incoming calls to one at a time for each
ST> account, or it's easy for someone to call with multiple phones and rob you of
cash.
ST>
ST> N.
ST>
ST>
ST> On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote
> Hello All,
>
> Its really feels nice to have joined the list. I'm in the process of deploying a
SER based solution for prepaid users. We're using a FreeRadius based billing solution
from a provider. If I'm not mistaken, SER is not aware of the call state, what this
means to me is, in case the user account on the radius runs out of credit, SER will not
know about it and will not be able to disconnect the call. Am I correct on this?
>
> If I am correct, I would like to know what would be the workaround for this? I'm
I am wrong, then I would like to know on how we could get the call disconnection working?
>
> I have a Nextone which would be sitting in front of the SER and acting as a Mirror
Proxy for SER. The purpose of this is to overcome NAT traversal issues and free SER from
that. Nextone doesn’t understand or talk radius. SER will be the registrar and handle AAA.
The user call will be sent back into the Nextone and then terminated from there. SER will
not be handling media. If to get my disconnect upon credit exhaust scenario working, what
changes should I introduce into my existing network model?
>
> Thank you.
> Shaf.
>
>
ST>
ST>
ST>
ST>
ST>
--
Mike Tkachuk
10:36 a.m.
New subject: Re[2]: [Serusers] SER + Prepaid with Radius AAA.
Hello Mike,
This is SER running on Separate server and Asterisk running on Separate
server, right?
If you're able to reach ~200 with RTP, should I be able to comfortably state
that I might be able to Achieve about ~1000 concurrent calls on a Single
*Server without RTP?
This is interesting. Asterisk doesn't look a bad option at all.
Can you please tell me, what advantages/disadvantages I might have by
proxying RTP / Not proxying RTP.
I will be having a Nextone MSX sitting in front of SER, and all users will
be registering to the SER via the Nextone. So I'm planning to let Nextone
handle all the RTP work.
Warm Regards,
Shafraz Thawfeek
-----Original Message-----
From: Mike Tkachuk [mailto:mike@yes.net.ua]
Sent: Tuesday, March 27, 2007 1:57 PM
To: Shafraz Thawfeek
Cc: serusers(a)lists.iptel.org
Subject: Re[2]: [Serusers] SER + Prepaid with Radius AAA.
Hello Shafraz,
I'm able to reach ~ 200 concurrent calls with RTP proxied on such hardware:
Dell 860, Xeon 3060, 2G RAM
Freebsd 6.2, Asterisk 1.4
If you will use SER dispatcher module you can add virtually unlimited
amount of *B2BUA machines.
Tuesday, March 27, 2007 10:55:46 AM, you wrote:
ST>
ST>
ST>
ST>
ST> Hello All,
ST>
ST>
ST>
ST> Thank you for the replies again. I would like to know, in case I
ST> decide to go with Asterisk B2BUA, how would the performance,
ST> stability be? and most importantly, how would the scalability be?
ST> Im not planning to route media via the *box, in that case, how
ST> many simultaneous calls would I be able to get considering my hardware
is of high spec.
ST>
ST>
ST>
ST> Also, I would like to know, has anyone tried using Yate for such
ST> a scenario? Perhaps as a B2BUA, or Standonle with or without SER to do
prepaid?
ST>
ST>
ST>
ST> Regards
ST>
ST>
ST> Shaf.
ST>
ST>
ST>
ST>
ST>
ST> From: sip [mailto:sip@arcdiv.com]
ST> Sent: Wednesday, March 21, 2007 5:08 PM
ST> To: Shafraz Thawfeek; serusers(a)lists.iptel.org
ST> Cc: serusers(a)iptel.org
ST> Subject: Re: [Serusers] SER + Prepaid with Radius AAA.
ST>
ST>
ST>
ST>
ST>
ST> You are correct. There are several workarounds for this, but for
ST> the most part, what you need is some sort of B2BUA functionality.
ST> Essentially, the call needs to go through a UAS that DOES keep
ST> track. The new SEMS is supposed to have some of this
ST> functionality, although I don't know much about it. Some people
ST> use Asterisk (with Asterisk B2BUA). We ended up writing our own
ST> Asterisk B2BUA as the Asterisk B2BUA code from sourceforge had
ST> things in it we neither wanted nor used and their patches never
ST> seem to be up to date on the later versions of Asterisk (current
ST> code out there works in a guaranteed way only for Asterisk 1.2.1,
ST> though it wasn't until after 1.2.9.1 that we had to seriously
ST> rewrite the patch). The sourceforge code works, though, for
ST> earlier versions of Asterisk, and is an excellent starting place
ST> if you've little desire to write the whole thing yourself.
ST>
ST> The concept of using Asterisk is pretty simple: call gets
ST> forwarded from SER to an Asterisk AGI program (C, Perl, etc) that
ST> does all the magic. The easiest way is to do a balance check when
ST> the call comes in to determine the cost of the outgoing call and
ST> check how much time a person has left on the call based on how
ST> much money is in their account. Then, just set up an Asterisk Dial
ST> command with the appropriate timeout and let the server take care
ST> of the rest. There are tricks to this, of course. Unless you're
ST> somehow updating call credit and call timeout on the fly, you'll
ST> need to limit the incoming calls to one at a time for each
ST> account, or it's easy for someone to call with multiple phones and rob
you of cash.
ST>
ST> N.
ST>
ST>
ST> On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote
> Hello All,
>
> Its really feels nice to have joined the list. I'm in the process of
deploying a SER based solution for prepaid users. We're using a FreeRadius
based billing solution from a provider. If I'm not mistaken, SER is not
aware of the call state, what this means to me is, in case the user account
on the radius runs out of credit, SER will not know about it and will not be
able to disconnect the call. Am I correct on this?
>
> If I am correct, I would like to know what would be the workaround for
this?
I'm I am wrong, then I would like to know on how we could get the call
disconnection working?
>
> I have a Nextone which would be sitting in front of the SER and acting
as a
Mirror Proxy for SER. The purpose of this is to overcome NAT traversal
issues and free SER from that. Nextone doesnt understand or talk radius.
SER will be the registrar and handle AAA. The user call will be sent back
into the Nextone and then terminated from there. SER will not be handling
media. If to get my disconnect upon credit exhaust scenario working, what
changes should I introduce into my existing network model?
>
> Thank you.
> Shaf.
>
>
ST>
ST>
ST>
ST>
ST>
--
Mike Tkachuk
28 Mar
28 Mar
4:47 p.m.
New subject: Re[2]: [Serusers] SER + Prepaid with Radius AAA.
Using Asterisk B2BUA, WITHOUT RTP Proxying, How many concurrent calls will I
be able to squeeze through without compromising on Stability? Advise much
appreciated.
Warm Regards,
Shafraz Thawfeek
-----Original Message-----
From: Mike Tkachuk [mailto:mike@yes.net.ua]
Sent: Tuesday, March 27, 2007 1:57 PM
To: Shafraz Thawfeek
Cc: serusers(a)lists.iptel.org
Subject: Re[2]: [Serusers] SER + Prepaid with Radius AAA.
Hello Shafraz,
I'm able to reach ~ 200 concurrent calls with RTP proxied on such hardware:
Dell 860, Xeon 3060, 2G RAM
Freebsd 6.2, Asterisk 1.4
If you will use SER dispatcher module you can add virtually unlimited
amount of *B2BUA machines.
Tuesday, March 27, 2007 10:55:46 AM, you wrote:
ST>
ST>
ST>
ST>
ST> Hello All,
ST>
ST>
ST>
ST> Thank you for the replies again. I would like to know, in case I
ST> decide to go with Asterisk B2BUA, how would the performance,
ST> stability be? and most importantly, how would the scalability be?
ST> Im not planning to route media via the *box, in that case, how
ST> many simultaneous calls would I be able to get considering my hardware
is of high spec.
ST>
ST>
ST>
ST> Also, I would like to know, has anyone tried using Yate for such
ST> a scenario? Perhaps as a B2BUA, or Standonle with or without SER to do
prepaid?
ST>
ST>
ST>
ST> Regards
ST>
ST>
ST> Shaf.
ST>
ST>
ST>
ST>
ST>
ST> From: sip [mailto:sip@arcdiv.com]
ST> Sent: Wednesday, March 21, 2007 5:08 PM
ST> To: Shafraz Thawfeek; serusers(a)lists.iptel.org
ST> Cc: serusers(a)iptel.org
ST> Subject: Re: [Serusers] SER + Prepaid with Radius AAA.
ST>
ST>
ST>
ST>
ST>
ST> You are correct. There are several workarounds for this, but for
ST> the most part, what you need is some sort of B2BUA functionality.
ST> Essentially, the call needs to go through a UAS that DOES keep
ST> track. The new SEMS is supposed to have some of this
ST> functionality, although I don't know much about it. Some people
ST> use Asterisk (with Asterisk B2BUA). We ended up writing our own
ST> Asterisk B2BUA as the Asterisk B2BUA code from sourceforge had
ST> things in it we neither wanted nor used and their patches never
ST> seem to be up to date on the later versions of Asterisk (current
ST> code out there works in a guaranteed way only for Asterisk 1.2.1,
ST> though it wasn't until after 1.2.9.1 that we had to seriously
ST> rewrite the patch). The sourceforge code works, though, for
ST> earlier versions of Asterisk, and is an excellent starting place
ST> if you've little desire to write the whole thing yourself.
ST>
ST> The concept of using Asterisk is pretty simple: call gets
ST> forwarded from SER to an Asterisk AGI program (C, Perl, etc) that
ST> does all the magic. The easiest way is to do a balance check when
ST> the call comes in to determine the cost of the outgoing call and
ST> check how much time a person has left on the call based on how
ST> much money is in their account. Then, just set up an Asterisk Dial
ST> command with the appropriate timeout and let the server take care
ST> of the rest. There are tricks to this, of course. Unless you're
ST> somehow updating call credit and call timeout on the fly, you'll
ST> need to limit the incoming calls to one at a time for each
ST> account, or it's easy for someone to call with multiple phones and rob
you of cash.
ST>
ST> N.
ST>
ST>
ST> On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote
> Hello All,
>
> Its really feels nice to have joined the list. I'm in the process of
deploying a SER based solution for prepaid users. We're using a FreeRadius
based billing solution from a provider. If I'm not mistaken, SER is not
aware of the call state, what this means to me is, in case the user account
on the radius runs out of credit, SER will not know about it and will not be
able to disconnect the call. Am I correct on this?
>
> If I am correct, I would like to know what would be the workaround for
this?
I'm I am wrong, then I would like to know on how we could get the call
disconnection working?
>
> I have a Nextone which would be sitting in front of the SER and acting
as a
Mirror Proxy for SER. The purpose of this is to overcome NAT traversal
issues and free SER from that. Nextone doesnt understand or talk radius.
SER will be the registrar and handle AAA. The user call will be sent back
into the Nextone and then terminated from there. SER will not be handling
media. If to get my disconnect upon credit exhaust scenario working, what
changes should I introduce into my existing network model?
>
> Thank you.
> Shaf.
>
>
ST>
ST>
ST>
ST>
ST>
--
Mike Tkachuk
29 Mar
29 Mar
12:28 p.m.
New subject: Re[4]: [Serusers] SER + Prepaid with Radius AAA.
Hello Shafraz,
I think you can get more than 200 concurent calls, but I doubt about
asterisk stability itself.
*B2BUA code is too dumb to have some problems.
Wednesday, March 28, 2007 5:47:54 PM, you wrote:
ST> Using Asterisk B2BUA, WITHOUT RTP Proxying, How many concurrent calls will I
ST> be able to squeeze through without compromising on Stability? Advise much
ST> appreciated.
ST> Warm Regards,
ST> Shafraz Thawfeek
ST> -----Original Message-----
ST> From: Mike Tkachuk [mailto:mike@yes.net.ua]
ST> Sent: Tuesday, March 27, 2007 1:57 PM
ST> To: Shafraz Thawfeek
ST> Cc: serusers(a)lists.iptel.org
ST> Subject: Re[2]: [Serusers] SER + Prepaid with Radius AAA.
ST> Hello Shafraz,
ST> I'm able to reach ~ 200 concurrent calls with RTP proxied on such hardware:
ST> Dell 860, Xeon 3060, 2G RAM
ST> Freebsd 6.2, Asterisk 1.4
ST> If you will use SER dispatcher module you can add virtually unlimited
ST> amount of *B2BUA machines.
ST> Tuesday, March 27, 2007 10:55:46 AM, you wrote:
ST>>
ST>>
ST>>
ST>>
ST>> Hello All,
ST>>
ST>>
ST>>
ST>> Thank you for the replies again. I would like to know, in case I
ST>> decide to go with Asterisk B2BUA, how would the performance,
ST>> stability be? and most importantly, how would the scalability be?
ST>> I?m not planning to route media via the *box, in that case, how
ST>> many simultaneous calls would I be able to get considering my hardware
ST> is of high spec.
ST>>
ST>>
ST>>
ST>> Also, I would like to know, has anyone tried using Yate for such
ST>> a scenario? Perhaps as a B2BUA, or Standonle with or without SER to do
ST> prepaid?
ST>>
ST>>
ST>>
ST>> Regards
ST>>
ST>>
ST>> Shaf.
ST>>
ST>>
ST>>
ST>>
ST>>
ST>> From: sip [mailto:sip@arcdiv.com]
ST>> Sent: Wednesday, March 21, 2007 5:08 PM
ST>> To: Shafraz Thawfeek; serusers(a)lists.iptel.org
ST>> Cc: serusers(a)iptel.org
ST>> Subject: Re: [Serusers] SER + Prepaid with Radius AAA.
ST>>
ST>>
ST>>
ST>>
ST>>
ST>> You are correct. There are several workarounds for this, but for
ST>> the most part, what you need is some sort of B2BUA functionality.
ST>> Essentially, the call needs to go through a UAS that DOES keep
ST>> track. The new SEMS is supposed to have some of this
ST>> functionality, although I don't know much about it. Some people
ST>> use Asterisk (with Asterisk B2BUA). We ended up writing our own
ST>> Asterisk B2BUA as the Asterisk B2BUA code from sourceforge had
ST>> things in it we neither wanted nor used and their patches never
ST>> seem to be up to date on the later versions of Asterisk (current
ST>> code out there works in a guaranteed way only for Asterisk 1.2.1,
ST>> though it wasn't until after 1.2.9.1 that we had to seriously
ST>> rewrite the patch). The sourceforge code works, though, for
ST>> earlier versions of Asterisk, and is an excellent starting place
ST>> if you've little desire to write the whole thing yourself.
ST>>
ST>> The concept of using Asterisk is pretty simple: call gets
ST>> forwarded from SER to an Asterisk AGI program (C, Perl, etc) that
ST>> does all the magic. The easiest way is to do a balance check when
ST>> the call comes in to determine the cost of the outgoing call and
ST>> check how much time a person has left on the call based on how
ST>> much money is in their account. Then, just set up an Asterisk Dial
ST>> command with the appropriate timeout and let the server take care
ST>> of the rest. There are tricks to this, of course. Unless you're
ST>> somehow updating call credit and call timeout on the fly, you'll
ST>> need to limit the incoming calls to one at a time for each
ST>> account, or it's easy for someone to call with multiple phones and rob
ST> you of cash.
ST>>
ST>> N.
ST>>
ST>>
ST>> On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote
>> Hello All,
>>
>> Its really feels nice to have joined the list. I'm in the process of
ST> deploying a SER based solution for prepaid users. We're using a
FreeRadius
ST> based billing solution from a provider. If I'm not mistaken, SER is not
ST> aware of the call state, what this means to me is, in case the user account
ST> on the radius runs out of credit, SER will not know about it and will not be
ST> able to disconnect the call. Am I correct on this?
>>
>> If I am correct, I would like to know what would be the workaround for
ST> this? I'm I am wrong, then I would like to know on how we could get the
call
ST> disconnection working?
>>
>> I have a Nextone which would be sitting in front of the SER and acting
ST> as a Mirror Proxy for SER. The purpose of this is to overcome NAT traversal
ST> issues and free SER from that. Nextone doesn?t understand or talk radius.
ST> SER will be the registrar and handle AAA. The user call will be sent back
ST> into the Nextone and then terminated from there. SER will not be handling
ST> media. If to get my disconnect upon credit exhaust scenario working, what
ST> changes should I introduce into my existing network model?
>>
>> Thank you.
>> Shaf.
>>
>>
ST>>
ST>>
ST>>
ST>>
ST>>
ST> --
ST> Mike Tkachuk
--
Mike Tkachuk
6456
days inactive
6464
days old
9 comments
3 participants
participants (3)
-
Mike Tkachuk -
Shafraz Thawfeek -
sip