summaryrefslogtreecommitdiff
path: root/CHANGES
diff options
context:
space:
mode:
authorMatt Jordan <mjordan@digium.com>2015-06-12 14:28:47 -0500
committerMatt Jordan <mjordan@digium.com>2015-06-13 08:47:53 -0500
commitb8bc15286fd4610221e98f53c34ab486f357198e (patch)
tree768fc70d204f45b50c2160c24a4fa0bb2df06a07 /CHANGES
parent56d6b52a3feec93995d86783b9aecc1608981723 (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 'CHANGES')
0 files changed, 0 insertions, 0 deletions