Section 12.2. Routing PSTN Calls at Connect Points

12.2. Routing PSTN Calls at Connect Points

In the previous section, we covered using PSTN trunks to facilitate users in the same organization calling each other. The following projects describe ways of using PSTN connect points for elegantly interfacing your PBX to the PSTN. This includes setting up outbound rollover groups, using automatic call distribution (ACD) to intelligently handle incoming calls, and leveraging common PSTN trunk features like distinctive ringing.

12.2.1. Project 12.3. Grouping PSTN Trunks

12.2.1.1 What you need for this project:

• Asterisk

• Two or more X100P interface cards (or other Asterisk-compatible TDM cards)

Just as PSTN trunks are grouped together for billing, like a Centrex group, or for aggregation, like a hunt group , your PBX needs to deal with trunks in groups, too. For instance, on a large system, it isn't practical to dedicate the same POTS interface to dial-plan functions that require an outbound line (like outbound calling or bridging). In the prior project, that's how we configured it: interswitch Dial commands used the Zap/1 channel.

Fortunately, Asterisk allows you to group analog interfaces together so that it can select an available PSTN line from the group when the dial-plan calls for it. This frees you from having to dedicate PSTN lines to a single purpose, as in Project 12.2. All commercial PBXs support similar functionality.

Trunk groups are called outbound rollover groups, because they simplify programming of outbound dialing actions in the dial-plan.

In the Zaptel module's configuration file, zapata.conf , you can set up groups of channels that the Dial command can take as an argument where a single channel is required. The four ways the Asterisk dial-plan can address the trunk groups areas follow:

g

Use the lowest -numbered non-busy Zap channel in sequential order.

G

Use the highest-numbered non-busy Zap channel in sequential order.

r

Use the next higher channel than last time the group was invoked (sometimes called a rotary hunt group).

R

Use the next lower channel than last time the group was invoked.

Let's set up a sequential Zaptel group. Take a look at the following config bits from zapata.conf , which establish three Zaptel channels in a single group:

 context=default     signalling=fxs_ks     usecallerid=yes     echocancel=yes     group=1     callerid="X100P 1"<[phone]>     channel=>1     context=default     signalling=fxs_ks     usecallerid=yes     echocancel=yes     group=1     callerid="X100P 2"<[phone]>     channel=>2     context=default     signalling=fxs_ks     usecallerid=yes     echocancel=yes     group=1     callerid="X100P 3"<[phone]>     channel=>3 

With this config, group 1 is established using the three Zaptel channels that are provided by three separate X100P PCI cards. Once this is established, you can use the groups in the dial-plan using the Dial command. Here's an example that dials a PSTN-bound call on the group in sequential order ( g ):

 exten => _XXXXXXX,1,Dial(Zap/g1/${EXTEN}) 

In the previous project, we set up a two-switch dial-plan that used the PSTN to automatically call between the switches. These calls were always placed on the same channel, but we could've just as easily used a group like the one set up in this project:

 exten => _34XX,1,Dial(Zap/g1/5551340,35,mD(${EXTEN})) 

12.2.2. Project 12.4. Create an Automatic Call Distribution (ACD) Scheme Based on Area Code

12.2.2.1 What you need for this project:

• Asterisk

• A PSTN trunk connected and working

• Two or more soft or hard SIP phones

Automatic call distribution is a way of delivering incoming calls logically based on the time of day, the availability of users to answer, or perhaps the number of calls already answered by a certain user. So, if a particular user hasn't answered as many calls as another user , she might be more likely to receive the call, if that's what your ACD policy calls for.

There can be very elaborate ACD policies that route calls based on the availability of users with certain skills or in certain departments. These ACD policies are often tied to IVR applications that allow the caller to qualify his need so his call gets to the right person. Sometimes, inbound call are routed by caller ID. Area codes can be used to route calls to a user who is responsible for a certain geographic region, for example.

In this case, we'll set up a simple app that routes calls based on their area codes. This project will deal with three area codes216, 330, and 440, routing them to an appropriate extension. Consider the following configuration in extensions.conf :

 exten => 2216,1,Dial(SIP/201,30)     exten => 2330,1,Dial(SIP/202,30)     exten => 2440,1,Dial(SIP/203,30)     exten => s,1,areacode=${CALLERIDNUM:0:3})     exten => s,2,Answer( )     exten => s,3,GoTo(2${areacode},1)     exten => s,4,Dial(SIP/200,30) 

This configuration assumes SIP/201, SIP/202, and SIP/303 are already defined in sip.conf and working properly. The first exten directive establishes extension 2216, which will ring calls on the SIP/201 channel. The next exten directive establishes extension 2330, which will ring calls on SIP/202. Next, 2440 will ring calls on SIP/203. Notice that the extension numbers contain the area codes we're routing. This will make using the dial-plan to route them a snap.

In the next section, extension s , the default extension for incoming calls on Zap channels, is established. Its first priority is to store the area code in a variable called areacode . It does this by grabbing the first three digits of the caller ID number, which, in North America, is the area code. The syntax for this substring processing is very simple:

 ${VARIABLE:  first character  :  length  } 

Once the area code is stored, the next priority ( 2 ) of the s extension, is to answer the call. Finally, priority 3 sends the call to the extension represented by the expression 2${areacode} . If the area code is 216, the extension taking the call is 2216. If it's 330, the extension is 2330, and so on. Note the use of the GoTo dial-plan command, whose purpose is to send the current call to the extension provided in parentheses. That extension consists of a 2 and the area code, but in another config, you could make it be 10 and the area code, or some other expression.

Refer to Chapter 17 for the synax of the GoTo dial-plan command. You'll also find a more detailed description of Asterisk string processing.

Once the target extension springs into action, the appropriate SIP phone rings, and the call can be fielded. In large environments, this kind of caller ID-driven ACD app could send calls to ring groups instead of individual phones.

12.2.2.2 What if the call is from a different area code?

If the area code doesn't match any of the 2xxx extensions because it's coming from an area code other than the ones we've made provision for, the GoTo command in the s extension will fail, and the next priority for s will instead be used. In this case, give the call to SIP peer 200, which we'll say is the front-desk receptionist who could manually route the call. This functionality is important so that calls originating from area codes other that 216, 330, and 440 don't get categorically dropped by the Asterisk server.

12.2.2.3 What if the caller is using caller ID blocking?

The behavior will be as if the caller has provided an invalid area code, and the call will go to SIP peer 200.

12.2.3. Project 12.5. Use Distinctive Ring Detection

12.2.3.1 What you need for this project:

• Asterisk with verbose logging enabled

• A POTS or Centrex line connected and working

• Two or more soft or hard SIP phones

Distinctive ring is a feature offered by some phone companies that permits you to use two or three phone numbers with the same POTS line. Depending on which number was dialed , the ring signal will differ , causing the ring to sound unique for each number. This feature allows parents to avoid answering their teenagers' incoming calls. With a fax/voice ring switch device, distinctive ring can be used to inexpensively use a single line for receiving both fax and voice calls.

Distinctive ringing is a legacy signaling solution. That is, it works only with POTS. On VoIP trunks, such functionality would be handled by out-of- band signaling.

With Asterisk, distinctive ring can be used to automatically route calls from the PSTN trunk to the right phones. Or the distinctive ring can just be passed through to the phones on the private network, so that incoming PSTN calls cause them to ring distinctively, too.

Each Zaptel channel can be configured to detect up to four different distinctive signals. The first thing we'll need to do is open zapata.conf and add this configuration to the section for the trunk in question:

 usedistinctiveringdetection=yes 

Enabling distinctive ring on a Zaptel channel will cause a slight delay before Asterisk can answer incoming calls, because the distinctive ring signals can take up to 5 seconds for the Zaptel channel to detect.

The signals used by distinctive ring consist of analog electrical cadencesvariations in voltage that cause analog phones to produce certain ring patterns. Asterisk uses the dring attribute in zapata.conf to describe the signals. Unfortunately, these signals vary from one regulatory jurisdiction to the next, and you'll have to figure out what value to give dring attributes yourself.

Here's how. When an incoming call is received on a POTS interface, Asterisk records the ring pattern in Asterisk's verbose logging output. (If you haven't already enabled verbose logging, see Chapter 10.) Use the tail command with its -f option to watch your logfile for changes as they occur:

 tail -f /var/log/asterisk/full 

While tail is following the logfile, call each of the numbers that cause distinctive rings on your POTS lines. When the POTS interface senses the ring pattern, a log entry will appear containing Asterisk's representation of it: a string of digits has three values separated by commas. Each digit represents a duration of ringing, such that each ring pattern could have up to three rings of varying length in a 1- or 2-second timespan. The pattern repeats at regular intervals until the call is answered.

The string representing this pattern is used to supply a value to the dring argument in zapata.conf . Repeat this process until you've identified the strings needed for each of the phone numbers associated with your POTS line. Here's a sample config in zapata.conf that describes two distinctive ring signals and assigns them different contexts in the dial-plan:

 usedistinctiveringdetection=yes     dring1=325,95,0     dring2=95,0,0     dringcontext1=TedsCalls     dringcontext2=JakesCalls     channel =>1 

Distinctive ring features outside North America can use caller ID signaling instead of ring pattern signaling to indicate which phone number is being called. Check with your telephone company to see how it supports distinctive ring.

12.2.3.2 Routing based on distinctive ring

The Zaptel channel's configuration will tell Asterisk the context into which distinctively rung calls are sent. In this example, we've used a POTS line with two ring signals and two corresponding contexts. Now, we've got to create those contexts in the dial-plan. Here's a sample that accomplishes that in extensions.conf :

 [TedsCalls]     exten => s,1,Dial(SIP/201,30)     exten => s,2,Voicemail(201)     [JakesCalls]     exten => s,1,Dial(SIP/202,30)     exten => s,2,Voicemail(202)