| Summary: | ASTERISK-24314: ConfBridge Doesn't Deliver 48 kHz Audio with Local channels | ||||
| Reporter: | Frankie Chin (fchin) | Labels: | |||
| Date Opened: | 2014-09-09 18:54:31 | Date Closed: | 2015-02-24 18:38:06.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Applications/app_confbridge | ||
| Versions: | SVN | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) confbridge_serverA.conf ( 1) extensions_serverA.conf ( 2) extensions_serverB.conf ( 3) full_serverA ( 4) sip_serverA.conf ( 5) sip_serverB.conf | |||
| Description: | I have two servers registered to each other via SIP. I only enabled "slin48" codec in sip.conf of both servers.
Scenario 1 (Happy): I use AMI to originate a call to Server B. Once Server B answers the call, Server A will start playing a 48 kHz speech audio from a *.sln48 file. At Server B, the audio is recorded into another *.sln48 file. The recorded audio quality at Server B is basically the same as the original source. Scenario 2: Using another AMI application, it originates a call to Server B and puts it into a conference hosted in Server A. It then originates another call to a local channel in Server A and puts the local channel into the conference as well. The local channel then starts playing the same speech audio from the source *.sln48 file into the conference. The audio is also recorded at Server B. But this time, the recorded audio quality is much worse than the source audio. The following are the settings in my confbridge.conf which I think relevant: - internal_sample_rate = 48000 - mixing interval = 20 - dsp_drop_silence = yes - dsp_talking_threshold = 128 - dsp_silence_threshold = 2000 I have even tried setting the internal_sample_rate to 192000 but it didn't improve the recorded audio quality. My final objective is to be able to put multiple servers into a conference and get a local channel in one server to play the 48 kHz audio out to all the other servers. | ||||
| Comments: | By: Rusty Newton (rnewton) 2014-09-11 16:05:20.973-0500 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. the specific steps or actions you took that caused you to encounter the problem, 2. the behavior you expected, and 3. the behavior you actually encountered (in as much detail as possible). This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks! By: Rusty Newton (rnewton) 2014-09-11 16:08:08.144-0500 Notably please include the full sip.conf and confbridge.conf configurations needed to reproduce the issue, as well as an [Asterisk debug log|https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information] showing AMI debug, plus SIP debug and the typical VERBOSE and DEBUG type logger channels. By: Frankie Chin (fchin) 2014-09-14 20:59:46.108-0500 For Scenario 2, attached sip.conf, extensions.conf, confbridge.conf and log files. By: Frankie Chin (fchin) 2014-09-14 21:08:45.652-0500 Below are the AMI Actions for Scenario 2... Action: Originate Channel: SIP/goldburg/1000 Exten: 1001 Priority: 1 Context: conference Async: true CallerID: 1001 Action: Originate Channel: Local/1@local/n Exten: 1001 Priority: 1 Context: conference_local CallerID: 1001 By: Frankie Chin (fchin) 2014-09-14 21:17:36.461-0500 Hi Rusty, I hope the information I just provided above would help you in reproducing the issue described in Scenario 2. My expected behaviour is that the audio quality received at Server B would be the same as the audio source being fed into the conference at Server A. The actual behaviour is that the audio quality received at Server B sounds like a 8 kHz quality. The audio source is a 48 kHz high quality speech audio, hence the difference is very significant. By: Rusty Newton (rnewton) 2014-09-23 18:15:42.004-0500 All of your config files have windows newline characters mixed in. The dos2unix tool is not converting them properly (not cleaning them up completely), for whatever reason. However, that scares me from using them for reproduction. Can you please attach the actual files used on your server (in unix file format) to avoid any strangeness with differing newline characters? By: Frankie Chin (fchin) 2014-09-24 18:04:16.982-0500 Re-attached the configuration files after fixing the newline characters issue. By: Rusty Newton (rnewton) 2014-09-26 14:26:40.144-0500 Well.. this is odd. Using Asterisk 12.4.0 (on both sides), your configs and swapping out only the necessary bits (IP addresses); I can't even get the Originate from server A to B working. In my case, Asterisk claims it is adding slin48 to SDP, but it actually doesn't. INVITE goes out with no codecs and the other side replies with 488 Not acceptable here, due to no compatible codecs, due to no codecs in the SDP. Below is a comparison of the INVITE SDP between the debug you attached to the issue and what I'm seeing at the console when testing with your AMI and configs. In your debug: {noformat} [Sep 15 11:07:31] VERBOSE[5914] chan_sip.c: Adding codec 100025 (slin48) to SDP <snip> [Sep 15 11:07:31] DEBUG[5914] chan_sip.c: Done building SDP. Settling with this capability: (slin48) <snip> ÿm=audio 15248 RTP/AVP 120 101^M ÿa=rtpmap:120 L16/48000^M ÿa=rtpmap:101 telephone-event/8000^M ÿa=fmtp:101 0-16^M ÿa=ptime:20^M ÿa=maxptime:70^M ÿa=sendrecv^M {noformat} In my debug: {noformat} Adding codec 100025 (slin48) to SDP <snip> [Sep 26 14:03:43] DEBUG[27121]: chan_sip.c:13718 add_sdp: Done building SDP. Settling with this capability: (slin48) <snip> m=audio 13192 RTP/AVP 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv {noformat} You can see in my case that slin48 doesn't get added. Which seems like a bug. What I'm wondering is how it is working in your scenario if it is a bug in my case? Can you shed any further light on configuration that might be needed? Or any custom configuration you did for your Asterisk installation? By: Frankie Chin (fchin) 2014-09-28 17:55:06.867-0500 Hi Rusty, sorry that I should have mentioned about this other issue with SLIN48 codec: ASTERISK-24274. Please see my first comment in that issue for what I did to get SLIN48 codec working. By: Rusty Newton (rnewton) 2014-09-29 18:36:55.699-0500 Well, that complicates things. We really can't work this issue until patches for ASTERISK-24274 are reviewed and committed into Asterisk. I'm going to close this one out for now, and when ASTERISK-24274 is resolved then we can re-open this one if ASTERISK-24274 is pushed in successfully. I'll link the two, and you should also note this behavior when you put patches for ASTERISK-24274 on Reviewboard to be sure that others test that aspect of behavior. As always, you can contact a bug marshal or developer on #asterisk-bugs or #asterisk-dev (irc.freenode.net) if you have questions or need assistance. By: Frankie Chin (fchin) 2014-12-29 17:53:34.276-0600 Hi Rusty, since ASTERISK-24274 has now been resolved, may I know if you could help reopen this issue for investigation? Thanks. By: Rusty Newton (rnewton) 2014-12-31 08:58:27.056-0600 I'll go ahead and reopen it. I set the Affectes Version/s field to SVN (since the feature was added into trunk). Can you verify this issue ASTERISK-24314 still occurs in trunk? By: Frankie Chin (fchin) 2015-01-07 22:05:08.056-0600 Rusty, I can confirm that this issue still occurs in the trunk. I downloaded the source from the trunk and build Asterisk from source. I retested Scenario 1 and Scenario 2 (as described in the Description) and they behaved the same as before. By: Rusty Newton (rnewton) 2015-01-26 08:26:16.754-0600 Thanks for confirming Frankie. I wanted to note that with this being such an unusual scenario for confbridge use (slin48 in confbridge) that progress will be made quicker if you or another community member are able to provide a patch. You can always seek help in #asterisk-dev in irc.freenode.net and the asterisk-dev mailing list if you need some assistance in investigating the issue. By: Matt Jordan (mjordan) 2015-01-26 09:25:49.132-0600 The reason this is occurring is most likely due to the usage of Local channels. When Local channels are typically created, they are created with only {{slin}} as the requested format capability. As such, SLIN and 48KhZ is transcoded down between the ConfBridges. I'd suspect that if the Local channels were created with all of the SLIN formats, it would work as you'd like. By: Frankie Chin (fchin) 2015-02-24 18:36:03.435-0600 Very exciting finding! After debugging into the code for a day. I found out that by specifying "slin48" into the Codecs argument for the Originate AMI action, it will work exactly as I expect! If this argument is not provided, the action will only add the default "slin" codec into the capability list. | ||||