Barge most recent call to Barge Group using Active Call List



Feature Request for UCM62xx Series IP PBX
Function added: Call Barge, Whisper, and Listen Guided by Active Call List

Motivation: The UCM 62xx series implements Call Barge, Whisper and Listen directed by barged extension. Each extension has a list of extensions which may barge it. This seem primarily intended for call center applications, in which supervisory personnel are assigned a list of call agents to supervise, and spend their time working through lists of extensions to check call quality.
An important user group not supported by the implemented feature is that of the small office or large family home, in which users actually desire to connect to calls jointly, much as they did with an old-fashioned key-system telephone. Such joint connection is supported for SLA phones connecting to analog trunks, but not for SIP trunks or normal extensions. Many users cannot handle the complexity of new SLA phones. Many PBX operators don’t want to install expensive end terminals.
Use Case As Currently Handled: When trunk calls come into the PBX, they ring on all phones assigned to a ring group. Users see the presented caller ID, and determine whether the call is of interest to them. BUT, the first user to answer the call gets total control over it, and must transfer the call to the appropriate user. This requires that the user answering the call know to which extension the call must be transferred. In an office setting where people sit at their workplaces, this may be a reasonable assumption, but in an office with mobile employees, garage, warehouse, et. where move from room to room, and must still answer phones, it is not. In such cases, the user answering the call is forced to try several extensions serially, until the appropriate user for whom the call was intended is found. This requires putting the incoming caller on hold multiple times, which can cause the incoming caller to lose patience or confidence and hang up. If barging is enabled, the second user can barge, but must know which extension answered the call, which presents similar problems.
Use Case As It Should Be Handled: When a trunk call comes into the PBX, it rings on all phones of the designated ring group as before. Users see the presented caller ID, and determine whether the call is of interest to them. The first user to answer still gets control of the call. HOWEVER, provided permissions for barging have been given, the second user to answer (who may be the user to whom the call was directed, or is also desired on the call) has the option to dial a fixed code to barge into a call in progress.
Differentiator: Key to this feature is that the second or further users to answer do not need to know which extension initially answered the call. Neither does the answering user need to know at which extension second and further users are located in order to add them in conference. This eliminates extension guessing which can cause the initial inbound caller to lose patience.
The lack of need to know an extension is achieved by searching the active call list in order from most recent connected call to oldest connected call. Each active call will have as a call participant an extension (unless it is possible to transfer an outside call to another trunk, in which case that call can be ignored). The barging user may only barge in on a call if the extension already involved has the barging caller’s extension in its barge list, and barging is enabled.
From the user’s point of view, this barging by call list would work similarly to the barging codes which by default are *54, *55 or *56. One would create three new barging codes (for example *64, *65, and *66), which would be web reconfigurable just as the original barge codes are now. An additional Web GUI switch enabling Barging by Call List could be added, in which case both Call Barging and Barging by Call List would need to be enabled for these new feature codes to work.

Unlike the existing barge feature codes *54, *55, and *56, the additional new feature codes would not take extension numbers as arguments. Rather they would take an ordinal number as an argument, or no argument at all (in which case a default argument of 1 would be assumed). The ordinal number would dictate into which of the active calls for which the barging user has barging rights the barge would be made, as determined by recentness of connection.
Thus, to barge into the most recent call to come in into which s/he is entitled to barge, the second user would simply dial *66# (or *661# which is equivalent). To barge into the second most recent such call, s/he would use *662# and so on. *66# will be most commonly used, and could be programmed as a speed-dial on users’ phones that had that capability. Failing that, users who are used to *69 and similar features should have no trouble remembering this feature code.
If such a bargeable call is found, the user is connected just as if s/he had dialed *56#. If there is no such bargeable call (as when the call has been dropped, or the barging user asked for a higher number call than there were eligible calls connected), a message like “No such call” or perhaps simply a reorder tone would be presented to the barging user.
Implementation Notes: This add-on feature should be relatively simple to implement. It should also be compute efficient, as active calls on the UCM are limited (I think to ~40 on the UCM6204) :
a. If both barging and barge by call list have been enabled, the active call list (ACL) is looped in reverse connect order for the number of iterations given as feature code argument (FCA):
i. If the next call in the ACL iteration involves an extension that doesn’t have the barging user’s extension in their barge group, the ACL iteration is advanced but not the iteration count. The loop begins again.
ii. If the iteration count is less than that specified by the FCA, both the ACL and iteration are advanced. The loop begins again.
iii. A simple call barge, listen or whisper (as specified by feature code used) is executed to the extension found in the active call list, and the search loop is ended.
b. If there are no suitable calls in the ACL, the barging user receives a reorder or error message.
Allay of Concerns: Privacy protection would be assured by the PBX operator, who waives it only by enabling the features and creating barge groups between users with sufficient mutual trust. Accidental barges soon become apparent, from which the barging user would politely withdraw. The barging extension is announced (I hope only to the barged extension and not to the other caller on the barged call), so there is no possibility for stealth barging, listening, or harassment.
I think this feature would enhance the salability of your UCM product line, and be easy to implement. New functionality is of an interrogatory nature only, so extensive retesting could be avoided. If the new features are not used, their presence should do nothing to affect current system functionality. So with minimal testing, they could be initially released as beta functionality to let customers test.
I hope you will include this feature set in a firmware upgrade. Thank you for evaluating this feature.


It is better to do request via ticket system.


Hello Martin (I read Polish),

I did request this feature back in April or so through the helpdesk. I had acquired this PBX for a valued customer after checking that it would provide this feature (or a similar one). I even have an email from a Grandstream employee confirming that the PBX would do this. When it didn’t, I was asked to write a feature request, which I did.

Months went by – the helpdesk attendand Jésus who was helping me (and who asked me to write the feature request) promised to check on it, but the ticket closed in time-out when he never got back to me.

Instead, someone new named ‘Daniel’ insisted I open a new helpdesk ticket. When I did this, he insisted that I put the request in as a feature-request in the Grandstream forums, which I did.

There is now a reasonable presumption that Grandstream are giving me a runaround. I don’t understand this – this is a really well-designed feature that would make their product more saleable without any compromise I can see.

I believe could easily be implemented as an Asterisk loadable module, which I’d be happy to do, but Grandstream do not provide support for loading such into their system. I also asked for loadable module support, but was told it would be better to focus on getting the feature implemented instead. Runaround, runaround, runaround.

This is my first experience with Grandstream after many years – I tried using their IP telephones many years ago, and had to send them back. If they fail to deliver on their promises again, it will be quite a long time before I push their products again. The client were quite unhappy this feature wasn’t present, and still threaten to want something else.


GS do not believe in modules. It is in system or not. As for forum request it means that more people need to like this so sales will prioritize this and add to new fw. As far i know GS have a lot request and they make priority to fast, normal, low(never:P )

So in short new code for barging without knowing who answer. It can be based on existing barging privileges and it check last few calls (for choose). Usable by home user mostly.

+1 from me, it is usable and nice feature.


Thank you for liking it. It is also useful (as I wrote in the feature request) for places like garages where there are few employees who need to be added to a line frequently from either the auto bay, the stock room or the machine shop, and don’t know where the call was answered. I’ve seen people in such places remarkably resistant to learning other workers’ extension numbers. It’s just not important. But, there is likely to be only one new call going on at any one time, at most two or three.

The feature could always be turned off for customers paranoid about security.

Here’s hoping it gets implemented quickly – this customer are angry at me because Grandstream lied.