Summary:ASTERISK-19723: Blind parking does not work anymore
Reporter:Michael Gaudette (bluefox)Labels:
Date Opened:2012-04-13 15:55:49Date Closed:2012-05-02 08:36:25
Versions: Frequency of
Environment:Attachments:( 0) features.conf
Description:Using multiple parking lots. Using 100 to park in my exemple
- Transferring (using a Polycom phone) normally (Transfert - 100 - Transfer) works
- Blind transfer (Transfer - blind - 100) doesn't.  The parkinglot exten is not recognized as if it wasn't part of the dialplan.

Yes it is relevant because although blind parking doesn't respond with the parking number, some users are using hints to tell them where calls were parked as opposed to waiting to hear it.

Regression bug as this worked perfectly in 1.8.10

Comments:By: Richard Mudgett (rmudgett) 2012-04-13 17:09:38.318-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks!

I suspect ASTERISK-19322 may have caused this.  A debug output with debug level 4 set should show what Asterisk is checking to see if it is a parking extension.  There should be a DEBUG line "Checking if %s@%s is a parking exten" in the output.

Please also supply your features.conf file to show how your parking lots are configured.

By: Michael Gaudette (bluefox) 2012-04-16 08:14:14.181-0500

The issue is 100% reproducible. I attached my features.conf file to this issue.  This is what happens on, did not happen on 1.8.9.x (don`t know about 1.8.10)

NOTE: I did find a pattern that may point to a problem being related to a dialplan processing change, not parking related. See note at the end

A call is received on a phone
The person blinds-transfers it into the parking lot (keyword: blind)
A fast busy tone is heard on the calling phone (not the one initiating the park, the other phone).

The phone`s context, simplified, is this:
include => parkingcustomera
include => someothercontext

exten => _XXX,1,noop()

IMPORTANT NOTE: The parking exten is 140. The pattern in someothercontext is _XXX, therefore they both overlap. This didn't create a problem in 1.8.9, as it prioritized the parkingexten over the generic _XXX pattern.

IMPORTANT NOTE 2: Removing "someothercontext" made blind parking work again! But that doesn't help as nothing else works.

It's not practical to ask me (or others) to change all my extensions. Was this change on purpose or an unforseen result of some other change?

By: Michael Gaudette (bluefox) 2012-04-16 09:04:34.770-0500

Just an additional comment: when NOT blind parking (transferring normally to a parking extension) the above problem does not appear. I would expect this change in extension priority to be reflected in both blind and normal parking of calls if it was as-designed.

By: Matt Jordan (mjordan) 2012-04-17 09:41:51.033-0500

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

As Richard requested, please provide a DEBUG log of at least level 4 illustrating the problem.

By: Matt Jordan (mjordan) 2012-05-02 08:36:12.580-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines

As noted by both myself and Richard, a DEBUG log is needed to resolve this issue.  If you can provide a DEBUG log, please contact a bug marshal in #asterisk-bugs and we will reopen this issue.