[asterisk-bugs] [JIRA] (ASTERISK-23262) Audio degredation with codec_dahdi and ChanSpy'ing

[Shaun Ruffell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215185#comment-215185 ] 

Shaun Ruffell commented on ASTERISK-23262:
------------------------------------------

I've attached a patch that I think is worth trying. I've done some basic tests using the file covert utility. This patch allows the synchronous mode of codec_dahdi to be disabled and for frames with silence to be returned when the hardware doesn't have frames to send yet. This results in some bad frames at the beginning of a call, but once the pump is primed, things should be fine. This should prevent codec_dahdi from blocking the translation chain.

This patch can be applied from the root of an asterisk-11 source directory like:

{noformat}
curl "https://issues.asterisk.org/jira/secure/attachment/49280/0001-wip-codec_dahdi-Add-configurable-synchronous-mode.patch" | patch -p1
{noformat}

After applying the patch, you can enable the non-synchronous mode of operation by running {{asterisk -rx 'transcoder set synchronous off'}} or by adding a {{synchronous=off}} line in the {{[dahdi]}} section in codecs.conf.

When synchronous mode is disabled, file convert will produce a file that doesn't have the correct audio since it will feed all the audio frames into the transcoder faster than the hardware can transcode them. Although I know both modes will work since if I add a 20ms delay in res_convert.c between each frame written, the audio is correct.

The thought is that disabling the synchronous mode of codec_dahdi will prevent interfering with any jitter buffers in the translation path.
                
> Audio degredation with codec_dahdi and ChanSpy'ing
> --------------------------------------------------
>
>                 Key: ASTERISK-23262
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23262
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Codecs/codec_dahdi
>    Affects Versions: SVN
>         Environment: Linux pbx-host 3.5.0-45-generic #68~precise1-Ubuntu SMP Wed Dec 4 16:18:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> Dell PowerEdge R620
>            Reporter: Sean Bright
>            Assignee: Shaun Ruffell
>         Attachments: 0001-wip-codec_dahdi-Add-configurable-synchronous-mode.patch, irc.txt
>
>
> The server has 2 TCE400P cards and I'm using the latest wctc4xxp driver from the DAHDI-Linux git repository (master branch).
> There are 3 channels involved in this scenario:
> * {{SIP/from-internal-user/1}}
> * {{SIP/from-external-user/1}}
> * {{SIP/from-spying-user/1}}
> The native format for all 3 of these channels is G729.
> {{SIP/from-internal-user/1}} enters dialplan and goes immediately into {{MusicOnHold}}.  The {{MusicOnHold}} class consists of only .g729 files, so no encoders/decoders are used at this point.
> {{SIP/from-external-user/1}} enters dialplan, and hit these three apps/functions in this order:
> * {{MixMonitor(<somefile>.sln,...)}}
> * {{VOLUME(RX)=2}}
> * {{Bridge(SIP/from-internal-user/1,...)}}
> Now, the third channel channel, {{SIP/from-spying-user/1}}, enters dialplan and goes into {{ChanSpy}}:
> * {{ChanSpy(SIP/from-internal-user/1,...)}}
> At this point, both {{SIP/from-internal-user/1}} and {{SIP/from-external-user/1}} begin to hear distortion/delay and are unable to understand each other.  There is also distortion/delay observed by {{SIP/from-spying-user/1}}.
> Spying on {{SIP/from-external-user/1}} does not cause the audio degredation.  Also, based on a suggestion by Josh Colp, removing the call to {{VOLUME(RX)=2}} appears to resolve the problem as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira