Firmware for UCM6202/6204/6208/6510 is released as Beta



Dear Grandstream Customers,

Firmware for UCM6202/6204/6208/6510 is now released as Beta. Here is the link for the release notes:

The firmware and release notes can be downloaded from:

Please contact us should you have any issues. Thank you for your support for Grandstream products.

Technical Support
Grandstream Networks, Inc.



I read the list of “known bugs” and wondered, is it not convenient to solve at least 95% of the problems then publish a stable and usable FW?
Otherwise everything continues to be an open-air test, the installers get angry, the customers get angry and GS loses credibility.
Mine obviously wants to be a constructive comment, what do you others think about it?


@damiano70 I agree with you. I understand that Beta is Beta and the point is to find the bugs in a beta test. But a large list of known bugs is a flag that the Beta process is happening too early in the dev cycle. Perhaps our friends at GS think that we are all running a DevOps environment! :yum:

Seriously, I really wish GS would slow down the release cadence and get things far more “right” before making firmware available. I said as much on the Insider forum survey on the 6300 series. New features are nice, features that actually WORK are nicer. I dont think it is unreasonable to expect reasonably bug free software from a vendor. 100% bug free is probably an impossibility but they should be able to get damn close.


The question is also: Are these “known bugs” already available in the previous “stable version”?
In this new beta version a security fix seems to have been implemented again.
Is it therefore necessary to import this version for security reasons and to accept the “known bugs”?

Or are the security fixes mentioned in the “release notes” already included in the stable version?
Generally: Which version should at least be on the customers UCM 62XX at the moment in order to be safe?


@grandgrand True. But you have to balance stable functionality against the bugs AND the security fixes based on how you are deployed. I guess it is a never ending battle. Frankly, I hate upgrading then immediately downgrading because something previously working is now borked. I am definitely behind in updates at this point as I cannot risk breaking operational systems.

It really would be nice if GS had 2 branches on f/w; an honest to God STABLE and a dev branch leading to next major release. Then, at least, you would have a fighting chance at knowing what you can put on customer boxes with reasonable expectation of success. As it stands now you basically have to replicate in a lab environment in order to KNOW if you can upgrade safely. Im pretty sure most cannot do that so it ends up being a crap shoot.

Ok, I will end my rant now!


The thing is: you have to answer to the customer if he gets a gigantic phone bill and the security hole was known long ago.


hi @robertd,
obviously it is a beta, and should not be used in production, but lately I see the beta, then the stable one, then the beta to solve the stable problem, then a further beta that solves the beta problems, then a third beta that solves the problems of the two previous beta, then a new stable with other “known” problems. So it is really difficult to wash.
2 stable FWs per year would be optimal, as long as they are seriously stable :wink:

p.s.: lately, unfortunately, I see many vendors using this strategy, in my wrong view, to bring out Beta versions, which would not even be alpha. So only the whole chain loses.


Hi @damiano70: Agree 100%. While security holes are bad, rushed “fixes” are worse. And do they even perform regression testing? This is Asterix and a custom GUI for pity sakes, it’s NOT the 10 zillion lines of code of Windows 10. But it does seem to be the way of thw world, now. Everyone is a “tester” (thanks Microsoft!).


I don’t think 2 releases a year are enough; especially given the key features that are not working they way many of us would like them to.

Now 2 major releases a year, fine. But I still want stable interim releases that fix many of the existing things that are IMHO not working properly; and I am not necessarily talking about bugs. For example, fixing the bulk edit/import-export limitations, or changing the minimum time for an IVR timeout from 1 to zero, should be able to be released in a minor release.

Adding completely new feature should be limited to the major relases.

Just my two cents (and remember we no longer have pennies in Canada). :wink:


Yes, David … maybe 2 loonies? With inflation and all that??? :hugs:


“2” was a way of saying, in the useless sense to have 20 “mess” versions better few but functional.


Hi everyone, after update I found one problem, if I changing setting>extension>VOIP trunk> edit trunk>DID Mode from request-line to to-header all calls from ALL lines begin coming only over one queue, and no possibilities to change it. Is this glitch of firmware or I still able to managing incoming call rout somehow? If yes, where this settings could be? Thanx.


what you mentioned are 2 completely different ways of handling the incoming call, and the method is identical even after updating the FW, it was probably not set correctly before the update and the problem became evident after the update.
Check the trunk and input path settings.


Well I wish to but not, all lines has own inbound rout, all rout already setup at least few years. Is there could be another inbound rout settings? Alternative? Where I can find this special settings?


to answer you would need to have complete details and scenario,
also a wrong setup can still do its job for years,
took a look here?


Thank you for your assessment, I certainly do not exclude the possibility of mistake, but there no other settings there. :frowning:

And there no any word about “2 completely different ways of handling the incoming call, and the method is identical even after updating the FW”

DID Mode
When editing SIP peer trunk, users shall see “DID Mode” option. This option is for user to configure how to obtain the destination ID of an incoming SIP call.
There are two modes available for uses to select: To-header and Request-line.
Select “To-header” to use To header in SIP message as the destination ID; select “Request-line” to use Requestline header in SIP message as the destination ID.

Are you sure about your statement “2 completely different ways of handling the incoming call” because the no information about this.


Is anyone know purpose of this options in VoIP trunk settings DID mode? If change it from request-line to to-header, all incoming calls disregards all inbound rules for this trunk and calling for some own unknown rules. Or it’s unexplained miracle from Grandstream engineers?


each feature of the Trunk settings follows the various needs of the SIP protocol in order to work in almost any situation.


@grandstream, this Beta firmware was announced almost 2 months ago. Can you advise when it will be going into production or are there know bugs with this firmware?