Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

Call queue order

Discussion in '3CX Phone System - General' started by GWN, May 13, 2008.

Thread Status:
Not open for further replies.
  1. GWN

    GWN

    Joined:
    Dec 10, 2007
    Messages:
    60
    Likes Received:
    0
    Hello,

    I've noticed something a bit strange with the call queue feature in that it doesn't seem to process the queue order correctly. We would like it to ring the person at the top of the queue first, and then try the rest of the extensions in order. More often than not it seems to miss a few people out at the start even if they aren't busy. It should go to extension 101, 102, 103, then 105 in order. 103 wasn't online at the time of call. Below for some reason it started with 102. Sometimes it starts with 105 for no apparent reason. Anyone have any ideas as to why?

    I've left an example log below.

    Thanks,

    Andy

    17:19:24.993 Call::Terminate [CM503008]: Call(35): Call is terminated
    17:19:24.915 Call::Terminate [CM503008]: Call(35): Call is terminated
    17:19:24.853 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10002 forwards to DN:804
    17:19:16.775 CallCtrl::eek:nLegConnected [CM503007]: Call(35): Device joined: sip:102@192.168.200.102:5060
    17:19:09.134 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(35): Calling: HuntGrp:800@[Dev:sip:101@192.168.200.101]
    17:19:09.134 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(35): Calling: HuntGrp:800@[Dev:sip:105@192.168.200.103:5060, Dev:sip:105@192.168.200.15:5070]
    17:19:09.134 CallCtrl::eek:nSelectRouteReq [CM503015]: Call(35): Target is not registered: HuntGrp800:
    17:19:09.040 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(35): Calling: HuntGrp:800@[Dev:sip:102@192.168.200.102:5060, Dev:sip:102@192.168.200.12:5070;rinstance=884d4b2c7c7c6625]
    17:18:38.056 Call::RouteFailed [CM503014]: Call(35): Attempt to reach [sip:Q800@127.0.0.1:5060] failed. Reason: No Answer
    17:17:52.057 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(35): Calling: HuntGrp:800@[Dev:sip:101@192.168.200.101]
    17:17:52.057 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(35): Calling: HuntGrp:800@[Dev:sip:105@192.168.200.103:5060, Dev:sip:105@192.168.200.15:5070]
    17:17:52.057 CallCtrl::eek:nSelectRouteReq [CM503015]: Call(35): Target is not registered: HuntGrp800:
    17:17:51.979 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(35): Calling: HuntGrp:800@[Dev:sip:102@192.168.200.102:5060, Dev:sip:102@192.168.200.12:5070;rinstance=884d4b2c7c7c6625]
    17:17:48.401 CallCtrl::eek:nLegConnected [CM503007]: Call(35): Device joined: sip:
    17:17:48.151 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(35): Calling: IVR:QueueHandler@[Dev]
    17:17:43.010 MediaServerReporting::DTMFhandler [MS211000] C:35.1: xx.xx.xx.xx61756 is delivering DTMF using RTP payload (RFC2833). In-Band DTMF tone detection is disabled for this call segment.
    17:17:34.823 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10002 forwards to DN:804
    17:17:34.729 CallCtrl::eek:nLegConnected [CM503007]: Call(35): Device joined: sip:07xxxxxxxx7@xx.xxx.xx.xxx:5060
    17:17:34.385 CallCtrl::eek:nLegConnected [CM503007]: Call(35): Device joined: sip:
    17:17:34.323 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(35): Calling: IVR:804@[Dev]
    17:17:34.198 Line::printEndpointInfo [CM505003]: Provider:[Voipunlimited] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] Transport: [sip:192.168.200.214:5060]
    17:17:34.198 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10002 forwards to DN:804
    17:17:34.120 CallCtrl::eek:nIncomingCall [CM503001]: Call(35): Incoming call from 07xxxxxxxx7@(Ln.10002@Voipunlimited) to [sip:804@xxx.xxxxxxxxxxx.com:5060]
     
  2. archie

    archie Well-Known Member
    3CX Support

    Joined:
    Aug 18, 2006
    Messages:
    1,299
    Likes Received:
    0
    As a simplest load balancing mechanism, PBX makes Queue agents order randomly.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. Thona

    Joined:
    Aug 10, 2007
    Messages:
    54
    Likes Received:
    0
    Have you considered other alternatives? User selectable.

    I could see a valid point for "order", but also for "not busy longest time", so that people which just hang up get to the bottom of the list. Reuqires some good "out of office" function, though, so that you dont get all the calls when you go to the toilet ;)
     
  4. archie

    archie Well-Known Member
    3CX Support

    Joined:
    Aug 18, 2006
    Messages:
    1,299
    Likes Received:
    0
    Yes, we're going to extend queue manager functionality.
    Re "out of office" - we have LogIn/LogOut to/from queue handling. Logged out agents do not receive calls to the queue. This function is accessible either in VoIP client or in extension settings page. Also it can be (de-)activated by dial codes.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. GWN

    GWN

    Joined:
    Dec 10, 2007
    Messages:
    60
    Likes Received:
    0
    Will it be possible for a tick box to choose to use a random order or not? I can understand wanting it to be random for a sales team, but some people use a first line person, then a second line person etc.
     
  6. MickeM

    Joined:
    Mar 13, 2009
    Messages:
    8
    Likes Received:
    0
    You would think that up & down buttons would have a purpose when setting up a new queue...

    My solution is to have a "Second-line support" that is a group called if nobody answers in my first queue.
    Position will be lost, but at least I wont call the wrong person first.

    /3cx Newbie :|

    ---------------------
    Going live with 3cx on March 21
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. GWN

    GWN

    Joined:
    Dec 10, 2007
    Messages:
    60
    Likes Received:
    0
    I managed to partially solve this in version 7 (think I tried this in previous versions but it didn't work).

    Rather than pressing a button from a digital assistant to be sent straight into the Call queue, it goes to a call group first with the first line support members in it. This will make sure it always goes to them first unless they are busy in which case it directs to the normal random call queue. Only downsides I've found is that the first line users can't log out the call queue and don't get the intro, and the callid has the call group as the ID rather than the call queue. Other than that it ensures their phone always rings before the second line team.

    Hope that helps until the advanced call queuing features go live!

    Regards,

    Andy
     
  8. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    Hi Andy,

    please check the "thread" http://www.3cx.com/forums/ring-strategy-on-call-queue-8984.html
    I hope it may provide some additional information for your investigations.

    Thanks
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.