Cisco Desk Mini Settings Not Saving On Reboot

[tommy-gcp]

Got a Cisco Desk Mini to replace our older Tandberg devices, so far it has been great, but got this one weird issue. 

After setting CallProtocol to Auto (default is Spark) and turning SIP on (default is off), rebooting the device flips those settings back to default. I have the device enrolled into Webex Control Hub, but in the control hub, you can't set those 2 settings (they're listed as read-only on Control Hub), so I can't really create a template to set those.

RoomOS is latest, I have the software channel set to Stable, so it updates to latest, version says RoomOS 11.28.1.3 046de2f862a

[Jonathan Schulenberg]

Those will be dictated by how you configure the Workspace in WCH. If you want to use the endpoint with CUCM or Expressway you’ll need to use Webex Edge for Devices and the Webex Device Connector app to get it setup properly.

[tommy-gcp]

So, if I want the CallProtocol and SIP setting to not reset to default on reboot, I need to use either of those 2 you mentioned? I'm not looking to get it connected to CUCM or Expressway, I mostly just registered it to Webex so I could update the OS.

[Jonathan Schulenberg · Accepted solution]

WCH will always push/force settings it believes are required. The default behavior is for SIP URIs to be parsed by the cloud (CallProtocol=Spark), either resolving to a Webex user/workspace/meeting identity or handled by the SIP B2B calling capabilities included in the Cloud Device Registration license. AFAIK Edge for Devices is the only scenario where SIP will be enabled locally and the SIP registrar/proxy config won't be forced upon the endpoint; WCH expects that CUCM or Expressway-C/TMS is pushing that instead. You're in uncharted (unsupported) territory with anything other than CUCM or Expressway-C for SIP registration of a cloud-aware endpoint.

Edge for Devices isn't a calling mode you can select in WCH. The Webex Device Connector app will create the workspace for you with the calling attribute set to webexEdgeForDevices and then generate the activation code - which it will also push to the endpoint for you. The same end result is also possible by API but that's probably more trouble than its worth.

[tommy-gcp]

Thanks for the explanation, the device defaulting to whatever it thinks work best with the activated method makes sense.