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.
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.
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.
When "on-hook" transfer is enabled, you can either hang up or press Trnsfer, then hang up.
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...