locked
RGS routes calls to Busy agents (alredy In a Call)... RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi guys,

    our Call Centre agents are reporting they get 2nd incoming call transferred via the same workflow as the 1st call.
    Their status is In a Call and obviously call should not be routed to them.

    Screenshot
    http://img855.imageshack.us/img855/8094/rgsbug.jpg

    Apparently this happens when there are a whole bunch of incoming calls.

    Do you know what is the coded logic for RGS quering agents status?
    Does it query RTC db for agents status?

    My guess is there's some OCS server component underperforming and RGS application queries something (db?) to find this particular agent status is Available (not updated yet to In A Call).

    OCS 2007 R2 Front-End is running on 3.5.6907.221 updates (RTCC/3.5.0.0 Response_Group_Service)

    Mediation Server
    RTCC/3.5.0.0 MediationServer/3.5.6907.196

    thanks for any hint

     

    Thursday, November 24, 2011 10:39 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Just to follow up. We opened the SEV-A case with the Lync Product group. They were able to reproduce the exact error described in their lab environment. Once they attempted to fix the issue, they made the product unstable to the point that it was unusable. The Lync product team has confirmed that it is an issue as that it will not be fixed in this version of Lync. It is being considered as a possible fix for wave 15.

    Sorry for the long wait, but we have been waiting for the Lync product team to complete their testing. We are looking to 3rd parties for our call center application.

    Bob Ausmus, System Administrator
    Blog 
    Twitter @bobausmus

    • Proposed as answer by Bob Ausmus Wednesday, April 25, 2012 3:06 PM
    • Marked as answer by plug n pray Saturday, May 5, 2012 3:32 PM
    Wednesday, April 25, 2012 3:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
     

    Pap3rkut,

    Sad to say but we tried EVERY routing method out there. All routing methods presented the same behavior. We tried a host of different scenarios and all failed. It appears there is an issue with the call handling and the match-making service that is causing this. This is NOT, I repeat, NOT a performance issue as described earlier in Santosh_More's reply.

    Just in case your are interested.... Here is the MS Case Number:  SR 112022755545407

    And here is what the letter from Microsoft stated:

    Dear Bob Ausmus,

    I am writing you concerning your support case 112022755545407 (RGS agents receive a toast for second waiting call in RGS once they accept the first waiting call from RGS) with Microsoft Customer Service and Support.

    <You> reported that there is an issue using Response Group Service with Lync 2010. Under certain circumstances, an RGS agent would receive a second toast on the screen once the first call is accepted from the queue.

    As a result the positive user experience for the agents hosted on the Lync 2010 Response Group Service is hampered.
    Lync 2010 Product Feature Team investigated the issue, collaborated with internal groups and understood the root cause of the issue. They have confirmed that unfortunately, developing an architecturally sound solution would require rigorous testing and the current functionality cannot be easily changed without risking destabilizing the product if delivered in the form of an interim patch.

    They have advised several workarounds for this issue.
    1. Declining the second toast once it is alerted on the agent desktop <This is not a solution>
    2. Reducing the alert time for the agent <This did not work either>

    Given the very high risk of a potential fix and that there are two workarounds available, we are unable to accept the request for the current major release of Lync Server 2010. It will be considered for the next major release of Lync.

    We hope you understand the challenges explained, and respect the decision that was reached. I personally thank you for continuing to use Microsoft products and services, your valuable feedback, and your understanding as we partner to look for the best possible solution.

    There You have it. Broken and they aren't going to fix it. Yeah..... #FAIL

    Bob Ausmus, System Administrator
    Blog 
    Twitter @bobausmus

    • Marked as answer by plug n pray Saturday, May 5, 2012 3:32 PM
    Friday, May 4, 2012 2:57 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi plug,

    A workflow defines the behavior of a call from the time the phone rings to the time somebody answers the call. The workflow can include queue and routing information, as well as interactive voice response.

    For detail, see this document Creating Workflows. Hope it’s useful.

    Monday, November 28, 2011 3:09 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    thx, but I already got this workflow configured.

    Let me reword the scenario:
    - the Agent gets an incoming call notification transferred via the workflow
    - the Agent answers the call
    - Agent see his/her presence updated to "In a Call"
    - there is ANOTHER incoming call notification transferred via the very same workflow from other Caller

    This should never happen as RGS doesn't route call to Busy agents.
    Unless it doesn't know Agent status is not "Avaliable" anymore..

     

    Monday, November 28, 2011 1:16 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

     

    plug n pray,

     

    "Match Making" component of RGS queries database for Agent's presence State.

    It is possible that it may not be getting the updated State because of performance issues.

    You can use  RGS performace Counters to monitor the activity.

    "LC:RGS - 01 -Response Group Service Match Making"\"Total Number of presence notifications received"

    "LC:RGS - 01 -Response Group Service Match Making"\"Total Number of presence subscriptions terminated"

     

    Also please review the capacity of your server

    http://technet.microsoft.com/en-us/library/dd425159(office.13).aspx 

     

    Table 6. Response Group Service User Model

    Component Per Enterprise deployment Per Standard Edition server

    Active agents (formal and informal)

    1,200

    1,200

    Number of standard Response Groups

    450

    150

    Number of queues used

    One unique queue for each hunt group, two for the One-Level Interactive response group

    One unique queue for each hunt group, two for the One-Level Interactive response group

    Distribution of routing methods on groups

    Parallel routing: 40%

    Longest idle: 40%

    Serial: 10%

    Round robin: 10%

    Parallel routing: 40%

    Longest idle: 40%

    Serial: 10%

    Round robin: 10%

    Percentage of workflows that use speech recognition in their interactive voice response (IVR) versus workflows that use only dual tone multi-frequency (DTMF) in their IVR

    Speech recognition/Text-to-speech (SR/TTS) + DTMF: 50% DTMF: 50%

    SR/TTS + DTMF:50% DTMF: 50%

    Number of hunt groups (mix of 50% simple and 50% complex hunt groups)

    600

    300

    Average number of agents per group

    10 agents

    10 agents

    Average number of groups an agent is a member of

    Two groups

    Two groups

    Number of groups per queue (average)

    90%: One group 10%: Two groups

    90%: One group 10%: Two groups

    Number of simultaneous response group calls

    480

    60

    Average call duration (IVR portion + music on hold)

    30 seconds

    30 seconds

    Average call duration with the agent

    3 minutes

    3 minutes

    Number of sign-in/sign-out cycles for formal agents in a day (based on an 8-hour day)

    4

    4

     

     

     

    Table 7. Maximum Supported Users for Each Topology

    Topology Servers required Maximum users supported

    Standard Edition server

    One Standard Edition server

    5,000

    Enterprise pool, consolidated configuration

    Eight Enterprise Edition Front-End Servers running all server roles

    One Back-end SQL Server

    100,000

    Dd425159.note(en-us,office.13).gifNote:
    If deploying only IM and presence, Office Communications Server 2007 R2 supports 200,000 client end points, where each end point is a client program, such as Communicator, based on eight Front End Servers and a 16-core computer running the Microsoft SQL Server database software. The back-end database must run on a 4-way processor, quad core, or 8-way, dual core, 2.0 GHz+ computer.

     

    -Santosh

     

    • Marked as answer by plug n pray Monday, December 5, 2011 2:25 PM
    • Unmarked as answer by plug n pray Saturday, May 5, 2012 3:28 PM
    Saturday, December 3, 2011 8:37 AM
  • Question
    Sign in to vote
    0
    Sign in to vote


    I am having this same issue in Lync server. I see that your answer was related to performance but specifically can you tell me what you did to correct the issue? Where did you fix the performance issue?

    Thanks for your help

    Bob Ausmus, System Administrator
    Blog 
    Twitter @bobausmus

    Wednesday, February 29, 2012 9:31 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    No clean resolution found.

    There were no hits for this counter
    "LC:RGS - 01 -Response Group Service Match Making"\"Total Number of presence subscriptions terminated"

    I've asked operators to just close incoming call toast - it bounces the caller back to queue without the caller noticing.
    Eventually RGS hunts truly Available agent..
    Thursday, March 1, 2012 1:31 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Just to follow up on this. I have opened a SEV-A case with Microsoft on this issue. They were able to reproduce the behavior in their lab. Possible bug in the code. I will keep you up to date on the resolution.

    Bob Ausmus, System Administrator
    Blog 
    Twitter @bobausmus

    Thursday, March 1, 2012 2:54 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Just to follow up. We opened the SEV-A case with the Lync Product group. They were able to reproduce the exact error described in their lab environment. Once they attempted to fix the issue, they made the product unstable to the point that it was unusable. The Lync product team has confirmed that it is an issue as that it will not be fixed in this version of Lync. It is being considered as a possible fix for wave 15.

    Sorry for the long wait, but we have been waiting for the Lync product team to complete their testing. We are looking to 3rd parties for our call center application.

    Bob Ausmus, System Administrator
    Blog 
    Twitter @bobausmus

    • Proposed as answer by Bob Ausmus Wednesday, April 25, 2012 3:06 PM
    • Marked as answer by plug n pray Saturday, May 5, 2012 3:32 PM
    Wednesday, April 25, 2012 3:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Bob,

        Do you happen to know if this is specific to a specific routing method?  We are having the same problem and are using the Longest Idle method.  I'm wondering if this could be solved by using another routing method such as Round Robin or Parallel.  I'm assuming if an Agent is on a call they won't be present with a call and in the case of Parallel, calls would be placed on hold if all Agents are busy.

    Thanks,

    Ricardo

    Friday, May 4, 2012 2:28 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
     

    Pap3rkut,

    Sad to say but we tried EVERY routing method out there. All routing methods presented the same behavior. We tried a host of different scenarios and all failed. It appears there is an issue with the call handling and the match-making service that is causing this. This is NOT, I repeat, NOT a performance issue as described earlier in Santosh_More's reply.

    Just in case your are interested.... Here is the MS Case Number:  SR 112022755545407

    And here is what the letter from Microsoft stated:

    Dear Bob Ausmus,

    I am writing you concerning your support case 112022755545407 (RGS agents receive a toast for second waiting call in RGS once they accept the first waiting call from RGS) with Microsoft Customer Service and Support.

    <You> reported that there is an issue using Response Group Service with Lync 2010. Under certain circumstances, an RGS agent would receive a second toast on the screen once the first call is accepted from the queue.

    As a result the positive user experience for the agents hosted on the Lync 2010 Response Group Service is hampered.
    Lync 2010 Product Feature Team investigated the issue, collaborated with internal groups and understood the root cause of the issue. They have confirmed that unfortunately, developing an architecturally sound solution would require rigorous testing and the current functionality cannot be easily changed without risking destabilizing the product if delivered in the form of an interim patch.

    They have advised several workarounds for this issue.
    1. Declining the second toast once it is alerted on the agent desktop <This is not a solution>
    2. Reducing the alert time for the agent <This did not work either>

    Given the very high risk of a potential fix and that there are two workarounds available, we are unable to accept the request for the current major release of Lync Server 2010. It will be considered for the next major release of Lync.

    We hope you understand the challenges explained, and respect the decision that was reached. I personally thank you for continuing to use Microsoft products and services, your valuable feedback, and your understanding as we partner to look for the best possible solution.

    There You have it. Broken and they aren't going to fix it. Yeah..... #FAIL

    Bob Ausmus, System Administrator
    Blog 
    Twitter @bobausmus

    • Marked as answer by plug n pray Saturday, May 5, 2012 3:32 PM
    Friday, May 4, 2012 2:57 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Bob,

        I very much appreciate the effort you've gone through working this problem and at least providing an answer to me to report back to the supervisors and managers expiriencing this issue.  In short, that really sucks.  Best of luck to you and I hope Microsoft resolves this sooner than later.

    Thanks,

    Ricardo

    Friday, May 4, 2012 3:40 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Anybody knows is there even a hope to get this fixed on the Lync 2010? I can see "plug n pray" had this issue on the O2007R2. And this sounds very much similar with this case:

    http://social.technet.microsoft.com/Forums/en-US/ocsclients/thread/188fd6cd-cbd8-40e1-b969-a62609cca25a/

    Where you cannot avoid second phone call if you are already having one.

    Or has anybody tested this on the Lync 2013?

    Petri

    Monday, November 5, 2012 2:53 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Bob,

        I've recently been revisiting this issue.  Have you happened to have heard from Microsoft or tested yourself if this issue is resolved by Lync 2013?  I've budgeted to have this installed this summer and was hoping it could solve our problems with the response groups.

    Thanks,

    Ricardo

    Monday, March 25, 2013 4:59 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Bob any update?  Do you know if this was ever corrected by MS?
    Friday, August 30, 2013 3:31 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I am experiencing this exact issue in Lync 2013. I haven't yet investigated whether this might be performance related, but before I do wondered if anyone knew if MS attempted to fix this in Lync 2013?

    Andrew Morpeth
    Lync Server Specialist - Auckland, NZ
    Check out my blog

    Wednesday, January 22, 2014 12:02 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Sorry guys, I have been in dream world and slacking on my posts. I have heard that this is NOT corrected in 2013. It didn't make the cut from what I have been told.

    We bailed on using Lync for our Call Center. We use it for the company phone system, but for the call center we use Interactive Intelligence (I3) which integrates with Lync.

    Hope this helps...

    Bob Ausmus, System Administrator
    Blog 
    Twitter @bobausmus

    Friday, January 24, 2014 2:50 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    This is a known issue in Lync Server 2013.

    If you want to Vote to have this issue addressed, please click below:
    http://lync.ideascale.com/a/dtd/response-group-routes-calls-to-busy-agent-bug/559917-16285

    +Say thanks and observe basic forum courtesy:
    +If this post answered your question, Mark As Answer
    +If this post was helpful, Vote as Helpful

    windowspbx blog: my thots/howtos
    see/submit Lync suggestions here: simple and public

    Friday, January 24, 2014 3:04 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Looks like Skype for Business Server June 2015 update may have fixed this issue.
    https://support.microsoft.com/en-us/kb/3068197

    anyone that is experiencing it, can you verify it has fixed your scenario?
    Thanks!

    +Say thanks and observe basic forum courtesy:
    +If this post answered your question, Mark As Answer
    +If this post was helpful, Vote as Helpful

    windowspbx blog: my thots/howtos
    see/submit Lync suggestions here: simple and public

    Monday, June 22, 2015 1:03 PM