[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