[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=215254#comment-215254 ] 

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

23 and 41 silent frames are definitely not what I would have expected. Normally I would think if packets are coming into the system at 20 ms intervals, you should only get one or two silent frames until the pump was primed, then there would always be a one-to-one correlation between a ready frame in and a frame from the hardware. So this makes me wonder if there are packets that are coming in at 40 or 60ms, and then are being smoothed out into 2 or 3 frames of 20 ms.

So ugh, I guess I'm really going to have to try and setup the scenario as you described it and take my own recordings through chanspy when there is a VOLUME() on the channel.

Can you confirm what the packet interval is from the end points?
                
> 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: Sean Bright
>         Attachments: 0001-wip-codec_dahdi-Add-configurable-synchronous-mode.patch, irc.txt, rattle.sln
>
>
> 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