We are having trouble retriving calls put on hold at our call centers.
We have the same behavior on both CM platforms at seperate locations.
A call comes in on 6300 the main call center number..
Phone A picks up the call on 6300 and puts the caller on hold.
A second call comes in on 6300 it does not roll to 6301 because the caller on 6300 phone A is on hold. Phone B picks up the second call on 6300. Now phone A has an x over the phone icon next to line 2 6300. Phone A can not retrive the caller on hold on 6300 until phone B finishes the call it has on 6300.
With all those line appearances and what not I would make the decision to turn off Call-Waiting Globally on the system. You can test the theory by doing it on one phone first however.
CM > Device > Phone > Find > Select Phone > Select Each Line Appearance for 6300 6301 6302 6303 and turn Call-Waiting OFF
See if that fixes your problem. You will notice a couple of annoying things when you do this however. For instance: you won't be able to see the caller ID of the 2nd incoming call because it is hidden behind the first call screen. Hard to explain, but you will see.
If you like what you see and it fixes your problem Consider setting it globally
CM > Service > Service Parameters > Server > Cisco CallManager > CallWaitingEnable = FALSE ( About 11 lines down on my CM version)
Do your other extensions behave correctly, that is does 6780 go to Unity when it is busy?
If you Forward All on 6300 to 6301 do calls behave correctly then?
You might want to try to remove 6300-04 from all but one phone and try to get it to work. I have on rare occasion run into situations where deleting and then
recreating has solved some quirky problems.
Also, not that this is causing the problem, but it could cause one. You have created a loop, by routing the last DN 6304 back to 6300. It would be safer to send FB FNA on 6304 to Unity, where you could perhaps offer to dial by name, or leave a message in general mailbox, or just make a slightly winded greeting stating all operators are busy and then send them back to 6300 to try again. Or you could send it to a failover DN somewhere else.
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...