Subject: [siprec] Time Sync

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Oct 2012 09:44:08 -0400

We're planning on using siprec in NENA for Next Generation 9-1-1 media recording.  An issue arose in the past few days about how we would time sync related recordings.  This happens in several real world circumstances where there is not one RS that has all of the media streams when you play them back. 

If RTCP is implemented on CS, then the SRC knows the relationship between wall clock and RTP timestamps.  Even if it doesn't have sender reports, it knows when it received the packets and could relate wall clock to it's view of RTP timestamps.

If RTCP is implemented on the RS, the SRS could record absolute time of the RS, and if it knew the delay of the SRC (if it was approximately constant), that is probably good enough.  But we have no text, and no way for the SRC to tell the SRS about what it knows about the CS time.

Brian

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 3 Oct 2012 22:52:07 +0530

Brian,

Could you please clarify whether CS start-time attribute in Sec 6.3.1 of
metadata draft (-07) shall be used to indicate about CS time from SRC to
SRS. The attribute exact text is as follows:

o  Start-time - This optional attribute represents start time of CS
      as seen by SRC

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Wednesday, October 03, 2012 7:14 PM
To: [email-masked]
Subject: [siprec] Time Sync

We're planning on using siprec in NENA for Next Generation 9-1-1 media
recording.  An issue arose in the past few days about how we would time sync
related recordings.  This happens in several real world circumstances where
there is not one RS that has all of the media streams when you play them
back. 

If RTCP is implemented on CS, then the SRC knows the relationship between
wall clock and RTP timestamps.  Even if it doesn't have sender reports, it
knows when it received the packets and could relate wall clock to it's view
of RTP timestamps.

If RTCP is implemented on the RS, the SRS could record absolute time of the
RS, and if it knew the delay of the SRC (if it was approximately constant),
that is probably good enough.  But we have no text, and no way for the SRC
to tell the SRS about what it knows about the CS time.

Brian
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Oct 2012 13:27:07 -0400

This is the signaling time, right, not the RTP time?

Start and End time value are derivable from Date header(if present in
   SIP message) in RS.  In cases where Date header is not present,
   Start/End time are derivable from the time at which SRS receives the
   notification of SIP message to setup RS / disconnect RS.

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 3 Oct 2012 23:35:09 +0530

Brian,

As you expect, start-time is not RTP time and it is CS signaling start time.
In case of SRC acts as RTP endpoint towards RS, SRC will override CS RTP
timestamp while passing towards RS. In case the requirement is to convey CS
RTP timestamp in RS RTP packets, then it is a new open item. 

Currently from SRC to SRS, the following timestamps are forwarded as part of
metadata to understand the signaling timing of the session:

1) Start-time - CS start-time for a session
2) Stop-time - CS stop-time for a session
3) Associate-time - RS is associated with CS
4) Disassociate-time - RS is disassociated with CS 

Thanks
Partha

PS: RS date header or the first message of RS is not required to be CS
start-time as RS may start during CS mid-session.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Oct 2012 14:19:38 -0400

I'm not sure what we need, because I'm not sure what the actual differences are between the items.

I know there is quite a bit of difference between the RTP and the signaling, so I know we need something that gets us wall time of the RTP.  It may be that if the RS has RTCP and there is negligible delay in the SRC between when it gets a packet on the CS and sends one on the RS, then just recording based on sender reports of RTCP on the RS may be okay.  However, if there is substantial delay, or especially if there is variable substantial delay, this may not be satisfactory.

Brian

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 18 Oct 2012 16:27:03 +0000

Hello Brian,

Please see inline for some comments on this question.

> On 03/10/12 7:14 PM, "Brian Rosen" <[email-masked]> wrote:

>recording.  An issue arose in the past few days about how we would time
>sync related recordings.  This happens in several real world
>circumstances where there is not one RS that has all of the media streams
>when you play them back.

1) When you say related recordings, how are the recording related ? Are
all these recording part of same CS but having multiple Recording Sessions
(RS) from the same SRC ?
Or  2) are they different CS's from the same SRC stitched together as part
of same CS-group ?
Or 3) Is it some other scenario ?

IOW I believe SRC would definitely have knowledge that these Recording
Sessions are related and must have conveyed the same in the metadata
either by having same session_id in case it is like (1) or cs-group Unique
ID in case of (2). 

Apart from conveying this at this level in the metadata we don't have any
thing at stream level.

In general I would be interested in hearing of any feedback from your
implementation if the current metadata is not sufficient for the
use-case/scenario you have. Please let us know.

>wall clock and RTP timestamps.  Even if it doesn't have sender reports,
>it knows when it received the packets and could relate wall clock to it's
>view of RTP timestamps.

In case RTCP is present on the CS, SRC can definitely learn wall clock
time of CS RTP streams. Now depending on the RTP model at the SRC the RTCP
reports may be sent as is or re-generated.  The protocol document has some
text on the same.

Ram

>
>If RTCP is implemented on the RS, the SRS could record absolute time of
>the RS, and if it knew the delay of the SRC (if it was approximately
>constant), that is probably good enough.  But we have no text, and no way
>for the SRC to tell the SRS about what it knows about the CS time.
>
>Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 19 Oct 2012 07:35:46 +0200

See inline

> Or 3) Is it some other scenario ?
Two examples: There is an ongoing incident, with media recorded.  Then another incident that is related to, but separate from the first.  On playback, you need a time synced version of both.  The other is more common - you continuously record a radio channel because there is no practical way to identify specific radio transmissions for a specific incident.  You then record, say a 9-1-1 call which has a caller on the line when the responder arrives.  You need to play back the radio channel and the 9-1-1 call simultaneously.

> use-case/scenario you have. Please let us know.
In the first case, we can relate them, but when the incidents start, we don't know they are related.  After a while, we figure out that they are related.  Then we can change the metadata.  However, the time sync has to exist for the entirety of the calls.

In the second, there is no practical way to have common metadata.