[Home]

Summary:ASTERISK-27579: app_bridgewait: ring tone generation not stopped with entertainment disabled
Reporter:Jean Aunis - Prescom (PrescomJA)Labels:
Date Opened:2018-01-12 05:02:14.000-0600Date Closed:2018-01-12 10:51:36.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_bridgewait
Versions:14.7.4 Frequency of
Occurrence
Constant
Related
Issues:
duplicatesASTERISK-25079 AMI bridge of channels results in MOH not destroyed and robotic audio on one channel
Environment:Attachments:( 0) full.txt
Description:Ringtone generation is not stopped on a channel when it enters the BridgeWait application with no entertainment, even after it has been bridged to another channel.

Consider the following dialplan :
{noformat}
[incoming_call]
exten = 302,1,Answer()
same  = n,Ringing()
same  = n,Set(DB(junk/mychan)=${CHANNEL})
same  = n,BridgeWait(,,e(n))

exten = 303,1,Bridge(${DB(junk/mychan)})
{noformat}

PHONE1 calls extension 302. PHONE2 calls extension 303, and thus is bridged to PHONE1.

Asterisk keeps generating the ring tone to PHONE1. As a result, PHONE1 cannot hear anything because it receives RTP packets from both Asterisk and PHONE2.

The issue does not happen when BridgeWait is asked to provide entertainment, for example by calling BridgeWait(,,e(s)).
Comments:By: Asterisk Team (asteriskteam) 2018-01-12 05:02:15.442-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Jean Aunis - Prescom (PrescomJA) 2018-01-12 05:03:20.279-0600

Attached full log with debug set to 4.

By: Joshua C. Colp (jcolp) 2018-01-12 05:06:17.021-0600

Does this also happen under 15? The 14 version receives only security fixes currently, so if the issue does still exist the fix will not be put into that version.

By: Jean Aunis - Prescom (PrescomJA) 2018-01-12 05:34:50.317-0600

It does not happen under 15. Do you know which commit may have fixed this issue ? As we cannot switch to 15 for the moment I will try to backport it to 14.

By: Joshua C. Colp (jcolp) 2018-01-12 05:48:25.137-0600

I don't, but all changes go through Gerrit so you can see if you can search on there to find the fix.

By: Jean Aunis - Prescom (PrescomJA) 2018-01-12 09:47:46.056-0600

Got it : this was fixed in ASTERISK-25079. Stopping the music on hold on a channel actually stops any generator running on it, so it also stops tones.

By: Asterisk Team (asteriskteam) 2018-01-12 09:47:46.453-0600

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.

By: Jean Aunis - Prescom (PrescomJA) 2018-01-12 09:50:26.963-0600

Closing again since fixed in 15.

By: Richard Mudgett (rmudgett) 2018-01-12 10:50:50.390-0600

FYI: You could have done the below dialplan instead since BridgeWait has a ringing entertainment which does the exact same thing as the Ringing application.  The advantages of this mode is that dialplan is simpler and BridgeWait is in charge of the entertainment while the channel is in the holding bridge.  Specifying no entertainment means BridgeWait is not going to do anything about entertainment.  BridgeWait also will answer the call if it is not already answered so using the Answer application isn't needed either.

{noformat}
[incoming_call]
exten = 302,1,NoOp()
same  = n,Set(DB(junk/mychan)=${CHANNEL})
same  = n,BridgeWait(,,e(r))

exten = 303,1,Bridge(${DB(junk/mychan)})
{noformat}

This really is a duplicate of ASTERISK-25079.