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

[John Hearty <[e-mail]>]

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

In a separate mail, Steve Donovan wrote:
>
>    I suppose one optimization to the current draft is to give the SIP
>Server the ability to specify an acceptable session time in the situations
>where the client either doesn't specify a duration or when the client
>specifies an unacceptable (too long) duration.

As Steve noted, we could add some information (in the reject?) to the
client indicating what timeout (max/min?) was allowed when a reject
was sent back to a client.  His draft seems to put control of the timer
with the originating client, and this suggested negotiation would work
well in that case.  Something more complex and uglier might be needed
if the terminating client were allowed to change the timer value in
the 200 OK.  I do not see any value added in allowing the terminating
client to modify the timer.

John H.

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