Multiple Parking Lot Module Update

SkykingOH, it works great. BUT only for the extension under the same parking lot group. i’m not able to pick up or park calls from another extension. but in my case is good, because i don’t want the other tenants to do that.

I Just did a test into one PIAF box that i have in my lab, running this config:

PIAF Installed Version = 2.0.6.2 under HARDWARE
FreePBX Version = 2.9.0.11 │
Running Asterisk Version = 1.8.12.0 │
Asterisk Source Version = 1.8.12.0 │
Dahdi Source Version = 2.6.1+2.6.1 │
Libpri Source Version = 1.4.12 │
IP Address = xx.xx.xx.xx on eth0 │
Operating System = CentOS release 6.2 (Final) │
Kernel Version = 2.6.32-220.13.1.el6.i686 - 32 Bit

after i add the settings on the features_general_custom.conf, extensions_custom.conf and /var/www/html/admin/modules/core/functions.inc.php

Just add the settings under each extensions, then go to parking lot and set the Return Destination Behavior to the originator. the call return to the originator.

Thanks for testing and that is exactly our results.

This is going to be an interesting thread because we have a philosophical divergence.

FreePBX is not designed for multi-tennancy and that is where this feature would be useful. For an enterprise phone system departmental level parks are highly desirable but useless if departments and operators can’t pickup the calls of multiple parking contexts.

Can an extension be part of more than on parking context? How does the effect the AGI park command?

hey SkykingOH, to be honest with you i dont know the answer to this 2 question, but i would like to see if i can make you to talk to cjonesmo from the PIAF forum he was actually the one that setup the module.

I will send him and you a PM, to see if you can chat.

Sorry, i’m basically learning asterisk now :frowning:

hey i create a conversation with you and CJONESMO at the PIAF forum.

let me know if that works.

:slight_smile:

You could possibly try to define the parkext within each custom context and then have the user transfer to the parkext# - I hadn’t tried doing it as I have each ext. within the custom context use the default parkext (in my case x7000). I’m not 100% sure that’s supported, but in theory, you define something like:

[parkinglot_a]
parkext=7010
parkpos=7011-7019
context=parkinglot_a
parkingtime=300
pickupexten=*8

[parkinglot_b]
parkext=7020
parkpos=7021-7029
context=parkinglot_b
parkingtime=300
pickupexten=*8

But I think you’d have to create a parkinglot2 field in the extension definition - just like we did with the first custom parking extension assignment within the extension modification web page. In theory, both contexts would be included for the extension - and it MAY be able to park on x7010 OR x7020. I hadn’t tried this and I’m not sure if it would just require the dialplan modifications and/or further source modification, but it’s worth a shot and an interesting idea. I chose to use the default PARKEXT for all extensions just to keep things simple, but I understand your need and I think this might be possible.

Let me know if it works.

CJ