On Thu, Sep 10, 2009 at 05:06:01PM -0500, Doug Bailey wrote: > > ----- "Doug Bailey" <[email protected]> wrote: > > > ----- "Doug Bailey" <[email protected]> wrote: > > > > > ----- "Barry Miller" <[email protected]> wrote: > > > > > > > On Fri, Sep 04, 2009 at 04:10:43PM -0500, Doug Bailey wrote: > > > > > > > ----- "Barry Miller" <[email protected]> wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Using 1.4.26.1 & DAHDI 2.2.0.2, FSK VMWI devices off a > > > TDM840 > > > > > > work > > > > > > > > fine. > > > > > > > > > > > > > > > > With 1.6.1.[45] & same DAHDI, instead of the FSK spill I > > > get > > > > a > > > > > > line > > > > > > > > polarity reversal. Stutter dialtone is generated as > > > > expected. > > > > > > > > > > > > > > > > Has anyone else seen this? Is there anything special I > > > need > > > > to > > > > > > do > > > > > > > > for > > > > > > > > 1.6.1 to make FSK MWI work? > > > > > > > > [snip] > > > > > > > > > > > > > > The only thing I can think of that would be preventing the > > output > > > > would be > > > > > problems in the interface chip with the On-Hook transfer mode. > > > > > > > > > > If you run a dahdi_monitor on the channel that should be > > sending > > > the > > > > FSK > > > > > spill and look at the results in a program like audacity, you > > can > > > > see if > > > > > the MWI FSK spill is actually reaching the interface SLIC IC. > > > > > > > > > > Something like "dahdi_monitor 1 -t spilloutput.raw" (Monitors > > the > > > > output > > > > > going to dahdi channel 1.) > > > > > > > > Hmm. With both 1.4 & 1.6, without touching > > /etc/[asterisk|dahdi], > > > > I used a butt-set to go off-hook, then back on. I got: > > > > > > > > 1.4.26.1: dahdi_monitor captured stutter dialtone, 4.5 seconds > > of > > > > silence, then the FSK spill. And that's what I heard. > > > > > > > > 1.6.1.6: dahdi_monitor captured stutter dialtone, 1.5 seconds > > of > > > > silence, then the FSK spill. Sounds good with audacity. But > > > > all I heard through the butt-in was stutter dialtone. No FSK > > > > spill at all. > > > > > > > > Here's hoping this tells you more than it does me :) > > > > > > > Actually it does tell me a lot. > > > > > > The problem appears in how the interface chip is being programmed. > > > > > For some reason, the interface chip is not being set to on-hook > > > transfer mode which would allow for the mwi spill to go out on the > > > actual fxs port lines. > > > > > > I am looking to see where the problem lies. (It is either in > > > chan_dahdi > > > or in the driver.) I hope to have more information later. > > > > > > > The problem lies in a race condition between chan_dahdi making an > > ioctl call to > > set the VMWI state (performed in the do_monitor loop ) and a a > > subsequent call > > to set the channel in ONHOOK transfer mode (performed in > > mwi_send_init). This > > requires the driver to send successive commands to the SLIC interface > > chip > > linefeed register. If the command required for the VMWI mode is not > > completed > > by the time the ONHOOK transfer mode is requested, the ONHOOK transfer > > request > > is thrown away and the MWI spill does not get sent. > > > > I will be fixing this in the drivers trunk branch and hope to have it > > committed > > soon. I'm not sure when it will be released. > > > > Another option is to comment out the ioctl call for VMWI in the > > do_monitor loop > > (especially if you do not care about line reversal MWI.). > > > > See https://issues.asterisk.org/view.php?id=15875 for more information
Thanks much! I would not have figured that out. Eliminating the ioctl works fine for now-- rpas is not an issue here. --Barry _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
