Hello. We are trying to use the call redirect bean to transfer calls from contact center to another automated system. The other automated is a SIP system and the problem we have found is that if the SIP trunk is down, for example if we shut the port down to simulate a network outage, the call gets connected even though it is down. It appears that it never makes it to the unsuccessful branch of the call redirect bean. I assume this could be caused by the default timeout in call manager of 60 seconds and contact center thinks that it is successful redirect. I cannot find a timer associated with this bean. We did find a workaround to this by using the call consult transfer bean and applying a timeout of 2 seconds. The problem with using the call consult transfer is that the caller id shows that of the CTI port. I need the outside caller id so that it populates in the SIP system. The call redirect will actually populate the outside caller id but we have the problem stated above on the redirect always being successful when the destination is not available. Is there a setting in call manager or with the bean to change this behavior?
Just an update on this. I did find a setting in call manager that limits the number of retries for the SIP invite message. I changed this value to 1 and now I receive a busy if the SIP trunk is down in about 2 seconds from a phone that dials the SIP trunk directly. However the call redirect function in UCCX always goes to the successful branch. Why does the busy branch never get called??
I recall running into this a few years back, and it's an issue (or maybe limitation) with the call control signaling from the gateway to CUCM, and then from CUCM to UCCX. I cannot really recall the specifics, but I do know we had a TAC case open on it and everything, and nothing positive came out of it.
I want to say it had something to do with the Incoming call leg dial-peer match tells CUCM "I got it from here" at which point the CTI Message back to UCCX is "Connected", but then the Outgoing call leg is what actually fails.
MGCP did not have this problem, as CUCM was invovled in the entire setup of the call.
Ah, the old MGCP vs H323 battle.
Like I said, that was a few years back, and cisco has since added new knobs to turn in CUCM, and therefore the possibility that this behavoir can be changed now is certainly there.
Good luck on this, and please do keep everyone posted on what you find.
Please use the star ratings to help drive great content to the top of searches.
We actually did just run another test and the call redirect busy branch actually did work if I redirected to a SCCP phone instead of the SIP trunk. So this at least tells me the busy does work under the call redirect bean.
I actually do have MGCP running between my gateway and call manager but I still have this issue. Call manager must be telling the UCCX (CTI port) that the call is successful when it is actually still retrying the call.
I really need the outside caller id to hit the third party system since it uses this information to make decisions or I would just use the call consult transfer function.
I will open a TAC case on this and keep everyone updated.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
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 ...