BUG: selectCmDevice returns no details on UCM 18.104.22.16800-6
We have found a bug in the RISPort API for CUCM version 22.214.171.12400-6 here are the details:
When sending a 'selectCmDevice' request to the /realtimeservice2/services/RISService70 URL we get a valid response but it contains zero device details.
When sending an identical request to the same URL for CUCM version 126.96.36.19900-2 we get a valid response that include the relevant device information.
I've attached a screenshot of two request/responses, the request/response on the left is to CUCM 11.5, the request/response on the right is to CUCM 11.0
The device names used are valid and if we send the request using 'selectCmDeviceExt' to UCM 11.5 using the same details it works fine, so the requests are correct, but the response is invalid. We have restarted the RIS Data Collector & RIS Soap API services with no effect.
Re: BUG: selectCmDevice returns no details on UCM 188.8.131.5200-6
I've been unable to reproduce this problem on my 184.108.40.20600-6 system. <selectCmDevice> request identical to yours returns expected live data.
I would suggest opening a ticket with DevNet developer support so they can investigate the Risport and web service logs to see if they can identify any issue in your particular system. As the request works with <selectCmDeviceEx> this appears very strange...
I need to have a notepad with some saved text to pop up with an incoming call hit to our call center. I am aware of the thick client screen pop gadget, I am working on seeing we can change that to fit our needs. I am unsure to change to get this working
HiWe have UCCX and are using cisco finesse. We have deployed popup screen feature on finesse and it is working fine, but we have a problem. It does not create new tab for each call that is handled and every new call over writes the call info with the new ...
Hi there, Suppose Agent001 is in Ready(userstate) state while Agent002 is in Not_ready(userstate) state. Agent002 makes call to Agent001,Agent001 answers the call & now they are in Talking(userstate) state...
I'm tasked with providing a credential unlock for CUCM endusers. Looking at the AXL schema and doing some trial & error I found that pinCredentials.pinResetHackCount / passwordCredentials.pwdResetHackCount is what I'm looking for.. setting this to tru...