Subject: Re: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!!

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 03:29:09 -0500

Well, if you say there is a real problem I don't want to strand people.

I suppose we can attempt to completely deprecate it once we go to draft.

So, we will go for the fallback, which is:

1. MUST only send delta times
2. MUST be prepared to handle absolute anyway, to handle older rfc2543, 
but DONT take that as an excuse to continue using absolute times in bis 
compliant systems, since its gonna get booted in draft....

-Jonathan R.

Shail Bhatnagar wrote:

> Jonathan Rosenberg wrote:
> 
>>Let me summarize the results so far.
>>
>>Scott Orton, Vijay Gurbani, Kiranai Pavoori, Brian Stucker all
>>
> indicated
> 
>>it was fine to deprecate absolute times (option A).
>>
>>Brett Tate says they have deployments with registrars that return
>>absolute times, but it would be OK to proceed with option A anway; I
>>assume this means that the registrars would need to be revved as soon
>>
> as
> 
>>any of the handsets became bis compliant (since they wouldn't be able
>>
> to
> 
>>handle the absolute tiems). Note that the opposite is true, you don't
>>need to rev the handsets if you upgrade the registrar.
>>
>>Shail indicated that their registrar uses absolute times. Shail - can
>>
> we
> 
>>get more details here? Would there be issues in existing deployments
>>that would be seriously affected by this change? I'd really like to do
>>option A, since otherwise you need to carry around the code for
>>
> absolute
> 
>>time processing anyway.
>>
> 
> Jonathan, Our proxy/registrar generates 200 response of the form 
> 
> SIP/2.0 200 OK
> Contact: <sip:contact1>;expires=gmt stamp
> Contact: <sip:contact2>;expires=gmt stamp
> This is more of an issue for the clients being used
> by existing deployments. If customer X, using our
> registrar, changes their client and the client cannot
> understand this 200 response, there maybe issues.
> This gmt time stamp in 200 responses will probably
> not be fixed for next few months in our proxy. 
> 
> Charles/Sean you want to add something ??
> 
> Thanks,
> Shail
> 
> 
> 
> 
>>Any others?
>>
>>-Jonathan R.
>>
>>Brian Stucker wrote:
>>
>>
>>>Propsal A is the way to go. Do away with absolute times, they cause
>>>
> problems and they're of no real use because all times are relative to
> the current clock at the processing node anyhow.
> 
>>>Brian
>>>
>>>-----Original Message-----
>>>From: Orton, Scott [NGC:B633:EXCH]
>>>Sent: Tuesday, December 11, 2001 3:46 PM
>>>To: 'Kiranmai Pavoori'; jdrosen; vkg
>>>Cc: sip
>>>Subject: RE: [Sip] Open Issue #178: Deprecate absolute times
>>>
> absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!!
> 
>>>
>>>
>>>Proposal A is fine.
>>>
>>>Scott
>>>Nortel Networks
>>>
>>>-----Original Message-----
>>>From: Kiranmai Pavoori [
>>>
> mailto:[email-masked]]
> 
>>>Sent: Tuesday, December 11, 2001 9:48 AM
>>>To: jdrosen; vkg
>>>Cc: sip
>>>Subject: Re: [Sip] Open Issue #178: Deprecate absolute times
>>>
> absolutely:
> 
>>>SPEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!!
>>>
>>>
>>>Proposal A resolves lots of synchronization problems seen in my
>>>
> work..
> 
>>>
>>>
>>>
>>>>>>Vijay Gurbani <[email-masked]> 12/10 12:44 PM >>>
>>>>>>
>>>Jonathan Rosenberg wrote:
>>>
>>>
>>>>Issue:
>>>>
>>>>The Expires header and expires param in the Contact header allow for
>>>>absolute times expressed in GMT. The problem with using absolute
>>>>
> times in
> 
>>>>the messages is that they require clock synchronization between the
>>>>
> two
> 
>>>>elements.
>>>>
>>>>
>>>[...]
>>>
>>>
>>>>PROPOSAL A:
>>>>  * Remove absolute times entirely from the specification
>>>>
>>>>PROPOSAL B:
>>>>  * Elements MUST NOT send messages with absolute times in Expires
>>>>
> or
> 
>>>>;expires, but they MUST be prepared to receive requests with
>>>>
> absolute
> 
>>>>times in those headers, for backwards compatibility
>>>>
>>>>If we can do A, we should. So, speak up NOW if you use absolute
>>>>
> times!!!
> 
>>>Proposal A is fine.  Our registrar sends out delta time in responses
>>>
> to
> 
>>>Register requests, for instance.
>>>
>>>Thanks,
>>>
>>>- vijay
>>>
>>>
>>--
>>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
>>Chief Scientist                         First Floor
>>dynamicsoft                             East Hanover, NJ 07936
>>[email-masked]                 FAX: (973) 952-5050
>>http://www.jdrosen.net                  PH:  (973) 952-5000
>>http://www.dynamicsoft.com
>>
>>_______________________________________________
>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use [email-masked] for questions on current sip
>>Use [email-masked] for new developments on the application of sip
>>
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Charles Eckel <[email-masked]>
Date: Sun, 06 Jan 2002 17:37:47 -0800

Jonathan,

We can/will make the necessary modifications to comply with the
depreciation, so you have the green light from Cisco.
Shail, thanks for clarifying the issue and the necessary fix.

Cheers
-- 
Charles Eckel
Software Engineer
Voice Technology Group, Cisco Systems
http://www.cisco.com

Shail Bhatnagar wrote:
> > Scott Orton, Vijay Gurbani, Kiranai Pavoori, Brian Stucker all indicated
> > assume this means that the registrars would need to be revved as soon as
> > any of the handsets became bis compliant (since they wouldn't be able to
> > Shail indicated that their registrar uses absolute times. Shail - can we
> > option A, since otherwise you need to carry around the code for absolute
> > time processing anyway.
> 
> > > Propsal A is the way to go. Do away with absolute times, they cause problems and they're of no real use because all times are relative to the current clock at the processing node anyhow.
> > >
> > > Brian
> > >
> > > Subject: RE: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!!
> > >
> > >
> > >
> > > Proposal A is fine.
> > >
> > > Scott
> > > Nortel Networks
> > >
> > > From: Kiranmai Pavoori [ mailto:[email-masked]]
> > > Subject: Re: [Sip] Open Issue #178: Deprecate absolute times absolutely:
> > > Proposal A resolves lots of synchronization problems seen in my work..
> > >
> > >
> > >
> > >
> > >>absolute times expressed in GMT. The problem with using absolute times in
> > >>the messages is that they require clock synchronization between the two
> > >>elements.
> > >>
> > > [...]
> > >
> > >>PROPOSAL A:
> > >>   * Elements MUST NOT send messages with absolute times in Expires or
> > >>;expires, but they MUST be prepared to receive requests with absolute
> > >>If we can do A, we should. So, speak up NOW if you use absolute times!!!
> > >>
> > >
> > > Proposal A is fine.  Our registrar sends out delta time in responses to

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jan 2002 14:12:27 -0500

OK, great to hear!

Well then, it looks like we can indeed go full steam ahead, and totally 
remove absolute times in Expires from the specification.

I would like to do that as well for Retry-After, I assume if people are 
OK with this for Expires it will be OK for Retry-After.

Most likely I will also add text that says "if you see a malformed value 
in the expires header or param (which an absolute time would be), assume 
a value of 3600. This assures that things would still even work, albeit 
not quite right, if someone still had an old registrar around that was 
sending absolute times.

Thanks,
Jonathan R.

---

From: Charles Eckel <[email-masked]>
Date: Thu, 10 Jan 2002 13:25:07 -0800

Maybe its a small point, but if fallback values are going to be
specified, it may be of value to state a context sensitive fallback
value. For a contact, I agree that 3600 is reasonable; however, for an
INVITE a value of 180 seems more appropriate. I thought these were the
default to assume in case of the absence of any Expires header for the
respective cases, but I don't see any mention of such defaults in
bis-05. Just my 2 cents.

Cheers

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jan 2002 15:38:07 -0500

> respective cases, but I don't see any mention of such defaults in

There is no need for defaults for INVITE, since the UAC will CANCEL in 
any case. The only place where we want this default defined is 
registrations.

-Jonathan R.

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 17 Jan 2002 16:05:13 -0500

> There is no need for defaults for INVITE, 
> since the UAC will CANCEL in any case. 
> The only place where we want this default 
> defined is registrations.

Not true.  If the UAS does not apply some 
local or received expiration value, the 
phone would ring indefinitely when the
CANCEL is not received because of UAC or
network outage.  If UAC supports INFO or
100rel, they could be used by UAS to 
ensure the UAC still considers the dialogue 
active.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jan 2002 18:41:13 -0500

> ensure the UAC still considers the dialogue 

it doesn't seem that important to support a case which requires:

(1) the uas to not be bis-compliant,
(2) expires is needed in INVITE
(3) uas doesn't apply local policy to stop ringing after some time (very 
unlikely, I think)
(4) there is a network outage.

The odds of simultaneous occurence of all of these four seem very low to me.

-Jonathan R.

---

From: [email-masked]
Date: Fri, 18 Jan 2002 10:44:27 -0600

> The odds of simultaneous occurence of all of these four seem 

You missed a fifth condition that must also be present:

(5) "ICMP address unreachable" packets are discarded by the
    UAS or other node on the path.

Extremely unlikely, indeed.

/a