[asterisk-users] asterisk 1.6.1.0 and dial plan changes

[David Backeberg]

On Sun, May 31, 2009 at 4:20 PM, David Backeberg <dbackeberg at gmail.com> wrote:
> On Sun, May 31, 2009 at 3:51 PM, sean darcy <seandarcy2 at gmail.com> 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.