[asterisk-bugs] [JIRA] (ASTERISK-26415) cdr: CDR merged to first call on attended transfer

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-26415:
------------------------------------

    Assignee: Ross Beer  (was: Unassigned)
      Status: Waiting for Feedback  (was: Triage)

I'm not able to reproduce this like you are seeing it.

I think for clarity we'll need you to provide a debug log including the SIP trace so we can see the messaging alongside the Asterisk debug messages where the CDR entries are made.

I'd say, include , warning, error, notice, verbose, debug. With verbose and debug turned up to 5 each.

With "pjsip set logger on" of course. 

Grab a separate log simultaneously *without* the additional DEBUG messages if possible.

> cdr: CDR merged to first call on attended transfer
> --------------------------------------------------
>
>                 Key: ASTERISK-26415
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26415
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/General
>    Affects Versions: 13.11.2, 14.0.1
>         Environment: Fedora 23
>            Reporter: Ross Beer
>            Assignee: Ross Beer
>         Attachments: cdr_example.txt
>
>
> When receiving a call to a handset, then placing the call on hold to perform an attended transfer. The resulting CDR is merged with the original CDR.
> For example:
> A -- > B -- > Hold --> Dial Number --> Transfer Call
> The resulting CDR is a single entry with the original call's information. 
> In my opinion, this should create a second CDR for the second call, containing data relating to that call. This should not be merged with the original call.
> This works fine if the transfer context is used for a blind transfer as it's possible to use the /n in a local channel call which does create two CDRs.
> It is possible to split the two CDRs as this is what happens in previous asterisk releases such as 1.8
> Its worth noting that on an attended transfer, the destination channel is updated, however, the 'dst' or the 'lastdata' column isn't updated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)