Call redirect and call consult transfer

Unanswered Question
Apr 18th, 2012

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
pbradley435 Wed, 04/18/2012 - 14:17

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

Anthony Holloway Wed, 04/18/2012 - 14:30

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.

pbradley435 Wed, 04/18/2012 - 14:46

Hello Anthony,

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.

Actions

Login or Register to take actions

This Discussion

Posted April 18, 2012 at 12:23 PM
Stats:
Replies:3 Avg. Rating:
Views:734 Votes:0
Shares:0
Tags: uccx8.5
+

Related Content

Discussions Leaderboard