[Home]

Summary:ASTERISK-22800: Dynamic parking pickup doesn't use PARKINGLOT
Reporter:David Cunningham (dcunningham)Labels:
Date Opened:2013-10-31 20:00:37Date Closed:2013-11-18 10:30:05.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Features/Parking
Versions:1.8.12.2 Frequency of
Occurrence
Related
Issues:
Environment:CentOS release 5.8 64 bitAttachments:( 0) park1.log.gz
Description:When picking up a call from a dynamically created parking lot, specified with the PARKINGLOT variable, the wrong call is picked up.

A full trace is attached. The call flow is:

1. External caller 0000101 called 0234567890 which routed to telephone 2000105.
2. Telephone 2000105 parked the call using #*7 on lot park_4, slot 701.
3. Telephone 1000102 called 1000101.
4. Telephone 1000101 parked the call using #*7 on lot park_3, slot 701.
5. Telephone 2000105 dialled 701 and got the call parked at step 4, which is the wrong one.

The important part of the trace is:
{noformat}
[Nov  1 11:49:44] VERBOSE[2694] res_agi.c: <SIP/product-local-00000069>AGI Rx << VERBOSE "Picking up call parked in 701" 9
[Nov  1 11:49:44] VERBOSE[2694] res_agi.c: <SIP/product-local-00000069>AGI Tx >> 200 result=1
[Nov  1 11:49:44] VERBOSE[2694] res_agi.c: <SIP/product-local-00000069>AGI Rx << SET VARIABLE __PARKINGLOT "park_4"
[Nov  1 11:49:44] VERBOSE[2694] res_agi.c: <SIP/product-local-00000069>AGI Tx >> 200 result=1
and then:
[Nov  1 11:49:44] DEBUG[2698] pbx.c: Launching 'ParkedCall'
[Nov  1 11:49:44] DEBUG[2698] features.c: Found Parking lot: park_3
{noformat}

For some reason it's using park_3, when it should be using park_4 as specified in PARKINGLOT.

The output of "parkedcalls show" while both calls were parked was:
{noformat}
Num        Channel                   (Context         Extension     Pri) Timeout
*** Parking lot: park_4 (1)
701        Local/*7@parkedcalls-9d2a;2 (parkedcalls     s               1)     40s
  1 parked call in parking lot park_4
*** Parking lot: park_3 (1)
701        Local/*7@parkedcalls-9b7c;2 (parkedcalls     s               1)     54s
  1 parked call in parking lot park_3
*** Parking lot: default (0)
---
2 parked calls in total.
{noformat}

And after the pickup was the following, which shows the wrong call was picked up:
{noformat}
Num        Channel                   (Context         Extension     Pri) Timeout
*** Parking lot: park_4 (1)
701        Local/*7@parkedcalls-9d2a;2 (parkedcalls     s               1)     24s
  1 parked call in parking lot park_4
*** Parking lot: park_3 (1)
*** Parking lot: default (0)
---
1 parked call in total.
{noformat}

Thank you.
Comments:By: David Cunningham (dcunningham) 2013-10-31 20:01:24.180-0500

Trace attached.

By: Richard Mudgett (rmudgett) 2013-11-01 12:20:17.188-0500

Your log does not have the verbose level set high enough to show it, but from other provided information your parking lots overlap.  You are using the automatically generated pickup extens to retrieve the parked call.  The automatically generated extens specify which parking lot they pickup a call from in the parameter list.  Since they overlap, the generated extens overwrite each other.  If you set verbose level to at least 3 you will see this happening.

{noformat}
<application name="ParkedCall" language="en_US">
<synopsis>
Retrieve a parked call.
</synopsis>
<syntax>
<parameter name="exten">
<para>Parking space extension to retrieve a parked call.
If not provided then the first available parked call in the
parking lot will be retrieved.</para>
</parameter>
<parameter name="parking_lot_name">
<para>Specify from which parking lot to retrieve a parked call.</para>
<para>The parking lot used is selected in the following order:</para>
<para>1) parking_lot_name option</para>
<para>2) <variable>PARKINGLOT</variable> variable</para>
<para>3) <literal>CHANNEL(parkinglot)</literal> function
(Possibly preset by the channel driver.)</para>
<para>4) Default parking lot.</para>
</parameter>
</syntax>
<description>
<para>Used to retrieve a parked call from a parking lot.</para>
<note>
<para>Parking lots automatically create and manage dialplan extensions in
the parking lot context.  You do not need to explicitly use this
application in your dialplan.  Instead, all you should do is include the
parking lot context in your dialplan.</para>
</note>
</description>
<see-also>
<ref type="application">Park</ref>
<ref type="application">ParkAndAnnounce</ref>
</see-also>
</application>
{noformat}
By: Alistair Cunningham (acunningham) 2013-11-01 12:34:34.500-0500

Hello, Alistair Cunningham here. I'm the manager of David Cunningham (the reporter of this ticket). I'm also the person who posted the bounty to have this implemented in the first place. The ability to have overlapping parking lots was part of the specification for implementing this, so that multiple customers on a multi-tenant hosted PBX system could each have (for example) parking slot 701 and they be completely separate. If Asterisk is getting confused because the parking slots are overlapping, then that's a bug. After all, if overlapping parking slots weren't supported, what would be the point of setting ${PARKINGLOT} before the pickup? If that were the case, we could specify only the parking slot.
By: Richard Mudgett (rmudgett) 2013-11-14 17:42:00.236-0600

Asterisk has always deleted the generated ParkedCall() exten when a call is picked up so you would have a different problem anyway.  The first call would get picked up but the second call could not be picked up because the exten no longer exists.

Overlapping parking lots are possible if you do *not* use the automatically generated extensions.

{noformat}
[my_park]
; This application must be used as the first extension priority
; to be recognized as a parking access extension.  DTMF transfers
; and some channel drivers need this distinction to operate properly.
; The parking access extension in this case is treated like a dialplan
; hint because the Park application does not get executed.
exten => 700,1,Park()

exten => _7XX,1,ParkedCall(${EXTEN})
{noformat}
By: David Cunningham (dcunningham) 2013-11-14 19:13:18.187-0600

Hi Richard,

We do specify the parking lot number when parking the call, like this from the attached trace:

[Nov  1 11:49:15] VERBOSE[2554] res_agi.c: <Local/*7@from-internal-201c;2>AGI Rx << SET VARIABLE __PARKINGLOT "park_4"
[Nov  1 11:49:15] VERBOSE[2554] res_agi.c: <Local/*7@from-internal-201c;2>AGI Tx >> 200 result=1
[Nov  1 11:49:15] VERBOSE[2554] res_agi.c: <Local/*7@from-internal-201c;2>AGI Rx << SET VARIABLE __PARKINGEXTEN "701"
[Nov  1 11:49:15] VERBOSE[2554] res_agi.c: <Local/*7@from-internal-201c;2>AGI Tx >> 200 result=1
...
[Nov  1 11:49:15] DEBUG[2560] features.c: Found Parking lot: park_4
[Nov  1 11:49:15] DEBUG[2560] features.c: Parking lot: park_4
[Nov  1 11:49:15] DEBUG[2560] channel.c: Planning to masquerade channel Local/*7@parkedcalls-9d2a;2 into the structure of Parked/Local/*7@parkedcalls-9d2a;2
[Nov  1 11:49:15] DEBUG[2560] channel.c: Done planning to masquerade channel Local/*7@parkedcalls-9d2a;2 into the structure of Parked/Local/*7@parkedcalls-9d2a;2
[Nov  1 11:49:15] DEBUG[2560] channel.c: Putting channel Local/*7@parkedcalls-9d2a;2 in ulaw/ulaw formats
[Nov  1 11:49:15] DEBUG[2560] channel.c: Released clone lock on 'Parked/Local/*7@parkedcalls-9d2a;2<ZOMBIE>'
[Nov  1 11:49:15] DEBUG[2560] channel.c: Done Masquerading Local/*7@parkedcalls-9d2a;2 (6)
[Nov  1 11:49:15] DEBUG[2560] pbx.c: Added extension '701' priority 1 to parkedcalls (0xa512b40)

By: Richard Mudgett (rmudgett) 2013-11-14 19:53:02.164-0600

The problem is not parking the call.  It is retrieving the call from the parking lot.  The ParkedCall extens managed by Asterisk are one shot and specify what parking lot the call is in.  When the call is retrieved, the exten is deleted.  Using your own exten with ParkedCall will retrieve the parked calls because you can then specify what parking lot to get the call from.
By: David Cunningham (dcunningham) 2013-11-14 20:43:46.501-0600

We will implement a workaround so it doesn't try using the same parking slot number. This can be closed.