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

[[e-mail] (Patrice Calhoun)]

>Patrice Calhoun wrote:
>> 
>> 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.
>
>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.

ok, but what is a client sends a timeout of infinity, and the server's policy
does not allow it to maintain soft state that long for a single session?

PatC
>
>-Jonathan R.
>
>
>-- 
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: [phone]                         Rm. 4C-526
>EMAIL: [e-mail]
>URL: http://www.cs.columbia.edu/~jdrosen