The fix for CSCul23643 was included in the 1.4.5SR1.3 release therefore is also in 1.4.6.3 as well. ... View more

Replication is continuous. It is more like a push model than a pull model. ... View more

From the bug Release-note: "The phone will sync with the timestamp in the 200 OK response to the REGISTER from the Cisco Unified Communications Manager (CUCM) server it registers with."   REGISTER is keepalive mechanism for SIP. SCCP uses DateTimeReq and was updated as part of CSCdz53716.   Are you observing incorrect times on phones where they are not sync'd to UCM? ... View more

Steinbachtill,   I'm not sure I follow. In versions before this change there were conditions where the two clock sync methods would get in conflict and cause problems. After this change the phone will use one method - taking date/time from a specific SIP message from UCM. These phones are only supported with UCM and so this method of updating time will always be available.   Attempting to use 2 sources for clock presents classic issues about "single source of truth". What gives you the impression you have to live with the wrong date and time? ... View more

Terminated because the bug was only filed for documentation purposes. I updated the bug Release-note to be more clear.  CSCti79536 removed ability for phones to pull time from NTP because it was causing conflicts with time derived from UCM messages.   Designed behavior is for phones to take time from UCM and not from NTP. We just managed to say that in a really confusing way. ... View more

one addition - NICE is likely already monitoring the device via CTI. It is possible to send DeviceToUserData message via CTI control of device to update the phone display. This is the same XML that would be sent directly to phone; just passed via CTI to CCM rather than doing http/XML directly to the phone. Because this goes through the call control channel it is slightly more reliable. And NICE should already have the device open via CTI so sending the message via CTI is already "in the workflow". ... View more

Please add formats for Split, Join, and Release.     ... View more

Hello Jesus, CSCua07154 was found during Cisco internal testing on pre-release software and subsequently deemed Unreproducible in the 9.0 customer release of Finesse. Beyond that our records do not indicate any customer encounters. This forum is specific for bug discussions. To reach an audience more attuned to the product you might try the Contact Center forum: https://supportforums.cisco.com/community/netpro/collaboration-voice-video/contact-center Regards, Wes ... View more

Hello Francis, Thanks for submitting your question. I don't see a link between the issue you describe and the bug CSCsm43875. It sounds like you are having issues with initial configuration of the feature. In that case I recommend posting to the general questions community: https://supportforums.cisco.com/community/netpro/collaboration-voice-video/ip-telephony Regards, Wes ... View more

Brent,  Interesting ideas indeed. Let me see what I can do.  Updating NTP version across all VOS deployments (Communications Manager, Unity Connection, UCCX, CUP, telepresence, cisco prime, ...) is non-trivial. Disabling unnecessary functions is a central tenant of the appliance model. I'll look into it.  -Wes ... View more

Hi Till, This bug is still under investigation. Please open a TAC case and reference this bug to get the lastest status. Regards, Wes ... View more

Randy,  You can look at a packet capture of traffic originating from the phone. You can connect to console and look at output. You can soft/hard reset the phone. Most likely the firmware got corrupted and you can hard reset it, with the appropriate network setup and files on UCM TFTP server, and recover it.  The phone is like a PC in the enterprise; only cheaper.  -Wes ... View more

CSCug84641 is marked as a duplicate of CSCug51773.  CSCug51773 is in terminal status and will not be fixed. CSCug51773 appears to be caused by limitation on of the Intel Atom processor. Jabber does not claim support for that processor. ... View more

Hi Peter, This forum is for discussions about specific known bugs. You might find better discussion in the IP Telephony forum: https://supportforums.cisco.com/community/netpro/collaboration-voice-video/ip-telephony Conceptually as an analog voice gateway the VG shouldn't generally provide any time information to an attached phone system. Is it possible the phone system is pointed to the VG as an NTP reference? In that situation the internal platform clock isn't terribly reliable and synch to an more reliable external NTP reference is recommended.  The only other possibility that comes to mind is delivery of a timestamp information along with callerid over the analog voice ports. In that situation the router again depends on internal clock. Configuring an NTP reference on the router will help to keep the router clock better synchronized.  These are all a bit of a stretch. The most likely, IMHO, is the pone system pointing to VG202 as NTP reference. In that case giving the VG202 a reliable NTP reference so the router can keep more accurate time would be my first approach. Hope this helps, Wes ... View more

Brent,  Great observation and idea.  The architecture of iptables inside the appliance doesn't really enable this approach. The iptables rules are selectively updated due to dependence on other processes. To that end UCM would only learn the IP of an endpoint when the endpoint registers. Every (un)registration event would then trigger a configuration change to iptables. This becomes unscalable very quickly.  Generally on UCM all resources are dedicated to call processing as first priority and everything after that gets leftovers. This keeps processing of calls as highest priority.  We are looking for opportunities to better leverage iptables and native capabilities in upcoming versions. Concurrently call processing remains priority #1.   From a security perspective it is best practice to have an external device performing security, policing, and inspection.  Regards, Wes ... View more