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

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 9 Jan 2002 11:01:29 -0000

> After a private discussion between myself, Jiri, and Robert, we 
> concluded on the following 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.

Good to see that you can only do this if not
fork.  I found a problem with the previous
approach when forking; in the case a late
non-2xx was followed by a 2xx.

But if INVITE, shouldn't there be some additional
requirement that you can't drop to stateless
before you've seen a 1xx?  Otherwise I can
see a request just suddenly disappearing into
the ether....

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

Okay.

> 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 3m.

Yes, and to be paranoidsafe a good few seconds short
of 3min, right?

> This seems to give us everything we need, and its fairly simple.
> 
> Agreement?

Agreement.

 - Jo.

_______________________________________________
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: Wed, 9 Jan 2002 10:38:42 -0500

I like the proposal very much.

more comments below

----- Original Message -----
From: "Jo Hornsby" <[email-masked]>

> see a request just suddenly disappearing into

If we say any value may be used for Timer C unless the proxy has forked,
that should cover it. I don't think we should say "you can drop to stateless
at any time". It should still follow the INVITE client transaction FSM.

Also, there should be some text in Section 16 that talks about what to do
when a client transaction terminates due to Timer B or Timer C expiring  and
under what circumstances you can simply drop the whole "context" without
sending a final response.

> > least as frequently as once every 3m.
<snip>

----- Original Message -----
From: "William Marshall" <[email-masked]>
<snip>
> > For this to work reliably over UDP, the 1xx responses used to extend
> > the timer should be sent reliably using 100-rel.
>
> Since 100rel is optional and may not be supported by the UAC, the
> UAS needs to implement two refresh algorithms....
>   1) with Supported: 100rel, resend the 1xx reliably every 2.5min
>   2) without Supported: 100rel, resend the 1xx every 1min (my
rule-of-thumb
>      for non-reliable keepalives is 1/3 of the timeout interval)
> But, if the UAS knows a final response will come within 3min (like
> a PSTN gateway, for instance) it need do none of this.
>
> This has the benefit of keeping the complexity on the element that is
> doing 1% of the cases, and nothing additional for the 99%.

I agree with Bill that when not using 100rel, the UAS should update every
minute in case there is UDP somewhere along the path.

cheers,
(-:bob