03-26-2009 09:38 AM - edited 03-15-2019 05:07 PM
We are currently using Call manager 4.2(3)sr2 and when a call comes into a reception phone from the voice gateway, the calling party's CLID appears on the phone. When the call is transfered internally to an extension, the CLID then becomes the reception's extension number.
Does anybody know how I can pass the original CLID through to the phone.
03-26-2009 11:22 AM
do you mean during the transfer while you have both parties on the phone??
or when you pressed transfer the 2nd time??
HTH
java
if this helps, please rate
03-27-2009 02:52 AM
When an incoming call is transfered to another extension using the transfer key, the number that appears on the other phone is the extension number of the phone that has just transfered the call and not the originating caller.
Thank you for your help I appreciate it.
03-27-2009 04:37 AM
There is the Service Parameter- Call Manager- "Always Display original Dialed Number" but this is Cluster wide
03-27-2009 06:20 AM
Hi Matthew,
Just to add a note to the great tips from Java and IPT (Happy Friday Java!)
This behaviour is always hard to explain, but I'll give it a try :) When a call comes in to Reception and is offered up for Transfer, there are really two stages;
Stage one is; the Reception phone answering and then Pressing the Transfer button. Once Transfer has been pressed the Caller is put on Hold/in a Conference loop (recieving MOH), then the Transfer destination DN is keyed in. At this point the call path is between the Reception phone/DN and the Transfer destination. This is why the CLID of the Reception DN is shown.
Stage two happens when the Transfer key is pressed a second time. This removes the original caller from the Hold/Conf loop and extends the call to the Transfer destination. Now the original PSTN call CLID is displayed.
So, the only way to show the original CLID is to complete Stage two. One way to mitigate this is to "speed up" the whole process. One way of doing this is to "re-train" the Receptionist to use this feature (or to press Transfer a second time thus completing a "Blind Transfer";
Here is the quickest current Transfer method;
Onhook Call Transfer
Modifications to the Call Transfer feature add the onhook (hangup) action as a possible last step to complete a call transfer. The Transfer On-hook Enabled service parameter, which enables onhook call transfer, must be set to True for onhook call transfer to succeed. If the service parameter is set to False, the onhook action ends the secondary call to the third party.
In the existing implementation, if user B has an active call on a particular line (from user A) and user B has not reached the maximum number of calls on this line, the Cisco IP Phone provides a Transfer softkey to user B. If user B presses the Transfer softkey (or Transfer button, if available) once, user B receives dial tone and can make a secondary call: user B dials the number of a third party (user C). Cisco CallManager provides a Transfer softkey to user B again. If user B presses the Transfer softkey again (or Transfer button, if available), the transfer operation completes.
With the new onhook call transfer implementation, user B can hang up after dialing user C's number, and the transfer completes. Both the existing and new implementations work in both the case of a blind transfer (user B disconnects before user C answers) and also in the case of a consult transfer (user B waits for user C to answer and announces the call from user A).
The previous implementation remains unchanged: user B can press the Transfer softkey twice to complete the transfer.
Have a look at how it works;
Transfer a call without talking to the transfer recipient
Press Trnsfer and enter the target number. When you hear the call ringing, hang up **(If On Hook Transfer Enabled).
If your system administrator did not enable on-hook transfer, you must press Trnsfer again to complete the transfer. To cancel the transfer, press EndCall.
Tips
When "on-hook" transfer is enabled, you can either hang up or press Trnsfer, then hang up.
From this doc;
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/4_2_3/ccmsys/a08ipph.html#wp1104993
Hope this helps!
Rob
04-03-2009 02:46 AM
Hi I sorted this issue. It was actually not a fault but rather a user error. I just want to say that I appreciate the time and effort you put into helping me. Thank you.
Mattthew
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: