[Asterisk-code-review] main/cdr: Fixed cdr start overwriting (asterisk[master])

sungtae kim asteriskteam at digium.com
Thu Dec 6 06:31:34 CST 2018


sungtae kim has posted comments on this change. ( https://gerrit.asterisk.org/10747 )

Change subject: main/cdr: Fixed cdr start overwriting
......................................................................


Patch Set 2:

(1 comment)

comment added. :)

https://gerrit.asterisk.org/#/c/10747/2/main/cdr.c
File main/cdr.c:

https://gerrit.asterisk.org/#/c/10747/2/main/cdr.c@1627
PS2, Line 1627: 	if ((!cdr->start.tv_sec) && (!cdr->start.tv_usec)) {
              : 		cdr->start = ast_tvnow();
              : 	}
> I don't think doing this without exploring (and defining) the CDR state machine for the scenario is  […]
Yes, I was thinking about that too. I wasn't happy to changing the code without deep understanding of the CDR. So I choose the smallest code fix as can as possible.

To me, cdr transit to single_state_fn_table() is make sense, but without initiating. But without adding a new flag/parameter, it was not possible. So I just use the existing variables.

And the single_state_fn_table used only when the cdr just generated and all the start time was set to 0. So, it was looks good, that's why I fixed this like this way. :)

Anyways, is there something that I can do, or get more detail what to do? I'm not clear what's next..



-- 
To view, visit https://gerrit.asterisk.org/10747
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I921bc04064b6cff1deb2eea56a94d86489561cdc
Gerrit-Change-Number: 10747
Gerrit-PatchSet: 2
Gerrit-Owner: sungtae kim <pchero21 at gmail.com>
Gerrit-Reviewer: Jenkins2 (1000185)
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: sungtae kim <pchero21 at gmail.com>
Gerrit-Comment-Date: Thu, 06 Dec 2018 12:31:34 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20181206/e6b5f837/attachment.html>


More information about the asterisk-code-review mailing list