Hack55.Link Two Asterisk Servers with PSTN

Hack 55. Link Two Asterisk Servers with PSTN

You don't have to have dedicated point-to-point lines to link two PBX systems. Just use the PSTN phone lines that are already connected to them, and you can simulate a direct link.

You can build a two-office unified dial plan using two Asterisk servers. This way, a user need only dial the extension of the user at the other office to reach him, instead of calling that office's main number, waiting for prompts, and then dialing the user's extension. Asterisk can handle all of these steps automatically, routing the call to the other office's PSTN trunk, waiting until it's answered, and dialing the recipient's extension to complete the connection. Figure 4-11 illustrates just such a configuration.

Figure 4-11. Two offices with PBXs connected to the PSTN

Ordinarily, if a West user wanted to reach an East user, he'd have to pick up his phone, dial the phone number of the East office, wait for an answer, and then request that user, either by speaking with a receptionist or by dialing that user's extension. This awkward process is shown in Figure 4-12. Direct Inward Dial could shorten the process, but the dialing user still wouldn't be able to reach his co-worker using a convenient, four-digit extension.

Figure 4-12. Figure 4-12. A caller has to dial a lot of digits to reach his intended recipient at the other office

4.16.1. The Configuration

We'll use the same dial-plan extension-numbering convention as shown in Figure 4-12. Phones at the East office will be 30003099; phones at the West office will be 34003499. Have one SIP phone register with the East server and the other SIP phone with the West server (our West user will be using the phone that registers with the West server, and the East user will be using the East-registered phone). The following code shows the SIP peer config for 3001 at the East office:

 # East office sip.conf … [3001] caller <3001> canreinvite=no context=default host=dynamic mailbox=3001 secret=3001 type=friend username=3001 

The following code represents the SIP peer config for 3401 at the West office:

 # West office sip.conf … [3401] caller <3401> canreinvite=no context=default host=dynamic mailbox=3401 secret=3401 type=friend username=3401 

With these first two configs committed, the SIP phones can now register with their respective Asterisk servers and place calls in their own default contexts. But they still can't call each other without dialing a lengthy PSTN phone number, waiting for the auto-attendant, and dialing the extension on the answering Asterisk system. To get around that, we can tell both Asterisk servers to route calls bound for the extension-number range of the other office out through the PSTN and automatically dial the extension on the answering system, as follows. We'll start with the dial-plan config for the East office:

 # East office extensions.conf … [default] exten => _34XX,1,Dial(Zap/1/5551340,35,mD(${EXTEN})) 

And we'll institute a mirror of that config so that West office users can dial 30XX extensions:

 # West office extensions.conf … [default] exten => _30XX,1,Dial(Zap/1/5551300,35,mD(${EXTEN})) 

Let's dissect this exten directive. First, _30XX is a wildcard expression that matches any number dialed that begins with 30. 1 is the extension priority. The Dial command tells Asterisk to dial the number of the other office on the Zap/1 channel and to wait for up to 35 seconds for the call to be answered. Then, the D(${EXTEN}) option tells the Dial command to send DTMF digits representing the extension number that was dialed by the user. ${EXTEN} is an Asterisk variable that always contains the extension number used for the current call. Finally, as with all Dial commands, the call will be connected after the DTMF digits are sent.

The net result of this config is that the users at West can dial 30013099 to reach the users at East, and the users at East can dial 34013499 to reach the users at West, all without any PSTN dialing or auto-attendant interaction. Here, the PSTN trunks are used like private trunks to connect two switches, while the dial plan makes it easy for the users.

4.16.2. Control Caller ID When Using PSTN Trunks

In the preceding example, the receiving PBX doesn't know the extension number of the party who is calling, because the calling PBX supplies the caller ID signals for the Zaptel channel and phone line being used, not the caller ID signals for the extension that originated the call. So, the receiving user will see that she is getting a call from the "other office," but she won't know which user is calling her.

Using some Asterisk dial-plan wizardry, you can preserve the original caller's caller ID information throughout the interswitch calling process:

 # West office extensions.conf … [default] exten => _30XX,1,SetCIDNum(${EXTEN}) exten => _30XX,2,Dial(Zap/1/5551300,35,mD(${EXTEN})) 

In this case, Asterisk will supply the originating extension number as the caller ID number. SetCIDNum establishes the caller ID number for outgoing channels on the current extension. This config would, of course, have to be mirrored for the East office, too:

 # East office extensions.conf … [default] exten => _34XX,1,SetCIDNum(${EXTEN}) exten => _34XX,2,Dial(Zap/1/5551340,35,mD(${EXTEN})) 

To override the phone company's caller ID, you'll need to be using PRI signaling, and the phone company will have to permit you to supply your own caller ID information.

There you have it: a two-office Asterisk PBX network that uses existing telephone lines to simulate a direct link between the two sites.

VoIP Hacks
VoIP Hacks: Tips & Tools for Internet Telephony
ISBN: 0596101333
EAN: 2147483647
Year: 2005
Pages: 156

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net