List Pick Group members

Is there a way to list all members in a Pickup Group?

I doubt it. There probably could be, but I don’t remember anyone ever asking?

I did find the same question asked a few years ago, but no replies.

What are you trying to do with Pickup groups? using the **ext feature code syntax you can pickup any extension anyway.

Only with a SQL Query.

SELECT `data` AS 'PickupGroup', `id` AS 'Extension' FROM `sip` WHERE `keyword` = 'namedpickupgroup' AND `data` <> '' ORDER BY `data`,`id`;


SELECT data AS ‘PickupGroup’, id AS ‘Extension’ FROM sip WHERE keyword = ‘named_pickup_group’ AND data <> ‘’ ORDER BY data,id;

If you have PJSIP extensions.

My sample was from a system that only has pjsip extensions.

I have no idea where it is for chan_sip extensions if it is different. I don’t have access to anywhere using those right now.

With all the older TDM PBXs I’ve worked with I’ve always been able to list pick groups. Not essential - just wondering if the option existed. Now I see can only be done with an SQL query.


Then that means they are storing the chan_sip setting which is namedpickupgroups and writing out the proper setting of named_pickup_groups for PJSIP extensions. Which is odd.

You still haven’t answered what your purpose in using these is for. Because if you are expecting users to be restricted, it is not going to happen. The mouseover help clearly says that.

Just because I put 2 extensions in the Pickup Group pgtest, does not mean only those extensions can pickup those extensions.

I have no idea what you are talking about. All the extension details have always been in the sip table for pjsip extensions.

The pjsip table only contains details on pjsip trunks.

Chan_PJSIP settings use snake case so where in Chan_SIP the setting would be fromuser in Chan_PJSIP it would be from_user, etc. So therefore if the setting in the database is namedpickupgroup then that would be a Chan_SIP setting when the needed setting for a PJSIP endpoint is named_pickup_group.

I just checked a system, it seems if there is a Chan_SIP version of the setting (fromuser, namedpickupgroup, etc) then that’s what the database still uses while PJSIP specific settings like device_state_busy_at have the proper setting in the table.

That was not clear in your reply, it is also really not relevant. I mean, who would write a query without checking the database structure first?
Here is the sip table data for my test extension at this site. I guess it would be interesting to switch it to chan_sip and then see what these all are.

You’re right, I made an assumption and I was wrong. However, there is an actual difference in setting names between Chan_SIP and Chan_PJSIP.

Everything from max_contacts to outbound_proxy would be gone as those are Chan_PJSIP settings. Everything from dtmfmode to allow would stay the same as they are Chan_SIP settings. The mailbox setting would stay the same as it is a Chan_SIP setting (PJSIP uses mailboxes= in both the endpoint and aor configs), secret is a Chan_SIP only setting.

context, callerid, accountcode, allow, disallow, rtp_mux and transport are the only settings in there that are the same for both Chan_SIP and Chan_PJSIP.

So looking at this raw data it would look like there are a bunch of wrong settings which would break PJSIP if used but they are converting them in the code instead of storing the actual setting names for the proper driver.

Simply for other extensions to be able to pickup another without knowing which one is ringing. I’m experimenting with our shop test system to get familiar with it, Not trying to restrict anything.

1 Like

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