[Home]

Summary:ASTERISK-22891: One way audio if dialplan_exec menu option runs Dial application and certain codecs are used
Reporter:Stefan Tichy (st)Labels:
Date Opened:2013-11-22 11:08:51.000-0600Date Closed:2013-11-23 10:09:52.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Applications/app_confbridge
Versions:11.6.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Debian Wheezy, i386Attachments:
Description:The scenario is similar to the "using dialplan_exec" example in "Asterisk - The Definitive Guide". Here Dial is used instead of Originate.

The user menu in confbridge.conf is extended by two lines. Everything else is default.

{code}
*5=dialplan_exec(cbexec,test,1)
5=dialplan_exec(cbexec,test,1)
{code}

The referenced dialplan snippet is:

{code}
context cbexec {
   test => {
       Dial(SIP/25,15,gHF(conference,100,1));
   }
}
{code}

First participant (sip channel) enters the conference and dials "5" to contact another user and to fetch this user into the conference. If for example both phones use codec alaw, the following warning is printed:

{code}
channel.c:5081 ast_write: Codec mismatch on channel SIP/snom360-00000028 setting write format to slin from alaw native formats (alaw)
{code}

After this the first participant can listen to the conference but cannot speak to the conference.

If the first phone uses gsm codec instead of alaw, everything works as expected.

ASTERISK-21144 describes another one way audio problem. The jitterbuffer setting does not matter for the problem described here.
Comments:By: Matt Jordan (mjordan) 2013-11-22 11:21:17.070-0600

I don't really think this is a bug.

Using Dial doesn't really make sense in the context of the {{dialplan_exec}} action. Dial implicitly creates a second bridge between the caller and the callee - at which point, they are in a bridge together and not in the ConfBridge. The bridging code between the caller and the callee will make those two channels compatible - and if, in the process of doing so, they are made incompatible with the ConfBridge, there's not much that can be done.

By: Stefan Tichy (st) 2013-11-22 11:48:09.464-0600

Thanks for the explanation. I supposed that using Dial could cause problems, but until now I was not sure about it. Maybe the documentation in confbridge.conf could be adjusted.
By: Matt Jordan (mjordan) 2013-11-22 14:15:42.469-0600

Really, anything that is incredibly long running or puts the channel into another bridge may cause problems. Queue, for example, would be another one.

The idea for {{dialplan_exec}} is that you want to go execute something custom when the user presses a DTMF, but not that it fundamentally changes what the participant is doing, that is, being in a ConfBridge. If they need to leave to go do some long running action, it may be better to have them removed from the conference completely (leave_conference).
By: Stefan Tichy (st) 2013-11-23 10:08:33.754-0600

This is the information I have missed. It is not a bug, but should be explained to the user.