| Summary: | ASTERISK-26262: stasis: Playing MOH to bridge with ARI does not work | ||||
| Reporter: | Joshua C. Colp (jcolp) | Labels: | |||
| Date Opened: | 2016-08-02 14:19:21 | Date Closed: | 2016-08-02 14:19:40 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Resources/res_stasis | ||
| Versions: | 13.9.1 13.10.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Ubuntu 14.04.4 LTS | Attachments: | ( 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 | ||||