Subject: RE: "Does anybody really know what time it is?" :-)

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 1 May 2001 08:16:19 -0400

Yes, I think a fixed timestamp is fine.

Yes, you must deal with the other guy's notion of time being 
ahead or behind yours.

When we get to "torture" tests, we should test time issues.

Note that to make sensible event detection work, you
need a nominally correct time increase (that is,
whatever you start with, it needs to go up in approximately
correct increments).

Brian 

> -----Original Message-----
> From: Paul Long [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 6:33 PM
> To: [email-masked]
> Subject: RE: "Does anybody really know what time it is?" :-)
> 
> 
> Brian,
> 
> Can't time be relative, as in RTP?
> 
> 5.1/RFC1889: "The initial value of the timestamp is random..."
> 6.3.1/RFC1889: "A sender that can keep track of elapsed time 
> but has no
> notion of wallclock time may use the elapsed time since 
> joining the session
> instead."
> Moreover, 6.3.1/RFC1889: "A sender that has no notion of wallclock or
> elapsed time may set the NTP timestamp to zero." Woohoo! :-)
> 
> Since it is already unlikely that a received timestamp will 
> _exactly_ match
> the receiving entity's clock at the time it is decoded--it'll 
> be off either
> a few milliseconds, several minutes, or maybe several days if 
> the time was
> simply set wrong--the receiver should probably apply a delta 
> to normalize
> the time (if this is even important at all to the entity). 
> Therefore, why
> can't we use a rule similar to the one in 6.3.1/RFC1889? For 
> example, the
> timestamp in an MG's ServiceChange/Restart command could be
> 20010101T00000000, and all subsequent timestamps reported by 
> the MG will be
> relative to that. Otherwise, how can a lowly consumer device 
> know the time?
> When was the last time you plugged in an analogue telephone 
> that wouldn't
> work until you set the time?
> 
> Hmmm... You know, it looks like we're already covered in this 
> regard. Take a
> look at this passage from 7.2.8/H.248 (emphasis mine): "The optional
> TimeStamp parameter specifies the actual time >>>as kept by 
> the sender<<<.
> It can be used by the responder to determine how its notion of time
> >>>differs<<< from that of its correspondent." So I think my 
> suggestion of
> using an arbitrary beginning timestamp, e.g., 
> 20010101T00000000, completely
> fulfills the requirement that "The TimeStamp parameter shall 
> be sent with a
> registration command..." As a matter of fact, this may have 
> been what you
> meant in your reply by "the MGs notion of time."
> 
> Okay, the timestamp stays in! However, it's interesting to 
> note that we
> weren't encoding a timestamp at the last interop, and none of the MGCs
> complained.
> 
> Paul Long
> ipDialog, Inc.
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 4:40 PM
> To: 'Paul Long'; [email-masked]
> Subject: RE: "Does anybody really know what time it is?" :-)
> 
> 
> The MGC needs to know the MGs notion of time because network 
> time is not
> constant, and things like timestamps for Notify are important.
> 
> Nearly every gateway and phone I've looked at has a time of 
> day clock, YMMV.
> 
> Brian
> 
> > -----Original Message-----
> > From: Paul Long [mailto:[email-masked]]
> > Sent: Monday, April 30, 2001 2:40 PM
> > To: [email-masked]
> > Subject: "Does anybody really know what time it is?" :-)
> >
> >
> > (Sorry about the possibly obscure reference in the Subject
> > line to an old
> > song by the band, Chicago.)
> >
> > I just noticed this requirement, and I have a rather big
> > problem with it.
> > Some MGs will not be maintaining a "wall clock," e.g., there
> > will be no
> > interface for the user to set the time or specify the current time
> > zone--it's just a simple, lightweight telephone for Pete's
> > sake--so how can
> > such an MG satisfy this requirement?
> >
> > 7.2.8: "The TimeStamp parameter shall be sent with a registration
> > command..."
> >
> > Can this requirement be relaxed to a "should?" Otherwise, an
> > MG will have to
> > contact some kind of UTC time server or require the user to
> > configure it
> > with the correct time before it can be used, neither of which
> > are reasonable
> > solutions, IMO.
> >
> > Paul Long
> > ipDialog, Inc.
> >
>

---

From: "Paul Long" <[email-masked]>
Date: Tue, 1 May 2001 11:14:33 -0500

Brian,

Right, I agree, the timestamps from a sender must be internal consistent.
For an MG, they must be correct relative to the first timestamp in the
registration request; for an MGC, the registration reply. They represent the
sender's own _notion_ of time, as per the standard, and not necessarilly
absolute time.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, May 01, 2001 7:16 AM
To: 'Paul Long'; [email-masked]
Subject: RE: "Does anybody really know what time it is?" :-)

Brian