Subject: RE: [SIP] Registrars and Date

From: [email-masked]
Date: Tue, 10 Oct 2000 16:26:23 +0530

I prefer option 1.
Since the embedded device sending it in this case has no concept of
absolute time, it sends a relative time
to the server, server replies back in relative time.
If an endpoint sends expiry in a format, I feel the server should respect
that format in its response (thouh not
mandatory, this makes interpretation simpler for the person who sent it)

solution 2 does not seem very natural to me - that is, if I say REGISTER
with expiry='13 Dec, 2000', if a server
returns back the calcuated relative time starting today in say seconds, its
correct but some how not natural.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

Jonathan Rosenberg <[email-masked]> on 10/10/2000 01:43:47 PM

To:   "'Eric Tremblay'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>
cc:

Subject:  RE: [SIP] Registrars and Date

Good catch.

Wouldn't life be easier if every device had a GPS receiver with completely
syncrhonized time.... oh well.

ANyway, there are a few possible solutions here:

1. always send a response with a delta-time if the request had an expires
with a delta-time
2. always use relative times in register responses
3. always send Date in the 200 OK response to INVITE

The third solution is what is proposed by Eric. 2 and 3 assume that
registrars have access to the date. I thinks its a reasonable assumption.

The easiest solution for all is probably 2, as it eliminates another
option.
But, I suspect that there are already implementations that always send
absolute times.

Comments?

-Jonathan R.

> -----Original Message-----
> From: Eric Tremblay [mailto:[email-masked]]
> Sent: Wednesday, September 27, 2000 11:14 AM
> To: [email-masked]
> Subject: [SIP] Registrars and Date
>
>
>
> I have a very simple question/request:
>
> Would it be possible to make the Date header mandatory in Registrar
> responses?  This would be required if the registrar sends its
> expires time
> in SIP-date format.
>
> The reason for this are the following:
>
> 1- Some embedded devices don't keep track of the time at all.
> 2- Other that do might be connecting to a NTP/SNTP server to
> acquire the
> notion of time (probably at bootup).  What if the server is down?  The
> device has no knowledge of the time.  This sould not prevent
> the device from
> registering.  If the date header is not included, the device
> cannot know for
> how long the registration is valid, until the time server
> comes back up.
>
> Regards,
>
> EricT
>
> ___________________________________________
> Eric Tremblay      | Mediatrix Telecom Inc.
> Technical Leader   | www.mediatrix.com
>
> [email-masked]
> tel: +1-819-829-8749 x238
> fax: +1-819-829-5100
>
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: [email-masked]
Date: Tue, 10 Oct 2000 16:32:56 +0530

arc> solution 2 does not seem very natural to me - that is, if I say
REGISTER
arc> with expiry='13 Dec, 2000', if a server
arc> returns back the calcuated relative time starting today in say
seconds, its
arc> correct but some how not natural.

On second thought , that depends. If  13th Dec is months away and the
server only supports 1 hr, it may be fine if it
sent back  1 hr in delta time.
What I mean is that unless the server has to modify the expiry time, I see
no reason why it should change the unit in its response,
if the sender himself had sent in SIP-DATE format.

[email-masked] on 10/10/2000 04:26:23 PM

To:   Jonathan Rosenberg <[email-masked]>
cc:   "'Eric Tremblay'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>

 I prefer option 1.

Regds
Arjun

Good catch.

Comments?

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Oct 2000 10:42:44 -0400

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2000 9:20 AM
> To: Jonathan Rosenberg
> Cc: 'Eric Tremblay'; [email-masked]'
> Subject: Re: [SIP] Registrars and Date
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > Good catch.
> > 
> > The easiest solution for all is probably 2, as it 
> eliminates another option.
> I would suggest that servers send Date headers. Everyone does anyways
> (as far as I can tell), it allows really simple end systems 
> that use the
> registrar for a rough notion of time, without reliance on another
> service, and the incremental pain for registrars is zero. We really
> don't want to add to the two big blunders in electrical engineering,
> blinking 12:00 on VCRs and ISDN phones that have to have 
> their time set
> manually...
> 
> Restricting Expires headers just adds yet another error condition. 
> 
> If the end system truly has no notion of time and gets an absolute
> expiration time, it just keeps to the one hour default. If 
> the registrar
> doesn't like this, it just gets what it deserves by saving 
> five lines of
> program code.

Sounds reasonable. Lets go with that.

-Jonathan R.
---