Subject: RE: [Sip] The fate of session timer?

From: Adam Roach <[email-masked]>
Date: Mon, 11 Nov 2002 18:11:40 -0600

> So, given this somewhat-marginal value, the complexity seems 
> startingly high. I have begun to wonder whether that is the
> reason for the troubles this specification is having. So, I
> see a few options:
...
> 4. others?

There's another option we might consider: simplify the mechanism
greatly and add it into the baseline on the next go-round.

When we start working on 3261-bis, we can make it a MUST-strength
to do a periodic re-INVITE. If we fix the period in the spec
instead of allowing it to be negotiated, almost all of the
complication goes away. (Of course, it remains to be seen whether
we could reach consensus on a single value that balances network
traffic with timely removal of stale states).

Then, if a proxy along the path doesn't see an re-INVITE in the
specified time period, it can go stateless for the dialog. It
doesn't matter if the failure was due to failure or simply
implementing an earlier version of the spec: at least there's a
way to clear state without limiting the services available to
well-behaved clients.

/a
_______________________________________________
Sip mailing list  https://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: "Sean Olson" <[email-masked]>
Date: Mon, 11 Nov 2002 18:58:58 -0800

The problem is that periodic re-INVITE is not needed in a great number
of 
situations. I would prefer we not make this part of the base
specification.
It does make sense to simplify the negotiation by either removing it or 
choosing reasonable defaults. 

/sean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Roach
Sent: Monday, November 11, 2002 4:12 PM
To: Jonathan Rosenberg; [email-masked]
Subject: RE: [Sip] The fate of session timer?

...
> 4. others?

There's another option we might consider: simplify the mechanism greatly
and add it into the baseline on the next go-round.

When we start working on 3261-bis, we can make it a MUST-strength to do
a periodic re-INVITE. If we fix the period in the spec instead of
allowing it to be negotiated, almost all of the complication goes away.
(Of course, it remains to be seen whether we could reach consensus on a
single value that balances network traffic with timely removal of stale
states).

Then, if a proxy along the path doesn't see an re-INVITE in the
specified time period, it can go stateless for the dialog. It doesn't
matter if the failure was due to failure or simply implementing an
earlier version of the spec: at least there's a way to clear state
without limiting the services available to well-behaved clients.

/a
_______________________________________________
Sip mailing list  https://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: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Nov 2002 22:37:27 -0500

There are also two somewhat separate problems of proxy session state and 
UA session state. Only the former is hard, since the UAs can easily 
determine each other's state at their convenience (and probably have 
other clues), but a proxy can't tell the UAs to show signs of session 
life. Thus, the question is whether call stateful proxies are 
sufficiently common and whether they couldn't use other means (such as 
subscribing to session state) to achieve the same aim in many cases.

One general criteria for such services might be the "value-ubiquity" 
curve. If something is only valuable if most entities implement it and, 
in addition, the entities bearing a good part of the complexity cost 
probably have little direct incentive to do this, the feature becomes 
dubious. Session timer seems to be exactly that type of service.