Creating a Dialplan

exten => _91NXXNXXXXXX,3,Congestion

exten => _91NXXXXXX,1,Dial(Zap/g1/${EXTEN:1}) exten => _91NXXXXXX,2,Dial(Zap/g2/${EXTEN:1}) exten => _91NXXXXXX,3,Congestion

include => local [local]

exten => _9NXXXXXX,1,Dial(Zap/g2/${EXTEN:1}) exten => _9NXXXXXX,2,Dial(Zap/g1/${EXTEN:1}) exten => _9NXXXXXX,3,Congestion

Let's take a quick look at what we have. We can now place handsets in the local or longdistance context. This gives us a good bit of security, but there is one small problem. Do you see it? If we put our users into either context, they cannot dial internal extensions. Assuming we allowed calling our local extensions in the default context, we should update the local context like so:

[local]

exten => _9NXXXXXX,1,Dial(Zap/g2/${EXTEN:1}) exten => _9NXXXXXX,2,Dial(Zap/g1/${EXTEN:1}) exten => _9NXXXXXX,3,Congestion

include => default

By so doing, we give access to the extensions for the local context. We also give access to the default context for those in the longdistance context because longdistance includes local, which in turn includes default.

Thus, we must be very careful about what we include. When we include any context, we are in turn including all contexts it includes. It is easy to include our way out of the security we set up!

Advanced Call Distribution

What exactly is Advanced Call Distribution? Many phone systems tout this feature, but most do not adequately define what it means. Basically, it refers to using call queues, parking calls for another user to answer, and Direct Inward Dialing (DID).

So that we keep our focus, we will look at each of these elements individually.

Call Queues

In Chapter 4, we configured call queues, through the /etc/asterisk/queues.conf file. As we go through how we're going to use our queues, we may decide we want to change the way our queues are configured. There is absolutely no problem with changing the configuration so that it more accurately reflects our needs. Just remember that we need to issue a reload on the Asterisk console, or type #asterisk –r –x reload at the command line.

The power and flexibility of other ACD systems can be matched or exceeded by Asterisk. As we evaluate our needs, we should remember that configuring a single aspect of Asterisk sometimes requires changes to more than one file. For example, queues will be

78

Chapter 5

configured both in the queues.conf file and the extensions.conf file. Since we have already discussed the queues.conf file in Chapter 4, we will discuss how to set up extensions.conf to give us the desired result.

When dealing with call queues, we need to think about the two types of users we have. First, we have the caller who calls in and waits in the queue for the next agent. We can think of this person as our customer. Next, we have the agents who work the queue. We can think of these people as our users.

As a business, we have to decide what we want our customers' experiences to be. Our call queue can make it sound like a phone is ringing. Or we can use music on hold while the customer waits. We can also announce call position and estimated wait time if we want to.

When we place customers in a queue, we use the Queue application. To place a caller in the queue named bob, we would use something like:

exten => 1000,1,Queue(bob)

Suppose we have an operator's extension. Since Ollie the Operator may have more than one call at a time, we decide to give him a call queue. His calls are always about a minute long. The customers waiting for him are going to there because they got lost in a system of menus. His queue will be named operator.

In this instance, we will choose to have the customer hear ringing so they will believe they are about to be helped. The sound of ringing should not last more than about a minute. We will not announce call queue length because our customer should not know that he or she is in a queue.

The entry for this queue would be:

exten => 0,1,Queue(operator|tr)

Notice our use of options. Options for the queue application include

•t: Allow the user to transfer the customer.

•T:T Allow the customer to transfer the user.

•d: This is a data-quality call.

•H: Allow the customer to hang up by hitting *.

•n: Do not retry on timeout. The next step in the dialplan will be executed.

•r: Give the customer the ringing sound instead of Music on Hold.

Thus, we told the Queue application to give the customer ringing, and the user (Ollie) the ability to transfer calls (since he's the operator).

Now, suppose we have Rebecca, the receptionist. Rebecca is at SIP phone 1006. When Ollie goes to the bathroom, we want our poor lost customers to be routed to her. So we could use the following in our extensions.conf file:

exten => 0,1,Queue(operator|trn) exten => 0,2,Dial(SIP/1006)

79

Creating a Dialplan

Now Rebecca had better answer this. Until she does, the phone will continue to ring. Notice that this call will never end up in Rebecca's voicemail, as it is not transferred to her extension, but instead dials her phone directly.

We have adequately addressed the customer's experience. But now we need to look at how our users will join and leave the queue. Previously, we discussed the power and flexibility of using Agents in queues. As with most things in Asterisk, there are many ways we can associate members to queues. The three main ways are statically, dynamically, and using agents.

Our first option is to have members statically assigned to the queue. To do this, we use the member directive in the queues.conf file. This is most helpful when we have a queue with fixed members, such as a switchboard queue.

Our second option is to allow members to log in dynamically. We do this through the AddQueueMember application. An example of this would be:

exten => 8101,1,AddQueueMember(myqueue|SIP/1001)

Whenever anybody dials extension 8101, the telephone handset SIP/1001 would be added to the queue named myqueue. All that we would have to do is define a login extension for every member of every queue.

What happens when this member no longer wishes to be in the queue? We use the RemoveQueueMember application, like this:

exten => 8201,1,RemoveQueueMember(myqueue|SIP/1001)

With this configuration, whenever anybody dials extension 8201, the telephone handset at SIP/1001 is removed. Again, we would have to define a logout extension for each member of the queue.

Suppose we did not wish to have to define a login and logout extension for each member. We have the option of leaving off the interface (SIP/1001 in the above example) and having Asterisk use our current extension. While this is very useful, Asterisk does not always use the right value. However, if it works for all extensions that need to be in the queue, we would only have to define one login and one logout per queue. The code would look like:

exten => 8101,1,AddQueueMember(myqueue) exten => 8201,1,RemoveQueueMember(myqueue)

This is better than having to define a login and logout for each member of each queue, but sometimes users are not good about remembering multiple extensions to dial. The AddQueueMember application will jump to priority n+101 if that interface is already a member of the queue. Therefore, we could define an extension like:

exten => 8101,1,Answer

exten => 8101,2,AddQueueMember(myqueue) exten => 8101,3,Playback(agent-loginok) exten => 8101,4,Hangup

exten => 8101,103,RemoveQueueMember(myqueue)

80

Chapter 5

exten => 8101,102,Playback(agent-loggedoff) exten => 8101,105,Hangup

When we define it this way, a user dialing extension 8101 is logged in if not already a member of the queue, or logged out if in the queue. Also, we added a confirmation to the action, so that the user can know if they are now in or out of the queue. Notice that before we could use the Playback application, we had to answer the call. If we have a lot of these, we could define a macro extension, like:

[macro-queueloginout] exten => s,1,Answer

exten => s,2,AddQueueMember(${ARG1}) exten => s,3,Playback(agent-loginok) exten => s,4,Hangup

exten => s,103,RemoveQueueMember(${ARG1}) exten => s,104,Playback(agent-loggedoff) exten => s,105,Hangup

. . .

[default]

exten => 8101,1,Macro(queueloginout|queue1) exten => 8102,1,Macro(queueloginout|queue2) exten => 8103,1,Macro(queueloginout|queue3)

And thus we see that using a macro will save us five lines in our extensions.conf for every queue after the first. This is how we can add queue members dynamically.

Our final option for adding queue members is by using Asterisk's agent settings. We were able to define agents in /etc/asterisk/agents.conf. We create an agent by defining an ID and a password, and listing the agent's name.

In the queues.conf, we could define agents as members of queues. Calls will not be sent to agents unless they are logged in. In this way, queues can be both dynamic and static: they are static in that we do not change the members of the queues, but dynamic in that calls will go to different handsets based upon which agents are logged in.

There are two main types of agents in this world. There are the archetypical large call center agents who work with a headset and never hear ringing, and there are the lowervolume agents whose phone rings each time a call comes in. Asterisk has the flexibility to handle both types of agents, even in the same queue.

First, imagine a huge call center that takes millions of phone calls per day. Each agent is in multiple queues, and we have set each queue to use an announcement at the beginning of calls to let the agent know which queue the call came in from. As employees arrive for their shift, they sit down at an empty station, plug in their headset, and log in. Each employee will hear music in between calls, and then hear a beep, and the call will be connected. To accomplish this, we use the line:

exten => 8001,1,AgentLogin

Through the normal login, the call is kept active the whole time. The agents will logout by hanging up the phone. This allows large call centers to be quieter, as the distraction of ringing phones will be removed. It also allows for more efficient answering of lines, as the time required to pick up the phone is eliminated.

81