[asterisk-bugs] [Asterisk 0015129]: Incoming DTMF causes "Cannot handle frames in 2 format" error, call dies
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue May 19 05:52:40 CDT 2009
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=15129
======================================================================
Reported By: bmh
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 15129
Category: Channels/chan_dahdi
Reproducibility: always
Severity: major
Priority: normal
Status: feedback
Asterisk Version: 1.6.1.0
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-05-16 08:18 CDT
Last Modified: 2009-05-19 05:52 CDT
======================================================================
Summary: Incoming DTMF causes "Cannot handle frames in 2
format" error, call dies
Description:
All incoming DTMF tones over my DAHDI interface (a PRI) cause the following
error:
[May 16 08:38:27] WARNING[2387]: chan_dahdi.c:5624 dahdi_write: Cannot
handle frames in 2 format
[May 16 08:38:27] WARNING[2387]: file.c:723 ast_readaudio_callback: Failed
to write frame
-- Hungup 'DAHDI/1-1'
The call is dropped and this error appears on the Asterisk console as soon
as any DTMF is received over the DAHDI interface. Calls otherwise function
normally until any digit on a phone's keypad is pressed while calling in.
======================================================================
----------------------------------------------------------------------
(0104995) bmh (reporter) - 2009-05-19 05:52
https://issues.asterisk.org/view.php?id=15129#c104995
----------------------------------------------------------------------
The log shows that DAHDI/1-1 is set to use gsm as the write format when the
call is initially accepted. Eight seconds later, at the same time the
digits are pressed on the calling phone's keypad, the write format is
changed to ulaw. Asterisk receives the frame (apparently still in gsm
format) and bails out on the call.
Is it normal for the initial format to be gsm? Or is something else going
on?
Issue History
Date Modified Username Field Change
======================================================================
2009-05-19 05:52 bmh Note Added: 0104995
======================================================================
More information about the asterisk-bugs
mailing list