| Summary: | ASTERISK-16783: Playback stalls when playing demo-congrats to an IAX2 channel | ||||
| Reporter: | Tim Panton (tpanton) | Labels: | |||
| Date Opened: | 2010-10-08 08:29:33 | Date Closed: | 2010-11-18 14:13:23.000-0600 | ||
| Priority: | Major | Regression? | No | ||
| Status: | Closed/Complete | Components: | Channels/chan_iax2 | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) stall-gdb.log | |||
| Description: | Calls from IAX to test context often stall (50% of the time?) in playback. Call is up, but no progress made. Problem does not occur in SIP calls. ****** ADDITIONAL INFORMATION ****** [voiptalk-in] exten => _XX.,1,Answer() exten => _XX.,n,Wait(1) exten => _XX.,n,Playback(demo-congrats) exten => _XX.,n,NoOp(dropthrough) exten => _XX.,n,Playback(vm-goodbye) exten => _XX.,Hangup() | ||||
| Comments: | By: Leif Madsen (lmadsen) 2010-10-12 11:21:30 I've marked ASTERISK-16778 as related to this issue, although it may end up they are duplicated. By: Russell Bryant (russell) 2010-10-12 14:28:05 What timing module do you have loaded? The playback should be driven by a timing interface, so it sounds like whichever one you have loaded might be not operating properly for some reason. A "thread apply all bt" of the Asterisk process while a call is up that isn't working might be insightful. By: Tim Panton (tpanton) 2010-10-13 08:06:23 I've got res_timing_timerfd.so built and configured - how can you definitively tell what is _loaded_ ? (Internal timing is on) I've also tested chan_skype and it seems not to do it either - so RTP is immune - IAX2 bug ? gdb output is attached. By: Tim Panton (tpanton) 2010-11-04 04:13:57 Small update on this - I've built stock 1.8.0 from tarball and this is reproducible. It only happens with timerfd - using pthreads timer seems much better (if less accurate). By the way, you can see which timer is in use with timing test on the cli. By: Jeff Peeler (jpeeler) 2010-11-04 14:52:48 Using your sample dialplan I couldn't reproduce any playback problems. Any additional information as to what is required to make it occur would be appreciated. By: Tim Panton (tpanton) 2010-11-04 14:56:41 I can only say that it happened on _both_ 1.8 systems I've built - both of which are Suse (but different versions) and only if the timing source is timer_fd . I can provide remote access if needed. By: Jeff Peeler (jpeeler) 2010-11-04 15:25:37 I sent an email to your registered email address for remote access. By: Jeff Peeler (jpeeler) 2010-11-05 17:39:00 If you comment out the "needqueue = 0" line in channel.c it forces use of the alert pipe and playback works as intended. Still working out the better fix for committing. By: Digium Subversion (svnbot) 2010-11-08 15:58:15.000-0600 Repository: asterisk Revision: 294277 U branches/1.6.2/include/asterisk/timing.h U branches/1.6.2/main/channel.c U branches/1.6.2/main/timing.c U branches/1.6.2/res/res_timing_timerfd.c ------------------------------------------------------------------------ r294277 | jpeeler | 2010-11-08 15:58:15 -0600 (Mon, 08 Nov 2010) | 16 lines Fix playback failure when using IAX with the timerfd module. To fix this issue the alert pipe will now be used when the timerfd module is in use. There appeared to be a race that was not solved by adding locking in the timerfd module, but needed to be there anyway. The race was between the timer being put in non-continuous mode in ast_read on the channel thread and the IAX frame scheduler queuing a frame which would enable continuous mode before the non-continuous mode event was read. This race for now is simply avoided. (closes issue ASTERISK-16783) Reported by: tpanton Tested by: tpanton I put tested by tpanton because it was tested on his hardware. Thanks for the remote access to debug this issue! ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=294277 By: Digium Subversion (svnbot) 2010-11-08 15:59:46.000-0600 Repository: asterisk Revision: 294278 _U branches/1.8/ U branches/1.8/include/asterisk/timing.h U branches/1.8/main/channel.c U branches/1.8/main/timing.c U branches/1.8/res/res_timing_timerfd.c ------------------------------------------------------------------------ r294278 | jpeeler | 2010-11-08 15:59:46 -0600 (Mon, 08 Nov 2010) | 23 lines Merged revisions 294277 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r294277 | jpeeler | 2010-11-08 15:58:13 -0600 (Mon, 08 Nov 2010) | 16 lines Fix playback failure when using IAX with the timerfd module. To fix this issue the alert pipe will now be used when the timerfd module is in use. There appeared to be a race that was not solved by adding locking in the timerfd module, but needed to be there anyway. The race was between the timer being put in non-continuous mode in ast_read on the channel thread and the IAX frame scheduler queuing a frame which would enable continuous mode before the non-continuous mode event was read. This race for now is simply avoided. (closes issue ASTERISK-16783) Reported by: tpanton Tested by: tpanton I put tested by tpanton because it was tested on his hardware. Thanks for the remote access to debug this issue! ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=294278 By: Digium Subversion (svnbot) 2010-11-08 16:03:55.000-0600 Repository: asterisk Revision: 294279 _U trunk/ U trunk/include/asterisk/timing.h U trunk/main/channel.c U trunk/main/timing.c U trunk/res/res_timing_timerfd.c ------------------------------------------------------------------------ r294279 | jpeeler | 2010-11-08 16:03:55 -0600 (Mon, 08 Nov 2010) | 30 lines Merged revisions 294278 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r294278 | jpeeler | 2010-11-08 15:59:45 -0600 (Mon, 08 Nov 2010) | 23 lines Merged revisions 294277 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r294277 | jpeeler | 2010-11-08 15:58:13 -0600 (Mon, 08 Nov 2010) | 16 lines Fix playback failure when using IAX with the timerfd module. To fix this issue the alert pipe will now be used when the timerfd module is in use. There appeared to be a race that was not solved by adding locking in the timerfd module, but needed to be there anyway. The race was between the timer being put in non-continuous mode in ast_read on the channel thread and the IAX frame scheduler queuing a frame which would enable continuous mode before the non-continuous mode event was read. This race for now is simply avoided. (closes issue ASTERISK-16783) Reported by: tpanton Tested by: tpanton I put tested by tpanton because it was tested on his hardware. Thanks for the remote access to debug this issue! ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=294279 | ||||