Ring group issues


I have just deployed our new UCM6208 with GXP2170 phones and I’m having issues with a ring group. When a call comes in and someone is already on the phone, once that person hangs up the phone, the call will continue to ring at other stations in the group, but the call never rings at the station that just hung up. Is this a setting that can be changed somewhere?



on the group ringing is normal (simultaneous setting), at the limit create 2 groups and in time one group forward it on the other and vice versa, however in VoIP we recommend a group queues instead of a group of ringtones



This is a bug with the latest firmware.
Grandstream knows about it and are working on a fix in the next release.

This is how call queues behave and are currently doing that with ring groups.

The temporary workaround I used was to create a BLF key for the Ring Group and put it on the phones that needed it.
They can press the BLF to grab the next call after hanging up.


you say it’s a bug? I follow UCM for 3 years and the ringtone group has always behaved that way, I thought it was normal (even if I do not like it), in fact I always use the tails



Wow, AFAIK, when a RG call comes in, an INVITE is sent to the members of the group. If some members are engaged in calls, the members’ phones respond back with a 486 (busy) which may prevent the phone from ringing (not getting into multiple call handling). I do not recall having seen GS or other systems that when the INVITES have been sent (assumed ring all) and a phone replies with a busy, but then hangs up (making itself available) that the PBX will recognize the hangup and then try and include the extensions back into the RG with a new INVITE for a call that had already come in and is still pending being answered.


Ring groups are supposed to allow calls to ring in the background regardless if you are on the phone or not.
Queues don’t.


What is background, call waiting?


Kind of, while on a call you can see that you have a second call ringing on your phone.
It would appear on the 2nd line key.

Press hold, select 2nd line and answer.

That is a Ring Group


OK. I get it now,.

You are saying that even though the member was already on the phone, the second call coming into the group should have been delivered to the phone’s other line appearance.

The aspect of the system seeing a hangup and then sending the still ringing call (at other phones) back to the member with a new INVITE is a non-starter as he would have already had the opportunity to answer.

The above assumes that more than one line is available. BUT, I can confirm that when a second call does come in from a RG and the phone has call waiting and more than one line appearance, that indeed the phone sends a 486 and the call is never delivered to the other line appearance.

I just assumed this was how GS elected to implement the function.

As the UCM has no knowledge of the phone set-up, I assume this is perceived as a phone firmware bug?

I know of another system where you can limit the multiple call handling on phones with the capability so that while the member can use the multiple lines to their need, the system will not force another call to them if set that way. It simply looks at the extension status and if busy, moves on. If on the other hand it is not set that way at the PBX, the system level it sends the INVITE and lets the phone and user decide what to do. They do not call it call waiting, which I suspect is intended to be the same function. You can take multiple calls in that system from a RG if so desired.



And i have clients who want to have the second call ring through while they are on a call; mostly when having a single receptionist on duty and they use a RG for the Inbound Route.


Then I will have to go back and take a look. Thanks,


Did anybody ever figure this one out? We’re in the same situation with a single member RG not getting notified if another call comes in while they’re on the line. The extension is responding with a 486 in the packet captures we’re seeing. I know this used to work because we’d place one caller on hold and then answer the second call.

Was this a change in either the UCM firmware or the phone firmware?

The receptionist isn’t sure when exactly this started, so I don’t know if it’s after we did the firmware update on the UCM or the phone. We typically don’t do them at the same time but both have had one done in the past few months.



There is a firmware version for the UCM that experienced this bug.
It is corrected in current firmware version.