Unity transfer - original calling number

[Lena R]

Customer has the following call flow:

Call comes in on PRI to Callmanager (version 3.3(3)).

Call is sent to call handler in Unity (version 4.0(3)). This is setup as the main auto attendant.

Caller has option to press 4 to get to third party application.

The call gets forwarded to the application via second call handler in Unity and CTI route point in Callmanager.

The issue is that the third party application needs to see the original calling number. It sees the voice mail port as the calling number.

It appears that Unity cannot be configured to send the original calling number.

My questions are:

Is it correct that Unity cannot be configured to send the original calling number?

Is there a way for the third party application to "see" the calling number?

Could Callmanager be configured to send the calling number?

[kseraphine]

I think you should be able to see the calling number info in your scenario. I have a similar thing working in a call manager 4 cluster with unity 4.03.

I'd step through each step of the flow and see where the info is lost.

Launch call viewer on the Unity server and call into the auto attendant and see if Unity is recieving the calling number. If not it's being modified in a gateway or translation pattern.

Then call into the auto attendant again and dial a subscriber extension and see what the caller id says.

If that works, change the CTI route point to forward to an IP phone and place the call again. If you loose the caller id now, check the system parameters for "retain forward information" or something similar (might be different or ccm 3). If set to true, try setting to false and try again.

On the system I'm in front of, when the call is forwarded from unity, to a CTI route point and then to my IP phone, I see the voicemail port as the calling number for a split second and then it changes to the original calling number. Maybe the application is answering too fast and is missing this information.

kris

[asimkamran]

Hello Kseraphine,

I'm having this same machine with Unity unable to forward the original calling party ID.

I tried a CTI route point but still I can't get it to work.

Can you pleas specify which CSS and partitions should I configure on CTI route point. Let's assume that I'm using PT_ABC on my phone and CSS is CSS_ABC. So shall I be using the same CSS and partition in CTI route point or different ?

Also what directory number shall I configure in CTI route point ?

Any help will be much appreicated.

Thanks

[eschulz]

Unity has no concept of sending or forwarding a calling number. It simply acts as a single line phone performing a transfer. During the consultation call, Unity is placing a new call to the transfer target. Since Unity is the calling party for this new call leg, the destination phone correctly displays Unity's extension as the calling party. That aspect is controlled by the phone system, i.e. CCM.

That said, in CCM 4.2(3) a new service parameter was added called "Original Calling Party on Transfer". I think this will give you what you are looking for...

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a008070e4e4.html#wp1102760

[asimkamran]

Thanks for the reply eschulz.

Actually I'm running Cisco Unity 4.0(4) and CCM 4.1.(3).

here is my detailed scenario:

I have Auto Attendant/Unity, CCM and CCM has a SIP trunk to another PBX (which functions as a mobility server to ring different devices when the call comes in for any of it's subscriber).

There is a route pattern which sends the caller to the called party over the sip trunk.

I can see in the CCM traces that CCM is sending the INVITE with one of the Unity ports e.g., 7600@IP Address. Which means that ANI is getting lost somewhere when callers enter the extension to reach someone in the organization after listening to the main greeting. In Unity, I can see calling party number (ANI) and as soon as I enter the extension to reach a user, I don't see any info in the Call Viewer for the ANI.

Any help will be appreciated.

[eschulz]

That sounds like the expected behavior. Again, the Unity port handling this call is just acting as a single line phone. You can replicate this behavior using a SCCP Phone connected to the same CCM:

1. place call to SCCP Phone. You should see the ANI in the phone display. This corresponds to the ANI you would see in the Unity Call Viewer.

2. press Transfer on the SCCP Phone to place the call on old and initiate a consultation call

3. dial the transfer target (whatever DN you were using as the transfer destination in Unity). Now you should see CCM sending INVITE across the SIP trunk to the other PBX. The SCCP Phone's DN will be used as the calling number in this INVITE. For this call leg the SCCP Phone IS the calling party.

4. press Transfer on the SCCP Phone again to release the transfer. Once the transfer is cleared and the two parties are connected, CCM should send an message to the target indicating the connected party number has changed. Depending on how that gets handled by the SIP trunk, the display on the target phone may then get updated to show the original caller's number.

Nothing is being lost. This is simply how transfers work and it is not unique to CCM. Transfers on any PBX with digital display phones have behaved the same way for decades.

However, the new "Original Calling Party on Transfer". feature in CCM was added specifically for this scenario. When the transfering station is a Voicemail port, then CCM will act differently in step 3 above. CCM will setup the consultation call leg using a "spoofed" calling number. This allows the original calling party's ANI to be passed immediately on the consultation call leg.

-Eric