[asterisk-bugs] [Asterisk 0006002]: [post 1.4] improper handling of contexts with same name

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=6002 
====================================================================== 
Reported By:                rizzo
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   6002
Category:                   Core/Configuration
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases): trunk 
SVN Revision (number only!): 7380 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             12-14-2005 15:39 CST
Last Modified:              03-05-2008 11:39 CST
====================================================================== 
Summary:                    [post 1.4] improper handling of contexts with same
name
Description: 
[I have put reproducibility=always because the problem is deterministic,
and severity=major because it is an undetected configuration error which
may result in serious and hard-to-detect misbehaviours of the dialplan.
Then, your mileage may vary]

When using regcontext=xyz where xyz is the name of a context already
existing in extensions.conf (or probably some other config file as well),
asterisk will create two instances of the context xyz.
However the extension lookup code will stop the search after the
first instance, thus resulting in unexpected results.

A stripped down example is below, where the _5. entry is in
exension.conf,
and the 551 entry is the result of regcontext=local-users regexten=551 in
sip.conf for a peer.

The source of the problem is that regcontext creates immediately
the empty context in the global list, whereas pbx_config later
builds contexts in a temporary list, then calling
ast_merge_contexts_and_delete() at line 1776 to merge the two lists.

Unfortunately the list merging only puts the local list in front of
the existing contexts, without checks for duplicates.

I have no idea on what is the proper fix, nor what is the behaviour
on a 'extension reload' or similar.

Surely, at the very least the code should produce a big warning message 
in case we found one such misconfiguration (i.e. multiple contexts with 
the same name), if merging the two is not possible or too expensive.

On a related topic: most functions that compare context names are
case-sensitive, however a few of them are not, e.g.
ast_context_create()
complete_show_dialplan_context()
__ast_context_destroy()
and possibly more.
Apart from the inconsistency that needs to be fixed, there is also
the issue that most of asterisk is case-insensitive when it comes to
names, so i think you should state clearly what is the policy
and why contexts are dealt with in a different way.


====================================================================== 

---------------------------------------------------------------------- 
 murf - 03-05-08 11:39  
---------------------------------------------------------------------- 
OK, I've published both intention and then completion of fixes to this bug
on the asterisk-dev, both of which letters got absolutely no response (deer
in the headlights?)

They are: 

http://lists.digium.com/pipermail/asterisk-dev/2008-February/032065.html

and:

http://lists.digium.com/pipermail/asterisk-dev/2008-March/032124.html

I have the fixes in team/murf/bug6002

Please review and test! I will commit these fixes to trunk soon if there
are no objections. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-05-08 11:39  murf           Note Added: 0083458                          
======================================================================