[asterisk-bugs] [JIRA] (ASTERISK-23493) SIP Attended Transfer CDR record has differing linkedid than associated CDRs from the entire call - conflicts with spec

[Rusty Newton (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216709#comment-216709 ] 

Rusty Newton edited comment on ASTERISK-23493 at 3/19/14 4:27 PM:
------------------------------------------------------------------

Looking at your CDR and the SIP attended transfer in your debug..

{quote}
There is no trace of CDR between Party A to Party C when bridged.
{quote}

Your sql file includes the CDR:

{noformat}
('2014-03-18', '09:06:52', '"Test" <100>', '100', '119', 'internal', 'SIP/100-00000000', 'SIP/112-00000003', 'Dial', 'SIP/119,20,TtWwM(record^100^1395119184.3)', '11', '11', 'ANSWERED', '', 'BILLING', '', '', '1395119184.3', '1395119184.3', '5');
{noformat}

Which, is the CDR for Party A to Party C (SIP/100 to SIP/112) , look at the *channel* and *dstchannel* fields, not the *src* and *dst* fields.

{quote}
Notice linkedid, linkedidl is not identical to the length of the call. 
{quote}
I'm assuming you meant *for* the length of the call, since there is a total of four CDR records in your sql file and one of them has a different *linkedid* than the rest.

The CDR record (below) with the different linkedid appears to be the record for the call from Party B to Party C. That does appear to differ from what is shown in the [CDR spec at this link|https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification#Asterisk12CDRSpecification-SIPAttendedTransfer]

{noformat}
('2014-03-18', '09:06:44', '"Test" <119>', '119', '112', 'internal', 'SIP/119-00000002', 'SIP/112-00000003', 'Dial', 'SIP/112,20,TtWwM(record^119^1395119204.5)', '8', '5', 'ANSWERED', '', 'BILLING', '', '', '1395119204.5', '1395119204.5', '2'),
{noformat}

I get this same behavior in my tests with cdr-csv in Asterisk 12.

I'll ping Matt again as he may know what is going on.


was (Author: rnewton):
Looking at your CDR and the SIP attended transfer in your debug..

{quote}
There is no trace of CDR between Party A to Party C when bridged.
{quote}

Your sql file includes the CDR:

{noformat}
('2014-03-18', '09:06:52', '"Test" <100>', '100', '119', 'internal', 'SIP/100-00000000', 'SIP/112-00000003', 'Dial', 'SIP/119,20,TtWwM(record^100^1395119184.3)', '11', '11', 'ANSWERED', '', 'BILLING', '', '', '1395119184.3', '1395119184.3', '5');
{noformat}

Which, is the CDR for Party A to Party C (SIP/100 to SIP/112) , look at the *channel* and *dstchannel* fields, not the *src* and *dst* fields.

{quote}
Notice linkedid, linkedidl is not identical to the length of the call. 
{quote}
I'm assuming you meant *for* the length of the call, since there is a total of four CDR records in your sql file and one of them has a different *linkedid* than the rest.

The CDR record with the different linkedid appears to be the record for the call from Party B to Party C. That does appear to differ from what is shown in the [CDR spec at this link|https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification#Asterisk12CDRSpecification-SIPAttendedTransfer]

I'll ping Matt again as he may know what is going on.

> SIP Attended Transfer CDR record has differing linkedid than associated CDRs from the entire call - conflicts with spec
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-23493
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23493
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 12.1.1
>            Reporter: c0rnoTa
>            Assignee: Matt Jordan
>         Attachments: CDR.sql, myDebugLog
>
>
> Attended Transfer CDR as specified in Asterisk 12 CDR specification does not work.
>  Party A calls Party B
>  Party B calls Party C and does an Attended transfer from Party A to Party B
>  CDR has old behavior as in Asterisk 1.4/1.8/11. There is no trace of CDR between Party A to Party C when bridged.



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