[asterisk-users] 1.6.1 + TDM840 FSK MWI problem

[Doug Bailey]

----- "Doug Bailey" <dbailey at digium.com> wrote:

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