Dear Grandstream Customers,
Firmware 1.0.15.10 for UCM6301/6302/6304/6308/6300A/6302A/6304A/6308A is now released as official.
Download Release notes
Download Firmware
For UCM6300 with RemoteConnect, make sure to download the latest Wave applications (1.0.15.x/1.15.x release) from here.
Please contact us should you have any issues. Thank you for your support for Grandstream products.
Technical Support
Grandstream Networks, Inc.
The bug that shows the REGISTERED TRUNK user name on all phone’s displays on outbound calls until the call is connected that was first reported by myself and others on 1.0.15.7 is still present on the new official firmware 1.0.15.10. I personally cannot install this firmware on customer’s systems until this bug is addressed, I hope this will be soon addressed in a new official firmware that can actually be installed.
Dear users,
Thank you for using the UCM63xx! You can try to disable “Remote Party ID” option in the UCM63xx and try again. That number will not be shown when the outbound calls are ringing. Thanks for your testing!
Thank you!
We had already implemented this “work around” on our office and test systems, however, I am hoping that GRANDSTREAM will address this issue that has just started with the 1.0.15.X firmware in the very near future as this does not seem like a “fix” that I want to push out to my customers. Also, on most of our installs the USER ID shown is not a number, but a alphanumeric logon. So, if you call a number, it doesn’t answer, you hang up, then press REDIAL the “number” redialed is actually the alphanumeric logon.
Please advise how the emergency callerID is supposed to work. If an emergency CID is set at the extension level and that extension executes an emergency call, in what SIP header will that emergency CID appear?
In my testing, it the emergency CID never appears nor does any DOD number. The FROM header always contains the From User number as set in the trunk.
IMPORTANT NOTE FOR @grandstream AND GDMS USERS:
When we upgraded a UCM6308 from 1.0.13 to 1.0.15.10 (through GDMS), all of the phones’ accounts were unassigned.
It seems the upgraded caused the UCM to delete/recreate all SIP Users in GDMS, which caused them to be unassigned. We had to redo all 50 phones.
Fortunately, only the accounts were reset. Not the parameters.
This is not really a fix, If you disable that option then park retrieve does not show the proper caller information, but instead shows the park number.
Can handsets be in GDMS and Zero config without any settings conflicting and overwriting each other?
Also, thought you were done with GS.
Emergency CID will be in the From and Contact headers of a SIP INVITE. If ELIN mapping is configured, and the trunk is a peer trunk, the ELIN will be used as the Emergency CID Number instead in the From header. Otherwise, whatever is entered into the Extension Settings->Emergency CID will be used as both the Emergency CID Number and Emergency CID Name in both headers.
If you’re using a register trunk, however, the behavior is slightly different. ELINs will not apply, and if the From User is configured, it will be used as the CID number and name in the From header. The Contact header, however, will retain the Emergency CID configured for the extension.
As a side note, Emergency CID will take priority over trunk DODs for both peer trunks and register trunks.
Yes they can but I’d recommend to stick to accounts in ZC and parameters in GDMS, so that they don’t conflict.
And yeah we are, that’s for an existing client.
Dear user,
Thanks a lot for your feedback! We will pass this feedback to our UCM development team for evaluation. Thanks for your testing!
Thank you!
I think that many use register trunks as I typically do. The idea that the emergency CID is put in the Contact header for a register trunk is meaningless to the emergency psap as they will/may never see it as they are downstream from the provider. The psap will see the CID as contained in the FROM header User Part, which, according to your response, will be the normal CID/ANI if the trunk is using a From User header regardless of the reason for an outbound call (normal or emergency).
I think it somewhat imperative that GS issue an updated and accurate document or other that clearly explains the use of the headers and how applied. There was definitely a change in how RPID was being used as it had contained the normal CID and would then convey the emergency CID when dialed. I had most of my sites set and tested this way and the changes implemented in the later versions now break that, which apparently also affects others. However, while RPID is supported, there is nothing in any of the manuals addressing how other than to send it and/or trust it. And yes, I am aware that RPID is still not in the official track RFC for SIP.
In the 63XX resource page there is a document that addresses emergency calling -
The above guide apparently covers all models of UCM given that any reference to a UCM is formatted as 6XXX and 6510. Additionally the above document also references the following -
Can you kindly point out in the Emergency Calls Guide where any reference is made to how the emergency call information in the SIP INVITE is formulated based upon the trunk type in use? I cannot find such and in fact, I see the reference made in the manual that “Note: The Emergency Location Mapping is only supported for SIP trunk”. I do not see a caveat that ELIN is only supported for a peer trunk.
I also see no reference to how RPID comes into play; yet as seen in the trace of the other forum thread covering same (https://forums.grandstream.com/t/firmware-1-0-15-7-for-ucm6301-6302-6304-6308-6300a-6302a-6304a-6308a-released-as-beta/51340), the emergency CID does show in the RPID when the emergency number is dialed. It used to also convey the normal CID for all non-emergency calls which allowed us to tell the providers to use the RPID header for the FROM.
The Trunk setup manual also makes no reference to ELIN or even emergency. The trunk username functionality does make some reference to how the CID is formulated -
"Important Note: When making outgoing calls, the following priority order rule will be used to determine which CallerID will be set before sending out the call : • From user (Register Trunk Only) → CID from inbound call (Keep Original CID Enabled) → Trunk Username/CallerID (Keep Trunk CID Enabled) → DOD → Extension CallerID Number → Trunk Username/CallerID (Keep Trunk CID Disabled) → Global Outbound CID. "
The above does help to some degree, but does not address how the emergency CID factors into it. The trunk manual makes no reference to RPID, emergency or ELIN. Additionally, if you hover your cursor over the DOD as From Name in the trunk settings, the explanation of its use is that if the FROM USER field is configured, the INVITE’S From Header will contain the DOD number. This is not exactly how I took the explanation. I had expected the DOD number to be in the FROM header as the user part which is the CID, and not as the Display part which is usually a name. The notion that there would be two numbers is somewhat odd. The name that I associated in the DOD was “Test 2”.
When I have the FROM USER setting populated in the trunk with 9563353999 and also have the DOD checked in the trunk and then have a DOD setup using 9563353666 for the extension making the call, I see the calls continue to appear with the FROM USER (PART) number in the FROM header (9563353999). The header is only changed with regard to the Display User which shows 9563353666 is the CallerNAM, not the CID.
And of course, on most mobile carriers, the CallerNAM is not displayed unless the recipient has the name associated to the number (FROM USER PART) in a contact list or subscribes or otherwise has a callerID/NAM on their service.
The DOD name that I had associated was -
The use of the DOD name is omitted in the Trunk Setup manual and while shown in the UCM admin manual, its use is not explained. So, where does the DOD name come into play? I see it in the contact header, but only as a display info for the URI.
From my testing, using a register trunk, I can remove the From User field setting and rely on the DOD setting, which is then put into the FROM USER Part header on an INVITE and the FROM USER Part is subsequently replaced with the extension emergency CID when the emergency number is dialed. Intuitively, it makes me wonder why if the FROM can be altered based upon DOD and emergency, why such is not also available if the FROM USER field has an existing entry and an emergency call is made?
I will need to do some additional testing on the Global CID usage, but in the past, I just relied upon RPID and set such at the provider level as well.
I will have to do some additional testing to see how the ELIN aspect is implemented when using a peer trunk as it is not quite clear to me yet why the differentiation between peer and register.
In any event, the lack of clarity of how the various headers are used and manipulated when making an emergency call is worrisome as many may not know that the setup is incorrect.
Sorry for the length of the post, but GS has a history of making changes on the fly or breaking things and when it comes to emergency calling, GS should go out of its way to make the documentation crystal clear with the specifics of how and why and the device should function exactly according to same. The explanation of emergency CID at the extension level is -
“CallerID number that will be used when calling out and receiving direct callbacks”. I see no indication that such is is not necessarily true if using a register trunk with a FROM USER set and I wonder how many have taken the documentation literally and setup the emergency number not knowing that it may not be sent?
Thank you very much for your detailed feedback. I’ll bring it up with the documentation team so that we can update our guides and webUI tooltips to include details regarding emergency calling/DOD and how they affect the SIP headers. As for why emergency CID behaves differently for register trunks, I will discuss this internally with our teams.
@GS.Jimmy Could you kindly help to confirm if we will have any updates about this issue? Thanks!
If you are referring to the emergency CID-register trunk relationship issue has already been brought up internally. How it’ll be addressed, I have limited knowledge on. If your are referring to the documentation, I have already notified our documentation team about the mentioned issues so those should be updated soon.
If this is referring to the trunk username issue, this issue will be resolved in an upcoming 1.0.15.x firmware update release.
