locked
Lync - Calls not being forwarded when all reponse group attendants are busy. Instead, system assigns the call to one of the attendants, causing calls to be dropped RRS feed

  • Question

  • Users from a response group have reported that, when all members of the response group are on the phone and a new call is placed, that call is automatically assigned to one of them (causing the calls they were on to drop), instead of being forwarded to voicemail.

    I checked the response group and queue settings in the control panel and calls should be forwarded to voicemail after 20 seconds so I am not sure why this is happening.

    Also, we have a monitoring server so I checked the diag reports for calls made/received by one of these users (who reported being disconnected at an specific time) but I could see no evidence of any calls being forcibly dropped.

    I've asked the members of that response group to write down the time, the number they are on call with, and the number that disconnects them the next time this occurs but, in the meantime, I'd appreciate if anyone could let me know if they ever come accross a similar problem.

    We have two reponse groups (each one with one queue) and a few of the users belong to both r.groups so I am wondering if that could be behind this behaviour

    Thanks in advance!

    Max 

    Thursday, October 4, 2012 3:18 PM

All replies

  • Hi MaxMassoni,

    Are these calls coming in from the PSTN that are being broken?  If so, what type of connection/device are you using?

    Have you tried calling the RGS internally from Lync?

    Does this happen on one or all RGS?

    One quick thing to try is disabling REFER support in the trunk configuration to see if this resolves the issue.



    Adam Curry, UC Consultant, Unify Square Inc. (Blog, Twitter)

    Looking for Lync Users Groups in your area? Check out Lync Users Group

    Thursday, October 4, 2012 3:27 PM
  • Thanks a lot Adam!

    I will test calling them internally when they are all busy to check whether that cuts them off. I have had reports from users in both RGS (we have only two).

    If internal Lync calls dont show the same behaviour then I will disable REFER Support in the trunk config.

     

    Max

    Friday, October 5, 2012 7:32 AM
  • Have you assign a voice policy to the RGS Group if you use call forward to a external number from the RGS?

    regards Holger Technical Specialist UC

    Friday, October 5, 2012 8:37 AM
  • Hi,

    Do you Enable queue overflow and set Maximum number of calls in the queue configuration? If yes, please set Newest call to be forwarded.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, October 8, 2012 7:52 AM
  • Hi MaxMassoni,

    Do you have any luck now?


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, October 12, 2012 2:13 AM
  • OK I have tried to reproduce the problem in various ways over the past month without success... I had another report from one of the agents today who complained of being on a call with someone when another call came in, terminated the call she was on and then disconnected. I had a look at the monitoring server reports and this is what I found:

    As you can see the agent (Ruth) was on a call initiated at 12:17 (the one in the bottom) which was suddenly terminated at 12:29:54 as she accepted another call from via the RSG at 12:29:53. The BYE response sent by the her when terminating the first call states "51004; reason = Action initiated by the user"

    The second call (12:29:53) was initiated by the RSG Service to Ruth who accepted the call and terminated it with "51000; reason=Call terminated by transferee on successful transfer" indicating a successful transfer.

    The third call (top one) was made by Ruth to the Mediation Server and shows as having been referred by the RSG. It terminates with "51004; reason = Action initiated by the user"

    Ruth is adamant that she did not accept the call and it was forcefully transferred to her. Looking at the Response Group reports it does not look like the other agents were all busy but rather that the call was transferred to/accepted by Ruth before anyone else had a chance to accept it:

    Looking at the Response Group queue properties I can see the following:

    Groups assigned to the queue: Receptionists

    Participation Policy: Informal

    Routing Method: Attendant

    Enable queue time-out: yes

    Time-out period: 15 seconds

    Call action: Forward to voicemail

    SIP address: reception@domain.com

    Enable queue overflow: yes

    Maximum number of calls: 5

    Forward the call: Newest call

    Call action: Forward to voice mail

    SIP address: reception@domain.com

    I'm slightly confused as to how the Attendant routing method works. According to the Micorosft Lync Server 2010 Response Group application resource kit (http://www.microsoft.com/en-us/download/details.aspx?id=5645) the match making process works in the following way:

    "An agent is eligible for a call only if the following is true:<o:p></o:p>

    1.    The agent is signed-in to their agent groups.<o:p></o:p>

    2.    The agent is available.<o:p></o:p>

    3.    The agent is not currently receiving another response group call.<o:p></o:p>

    4.    The agent has not declined the call within the last 60 seconds.<o:p></o:p>

    If you have selected Attendant routing when configuring your routing method, criteria two and three in the previous list are ignored. The agent must still be signed into Microsoft Lync 2010."

    That leads me to believe that by selecting Attendant routing we could run into a scenario where an agent gets assigned a call despite already being on a call! Could that be we are seeing such behaviour?

    <o:p></o:p>

    <o:p></o:p>

    Wednesday, November 14, 2012 4:06 PM
  • I created a new post for this issue as I believe it is slightly different from what I originally posted. here is the link to the new one: http://social.technet.microsoft.com/Forums/en-us/ocsvoice/thread/2f7dc5d3-1455-4761-a42f-20248b2a31e6 
    • Proposed as answer by Max Massoni Wednesday, November 14, 2012 6:27 PM
    Wednesday, November 14, 2012 6:27 PM