> On Sept. 3, 2014, 12:01 p.m., rmudgett wrote: > > /branches/12/main/cdr.c, lines 1352-1354 > > <https://reviewboard.asterisk.org/r/3962/diff/1/?file=66995#file66995line1352> > > > > The comment seems wrong.
Actually, I think it is still correct. If a channel has been hung up on - indicated by the 'we are executing hangup stuff' flag - and we are told to ignore hangup updates via the 'endbeforehexten' flag - then we make sure our CDR knows that Party A has been hung up and we bail. We don't actually update the Party A snapshot with the new information (which happens on line 1369). - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3962/#review13215 ----------------------------------------------------------- On Aug. 29, 2014, 9:33 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3962/ > ----------------------------------------------------------- > > (Updated Aug. 29, 2014, 9:33 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24254 > https://issues.asterisk.org/jira/browse/ASTERISK-24254 > > > Repository: Asterisk > > > Description > ------- > > 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. Today, 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. > > > Diffs > ----- > > /branches/12/main/cdr.c 422438 > /branches/12/include/asterisk/channel.h 422438 > /branches/12/apps/app_stack.c 422438 > /branches/12/apps/app_macro.c 422438 > > Diff: https://reviewboard.asterisk.org/r/3962/diff/ > > > Testing > ------- > > All existing CDR tests and the hangup handler tests pass. > > In addition, a new test has been added on review 3963. This test performs > several Dials within a Macro/GoSub, with at least one nested > GoSub/Macro/GoSub wrapping a Dial. The CDR entry is verified to have the > expected fields. > > > Thanks, > > Matt Jordan > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
