RE: FLUTE, ACL and timestamps and wall clocks
| Newsgroups | gmane.ietf.rmt |
|---|---|
| Message-ID | <[email protected]> |
>such that (e.g.) RAP time stamped media can be cross-checked
^^^
RTP not RAP - though rap over RTP might be to someone's taste :)
>-----Original Message-----
>From: [email protected] [mailto:[email protected]]
>Sent: 17 August, 2005 16:22
>To: [email protected]
>Subject: [Rmt] FLUTE, ACL and timestamps and wall clocks
>
>As everyone knows, we have an optional 32-bit "Sender Current
>Time" to use with ALC and LCT. It's expressed in milliseconds
>since the start of the session - i.e. the sender chooses when
>to set it to zero and no packet gets labelled with a negative
>value. There is a wraparound at
>49.71 days which we assume implementers understand they have
>to deal with. This time is totally in-band for a session and
>has no baring on any other clock (other than the length of a
>second being equal) without additional specification.
>
>For example, one might specify that the sender must set the
>SCT=0 at the advertised session start time (e.g. from an SDP
>start time), and that the sender must be able to synchronise
>itself with a common clock (i.e.
>so that the abstract entity which set the time in the
>advert/SDP is synchronised with this), and one might say that
>a +/-1 second tolerance is allowed (or something reasonable
>for the deployment in question).
>These are the kind of sensible sets a mobile broadcast system
>might implement.
>
>However, another alternative is to provide a time stamp
>relative to absolute (wallclock) time <and then make all the
>same requirements about synchronising servers and other
>abstract entities>.
>
>So the point is: What about an optional NTP wall clock time
>stamp header extension? Not only does this give a common
>reference against (e.g.) SDP, it also does for media payout -
>such that (e.g.) RAP time stamped media can be cross-checked
>with FLUTE-media and the client can do "something great" (like
>play out, caching and storage) in a synchronised way.
>
>I'm thinking about an I-D on such an extension header so I
>want arguments as to why this is a bad idea (as I don't see
>any yet) and maybe why a 32-bit millisecond SCT was more
>interesting than a middle or most significant 32-of-64 bit NTP
>timestamp.
>
>
>Cheers, Rod.
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt
>