[Asterisk-Users] Question about x100P and zap

[Hall, Eric M.]

Skipped content of type multipart/alternative-------------- next part --------------
[general]
static=yes       ; These two lines prevent the command-line interface
writeprotect=yes ; from overwriting the config file. Leave them here.
;
;
;
[from-sip-external]
;
; Take unknown callers that are sending calls to our system,
;  and send them to the appropriate extension.  It is in this
;  area that we do name-to-number mapping for SIP extensions.
;
; This context will allow calls to "2000 at this.host.com" or calls
;  to "2001 at this.host.com" to be answered on the relevant SIP
;  phones.  We also do some name-to-number mapping here; see below.
;
; The SIP URI of sip://sidney@this.host.com  will be handled here.
;  Note that we assume Sidney is on the SIP phone described as 
;  extension "2000" in sip.conf, so this short routine just
;  re-directs the call flow recursively back into the same
;  context, but we change the extension and priority.  Since
;  we're including [local-extensions], this will get picked up
;  by the dialplan contained in local-extensions.
;
; I could be more space-efficient and put all these lines into
;  a single regexp, but for clarity I put them each on their
;  own lines.
;
; Here are Sidney's aliases
;
exten => sidney,1,Goto(2000,1)
exten => sidney.zweibel,1,Goto(2000,1)
exten => info,1,Goto(2000,1)
;
; ...and John's aliases.
;
exten => john,1,Goto(2001,1)
exten => john.whorfin,1,Goto(2001,1)
exten => sales,1,Goto(2001,1)
;
;
; Include the numbers which we have defined in local-extensions
;  and allow them to be accessed from within this context.  This
;  is how we are able to use the "Goto" commands above, since
;  we will be including extensions 2000 and 2001 (and 0 and 2999)
;  as available extensions to which we may re-route calls within
;  this context.
;
include => local-extensions
;
; If the line hangs up, it's always good to have the "h" 
;  extension in each context that is the "master" handler
;  for calls.  This cleanly exits and closes dial path routes.
;
exten => h,1,Hangup
;
; The user has dialed an "i"nvalid number, which means that
;  there was no match by any other matching routines.  Set an
;  absolute timeout on the call (15 seconds), play a Congestion
;  tone, and hangup.  We set the absolute timeout to prevent easy
;  DoS attacks from consuming too much bandwidth.  However, it
;  is possible that we could still be attacked in some fashion 
;  by someone making many calls to bogus numbers on our server.
;  We could reduce this threat by removing the Congestion
;  playback and going straight to hangup, but that is very 
;  difficult to debug at the remote end, so we are good VoIP
;  citizens and we create some audio if the call reaches us.
;
exten => i,1,AbsoluteTimeout(15)
exten => i,2,Congestion
exten => i,3,Hangup
;
;
;
[from-sip-internal]
; Calls that come in from our two SIP phones will land here
;  first and match against extensions listed below.
;
; The context [from-sip-internal] is really just a collection
;  of include statements that pull the extension matching lists
;  in from other contexts.  A well-designed dialplan segregates
;  extensions with similar functions into contexts, and then
;  uses the "include" referencer.  This should be a familiar 
;  concept to anyone who does programming - segmenting a block
;  of phone numbers makes them more re-usable in a generic way
;  so that the administrator can avoid re-typing the same configs
;  over and over.
;
; First, we include [local-extensions], since that's what
;  we should try matching on first.  If anyone on one of our
;  local SIP phones dials an extension that appears in
;  [local-extensions], then send the call to whatever priority
;  list exists for that number.  This is for local-to-local call
;  termination.
;
include => local-extensions
;
; Next, we include and try to match against extensions contained
;  in [always-out-pots].  These are mostly wildcarded matches,
;  so we make sure to put them second when we list our "include"
;  statements, since Asterisk will process the matching lists in
;  a predictable way ONLY based on the order in which multiple
;  contexts are included in some other context.  This is an important
;  point, since often dialplans will contain a "catch-all" at the
;  bottom of the matching list.  If that "catch-all" (usually
;  something like "_X."  or "_.") is just jumbled in with the rest
;  of the extensions, then it may be matched FIRST, which would
;  be opposite of the desired effect.  Any time it is the case that
;  you have possible overlapping extension matches in a context,
;  you should order them by creating multiple sub-contexts and
;  using the "include =>" method to order them in the right sequence.
;
include => always-out-pots
;
; Include the "local" numbers which we want to send out our
;  POTS line since they don't cost us anything.
;
include => local-calls-pots
;
; Include the long-distance matching lines to hand off calls to non-
;  local area codes and international dialing.
;
include => ld-calls
;
; As usual, include "h"angup and "i"nvalid extensions to allow for
;  appropriate handling of those two cases.
;
exten => h,1,Hangup
exten => i,1,Congestion
exten => i,2,Hangup
;
;
;
[always-out-pots]
;
; The [always-out-pots] context is where we store numbers that will
;  always go out the local analog POTS connection.  When working
;  with any priority list for these numbers, it is important to 
;  remember that if the POTS line is unavailable for some reason
;  (such as the line not being connected to the card) then the
;  Zap drivers will force the call to go to the next priority.
;  In our case, there is no "next-best-path" for things like 911
;  or 411, so play a congestion tone which should indicate to the
;  caller that the system is unavailable for their use.  Just
;  like any other PBX, if it's not connected to the outside world,
;  calls outbound won't work.
;
; In all of the examples below, we use the "Zap" technology 
;  specifyer (analog) and select channel "1", since we only have 
;  one channel in this particular computer (a single Digium X100P 
;  FXO card.)  In a situation where there are multiple cards or
;  channels, a "group" could be created in the zapata.conf file
;  that allows the call to be sent to the group, and Asterisk will
;  choose the first available channel automatically.
;
; Calls to 911, 411, 511, etc. are all handed off to the local
;  analog channel.  The "X" matches any digit, so 911/411/511 etc.
;  are handed to the local provider of those services.
;
; Each number matching sequence contains an priority chain at
;  priority 102.  See the explanation in section [local-calls-pots]
;
; We NEVER fail these calls over to the IPCSP account, since the
;  IPCSP almost never has the correct location to which to send calls
;  for 911, 411, etc.  There is work towards solving this problem, but
;  most IPCSP's are still some months away from implementation.  In
;  the meantime, always hand these numbers off to the POTS line.
;
exten => _X11,1,Dial(Zap/1/${EXTEN})
exten => _X11,2,Congestion
exten => _X11,3,Hangup
exten => _X11,102,Congestion
exten => _X11,103,Hangup
;
; Make sure if the user dials the external line seizure number that
;  the calls is handled in the same way, but strip off the leading 
;  "9" from the ${EXTEN} variable because the local POTS system
;  won't know how to deal with it.
;
exten => _9X11,1,Dial(Zap/1/${EXTEN:1})
exten => _9X11,2,Congestion
exten => _9X11,3,Hangup
exten => _9X11,102,Congestion
exten => _9X11,103,Hangup
;
; Send calls out to the operator if the user has indicated that they
;  want to talk to the PSTN operator.  Note that we grab "0" by itself
;  in the [local-extensions] context; this is for outside operator 
;  requests only.
;
exten => _90,1,Dial(Zap/1/${EXTEN:1})
exten => _90,2,Congestion
exten => _90,3,Hangup
exten => _90,102,Congestion
exten => _90,103,Hangup
;
;
; So, we should also always provide an "escape" route for our
;  users so that they can call out on the local analog line in
;  the way that they expect.  Most office phone systems have "9"
;  as the "seize external line" prefix.  Since SIP phones
;  take their dial strings all at one time, there is no secondary
;  dialtone that the user will hear; they should just dial the
;  number like "914155551212" on their SIP phones, without waiting
;  for a second dialtone.
;
; We match on any number that begins with a "9" and is 7 or more digits,
;  which is the minimum we need for a standard phone call.  The "." 
;  stands for "zero or more digits"
;
exten => _9XXXXXXX.,1,Dial(Zap/1/${EXTEN:1})
;
; If we get an "out of service" or busy signal error on the
;  attempt, send a fast busy to the user and hangup.
;
exten => _9XXXXXXX.,2,Goto(102)
;
exten => _9XXXXXXX.,102,Congestion
exten => _9XXXXXXX.,103,Hangup
;
;
;
[local-calls-pots]
; This next section is a tricky part.  Each phone company in the US 
;  seems to have different rules about how you can or cannot dial
;  a local number.  The concept of local numbers is one that is 
;  going the way of the dinosaur, and only in rural areas does
;  the concept of a single non-overlapping area code still exist.
; That being said, our imaginary example here has a phone company
;  that requires all local numbers to be ten digits (area code plus
;  seven digit prefix/subscriber number.)  HOWEVER, we are going to
;  be responsible members of the e.164 world community, and force
;  users to dial a "1" in front of all numbers.  This will make 
;  some people complain, especially if they're used to just dialing
;  the seven-digit prefix/subscriber number (123-4567) or if they
;  aren't used to dialing the "1" in front of the area code.  Well,
;  they should get used to it - that is the way the dialing plan
;  in North America is moving, and it eliminates huge tables for
;  the phone administrator.
;
;
; First, we want to hand off numbers that are "local" to our POTS 
;  line to the X100P board and subsequently to the local phone system.
;  Our area code in this hypothetical example is "614", so we'll 
;  match any numbers dialed that start with 1614 and strip off the 
;  leading digit (:1) and pass it to the Zap channel driver (POTS line.)
;  We don't have a dial time limit on this, nor are we passing any
;  special settings to the Dial statement; this is an extremely simple
;  invocation of "Dial".
;
; If we get a "Busy", jump to 102 - see notes there for why and how
;  this jump happens.
;
exten => _1614XXXXXXX,1,Dial(Zap/1/${EXTEN:1})
;
;
; Now, what if the Zap line is showing an error?  Asterisk has some
;  error routines that allow for failover if a particular channel
;  is unavailable due to an error.  If the line is disconnected,
;  then Asterisk will increment the priority counter by 1, and 
;  continue.  


; In the case of a failure on our first dial attempt, we'll try handing
;  off the call to the IPCSP account, since something is wrong with
;  our local POTS line.  Note that we hand off the whole number,
;  including the leading '1', since iconnecthere expects a fully
;  qualified e164 address (country code, area code, prefix, subscriber)
;  such as 16145551212
;
; If this second attempt results in an error, jump to 103  
;
exten => _1614XXXXXXX,2,Dial(SIP/${EXTEN}@iconnecthere-1)
;
; If we get an error on the dial to the IPCSP, just give up.
;  This means we've tried both the analog like and the IPCSP,
;  but both have given us "out of service" errors.  
;
exten => _1614XXXXXXX,3,Goto(203)
;
;
; There are two kinds of errors that may be given back by the Dial
;  statement.  The first is a generic error, which jumps to +1 in 
;  the priority list.  The second type of error is the "Busy" error
;  which will jump to +101 from the current priority.  "Busy" may
;  is a misleading term - if there is no dialtone on the line, that
;  is considered "Busy", along with several other circumstances.
;
; We are faced with the problem that if the statement at priority 1 
;  gets a busy, it will jump to 102, and now also if priority 2 gets
;  a busy, it will jump to 103.
;
; I personally dislike the +101 auto-jump syntax; it's a kludge, but to this
;  point nobody has submitted a better patch to handle Dial results.
;
;
exten => _1614XXXXXXX,102,Dial(SIP/${EXTEN}@iconnecthere-1)
;
; We get to priority 103 either because priority 2 got a "busy"
;  error, or because priority 102 got a "not in service" error.
;  In either case, we want to jump to 203, which is the end of
;  the road.
;
exten => _1614XXXXXXX,103,Goto(203)
;
;
; Priority 203 is where we go if we've tried everything and it all
;  didn't work.  Jumps get to 203 via a +101 leap from priority 102,
;  or from explicit "Goto" calls elsewhere.
;  We play a congestion tone (fast busy) then hang up.
;
exten => _1614XXXXXXX,203,Congestion
exten => _1614XXXXXXX,204,Hangup
;
;
;
; We re-do the prior match, but slightly modify it for those very 
;  annoying phone companies that force you to dial a "1" in front
;  of only certain exchanges.  The user would dial "116143334444" to
;  call those exchanges.  This sounds pretty unpleasant, and it is.
;  However, until all phone companies standardize on 1+ten-digit 
;  dialing, this will be an issue.  Really, the only difference
;  between this small matching set and the "1614XXXXXXX" matching
;  set is that we clip a digit off of the dialed strings when
;  we send the call to our IPCSP.  When we dial via the Zap analog
;  interface, we clip off only one of the two leading "1"'s when
;  we pass the ${EXTEN} to the channel.
;
; Another way to get around this would be to build a big table 
;  of all "non-local" exchanges and then match on those exchanges,
;  and add a "1" to the dialing string.  That is beyond the 
;  scope of this example...
;
;exten => _1614XXXXXXX,1,Dial(Zap/1/${EXTEN}:1)
;exten => _1614XXXXXXX,2,Dial(SIP/${EXTEN}:1 at iconnecthere-1)
;exten => _1614XXXXXXX,3,Goto(203)
;exten => _1614XXXXXXX,102,Dial(SIP/${EXTEN}:1 at iconnecthere-1)
;exten => _1614XXXXXXX,103,Goto(203)
;exten => _1614XXXXXXX,203,Congestion
;exten => _1614XXXXXXX,204,Hangup
;
;
;
;
[ld-calls]
;
; Here is where we define any other calls outbound from the system
;  that seem to be using NANP numbers.  If the iconnecthere.com 
;  system fails, then send the call out the analog line.  It is
;  perhaps the case that an audio hint should be played if the call
;  fails to go out via the SIP long distance provider and uses the
;  more expensive analog line, but that can be added later if desired.
;
exten => _1XXXXXXXXXX,1,Dial(SIP/${EXTEN}@iconnecthere-1)
exten => _1XXXXXXXXXX,2,Dial(Zap/1/${EXTEN})
exten => _1XXXXXXXXXX,3,Hangup
exten => _1XXXXXXXXXX,102,Dial(Zap/1/${EXTEN})
exten => _1XXXXXXXXXX,103,Hangup
exten => _1XXXXXXXXXX,203,Hangup
;
;
; And do the same for calls that are prefixed with the international
;  dialing code of "011"
;
exten => _011XXXXXXXXXX,1,Dial(SIP/${EXTEN}@iconnecthere-1)
exten => _011XXXXXXXXXX,2,Dial(Zap/1/${EXTEN})
exten => _011XXXXXXXXXX,3,Hangup
exten => _011XXXXXXXXXX,102,Dial(Zap/1/${EXTEN})
exten => _011XXXXXXXXXX,103,Hangup
exten => _011XXXXXXXXXX,203,Hangup
;
;
;
[local-extensions]
; The "local-extensions" context used to be called "from-sip" in
;  the first example article.  Other than the name change, it is 
;  identical.  The comments have been removed for brevity.
;
exten => 2000,1,Dial(SIP/2000,20)
exten => 2000,2,Voicemail(u2000)
exten => 2000,102,Voicemail(b2000)
exten => 2000,103,Hangup
;
exten => 2001,1,Dial(SIP/2001,20)
exten => 2001,2,Voicemail(u2001)
exten => 2001,102,Voicemail(b2001)
exten => 2001,103,Hangup
;
exten => 2999,1,VoicemailMain($CALLERIDNUM)
;
exten => 0,1,Goto(2000,1)
;
;
;
[from-analog]
;
; The [from-analog] context deals with calls coming in from 
;  the Zap card.  Since the Zap card doesn't "know" what number
;  is attached to it, we use the "s" extension to handle all inbound
;  calls.  Caller ID tells us who is calling, but Asterisk uses
;  the concept of what number was _called_ as the primary matching
;  criteria in the dialplan.  Since all we know is that there is 
;  a call coming in on the analog line, we have to just use the
;  "default" value of "s" as our matching criteria.  (Note: Asterisk
;  can in fact use the Caller ID as a match method, but we won't 
;  cover that in this example.  See the "ex-girlfriend" portion
;  of the Asterisk manual.)
;
; We're going to install a nice little trick in here that nabs
;  telemarketers.  What it does is look for any call on the channel
;  that does NOT have a valid caller ID (or caller ID is "blocked")
;  Then, a pleasant voice asks for the person to enter in a valid
;  ten digit caller ID.  If they fail three times, it hangs up.
;  I have stopped about 90% of the telemarketing calls on my home
;  line with this trick.
;
exten => s,1,PrivacyManager
;
;
;  We could also put an auto-attendant here, or a menu system, or
;  any number of other tools.  However, this is going to be kept as 
;  a simple demo.  We just ring both office lines.
;
; Now, this is pretty simple.  We ring both extension 2000 and 2001
;  at the same time, and whoever answers first gets the call. If there
;  is no answer after 30 seconds, then send the call to voicemail with
;  the unavailable message. If both phones are unavailable, send the
;  call to the busy message.  The voicemail box we use is John Whorfin,
;  since he is the manager responsible for answering messages.  It is 
;  possible to define a "company" mailbox, and then send the calls
;  there instead of to a particular person if one chose to do that.
;
exten => s,2,Dial(SIP/2000&SIP/2001,30)
exten => s,3,Voicemail2(u2000)
exten => s,4,Hangup
exten => s,103,Voicemail2(b2000)
exten => s,104,Hangup
;
;
; Always put these two extensions in any "main" context that handles
;  call processing, for good form and graceful hangups.
;
exten => i,1,Hangup
exten => h,1,Hangup