callRecord startTime/offset and endTime/duration are redundant fields about voice-metadata-standard

[leop-tcto]

@vitorespindola In turret systems you will sometimes record a multi-channel speaker in ONE recording file. As a result the recording file may have more than one call in it. The 'offset' is necessary to tell you how many seconds into the recording a particular call begins.

You are right the duration is redundant. I can simply be calculated by subtracting the endTime from the startTime of the call record.

To further clarify offset here is an example.

1. You are recording all your speaker calls to one recording file.
2. At 9:00:00AM Jim begins a call on the speaker line A by performing a push-to-talk (PTT). The recording begins, let say file name REC98765.mp4.
3. About 2 seconds later Joe shouts to Jim on a separate speaker line B.
4. About 4 seconds later Joe stops shouting to Jim on speaker line B.
5. About 10 seconds later Jim stops talking on line A.
   The above will generate two call records and one recording files as follows:
   Call Record 1: startTime=9:00:00, endTime=9:00:10, offset=00:00:00, filename=REC98765.mp4
   Call Record 2: startTime=9:00:02, endTime=9:00:04, offset=00:00:02, filename=REC98765.mp4

[vitorespindola]

@leop-tcto In the current draft we have callStartTime in the document root and then startTime and endTime for each callRecord. So if we substract startTime(from Call Record 2) with the callStartTime(global) we will have the same result I think.

Following your example I've tried to create a partial example here:

{
...
"callStartTime": "2019-07-11T09:00:00+00:00",
...
callRecords: [
    {
        // Jim
        "startTime": "2019-07-11T09:00:00+00:00",
        "endTime":  "2019-07-11T09:00:10+00:00",
    },
    {
        // Joe
        "startTime": "2019-07-11T09:00:02+00:00",
        "endTime":  "2019-07-11T09:00:04+00:00"
    }
]
}

Another question is shall we use relative(offset/duration) or absolute(startTime/endTime) here? I prefer to use absolute on all date-time fields in the standard for validation purposes.

[kemmiso]

Vitor - I dont think that works. These would appear as two separate calls. It would be very confusing to base a call start time on when a recording takes place. Maybe this should be recordingstarttime?

[leop-tcto]

@kemmiso I think @vitorespindola mean that the item called callStartTime is really recordingStartTime. If we rename it to that maybe it will help? @vitorespindola is this what you mean?

[kemmiso]

Yep sorry - that was kind of what I was saying/clarifying.

[vitorespindola]

@leop-tcto @kemmiso, yes. callStartTime is the name in the current draft, and I agree that renaming to recordingStartTime will make it clearer.

@leop-tcto do you think this way will work without the offset attribute?

{
...
"recordingStartTime": "2019-07-11T09:00:00+00:00",
...
"callRecords": [
    {
        // Jim
        "startTime": "2019-07-11T09:00:00+00:00",
        "endTime":  "2019-07-11T09:00:10+00:00",
    },
    {
        // Joe
        "startTime": "2019-07-11T09:00:02+00:00",
        "endTime":  "2019-07-11T09:00:04+00:00"
    }
]
}

[leop-tcto]

@vitorespindola I agree that we do not need offset if we have what you propose. Offset could be calculated by subtracting the call record start time from the call recording start time.

[vitorespindola]

@leop-tcto @kemmiso I've created a PR based on our discussion. Please evaluate and comment or approve it.

Please check out the following items:

• callStartTime is renamed to recordingStartTime - This is OK if the initial idea of the callStartTime field(originally timeStampForCallStart from Cloud9) is to store the recording start time. @leop-tcto this is the initial idea of timeStampForCallStart field or it is related to initial call connection?

• It keeps absolute date-time fields(startTime/endTime) instead of the relative ones(offset/duration).

• There are some changes in the description of the fields, please review them.