[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

[Andrew Nagy (JIRA)]

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

Andrew Nagy commented on ASTERISK-24630:
----------------------------------------

Rusty,

Just ran into this issue in FreePBX. Looking at the old that's been around since the 1.8 days it appears parkext_exclusive was used to create a "private" lot of sorts. I am not entirely sure how it was suppose to function. All I can see now is that what you are documenting IS how it functions now. Just wanted to reconfirm with you.

> 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)