| Summary: | ASTERISK-23164: CDRs: mid-call/pre-dial handlers perturb context/exten/app/data fields during Dial | ||||
| Reporter: | Matt Jordan (mjordan) | Labels: | |||
| Date Opened: | 2014-01-20 09:30:33.000-0600 | Date Closed: | 2014-01-31 17:41:13.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | CDR/General | ||
| Versions: | 12.0.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ||||
| Description: | Currently, CDRs are tracked by the channel snapshots received over Stasis. This includes the last known application/data/context/extension for that channel. In scenarios where a channel uses the Dial application to dial another channel, this works fine: the last known snapshot recorded for that CDR is the Dial application (and its corresponding location in the dialplan).
However, this doesn't work when a mid-call subroutine is executed on the channel. If the calling channel bounces out of the Dial application and executes a macro or subroutine, this will change the CDR record: the channel snapshots will update the CDR with the last known context/extension/application/data in the subroutine, as opposed to the Dial application. This ends up creating some rather odd CDR entries that don't convey their intent. Luckily, there is already code in the CDR engine to lock the application of a CDR to a particular value. This is done for Parking (which is strange and odd, and had similar problems). This logic will have to be extended to CDRs in the Dial state, and include the context/extension of the Party A channel. | ||||
| Comments: | By: Matt Jordan (mjordan) 2014-01-25 23:17:30.273-0600 Up for review at https://reviewboard.asterisk.org/r/3154/ | ||||