Subject: [MMUSIC] RTSP: Server killing the session in ready state depiste keep-alives:

From: Magnus Westerlund <[email-masked]>
Date: Fri, 05 Dec 2008 15:45:44 +0100

In the Pause section the following text it written:

Any server resources are kept, though servers MAY close the session and
free resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message.

I interpret this to mean that the server may unilateral tear down the
session after one session-timeout in ready state, despite the fact that
the client sends keep-alive messages.

I can understand there being a benefit in allowing this for the server
to allow for state clean-up. However, I am a bit worried that the client
get no indication that this will happen. So the question if this should
be clarified and some additional notification should be done towards the
client?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 5 Dec 2008 15:50:33 +0100

Hi,

Shouldn't the server use the REDIRECT semantics of ending a session:
   The lack of a Location header in any REDIRECT request is indicative
   of the server no longer being able to fulfill the current request and
   having no alternatives for the client to continue with its normal
   operation.  It is akin to a server initiated TEARDOWN that applies
   both to sessions as well as the general connection associated with
   that client.

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Sent: Friday, December 05, 2008 3:46 PM
> To: mmusic (E-mail)
> Subject: [MMUSIC] RTSP: Server killing the session in ready state
> depistekeep-alives:
>

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 5 Dec 2008 17:16:23 +0200

> be clarified and some additional notification should be done towards the

I don't really understand the point here.

If the client keeps alive, it probably has a reason for doing so. If server 
routinely kick paused-but-alive clients, client implementations will just 
work around it by re-setting up. We're back to the starting point, only with 
more intricacies.

With my Nokia employee hat *off*:

I'd like to point out that "automatic immediate reconnection" is the one 
single feature request that I see for VLC media player (sometimes for 
RTSP/1.0, sometimes for HTTP). While I think it's a pretty bad idea, it would 
seem that many other implementations do it anyway.

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Dec 2008 16:52:39 +0100

> seem that many other implementations do it anyway.

The question is how one defines this in some other way. As I see it one
should keep sessions that are kept alive even if not active. However the
question is what happens if one are getting resource constrained in this
situation. Does one start to end the longest alive sessions to accept
new ones that actually request media? In that case how far does one take
it, what is the minimum time for keeping the session in this situation,
maybe it is one RTSP session timeout interval.

If one closes down a session then that capacity slot is up for grabs by
anyone. And if one then comes to a situation where all slots are used
one will have to respond to any setup requests with 503.

But in general I would like to change this language to something more
constructive.

If the server is resource constrained and the client has not requested
any media delivery for more than one RTSP session timeout interval the
server may end the session by sending a REDIRECT request. We might also
add something that clarifies why, although I don't know if that helps
the client doing the right thing.

Cheers

Magnus Westerlund