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

From: Nurit Shenhar <[email-masked]>
Date: Tue, 1 May 2001 15:36:34 +0200

Hi

We had a discussion about the time issue at the second half of January 2001.
(see subject: TimeStamp in registration replies). In this discussion we said
that the TimeStamp should be added to the ServiceChangeReply, and can be
used to set the MG clock according to the MGC clock. Was anything done about
it?

Nurit

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

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: "Kevin Boyle" <[email-masked]>
Date: Tue, 01 May 2001 11:07:04 -0400

All,

We may want to be fairly careful here about monkeying with the time in the MG.
Caller ID (or any display feature that includes the time, for that matter) will
be dependant on knowing the time difference between the MGC and the MG.  Since
there is no requirement that the MG and the MGC be in the same time zone, the
MGC will need to know what the differential between itself and the MG is, in
order to deliver the local time of the set with the display payload.

One could provision the differential into the the MGC, or one could calculate
the differential based upon the timestamp sent from the MG upon registration.
Since registration already requires a timestamp, this is a way to determine the
differential without adding provisioning requirements upon the MGC.

Kevin

---

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

Nurit,

The timestamp is already required in the ServiceChange request _and_
response. I left out the last three words of this sentence in my previous
post.

7.2.8/H.248: "The TimeStamp parameter shall be sent with a registration
command and its response."

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Nurit Shenhar
Sent: Tuesday, May 01, 2001 8:37 AM
To: 'Megaco (E-mail)
Subject: RE: "Does anybody really know what time it is?" :-)

Hi

Nurit

---

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

Kevin,

I just don't want the consumer to have to set the time and time zone on his
or her phone before it can be used. Maybe in v2 we could add an optional
field to ServiceChange that indicates what time zone the sender is in. (This
would most likely just be used by the MG, but I see no reason why the MGC
couldn't encode it, too.) We could still allow the timestamps to be
relative, though, from both the MG and MGC, although the MGC is likely to
encode absolute time. If the MG does not encode the timezone field either
because it has not been set yet or it does not support this feature, the MGC
knows not to display ostensibly local time. The MGC could either display UTC
time or no time at all. How about that?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kevin Boyle
Sent: Tuesday, May 01, 2001 10:07 AM
To: Nurit Shenhar
Cc: 'Megaco (E-mail)
Subject: Re: "Does anybody really know what time it is?" :-)

All,

We may want to be fairly careful here about monkeying with the time in the
MG.
Caller ID (or any display feature that includes the time, for that matter)
will
be dependant on knowing the time difference between the MGC and the MG.
Since
there is no requirement that the MG and the MGC be in the same time zone,
the
MGC will need to know what the differential between itself and the MG is, in
order to deliver the local time of the set with the display payload.

One could provision the differential into the the MGC, or one could
calculate
the differential based upon the timestamp sent from the MG upon
registration.
Since registration already requires a timestamp, this is a way to determine
the
differential without adding provisioning requirements upon the MGC.

Kevin

---

From: "Paul Long" <[email-masked]>
Date: Tue, 1 May 2001 12:27:47 -0500

Nurit,

Hey, it just occurred to me that the MG can't use the MGC timestamp to set
its own clock at least for the just-established association because the MG
has already reported its "time base" in the (required) timestamp it
previously sent to the MGC in its ServiceChange registration request. It
would have to unregister first and then re-register in order to use the new
setting. Maybe that was the intent, though.

You know, the more I think about it, the more convinced I am that there is
no reason to encode absolute time. Not even that it should be optional, or
it would be nice if a sender were able to, etc., but that there is really no
value in absolute time because the receiving entity will always apply a
delta to normalize the senders' time to its own. What does seem to be
needed, though, is some way for a receiver to know what time zone it and the
sender is in. But note that this feature would just be useful and not
essential.

Paul Long
ipDialog, Inc.

-----Original Message-----

Hi

Nurit