Summary:ASTERISK-00635: DNIS routing ignores "i"nvalid extension in dialplan
Reporter:hex (hex)Labels:
Date Opened:2003-12-07 12:40:35.000-0600Date Closed:2011-06-07 14:10:44
Versions:Frequency of
Description:DNIS from PRI incorrectly ignores the 'i' extension in same context, but works OK when its dialed or context is target of a Goto.


I am using a T400P with ISDN PRI to the PSTN on one span, and channel bank on another span.  I added a couple lines in my dialplan to play a message when an invalid extension number (4 digit DNIS in this case) is dialed.  It works OK if I dial it from a phone on the channel bank in the same context, or if the context is the target of a Goto.

exten => i,1,Answer
exten => i,2,Playback(my-message)

Here's what happens if I dial in from the outside:

   -- Extension '1111' in context 'foobar' from '<MYPHONENUMBER>' does not exist.  Rejecting call on channel 2, span 1
   -- Hungup 'Zap/1-1'

However, if calling in via loop start locally...

   -- Sent into invalid extension '1111' in context 'foobar' on Zap/25-1
  -- Executing Answer("Zap/25-1", "") in new stack
  -- Executing Playback("Zap/25-1", "my-message") in new stack

Any ideas?
Comments:By: Brian West (bkw918) 2003-12-09 16:59:18.000-0600

we specifically have a way to reject a call in PRI for an invalid number. if you wants, you can setup a default rule
e.g. _XXXX to do it

it would *not* be a good idea for us to accept the call and send it to "invalid" on DNIS

By: Mark Spencer (markster) 2003-12-09 18:05:05.000-0600

Since PRI specifically provides a way to reject the call if you don't have a number, we use that rather than tell it it *is* a valid number and then send you to "i" extension.  You could make a wildcard match like this:


Or something along those lines.