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

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Jan 2002 17:33:02 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2002 3:59 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [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)
> > 
> > 
> > 
> > 
> > Robert Sparks wrote:
> > 
> > 
> > > 
> > > We only need to specify a minimum if use of the protocol 
> > with a smaller
> > > value will cause really
> > > bad things to happen to the network (this is the 
> motivation for the
> > > minimum
> > > values for T1 yes?).
> > > This is different metric than having really bad things happen to
> > > applications running on the
> > > network.
> > 
> > 
> > No, we need to define minimums in order to guarantee 
> > interoperability. 

Interoperability of what? If I want a _mimimum_ to _guarantee_
interoperability with the PSTN (the way AA uses it), I need a 
minimum that is much higher than we collectively think is sane.

> > Relying on "if its wrong, the market pressures will make 
> you crank it 
> > up", is not the right answer.
> >

I think you are caught in the same minimum=recommended=
manditorily deployed value misconception I was caught in. This value
is one that will need to be tuned (although the importance
of tuning goes way down if we can cause timer C to restart
through provisional responses) and the market is exactly
what will tune it up or down. The only point in having 
a minimum is keeping them from tuning it down so far it
causes the protocol itself to break or become a menace to
its environment. 

> >   That could be applied, in theory, to 
> > almost any aspect of the spec (for example, having 
> > max-forwards never be 
> > greater than three, which means a max of three hops. Its 
> good for the 
> > network (less traffic), but bad for apps. I would rather not 
> > field these 
> > customer support questions. It should work.).

So a recommended initial value of max forwards is probably wrong.
For most people, it will be insufficient. For some, it will be
just fine. Are you going to specify a minimum, making me violate
spec to insert a header with a Max-Forwards of 1? I may really
be into avoiding proxies someday.

Further, whatever _recommended_ value you choose is, again, going
to have to be tunable (the 5G folks will come in with a system
that mandates 11 hops per carrier, so intercarrier INVITES will
have to transit at least 22).

> > 
> > Bob has proposed some interesting ways to signal for more time:
> > 
> > 
> > > 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.
> 
> > 
> > > 
> > > 2) Include the "expected time" the UAS will take to answer 
> > the call in
> > > the
> > > 1xx response and the proxies would set their Timer C 
> > accordingly. This
> > > would
> > > still require the UAS to retransmit the 1xx response if the 
> > call was not
> > > answered in time, but the proxies would only have to 
> reset the timer
> > > when
> > > they saw the "expected time" value.
> > 
> > 
> > Well, a malicious UAS could set the value to infinity and 
> > blow out the 
> > state in proxies.
> > 
> > Another approach is the one I had proposed - do nothing. Let 
> > the proxies 
> > discard state, and I think it still works OK. Any comments on that?
> 
> 
> I was hoping Robert Sparks would comment on what you 
> discussed ealier today,
> the points sounded interesting.

As adam pointed out, this doesn't survive proxies that are controlling
access through firewalls.

>
>
>  If the stateless forwarding 
> of responses
> and Routing of ACKs would hold the call up, I'm not clear why 
> Robert and
> Henry are having their calls dropped after a minute, unless 
> it's really a
> PSTN switch they are ultimately interworking with that is 
> dropping the call.

The calls are dropping today because of implementations that don't
allow control over providing an expires header with a long value.
This discussion of timer C combined with proxies ignoring expires
was introducing a new place where the protocol would tank the call if
implemented.

> If the points made are ultimately valid, then this approach 
> would seem the
> best and my vote would change to this, as it would remove a 
> requirement of
> UAS's to retransmit provisionals and proxies to reset timers. 
>  Again, a
> minimum would still need to be chosen here such as the 
> originally proposed
> 32s.
> 
> 
> John Hearty
> Level3
> 
> _______________________________________________
> 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

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 8 Jan 2002 18:20:41 -0500

----- Original Message -----
From: "Robert Sparks" <[email-masked]>
<snip>
> was introducing a new place where the protocol would tank the call if

Even if this was allowed, how does the calling UA know how the far end
behaves?

The called UA knows, so it could do something about it.

cheers,
(-:bob