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 <abalashov@evaristesys.com> 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 <sasha@presidium.org> > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > lists.digium.com/mailman/listinfo/asterisk-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: lists.digium.com/pipermail/asterisk-users/attachments/20070512/5d872d02/attachment.htm
On Sat, 12 May 2007, Atlanticnynex said something to this effect:> 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).It's really hard to say. My personal impression from discussions I've witnessed on this subject is that you might be able to get away with 1/3rd of a DS3, and under no circumstances more. But that doesn't mean you can't make this work with a few Asterisk servers and a proxy that routes requests to them in a round-robin and/or other load balancing fashion. And of course, I could be completely wrong. I know that one of the main frustrations with Asterisk on the TDM side -- and yes, I know you're talking about SIP-to-SIP -- is that there is no way it can possibly scale to handle a DS3 of PRIs, and that approach at least grants some possibility of hardware offloading. This has led people to have to use TNTs and other things that have DS3 adaptors as media gateways, although finding adequate call logic / call control is not within the economic reach of most. -- Alex -- Alex Balashov <sasha@presidium.org>
Atlanticnynex wrote:> 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).When appropriately configured, MySQL does a pretty good job of caching results too. [129 lines snipped] /Per Jessen, Z?rich -- ENIDAN Technologies GmbH - managed email security. Starting at SFr1/month/user - spamchek.ch
On May 12, 2007, at 4:11 PM, Atlanticnynex wrote:> 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? >Simply put, NO. I am on a project now where a client had an OpenSER box acting as an SBC and registrar passing traffic to several asterisk boxes which are doing LCR lookups on the fly as well as writing custom CDRs all through PHP AGI scripts to a Postgres DB. The Asterisk boxes do not scale, and randomly start swallowing calls or, more often, restart the process (safe_asterisk is handling this). There is some light IVR type usage for reporting account balances and the like. With anything more than 80 or 90 calls on the box, the IVR prompts start to break up. Ben through replacing hardware, more memory, different Asterisk builds, etc. I've had an open issue with Digium support on this for at least a couple of weeks, and the best advice so far was "try using the SVN build". That makes things better, but it's still not anywhere close to fixed.. It's absolutely incredible that Asterisk works at all for some of the situations its been put in - major kudos to the developers. But I don't think using it for what you're talking about is a long-term business strategy. When the highlight of the 1.6 release is bridging channels, you know high volume sip to sip usage in a carrier class call routing environment is NOT what development is focused on. And that's fine. If you use a wrench to do the job of a screwdriver, you shouldn't complain when you bust your knuckles That being said, I don't meant to trash Asterisk at all. It's a fantastic feature server, and a great PBX, both of which things I use it for very successfully. I just don't think it's ready to handle 50k plus minutes a day SIP to SIP with LCR and billing data, no matter what you do with it. I'm 100% positive there are people out there doing it successfully, but those are the exception, not the rule. And I doubt they are running unmodified code.