Review Board 1.7.16


Prevent DTMF incorrectly triggering during SAS+CAS (CallWaiting) signalling to an FXS port

Review Request #978 - Created Oct. 19, 2010 and submitted

Alec Davis
trunk
18129
Reviewers
asterisk-dev
Asterisk
The dsp incorrectly detects a DTMF 'D' start event, during the call waiting CAS acknowledgement from a CPE device that supports SAS+CAS connected an FXS port.
The result is the SIP call has continuous DTMF RTP packets sent to it.

This can be corrected by the FXS port pressing any DTMF button.
intial setup SIP -> FXS port (TDM800P)
2nd call from console -> same FXS port as above.

Call waiting beep heard, and audio resumes both directions.
Review request changed
Updated (Nov. 4, 2010, 1:49 a.m.)
  • The dsp incorrectly detects a DTMF start, when call waiting spill is injected to an FXS port.
    The result is the SIP call has continuous DTMF RTP packets sent to it.
    
    This can be corrected by the FXS port pressing a DTMF button.

    The dsp incorrectly detects a DTMF 'D' start event, during the call waiting CAS acknowledgement from a CPE device that supports SAS+CAS connected an FXS port.
    The result is the SIP call has continuous DTMF RTP packets sent to it.
    
    This can be corrected by the FXS port pressing any DTMF button.
  • changed from Prevent DSP from incorrectly triggering during CallWaiting spill to Prevent DTMF incorrectly triggering during SAS+CAS (CallWaiting) signalling to an FXS port
Mute the conference as soon as the SAS+CAS signalling starts, and unmute when finished.

The symptom otherwise is that the other channels' dtmf detectors would hear the CAS acknowledgement (DTMF 'D') from the CPE, and would trigger a DTMF begin event, but with no corresponding DTMF end event, thus DTMF packets were sent continuously.

This also cleans up the beep that was heard by the other party/parties in the conference, when the FXS port is rung.
Ship it!
Posted (Nov. 4, 2010, 5:31 a.m.)
Looks ok to me.  Just have a couple minor commenting items below.
  1. Further testing revealed that muting the conference stopped the FXS port detecting the CPE's CAS response DTMF 'D', and thus doesn't send the CallWaiting CallerID.
    
    Need to find another way.
trunk/channels/chan_dahdi.c (Diff revision 3)
 
 
 
Can you give a good description for callwaitcas?  It looks like it could be:
"TRUE if sending call waiting caller id."  However, that description does not quite fit with how it is used.
trunk/channels/chan_dahdi.c (Diff revision 3)
 
 
 
 
 
Put this in my_callwait() as well.  my_callwait() is the sig_analog.c callback equivalent to this function.

https://reviewboard.asterisk.org/ runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to asteriskteam@digium.com.