Enterprise level phone system with area codes and exchange codes

Ok, this might be a weird question. I am coming at this from a mindset of emergency communications for an area such as Puerto Rico after the hurricane hit it. But what I am looking at is setting up a system of multiple PBX’s that are connected via SIP/IAX simulating the “normal” phone system. Is there a way to set up an area code controller and exchange controllers within the area code, all linked together to make “normal” (801) 555-1234 style dialing?

Asterisk does as it you tell it to do and configure it to do. It has no concept of an “area code controller” or “exchange controller” inherently, those would just be concepts expressed by your configuration.

E.g. (although this needs some refining for practical and you should use PJSIP, rather than the SIP that I know):

Exchange level;

exten=>1234,1,Dial(SIP/Line1234)
exten=>_801555XXXX,1,Goto(${EXTEN:6},1)
exten=>_555XXXX,1,Goto(${EXTEN:3},1)
exten=>_XXXXXXXXXX,1,Diall(SIP/${EXTEN}@801Area

801 Area

exten=>_801555XXXX,1,Transfer(SIP/${EXTEN}@<address of 801555 exchange>)
exten=>_802XXXXXXX,1,Transfer(SIP/${EXTEN}@<address of area code router>)

Area code router

exten=>_801XXXXXXX,1,Transfer(SIP/${EXTEN}@<address of 801 area node>)

These are not the only ways of distributing the network topology knowledge and whilst Transfer gives the most optimal final routing, given that Asterisk doesn’t de-trombone sub-optimal routes, it is not often used, so is more likely to be buggy, and we are presuming here that lower level nodes don’t know all the other nodes, so it would require calls to be accepted form unknown sources, and therefore a security risk if the network is open.

The various different pattern letters are to allow the patterns to be more specific to what digits are actually allowed in area and exchange codes in the NANP. X was lazy on my part, but you should be more specific.Preformatted text

Fair enough so then what is the plan to keep these systems up and connected to each during an emergency like a hurricane? Before we worry about how you will route calls within the system let’s look at how the system is going to stay alive during something like a hurricane that would do things like take out power and other infrastructure.

What is the power plan? During something like a hurricane or other disaster you’ll need to keep power going if the grid goes out. Will there be redundant power from a second grid available? Will there be a generator to keep the power going? Or some other external power source (batteries, etc)?

What about connectivity? How will these PBX systems connect to each other? How will user devices connect to the PBX? What is the plan if the Internet goes does down? Will you have GSM/Cell backup?

Will there be any routing or connecting uses to emergency services such as EMT’s, fire or police services? How will you route those calls? How will you pass user details on to them for reaction to the emergency?

Blaze,
The ham radio community already has this all working. They have come out with data over radio basically using 2.4Ghz devices with high gain directional antennas to cover large distances. We use generators, solar, etc to set up communications into places after they are hit. This is not the problem.

As for connectivity, the network will be there provided by us hams.

David,
Thanks for the response. AS for security, I don’t think that is a huge risk in this case as this is a temporary set up to assist in disaster areas. So, if I am understanding this correctly, Asterisk does function as I was hoping, in that you would forward to the “area code” server, which would then forward to the “Exchange” controller which would connect the call. And the call would be forwarded to each so that the final “call” would go directly from exchange to exchange without plugging up the “Area code” controller?

Well that sounds pretty solid. As for what you’re looking to do, you control what can be dialed/accepted from the endpoints. So even if they wanted to call out over the PSTN, you still need to tell Asterisk to accept the digits they present.

So you could take a normal PSTN routed number and on this system have it route to one of your connected devices or out an endpoint/peer to the PSTN. So if you had a direct peer with a PSAP/emergency center you can route any calls to 911 directly over that peer instead of the PSTN. The example @david551 gave is a good jumping point.

We are more of an After the event setup. As a Pilot and a Ham, I would fly into an area, set up shop, connect the network, then set up the phone communications. That way people could use SIP apps on their own cell phones, register their existing numbers, and then call their friends/family in the area. I was just starting to look into the idea of connecting via the internet to a sip provider to allow calls outside the area. That would probably be limited to emergency responders and such as I don’t think we would handle the load of everyone in the area calling out at the same time. Hams are playing with using one or 2 pbxs to connect like an enterprise company, dialing extensions directly, but that would require a large amount of documentation to figure out who’s on what extension. Then disseminating the info the people on who they can call for what service, etc… It’s a nightmare. LoL
My idea would simplify a lot of this. People could just call each other directly. We could set up a 911 dialing that reached an operator, just like the real thing.

Asterisk provides building blocks, which allow you to create complex routing rules. This assumes you are using Asterisk directly, as GUIs can considerably constrain things.

Taking SIP, there are two ways of getting direct routing, one is, as my example suggested, to redirect the signaling, with the media following. However, you can also work with direct media, but roundabout signalling. In principle, the media can be direct from phone to phone, but you might find it easier to limit the tricky configuration to server machines, as this feature may not be particularly well supported by phones, particularly ones where you cannot control the phone configuration directly. (Actually, in theory you could redirect the signalling so that most of the call is phone to phone as well; it is just that people mimic traditional, hierarchical, phone systems, and don’t use that power of SIP.)

One other problem is that many mobile phones now need push notifications to wake up VoIP applications. Those typically require the full internet infrastructure. I think Androids can have applications set to never sleep, but not iPhones, but even for Androids, someone will have to configure the phones of the general public.

There are also protocols that will allow number to address translations to be done without relying on SIP forwarding, but I have no direct knowledge of them.

I used chan_sip as an example, because I know it supports pre-answer forwarding, but forwarding support varies between channel technologies. I don’t, for example, know if IAX supports it.

One thing to consider is that even single hop WiFi has poor latency characteristics. You may find that audio quality and round trip delay are unacceptable over multiple hops. As you mention 2.4GHz, and not a ham frequency, I assume you are using long range WiFi, carrier sense access devices, and not continuous transmission point to point link devices.

Single hop distance for WiFi seems to be limited to about 1km, because of protocol constraints.

There are WiFi enhancements that prioritize time dependent media, but I’m not sure how they will cope with a lot of VoIP traffic, and multiple hops.

Dave, with the devices and antennas we use, we regularly push 2.4ghz to 12 to 15 miles. It’s a really interesting system. With our ham licenses, we are able to push a little more power on wifi channels that are in the Amateur radio ranges (not usable by the “normal” wifi devices). Anyway, I’m not here to teach HSMM on an ASTERISK site. :o)

Thank you VERY much for your inputs. It gives me a lot to research.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.