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

From: "Chris Boulton" <[email-masked]>
Date: Thu, 11 Sep 2003 10:45:21 +0100

<<See comments>>

>-----Original Message-----
>From: Ben Campbell [mailto:[email-masked]]
>Sent: 10 September 2003 16:41
>To: Chris Boulton
>Cc: Miguel A. Garcia; [email-masked]
>Subject: Re: [Simple] Default 1 minute inactivity timer in MSRP
>
>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.

[Chris Boulton] Ben, I might be missing something here so feel free to
SHOUT.  I personally don't see why relays should be a stakeholder in a
predominantly e2e solution.  The only reason for the introduction of
relays was to overcome the case where clients could not connect TCP
sockets.  As it stands, the client currently is responsible for
refreshing + terminating state using BIND requests at a relay unless the
'Exp' header expires.  I don't see anything wrong with allowing the end
client to be responsible, as I proposed.  If an implementer wishes to
restrict a MAX time that a state can be alive at a relay, then it could
introduce a local policy to terminate once the threshold is reached THEN
respond with a 481 response. 

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Sep 2003 08:55:01 -0500

Chris Boulton wrote:

> sockets.  

Obviously, the relay is not a stakeholder in an e2e case, where it does 
not exist :-)

But any existing relay is going to consume resources for each open 
session. This includes TCP connections, space in a state table, etc. 
This gives it a definite interest in managing session lifetimes. 
Considering that a relay is probably handling many more sessions than 
any given endpoint, one can argue that it has an even greater interest.

As it stands, the client currently is responsible for
> respond with a 481 response. 

Keep in mind, in the current draft version, we no longer have a concept 
of refreshing state using BIND requests.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Sep 2003 08:55:01 -0500