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.