bis will be mandating the use of relative times only, no longer absolute times. It has the synchronization problems that have been pointed out here.
The only issue is whether we can remove absolute times entirely from the spec, or mandate that UA/registrar still be able to process it (but NEVER send them) in order to provide backwards compatibility. That is still being hashed out on the sip list. -Jonathan R. Matt Zito wrote: >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, November 27, 2001 11:52 AM >>To: [EMAIL PROTECTED] >>Subject: [Sip-implementors] Current date and exipres date >> >> >>Take a look to this scenario. >> >>A device implements NTP protocol, so it has a device time >>(current-time). >>The device sends a REGISTER and it receives a 200 OK response in which >>there is the "expires" parameter in "Contact" header but >>there is not the >>"Date" header. >>The device must use his current time to compute the expire time. >>Now suppose there is an error in NTP server or in Sip server date >>so that from the expire date and the current date there are a >>long time. >> >>Example: >>Current date: Mon, 26 Nov 2001 01:01:45 GMT (received from NTP) >>Expires date: Mon, 26 Nov 2003 02:01:45 GMT (received from Sip Server) >> >>What the device has to do? >>which must be the behaviour of the device in this case ? >> >>Is it a correct implementation chek the difference between >>current date >>and expire date and if the difference is larger than one year >>it set the expire >>time at 3600 seconds (default expire time) ? >> >>I did not find any item on rfc. >> >> >> > > I think, in general, any implementation of any protocol has the right to > discard obviously broken information. In this particular case, you could > easily make such a requirement, and I would even set it to lower, like if > its more than a week, roll it back to the default of 3600 seconds. I don't > necessarily know if there should be a note in the RFC about it, though. > > An alternate fix would be to make the expire time value an offset in > seconds, so it returns "Expires date: 5000". This fixes the ntp scenario, > but broken implementation X could still return "45000000" for the offset, > meaning you'd have to set an upper limit on what you will consider a valid > response anyway, so you haven't actually gained that much. > > Thanks, > Matt > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
