asterisk users - Oct 2012 - Recommendation for extension mapping on inbound T1 line

Converting this customer from a MiTel system to asterisk. Discovered 
that the inbound calls from the T1 are going to extension 366.  (This 
was mapped in the MiTel for some arcane purpose.)  The dial plan I am 
currently using is shown below.  When loading the dial plan, I get this 
warning:

  WARNING[5004]: pbx_config.c:1561 pbx_load_config: The use of '_.' for 
an extension is strongly discouraged and can have unexpected behavior.  
Please use '_X.' instead at line 331 of extensions.conf

Question: Do I need to worry about this warning?

I'm a little leery of just using 366 in the dialplan, since the company 
we are dealing with is a little flaky.


[from-pstn]
exten =>s,1,NoOp(pstn call from ${CALLERID(all)} exten=${EXTEN})
   same =>n,Goto(MainMenu,s,1)
exten =>_.,1,NoOp(pstn call from ${CALLERID(all)} exten=${EXTEN})
   same =>n,Goto(MainMenu,s,1)



-- 

Mitch

On Fri, Oct 12, 2012 at 9:10 AM, Mitch Claborn <mitch_ml at claborn.net>
wrote:
> Converting this customer from a MiTel system to asterisk. Discovered that
> the inbound calls from the T1 are going to extension 366.  (This was mapped
> in the MiTel for some arcane purpose.)  The dial plan I am currently using
> is shown below.  When loading the dial plan, I get this warning:
>
>  WARNING[5004]: pbx_config.c:1561 pbx_load_config: The use of '_.'
for an
> extension is strongly discouraged and can have unexpected behavior.  Please
> use '_X.' instead at line 331 of extensions.conf
>
> Question: Do I need to worry about this warning?

On Friday 12 October 2012, Mitch Claborn wrote:
> Converting this customer from a MiTel system to asterisk. Discovered
> that the inbound calls from the T1 are going to extension 366.  (This
> was mapped in the MiTel for some arcane purpose.)  The dial plan I am
> currently using is shown below.  When loading the dial plan, I get this
> warning:
> 
>   WARNING[5004]: pbx_config.c:1561 pbx_load_config: The use of '_.'
for
> an extension is strongly discouraged and can have unexpected behavior.
> Please use '_X.' instead at line 331 of extensions.conf
> 
> Question: Do I need to worry about this warning?
You only need to worry about it if  (1)  you are using non-numeric extensions 
anywhere in your dialplan and  (2)  another context includes the
"from-pstn"
context or something might jump into it.

If  (and only if)  all the extensions you are using in all your contexts are 
numeric, then "_." is fine.  (But you don't really need it anyway
in your
example, since the "s" extension in your from-pstn context will
already catch
the incoming call.)

*But* some hardware specifically expects to work with non-numeric extensions -- 
I know from bitter experience that the OpenVox G400P/E cards do.  If you later 
install one of these cards, it will want to call extension "sms" when
a text
message comes in, and either "sms_send_ok" or
"sms_send_failed" when a text
has been sent.  If you specify the wrong context in your chan_extra.conf  (and 
Sod's Law says you *will* do that at first, while you're setting it up),
one
of these could potentially match against "_." -- which probably is not
what
you want. 
> I'm a little leery of just using 366 in the dialplan, since the company
> we are dealing with is a little flaky.
That's quite sensible!  Some telcos do some really counter-intuitive things.
If you have only one number for all incoming calls, a catch-all is fine.
> [from-pstn]
> exten =>s,1,NoOp(pstn call from ${CALLERID(all)} exten=${EXTEN})
>    same =>n,Goto(MainMenu,s,1)
; you don't really need the following 2 lines:
> exten =>_.,1,NoOp(pstn call from ${CALLERID(all)} exten=${EXTEN})
>    same =>n,Goto(MainMenu,s,1)
If you later decide to set up direct dial-in lines, and route calls depending 
on the dialled number, then you will have to do something a bit more 
sophisticated, obviously.  But cross that bridge when you come to it  :)

-- 
AJS

Answers come *after* questions.