Firmware for UCM6202/6204/6208 is released as Beta



When you select a number of items to display in the bottom of the page drop downs (e.g. number of devices in Zero Config) the page reverts to the original default number of items instead of remembering what the user set it at.

This is quite problematic when you are dealing with more devices/items than the default setting and it delays a person’s ability to do their work effectively.

Can this please be corrected?


Thanks for the information!
Indeed I had a $ sign in the GDMS Password.
Then I replaced it with a # sign and this did not work also…
In the meantime I recognized, that the UCM did not register to the SIP-Trunk
anymore.Provider tells me that there isn´t even a register-trying since the time
the new beta is active.
UCM began to send alerts to me via email about 6 hours after activating the new firmware.
In between these 6 hours there also wasn´t any incoming try to register the trunk my provider said.
So I went back to and everything works as expected now again (Except GDMS of course).
Has anything changed regarding trunk registration options that explains this behavior?
Regards Michael


In the post I referenced I mentioned that I tested passwords containing $,£,~,%,& for GDMS and whilct they worked when logging on to GDMS authentication didn’t work from the UCM. In fact there’s a typo in my original post and $,£,~,%,& should read $,£,#,%,&
I’ll need to test more when I have time but it seems authentication from the UCM only works with alphanumeric passwords and special characters aren’t supported


That´s funny because if you change the GDMS password a message appears that the password should be at least 8 characters including special characters.
I changed it without a special charakter and it was accepeted by GDMS anyway.
This should be working with the BETA now I think.

But it´s really worthless if GDMS should work now and my SIP trunk doesn´t register anymore.
I never had any registering issues since 3 years and no other hardware or setting has changed except the UCM firmware.

The only thing I´ve found in release notes known issues is:

[System] Crashing may occur if PBX Settings->SIP Settings->Misc→Enable Use of Final SDP is toggled on.

If that has to do with the new registering issue, the FW cannot be used by me if I want to get calls from outside or want to call out.That´s a pitty…


I doubt if the trunk issue you’re experiencing is related to GDMS and the beat fw. I’m using the on a 6510 with 4 trunks and GDMS enabled and don’t see any issues with registration.
Look at a trace to see what the issue is with registration


I wanted to report several times it happened to me that in normal procedures you transfer of the conversation (with warning and blind), UCM crashed producing coredump error

System Crash 24-12-2019 18:20:29 asterisk process crash happend! The system has automatic recovery, Coredump file create time is: 24-12-2019 18:18:20 , Coredump file is: core.asterisk-1577207900-


I wanted to report an Italian translation error in the “Ring Group” under “Skip Busy Agent”.
There is a completely wrong translation, the correct one should be “Salta Agente occupato” oppure “Salta Extension occupato”.





I have noticed that the information on CDR has improved considerably, but there is one fundamental thing, in my opinion, the “transferred” calls must have a reference to which call they refer to.

  • I who am 201 make or receive an external call called B
  • Meanwhile other extensions make 20 internal/external phone calls.
  • I who am 201 pass my B call to extension 209 example
  • at that point CDR shows that 201 passes the call to 209, but there is no trace to understand that the external call B is the one transferred.

It must be considered that many external sw want the CDR with the correct information, precisely the one that would not understand the exact dynamics of the transferred conversation.

Therefore an incomplete CDR remains on the transferred calls. I hope you resolve it.


Thank you for the feedback!

Have you filed a ticket with the coredumps? If you’re comfortable with it, you can also DM me the coredump, and I can forward it internally to the proper person to take a look at it.

We will correct this.

Could you clarify this a bit? The transferred call leg will be shown under the original call’s CDR entry. Using your example:

  1. 201 calls B. The CDR will then show the CDR entry 201 -> B

  2. 201 transfers B to 209. This transfer will be shown as a call leg under the original call 201->B

  3. 201 is under the Premier Caller column, which indicates it as the transferer. B is shown under Call From column, indicating that it is the transferred party. 209 is shown under the Call To column, indicating that it is the transfer destination.


I’m unable to reproduce this issue even after using the same username (admin2000). Would you happen to have a capture of when the issue occurred? If you’re able to reproduce it reliably, could you file a ticket with a backup of your UCM config or send it to me in a private message?


Unfortunately I don’t have backups or anything else, I was doing some tests, I just changed “admin” to admin2000" and at reboot I didn’t access neither with admin nor with admin2000, he told me that both users didn’t exist.
I just made a report of what happened.


I honestly see from the screen below that a conversation has been transferred from extension 202 to 202, but I don’t see how you can understand the external number transferred (let alone an external sw would understand it).
To be even more precise (optional) it would be good to have a reference on the trunk used.
Maybe I’m wrong, anything can be.

but on the screen below I think the information is correct.
It probably changes from a blind trip to a trip with warning, at which point one of the two conditions is not detailed correctly in the CDR. Unless I’m wrong.


I don’t know why but there is no trace on UCM of the coredamp file in question, if the control error occurs again.
The scenario was always the same, GRP2613 transferring a conversation to another extension. Never the other way around. The GRP phone crashed and consequently UCM crashed and I had to restart them both.
The thing I don’t understand, how does the phone crash and UCM crash, if you crash the phone is a limited problem (still to be solved), but if you crash UCM becomes very serious.


(of course I’ve tried it 20 times now, and it didn’t happen too badly.)


I take this opportunity to congratulate you for having greatly improved LDAP, to be perfect it would be necessary to make the export/import easier and make it possible to access a user with “Custom Privileges”, to date it is not possible.


if you want to make UCM better or at least equal to other competitors’ products, you have to introduce the BLF Forward keys (the customer activate/deactivate the deviations by simply pressing a BLF, moreover through the BLF Forward led you would immediately understand if the deviation is active or not).
I have already written it in several posts and tickets, I hope you will activate it as soon as possible.

(let’s see who shares my request)


It seems like attended transfer via endpoint buttons causes the unclear CDR. Blind transfer will create a sub-entry under the original call. If you do attended transfer via the UCM’s *2 feature code, it will create a new main CDR entry for the transfer. I will note this feedback.

What firmware is the GRP on, and does crashing occur with both blind transfer and attended transfer?

Could you clarify what you mean by making ldap phonebook importing/exporting easier and being able to access a user with custom privileges?

Do you mean creating BLFs (one for each forwarding type) that toggle an extension’s forwarding settings and monitor whether they’re enabled or not?


Yes basically a quick setting for call forwarding.


hello @GS.Jimmy first of all thank you for your consideration:

“What firmware is the GRP on, and does crashing occur with both blind transfer and attended transfer?”

“Could you clarify what you mean by making ldap phonebook importing/exporting easier and being able to access a user with custom privileges?”
as for the privileges look at the screen below, there are 27 possibilities but it lacks (if I’m not wrong) the possibility to create a user with permissions to access LDAP, for import/export I think something simpler, the LDAP address book would be better managed by the end user, and at the moment it doesn’t seem a simple procedure (in my opinion):

“Do you mean creating BLFs (one for each forwarding type) that toggle an extension’s forwarding settings and monitor whether they’re enabled or not?”
Yeah, that’s right, I think just one is enough.
Example scenario:

  • Suppose there is a “generic” BLF Forward button.
  • user dial *72+3456789 once (active deviation)
  • then by pressing the BLF Forward key the user activates/deactivates the same deviation made towards 3456789.

Then of course the whole thing can be applied with a thousand variations, but I think this is enough for the average user.
Very useful especially with the user who makes the same deviation from his phone 5-10 times a day. Moreover the BLF Forward key led would help the user to understand if the deviation is active or not (green/red led).
Many competitors’ phones have it, for example Snom and Yealink. You will agree with me that it would not be bad :slight_smile:

For the moment, thank you for giving me the opportunity to have my say, if you need clarification, just ask.


I’m in the mood today, let’s see what you think,
I’ve seen that inbound mode can now create more than two.
Now, in order for the BLF “BLF Subscription Number” button to make sense, you would need to activate situations accordingly, for example:

  • *61= fixed green LED
  • *62 = fixed red led
  • *63 = green led flashing.
  • *64 = red led flashing
    Obviously I stop at 4 conditions, which satisfy 99.99% of customers.
    Can you think of activating this thing?


So i have created a time rule and when i try to implement it on outbound Routes it is not there.
I need a couple of different rules for different extensions, trying to block the hackers from piggy backing my system because these security fixes don’t seem to be stopping them !


you don’t have to look for the problem on UCM, but on the firewall, the attacker MUST NOT ARRIVE AT UCM, if he gets there you will not have activated ACLs on the firewall