Escape \ in perfmonservice call

[Jim duPuis]

Hi all, I'm trying to pull some call queueing statistics using SOAP calls to perfmonservice/services/PerfmonPort in CUCM. In this case I'm using PerfmonAddCounter to add counters, then PerfmonCollectSessionData to retrieve the counters I'm interesting in. This all works fine until I try to use a counter for an E164 hunt pilot. Basically, the counter I'm after is \\10.0.0.10\Cisco Hunt Pilots(\+18005532447)\CallsQueued. I'm guessing I need to escape the \ in front of the E164 hunt pilot, but haven't been able to figure this out. I have to be missing a simple escape sequence, RTMT has no issues with it.

I've tried \\, \ and just leaving it as a slash, and all result in 500 errors. Any pointers would be appreciated.

[dstaudt]

It looks like the Perfmon SOAP service may have a defect in handling these types of Hunt Pilot patterns.  I note that perfmonCollectCounterDataResponse also has a problem with these and will not return the counters for those Hunt Pilots.  I have escalated this issue to engineering for analysis, and will report the defect # if confirmed.

[phogandepaul · Accepted solution]

Thanks dstaudit! Has there been any update on this issue? Our team ran into a similar issue, however we were able to get the service to register the counter when subscribed with %5C as a replacement for the backslash character. When we tried to execute the request, we received an Error Code 2: "Invalid Request" Client Error (Cisco Unified Communications Manager XML Developers Guide Release 8.0(1) - Serviceability XML API [Cisco Unified Communi… ). I am not sure if this is because it is interpreting the value literally or if there is some other issue.

[dstaudt]

Following up on the defect escalation...

Engineering did mention that hunt pilots no longer allow '+' in the pattern as of 10.5(2), which should then remove the need for the '\'...any chance the customer can remove the '\+' (without knock-on/undesireable effects) as a workaround?

[dstaudt]

FYI the associated defect is CSCux44250

[Jim duPuis]

Thanks Peter Paul, I had not tried URL encoding the value.