Plau
-
Posts
107 -
Joined
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by Plau
-
-
No, you don't need to manually enable "Tag SN to UA" anymore. We added an additional automated step in the provisioning process for Polycoms so they will first pull a config file to set "Tag SN to UA" before continuing with the normal provisioning steps. This was done a year ago. Have you been having issues with this?
-
Well, 5.9.2 wasn't listed as one of the firmwares that got the security fix.
-
So there's a security flaw with a number of the older firmwares, so I'm working on updating all the Polycoms to newer versions of the firmwares that doesn't have the security flaw. I was originally going to update to 5.8.4, but it looks like I'll have to go to 5.9.3 because of this issue. Once we have it QAed, then we'll announce the release to Production.
-
Looks like it's an issue with the older firmwares. It's resolved in 5.9.2.
QuoteGeneral EN-122406 After you complete a consultative transfer, VVX phones display the number “10” when you press the star (*) key when the phone is in an idle state.
-
On 8/7/2019 at 1:40 PM, Rick Guyton said:
More info, I did change the default transfer type to blind. And at first I did think this fixed it. BUT, then I did an attended transfer and it happened again. So, apparently, pressing the star button after doing any attended transfer causes "10" to be dialed instead of *. Very strange stuff...
I guess I wasn't that clear when I wrote my post earlier. It doesn't happen on Blind Transfers, but will always happen on Attended Transfers. It only happens when a Transfer button is pressed before the phone is no longer on an active call. That's why it doesn't happen the second time you press *. You can't recreate it when the phone boots up and press * for this same reason.
Blind Transfers doesn't actually fix the issue, it's more of you won't run into it because it's a problem that only occurs with Attended Transfers.
-
We default transfer to blind for all the brands except Polycom. I discovered that you could switch the default transfer type to Blind way too late, so I left it as Attended to preserve the expected behavior.
I'll reach out to Poly to see if they can shed some light on this issue.
-
I just tested it on my end on a VVX601 and I do see it happening. I never noticed before because I would only dial off hook or pushed the speaker button.
I was able to avoid the 10 popping up when pushing * by setting the transfer type to Blind (both through the phone and provisioning the Polycom with the default transfer type as Blind)
Did this use to work before? Or is this something recent?
-
Hi @DavidChan,
Yes, you can purchase licensed apps for the community version of Kazoo. Just contact our sales team and they'll be able to help you.
-
So after @esoare gave me a very helpful write-up of what he did to trigger the keys disappearing, I was able to figure out a simple way to get the keys to show up after the reboot.
If you have access to the phone's Web UI, then just go to Settings -> Upgrade and click the "Reset Local Settings" button.
If you don't have access to the phone's Web UI, then on the phone, go to Menu -> Advanced -> Reset Config -> Reset local settings.
After resetting the local settings, the keys are restored on the phone.
-
Glad to hear that things are working!
The logs in Advanced Provisioner show interactions of kazoo and the phone to the Provisioner server. So it shows device creation and updates as well as when the phone has tried to retrieve config files. These logs are cleared at the beginning of each month, so right now the logs do appear empty.
It isn't the logs from the phone itself. We currently don't have any plans around storing phone logs.
-
Hi @pilot,
The VVX350 and VVX450 were recently added to Provisioner, but it uses Polycom's firmwares for those phones. There are no plans to support the Obihai firmware versions for these phones at this time.
-
Hi,
Is this limited to only the T46S models? Were you able to reproduce this on different models?
I tested on a T48S and a T46G (I don't have access to the T46S) and was not able to reproduce the same issue you're facing.
What I do know is that setting Park keys through SmartPBX is broken because of a bug in Kazoo where if you don't label the Park keys, it'll drop the key entirely from the payload to Provisioner meaning the key will be missing. If you don't have the latest UI that includes labels for Combo Keys in SmartPBX, this will always happen. A fix was made two weeks ago, but it looks like it hasn't been deployed to Production yet. If you have your own install of Kazoo, then it needs to be updated to the version with the fix.
This is an older bug that has been fixed, but you could lose devices settings if you updated the User in SmartPBX or Callflows. There was a bug in Kazoo where updating the User updates all devices attached to the User with Default settings. This means that all the keys and settings are erased from Provisioner. If you have any settings set through SmartPBX or Callflows, those will be preserved, so saving through either of those apps will restore settings.
I couldn't reproduce this issue when using Advanced Provisioner at all.
As for when rebooting doesn't work but factory resetting does, have you checked the device logs available in Advanced Provisioner? It could be that the phone is provisioned to an out of date URL. The secure folder path may have changed and this is caused by a different bug in Kazoo. Kazoo had a bug where if the case of the MAC changed (eg. from uppercase to lowercase), it would tell Provisioner to delete the device and create a new one. You could have triggered it unknowingly by updating the device in Callflows as it normalizes the MAC to lowercase before saving to Kazoo. This was a long standing bug that I had a lot of trouble pinning down but a fix was made and rolled out around the beginning of this year. A number of devices were affected by this bug and we currently have no way of batch fixing the URLs.
-
Hi Dhruv,
I'm not quite sure what you're asking for. Are you asking about how to set DHCP Option 66 on your router/switch?
Also, are you using filezilla as a alternative because your phones aren't provisioning?
-
Hi @anir, we don't have a timeline on adding the VVX x50 phones yet. As I understand it, it's rebranded Obihai phones for Polycom. These might be trickier to add as they might support both Obihai firmware and Polycom firmware, which means config file generation needs to support both templates in case one doesn't work. We don't have any of the phones either so I really have no idea how much work would go into adding them at this time.
@esoare, I do have an HT8xx model for testing, but we have a code freeze on Provisioner so it's been delayed. When I worked on it, the HT8xx ATAs doesn't work with the current HT templates, so it would take a lot more work to get it up as the Grandstream settings naming scheme is very unfriendly.
-
We don't have any plans to add it anytime soon. Currently, you can use "Use own firmware" to prevent Provisioner from updating the firmware during provisioning.
-
Yeah, it's a requirement after each factory reset. With the last update, this is strictly enforce. This does break ZTP and DHCP option 66, but I'm working on a fix. It would add an additional reboot cycle to the beginning of the provisioning process to enable "Tag SN to UA".
-
Without know which IPs or MACs are associated with your account, I can't debug any further. I do see recent requests from 410 that is failing because it's not sending the MAC in the User Agent. Do you have "Tag SN to UA" checked for the device?
-
So this is a mistake on my part. I accidentally left the locking feature of Provisioner enabled after the update Monday night which was preventing phones from initial provisioning. I have since turned the locking feature off, so rebooting the device is all that's needed to get it provisioned.
-
I just tested adding a device on our production server and sandbox server and RPS still works. It no longer steals phones away from an existing RPS account.
-
@DinkyDonkey I replied to your support ticket. Custom Config File URL only works for firmware v81 or above. It wasn't explicit in the UI, so I'll be adding a note for the next update. This is also why not all Yealinks have the setting Custom Config File URL available in the UI.
-
I've updated it in an upcoming release I'm still testing. Once I'm done testing, we'll make an announcement for when we're updating production with the next release.
-
Sorry about all of this. I was attempting to plug a minor security hole I discovered last week where someone was scanning with folders that did not match our directory hash. The risk of the scanner actually getting a valid config file was 0 (it was done with the same bad hash over and over), but the security in Provisioner was ignoring it so we weren't getting notified.
I was overly aggressive in my check resulting in Provisioner rejecting requests to .boot files (which contain the custom config file URLs). I just fixed it and have tested on my end to show that Provisioner is no longer outright rejecting requests to .boot files. Please reboot the phone and let me know if the phones are picking up custom config files again.
-
I'm not exactly sure why we enforce the reboot. I know that the enforcement on Polycom phones was a more recent change. My best guess is that some people were confused when they click the "Reboot"/"Restart" button in the UI and the phone did nothing.
I did receive from Yealink the SIP payload that triggers the "Autoprovision now" feature, so it's possible to add this functionality. The SIP side would be to Kazoo. As for the UI, it would probably make more sense to add an additional button to "Update" where it simply updates the config file. I don't know if there's a way to inform the user that an update was successful or not.
@Chris Kerber takes care of feature requests, so this might be something we add later on.
-
Oh, yeah, nice catch @esoare. It's a typo. Should be Reseller 4, not 3.
Cisco 504G Park feature setup
in Product Discussion
Posted
Here's what you need to place in the value section for Cisco SPAs:
fnc=blf+sd+cp;sub=[blf_number]@[realm];usr=[blf_number]@[realm];nme=[label]
Replace:
[blf_number] - the park/retrieve number (e.g. *31)
[realm] - realm of the account of the phone
[label] - what shows up as the key label on the phone