Section 12.1. Dial-Tone Trunks

12.1. Dial-Tone Trunks

Choosing from the plethora of legacy voice connectivity technologies isn't a no-brainer. When you choose a dial-tone trunk solution to supply your voice switch with a path to the outside world, you should consider the capacity of the solution, the implications for quality of service, geographic availability, and, of course, the cost.

12.1.1. POTS and Centrex Trunks

Plain old telephone service, introduced in Chapter 1, is an analog phone line from the CO that connects to your PBX using one copper pair. This is the kind of phone service you most likely have in your home. The POTS line is cost effective when fewer than 10 lines are concentrated in one location. Most POTS lines are paid for monthly, with overage charges added when a certain level of utilization (minutes) has been surpassed. POTS lines are available just about anywhere there's electricity and running water. Each POTS lines can support one phone call at a time.

Centrex phone lines are POTS lines with special, business- related calling features like four-digit private endpoint dialing. These are the lines on which you have to "dial a 9 to get out." Centrex has the same economics as POTSyou generally pay a monthly fee that covers a certain amount of utilization on the line; after that, you pay by the minute. Centrex is less widely available than POTS. It's often absent from residential and rural areas. Like POTS, each Centrex line can support one phone call at a time. T1/PRI trunks

While T1/PRI trunks vary greatly from one carrier to the next , a safe rule to use when comparing their cost to that of traditional POTS lines is this: a T1/PRI is a cost-effective choice for locations needing 10 or more PSTN trunks connected to the same voice network. In fact, using 10 voice channels on a T1 is often cheaper than using POTS or Centrex lines because of most telephone companies' price structure. (Check with your phone company to see if this is the case for you. In some areas, PRI still isn't cost competitive with POTS.)

T1s in the United States use PRI signaling to support up to 23 simultaneous calls. With DID (direct inward dial), hundreds of E.164 phone numbers can be used with PRI. DID, combined with T1's high capacity and cost appeal , makes this solution very appealing. Since T1s dedicate a fixed slice of the bandwidth pie to each voice channel, quality of service is never an issue.

The interface at the subscriber's demarc where a T1 ends is called a smart jack .

ILECs, CLECs, and TSPs

ILECs, CLECs, and TSPs compete for roughly the same customers. ILECs entered the market first, followed by CLECs and TSPs.


Incumbent local exchange carrier, the company that owns the network infrastructure used to deliver traditional phone service in a local area such as a city or county. ILECs sell voice services on landline connections like T1s and POTS.


Competing local exchange carrier, a company that colocates switching equipment in an ILEC's network operations center or CO, so it can use the ILEC's network infrastructure to deliver competing phone service. CLECs sell voice services on landline connections like T1s and POTS.


Telephony service provider, a company that uses VoIP or some other packet telephony service to provide phone service using network pathways provided by an ILEC, CLEC, ISP, or cable operator. TSPs are often customers of ILECs and CLECs. TSPs tend to offer dial-tone services at a highly discounted rate, and they have limited control over QoS.

If your voice network originates enough traffic, you may be using separate T1s for long-distance and local traffic. One or more T1s connect to your LDC, while another T1 or two connect to your LEC. This arrangement can enable you to avoid regulatory fees imposed for cost recovery purposes by LECs (called PICC charges) and enjoy a lower LD billing rate. ISDN BRI trunks

Supporting up to two PSTN calls simultaneously , the BRI signaling technology provides an essentially obsolete option for PSTN trunking. BRI circuits tend to be less cost-effective for voice calls than POTS or Centrex and are always less cost-effective than PRI. Yet, because of BRI's vintage , you may still encounter it with some legacy systems. Consolidating BRI connections with PRI connections is just about always a good idea, unless you've only a half- dozen or so trunks to support. Even then, POTS is often cheaper than BRI. VoIP trunks

Using a T1 (PRI) trunk to bring in 23 channels of digital dial-tone is more cost-effective than bringing in 23 POTS lines to do the same thing. But using that T1 as an IP point-to-point to link the CO to your PBX can bring even greater efficiency, especially if your telephone company supports bandwidth-conservation goodies like highly efficient codecs and silence suppression.

If you use a residential VoIP dial-tone provider, the SIP or IAX connection from your ATA or softPBX to the TSP is, by definition, a VoIP-based trunk. But these types of VoIP trunks have no quality-of-service measures, and their proprietors cannot guarantee a level of service. This is where a traditional phone company (SBC, XO, Verizon, etc.) has a big advantage over the upstart TSPs. Some TSPs do not yet offer 911 emergency dispatch service yet, either.

In North America, phone lines serviced by state- regulated phone companies (ILECs) are required to allow quick dialing of a public safety dispatcher. The phone number used in case of emergencies is 911.

In early 2005, the FCC mandated that CLECs provide access to the 911 call-routing system on behalf of VoIP-only TSPs such as Vonage. As a result, competitive carriers like CLECs and TSPs can be required to pay the CLEC a fee for routing of 911 calls to the local dispatch center. Competitors pay this fee because they fall under state regulatory agencies that require them to provide 911 service on a minimum of one line at each subscriber's premises. If you use a competitor, you may see this fee, which is usually only a buck or two, added on to your telephone statement as a tax.

An ILEC has dedicated trunks connecting to PSAPs (public safety answering points), which it must allow the CLECs and TSPs to use. Of course, not all TSPs have integrated 911 call routing as well as the ILEC's we've all relied on for decades. As access to 911 dispatch services are enabled, TSP support of 911 will become more consistent. Check with your TSP to see if they support it.

The big difference between TSPs like Vonage and phone companies like Verizon is QoS. TSPs usually can't offer quality-of-service measures because they don't own the infrastructure that they use to deliver their VoIP trunks to your network. Phone companies, on the other hand, own the "last mile," even for IP links. They have complete control over each phone call, from its point of origin on your phone network, to its PSTN handoff point on the phone company's network. This total ownership of the last mile means the phone company can guarantee quality for you.

If you're intent on using a TSP, you won't get QoS unless you're willing to pay for a direct network connection to that TSP. More often than not, this connection would be a T1. Of course, that would likely end up being more costly than just using the phone company for dial-tone service, because if you have a T1, it's touching the phone company's network anyway. Remember, the phone company, not the TSP, owns the last mile of connectivity, and this gives the phone company the quality advantage. Hosted PBX

A step beyond VoIP trunks from the CO switch to your PBX is outsourcing PBX services to an application service provider. Hosted VoIP PBX services do this, allowing you to support only IP phones (and not a softPBX) at your premises. These phones communicate directly to the hosted PBX server at the provider's data center using a direct IP link or the Internet. The use of VoIP trunks for your on-premises PBX is a relatively new idea. There are lots of variations on the VoIP trunk theme, though a SIP-based service called IP Centrex is getting the most marketing attention by the big local phone companies. ATM trunks

A number of long-distance carriers now offer local dial-tone service using T1 circuits connected to an ATM network. In high-density situations, this kind of local service can save money, especially in long-distance fees. If your system has a lot of long-distance traffic, you may consider a VoATM solution for your PSTN trunks. Television cable and fiber trunks

Cable television operators like Adelphia and Comcast offer telephone service via VoIP, though it remains to be seen whether this service will evolve into a dial-tone trunk offering for PBX operators. Obtaining dial-tone service from a cable operator is likely to get you quality of service that is on par with a phone company. That's because cable operators own last-mile infrastructure as ILECs do. Because of cable's high bandwidth yield, it has the potential to carry many times more voice traffic than a VoIP trunk over a T1.

Some cable operators are introducing fiber- optic cabling to the customer's demarc. This will result in even higher capacity. Aside from voice calling, videoconferencing and eventually television programming will be delivered using a packet-based, probably IP-based approach. If that's not enough bandwidth...

If some combination of the preceding technologies doesn't solve your PSTN connection needs, then there are even faster kinds of connections. Optical STS connections, also called OC (optical carrier), offer call capacities in the tens of thousands. Chances are pretty good though, if you're seriously considering OC, you're a telephone carrier, a very large ISP, or AT&T. Very few corporate call centers need that caliber of voice bandwidth.

Table 12-1 compares trunk technologies and their characteristics.

Table 12-1. Characteristics of dial-tone trunk technologies




VoIP via T1/E1

VoIP w/ QoS via T1/E1

VoIP via cable

Simultaneous call capacity



23 / 29

G.711: ~18/24

G.711: ~18/24

Depends on carrier

Who provides calling service






TSP or cable company

Who provides connectivity




ILECs, CLECs, Internet


Cable company

Cost per line







Calling features

Usually cost extra

Usually built in

Usually built in

Built in

Built in

Usually none

Interface device to TDM system

Analog PBX trunk port

Analog PBX trunk port

T1 port or channel bank

VoIP Server

VoIP Server

VoIP Server

Interface device to VoIP system

ATA or analog trunk port

ATA or analog trunk port

T1 port or media gateway

Ethernet interface

Ethernet interface

Ethernet interface


Easy to use; available everywhere

Easy to use; extra calling features

Cheaper per-trunk cost when lots of channels are used

Can be used for voice and data without channelizing

QoS can be managed by the telephone company

Can be used for voice and data


Too expensive for connect points with a lot of trunks

Too expensive for connect points with a lot of trunks

Not always a good choice for small connect points (fewer than six lines)

Doesn't always provide QoS

Doesn't always provide QoS

12.1.2. How Many Dial-Tone Trunks Are Needed?

Whether you use POTS or your dial-tone is brought to you by way of SIP, you've got to make sure you've got enough trunks for your telephony application. If you're building a large hosted telephony application, like a call center, you'll probably need loads of them. If you're building a simple PBX in your home, you may require only one or two. In a medium- sized office, you might need a few dozen.

The place where your PSTN interfacing occurs is your PSTN connect point . Recall that, through VoIP, you can have voice conversations over your IP network, which may be a WAN that spans many, many miles. This will no doubt affect the location of your PSTN connect point, as well as the number of trunks required at that point. In Figure 12-1, you can see how a traditional wide area voice network might look. Its connect points are at every location where there's a PBX. The case for fewer trunks

You'll use fewer PSTN trunks if you leverage your IP network. Say you've got three officesone in New York, one in Detroit, and one in Kansas City. The one in

Figure 12-1. A traditional wide area enterprise voice network has lots of PSTN connect points

Detroit may be considered the central office because it acts as the corporate data center, the "hub," providing services for New York and Kansas City, the "spokes." It might make sense, if a lot of the spokes' voice traffic is long-distance traffic, to reduce the number of trunks at the spokes ' PSTN connect points and increase them at the hub's PSTN connect point, as in Figure 12-2.

Figure 12-2. An enterprise voice network that uses VoIP trunks can leverage its WAN, and reduce the number of PSTN connect points, and often the number of PSTN trunks, it requires

This way, the organization could conceivably get a volume deal from the carrier providing dial-tone in the Detroit office. As a rule, the more bandwidth you have at one PSTN connect point, the less expensive, per trunk, that point becomes. You might also be able to trim the PSTN overall trunk count across the network because, when you consolidate PSTN trunks to a single connect point, you may find you just don't need as many trunks to support a centralized setup. (There are plenty of reasons not to centralize, too; Chapter 13 describes them.) The case for more trunks

Some telephony applications, like conference calling, bridging, and hold queues may tie up PSTN trunks and require you to use more of them than you'd normally need. For instance, conference calling requires one additional trunk for every outside party participating in the call. If you've got three outside participants , then you need three trunks.

Call bridging and "find-me-follow-me" applications, which ring internal and external phones simultaneously in order to make it easier to reach the intended party, tie up PSTN trunks, too. If your application rings a user 's IP desk phone and his cell phone simultaneously, keep in mind that a PSTN trunk is used to ring the cell phone. If the call causing this to occur originated from outside your network on the PSTN, then you've got another PSTN trunk tied up. That's two phone lines tied up.

In these situations, the only solution is to add additional trunk capacity. By using the Erlang B table in Chapter 4, you can properly size each of your PSTN connect points so that applications don't suffer busy signals due to inadequate capacity.

12.1.3. Project 12.1. Make It Easier for Callers to Reach PBX Users What you need for this project:
  • Asterisk

  • Two X100P interface cards or a TDM400P card with two FXO modules

  • One or more SIP phones

  • LAN

In the early 1990s, phone companies began to introduce a feature called call forwarding . This feature allowed a subscriber to enter a short DTMF code that would cause the CO to ring calls destined for her phone number to another phone number of the subscriber's choosing. This way, you would "never miss a call."

Today, a newer telephony application exists to solve the same challenge in the enterprise. Called find-me-follow-me or FMFM, this app goes through a list of internal extensions and external phone numbers stored on the PBX and rings them each, simultaneously or in a certain order, in an attempt to track down the desired person when the PBX has received a call for his extension. Sometimes, the caller will hear a special recorded message or on-hold music while this "find" is proceeding.

More advanced FMFM setups allow users to log in to extension phones or otherwise notify the PBX where they are and how best to reach them, so users' extensions can "follow" them. Using Asterisk's AGI and Asterisk Manager socket API, for example, you could program presence features that contribute to an elegant FMFM solution.

FMFM and hunt groups are two different things. Hunt groups are statically defined and comprised only of endpoints or trunks associated with a certain group of users. FMFM uses a group of endpoints and phone numbers associated with a certain single user. In Asterisk, though, their extension programming is similar.

To create a simple FMFM app with Asteriskone that doesn't use presenceyou must program the dial-plan with the right steps to carry out the FMFM "find" when an extension is dialed . To do this, first pick out the three or four endpoints or PSTN phone numbers you want to use. Then decide if you want the find pattern to be simultaneous or sequential. Don't forget that for every simultaneous PSTN destination you put in your pattern, your PBX server will need an additional PSTN trunk. We'll start with a sequential pattern and do a simultaneous one next.

Now, make sure you have a cell phone and a couple of IP phones turned on and working. Make a note of the cell phone's number and IP phones' extensions. If they aren't configured, set them up now.

When creating an FMFM find pattern, what you're really doing is programming an extension to hunt through other extensions and PSTN numbers. So, in the following example, calling extension 601 will result in the sequential dialing of extension 201, then 202, then cell phone number 440-523-0555. Eventually, if there's no answer anywhere, the extension will result in a voice mail greeting.

Take a look at this sample extension from /etc/asterisk/extensions.conf , which achieves just that:

 exten => 601,1,Answer( )     exten => 601,2,Dial(SIP/201,15,m)     exten => 601,3,Dial(SIP/202,15,m)     exten => 601,4,Dial(Zap/1/14405230555,15,m)     exten => 601,5,Voicemail(201)     exten => 601,6,Hangup( ) 

So, when extension 601 is dialed, Asterisk answers the call and immediately attempts to connect it to channel SIP/201, assumed to be a SIP peer already configured in /etc/asterisk/sip.conf . If, after 15 seconds, nobody answers at SIP peer 201, then Asterisk attempts to connect the call to SIP/202. If nobody answers, then Asterisk attempts to connect the call on a Zaptel channel, Zap/1, to 440-523-0555the cell phone. If there's no answer signaled before 15 seconds elapses, the call is transferred to voicemail box number 201. Finally, Asterisk hangs up the call. The m options in each of the Dial commands will cause Asterisk to play a music-on-hold message that's based on your on-hold configuration and context (more on that in Chapter 17).

The options used with the Dial command, such as m in the preceding example, are case sensitive. m is used for music-on-hold, and M is used for macros, so watch those caps! For a complete list of Dial command options, check out the command reference in Chapter 17.

It only takes a few tweaks to the FMFM extension to improve its functionality. By concatenating the SIP channels into a single Dial command, we can ring them simultaneously, then continue the find attempt with the cell phone:

 exten => 601,1,Answer( )     exten => 601,2,Dial(  SIP/201&SIP/202  ,15,m)     exten => 601,3,Dial(Zap/1/14405230555,15,m)     exten => 601,4,Voicemail(201)     exten => 601,5,Hangup( ) 

In this case, the two SIP phones are rung simultaneously for 15 seconds before the find proceeds to the cell phone number. If you wanted to ring all three simultaneously, you could concatenate the Zap/1/1440 ...expression into the Dial command.

Much more elaborate FMFM tricks can be accomplished with web-based or Asterisk Gateway Interface programming. You could create a CGI script that lets you tell the Asterisk database the extension at which you're currently available (i.e., cell phone, desk phone, home phone), and then set up your dial-plan to pull that extension out of the database when someone is trying to call you. Asterisk's database commands are described in Chapter 17. Home phone call bridging

Now, suppose you wanted to build a simple server for your home that would ring both your home phones and your cell phone simultaneously whenever your home phone line receives a call. This is easy to accomplish with Asterisk. Bear in mind, you'll need two phone lines connected to your Asterisk serverone to receive the call and one to bridge the call to the cell phone. We'll assume for the following config that the analog channels are called Zap/1 and Zap/2 and that your home phones are SIP phones. (This could be done with analog phones too, if you had an additional Zaptel channel.)

In all dial-plans, the special extension s handles inbound calls on channels that are destined for the Asterisk server itself. So, when a PSTN caller reaches a trunk connected to Zap/1, the s extension tells Asterisk how to handle the call:

 [default]     exten => s,1,Answer( )     exten => s,2,Dial(Zap/2/14405230555,35,m)     exten => s,2,Dial(SIP/201&SIP/202,35,m)     exten => s,3,Voicemail(201)     exten => s,4,Hangup( ) 

This config answers the incoming call on Zap/1, then bridges it to the cell phone by placing an outgoing call on Zap/2. It also attempts to bridge on the two SIP phones as in prior examples. Finally, if after 35 seconds, neither the cell phone nor the SIP phones answer, the voice mail module takes over. Time-based context includes

You've already set up an FMFM find list to track you down wherever you go and even set up an Asterisk machine to just bridge everything to your cell phone. Both of these solutions are effective, but neither is especially elegant. That's why we're going to alter the home cell phone bridge dial-plan so that it bridges all calls to the cell phone only during the day, not at night.

Asterisk's include directives in extensions.conf can be used to specify context inclusion in a time-dependent manner. The format for include directives is:

 include =>  context   times   weekdays   days of month   months  

Since we want to prevent bridging of all inbound PSTN calls during non-business hours, we'll use time-dependent contexts to make it happen:

 [default]     include => business09:00-19:59mon-fri**     include => nonbusiness     [business]     exten => s,1,Answer( )     exten => s,2,Dial(Zap/2/14405230555,35,m)     exten => s,2,Dial(SIP/201&SIP/202,35,m)     exten => s,3,Voicemail(201)     exten => s,4,Hangup( )     [nonbusiness]     exten => s,1,Answer( )     exten => s,3,Voicemail(201)     exten => s,4,Hangup( ) 

In the preceding snippet of extensions.conf , the [business] context is included only during business hours, Monday through Friday, all days of the month, all months of the year. The [nonbusiness] context is also included. Though both contexts contain instructions for the s extension, Asterisk evaluates them at runtime in the order they're included in the dial-plan. So, [business] will be applied first, only during the time indicated in the include directive.

Now, suppose we wanted to do some additional exclusionsay, during holidays. Who wants to get a cell phone call when she's at Grandma's carving the Thanksgiving turkey ? Or on New Year's Day, for that matter?

 include => nonbusiness**1jan     include => nonbusiness**31may     include => nonbusiness **4jul     include => nonbusiness **6sep     include => nonbusiness 17:00-23:59*24nov     include => nonbusiness **25nov     include => nonbusiness 17:00-23:59*24dec     include => nonbusiness **25dec     include => nonbusiness 17:00-23:59*31dec     include => business09:00-19:59mon-fri**     include => nonbusiness     [business]     ...     [nonbusiness]     ... 

Now you've got a fully functional gateway that answers your calls, rings your cell phone when and if you want it to, and records a voice mail message if you're unavailable.

12.1.4. More on Trunk Sizing

T1 and its Euro-equivalent E1 provide 1.5 mbps and 2.0 mbps of bandwidth organized into 24 and 30 channels called DS0s. Throughout this book, we've referred primarily to T1 circuits, since they are the most common form of digital dial-tone trunk. But there are much higher capacity circuits available from your friendly local exchange carrier that are based on the same technology. These hi-cap circuits are the preferred way of hauling dial-tone from the LEC because they are generally less costly for it and you to maintain. Still faster speeds are available using SONET optical carrier connections.

Unlike T1s, which are connected by two copper pairs, SONET connections are made on multimode fiber-optic cable.

Once you decide how much capacity is needed at a PSTN connect point, you can choose one of the T carrier or OC circuits described in Table 12-2.

Table 12-2. T Carrier and OC circuits for PSTN trunking

N. American


N. American capacity

European capacity



64 kbps (1 call)

64 kbps (1 call)



1.5 mbps (23 calls)

2.0 mbps (29 calls)


E1 Third Level

44 mbps (~ 670 calls)

34 mbps (~ 480 calls)


STM-1 or OC-1

51.8 mbps (~ 800 calls)

155.5 mbps (~ 2400 calls)


STM-4 or OC-12

622 mbps (~ 9,600 calls)

622 mbps (~ 9,600 calls)


STM-16 or OC-48

2,488.3 mbps (~ 38,000 calls)

2,488.3 mbps (~ 38,000 calls)

12.1.5. Connecting Trunks to Your Telephone Network

Whether your PSTN trunks are PRI-signaled T1s, POTS lines, or VoIP trunks, there are basically two ways to connect them to the VoIP network or PBX. Either you're going to have an interface in the softPBX server, or you're going to have an offboard gateway that is itself trunked to the PBX.

Cisco's media gateways are Cisco routers with VoIP firmware. They have modular expansion slots that allow them to connect T1s, optical connections, POTS lines, and Ethernet interfaces for IP-based trunking. In a Cisco CallManager setup, all PSTN trunking to and from the softPBX is facilitated by these media gateways, as shown in Figure 12-3.

Figure 12-3. Cisco CallManager connects to the PSTN through a PRI-equipped media gateway router

Avaya's S8300 and S8700 softPBX chassis can connect to the PSTN in a more direct manner, using an onboard POTS or PRI interface. While the Avaya solution can certainly make use of a media gateway, say for trunking PSTN traffic back and forth to the softPBX over Ethernet, most Avaya chassis in the field are hosting PSTN trunks with onboard interface hardware. (You might have cause to use a gateway for PSTN trunks if the demarc is a great distance from the softPBX and you can use your IP network to overcome that distance.) (See Figure 12-4.)

An Asterisk server can also use either method. Digium's T1 and FXO/FXS interface cards give the Asterisk PC the ability to directly connect to PSTN trunks, while offboard gateway equipment lets you take a more distributed route. Figure 12-4 illustrates how an Asterisk server can use either approach. The dial-plan programming on the Asterisk server must be altered to support offboard gateways, of course, and those gateways must be programmed to route calls to the Asterisk server. For this reason, the preferred solution is to use onboard interfacing.

12.1.6. Channelized or Split-Use T1s

So far, we've talked about using T1s for voice dial-tone service from the CO, and we've talked about T1s for data: an IP point-to-point link for example. We've even covered getting your voice dial-tone service by way of VoIP on such a link. But what we haven't talked about is split-use service, which allows you to use a T1 for both.

Since a T1 circuit has 24 channels, most local phone companies will gladly group those channels into appropriately-sized pipes: one for Internet access service and the

Figure 12-4. Asterisk and Avaya softPBX servers support direct PSTN trunking as well as media gateways

other for dial-tone service from the CO. So, it's possible to have a T1 trunking your PBX to the CO with, say, 12 channels and linking your IP network to the Net with the other 12. This could save you money, because most LECs are also ISPs, and they sell Internet access at a discount if you're willing to bundle their local dial-tone service on the same circuit.

When connecting a T1 circuit from the smart jack to your DSU/CSU, router, or PBX, don't use a CAT-5 cable! Standard CAT-5 cables don't have the shielding needed by a T1. T1s will behave better if you use individually shielded twisted-pair cables instead. You can get these from any telecom supply catalog. Ask for a plain T1 cable.

12.1.7. Using the PSTN for Intraorganization Calls Leverage Centrex groups

Calls between lines on the same Centrex group are usually cheaper than calls made to destinations outside the Centrex group. If you have a couple of offices in the same vicinity, close enough to be members of the same Centrex billing arrangement (the same area code and phone company), you can use Centrex signaling to your advantage to connect them seamlessly. Have your users reach one another by Centrex four-dialing, which is "in-group," rather than having them use seven-digit dialing, which is "out-of-group." This will save money. Use dial-tone trunks to seamlessly route calls between PBXs in the same organization

Say we've got two separate offices, each with a PBX that has Centrex PSTN trunks. Let's also say that there's a ton of voice traffic between each of the offices because the workers are constantly calling one another. Now, let's say that the West office phones are numbered between 3400 and 3499, while the East office phones are all numbered 3000 to 3099 (see Figure 12-5).

Figure 12-5. 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 and 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 12-6. Direct inward dial could shorten this process, but the dialing user still wouldn't be able to reach his coworker using that convenient , four-digit extension.

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

But with a little bit of dial-plan setup on each of the two PBXs and a few PSTN trunks dedicated to the task, it's possible to allow users at the East office to dial users at the West office by their four-digit extensions. Each office will need a minimum of one PSTN trunk for this to work. Larger setups that require more concurrent calls will need more PSTN trunks. Project 12.2 explains how to set up four-digit dialing between PBX systems at different offices, making the convoluted process in Figure 12-6 disappear.

12.1.8. Project 12.2. Use PSTN Trunks in a Multioffice Dial-Plan What you need for this project:
  • Two or more Asterisk servers

  • Two X100P interface cards (one in each server)

  • Two SIP soft- or hardphones

  • LAN

In keeping with the example illustrated in Figures 12-5 and 12-6, we can build a two-office unified dial-plan using two Asterisk servers. This way, users need dial only the extension of the user at the other office in order to reach her. Asterisk will then route the call to the other office's PSTN trunk, wait until it's answered , and dial the recipient's extension in order to complete the connection.

We're assuming here that we have two Asterisk serversEast and West. We'll use the same dial-plan extension numbering convention as in Figure 12-6. Phones at the East office will be 3000-3099; phones at the West office will be 3400-3499. Have one SIP phone register with the East server and the other SIP phone with the West server:

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

The preceding is the SIP peer config for 3001 at the East office. Following is the SIP peer config for 3401 at the West office:

 # West office sip.conf     ...     [3401]     callerid="West User" <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 the default contexts of each. But they still can't call each other without dialing a lengthy PSTN phone number, waiting for the autoattendant, 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 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. Next, the 1 is the extension priority. Then, the Dial command tells Asterisk to dial the number of the other office on the Zap/1 channel and 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 3001-3099 to reach the users at East, and the users at East can dial 3401-3499 to reach the users at Westall without any PSTN dialing or autoattendant interaction. Here, the PSTN trunks are used like private trunks to connect two switches while the dial-plan makes it easy for the users. Controlling Caller ID when using PSTN trunks

In the previous 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 he is getting a call from the other office but won't know which user is calling.

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:

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

Asterisk's built-in variables , like EXTEN , are case-sensitive! ${EXTEN} works fine but ${exten} does not. User-defined variables, on the other hand, are case-insensitive.

Switching to VoIP
Switching to VoIP
ISBN: 0596008686
EAN: 2147483647
Year: 2005
Pages: 172

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: