[asterisk-dev] [Code Review] 3962: CDRs: preserve context/extension when executing a Macro or GoSub

Matt Jordan reviewboard at asterisk.org
Thu Sep 4 15:06:35 CDT 2014


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3962/
-----------------------------------------------------------

(Updated Sept. 4, 2014, 3:06 p.m.)


Review request for Asterisk Developers.


Changes
-------

Unsigned ftw.


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 (updated)
-----

  /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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140904/ad88f98e/attachment-0001.html>


More information about the asterisk-dev mailing list