[cisco-voip] UCCX 10.0 Calls Dropping while being transferred to another Queue by Agent

Wed Jun 18 22:20:15 EDT 2014

Brian,
I was working with TAC today and it seems we may be hitting bug ID CSCue84341
At this time we’ve got detailed tracing turned on so we’ll know for sure when the issue re-occurs.
Thanks,

:-:gm

Grace Maximuangu
Voice Solutions Engineer
Black Box Network Services
Cell: 213.268.6342
grace.maximuangu at blackbox.com<mailto:grace.maximuangu at blackbox.com>
www.blackbox.com<http://www.blackbox.com/>

[cid:image005.jpg at 01CF8B2A.5550A6F0]

From: bmeade90 at gmail.com [mailto:bmeade90 at gmail.com] On Behalf Of Brian Meade
Sent: Wednesday, June 18, 2014 11:35 AM
To: Grace Maximuangu
Cc: Gurpreet Singh Kukreja; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] UCCX 10.0 Calls Dropping while being transferred to another Queue by Agent

Do you have CallManager traces for one of these failures?

On Wed, Jun 18, 2014 at 1:25 PM, Grace Maximuangu <Grace.Maximuangu at blackbox.com<mailto:Grace.Maximuangu at blackbox.com>> wrote:
Opened a TAC case and we were unable to reproduce the issue, given the intermittent nature, fact is we can’t totally rule the “phantom calls” theory!!!.
Although:
I did look at the regions and codecs and they are set to system default:
That is ( 64 kbps (G.722, G.711)    384 kbps
I also noticed that the device pool does not have a MRGL configured. Does that mean a transcoder might not be available in the system to do the conversion between the codecs?
@Gurpreet
Per your request I am attaching the script and errors.
:-:gm

Grace Maximuangu
Voice Solutions Engineer
Black Box Network Services
Cell: 213.268.6342<tel:213.268.6342>
grace.maximuangu at blackbox.com<mailto:grace.maximuangu at blackbox.com>
www.blackbox.com<http://www.blackbox.com/>

[cid:image003.jpg at 01CF8B29.D11D6BC0]

From: Gurpreet Singh Kukreja [mailto:tycoononway1987 at gmail.com<mailto:tycoononway1987 at gmail.com>]
Sent: Monday, June 16, 2014 3:23 PM
To: Grace Maximuangu
Cc: Ted Nugent; Jason Aarons (AM); cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>

Subject: Re: [cisco-voip] UCCX 10.0 Calls Dropping while being transferred to another Queue by Agent

Grace,

- Can you verify the settings on the agent device (s), if there is any kind of forwarding done or any shared lines?
- If the setting on the agent's IPCC extension is set to 2 and 1 for max calls/busy trigger?
- Does the agent state change to Reserved on CAD even though they do not hear the ring?
- Check for any scripting loops.

The intermittent nature of this problem suggests this might be an issue when some given agents are selected out of the group and not all. This could be something to do with the configuration.
Here's what i would suggest if you'd really like to get to the bottom of this:
1) Create a copy of the script. Name it something else and save it on your desktop.
2) Upload it into Script repository. Make sure to validate to avoid any obvious errors.
3) Create a test application and test trigger. Associate the script with this new application.
4) Let the normal call flow (for the internal call) continue and have the first agent answer the call.
5) Now, let them transfer it to the newly created test trigger but before the first agent initiates the transfer, run a reactive debug on the script to see for yourself what is going wrong with and at what point..Make sure to have an agent remain logged in to take a call.
This is a bit much to do all by yourself unless you know what you're doing, and if you think it is, may be a TAC case would be the best way to go about at this point.

I could point you to some common keywords you'd find useful if at all you can look at the CCX Engine logs in this scenario:

- CTIERR
- MULT_XFER_FAIL (As per your screenshot attached, where you saw this error, "WFExecutionException: Too many transfer failures"
Share you script, if you can, may be i can take a look at it if i do get a chance.
BR
Gurpreet

On Mon, Jun 16, 2014 at 2:53 PM, Grace Maximuangu <Grace.Maximuangu at blackbox.com<mailto:Grace.Maximuangu at blackbox.com>> wrote:
Thanks for all your contributions, this is weird one, I’ve tried to replicate the issue again to no avail. The customer is treating this as production impacting.

@Gurpreet, responses to your questions

Do you immediately have the Select Resource step after the Welcome greeting in the script where the call fails? YES
Do all calls fail in this transfer scenario? NO, the issue is intermittent
Please explain the call flow like this for a failing and working call:

NO PSTN Internal Call DN>> RP-Trigger>>>Agent answers call>>Agent uses CAD to transfer the call >>>Here error message, call drops>>>Destination agent never hears a ring

@Jason
Does the CTI Port CSS have access to where they are transferring?
The CTI Ports, and agent they are transferring to have the same CSS

[cid:image004.png at 01CF8B29.D11D6BC0]
:-:gm

Grace Maximuangu
Voice Solutions Engineer
Black Box Network Services
Cell: 213.268.6342<tel:213.268.6342>
grace.maximuangu at blackbox.com<mailto:grace.maximuangu at blackbox.com>
www.blackbox.com<http://www.blackbox.com/>

[cid:image003.jpg at 01CF8B29.D11D6BC0]

From: Ted Nugent [mailto:tednugent73 at gmail.com<mailto:tednugent73 at gmail.com>]
Sent: Monday, June 16, 2014 2:02 PM
To: Gurpreet Singh Kukreja
Cc: Grace Maximuangu; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] UCCX 10.0 Calls Dropping while being transferred to another Queue by Agent

Hit the same problem a few months ago on 9.12. Turned out to be a codec lock like Brian mentioned and the call was being presented as ISAC, Ended up creating a new codec preference list and ordering g711/g722 first. That resolved it. weird thing was it was only intermittent so it was hard to track down in the traces.

On Mon, Jun 16, 2014 at 3:28 PM, Gurpreet Singh Kukreja <tycoononway1987 at gmail.com<mailto:tycoononway1987 at gmail.com>> wrote:
I believe it's also important to find out at what point (step) in the script after the agent has initiated a Xfer, does the agent hear the error message? Do you immediately have the Select Resource step after the Welcome greeting in the script where the call fails? Do all calls fail in this transfer scenario?

On Mon, Jun 16, 2014 at 11:21 AM, Grace Maximuangu <Grace.Maximuangu at blackbox.com<mailto:Grace.Maximuangu at blackbox.com>> wrote:
Description:
The agents receive a lot of calls that are not meant for their queue so they have to transfer to another queue.
Ones the agent initiate the transfer, after they hear a welcome greeting, then the system plays a fail message “we are currently experiencing technical difficulties”
And then the call is aborted.
Anyone experienced this issue before please let me know how you resolved it?
:-:gm

Grace Maximuangu
Voice Solutions Engineer
Black Box Network Services
Cell: 213.268.6342<tel:213.268.6342>
grace.maximuangu at blackbox.com<mailto:grace.maximuangu at blackbox.com>
www.blackbox.com<http://www.blackbox.com/>

[cid:image003.jpg at 01CF8B29.D11D6BC0]

________________________________
This email and any files transmitted with it are confidential and are intended for the sole use of the individual to whom they are addressed. Black Box Corporation reserves the right to scan all e-mail traffic for restricted content and to monitor all e-mail in general. If you are not the intended recipient or you have received this email in error, any use, dissemination or forwarding of this email is strictly prohibited. If you have received this email in error, please notify the sender by replying to this email.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140618/785e28b1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3491 bytes
Desc: image003.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140618/785e28b1/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 34419 bytes
Desc: image004.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140618/785e28b1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 3491 bytes
Desc: image005.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140618/785e28b1/attachment-0001.jpg>