[Home]

Summary:ASTERISK-16901: DISA "Cannot handle frames in gsm format"
Reporter:Chris Gentle (gentlec)Labels:
Date Opened:2010-11-02 12:53:55Date Closed:2012-03-14 12:25:19
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
is related toASTERISK-17541 Calls from VOIP to Dahdi requiring transcoding fail
Environment:Attachments:
Description:When I call into my Asterisk box via a VoIP line (in this case it's incoming IP from Vitelity using gsm codec) and then try to make an outgoing DISA call over my PSTN I get the following:

[Nov  1 15:12:54] WARNING[17694]: chan_dahdi.c:8930 dahdi_write: Cannot handle frames in gsm format
[Nov  1 15:12:54] WARNING[17694]: app_dial.c:1401 wait_for_answer: Unable to forward voice or dtmf

It looks like asterisk is not converting the gsm frames to whatever it needs to send over the PSTN.  I never had this problem with the 1.6.x series but it started as soon as I upgraded to 1.8.0 and dahdi-2.4.0.  My Asterisk machine has a TDM-410 card installed for the interface to the PSTN.  Running on Ubuntu server 10.10.  DAHDI and Asterisk compiled from source tarballs.  Please let me know if I didn't include something that you need.

Here is the call log of the failed DISA call:

[Nov  2 12:12:58] VERBOSE[22688] pbx.c:     -- Executing [XXXXXXXXXX@disa:16] Dial("SIP/xxxxxxx-00000000", "dahdi/1/XXXXXXXXXX,60,r") in new stack
[Nov  2 12:12:58] DEBUG[22688] sig_analog.c: analog_available 1
[Nov  2 12:12:58] DEBUG[22688] sig_analog.c: analog_request 1
[Nov  2 12:12:58] DEBUG[22688] sig_analog.c: CALLING CID_NAME: Chris Gentle CID_NUM:: XXXXXXXXXX
[Nov  2 12:12:58] DEBUG[22688] sig_analog.c: Dialing 'XXXXXXXXXX'
[Nov  2 12:12:58] VERBOSE[22688] app_dial.c:     -- Called 1/XXXXXXXXXX
[Nov  2 12:12:58] WARNING[22688] chan_dahdi.c: Cannot handle frames in gsm format
[Nov  2 12:12:58] WARNING[22688] app_dial.c: Unable to forward voice or dtmf
[Nov  2 12:12:58] DEBUG[22688] sig_analog.c: analog_hangup 1
[Nov  2 12:12:58] VERBOSE[22688] sig_analog.c:     -- Hanging up on 'DAHDI/1-1'
[Nov  2 12:12:58] VERBOSE[22688] chan_dahdi.c:     -- Hungup 'DAHDI/1-1'
[Nov  2 12:12:58] VERBOSE[22688] app_dial.c:   == Everyone is busy/congested at this time (1:0/0/1)
[Nov  2 12:12:58] VERBOSE[22688] pbx.c:     -- Executing [XXXXXXXXXX@disa:17] Hangup("SIP/xxxxxxx-00000000", "") in new stack
[Nov  2 12:12:58] VERBOSE[22688] pbx.c:   == Spawn extension (disa, XXXXXXXXXX, 17) exited non-zero on 'SIP/xxxxxxx-00000000'

My sip profile for the incoming vitelity connection has the following codec related settings:

disallow=all
allow=gsm

My chan_dahdi config looks like this:

[channels]
context=incoming
signalling=fxs_ks
toneduration=300
usecallerid=yes
callwaiting=no
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=no
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
rxgain=4.0
txgain=1.0
group=1
callgroup=1
pickupgroup=1
immediate=no
adsi=yes
progzone=us
callerid=asreceived
channel => 1
Comments:By: Jacob LIpstein (jacobli) 2011-03-03 11:41:57.000-0600

The problem exists in any of 1.8 versions including 1.8.3.  Actually it takes place when call is originated from outside (any outside PSTN or cell phone) of one asterisk and terminates outside of other asterisk (outside PSTN or cell) and the asterisks are connected via IAX interface with actual codec other than ULAW/ALAW.
If GSM codec is in use you will get:
Cannot handle frames in gsm format
If iLBC codecis in use you will get:
Cannot handle frames in ilbc format
To fix the problem at asterisk 1.8.3 when using GSM or iLBC I have applied the following patch:


--- main/chan_dahdi.c
+++ main/chan_dahdi.c
@@ -9056,6 +9056,8 @@
return 0;
}
if ((frame->subclass.codec != AST_FORMAT_SLINEAR) &&
+ (frame->subclass.codec != AST_FORMAT_ILBC) &&
+ (frame->subclass.codec != AST_FORMAT_GSM) &&
(frame->subclass.codec != AST_FORMAT_ULAW) &&
(frame->subclass.codec != AST_FORMAT_ALAW)) {
ast_log(LOG_WARNING, "Cannot handle frames in %s format\n", ast_getformatname(frame->subclass.codec));


Actually this patch is applicable to any of 1.8 versions. I was using 3 patched instances of asterisk 1.8.1.1 for several months. And several days ago switched to patched 1.8.3. Preliminary double checked that the original 1.8.3 still has the problem.
By: clint (clint) 2011-03-06 20:52:25.000-0600

More information:

Issue occurs on any DIAL via DAHDI, not only in DISA.
Issue only occurs if Asterisk is generating indication.  
eg. ringback (r flag to dial command) or music on hold (m flag to dial)

The issue will occur with ANY non ulaw codec over IAX OR SIP.  Tested with GSM, G722, G729.
Tested in 1.8.3.
Requires CALLER to come in over IAX OR SIP, and be routed to DAHDI channel.

Examples:

Failure, Asterisk generating indication via "r" flag to dial command:

   -- Executing [151@xenir-group:2] Dial("IAX2/banbury-279", "Dahdi/G1/1XXXXXXXXXX,24,tr") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called G1/1XXXXXXXXXX
[Mar  6 20:39:05] WARNING[2994]: chan_dahdi.c:9061 dahdi_write: Cannot handle frames in g722 format
[Mar  6 20:39:05] WARNING[2994]: app_dial.c:1410 wait_for_answer: Unable to forward voice or dtmf
   -- Hungup 'DAHDI/i1/1XXXXXXXXXX-a'
 == Everyone is busy/congested at this time (1:0/0/1)

Failure, music on hold ("m" flag to dial):

   -- Executing [151@xenir-group:2] Dial("IAX2/banbury-402", "Dahdi/G1/1XXXXXXXXXX,24,tm") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called G1/1XXXXXXXXXX
   -- Started music on hold, class 'default', on IAX2/banbury-402
[Mar  6 20:37:43] WARNING[2987]: chan_dahdi.c:9061 dahdi_write: Cannot handle frames in g722 format
[Mar  6 20:37:43] WARNING[2987]: app_dial.c:1410 wait_for_answer: Unable to forward voice or dtmf
   -- Hungup 'DAHDI/i1/1XXXXXXXXXX-9'
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Stopped music on hold on IAX2/banbury-402

Success, passthrough indication (no "r" flag):


   -- Executing [151@xenir-group:2] Dial("IAX2/banbury-5514", "Dahdi/G1/1XXXXXXXXXX,24,t") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called G1/1XXXXXXXXXX
   -- DAHDI/i1/1XXXXXXXXXX-8 is proceeding passing it to IAX2/banbury-5514
   -- IAX2/banbury-5514 requested special control 20, passing it to DAHDI/i1/1XXXXXXXXXX-8
   -- IAX2/banbury-5514 requested special control 20, passing it to DAHDI/i1/1XXXXXXXXXX-8
   -- DAHDI/i1/1XXXXXXXXXX-8 is making progress passing it to IAX2/banbury-5514

This probably increases the severity of this bug a bit.


By: Jacob LIpstein (jacobli) 2011-03-06 21:05:05.000-0600

The patch I suggested on 03/03 should fix the problem.
Add codecs G722, G729 if you need them
By: Chris Gentle (gentlec) 2011-03-07 09:09:10.000-0600

I think your patch above should be applied to channels/chan_dahdi.c and not main/chan_dahdi.c since there is no main/chan_dahdi.c in 1.8.x.  Or did I miss something?

I'll try your patch and post back with the results.  Thanks!
By: clint (clint) 2011-03-07 09:32:13.000-0600

Patch does in fact work as intended, however I wonder if we're not simply masking a larger issue.  What was the intention behind this check of codec type in the first place?

Perhaps we need to modify the title of this ticket to remove the reference to DISA, thereby indicating to others that this ticket has wider ramifications.

Is there anyone watching who can help to illuminate the thought behind this design?
By: Jacob LIpstein (jacobli) 2011-03-07 11:00:11.000-0600

Sorry. The patch has to be applied to channels:
--- channels/chan_dahdi.c
+++ channels/chan_dahdi.c
@@ -9056,6 +9056,8 @@
        return 0;
    }
    if ((frame->subclass.codec != AST_FORMAT_SLINEAR) &&
+ (frame->subclass.codec != AST_FORMAT_ILBC) &&
+ (frame->subclass.codec != AST_FORMAT_GSM) &&
        (frame->subclass.codec != AST_FORMAT_ULAW) &&
        (frame->subclass.codec != AST_FORMAT_ALAW)) {
        ast_log(LOG_WARNING, "Cannot handle frames in %s format\n", ast_getformatname(frame->subclass.codec));

And the issue is not related to DISA only.
And probably there are something behind the patch what the patch is masking but I'm running several asterisk the patch was applied to. Didn't run into any problem. Hope developers will investigate the issue and close it.
By: clint (clint) 2011-03-07 11:50:15.000-0600

gentlec,

If you can, please modify this bug to be against chan_dahdi rather than app_disa, and remove disa from the summary.  Hopefully that'll get it the attention it needs from the appropriate folks.  Probably also want to change it from minor to major, given the wide ranging effects.
By: Chris Gentle (gentlec) 2011-03-07 11:58:26.000-0600

I'll be happy to, if I can figure out how.  I can't seem to find a way to edit the report.  Do I have permission to do that as the reporter?  What am I missing?
By: Douglas Jensen (djensen99) 2011-03-10 20:57:17.000-0600

Just upgraded to 1.8.3 from 1.6.2.17 - spun my wheels for 2 hours dialing our own number with g729 and going straight to voicemail for all dahdi extensions.  Recommend adding a line for AST_FORMAT_G729A to the final version of this patch (it worked for us just fine).
By: Douglas Jensen (djensen99) 2011-09-16 14:03:31.536-0500

Any update on this issue?  It's annoying to manually delete the lines in question each time we build a new version of Asterisk.
By: Chris Gentle (gentlec) 2011-09-20 09:29:28.072-0500

As suggested, changing this from app_disa to chan_dahdi.
By: cmaj (cmaj) 2011-11-11 17:45:16.188-0600

Still a problem on upgrade from 1.6 to 1.8.7.1 -- without upgrading DAHDI though.
By: cmaj (cmaj) 2011-11-11 17:57:03.617-0600

Wow, dialing IAX with gsm to DAHDI does not work like this:

exten => s,n,Dial(DAHDI/22&DAHDI/23&DAHDI/24)

but does work with a single channel:

exten => s,n,Dial(DAHDI/22)

and surprisingly works like this (1 second ring on first channel must solidify the call as needing gsm<->ulaw conversion):

exten => s,n,Dial(DAHDI/22,1)
exten => s,n,Dial(DAHDI/22&DAHDI/23&DAHDI/24)