asterisk users - Sep 2011 - Fixing an old bug related to extension "s" - feedback wanted

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

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Olle E.
Johansson
Sent: Tuesday, September 20, 2011 4:23 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] Fixing an old bug related to extension "s" -
feedback wanted

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

Just my .02 - fix Originate since the "Original Asterisk" book, page
125
paragraph 1 says "s" = "start".  If "s" is not
really "start", I'm going to
scrap my 3+ years of dialplan writing and change all of my simple dialplans
to read exten=> start,1,blah instead of exten => s,1,blah.  To me
exten=>
s,1,blah is more intuitive and less vulnerable than exten => _X.,1,blah.