I'm very pleased to see the level of involvement by Cisco staff on this forum.
I've experienced some of the problems reported by other posters, but the two that have caused me the greatest pain are as follows:
1) As a router/firewall, the UC320W is weak, which is fine with me because I really only want it to operate as a VoIP phone system. My problem is that it requires a WAN connection to support any Internet/cloud functionality, such as direct downloading of firmware updates and NTP. I understand there's a pmf to support LAN side NTP, but why not allow all Internet functions to operate over the LAN gateway? I know this has been requested by many and I'm surprised it's still an issue. I'd prefer never to use the UC320W as the primary router.
2) I haven't tested this after the latest firmware update, so I don't know if it's still a problem. When connecting to the UC320W remotely (via WAN), users would lose the ability to access voicemail. There were other odd issues that suggested instability, but I didn't document them and simply stopped connecting remotely.
In a SMB environment, it's not unusual for the customer to attempt DIY remedies prior to calling us (we try to train them, but it's a process). I received a call from a customer reporting that a Verizon technician was on site troubleshooting an Internet performance issue and wanted the password for access to the router (UC320W). I'm glad the customer forgot the password, otherwise I'd potentially be fixing a problem with his Internet connection AND his phones. Even something as simple as being directed by the ISP over the phone to power-cycle the router will knock out the phones, including the call to the ISP.
On another note, reducing the number of cases where a full restart was needed after changing settings was a welcome update, but it would be nice to know in advance which changes still require a full restart. Perhaps a note or mark (color or icon) on the configuration page or next to the setting could be used to make this known.
As far as I know, other than for NTP, there is no workaround for #1, so I suppose we'll consider it a feature request. Please pass it on as such. I know I'm not the only wanting to use the device without a WAN connection, so hopefully development will fix this in a future release.
As for #2, it would help to know if there are any known issues where remote access causes instability. The only time we've noticed the problem where access to voicemail stops working is after connecting remotely. A restart will resolve the problem. It took a bit of troubleshooting (all futile) before realizing that the problem only occurred after remotely accessing the device.
I'd like to back the issue Rick has brought up in #1. This might provide a little help - I ran into the same problem where I was trying to install the UC320W into an environment that had an exisitng ASA5505 in place for VPN connectivity. As a work around, I added a third VLAN to the ASA, assigned a port to the third VLAN, and connected to the UC320W WAN port. This only resolves the NTP issue 50% of the time. Occasionally, I have to walk an onsite user through resetting the system time on one of the phones. I am not sure why the system time cannot be set through the administration interface.
I support several sites that could benefit from a system similar to the UC320W. At this stage, I am not willing to deploy another one of these systems until issues like the one mentioned above are resolved.
If there is no WAN connectivity you may set the system clock via the a SPA Phone. Press the Phone Settings button and set the time on the phone. Once the time is saved, it will update the UC320 and other connected phones. The one downside to this is that there is no Time of Day Clock battery in the UC320, so any power loss the UC320 and all connected devices will lose the current time. NTP is preferred.
Hope this helps.