RE: [Sip] The fate of session timer?

[Adam Roach <adam@dynamicsoft.com>]

> 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