main/cdr: Fix crash/memory consumption in CDRs in multi-party bridge scenarios

This patch fixes an issue where CDRs would get stuck generating an infinite
number of CDRs, eventually crashing Asterisk (and consuming a lot of memory
along the way).

When a channel enters into a multi-party bridge, the CDR engine creates
mappings of each participant to each other participant, picking the 'A' party
as it goes. So, if we have four channels in a multi-party bridge (Alice, Bob,
Charlie, Denise), we would have something like:

Alice => Bob
Alice => Charlie
Alice => Denise
Bob => Charlie
Bob => Denise
Charlie => Denise

This works fine when participants enter the bridge a single time.

When a participant leaves a bridge, the CDRs for that channel are transitioned
to a finalized state.

The bug occurs if Bob rejoins. When the CDR engine creates mappings between the
channels, it walks through all the participants currently in the bridge, and
realizes that no one in the bridge can create a CDR with the channel (Bob).
As such it creates a new CDR for the candidate and appends it to that
candidate's chain. Unfortunately, on this particular code path, it doesn't
stop traversing the candidate's chain. Since we just added ourselves to the
chain, this causes the loop to keep going, constantly adding new CDRs.

This patch makes it so the engine bails when it creates a CDR match in this
case.

Review: https://reviewboard.asterisk.org/r/3964/

ASTERISK-24241 #close
Reported by: Deepak Singh Rawat
Tested by: Deepak Singh Rawat

ASTERISK-24208
Reported by: Frankie Chin
........

Merged revisions 422715 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422716 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@422717 f38db490-d61c-443f-a65b-d21fe96a405b
main/cdrs: Preserve context/extension when executing a Macro or GoSub

The context/extension in a CDR is generally considered the destination of a
call. When looking at a 2-party call CDR, users will typically be presented
with the following:

context    exten      channel     dest_channel app  data
default    1000       SIP/8675309 SIP/1000     Dial SIP/1000,,20

However, if the Dial actually takes place in a Macro, the current behaviour
in 12 will result in the following CDR:

context    exten      channel     dest_channel app  data
macro-dial s          SIP/8675309 SIP/1000     Dial SIP/1000,,20

The same is true of a GoSub:

context    exten      channel     dest_channel app  data
subs       dial_stuff SIP/8675309 SIP/1000     Dial SIP/1000,,20

This generally makes the context/exten fields less than useful.

It isn't hard to preserve these values in the CDR state machine; however, we
need to have something that informs us when a channel is executing a
subroutine. Prior to this patch, there isn't anything that does this.

This patch solves this problem by adding a new channel flag,
AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a
Macro or a GoSub. The CDR engine looks for this value when updating a Party A
snapshot; if the flag is present, we don't override the context/exten on the
main CDR object. In a funny quirk, executing a hangup handler must *not* abide
by this logic, as the endbeforehexten logic assumes that the user wants to see
data that occurs in hangup logic, which includes those subroutines. Since
those execute outside of a typical Dial operation (and will typically have
their own dedicated CDR anyway), this is unlikely to cause any heartburn.

Review: https://reviewboard.asterisk.org/r/3962/

ASTERISK-24254 #close
Reported by: tm1000, Tony Lewis
Tested by: Tony Lewis
........

Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@422720 f38db490-d61c-443f-a65b-d21fe96a405b