[Home]

Summary:ASTERISK-24281: When bridging 2 chan_sip channels, MOH not removed from on-hold channels and bridge is never destroyed after hangup.
Reporter:Stefan Engström (StefanEng86)Labels:
Date Opened:2014-08-28 11:03:16Date Closed:2015-03-14 09:49:39
Priority:MajorRegression?
Status:Closed/CompleteComponents:Bridges/bridge_holding Channels/chan_sip/General
Versions:SVN 12.5.0 Frequency of
Occurrence
Related
Issues:
is duplicated byASTERISK-25079 AMI bridge of channels results in MOH not destroyed and robotic audio on one channel
Environment:Attachments:( 0) full.txt
Description:Create 3 SIP peers A, B and C.
A dials C. C answers. A puts C on hold (with INVITE with a=sendonly)
A dials B.
At this point I have 2 simple bridges in asterisk, [SIP/A,SIP/B] and [SIP/A,SIP/C].

Send a manager command:
Action: Bridge
Channel1: SIP/B
Channel2: SIP/C
Tone: no

This action destroys the two old bridges, and creates a new one with [SIP/B, SIP/C] as expected, but C still has the music on hold running and there seems to be no way of removing it. Should the music on hold/recvonly not stop when SIP/C leaves the old bridge?

Comments:By: Rusty Newton (rnewton) 2014-09-17 09:56:57.813-0500

Yeah this is definitely a bug. Just reproduced it. The MOH overlaps the voice as well.

By: Rusty Newton (rnewton) 2014-09-17 10:37:11.521-0500

Also noticed the bridge is never destroyed.  Going to attach some debug.

By: Rusty Newton (rnewton) 2014-09-17 10:50:57.122-0500

Attached a full log with DEBUG showing the AMI bridge and both bridged channels eventually hanging up.

Afterwards you are left with a empty bridge:

newtonr-laptop*CLI> bridge show ea5a7775-9fd8-4fe4-894b-c4d23caad9ea
Id: ea5a7775-9fd8-4fe4-894b-c4d23caad9ea
Type: basic
Technology: native_rtp
Num-Channels: 0

By: Corey Farrell (coreyfarrell) 2014-11-12 14:39:56.382-0600

I've committed a fix to the leaked bridge.  I do not believe this will have any effect on the MOH not being removed, so I've left this ticket open.

By: Stefan Engström (StefanEng86) 2015-03-14 08:16:09.748-0500

I could not reproduce this issue on 13.1.0. It looks like whatever you have done fixed it for version 13 at least

By: Zane Conkle (zconkle) 2015-05-11 15:35:44.865-0500

The issue with MOH not stopping on the held channel is still a reproducible problem on 13.3.2. I have not run into the bridge not being destroyed so that must have been fixed.

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

PJSIP/205 dials <ten digit number>
PJSIP/205 dials PJSIP/200 -> <ten digit number> is placed on hold

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

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.