Section 12.1. Dial-Tone Trunks
12.1. Dial-Tone TrunksChoosing 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 TrunksPlain 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. 12.1.1.1 T1/PRI trunksWhile 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.
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. 12.1.1.2 ISDN BRI trunksSupporting 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. 12.1.1.3 VoIP trunksUsing 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.
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. 12.1.1.4 Hosted PBXA 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. 12.1.1.5 ATM trunksA 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. 12.1.1.6 Television cable and fiber trunksCable 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. 12.1.1.7 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
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. 12.1.2.1 The case for fewer trunksYou'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.) 12.1.2.2 The case for more trunksSome 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 Users12.1.3.1 What you need for this project:
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.
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).
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.
12.1.3.2 Home phone call bridgingNow, 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. 12.1.3.3 Time-based context includesYou'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 SizingT1 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.
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
12.1.5. Connecting Trunks to Your Telephone NetworkWhether 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 T1sSo 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.
12.1.7. Using the PSTN for Intraorganization Calls12.1.7.1 Leverage Centrex groupsCalls 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. 12.1.7.2 Use dial-tone trunks to seamlessly route calls between PBXs in the same organizationSay 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-Plan12.1.8.1 What you need for this project:
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. 12.1.8.2 Controlling Caller ID when using PSTN trunksIn 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}))
|
EAN: 2147483647
Pages: 172