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.
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.)
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.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...