Caller-ID / ANI Incorrectly displayed on Blind Transfer from Specific Agents

[Matthew Martin]

Hello All,

We just added a new feature to Blind Transfer customer callers to a Post Call Survey. Everything appears to be working great, except I noticed that the incorrect Caller-ID is being displayed in the Database where the Post Call Survey writes to, for Agents who are working from home.

These Agents working from home are using Cisco IP Communicators. I believe the main difference between CIPC phones in our CUCM and normal Desk phones, is the Device Pool. But, I'm not seeing anything special in the in-office DP compared to the Remote phones DP.

Working Example: Customer calls in, eventually gets routed to an Agent phone that is physically working in the office. At the end of the call the Agent presses a button that is configured to Blind Transfer the caller to a new script that does a Post Call Survey. In that script we do a Get Contact Info step and capture the Caller's number. We then write some data including the Caller-ID to a external DB. In this example the Caller-ID shows the customer's telephone number correctly.

Non-Working Example: Everything is the same as above. But, this Agent is working from home using a CIPC softphone. The data written to the DB in this example, shows the Caller-ID as the Agent's extension who took the call, instead of the Customer's phone number.

Any ideas where I should start looking for this? Thought it might be something in the Device Pools. But, nothing stands out.

If I should ask this question in a CUCM forum, just let me know.

Thanks in Advance,

Matt

[Anthony Holloway]

It's entirely possible that the failed scenario is taking longer to complete the transfer, thus leaving the agent's extension in touch with the post call survey just a little too long, and allowing your Get Call Contact Info step to pull their number instead of the caller's. To prove this, try adding a delay, just after Accept but before Get Call Contact Info, and start high, but then reduce it to see how low you can get away with. By "high" I mean like no more than 8 seconds, but realistically, depending on the delay, it could be more. I'd be surprised though. Then if 8 seconds works to fix the report, then lower it to like 5 seconds, and keep lowering it until it breaks again, and then go back up. So, if it worked at 3, but broke at 2, then go back to 3.

[Matthew Martin]

Makes sense. Thanks Anthony.

I'll give that a shot tonight after-hours while I'm connected to VPN myself.

Thanks Again,
Matt