[Home]

Summary:ASTERISK-18639: Multiple Bridge Events Triggered Upon DTMF Key-Presses
Reporter:Michael Iedema (michael_iedema)Labels:
Date Opened:2011-09-28 19:35:38Date Closed:2013-11-22 15:05:31.000-0600
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:10.0.0-beta1 10.0.0-beta2 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Ubuntu 11.04, 64bitAttachments:
Description:When the two legs of a call connect an initial Bridge.Link event is fired. Then, upon DTMF key-presses, Bridge.Unlink and Bridge.Link events are fired for each key-press. When the call is destroyed, the expected Bridge.Unlink event is fired.

A complete trace of this behavior follows: 201 calls 202, presses 1, 2, 3, hangs up


Response: Success
Message: Authentication accepted

Event: FullyBooted
Privilege: system,all
Status: Fully Booted

Event: ExtensionStatus
Privilege: call,all
Exten: 201
Context: internal
Hint: SIP/201
Status: 2

Event: ExtensionStatus
Privilege: call,all
Exten: 202
Context: internal
Hint: SIP/202
Status: 8

Event: ExtensionStatus
Privilege: call,all
Exten: 202
Context: internal
Hint: SIP/202
Status: 2

Event: Bridge
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/202-00000003
Uniqueid: 1317256274.3
Digit: 1
Direction: Received
Begin: Yes
End: No

Event: Bridge
Privilege: call,all
Bridgestate: Unlink
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/201-00000002
Uniqueid: 1317256274.2
Digit: 1
Direction: Sent
Begin: Yes
End: No

Event: Bridge
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/202-00000003
Uniqueid: 1317256274.3
Digit: 1
Direction: Received
Begin: No
End: Yes

Event: Bridge
Privilege: call,all
Bridgestate: Unlink
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/201-00000002
Uniqueid: 1317256274.2
Digit: 1
Direction: Sent
Begin: No
End: Yes

Event: Bridge
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/202-00000003
Uniqueid: 1317256274.3
Digit: 2
Direction: Received
Begin: Yes
End: No

Event: Bridge
Privilege: call,all
Bridgestate: Unlink
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/201-00000002
Uniqueid: 1317256274.2
Digit: 2
Direction: Sent
Begin: Yes
End: No

Event: Bridge
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/202-00000003
Uniqueid: 1317256274.3
Digit: 2
Direction: Received
Begin: No
End: Yes

Event: Bridge
Privilege: call,all
Bridgestate: Unlink
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/201-00000002
Uniqueid: 1317256274.2
Digit: 2
Direction: Sent
Begin: No
End: Yes

Event: Bridge
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/202-00000003
Uniqueid: 1317256274.3
Digit: 3
Direction: Received
Begin: Yes
End: No

Event: Bridge
Privilege: call,all
Bridgestate: Unlink
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/201-00000002
Uniqueid: 1317256274.2
Digit: 3
Direction: Sent
Begin: Yes
End: No

Event: Bridge
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/202-00000003
Uniqueid: 1317256274.3
Digit: 3
Direction: Received
Begin: No
End: Yes

Event: Bridge
Privilege: call,all
Bridgestate: Unlink
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: DTMF
Privilege: dtmf,all
Channel: SIP/201-00000002
Uniqueid: 1317256274.2
Digit: 3
Direction: Sent
Begin: No
End: Yes

Event: Bridge
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: Bridge
Privilege: call,all
Bridgestate: Unlink
Bridgetype: core
Channel1: SIP/201-00000002
Channel2: SIP/202-00000003
Uniqueid1: 1317256274.2
Uniqueid2: 1317256274.3
CallerID1: 201
CallerID2: 202

Event: Cdr
Privilege: cdr,all
AccountCode:
Source: 201
Destination: 202
DestinationContext: 201
CallerID: "201" <201>
Channel: SIP/201-00000002
DestinationChannel: SIP/202-00000003
LastApplication: Dial
LastData: SIP/202,10
StartTime: 2011-09-28 17:31:14
AnswerTime: 2011-09-28 17:31:16
EndTime: 2011-09-28 17:31:22
Duration: 8
BillableSeconds: 6
Disposition: ANSWERED
AMAFlags: DOCUMENTATION
UniqueID: 1317256274.2
UserField:

Event: ExtensionStatus
Privilege: call,all
Exten: 202
Context: internal
Hint: SIP/202
Status: 0

Event: ExtensionStatus
Privilege: call,all
Exten: 201
Context: internal
Hint: SIP/201
Status: 0
Comments:By: Terry Wilson (twilson) 2011-10-25 17:07:14.954-0500

Unfortunately, this is representative of what is actually happening in the system. It is as designed. When Asterisk is set to interpret dtmf events, it will break the bridge to interpret the dtmf event, then re-connect the bridge afterwards. So, for each dtmf event you end up with an unlink and a link event for the dtmf begin and end frames. If Asterisk is not set to interpret dtmf features (for example by not having any dial options like t,T,w,W, etc.) then you will not see these events.
By: Ben Langfeld (benlangfeld) 2012-09-24 03:56:36.036-0500

So what you are saying, Terry, is that one should not attempt to write software which consumes the AMI Bridge API because Asterisk is unwilling to present this API in such a way that deterministic software may be written against it? It may represent internal state, but it does not represent anything useful, which makes it a bug in my book.
By: Ben Langfeld (benlangfeld) 2013-01-15 09:46:42.777-0600

Further information about why this behavior in Asterisk is total nonsense is available here: https://github.com/adhearsion/adhearsion/issues/188#issuecomment-12273153

I really hope this can be fixed in Asterisk 12 with the AMI changes. Asterisk is currently making 3rd party developer's lives...well, impossible, for no gain to Asterisk. This issue needs to be reopened.
By: James Le Cuirot (chewi) 2013-01-15 09:52:36.905-0600

I have not encountered this issue myself but I may well do in future. I believe it should be addressed.
By: Jason Parker (jparker) 2013-01-15 09:55:48.179-0600

Adding "+1" comments on issues (especially those that do not affect you) is not useful.  Please refrain from doing so.
By: Matt Jordan (mjordan) 2013-11-22 15:05:23.221-0600

After a lot of thought, I'm going to move to close this out as Fixed in Asterisk 12. In Asterisk 12, there is only one BridgeEnter event when a channel enters into a Bridge, and a single BridgeLeave event when a channel leave a Bridge. You are guaranteed to get those events in pairs, and the events have semantic meaning. While in a bridge, a channel can communicate per the media policies set forth in that bridge. Hitting DTMF, having your media restricted (call hold), and other shenaniganry does not change the fact that you are *in the bridge*. This behavior was well defined and is documented on the Asterisk 12 wiki in the AMI specification.

As this is a core concept in Asterisk 12, it certainly extends beyond just AMI - but this issue is all about AMI.

I'm concerned about attempting to fix this in Asterisk 1.8 and 11, as I'll explain here.

I don't diagree with the bug report on its face: Bridge enter/leave events are tantamount to meaningless in Asterisk 1.8/11, for the reasons enumerated by Ben (although I'm not sure we're drunk at the wheel, it's just a very hard wheel to steer in 1.8/11). Let's say we move the events so that they are, at the very least, not triggered by DTMF. A small improvement.

Due to the way the briding loops are structured, it is still difficult to prevent said events from firing on bridge changes from native bridges to feature bridges. We can solve this problem by moving the events further out of the loops to the beginning of {{ast_bridge_call}} in features.c - but we still haven't actually solved the problem.

At this point, the problem comes back to Masquerades. If you masquerade the channel - which will happen quite often on the outbound channel - the Bridge leave event will be for a Zombie channel, and you will not get any information about the masqueraded channel. So we still can't guarantee the sanity of these events - there's still no direct correlation between the two, and you still can't trust what they tell you.

To address each of these various problems goes quickly down the road of the architectural changes we made in Asterisk 12 - which, of course, were akin to a complete trashcanning of the existing bridging code and usage of the bridging framework. To really solve this in 1.8/11, we'd simply be backporting all of the bridging work done in 12 to those branches, which isn't feasible (CDRs, CEL, AMI, Stasis are also all needed, at a minimum).

For all of those reasons, I'm going to close this out as Fixed in Asterisk 12. I completely understand that this doesn't help Asterisk 1.8/11 and does make bridge detection in those versions incredibly complex and difficult - but hopefully this will also provide some impetus behind why we made the changes we did in Asterisk 12, and encourage people to adopt the new architecture.
By: Ben Langfeld (benlangfeld) 2013-11-22 20:02:32.254-0600

That makes perfect sense, Matt, and I'm glad the situation is resolved in 12. I'm very much looking forward to all of the improvements that have been made there!