[asterisk-bugs] [Asterisk 0016586]: features.conf auto-included park function sometimes included junk in Park() command

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16586 
====================================================================== 
Reported By:                DLNoah
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16586
Category:                   Applications/app_parkandannounce
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.0 
JIRA:                       SWP-707 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-01-12 09:20 CST
Last Modified:              2010-01-12 17:40 CST
====================================================================== 
Summary:                    features.conf auto-included park function sometimes
included junk in Park() command
Description: 
When using the included parking context from features.conf, or using an
Aastra phone with their built-in park softkey (which appears to call the
same built-in park, from what I can tell) in any version of 1.6.x that I've
used (including 1.6.0.9, 1.6.0.15, 1.6.1.0, 1.6.2.0), the Park() command
will sometimes but inconsistently include extra information--most commonly
a channel that was dialed by the parking phone.  In 1.6.0.x, the extra
information is simply ignored as Park() doesn't take parameters.  In
1.6.1.x and 1.6.2.x, Park interprets this information numerically (usually
as 0, since they generally start with a letter), which causes the call to
timeout immediately.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016406 Calls transfered to parking lot immedia...
====================================================================== 

---------------------------------------------------------------------- 
 (0116548) DLNoah (reporter) - 2010-01-12 17:40
 https://issues.asterisk.org/view.php?id=16586#c116548 
---------------------------------------------------------------------- 
When I have problems, it's if I'm parking using an attended transfer to my
features.conf parking extension *using the included parking context from
features.conf*.  

If I set up my own extension in the context my SIP phones are dialing
into, then it will call that extension and will park with the options I
set.

The Aastra phones have a Park softkey that will park via the features.conf
context, so they have the same problem with their Park softkey.

The problem I am having is definitely not consistently reproducible.  If
you sit at your phone constantly dialing (or transferring to) the parking
extension, you will have some of those dials look like:
-- Executing [170 at default:1] Park("SIP/100-b7e92170", "") in new stack

Which is what I expect it should be.  But as you keep going, you'll
eventually wind up with some sort of random gobbledy-gook passed to the
Park application.  It appears to me that the most reliable way to get the
extra information in the Park application is to place an outgoing call from
the phone, then park a call within a few minutes of placing that outgoing
call (and the extra information will have a string related to the outgoing
call you placed), but it's not 100% reproducible that way.  

If there's more testing type stuff you want me to do, let me know, but up
until about 2 days ago, I had thought this was an Aastra-softkey specific
problem.  I've had it ongoing for at least a couple months. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-01-12 17:40 DLNoah         Note Added: 0116548                          
======================================================================