[asterisk-bugs] [Asterisk 0012193]: PARKINGEXTEN misbehaves when it is not a canonical form number and can double park or destroy the 700 entry

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=12193 
====================================================================== 
Reported By:                davidw
Assigned To:                jpeeler
====================================================================== 
Project:                    Asterisk
Issue ID:                   12193
Category:                   Resources/res_features
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     resolved
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 101988 
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             03-12-2008 06:53 CDT
Last Modified:              06-12-2008 10:40 CDT
====================================================================== 
Summary:                    PARKINGEXTEN misbehaves when it is not a canonical
form number and can double park or destroy the 700 entry
Description: 
If you set PARKINGEXTEN to "XXXX" it gets treated as 0.  (I think it would
also not be identiried as duplicate, if re-used, but I only have the
console at the moment.)

If you set it to "-1XXXX", it is handled correctly, with the exception
that it gets announced as minus one.

If you set it to "0700", it overwrites the system generated Park() line,
and removes it completely when the parking completes.

If you set it to "0701", it is treated as 701, however, I believe that it
would fail to detect the duplication and double park the call (I'd need two
phones, on the system I'm learning on, to demonstrate this other than by
code reading).

At some time, before the formal test run, I managed to get one with an
empty name created, which wouldn't go away, but I couldn't work out how to
reproduce that.

I will attach console traces, interleaved with the relevant extension.conf
lines.  Note that these traces also demonstrate a problem with returning
calls on timeout, which I intend to report separately.
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-12-08 10:40  svnbot         Status                   assigned => resolved
06-12-08 10:40  svnbot         Resolution               open => fixed       
======================================================================