Summary:	ASTERISK-10776: Jitterbuffer does not work well with injected sound
Reporter:	Tony Plack (plack)	Labels:
Date Opened:	2007-11-15 10:28:05.000-0600	Date Closed:	2008-08-05 19:16:46
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/Jitterbuffer
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Using the following in the dial plan: exten => 208,1,Noop exten => 208,n,Set(LIMIT_WARNING_FILE=beep) exten => 208,n,Dial(SIP/5001||L(36000000:36000000:15000)) the injected beep file is not passing through the jitterbuffer properly.  If you look at the additional information, the jitterbuffer is off by the number of frames required to send the audio. Audio quality is impacted and there is a loss of packets during the transmission of the beep tone. ****** ADDITIONAL INFORMATION ****** verbose gives the following:    -- <SIP/5000-b6622db0> Playing 'beep' (language 'en') [Nov 15 10:14:08] WARNING[10035]: abstract_jb.c:429 jb_get_and_deliver: JB_IMPL_NOFRAME is retuned from the adaptive jb when now=60048 >= next=60047, jbnext=60047! [Nov 15 10:14:08] WARNING[10035]: abstract_jb.c:429 jb_get_and_deliver: JB_IMPL_NOFRAME is retuned from the adaptive jb when now=60052 >= next=60051, jbnext=60051! [Nov 15 10:14:08] WARNING[10035]: abstract_jb.c:429 jb_get_and_deliver: JB_IMPL_NOFRAME is retuned from the adaptive jb when now=60052 >= next=60047, jbnext=60047! [Nov 15 10:14:08] WARNING[10035]: abstract_jb.c:429 jb_get_and_deliver: JB_IMPL_NOFRAME is retuned from the adaptive jb when now=60056 >= next=60051, jbnext=60051! [Nov 15 10:14:08] WARNING[10035]: abstract_jb.c:429 jb_get_and_deliver: JB_IMPL_NOFRAME is retuned from the adaptive jb when now=60056 >= next=60047, jbnext=60047! [Nov 15 10:14:08] WARNING[10035]: abstract_jb.c:429 jb_get_and_deliver: JB_IMPL_NOFRAME is retuned from the adaptive jb when now=60060 >= next=60051, jbnext=60051! [Nov 15 10:14:08] WARNING[10035]: abstract_jb.c:429 jb_get_and_deliver: JB_IMPL_NOFRAME is retuned from the adaptive jb when now=60063 >= next=60051, jbnext=60051! [Nov 15 10:14:08] WARNING[10035]: abstract_jb.c:429 jb_get_and_deliver: JB_IMPL_NOFRAME is retuned from the adaptive jb when now=60064 >= next=60051, jbnext=60051! [Nov 15 10:14:08] WARNING[10035]: abstract_jb.c:429 jb_get_and_deliver: JB_IMPL_NOFRAME is retuned from the adaptive jb when now=60066 >= next=60051, jbnext=60051!
Comments:	By: Olle Johansson (oej) 2007-12-16 03:23:15.000-0600 THis bug report needs some attention after one month in the queue. /Housekeeping By: Tony Plack (plack) 2007-12-18 06:46:57.000-0600 I have attempted just after this was created to modify playback_file(not positive on the function name right now) to use the jb to post, but that created a couple of other issues.  One, is that if the jb was turned off, I got no sound.  Second, the frame numbers were off still on transmission and it triggered jitter in the channel. I am thinking that we need to have the jb be a little less sensitive to sequentially missing frames.  If it misses one frame it seems to miss 5 (based on config of course, as I have 5). I am thinking now that an off by one should be allowed. The only other solution I see is how SLA is implemented through meetme but I would hate to have meetme required for playback and background. By: Mark Michelson (mmichelson) 2008-07-25 09:25:16 This issue has grown quite old, and so I was assigned to try to bring a resolution. The problem I'm having right now is that I am unable to reproduce the issue. I tried using the latest 1.4 as well as the revision specified in the original bug report. Neither of them cause the warning message to be displayed, nor did they cause issues with audio quality. Well, this isn't the entire truth. The full truth of the matter is that I see no issue when using a fixed jitter buffer. When attempting to use an adaptive jitter buffer, I'm having a much worse issue, and that is that I receive no audio at all on the channel with the adaptive jitter buffer attached. This happens in both the latest 1.4 svn revision and the revision specified in this report. Specifically, I'm seeing this messsage So what I'm going to need in order to try to solve this problem is 1. The jitter buffer settings from your conf files. 2. The channel types involved in the call. I see that you are dialling a SIP channel, but I'm not sure what type of channel you are dialling in from (nor do I actually know if that matters). Thanks! By: Mark Michelson (mmichelson) 2008-07-25 09:49:39 Okay, I actually got the warning to appear. I needed to set a jbresyncthreshold for the channel with the adaptive buffer. No need for feedback now. I will try to get this fixed! By: Digium Subversion (svnbot) 2008-08-05 10:23:16 Repository: asterisk Revision: 135650 A   team/mmichelson/issue11259/ ------------------------------------------------------------------------ r135650 | mmichelson | 2008-08-05 10:23:15 -0500 (Tue, 05 Aug 2008) | 18 lines Making a branch to solve issue ASTERISK-10776 on the bugtracker. The work involved can be broken into four parts: 1. Identify all places where the source of audio   will change and queue source update frames in   those situations. 2. Add an API call to abstract_jb to reset a jitter-   buffer. 3. Add code to ast_generic_bridge to clear and reset   the jitterbuffer when a source update occurs. 4. Test! ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=135650 By: Digium Subversion (svnbot) 2008-08-05 19:16:43 Repository: asterisk Revision: 135841 _U  branches/1.4/ U   branches/1.4/apps/app_skel.c U   branches/1.4/include/asterisk/abstract_jb.h U   branches/1.4/main/abstract_jb.c U   branches/1.4/main/channel.c U   branches/1.4/main/fixedjitterbuf.h ------------------------------------------------------------------------ r135841 | mmichelson | 2008-08-05 19:16:43 -0500 (Tue, 05 Aug 2008) | 27 lines Merging the issue11259 branch. The purpose of this branch was to take into account "burps" which could cause jitterbuffers to misbehave. One such example is if the L option to Dial() were used to inject audio into a bridged conversation at regular intervals. Since the audio here was not passed through the jitterbuffer, it would cause a gap in the jitterbuffer's timestamps which would cause a frames to be dropped for a brief period. Now ast_generic_bridge will empty and reset the jitterbuffer each time it is called. This causes injected audio to be handled properly. ast_generic_bridge also will empty and reset the jitterbuffer if it receives an AST_CONTROL_SRCUPDATE frame since the change in audio source could negatively affect the jitterbuffer. All of this was made possible by adding a new public API call to the abstract_jb called ast_jb_empty_and_reset. (closes issue ASTERISK-10776) Reported by: plack Tested by: putnopvut ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=135841