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