Unity Connection 8.6(2) / CUCM 8.6(2) showing incorrect Caller ID when transfering from Unity / AA

[jmujica]

Hi.

I have a customer that is using CUCM 8.6 integrated with Unity Connection 8.6 via SCCP. Also the PSTN Trunks were ISDN/PRIs circuits. Callers dial the main customer DID get connected to CUC for AA services and from there to a final destination. On the Phone endpoints CLI was showing properly with the original calling number.

Now we changed from ISDN / PRI circuits to SIP Trunking for PSTN Access. Everything else is the same. Now when an external user gets connected to CUC and from there transfer to an endpoint for some reason the Caller ID shown is the Internal Caller ID of the end device so for the customer looks like if he is calling himself. Tested with different Phone Endpoints (69XX / 79XX) and the problem is the same.

I check the service parameter on CUCM under device - phone and the "Show Original Caller ID when transferring from Unity" is set to true. 

Any ideas? Also with the remote port status I can see on Unity Connection that the calls are getting there with the correct Original CLID. But for some reason that is changed to the final destination "Internal Caller ID" when transferring the call. So for example if I'm calling DN 2500 (Internal Caller ID is Joe). When Unity Connection transfer the called to 2500 on the IP Phone shows Calling From Joe.

I've never seen that before. 

Any ideas? Almost sure it is a CUCM issue or mis-config.

Thanks.

Jose

[Nick Barnett]

You didn't state how your SIP trunk is egressing from PSTN, so I will assume you are using a CUBE. You should debug ccsip mess on the CUBE and initiate an inbound call. Check the invite and see if the SIP service provider is giving the called number populated in any other field, like CONTACT. I have seen this before when the call was being "redirected" and arriving with a redirected number, but that was over PRI.

What CUCM mechanism is in place so that the inbound call actually reaches CUC for AA treatment? TP? HP? etc...

[jmujica]

Thanks Nick. Yes we are using CUBE. I can collect later on the debug ccsip messages.  When I was at the customer I used the Port Status Monitor Application and I was seeing CLID from my cellphone fine at the CUC. But when doing the transfer from the AA to the final IP Phones the CLID was missing and was changed to the CLID of the IP Phone itself.

We are using a translation pattern at the UCM to send the External DID to a Route Point that is forwarded to VM and at the CUC we have the right routing to choose the Call Handler for the AA service. Last night we reset the VM Ports at the UCM level and now the behaviour is a little different.

When the IP Phone received the call immediately the external CLID appears for maybe 1-second and then it goes away and the IP Phone CLID itself shows up as the CLID while the phone is ringing and also after it is answered.

We were planning to reboot the entire UCM cluster just in case before opening a tac case. Do you have any other idea?

Thanks in advanced.