Thanks Alex, some great ideas. <br>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).
<br><br><br>With my hardware, could Asterisk run stable for this amount of traffic? <br>What stability issues does Asterisk have at this scale?<br><br><div><span class="gmail_quote">On 5/12/07, <b class="gmail_sendername">
Alex Balashov</b> <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Sat, 12 May 2007, Atlanticnynex said something to this effect:<br><br>> 'SIP Redirect Proxy', which I'm understanding to just redirect the SIP<br>> requests to the appropriate destination based on the routing logic- and
<br>> OpenSER is no longer involved in the call process (meaning that<br>> accounting can no longer be handled); but I hear their are many different<br>> ways for OpenSER to behave, can this include my described configuration?
<br><br> I gather that OpenSER can be combined with rtpproxy to stay in the media<br>path as well, if desired. And really, OpenSER can behave however you want;<br>it allows you full read/write modification of pretty much any SIP header.
<br><br> In terms of what module to use for this, I had a very hard time with this<br>too since, believe it or not, for such a ubiquitous open-source package,<br>it did not offer a straightforward way of making SQL database dips without
<br>relying on the particular schema of some module or another.<br><br> Ultimately, I found that the 'avp' module has a little function called<br>avp_db_query() which can extract query results and stick them in individual
<br>AVP values. This function may have just been put there for kicks, since<br>what AVP "really" implements is some transparent way of storing key/value<br>pairs.<br><br> So, what I really end up doing for most of my intelligent routing is
<br>something like:<br><br>---<br><br> avp_db_query("SELECT ip_addr, port FROM customer_proxies WHERE<br>customer_id = $avp(S:customer_id) AND active = true",<br>"$avp(S:proxy_ip);$avp(S:proxy_port)");
<br><br> if(!is_avp_set("$avp(S:proxy_ip)") ||<br> !is_avp_set("$avp(S:proxy_port)")) {<br> xlog("L_INFO", "target-das - [$ci] - Active proxy not<br>found.\n")
<br>;<br> sl_send_reply("404", "Not Found");<br> exit;<br> }<br><br> xlog("L_INFO", "target-das - [$ci] - Resolved proxy<br>$avp(S:proxy_ip):$avp(S:proxy_port)\n");
<br><br> avp_pushto("$ru/domain", "$avp(S:proxy_ip):$avp(S:proxy_port)");<br><br> xlog("L_INFO", "target-das - [$ci] - Attempting handoff to $ru\n");<br><br> avp_delete("$avp(S:customer_id)");
<br> avp_delete("$avp(S:proxy_ip)");<br> avp_delete("$avp(S:proxy_port)");<br><br>---<br><br> Seems like the simplest approach to me.<br><br>> My SIP users can't know who the Upstream Providers are, so all traffic must
<br>> be 'relayed' through my server, including media.<br><br> In that case, use Asterisk as an SBC and keep it in the media path<br>perhaps, or tack on an RTP proxy to OpenSER, although unfortunately I can<br>
tell you absolutely nothing about how to go about this.<br><br>> I've confirmed that my SIP users can authenticate to OpenSER via the<br>> RADIUS module, but 1) how do I keep track of the call detail records<br>
> {minutes used, user info, dest. info} and report it back to RADIUS?<br><br> A decent RADIUS module will have the capability log the accounting<br>information into a RADIUS accounting backend as well, since accounting is a
<br>key component of RADIUS. If not, you can use something akin to what I<br>described above to keep the CDRs yourself.<br><br>> how do can OpenSER authenticate to my Upstream Providers?<br><br> I am not sure if it can. There may have to be a B2BUA somewhere further
<br>upstream within your "backend platform," as is not infrequently done.<br><br> In other implementations I've seen, all connections to providers are done<br>on a hard-coded port/IP-mapped "peer" basis so that proxies can hand calls
<br>off straight to them. But another way is to put another SBC-type unit at<br>the egress to the provider(s) to take care of that. Just beware that this<br>comes with the full implications of a B2BUA--distinct logical call legs.
<br><br>Best of luck,<br><br>-- Alex<br><br>--<br>Alex Balashov <<a href="mailto:sasha@presidium.org">sasha@presidium.org</a>><br>_______________________________________________<br>--Bandwidth and Colocation provided by
<a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users
</a><br></blockquote></div><br>