CallHandler taking call and not passing Caller ID?

[mcolao]

I have a customer that has a number primary number for the outside people to dial so that they get into the CallHandler. When a user on the outside dials the primary number for the company (i.e. 555-6000) and they go into the CallHandler tree and either dial the users extension or press the number for that particular user the customer sees the voicemail port from which it comes from...how do I tell Unity to pass the proper number from which the call originated and have it displayed on the IP Phone? Thanks...-Mike

[oliviers]

It's totally out of Unity's hands. CCM is in control of what ID is going to show up. Under some situations you'll see a couple of things that might happen:

1. With unity release transfers, you'll quickly see the DN of the Unity port show up on the transferred phone followed by the originating called party.

2. With unity supervised transfers, you'll see the DN of the Unity port show up until the transferred party answers. At that point, originating called party will show up.

If you replace Unity with an IP phone and direct external calls to it, then transfer the same way Unity is (i.e release or supervised), you can expect to see the same thing.

[mcolao]

I don't think it is a CCM problem...I think is has to do with a forwarding problem with unity and not passing the proper DN.

(1) When unity releases the transfer I see the Voicemail port (or unity port if that is what you want to call it, but it is the same thing) and no originating called party.

(2) With the supervised transfer (I am not sure if this is the way the unity system was set up, because another person set it up, so I would have to check)...I just see the Voicemail port and when they answer it still says the unity port.

(3) I haven't tried replacing Unity with an IP phone...

I think it might be something with the call routing in Unity. I appreciate the help with this though...

Thanks...

[kechambe]

Yeah I'm pretty sure Steve is right on this one.

Unity communicated with CallManager using the SCCP (skinny) protocol. SCCP is a master/slave protocol and CallManager is the master. IP phones and Unity are simply dumb clients with all of the logic controlled by CallManager. The SCCP protocol doesn't allow devices to initiate Call Forwarding and therefore Unity doesn't call forward. We use transfers to route calls back out in the same manor an IP phone would. Again the CallManager controls the caller ID and display name of these transfers. The SCCP protocol doesn’t have provisioning for a client to specify the caller ID and display name data.

Keith

[oliviers]

Yeah, you're going to have to trust Keith and myself here. Keith has had experience with Unity since the dawn of time, and I've gotten neck deep in the TSP code more times than I'd like to admit.

There's only one way to get close to controlling the ID when intiating a transfer. That would be to do the SCCP "offHookWithCallingPartyId" request upon initiating the transfer. I'm not sure if the DN inserted has to be a valid CCM dn or not, but I can guarantee you that Unity does not do this. It's going to transfer just like an IP phone does.

The level of Unity code that controls the call routing rules has absolutely no method or support of modifiying any portions of call info on outbound calls.