[Home]

Summary:ASTERISK-17541: Calls from VOIP to Dahdi requiring transcoding fail
Reporter:clint (clint)Labels:
Date Opened:2011-03-10 21:18:09.000-0600Date Closed:2012-03-14 12:25:19
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_bridge Channels/chan_dahdi
Versions:1.8.3 1.8.7.2 1.8.8.0 10.0.0 Frequency of
Occurrence		Constant
Related
Issues:
is the original version of this clone:ASTERISK-19197 Calls from VOIP to Dahdi requiring transcoding fail
is related toASTERISK-16901 DISA "Cannot handle frames in gsm format"
Environment:Attachments:( 0) codec_fix.patch
Description:A call which originates on VOIP (SIP, IAX tested) and terminates via Dahdi will fail if codec other than ulaw is used on VOIP leg of call.

ASTERISK-16901 is a subset of this issue - that issue refers specifically to DISA having this problem, however the problem exists whenever a call is bridged from VOIP to Dahdi.  Creating a new issue to highlight the wider scope of the bug and clarify that it is not DISA related.
Comments:By: clint (clint) 2011-03-10 21:21:41.000-0600

Issue 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
By: clint (clint) 2011-03-18 18:40:00

Still the case in 1.8.3.2.  1.8 is completely unusable without major dialplan workarounds (turn off all music on hold, remove all dial command r's.)
By: Jacob LIpstein (jacobli) 2011-03-21 11:55:53

For 1.8.3 apply the following patch and you will not have any problem with GSM/g722/g729 codecs. For other 1.8 versions the patch is similar.

--- channels/chan_dahdi.c
+++ channels/chan_dahdi.c
@@ -9056,6 +9056,10 @@
        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_G722) &&
+ (frame->subclass.codec != AST_FORMAT_G729) &&
        (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));
By: clint (clint) 2011-03-21 12:14:32

While the above patch does indeed stop the error from appearing, the guy who thought that the codec check would be useful in the first place needs to chime in here with an explanation of the motivation behind the check.  Otherwise, the above patch would be more correct in simply removing the if() statement altogether.

Additionally, the subsequent code seems to depend upon the call being in either slin or u/alaw.

So I don't think the above patch is correct.

More likely, the problem is that for some reason, when asterisk is presenting indication, the leg of the call on dahdi (the outbound leg in the case above) is being flagged with the codec of the inbound (voip) leg, causing dahdi_write to blow up.  It is clear that this flag is being set in a manner inconsistent with reality, as if the frames were truly not in one of the acceptable formats, something would blow up further down the road after we ignore the format per the patch above.
By: Jacob LIpstein (jacobli) 2011-03-21 12:34:42

I agree that it looks like the statement could be removed completely but without any notice of the real reason of the issue I (and some other guys) am using the patch at several Asterisk instances without any problem. And waiting when the issue will be fixed and closed by the Asterisk team.
By: clint (clint) 2011-04-22 17:31:50

Tested in 1.8.3.3, problem still present.
By: clint (clint) 2011-05-10 09:42:09

Issue persists in 1.8.4.
By: clint (clint) 2011-07-17 20:29:58.586-0500

Tested in 1.8.5.0.  Issue persists.
By: Gregory Hinton Nietsky (irroot) 2011-07-18 04:29:29.974-0500

This patch is fundamentally flawed ill patch a working solution in a few seconds
By: Gregory Hinton Nietsky (irroot) 2011-07-18 04:36:33.178-0500

More generic codec fixup.

Dahdi is only capable of SLIN/ALAW/ULAW we need to make sure the call is compatiable before it gets to the channel.
By: Niccolò Belli (darkbasic) 2011-12-17 09:24:28.960-0600

Which version of asterisk does include the fix?
By: clint (clint) 2012-01-12 14:39:54.481-0600

This bug is not fixed in 10.0.

By: Niccolò Belli (darkbasic) 2012-01-12 15:32:16.192-0600

Why it's closed with Resolution: "Fixed" then?
By: Sean Bright (seanbright) 2012-02-20 12:13:34.698-0600

I'm not sure why this issue was closed (because the clone was closed maybe)?  This is still an issue with 1.8-latest SVN.
By: Matt Jordan (mjordan) 2012-02-20 12:38:03.990-0600

It was closed because the commit message for r337430 specified that the issue should be closed.  The issue is back on the radar.
By: Richard Mudgett (rmudgett) 2012-03-07 16:03:02.700-0600

See reviewboard for patch.
https://reviewboard.asterisk.org/r/1805/