Subject: RE: [Simple] Default 1 minute inactivity timer in MSRP

From: "Chris Boulton" <[email-masked]>
Date: Wed, 10 Sep 2003 16:11:30 +0100

<<see comments in-line>>

>
>So, this brings up a couple of questions for the list in general:
>
>1) Do others agree with Miguel that we should make the inactivity
>timeout negotiable?

[Chris Boulton] I must admit that I do have reservations regarding a one
minute session timer.  Yes, this may only produce a minimal amount of
extra chargeable bytes BUT it does indicate a slight deficiency in the
solution.   

>
>2) If not, can anyone suggest a better way to choose the standard
value?

[Chris Boulton] As mentioned earlier, negotiation maybe increase
complexity BUT I will throw this into the pot as a potential solution.
On receiving the 200 OK to the SIP INVITE the initiator of the session
will send a SIP ACK - It will also send an MSRP SEND which contains a
new header 'sess-timer' (*Note - it can use this header at any time
during the session).  This new header has a default value so that if
this method is not used, the default will apply (e.g. 1 minute).  On
receiving the SEND (whether it be at the start of the session or mid
session), the receiving MSRP client can either respond positively to the
MSRP SEND request, indicating that it accepts the timer OR it rejects
with a new MSRP error response code.  The new response code will
indicate the range of seconds that the client is willing to accept (max
+ min values in a header).  If the initiator does not like this range it
terminates the session, sending a SIP BYE ELSE it retransmits the send
request with an alternative value in the 'ses-timer' header which falls
into the range.  There probably should be a limit on the number of times
the client retries to avoid DOS attacks.  

>Thanks!
>
>Ben.
>
>
>
>
>_______________________________________________
>Simple mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Sep 2003 10:40:46 -0500

This appears to be an e2e negotiation that would work fine if the 
endpoints are the only stakeholders. However, I think that any relays 
would want a say in this as well. In order to do that, we would need to 
negotiate someting in the BIND request. That value could be sent to the 
visitor in the sdp, or as the return code from the visit request.

It gets more complicated if you have 2 relays, that _each_ want to 
select a value. That could work something like the following:

1) Host proposes a value in a BIND request.
2) Hosting relay selects a value less than or equal to the proposed value.
3) (optional) Host communicates value to visitor in SDP
4) Visitor proposes a value in the VISIT request.  (If we used step 3, 
we might say this must be equal or less than the value in the sdp)
5) Visiting relay forwards request to hosting relay. It MAY reduce the 
value if it chooses. (I expect objections to having the relay modify the 
request. I admit it makes me nervous.)
6) Hosting relay puts final value in VISIT response. Visiting relay and 
visiting endpoint set timers based on this value.

It was after we had worked through an example similar to this that the 
people at the interim meeting chose to punt on making this negotiable.

I personally have no strong opinion on the matter, and was working based 
on group consensus. If that consensus is not real, I am happy to change 
it--but I think we need substantial evidence of that before we change 
things at this point.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Sep 2003 10:40:46 -0500