[asterisk-bugs] [JIRA] (ASTERISK-24630) When defining 'parkext' for a custom lot, 'parkext_exclusive' is required to have the parking extension park at the custom lot

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229987#comment-229987 ] 

Richard Mudgett commented on ASTERISK-24630:
--------------------------------------------

There is some confusion about parking lot on-ramps created with the {{parkext}} option.  Just specifying the {{parkext}} extension option creates a general on-ramp to *any* parking lot at the specified extension.  Which parking lot a call gets parked in is determined in the following order: the parking lot explicitly specified as a parameter to the Park application, the PARKINGLOT channel variable value, the function CHANNEL(parkinglot) value, or the default parking lot.  How you set the PARKINGLOT channel variable or function CHANNEL(parkinglot) value is up to you and your dialplan.  The easiest way is to have the channel driver set a default value when the channel is created by using a varset or parkinglot option specific to the channel driver configuration.  If you enable the {{parkext_exclusive}} option then the created on-ramp can only send calls to that parking lot because the Park extension will explicitly specify that parking lot as a parameter to the Park application.


> When defining 'parkext' for a custom lot, 'parkext_exclusive' is required to have the parking extension park at the custom lot
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24630
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24630
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Documentation, 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)
> ;parkext_exclusive=yes          ; Specify that the parkext created for this parking lot
>                                 ; will only access this parking lot. (default is no)
> {noformat}
> Then where we show a custom lot:
> {noformat}
> ;*** Define another parking lot
> ;
> ; The parkinglot used can be set with the CHANNEL(parkinglot) dialplan function or by
> ; setting the 'parkinglot' configuration for a channel in its configuration file.
> ;
> ; Parking lots can now be any named configuration category aside from
> ; 'general' which is reserved for general options. They no longer need to be
> ; prefixed with 'parkinglot_'
> ;
> ;[edvina]
> ;context => edvina_park
> ;parkpos => 800-850
> ;findslot => next
> ;comebacktoorigin = no
> ;comebackdialtime = 90
> ;comebackcontext = edvinapark-timeout
> ;parkedmusicclass = edvina
> ;
> ; Since edvina doesn't define parkext, extensions won't automatically be
> ; created for parking to it or for retrieving calls from it. These can be
> ; created manually in the dial plan by using the Park and ParkedCall
> ; applications.
> {noformat}
> We only mention that parkext is not used in the custom lot example , but not that if it were used we would also need parkext_exclusive to make parkext relevant to the custom lot it was configured within.
> You can get that from reading the documentation for parkext_exclusive, but even that is worded oddly.
> Basically, {{parkext_exclusive}} is required to be enabled for any custom lot where you want to define a {{parkext}} that parks the caller at the custom lot.



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