Summary:ASTERISK-25079: AMI bridge of channels results in MOH not destroyed and robotic audio on one channel
Reporter:Zane Conkle (zconkle)Labels:pjsip
Date Opened:2015-05-12 12:47:36Date Closed:2017-12-20 08:12:58.000-0600
Status:Closed/CompleteComponents:Channels/chan_pjsip Channels/chan_sip/General Core/Bridging Resources/res_pjsip
Versions:13.3.2 13.4.0 Frequency of
duplicatesASTERISK-24281 When bridging 2 chan_sip channels, MOH not removed from on-hold channels and bridge is never destroyed after hangup.
is duplicated byASTERISK-27579 app_bridgewait: ring tone generation not stopped with entertainment disabled
Environment:Attachments:( 0) issue_25979.log
( 1) ps_endpoints.csv
( 2) rusty_extensions.txt
( 3) rusty_full.txt
( 4) rusty_messages.txt
( 5) rusty_pjsip.txt
( 6) rusty_reproduction.pcap
Description:[Edit by Rusty - Amended description]
An AMI bridge of two channels, where one is currently on hold and both are configured with direct_media=no results in MOH generally sticking around and very robotic audio on the channel previously on hold. Enabling direct_media results in expected working behavior.

[Edit by Rusty - Original description]

There is an issue with MOH not stopping when bridging channels.

Lets assume PJSIP/205 is me. Steps to reproduce:

PJSIP/205 Answers inbound call
PJSIP/205 dials PJSIP/200 -> inbound call is placed on hold

via AMI:
Action: Bridge
ActionID: 1234
Channel1: SIP/carrier-000000be
Channel2: PJSIP/200-00000100
Tone: no

The SIP/carrier channel still has hold music playing. I have tried this with PJSIP/PJSIP and SIP/PJSIP combinations and the issue happens both ways. I was thinking for a while it may have been due to mixing the technologies. One thing I have noticed is every so often the bridge will work. I cant find out what causes it.. It seems to be when I have the call held for an extended period of time before bridging. Also, if I set tone to "Both" the MOH will stop after the beep but you cannot hear the other party. There is a similar issue that was closed earlier this year reporting the same thing. I am not sure if this is a regression or if it was just assumed fixed.
Comments:By: Rusty Newton (rnewton) 2015-05-15 17:12:10.383-0500

Linking to ASTERISK-24281.. possibly is a duplicate or regression.

By: Rusty Newton (rnewton) 2015-05-15 17:15:37.812-0500

Zane can you provide a debug log (including manager debug) captured during the issue?


*Use Send Back or Enter Feedback to return the issue to us.

By: Zane Conkle (zconkle) 2015-05-15 18:23:37.218-0500


Attached is the debug log. When looking at this the dispatch1 channel (the inbound call) was the call that had the hold music still playing after the bridge.

Let me know how else I can help.


By: Rusty Newton (rnewton) 2015-06-03 17:46:31.616-0500

[~ipengineer] I tested with Asterisk GIT-13-5dc9fb4 (pulled this afternoon) and could not reproduce the issue. The AMI bridge works every time, even after leaving call A on hold for 10-15 minutes.

I tested with PJSIP to PJSIP and it seems you saw the issue there, so it should be a valid test. I used your same AMI command and call flow.

Could you test with a recent version of the 13 branch pulled from gerrit?

By: Zane Conkle (zconkle) 2015-06-04 10:46:36.324-0500

Attached is the ps_endpoints config for the three devices used in this scenario.

By: Rusty Newton (rnewton) 2015-06-04 19:42:00.179-0500

Zane I was able to reproduce the issue or at least a very similar issue after looking at your pjsip configuration and eliminating a few options. It looks like the key is direct_media.

I'm attaching several files prefixed with *rusty*. These can be used for reproduction and analysis.

In the files I have configured three extensions, ALICE, BOB and CATHY.

To reproduce, register phones to the configured PJSIP endpoints and then follow this direction:

* ALICE should call CATHY.
* CATHY should put ALICE on hold and then call BOB.
* At that point use AMI to bridge ALICE's and BOB's channels.

I used Zane's AMI:
Action: Bridge
ActionID: 1234
Channel1: <channel1>
Channel2: <channel2>
Tone: no

At this point you should note that ALICE's receive audio is "robotic" sounding and may or may not still include Music on Hold. Even if MOH doesn't stick around the audio was extremely robotic for me every time.

If direct_media=no is set then you will encounter the audio issues. If direct_media is undefined or set to yes then you will not encounter the audio issues (assuming you don't run into networking issues in your own lab).

By: Zane Conkle (zconkle) 2015-06-04 19:55:24.335-0500


That makes sense because when bridging PJSIP -> PJSIP I get the no audio issue (I have direct_media = no). When I bridge PJSIP -> SIP I get the robotic audio sound and MOH may or may not stop. There is no direct_media in that case because the SIP channel is always with the outside carrier.

I can try to set direct_media = yes and see if that fixes the PJSIP -> PJSIP problem.. Still not sure how we will fix the other issue I am having with PJSIP > SIP bridging. I am assuming that would still be a problem with PJSIP > PJSIP if one of the parties was outside.


By: Rusty Newton (rnewton) 2015-06-04 20:04:09.980-0500

I tested only PJSIP to PJSIP because PJSIP to SIP on one box is going to be extremely rare and not really recommended (but it should work too). I also didn't want to overload this single issue or complicate the troubleshooting too much. If you want, open a new issue for the problem with PJSIP to SIP and make a note on it for me to link it to this one. Hopefully when a developer fixes the root problem behind this then it will fix whatever issue you have when bridging PJSIP to SIP.

I'd imagine that the issue here is with bridging and not with either channel driver directly.

Are you sure that when bridging PJSIP channels you get no audio? I only ever had robotic audio (sometimes it was very quiet) and the MOH sticking around when it shouldn't.

The difference could be that my three endpoints are all on the same network and I didn't test with an inbound carrier from outside my network.

By: Zane Conkle (zconkle) 2015-06-09 16:31:12.646-0500

Correct, when bridging two PJSIP endpoints I would get one-way audio for one of the peers. When bridging PJSIP and SIP I would get the moh not destroyed problem. I agree this is probably an issue with bridging and I think the only reason I am seeing an issue with PJSIP -> SIP is because the outbound carrier is on chan_sip.

I will keep an eye on the issue and once a commit is pushed I will test it locally.

By: Zane Conkle (zconkle) 2015-07-08 13:52:41.072-0500

Wanted to update this issue. Even with direct_media enabled the hold music still persists in the background of the call once it is joined. This is a different result then having direct_media disabled in that when it is disabled the media is never bridged to begin with.

By: Rusty Newton (rnewton) 2015-07-11 17:23:48.506-0500

Odd, I didn't see that in my reproduction. There is certainly weirdness happening. I updated the summary to reflect your finding. Hopefully whatever fix is found will fix both scenarios.

By: Zane Conkle (zconkle) 2015-07-28 15:32:55.376-0500

Tested against 13.5.0-rc1 issue still exists. Was hoping ASTERISK-25171 might have fixed it since similar symptoms were shared.

Simulated the test four times. First attempt call was bridged with MOH still on the channel and no media from the bridged party. Next two attempts things worked as expected call was bridged with no moh or robotic sound on the channel. Last attempt moh was present on the channel after bridged but you could also here the party in the background.

By: nappsoft (nappsoft) 2016-07-25 10:52:40.963-0500

Still the same problem with 13.10.0 (only PJSIP channels involved!)

By: nappsoft (nappsoft) 2017-01-18 07:01:38.529-0600

Still the same problem with 13.13.0

By: Friendly Automation (friendly-automation) 2017-12-20 08:12:59.224-0600

Change 7616 merged by Jenkins2:
bridge: Stop music on hold on adding an arbitrary channel to a bridge


By: Friendly Automation (friendly-automation) 2017-12-20 08:22:28.823-0600

Change 7617 merged by Jenkins2:
bridge: Stop music on hold on adding an arbitrary channel to a bridge


By: Friendly Automation (friendly-automation) 2017-12-20 08:35:55.501-0600

Change 7615 merged by Jenkins2:
bridge: Stop music on hold on adding an arbitrary channel to a bridge