[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=229870#comment-229870 ] 

Andrew Nagy edited comment on ASTERISK-24630 at 3/11/16 12:36 PM:
------------------------------------------------------------------

Wanted to come back here and state that I got this to work and it seems to be correct.

Basically you have to set the parkinglot in said "extension".

So in sip.conf
parkinglot=<parking lot context>

Here's where it gets fun though

pjsip.conf (Under the endpoint)
set_var=CHANNEL(parkinglot)=<parking lot context>

Once that is set at that level you can park to "non" exclusive lots.

I believe this ticket should be closed as "works for me"


was (Author: tm1000):
Wanted to come back here and state that I got this to work and it seems to be correct.

Basically you have to set the parkinglot in said "extension".

So in sip.conf
parkinglot=<parking lot context>

Here's where it gets fun though

pjsip.conf (Under the endpoint)
set_var=CHANNEL(parkinglot)=<parking lot context>

Once that is set at that level you can park to "non" exclusive lots

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