asterisk users - Sep 2009 - 1.6.1 + TDM840 FSK MWI problem

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?

Thanks,

--Barry

----- "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?
> 
The ability to do line reversal MWI was added into the 1.6.2 branch. 
Looking through the 1.6.1 code base, I don't see anything other than fsk 
MWI (with and without Ring Pulse Alert Signalling.) 

In any case, this is set by defining "mwisendtype" in chan_dahdi.  
The default for this is fsk spills.  
It can be set to "nofsk" if you want to disable the fsk spills. 

The line reversal is set by specifying 
mwisendtype=lrev

Regards,
Doug Bailey

----- "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.).  

Doug