[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] The fate of session timer?

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.

Sean Olson wrote:
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: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Adam
Roach
Sent: Monday, November 11, 2002 4:12 PM
To: Jonathan Rosenberg; sip@ietf.org
Subject: RE: [Sip] The fate of session timer?



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 sip-implementors@cs.columbia.edu for questions on current sip Use
sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip