CLID on a transferred call

loganseth · ‎12-17-2008

We run 6.1(2). When a phone transfers a call to the PSTN (via MGCP controlled gateway), the CLID on the PSTN device (for example, a cell phone) displays from the phone that transferred - NOT the original calling party.

The application, here, in particular is for Mobilitiy (SNR). When our operator answers the call and then transfers it to the employee, both their desk and cell phone ring; while the caller-id on the desk phone shows the original calling party, the cell phone shows the outpulsed digits from the operator's phone.

I noticed the same behavior, though, when simply transferring calls.

If I call voip phone 1 to voip phone 2, then transfer from 2 to the PSTN cell phone, the caller-id on the cell phone is the outpulsed digits from voip phone 2, not voip phone 1.

The transfer is done via (a) transfer, (b) dial numbers then (c) immediately press transfer to release the call.

Thoughts?

huydien3384 · ‎12-19-2008

I guess original calling party calls from PSTN, right? If it's true, of course we must use two TDM channel to bridge two PSTN phones, so the CLID is the telephone number of your PSTN trunk.

HTH

loganseth · ‎12-19-2008

The original calling party could be internal, as well. We send out unique caller-id per station (DID).

In this scenario, we're not necessarily burning two TDM channels.

Regardless, though, I understand that when the transfer button is invoked, the original call is placed on hold while a new call begins (therefore, if the remote destination is on the PSTN, it would be the caller-id from the transferring station); however, once the transfer button is pressed the second time, the call is released, and the original caller-id is presented to the VoIP phone.

In this case, with Single Number Reach, the original caller-id shows up on the desk phone, but the operator caller id (transferring station) displays on the Remote Destination (cell phone).

My thinking is if there was a way to delay extending the call to the remote destination until after the transfer button is pressed or if there was a way (a field?) to send the original calling party, as well, to the PSTN, we could 'get around' this.

Does that makes sense?

Again, I understand a transfer to the PSTN would display the caller-id of the transferring station, but in this case, since it's a Remote Destination tied to an internal line, I'm hoping there's a clever way to send the original calling id.

(Thank you for the reply, by the way. You know how it is, you post something, sometimes people answer, sometimes not, and it's really refreshing when they do.)

mattcalderon · ‎03-02-2009

I am actually having the same issue with CUCM 7.0 only its the attendant console transferring the call that we are concerned with at this time.

Gateway is MGCP controlled PRI

Incoming call comes down the PRI into the Receptionist via Attendant Console (No pilot point)

Receptionist transfers the call to the internal DN and with SNR enabled and the call rings to the adjoining cell phone.

Same result-CLID is coming from the Main Number and not transferred number.

Any ideas on this?

loganseth · ‎03-03-2009

Good morning, Matt.

In the end, this is 'by design' according to Cisco and after my testing, I agree under the current way call transfer works.

When the OPR (well, when ANYONE) is on a call, then go to transfer it, notice on the phone what happens:

1. The original call is placed on hold

2. A new call begins

This is the reason why you see the OPRs calling number (not the original call) is because that 'new call' is the one the phone system passes to telco which advertises your CID.

The deal is that even if she presses that transfer button a 2nd time to 'release' the call immediately, the original transferred action to the PSTN was done by the 'new call' so that caller id information is passed on.

Within the phone system, Cisco can control all of this information, so once the OPR presses the 2nd transfer, Cisco can re-write the calling party information, so on your deskphone you will see the original caller, but there is no way for them to re-write the calling party once it's in the PSTN cloud.

There may be a more advanced way of doing this with calling center software (or 3rd party something), but we grew tired of trying to find the answer and left it as is.