----- "Doug Bailey" <dbai...@digium.com> wrote: > ----- "Doug Bailey" <dbai...@digium.com> wrote: > > > ----- "Barry Miller" <asterisk-us...@notanet.net> wrote: > > > > > On Fri, Sep 04, 2009 at 04:10:43PM -0500, Doug Bailey wrote: > > > > > > ----- "Barry Miller" <asterisk-us...@notanet.net> 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 _______________________________________________ -- 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