[asterisk-users] Asterisk 13.12.2 : strange queue behaviour
Jonas Kellens
jonas.kellens at telenet.be
Mon Nov 21 10:05:11 CST 2016
On 21-11-16 15:17, Matthew Jordan wrote:
>
> On Mon, Nov 21, 2016 at 7:05 AM, Jonas Kellens
> <jonas.kellens at telenet.be <mailto:jonas.kellens at telenet.be>> wrote:
>
> Hello
>
> when using Asterisk version 13.12.2 I notice that it takes up to
> 30 seconds (sometimes even longer) for a call queue to call its
> members.
>
> Example 1 :
>
> [Nov 21 08:17:57] pbx.c: Executing [queue at pbx-routing:15]
> Queue("SIP/incoming-00000246", "myqueue1,,,,300,,,") in new stack
> [Nov 21 08:17:57] res_musiconhold.c: Started music on hold, class
> 'default', on channel 'SIP/incoming-00000246'
>
> [Nov 21 08:18:26] pbx.c: Executing [mysip692 at CallFromQueue:1]
> NoOp("Local/mysip692 at CallFromQueue-0000003c;2", "") in new stack
> [Nov 21 08:18:26] app_queue.c: Called Local/mysip692 at CallFromQueue
> [Nov 21 08:18:26] pbx.c: Executing [mysip692 at CallFromQueue:3]
> Dial("Local/mysip692 at CallFromQueue-0000003c;2", "SIP/mysip692") in
> new stack
> [Nov 21 08:18:26] app_dial.c: Called SIP/mysip692
>
>
> Example 2 :
>
> [Nov 21 08:20:11] pbx.c: Executing [queue at pbx-routing:15]
> Queue("SIP/incoming-00000255", "myqueue1,,,,300,,,") in new stack
> [Nov 21 08:20:11] res_musiconhold.c: Started music on hold, class
> 'default', on channel 'SIP/incoming-00000255'
>
> [Nov 21 08:20:45] app_queue.c: Called Local/mysip692 at CallFromQueue
> [Nov 21 08:20:45] pbx.c: Executing [mysip692 at CallFromQueue:1]
> NoOp("Local/mysip692 at CallFromQueue-00000040;2", "") in new stack
> [Nov 21 08:20:45] pbx.c: Executing [mysip692 at CallFromQueue:3]
> Dial("Local/mysip692 at CallFromQueue-00000040;2", "SIP/mysip692") in
> new stack
> [Nov 21 08:20:45] app_dial.c: Called SIP/mysip692
>
>
> I did not see this behaviour in previous Asterisk versions.
>
> Could this be a bug ?
>
>
> There's not enough information here to know what is preventing the
> call from occurring.
>
> I'd look at a debug log between the caller entering the Queue and the
> outbound call being made. That should illustrate what is causing the
> delay.
>
> --
> Matthew Jordan
Hello
and what exactly am I looking for in the debug logs ?
I have generated debug output and re-produced the issue.
Again 23 seconds before calling the queue member :
[Nov 21 16:23:33] pbx.c: Executing [queue at pbx-routing:15]
Queue("SIP/incoming-00004e6e", "myqueue1,,,,300,,,") in new stack
[Nov 21 16:23:33] res_musiconhold.c: Started music on hold, class
'default', on channel 'SIP/incoming-00004e6e'
[Nov 21 16:23:56] pbx.c: Executing [mysip692 at CallFromQueue:1]
NoOp("Local/mysip692 at CallFromQueue-0000081a;2", "") in new stack
[Nov 21 16:23:56] app_queue.c: Called Local/mysip692 at CallFromQueue
[Nov 21 16:23:56] pbx.c: Executing [mysip692 at CallFromQueue:2]
NoOp("Local/mysip692 at CallFromQueue-0000081a;2", "exten = mysip692") in
new stack
[Nov 21 16:23:56] pbx.c: Executing [mysip692 at CallFromQueue:3]
Dial("Local/mysip692 at CallFromQueue-0000081a;2", "SIP/mysip692") in new stack
[Nov 21 16:23:56] app_dial.c: Called SIP/mysip692
[Nov 21 16:23:56] app_dial.c: SIP/mysip692-00004e86 is ringing
[Nov 21 16:23:56] app_queue.c: Local/mysip692 at CallFromQueue-0000081a;1
is ringing
Could it be that it is because my Queue member 'mysip692' is occupied in
another bridge (call) ?
This I see in the logs just before the Call Queue starts calling the
queue member :
[Nov 21 16:23:55] bridge_native_rtp.c: Locally RTP bridged
'SIP/mysip-00004e6a' and 'SIP/incoming-00004e63' in stack
[Nov 21 16:23:55] bridge_channel.c: Channel SIP/incoming-00004e63 left
'native_rtp' basic-bridge <fed056d3-669a-493d-a4bd-f0d9ab0102a7>
[Nov 21 16:23:55] bridge_channel.c: Channel SIP/mysip-00004e6a left
'native_rtp' basic-bridge <fed056d3-669a-493d-a4bd-f0d9ab0102a7>
A bit too coincidal, no ?
So then it has something to do with the bridging ?
I did not have this behaviour in previous Asterisk versions.
Kind regards.
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20161121/bab62b2c/attachment.html>
More information about the asterisk-users
mailing list