[asterisk-bugs] [JIRA] (ASTERISK-18639) Multiple Bridge Events Triggered Upon DTMF Key-Presses

Matt Jordan (JIRA) noreply at issues.asterisk.org
Fri Nov 22 16:08:03 CST 2013 

    [ https://issues.asterisk.org/jira/browse/ASTERISK-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=212187#comment-212187 ] 

Matt Jordan edited comment on ASTERISK-18639 at 11/22/13 4:07 PM:
------------------------------------------------------------------

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.
                
      was (Author: mjordan):
    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 tatamount of meaningless in Asterisk 1.8/11, for the reasons enumerated by Ben. 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 go ahead and close this out as Fixed - but 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.
                  
> Multiple Bridge Events Triggered Upon DTMF Key-Presses
> ------------------------------------------------------
>
>                 Key: ASTERISK-18639
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-18639
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/ManagerInterface
>    Affects Versions: 10.0.0-beta1, 10.0.0-beta2
>         Environment: Ubuntu 11.04, 64bit
>            Reporter: Michael Iedema
>            Severity: Critical
>      Target Release: 12.0.0
>
>
> 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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

More information about the asterisk-bugs mailing list