CDR not how I was expecting when dialing

[socallmemaybe]

Hi all,

Recently been using Asterisk 18.14.0 having used different versions in the past and I think some behaviour has changed. Either way the CDR when using dial is not outputting the durations and answer times as I would have expected (and even if it is it makes them less obvious to see what is happening with calls in my opinion).

In the following scenario:

exten => s,1,Playback(some_welcome_message) ;takes a few seconds
 same => n,Dial(pjsip/+123@somewhere&pjsip/+456@somewhere) ;no answer
 same => n,Playback(sorry_no_one_available) ;takes a few seconds
 same => n,Hangup(16)

The CDR will yield data like:

|        dstchannel         | lastapp |                  lastdata                   |        start        |       answer        |         end         | duration | billsec | disposition |
+---------------------------+---------+---------------------------------------------+---------------------+---------------------+---------------------+----------+---------+-------------+
| PJSIP/somewhere-00000001  | Dial    | pjsip/+123@somewhere&pjsip/+456@somewhere   | 2022-09-14 08:37:13 | 2022-09-14 08:37:13 | 2022-09-14 08:37:16 |        3 |       3 | NO ANSWER   |
| PJSIP/somewhere-00000002  | Dial    | pjsip/+123@somewhere&pjsip/+456@somewhere   | 2022-09-14 08:37:16 | 2022-09-14 08:37:16 | 2022-09-14 08:37:16 |        0 |       0 | NO ANSWER   |
|                           | Hangup  | 16                                          | 2022-09-14 08:37:16 | 2022-09-14 08:37:16 | 2022-09-14 08:37:19 |        2 |       2 | ANSWERED    |

In the example each dial channel rejects immediately. Problem I am having here are that the answer time, duration and billsec are being set like they are on the main channel rather than the new dialled channels, where the disposition is NO ANSWER. Should duration and billsec be 0, and asnwer time 1970?

Another thing I am seeing is that the following scenario produces only two rows, should there not be three? (Main channel and two sub from dial).

exten => s,1,Dial(pjsip/+123@somewhere&pjsip/+456@somewhere) ;no answer
 same => n,Hangup(16)

|        dstchannel         | lastapp |                  lastdata                   |        start        |       answer        |         end         | duration | billsec | disposition |
+---------------------------+---------+---------------------------------------------+---------------------+---------------------+---------------------+----------+---------+-------------+
| PJSIP/somewhere-00000001  | Dial    | pjsip/+123@somewhere&pjsip/+456@somewhere   | 2022-09-14 12:55:54 | 1970-01-01 00:00:00 | 2022-09-14 12:55:54 |        0 |       0 | NO ANSWER   |
| PJSIP/somewhere-00000002  | Dial    | pjsip/+123@somewhere&pjsip/+456@somewhere   | 2022-09-14 12:55:54 | 1970-01-01 00:00:00 | 2022-09-14 12:55:54 |        0 |       0 | NO ANSWER   |

Am I misunderstanding in these two scenarios and how channels log to the CDR, or has something changed and this is not intended behaviour? To me it feels like the logging is wrong, and each row should represent the final action of each channel.

Thanks in advance!

[socallmemaybe]

Been testing and not confident the CDR system does what I need to do it (and might just be a misunderstanding on my part). The hope was that each channel created, from dial in the above, would not inherit things like answer.

Additionally been trying to set a custom CDR value in a predial routine which has not been successful. Might try out CEL or do custom table inserts per-channel for my specific use case.

[david551]

1970/01/01T00:00:00 is the start of Posix time, (a rounded down time of the creation of Unix).

Playback answers the incoming channel, which is why you get a third line in the first case.

[socallmemaybe]

Hi David, thanks for this. The third line makes sense and I am happy with but just don’t understand rows 1 and 2 in the first example, why its inherited the answer time and durations despite those secondary channel having no answer (both immediately rejecting).

[david551]

There was a big rework of CDRs after I looked at them closely, so I’m afraid I can’t explain your last point.