In this case there is only one callmanager (3.1) since it is a small office. So nothing fancy there.
The scenario is this: When the receptionist goes to lunch, she forwards her phone to a co-worker (Ms. D). Calls come in from the outside, and Ms. D transfers them to the correct users inside. Sometimes, a caller gets lost. For example, Ms. D gets a call for Mr. Smith. She says, "one moment please", and pushes transfer and dials smith's number. She talks to smith, announces the caller, and attempts to transfer him, but nothing happens. "where's the call?" Turns out the caller is still on hold, but no one can retrieve him. Eventually he hangs up after about 10 minutes and calls back ticked off that he was left on hold for 10 minutes. This is an intermittant problem.
In situations when the call transfer failed, can you check to see whether the phone numbers were shared lines ?
You could be hit by the bug CSCdx37948. Here is a description of the bug.
When calling from the PSTN to an Ip phone and doing a consultative call transfer to a shared line sometimes, around 10% of the calls are failing and the end destination hears music on hold instead of connecting the two legs.
Call manager version 3.1(3)a with spc installed .
IP phone load : P00303010107.
Consultative transfer to a shared line fail intermittently, around 10 % of the calls are
failing , the destination party hears Music on hold instead of connecting the call.
From the ccm traces we have the following:
When the user receiving the call from the PSTN side press TRANSFER (to transfer the call to
the shared line) the 2nd time, the call state for both calls in the IPphone "transferring the call" should go to "on hook",
So the call can be transferred to the end device (shared line phone), but it does NOT! It
goes "on hold" state instead of "on hook" state, therefore MoH is played..
The user tried many times and sometimes it works fine. But at the moment there is no known workaround.
Since Cisco suggests that there is no workaround, I would think an upgrade to the latest release of CCM might help.
It does help... I spent a lot more time looking at the traces and the setup. Looks like there are no share lines here. No Inter-cluster trunks.
That error (H225D) I put at the top is not really relevent. I had not compensated for the time zone! Don't laugh! It was just magically exactly 2 hours from the problem... Anyway... I don't see any errors that occur consistently right during this loss of the transfered call.
I see the user A calls Receptionist which is forwarded to B, B connects with A and pushes Transfer. Dials C's extention, C picks up and talks to B. B pushes Transfer button again and nothing happens. So B pushes transfer again, and then again... and then goes off hook and on hook and all sorts of crazy things to get the caller back, but to no avail. This happens maybe 10% of the time. I guess this is just a "feature" of 3.1, and we have to live with it...
I'll get more traces hopefully and see if there are any other hints, or patterns that emerge.
I too had the same problem at one of our satellite offices. i.e. intermittent transfer failure exactly as described above. We upgraded to 3.1(4b)-spC and things seem to have been better since then, but i can't say for sure whether the problem has definitely been resolved.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...