2014-02-06:

11:45 <@seanbright> there are 3 machines, we'll call them 'RemoteAgent', 'BridgedCalls', 'PSTN' for the purposes of this discussion
11:45 <@seanbright> RemoteAgent sends G729 calls to BridgedCalls, and PSTN sends G729 calls to BridgedCalls
11:46 <@seanbright> the RemoteAgent channel on BridgedCalls is sitting in MusicOnHold
11:46 <@seanbright> (and the files being played are g729, so there is no transcoding at this point)
11:47 <@seanbright> call comes in from PSTN.  in dialplan we start a mixmonitor on that channel, and then call the Bridge() application, passing in one of the RemoteAgent channels
11:48 <@seanbright> that works fine
11:48 <@seanbright> another channel comes in from RemoteAgent and does a ChanSpy on the RemoteAgent channel involved in the Bridge
11:49 <@seanbright> then, both the original RemoteAgent channel and the original PSTN channel start getting audio delays and the conversation starts getting choppy
11:49 <@seanbright> and the BridgedCalls box has 2 tc400bs in it
11:49 <@seanbright> so we're offloading the transcoding to those
11:49 <@mjordan> The channel involved in the ChanSpy - what are the formats on it?
11:50 <@seanbright> opus
11:50 <@seanbright> dun dun dun
11:50 <@mjordan> what happens if it isn't Opus?
11:50 <@seanbright> not sure.  i can test.
11:51 <@seanbright> what would be the ideal test?  slinear?  ulaw?
11:51 <@mjordan> either of those, probably
11:51 <@mjordan> something that is 'simple'
11:51 <@file> yeah, I'd eliminate that from the equation
11:51 <@file> go for ulaw
12:16 <@seanbright> mjordan: file: so i registered eyeBeam directly with the BridgedCalls box and set ulaw as the only usable codec
12:16 <@seanbright> same issue occurred
12:17 <@seanbright> and when i spoke into the RemoteAgent channel, it took about 6 seconds for it to show up on the chanspy'ing channel
12:20 <@mjordan> seanbright: that doesn't seem right at all. I'm not sure what would be causing that kind of delay however. The only other thing I can think of to remove from the equation is the transcoder card
12:21 <@mjordan> but if it still happens after that, then I've got to blame something in the mixing of g729 and anything else in the spy code
12:22 <@seanbright> i can't run the software g729 codecs and the transcoder cards in paralle
12:23 <@seanbright> any idea how i could remove the transcoder card from the equation and leave transcoding in the equation?
12:25 <@mjordan> hum.
12:25 <@mjordan> not without pulling the card out
12:25 <@opticron> unload the driver
12:26 <@seanbright> well, there are a couple issues
12:26 <@seanbright> 1) i don't have 50 g729 software licenses laying around
12:26 <@seanbright> 2) we have the transcoder card so the cpu doesn't have to do any of the heavy lifting
12:27 <@seanbright> i could use the less-than-kosher g729 codecs for testing i guess
12:41 <@seanbright> i wonder if it's possible that multiple channels are somehow use the same transcoder card "slot"
13:58 <@seanbright> so, on one of the boxes experiencing the issue i have beaten in the ground, i created another fake set of dialplan that let me dial in with 3 soft phones to be the 3 players in the scenario i described before
13:58 <@seanbright> on the first test, it was ulaw everywhere
13:58 <@seanbright> on the second test, it was opus everywhere
13:58 <@seanbright> in neither of those scenarios did we experience the issue

2014-02-07:

10:10 <@seanbright> mjordan: file: rmeyerriecks: so an update from my testing the past few days
10:10 <@seanbright> sruffell suggested that i back out the patch from ASTERISK-19643 and test again
10:11 <@seanbright> that would be r366007
10:11 <@seanbright> so i backed that out, and the call between the RemoteAgent and the PSTN channels was immediately degraded
10:11 <@seanbright> even without the ChanSpy
10:13 <@seanbright> so then, on one of the BridgedCalls machines, i installed "codec_g729.so" (i think you get why i am quoting that) and noload'ed codec_dahdi.so
10:13 <@seanbright> no quality problems at all, in all of my test scenarios, including spy, whisper, or barge
10:15 <@seanbright> so either i have bad hardware (which i find unlikely considering it doesn't manifest unless a spy is happening) or codec_dahdi is the culprit
10:18 <@file> well, it's nice to have it isolated further
10:19 <@seanbright> so now what do i do?
10:19 <@seanbright> fix bugs?
10:19 <@seanbright> heh