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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 30 Apr 2001 17:40:06 -0400

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: Mon, 30 Apr 2001 17:32:37 -0500

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?" :-)

Brian