[asterisk-users] Fixing an old bug related to extension "s" - feedback wanted

[Olle E. Johansson]

Friends,

While working with the manager interface, I noticed that an originate action to a non-existing extension had a strange behaviour. Instead of generating an error, which would happen in most VoIP channels and Dahdi, Asterisk started looking for extension "s" as a "fallback". 

For as long as I've worked with Asterisk, the definition of extension "s" has been that it is used when *NO EXTENSION* has been given (and in the macro command). There are two good examples - immediate answer in Dahdi and calling a SIP domain without a username part - like "sip:digium.com". In my trainings I always repeat (with a loud voice) that extension "s" is *NOT* a wildcard.

Obviously this behaviour is a bug. It's been around for a long time and has been hidden by most apps and channel drivers that handle a bad extension in a correct way and report errors before the PBX is started in order to handle the channel.

The question is - how do we fix this? There might be applications out there that depend on this buggy behaviour.

What I've proposed are two separate fixes:

1) Change the manager Originate action
================================

In Asterisk 1.8, there will be a warning if an extension given doesn't exist, but the behaviour will not change. A flag in Asterisk.conf [compat] section will be implemented so that you can change this behaviour and get an error response in manager if the extension does not exist.
In Asterisk 10 the error response will be the default behaviour. If an application using AMI needs a fallback, it needs to be controlled by the application. It needs to know that an extension does not exist and that the call can't be fulfilled.

2) Change the PBX core
===================

The bug actually exists in the PBX core, in ast_pbx_start(). We will not change this in Asterisk 1.8. 

In Asterisk 10, the core pbx will report that the extension does not exist and no longer fall back to s in current context or s at default. This will, as we see it now, not affect most channel drivers and thus most dialplans. If you rely heavily on the originate function (AMI, CLI and dialplan)  and use the fallback behaviour, you will need to modify your dialplans.

Final question
===========

My question now is what you think about these changes. Do you need a flag for Asterisk 10 to revert to the old behaviour? Is this bug something you actually rely on in your application?

Thanks for your response!

/O

----
Edvina SIP Masterclass covering SIP, Asterisk & Kamailio - Oxford, UK, Nov 7-11. *  http://www.telespeak.co.uk