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

From: [email-masked] (Patrice Calhoun)
Date: Tue, 16 Feb 1999 14:56:01 -0800

>
>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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Feb 1999 22:40:22 -0500

> timeout period, unless SC1 re-sends another INVITE message.

Thats pretty much whats specified in the Donovan draft. THe difference
is that the timeout doesn't get reflected in the ACK. THis is not
needed, though. The timeout should be echoed in the response, which will
be seen by both servers. I think this works just fine. The only issue
has to do with backwards compatibility - knowing that SC1 will
understand the timer in the response.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen