On Sun, May 31, 2009 at 4:20 PM, David Backeberg <[email protected]> wrote: > On Sun, May 31, 2009 at 3:51 PM, sean darcy <[email protected]> wrote: >> David Backeberg wrote: >>> >>> You don't say the kind of call you're making, but if you're using >>> MeetMe() I have more advice regarding voice quality with conference >>> rooms. >> >> I don't know about the OP, I'd sure appreciate any advice regarding >> voice quality with MeetMe(). When we have 2 -3 internal SIP lines, 2+ >> internet SIP lines, and some PRI lines, we have a difficult time with >> quality. >> >> Any tips appreciated. > > Sure. In addition to the things I mentioned, try jumping to the > 1.6.1.* series. And be sure to NOT pass 'o' as an option to the
I should clarify that the patch in the issue I linked to DID go back into 1.6.0. trunk, so any releases made to the 1.6.0. series after the date of that patch will have the optimization as optional. I haven't checked whether any 1.6.0. releases have been made since the patch, but I can say that 1.6.1.0 has the patch, and that upgrading to 1.6.1.0 made an enormous improvement. Also, I should say that when I was troubleshooting this, I was so disturbed at what MeetMe() was doing to the conference that I went looking for any alternative. I tried making my own Bridge()-based conference solution, but I coded it up very quickly and made enough mistakes that I instead tried to track down what was making MeetMe() sound so awful. After moving on from that idea, I didn't end up pursuing this, but trunk, and 1.6.2.* series has a new application called ConfBridge(). It's not (yet?) as full-featured as MeetMe() but if you've worked up a MeetMe() solution you'll find the features that do exist familiar. I went looking through DAHDI issues and saw that there was a pending patch involving dahdi_dummy. I tried this patch, discovered that it seemed to make things better, and I helped contribute to the momentum that got a change to using the kernel timer rather than RTC for dahdi_dummy. Check out http://svn.digium.com/svn/dahdi/linux/tags/2.2.0-rc4/ChangeLog for details, and upgrade your DAHDI to get those changes. So for me, first patching, then upgrading when main-lined DAHDI came out. Plus upgrading to 1.6.0.1, NOT using talker optimization. Plus the other things I mentioned about disabling vad and lengthening the interval for looking for talking activity (which is probably redundant but I haven't dug in the code to find out). Equaled a much better MeetMe conference with SIP users. I will also say that as a test, I did the same setup on a system that had a real Digium card in it, where the Digium card provides the timing. On that system dahdi_test will always be perfect. I also used dahdi_test to check out how well the dahdi_dummy was generating timing and had the users jump in that system. Then I put them in the same software config, but on a system that didn't have a Digium card. After figuring out the changes I mentioned, users weren't able to tell a difference. If you have a real Digium card in the system, you can ignore my stuff about dahdi_dummy, but in my situation it was one more variable I needed to consider. _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
