I’m about to start builing my first production, office-oriented Asterisk server. I’ve convinced my company that Asterisk is the way to go long-term, so they’ve agreed to let me use the new office I’m setting up as a testbed.
I’ve been doing a lot of reading of voip-info.org and these forums and the mailing list, and I’ve got most of my requirements mapped out. I’m left with a single issue that I can’t seem to find a definitive solution for (though I’m sure its possible).
Essentially, I’d like to use multiple Asterisk servers to provide Least Cost Routing between multiple offices.
Scenario:
Office A is in City A. Asterisk Server A is connected to local ISDN lines.
Office B is in City B. Asterisk Server B is connected to local ISDN lines.
If a user in Office A dials a number in City B, I’d like Asterisk to route the call to Server B which dials out using a local ISDN line (if available), and vice-versa.
Is this possible? If so, could someone point me towards appropriate resources to research the configuration for this?
I’m VERY green when it comes to asterisk, but I do know that the scenario you’ve described is not only feasible, it is a cornerstone in asterisk functionality. Others will be able to give you much more detail, but I do know that you will be looking into ‘IAX’, which stands for Inter-Asterisk-Exchange; this allows for a peering system that will facilitate the very type of Lowest-Cost routing you seek. I’m assuming you already have IP connectivity or some sort of network infrastructure that you could carve out a pipe for IP to ride on… else you’re going to incur the asterisk-to-asterisk call costs anyway, negating the benefits altogether. Perhaps even more costly since call-setup will be doubled. Nailed connections already assume you have infrastructure in place. Assuming you’re set IP network-wise, the learning curve will take some time to get used to so do not expect to theorize your entire config on paper, or even testbed which can be flat/2d; and then go production with the flip of a switch, problem-free. Only gurus in any technology can spatially assess every single cause/effect and KNOW every pre-deployment config will snap-in without a single surprise. ESPECIALLY with remote servers involved in your case… the testbed should encompass the new office as a pseudo-core, with at least one more asterisk server on a remote site. This way you won’t be blindsided by latency/echo and other issues unforseen when configuring a WAN buildout on reliable LAN technology. Unless you have spare routers & isdn sims etc. the testbed cannot be 100% local. An asterisk dev box and some cards can sort-of emulate, but not to the degree needed. No drunken backhoes, little latency, the dreaded ‘chronic circuit trouble’, etc . etc.like in the real world . I’d recommend at least 30 days in the testbed once the production config is mostly stabilized to account and develop procedures for daytoday events. You will need to do parallel integration, that is to say you will need to install the asterisk hardware in all of the offices and work through the buildout using test stations/agents at first, and then slowly & progressively migrating the system onto asterisk once you know all behaviour is as the users expect and the business requirements demand. As a data-side analyst I catch enough flack when the network has problems, but at least they expect trouble from my gear. (five nines my ass!) Mess up the users’ VOICE on the other hand and a whole new level of wigging out will ensue… sorry if i’m telling you things you may very well already know even at a subject matter expert level, but it’s best to put it out there just in case. So yeah, you can definetely do that with asterisk… and then some…
I figured it would be pretty core to Asterisk. I just didn’t find any handy "How To"s, so I thought I’d ask to be absolutely sure.
On the network side, we will have an SHDSL-based VPN connecting all the offices which is managed for us. This VPN supports end-to-end QoS, so I will be able to prioritize Asterisk traffic as necessary. However, the VPN is not fully redundant, so we are prepared for the scenario where we cannot make a connection to other offices via the VPN (hence the ISDN connections and “normal” phone calls!).
Luckily, I don’t really have to worry about IAX for a while. The first office is being installed next week and I’m only planning on having to take the second office live sometime in December or January. I’ll have plenty of time to play.
Sounds like a lot of learning & fun is in your future good stuff!
As far as the asterisk howto’s, how right you are! There is no singular clearing house that covers both multiple scenario howto’s as well as exhaustive syntax documentation. At first I was like ‘wtf’ until I realized that in fact there are tons of config files, hundreds of tons of options and no ‘default’ config to speak of… BUT, there are definetely some gems as far as helpful documents and repositories go. Ultimately though, it’s one of those deals where you have to just pound on it over and over and over until each mini-revalation and eureka moment comes together to form a working knowledge. Kinda like learning IP if you’ve ever done so, subnetting, routing, etc… or much like learning IP filters… protocol mechanics slowly coming together one by one to form the big picture… finally tackling that default-deny…
there are plenty of resources here documenting the repository addresses themselves, but I do have a couple favorite links I found amazingly useful as a greenie myself that I’ll cull together and pass on to ya once I get back from the Fry’s Electronics binge I’m about to go on this very second… past that, it’s a weeks-long project just to become the most elementary tier of ‘proficient’… that’s OK though, all that much more rewarding and ahem, MARKETABLE once attained What blows me away is that one guy coded most everything… I can’t even get my brain around the scope involved let alone the billions of minutia implemented in code… wow.
just wish i’d have found asterisk sooner… i’ve been wanting to harness control of my voice traffic beyond that of ultra-expensive and worse-than-m$-stability cisco IOS and H.323 solutions, etc. Let alone a full featured PBX…
good stuff!