Summary:	ASTERISK-03944: [patch] Allow incoming DIDs to be deflected to the "i" extension
Reporter:	Tilghman Lesher (tilghman)	Labels:
Date Opened:	2005-04-15 12:24:17	Date Closed:	2011-06-07 14:05:18
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20050415__invain_to_i_ext.diff.txt ( 1) chan_iax2-jump_to_i.diff.txt ( 2) jump_to_i.diff.txt
Description:	Currently, incoming numbers on a PRI which are not immediately matched by an extension are refused.  This behavior should be modifiable by including an "i" extension in that context, which should catch all DIDs not immediately mapped by the dialplan. Note that the legacy behavior can still be attained by not having an "i" extension in either the PRI context or any included contexts. ****** ADDITIONAL INFORMATION ****** Disclaimer on file.
Comments:	By: Matthew Fredrickson (mattf) 2005-04-15 13:17:33 How does this differ from the 's' extension?  IIRC, shouldn't any unmatched DIDs go to the s extensions automatically? By: Matthew Fredrickson (mattf) 2005-04-15 13:22:09 Ok, nevermind, found the discussion on the mailing list.  I see where this is going. By: Andrew Kohlsmith (akohlsmith) 2005-04-15 14:16:36 Is that the right way to do it?  I was just going to take your code and modify it for chan_iax2.c but I also see a ast_canmatch_extension() which looks like it might be more correct? By: Tilghman Lesher (tilghman) 2005-04-15 15:35:30 My reading of the code in pbx.c indicates that for this situation, ast_canmatch_extension() and ast_extension_exists() will return exactly the same result. By: Andrew Kohlsmith (akohlsmith) 2005-04-15 15:40:52 pbx.c was incorrectly jumping to 's' when an invalid extension was seen.  's' is only supposed to be hit when the extension called is blank, not nonexistant.  jump_to_i is a patch which corrects this. By: Andrew Kohlsmith (akohlsmith) 2005-04-15 15:46:20 the chan_iax2 diff basically checks for the existance of an 'i' extension as well when getting a request to set up a call. By: Andrew Kohlsmith (akohlsmith) 2005-04-15 15:52:27 just in case anyone is still unfamilliar with who I am, my disclaimer is already on file.  :-) By: Mark Spencer (markster) 2005-04-15 23:18:49 This patch has been submitted, and rejected, before.  Since PRI and IAX both supply a mechanism for rejecting an unknown number, it makes no sense to accept the call.  However, this behavior could be simulated by creating a _+ or similar extension in the dialplan. By: Andrew Kohlsmith (akohlsmith) 2005-04-16 01:47:52 Then why doesn't it work? If I call an invalid extension over IAX, I get DIALSTATUS=NOANSWER.  Hardly usable for any kind of failover situation, but perhaps I'm just not seeing something. As far as Zap goes, we're just trying to make things consistent.  From what I have been able to gather, the mere presense of an 'i' extension in the PRI channel's context should trigger this behaviour, and this is precisely what the patch (should) do.  If there is no 'i' then you get the default behaviour. By: Mark Spencer (markster) 2005-04-16 03:51:50 "i" is for handling an invalid extension dialed from the dialplan (e.g. from WaitExten / Background) only, not from the dialplan.  If you want to accept a call regardless of the extension dialed, you can use a wildcard. By: Tilghman Lesher (tilghman) 2005-04-16 09:02:31 I think really the issue here is that people don't like the implied behavior of a PRI which rejects calls, simply because they don't have an extension to catch it.  The presence of a greedy wildcard influences the dialplan in ways that many people simply find difficult to work with. Perhaps the solution would be for zaptel to check for a different extension (I suggest I [capital i]), but also also to create a new application Reject(), which allows administrators to explicitly reject calls, instead of relying on builtin behavior. Mark, what do you think of this (proposed) change?  Would that be an acceptable compromise? By: Andrew Kohlsmith (akohlsmith) 2005-04-16 09:34:46 Ugh.  Mark, we're trying to achieve a CONSISTENCY in the dialplan.  I realize what 'i' was ORIGNALLY for but how it is now is bloody confusing and to be honest, I fail to see the difference between an invalid selection in an IVR and an invalid extension being entered.  It's all dialplan.  It should be consistent. I'm trying very hard to see your point but I just don't see it.  The difference between an invalid extension being entered from Background or WaitExten and an invalid extension being requested on a new call is a very, VERY subtle one and it's bloody confusing to even people who have been using Asterisk for a very long time. I implore you -- what is so very important in making this distinction between an extension being entered once IN a call, and an extension being entered in MAKING a call?  Right now the only way to do anything with any invalid extension being called is in using _. and that's insanity, in my opinion. By: Kevin P. Fleming (kpfleming) 2005-04-20 11:31:36 I too agree with the posters here... I don't see a distinction between an invalid extension entered via a SIP phone (which already goes to the 'i' extension) and an invalid one entered via an IAX2 phone (which does not) or via a PRI. I think that in general once someone gets the concept of the 'i' extension they are going to expect it to be used consistently for all channel types. By: Brian West (bkw918) 2005-04-27 08:44:58 I have to agree here too.  i is a good thing.. also remove that stupid _. warning. :P /.b By: drmac (drmac) 2005-04-27 10:16:02 I agree with this too. We will soon be getting rid of our Class 4/5 switch and plugging all our providers' PRIs directly into asterisk. If for some dumb reason SBC/TW/XO decides to send me a call that my asterisk box doesn't handle, i'd like to be able to play a message using the 'i' context; because that call would be tecincally an "invalid" extension for us. Also, this might help in debugging since the call would appear in CDR wouldn't it? Once a month I could go in and see the calls that went into that context's 'i' extension then call upstreams and see if there is a problem. By: Kevin P. Fleming (kpfleming) 2005-04-27 11:42:40 Mark: I think the user community feels pretty strongly that the consistency this provides is very valuable... Even with SIP phones it's nice to be able to have invalid extensions the user dials go to 'i' for an intercept message, and right now we can't do that with IAX2 phones because they don't go there. Same would be true for an ISDN phone on the other side of a PRI, although that is very rare. By: Andrew Kohlsmith (akohlsmith) 2005-04-27 11:53:30 Well we really can get the best of both worlds...  If the peer does not have an 'i' extension things are exactly as they always were since 'i' is not being trapped: - IAX can return the proper causecode now (bug 4064) - PRI will reject the call with the proper causecode - SIP will do whatever SIP does (I think I need to adapt 4064 for it) and if 'i' *is* defined in the target context on the peer, the dialplan does whatever it's been instructed to do. I think the only 'gotcha' is if we dial 'i' on the peer -- we have no way of telling if we got to 'i' because it was defined or because it was invalid, but now that's just getting silly.  :-) By: Michael Jerris (mikej) 2005-05-23 22:59:20 Mark-  Can you please revisit your comments here and give it another look considering the overwhelming support for this. By: Michael Jerris (mikej) 2005-06-26 18:12:54 Can we have an update on this one way or the other.  This either needs to go in, or be closed. By: Michael Jerris (mikej) 2005-07-20 19:10:15 I am going to suspend this due to inactivity.  If anyone feels strongly enough about this, speak to mark or kevin about it and convince them, otherwise, there is no reason to keep this open.