System information

Controlling Responses
Responses are controlled with the dialplan. Whenever an incoming request matches
the dialplan configured for the mapping (whether the request is for a specific extension
or a pattern match), a response will be sent. If the request does not match within the
dialplan, no response is sent. In the example we’ve been building, the extension 1000
is the only extension that can be matched and thus generate a response.
In the next few sections we’ll look at some of the methods we can use to control what
requests are responded to.
Manually adding responses
The extensions.conf file handles what numbers you advertise and what you do with the
calls that connect to them.
The simple method to control responses is to simply add them manually to the [Regis
teredDevices] context. If we had several extensions at one of our locations, we could
add them all to that context:
[RegisteredDevices]
exten => 1000,1,NoOp()
exten => 1001,1,NoOp()
exten => 1002,1,NoOp()
The NoOp() dialplan application is used here because the matching and responding is
done only against the extension number, and no dialplan is executed. While we could
overload this context and cause it to also be the destination for our calls, it’s not rec-
ommended. Other reasons for using the NoOp() application should become clear as we
progress.
Using pattern matches
Of course, adding everything we want to respond with manually would be silly, espe-
cially if we wanted to advertise a larger set of numbers, such as all numbers for an area
code. As mentioned earlier, in our example we might wish to allow our Toronto and
Vancouver offices to call out from one another when placing calls that are free or cheap
to make from the other location.
We can respond with all of an area code using pattern matches, just as we do in other
parts of the dialplan:
[RegisteredDevices]
exten => _416NXXXXXX,1,NoOp()
exten => _647NXXXXXX,1,NoOp()
exten => _905NXXXXXX,1,NoOp()
516 | Chapter 23: Distributed Universal Number Discovery (DUNDi)