<HTML>
<HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="OPENWEBMAIL" name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<font size="2">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.
<br />
<br />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.
<br />
<br />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.
<br />
<br />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.
<br />
<br />You might be able to jury-rig some sort of solution out of a modified Media Proxy, but I've no idea.
<br />
<br />There's another solution I know nothing at ALL about which uses Asterisk called AstBill that handles prepaid.
<br /><b>
<br /></b>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.
<br />
<br />There are probably at least a half dozen others available if you look about.
<br />
<br />Good luck. :)
<br />
<br />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.
<br />
<br />
<br />N.
<br /><b>
<br />On Thu, 22 Mar 2007 13:00:18 +0530, Shafraz Thawfeek wrote</b>
<br />> <span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Thank you for the information.
<o:p /></span>
<br />> <span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">As a B2BUA, can I use Vovida? Anybody has successfully
deployed
Vovida with SER for a Prepaid scenario? Or Vovida is a bad
idea?<o:p /></span>
<br />> <span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">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?<o:p /></span>
<br />> <span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">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
;)<o:p /></span>
<br />> <span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p>
</o:p></span>
<br />>
<br />> <b><span style="font-size: 10pt; font-family: "Tahoma","sans-serif";">From:</span></b><span style="font-size: 10pt; font-family: "Tahoma","sans-serif";">
sip
[mailto:sip@arcdiv.com]
<br />>
<b>Sent:</b> Wednesday, March 21, 2007 5:08 PM
<br />>
<b>To:</b> Shafraz Thawfeek; serusers@lists.iptel.org
<br />>
<b>Cc:</b> serusers@iptel.org
<br />>
<b>Subject:</b> Re: [Serusers] SER + Prepaid with Radius
AAA.<o:p /></span>
<br />> <o:p>
</o:p>
<br />> <span style="font-size: 10pt;">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.
<br />>
<br />>
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.
<br />>
<br />>
N.
<br />>
<b>
<br />>
<br />>
On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote</b>
<br />>
> Hello All,
<br />>
>
<br />>
> 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?
<br />>
>
<br />>
> 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?
<br />>
>
<br />>
> 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?
<br />>
>
<br />>
> Thank you.
<br />>
> Shaf.
<br />>
>
<br />>
>
<br />>
<br />>
</span><o:p />
<br />
<br />
<br />
</font>
</BODY>
</HTML>