[Home]

Summary:ASTERISK-26094: stasis: Playing MOH to bridge with ARI does not work
Reporter:Cameron (cbanta78)Labels:pjsip
Date Opened:2016-06-07 10:14:50Date Closed:2018-10-01 04:35:17
Priority:MajorRegression?
Status:Closed/CompleteComponents:Resources/res_stasis
Versions:13.9.1 13.10.0 Frequency of
Occurrence
Constant
Related
Issues:
is a clone ofASTERISK-26262 stasis: Playing MOH to bridge with ARI does not work
is related toASTERISK-26083 ARI: Announcer channels staying around after playback to a bridge is finished
Environment:Ubuntu 14.04.4 LTSAttachments:( 0) debug_log_26094
( 1) mohbug.js
Description:I do the following on an incoming call:

1 - Create/Update a bridge using ARI (POST to /bridges/\{bridgeid} with custom bridgeid and type=mixing

2 - Add current channel to bridge (POST /bridges/\{bridgeId}/addChannel). Nothing for role. There is now 1 channel in bridge.
   -- Channel PJSIP/abc-00000000 joined 'simple_bridge' stasis-bridge <1111a>

3 - Play moh (POST to /bridges/\{bridgeid}/moh).

Expected to hear something on channel, but nothing. Console debug says moh started and then immediately says it stopped with no reason why.
   -- Channel Announcer/ARI_MOH-00000000;2 joined 'simple_bridge' stasis-bridge <1111a>
   -- Started music on hold, class 'en', on channel 'Announcer/ARI_MOH-00000000;1'
   -- Stopped music on hold on Announcer/ARI_MOH-00000000;1


4 - Play moh again. Same parameters.

Now moh file plays just fine. The single short wav file plays over and over as expected.


5 - Hangup channel, and repeat.


After the steps above, every time I POST to /bridges/\{bridgeid}/moh I get an error back "Allocation failed". Nothing is heard. Nothing is logged on asterisk console for this POST. (Debug 9, verbose 9)
Comments:By: Asterisk Team (asteriskteam) 2016-06-07 10:14:50.823-0500

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: Joshua C. Colp (jcolp) 2016-06-07 10:43:02.595-0500

Thanks for the reproduction information. Can you also attach console output with core debug on and logging?

By: Joshua C. Colp (jcolp) 2016-06-07 11:17:56.310-0500

After looking at this the underlying cause seems to be the same as ASTERISK-26083 so I'm closing this one out in favor of that one.

By: Cameron (cbanta78) 2016-06-22 14:37:41.946-0500

I tried latest git version of asterisk today with the commit in issue ASTERISK-26083, and it does not fix the issue reported here.

By: Asterisk Team (asteriskteam) 2016-06-22 14:37:42.220-0500

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: Cameron (cbanta78) 2016-06-22 15:19:49.476-0500

Some more details.

I seem to have not been deleting the bridge after all channels left. If I delete the bridge after all channels have left, I do not get the allocation error.

However, I still have to send the startMoh command twice before it plays.

By: Cameron (cbanta78) 2016-06-22 15:22:38.635-0500

sample code to reproduce the issue

By: Mark Ingles (markingles) 2016-06-23 18:46:21.884-0500

I tried to reproduce on 13.9.1 and GIT-13-dab39a6 and couldn't reproduce it. I just saw your reproduction code as I refreshed. I'll try adding the wait(1) from the dialplan. I was originating the channel via ari. -Mark

By: Mark Ingles (markingles) 2016-06-23 19:49:55.948-0500

I installed node and your sample code and it uses the default mohclass. I tried to tell it to use the class named "en", but it still wanted to play default. Can you show me your musiconhold.conf so I can duplicate it?

In my prior tests, I used the default moh file of manolo_camp-morning_coffee.ulaw and put it in as the only file (named moh.ulaw) in  /var/lib/asterisk/moh1/  and set musiconhold.conf to:

[en]
mode=files
directory=moh1

I also thought maybe you where hitting 2 during your 1 sec wait() in the dialplan, but either I couldn't hit 2 fast enough, or that wasn't it.

Mark


By: Cameron (cbanta78) 2016-08-01 21:16:38.125-0500

Second script to produce the error, with log from script.

Test procedure:
Call extension.
Wait for answer.
Press 2. This sends startMoh ARI to bridge. Expecting to hear something, but nothing.
Press 2 again. Now we hear the music.
Hangup.
Call again.
Wait for answer.
Press 2. Get an allocation failed error.

By: Cameron (cbanta78) 2016-08-01 21:18:41.866-0500

Second script and log had the same names as the first ones, so I deleted the first ones to avoid confusion.

I have noticed the error only happens when sending a client generated ID for the bridge ('mohbug' in the example). When not sending a bridge ID, and using the asterisk generated ID, there is no allocation error message. (But still have to start moh twice to hear anything.)

EDIT: The autogenerated ID works, because it's random each time and never used again. The allocation error happens when using a bridge ID that's been used before. (Whether it was destroyed or not.)

By: Cameron (cbanta78) 2016-08-01 21:19:56.262-0500

My latest testing was done on GIT-13-f2a93dcM from a couple days ago. Should be 13.10

By: Cameron (cbanta78) 2016-08-02 14:06:54.685-0500

This really appears to be nearly the same issue as ASTERISK-26083. Can what was done for the announcer channels be done to the moh channels?

I added some debug code, and found out that the ao2_find(app_bridges_moh... [1] returns a moh_wrapper even after the bridge has been destroyed and recreated. That leads to ast_channel_get_by_name and the function returning NULL [2]. I would expect the moh_wrapper to be destroyed when the bridge is destroyed.

[1] https://github.com/asterisk/asterisk/blob/11caa10cf5abae8abef91a887c30e81e8d38486a/res/res_stasis.c#L614
[2] https://github.com/asterisk/asterisk/blob/11caa10cf5abae8abef91a887c30e81e8d38486a/res/res_stasis.c#L620

By: Moritz Fain (maurice2k) 2018-06-25 10:51:48.467-0500

The problem is that the critical section in {{stasis_app_bridge_moh_channel}} is too short; the lock should only be released *after* {{ast_channel_get_by_name}} logic, right before the return.
Further, there was no cleaning up of the {{moh_wrapper}} in {{moh_channel_thread}} which resulted in cached {{moh_wrapper}} structures being returned from {{ao2_find}} but the channel was already gone.

I made a patch here:
https://github.com/asterisk/asterisk/compare/15.3.0...maurice2k:bugfix-26094

I signed the license agreement, but not sure how to proceed from here with code commits.


By: Richard Mudgett (rmudgett) 2018-06-25 11:01:43.959-0500

Thanks for the contribution! If you'd like your contribution to be included faster, you should submit your patch for code review by the Asterisk Developer Community. To do so, please follow the Code Review [1] instructions on the wiki. Be sure to:
* Verify that your patch conforms to the Coding Guidelines [2]
* Review the Code Review Checklist [3] for common items reviewers will look for
* If necessary, provide tests for the Asterisk Test Suite that verify the correctness of your patch [4]

When ready, submit your patch and any tests to Gerrit [5] for code review.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Code+Review
[2] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines
[3] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist
[4] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation
[5] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage



By: Moritz Fain (maurice2k) 2018-06-25 13:52:23.014-0500

Unfortunately Gerrit OpenId login is not working for me. Maybe the license agreement is not yet approved (filled out the form last week)?

By: Friendly Automation (friendly-automation) 2018-10-01 04:35:18.805-0500

Change 10289 merged by Joshua Colp:
res_stasis: Fix stale data in ARI bridges

[https://gerrit.asterisk.org/10289|https://gerrit.asterisk.org/10289]

By: Friendly Automation (friendly-automation) 2018-10-01 04:35:32.014-0500

Change 10287 merged by Joshua Colp:
res_stasis: Fix stale data in ARI bridges

[https://gerrit.asterisk.org/10287|https://gerrit.asterisk.org/10287]

By: Friendly Automation (friendly-automation) 2018-10-01 04:35:45.591-0500

Change 10288 merged by Joshua Colp:
res_stasis: Fix stale data in ARI bridges

[https://gerrit.asterisk.org/10288|https://gerrit.asterisk.org/10288]

By: Friendly Automation (friendly-automation) 2018-10-01 06:24:33.580-0500

Change 9297 merged by Joshua Colp:
res_stasis: Fix stale data in ARI bridges

[https://gerrit.asterisk.org/9297|https://gerrit.asterisk.org/9297]