FreePBX 15.0.17.43 Parking Lot Pro show CID of parked call on Programmable Key (GXP2160)

Hi All,

I’m a bit of a noob to full-flavor FreePBX (coming from several years installing Grandstream UCMs), and have a question about the Parking Lot Pro module. We recently migrated a large (500+ endpoint) customer from a failing Grandstream UCM to a FreePBX, and in general it has been a very positive change. However, now that the dust has settled from the initial install, the customer is asking about getting some of their old functionality back. In short, they’d like mapped parking keys (on GXP2160 phones) to show the Caller ID of the call assigned to each lot (something that worked natively with Grandstream).

We’ve purchased Parking Lot Pro and are using it for this customer, but it appears the documentation on the FreePBX wiki is out of date. It references a “BLF Capabilities” option that no longer appears to be present; it’s my understanding that this added an Asterisk hint for each parked call.

Ultimately, I suppose I have several questions; can anyone provide any insight into the BLF Capabilities option, or perhaps a more updated source of documentation?

More broadly, I’d be very grateful if anyone knowledgeable could tell me if I’m on the right track here. From my research, I believe I have the correct settings elsewhere in FreePBX and in the endpoints; both sides are set to use P-Asserted-Identity headers, and the Caller ID displays when picking a call up from park.

Let’s say you have Parking lot extension 70 with 4 spaces. That makes the parking space extension numbers 71-74. You would create a BLF for each of those spaces to pickup the call on those spots. The hints are already generated as a part of the dialplan.

When you pickup the call you should see the caller ID on the phone.

And if you do not, it is likely a phone setting.

Thank you both for the replies; the functionality you’ve described works as it should (we can park calls, the BLF turns red to show that, and when retrieved the CID of the external caller is displayed). What we’re looking for is a way to see the Caller ID for each park before picking it up; e.g. they want the key to not only become red, but also display the parked call’s CID on the button label.

This page in the Wiki shows how to do it with Sangoma phones but I don’t know of a way to do it with other phones.

That is not a BLF. That is an application. How it works will be dependent on the endpoint model in use.

Hi All,

Again, thanks for the replies; I’m slowly unraveling this. I understand now what you mean by application instead of BLF; this has really given me a deeper understanding of the intricacies of Asterisk.

After several hours of research today, I went right to the source and took a packet capture of this functionality working on a Grandstream UCM to a Grandstream GXP2160; the Red is my endpoint (GXP2160) and the Blue is my PBX:

I’m only somewhat experienced in reading PCAPs, but it appears in this instance the PBX is sending SIP NOTIFY updates to the endpoint with the Caller ID information to display on the key; in turn, on the GXP2160 a key must be programmed as a “Monitored Call Park” type in order for this information to be displayed. This is located in roughly the middle of the attached screenshot; it includes the various data I see displayed on my phone (Park 701, Caller ID “FloridaPhoneOffice” (the name of the SIP trunk being used; not desired, but a separate bug in the Grandstream UCM firmware)).

I’m still researching ways of editing Asterisk to manually send this information; does anyone have any pointers of how to best accomplish this/good resources for learning? At this point I’m losing hope for an easy solution, but am not against writing custom code to enable this functionality.

It’s worth mentioning that I was led down this path of discover via this (old) forum post: https://forums.grandstream.com/t/monitor-call-park-cid-name-information-when/31952

Like I said, Sangoma phones apparently support this. Take a look at the Wiki I posted to see how it works and maybe you can glean a workable solution out of a different model phone.

Thank you for the suggestion; we may end up buying a single Sangoma phone to test with for that very reason.

In my searching, I found that this thread is one of the top results on Google for this issue; as such, I’m going to update my progress here, in the hopes that I can save anyone else in a similar boat some time and headache.

My Discoveries:
Grandstream phones (specifically GXP-series, but most likely all models) have two special types of keys that make the phone send SUBSCRIBE packets for the entry in the “Value” field; setting the key type to “Call Park” is intended for individual park slots, while “Monitored Call Park” seems to be designated for lot numbers
Source: https://www.grandstream.com/hubfs/Product_Documentation/VPK_Guide.pdf

Using the Asterisk “core show hints” command, I can tell when a phone is subscribed to a particular lot (via the Watchers value).
Source: https://kb.smartvox.co.uk/asterisk/how-it-works/sip-subscribenotify-asterisk-hints-explained/

As described above, it appears that the Grandstream endpoints are looking for a specific “dialogue info” syntax in the Notify packet from the PBX (as outline in the PCAP screenshot). As FreePBX is not configured out of the gate to provide this, my next task will be writing custom script(s) to be called via “externnotify”; I’m still researching how to best accomplish this algorithmically, as opposed to creating manual entries for each existing park (as well as having to create more manual entries for any future parks)
Source (not directly relevant, but in the ballpark): https://kb.smartvox.co.uk/asterisk/sip-extensions/shared-voicemail-part2/

Thank you all for your help thus far, and I appreciate any tips/pointers on calling scripts; this project is turning into a great learning experience

Further links (mainly for my reference, but hopefully they can help someone else):

After further research, I’m following up more on using a Kamailio server to handle/publish this information; I’ve been spurred to this realization by: https://wiki.asterisk.org/wiki/display/AST/Publishing+Extension+State

The rabbit hole goes ever deeper…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.