RE: draft-ietf-mmusic-sip-session-timer-00.txt

[[e-mail] (Patrice Calhoun)]

>
>Pat Calhoun responded:
>>> Dean Willis said:
>>>Can we at least get some consensus that it IS a problem?
>>
>> Oh, I agree that there is a problem. I am just not sure that
>> the solution
>> proposed is the best one. I suppose I need to really
>> understand why the INVITE
>> approach cannot work to setup soft-state along the proxy
>> chain. you state that
>> P4 never sees the REGISTER, but I think that the INVITE/ACK
>> is sufficient
>> for the proxies to build state. Am I wrong?
>
>INVITE is quite sufficient for proxies to build state, just not
>sufficient for them to destroy state if the endpoints fail to signal the
>state change.
>
>I'm not sure that the proposed solution is the best one either. Two
>timer mechanisms and two active status determination mechanisms have
>been discussed as alternatives -- now we debate, maybe someday we have a
>consensus?

I am sure that we will get to that one day :). However, I would like to
understand why this would not work.

Here is an example:


    SC1 ------> SS1 --------> SS2 -------> SC2

In the above picture, Sip Client 1 (SC1) sends an invite along to its local
Sip Server (SS1). The server adds some timeout information to the request 
and passes this along to SS2. If SS2 is satisfied with the timeout information
added by SS1, it will leave it be. If SS2 requires a smaller timeout period,
SS2 will modify the timeout value and pass the INVITE to SC2.

SC2 must response with an ACK. This ACK could include the timeout period, and
could be checked by either SIP Server to ensure that it meets its local 
policy. The Sip Servers will assume that the session is destroyed within the
timeout period, unless SC1 re-sends another INVITE message.

That said, how can this not be sufficient if the endpoints fail to signal the
state change?

Thanks,

PatC

>
>--
>Dean
>