[asterisk-bugs] [Asterisk 0018637]: No MOH on Call Park and Exceptionally long voice queue length ...

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18637 
====================================================================== 
Reported By:                jvandal
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18637
Category:                   Resources/res_features
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.39 
JIRA:                       SWP-2920 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 302166 
Request Review:              
====================================================================== 
Date Submitted:             2011-01-18 08:58 CST
Last Modified:              2011-01-20 09:19 CST
====================================================================== 
Summary:                    No MOH on Call Park and Exceptionally long voice
queue length ...
Description: 
I have 2 extensions :

- SIP 250
- IAX2 251

When both 250 / 251 are on a call and that an 250 (SIP) press
https://issues.asterisk.org/view.php?id=72 (one
touch park) then no MOH is played on 251 and have this warning message
displayed every seconds :

[2011-01-18 09:28:21] WARNING[18208]: channel.c:985 __ast_queue_frame:
Exceptionally long voice queue length queuing to IAX2/251-6506

On same setup, if 251 do the parking
(https://issues.asterisk.org/view.php?id=72) then MOH is played correctly on
250.

Any ideas where to look in order to debug ?


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0018028 Exceptionally long queue length queuing...
====================================================================== 

---------------------------------------------------------------------- 
 (0130781) aragon (reporter) - 2011-01-20 09:19
 https://issues.asterisk.org/view.php?id=18637#c130781 
---------------------------------------------------------------------- 
PRI incoming call to 6010

lab*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/6010-00000016    (None)               Up      AppDial((Outgoing
Line))
Local/6010 at default-l s at macro-default-dial Up      Dial(SIP/6010|20|tkKT|)
Local/6010 at default-l (None)               Up      AppDial((Outgoing
Line))
Zap/23-1             6010 at zap-incoming:26 Up     
Dial(Local/6010 at default-local/
4 active channels
2 of 460 max active calls ( 0.43% of capacity)

6010 transfer to park extension 7000
Call is parked on first available parking orbit 7001 using attended SIP
transfer.

lab*CLI> core show channels
Channel              Location             State   Application(Data)
Local/6010 at default-l s at default-super:1    Up      Parked Call()
Local/6010 at default-l (None)               Up      AppDial((Outgoing
Line))
Zap/23-1             6010 at zap-incoming:26 Up     
Dial(Local/6010 at default-local/
3 active channels
1 of 460 max active call ( 0.22% of capacity)

Caller on PRI channel channel hangs up

lab*CLI> core show channels
Channel              Location             State   Application(Data)
Local/6010 at default-l s at default-super:1    Up      Parked Call()
1 active channel
0 of 460 max active calls ( 0.00% of capacity)

6010 is still bridged with the park extension although the park extension
7001 is no longer bridged with the incoming PRI channel.  Some intelligence
is needed to drop the local channel bridged with the park extension if the
incoming channel is hung up.

I have attached the full CLI to this ticket:
core show channels parked and after h.txt

Of course this does not explain the exceptionally long... but I still see
that warning even after the incoming channel disappears as long as 6010 is
bridged with the park extension.  Possibly caused by the MOH RTP bridging. 
I'll re-test using native .WAV MOH 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-20 09:19 aragon         Note Added: 0130781                          
======================================================================