Thanks Alex, some great ideas.
I think, however, I'm leaning towards Asterisk at this point- since I have
quite a bit of experience there, and very little with SER. At this point,
I'm wondering from a dimensioning standpoint, what kind of capacity my
machine will have (Dual Core Xeon 2.4GHz 4GB RAM). As I said, I don't plan
to do any transcoding. I read the voip-info page on dimensioning and it
seems theres some mixed feelings about Asterisk in high-capacity
environments. I guess I'm looking for input as to whether Asterisk could
handle roughly one DS3's worth of calls (672 calls) just doing the LCR (I've
seen some pre-built LCR apps, looks like they all do on-the-fly MySQL
queries- I think I'd write my own AGI that would use a cache).
With my hardware, could Asterisk run stable for this amount of traffic?
What stability issues does Asterisk have at this scale?
On 5/12/07, Alex Balashov <[EMAIL PROTECTED]> wrote:
On Sat, 12 May 2007, Atlanticnynex said something to this effect:
> 'SIP Redirect Proxy', which I'm understanding to just redirect the SIP
> requests to the appropriate destination based on the routing logic- and
> OpenSER is no longer involved in the call process (meaning that
> accounting can no longer be handled); but I hear their are many
different
> ways for OpenSER to behave, can this include my described configuration?
I gather that OpenSER can be combined with rtpproxy to stay in the
media
path as well, if desired. And really, OpenSER can behave however you
want;
it allows you full read/write modification of pretty much any SIP header.
In terms of what module to use for this, I had a very hard time with
this
too since, believe it or not, for such a ubiquitous open-source package,
it did not offer a straightforward way of making SQL database dips without
relying on the particular schema of some module or another.
Ultimately, I found that the 'avp' module has a little function called
avp_db_query() which can extract query results and stick them in
individual
AVP values. This function may have just been put there for kicks, since
what AVP "really" implements is some transparent way of storing key/value
pairs.
So, what I really end up doing for most of my intelligent routing is
something like:
---
avp_db_query("SELECT ip_addr, port FROM customer_proxies WHERE
customer_id = $avp(S:customer_id) AND active = true",
"$avp(S:proxy_ip);$avp(S:proxy_port)");
if(!is_avp_set("$avp(S:proxy_ip)") ||
!is_avp_set("$avp(S:proxy_port)")) {
xlog("L_INFO", "target-das - [$ci] - Active proxy not
found.\n")
;
sl_send_reply("404", "Not Found");
exit;
}
xlog("L_INFO", "target-das - [$ci] - Resolved proxy
$avp(S:proxy_ip):$avp(S:proxy_port)\n");
avp_pushto("$ru/domain", "$avp(S:proxy_ip):$avp(S:proxy_port)");
xlog("L_INFO", "target-das - [$ci] - Attempting handoff to
$ru\n");
avp_delete("$avp(S:customer_id)");
avp_delete("$avp(S:proxy_ip)");
avp_delete("$avp(S:proxy_port)");
---
Seems like the simplest approach to me.
> My SIP users can't know who the Upstream Providers are, so all traffic
must
> be 'relayed' through my server, including media.
In that case, use Asterisk as an SBC and keep it in the media path
perhaps, or tack on an RTP proxy to OpenSER, although unfortunately I can
tell you absolutely nothing about how to go about this.
> I've confirmed that my SIP users can authenticate to OpenSER via the
> RADIUS module, but 1) how do I keep track of the call detail records
> {minutes used, user info, dest. info} and report it back to RADIUS?
A decent RADIUS module will have the capability log the accounting
information into a RADIUS accounting backend as well, since accounting is
a
key component of RADIUS. If not, you can use something akin to what I
described above to keep the CDRs yourself.
> how do can OpenSER authenticate to my Upstream Providers?
I am not sure if it can. There may have to be a B2BUA somewhere
further
upstream within your "backend platform," as is not infrequently done.
In other implementations I've seen, all connections to providers are
done
on a hard-coded port/IP-mapped "peer" basis so that proxies can hand calls
off straight to them. But another way is to put another SBC-type unit at
the egress to the provider(s) to take care of that. Just beware that this
comes with the full implications of a B2BUA--distinct logical call legs.
Best of luck,
-- Alex
--
Alex Balashov <[EMAIL PROTECTED]>
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
