[asterisk-bugs] [JIRA] (ASTERISK-24630) Park extension created by 'parkext' option for custom parking lots only parks calls in the default lot

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-24630:
------------------------------------

    Description: 
For custom parking lots, the option {{parkext}} when populated results in the creation of a Park extension, but with no arguments, such that it only parks calls at the default lot.

The behavior is the same in Asterisk 11 and 13. Below I have two examples of the parking extensions created when you define {{parkext}} for a custom parking lot.

Asterisk 11
{noformat}
centosclean*CLI> dialplan show
[ Context 'parkedcalls' created by 'features' ]
  '700' =>          1. Park()                                     [features]

[ Context 'mycustomlot' created by 'features' ]
  '800' =>          1. Park()                                     [features]
{noformat}

Asterisk 13
{noformat}
[ Context 'mycustomlot' created by 'res_parking/mycustomlot' ]
  '800' =>          1. Park()                                     [res_parking]
<snip>
[ Context 'parkedcalls' created by 'res_parking/default' ]
  '700' =>          1. Park()                                     [res_parking]
{noformat}

h1. Reproduction

* Configure a custom parking lot in features.conf or res_parking.conf

An example Asterisk 13 configuration of res_parking.conf

{noformat}
[general]

[mycustomlot]
context => mycustomlot
parkext => 800
parkpos => 801-850
{noformat}

If you set this up in 11,remember that you need the {{parkinglot}} prefix for the custom lot name.

* Load Asterisk with that configuration.
* Dialing the created extension results in parking to the default lot. Begging the question, why did I need or want to configure parkext in the custom lot in the first place?

h1. Workaround

The workaround is of course dialing your own Park extension via other means and setting channel variables or application arguments to target the custom lot.

h1. Edit

I found out later that for {{parkext}} to create a parking extension that targets the custom lot you configured it within, you also need to define {{parkext_exclusive=yes}} within that same custom lot.  I feel like this behavior was different in this past... nevertheless we need to document this better. 

The current documentation for parkext says:

{noformat}
parkext => 700                  ; What extension to dial to park. (optional; if
                                ; specified, extensions will be created for parkext and
                                ; the whole range of parkpos)
{noformat}

We also show it configured under a custom lot:

  was:
For custom parking lots, the option {{parkext}} when populated results in the creation of a Park extension, but with no arguments, such that it only parks calls at the default lot.

What is the point of the parkext option for custom lots?

Asterisk 11
{noformat}
centosclean*CLI> dialplan show
[ Context 'parkedcalls' created by 'features' ]
  '700' =>          1. Park()                                     [features]

[ Context 'mycustomlot' created by 'features' ]
  '800' =>          1. Park()                                     [features]
{noformat}

Asterisk 13
{noformat}
[ Context 'mycustomlot' created by 'res_parking/mycustomlot' ]
  '800' =>          1. Park()                                     [res_parking]
<snip>
[ Context 'parkedcalls' created by 'res_parking/default' ]
  '700' =>          1. Park()                                     [res_parking]
{noformat}

An example Asterisk 13 configuration of res_parking.conf
{noformat}
[general]

[mycustomlot]
context => mycustomlot
parkext => 800
parkpos => 801-850
{noformat}

The same configuration works for features.conf in 11, but you need the {{parkinglot}} prefix for the custom lot.

Dialing the created extension results in parking to the default lot.

The workaround is of course dialing your own Park extension via other means and setting channel variables or application arguments to target the custom lot.

It really feels like I'm missing something here. If not, then we should at a minimum document that the parkext option requires the setting of channel variables to access the custom parking lot.


> Park extension created by 'parkext' option for custom parking lots only parks calls in the default lot
> ------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24630
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24630
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Features/Parking, Resources/res_parking
>    Affects Versions: SVN, 11.15.0, 13.1.0
>         Environment: Affects both 11 (pre 12 parking changes) and Asterisk 13 (post changes)
>            Reporter: Rusty Newton
>            Severity: Minor
>
> For custom parking lots, the option {{parkext}} when populated results in the creation of a Park extension, but with no arguments, such that it only parks calls at the default lot.
> The behavior is the same in Asterisk 11 and 13. Below I have two examples of the parking extensions created when you define {{parkext}} for a custom parking lot.
> Asterisk 11
> {noformat}
> centosclean*CLI> dialplan show
> [ Context 'parkedcalls' created by 'features' ]
>   '700' =>          1. Park()                                     [features]
> [ Context 'mycustomlot' created by 'features' ]
>   '800' =>          1. Park()                                     [features]
> {noformat}
> Asterisk 13
> {noformat}
> [ Context 'mycustomlot' created by 'res_parking/mycustomlot' ]
>   '800' =>          1. Park()                                     [res_parking]
> <snip>
> [ Context 'parkedcalls' created by 'res_parking/default' ]
>   '700' =>          1. Park()                                     [res_parking]
> {noformat}
> h1. Reproduction
> * Configure a custom parking lot in features.conf or res_parking.conf
> An example Asterisk 13 configuration of res_parking.conf
> {noformat}
> [general]
> [mycustomlot]
> context => mycustomlot
> parkext => 800
> parkpos => 801-850
> {noformat}
> If you set this up in 11,remember that you need the {{parkinglot}} prefix for the custom lot name.
> * Load Asterisk with that configuration.
> * Dialing the created extension results in parking to the default lot. Begging the question, why did I need or want to configure parkext in the custom lot in the first place?
> h1. Workaround
> The workaround is of course dialing your own Park extension via other means and setting channel variables or application arguments to target the custom lot.
> h1. Edit
> I found out later that for {{parkext}} to create a parking extension that targets the custom lot you configured it within, you also need to define {{parkext_exclusive=yes}} within that same custom lot.  I feel like this behavior was different in this past... nevertheless we need to document this better. 
> The current documentation for parkext says:
> {noformat}
> parkext => 700                  ; What extension to dial to park. (optional; if
>                                 ; specified, extensions will be created for parkext and
>                                 ; the whole range of parkpos)
> {noformat}
> We also show it configured under a custom lot:



--
This message was sent by Atlassian JIRA
(v6.2#6252)