Summary:	ASTERISK-24423: High pitched constant sound in ConfBridge when sample rate is set to 16000 and with dsp_drop_silence=yes
Reporter:	Thomas Frederiksen (ToMMeR)	Labels:
Date Opened:	2014-10-15 04:57:07	Date Closed:	2014-12-03 15:02:15.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_confbridge
Versions:	11.11.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS 6	Attachments:
Description:	For a audio broadcasting we have Confbridge configured like below. ConfTransmit is the sip-client that will be transmitting audio to the listeners. ConfMuted is all the listeners that can listen to the audio from ConfTransmit: {noformat} [Conf] type=bridge internal_sample_rate=16000 {noformat} {noformat} [ConfTransmit] type=user marked=yes dsp_drop_silence=yes {noformat} {noformat} [ConfMuted] type=user startmuted=yes wait_marked=yes dsp_drop_silence=yes quiet=yes {noformat} When using these settings together with G.722 SIP-clients in both ends, the "ConfTransmit" user sometimes hears a high pitched (sounds like around 8kHz) constant sound from the conference. The issue always happens if the ConfMuted user is the first to dialin to the conference. Then when the ConfTransmit user dials in after the ConfMuted user the high pitched sound is heard in the ConfTransmits phone constantly. It's always the ConfTransmit user who has the problem with a high pitched sound from the conference, not the ConfMuted user. The problem only exists if both SIP-users are running G.722 codec. The high pitched sound disappears if i disable dsp_drop_silence, but then a burst of white noise is heard every 5 seconds or so. The problem also exists if "internal_sample_rate=auto" but disappears completely if i set the conference to "internal_sample_rate=8000" and dsp_drop_silence is on. The very strange thing is that i cannot hear any audio quality difference when ConfBridge i set to 8000 instead of 16000. It still sounds like 16kHz G.722 To my understanding if the internal_sample_rate in ConfBridge is set to 8000 the audio should sound like 8kHz audio or G.711, is this correct? Why doesn't this have any effect on the audio quality? I have tried with both X-Lite and Linphone SIP-phones to eliminate if the problem was with one of the SIP-clients. I was also wondering if this problem still exists in Asterisk 12 or 13, or it has been fixed on these versions?
Comments:	By: Matt Jordan (mjordan) 2014-10-28 09:05:39.461-0500 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Rusty Newton (rnewton) 2014-11-13 17:13:37.369-0600 This looks easy enough to lab up - I'll take a look tomorrow when I get a chance. By: Rusty Newton (rnewton) 2014-11-14 19:07:33.280-0600 I could not reproduce the issue. I used the provided configuration: {noformat} [general] [Conf] type=bridge internal_sample_rate=16000 [ConfTransmit] type=user marked=yes dsp_drop_silence=yes [ConfMuted] type=user startmuted=yes wait_marked=yes dsp_drop_silence=yes quiet=yes {noformat} Dialplan: {noformat} exten = 7001,1,Confbridge(1001,Conf,ConfTransmit) exten = 7002,1,Confbridge(1001,Conf,ConfMuted) {noformat} I tested on Asterisk SVN-branch-11-r427874 with two Digium D40 phones, configured in Asterisk for only G722. I called into the conference first with the ConfMuted user, then the ConfTransmit user. I couldn't hear any audio abnormalities on either device. You said it happens sometimes, so I tried about ten times and didn't see it happen. Since we are unable to reproduce the issue - if you can't provide further debug demonstrating the issue or how to reproduce it then we'll go ahead and close it out. By: Rusty Newton (rnewton) 2014-12-03 15:02:15.798-0600 No response from reporter and I was unable to reproduce this as described. When further debug or reproduction steps are available then this issue can be reopened. Bug marshals can be contacted on irc.freenode.net at #asterisk-bugs or #asterisk-dev to request an issue to be reopened.