[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] The fate of session timer?
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