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

Wed Jun 18 17:29:57 EDT 2014

Unless it's changed recently, the MRGL will only define preference based on
ordered MRGs. If resources are not defined in an MRG/MRGL then they will
find their way into the Null-MRGL in which case equal resources will be
round-robbined. You checked the ordering of the Codec preference lists for
the regions and confirmed that G711/g722 were ordered first? I'm assuming
that's what you meant?

On Wed, Jun 18, 2014 at 1:25 PM, Grace Maximuangu <
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
>
> grace.maximuangu at blackbox.com
>
> www.blackbox.com
>
>
>
> [image: bbox logo.JPG]
>
>
>
> *From:* Gurpreet Singh Kukreja [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
>
> *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> 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
>
>
>
>
>
> :-:gm
>
>
>
> Grace Maximuangu
>
> Voice Solutions Engineer
>
> *Black Box Network Services*
>
> Cell: 213.268.6342
>
> grace.maximuangu at blackbox.com
>
> www.blackbox.com
>
>
>
> [image: bbox logo.JPG]
>
>
>
> *From:* Ted Nugent [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
> *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> 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> 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
>
> grace.maximuangu at blackbox.com
>
> www.blackbox.com
>
>
>
> [image: bbox logo.JPG]
>
>
>
>
> ------------------------------
>
> 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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> 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/93e1f44b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 3491 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140618/93e1f44b/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 34419 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140618/93e1f44b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3491 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140618/93e1f44b/attachment-0001.jpg>