diff options
author | Matt Jordan <mjordan@digium.com> | 2015-06-12 14:28:47 -0500 |
---|---|---|
committer | Matt Jordan <mjordan@digium.com> | 2015-06-13 08:47:53 -0500 |
commit | b8bc15286fd4610221e98f53c34ab486f357198e (patch) | |
tree | 768fc70d204f45b50c2160c24a4fa0bb2df06a07 /formats | |
parent | 56d6b52a3feec93995d86783b9aecc1608981723 (diff) |
main/cdr: Copy context/exten on chained CDRs for parallel dials in subroutines
When a parallel dial occurs, a new CDR will be created for each dial
attempt that is made. In most circumstances, the act of creating each
CDR in the chain will include a step that updates the Party A snapshot,
which causes the context/extension of the Party A to be copied onto the
CDR object.
However, when the Party A is in a subroutine, we explicitly do *not*
copy the context/extension onto the CDR. This prevents the Macro or
GoSub routine name from blowing away the context/extension that the
channel was originally executing in. For the original CDR, this is not a
problem: the original CDR already recorded the last known 'good' state
of the channel just prior to it going into the subroutine. However, for
newly generated CDRs in a chain, there is no context/extension set on
them. Since we are in a subroutine, we will never set the Party A's
context/extension on the CDR, and we end up with a CDR with no
destination recorded on it.
This patch updates the creation of a chained CDR such that it copies
over the original CDR's context/extension. This is the last known "good"
state of the CDR, and is a reasonable starting point for the newly
generated CDR. In the case where we are not in a subroutine, subsequent
code will update the location of the CDR from the Party A information;
in the case where we are in a subroutine, the context/extension on the
original CDR is the correct information.
ASTERISK-24443 #close
Change-Id: I6a3ef0d6e458d3b9b30572feaec70f2964f3bc2a
Diffstat (limited to 'formats')
0 files changed, 0 insertions, 0 deletions