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.
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...