----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3962/#review13235 -----------------------------------------------------------
/branches/12/apps/app_stack.c <https://reviewboard.asterisk.org/r/3962/#comment23725> unsigned int for single bit bitfields - rmudgett On Sept. 4, 2014, 11:25 a.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3962/ > ----------------------------------------------------------- > > (Updated Sept. 4, 2014, 11:25 a.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 422582 > /branches/12/include/asterisk/channel.h 422582 > /branches/12/apps/app_stack.c 422582 > /branches/12/apps/app_macro.c 422582 > > 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
