Subject: RE: [Sip] Default value for Timer C (was #282)

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 9 Jan 2002 13:47:23 -0500

I'll add my support for the proposal for periodic retransmission of 1xx as
excerpted below.  I can see some uses for that 1xx.  This shouldn't be an
issue once the offer/answer stuff is done, but we'll have to be totally
clear on what goes in the 1xx body and whether changes to SDP are allowed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 4:59 PM
To: [email-masked]; [email-masked]
Cc: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]; [email-masked]
Subject: RE: [Sip] Default value for Timer C (was #282)

Comments inline.  Note that this is not one of the major issues, but has
been getting alot of attention.  We should try to choose a solution quickly.
My vote is below.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2002 2:27 PM
> To: Robert Sparks
> Cc: Hearty, John; [email-masked]'; [email-masked]';
> [email-masked]'
> Subject: Re: [Sip] Default value for Timer C (was #282)
> 
> 
[snip]
> 
> 
> > 1) Modify the FSMs to restart Timer C for every 1xx 
> response and then
> > have
> > the UAS send a 1xx periodically to maintain the transactions in the
> > proxies.
> 
> 
> This one is nice, since it has the effect of requring insertion of 
> traffic to refresh state. This helps make it immmune from DoS 
> attacks, 
> which your second proposal below is.
> 

 This solution currently gets my vote (is this a democracy?).  The problems
prompting some to want the timer to be long would be solved by the user that
needs it to be long, the UAS.  The minimum could then be some small value
such as 32s as originally proposed.

[snip]

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jan 2002 13:26:08 -0500

OK, great.

I think there is consensus on this, which is the following slightly 
amended proposal:

1. If you are a proxy which can act statelessly (ie., you didn't fork,
no tcp, and so on), if you are stateful anyway, you can drop to
stateless at any time without sending a CANCEL or anything else. We
relax whatever constraints are needed for this.

2. If you can't go stateless, there is a minimum timer C of 3m. A
minimum of this size is needed (as opposed to recommended), since
otherwise, the UAS won't know how frequently to send 1xx (see below).

3. If a uas needs an extension on timer C, it sends a 1xx. A proxy
resets timer C on receipt of a 101-199. The UAS will need to send 1xx at
least as frequently as once every 1m, allowing for several 1xx to be lost.

Thanks for everyones cooperation in commenting and working towards a 
solution.

-Jonathan R.

-- 
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