Subject: Re: [MMUSIC] RTSP timeout issue

From: Magnus Westerlund <[email-masked]>
Date: Wed, 05 Sep 2007 13:33:27 +0200

Hi Rémi,

It is clearly the client that selects the mechanism to use. As it is on
his responsibility to ensure that the session is kept alive. The RTSP
signalling has one way to keep it alive. This is necessary as there are
no guarantees that there exist a possibility for doing keep-alives over
the media transport. MPEG transport streams, Single source multicast and
other choices makes it difficult or not possible at all to do keep-alive
over the media plane.

The mandatory support of the RTSP one is implicit through the
implementation of certain methods carrying session IDs. I will need to
check if there needs more clarity here. The support of RTCP keep-alive
is of course depending on the server using RTCP at all. But I think we
should clarify the requirement that server supporting RTCP must refresh
its session timers based on that feedback.

So I think it is impossible to have a single mandate. We will always
have RTSP to fall back, and each individual media transport needs to
decide if keep-alive can be done and then safely enough.

Rémi Denis-Courmont skrev:
 >
> Then of course there is the side issue, of proving that the 
> client "owns" the IP address it receives data on - especially when a 
> proxy is used. I guess nobody wants to require congestion control (-> 
> DCCP) support usage at this point.
> 

Well, congestion control is already mandated. Go look in RTP and you
will find that it points out the need for congestion control. From a
strictly practical point. Any streaming server not using RTCP to monitor
its transmission is stupid as the quality delivered to the client can't
be ensured at all. A reasonable approach is to at least monitor loss
rates on a medium turn and adapt based on that. Sure you will not be
TCP-friendly that way, but you will at least not create total congestion
collapse. I hope that the future will allow for better congestion
control. But the reality for streaming is that in most case you don't
have any serious issues with using congestion control thanks to the
large buffer to smooth variations in.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 5 Sep 2007 15:36:29 +0300

> its session timers based on that feedback.

But then, how does the client know the server will understand RTCP 
keep-alives? One could argue that if the profile is AVP (or AVPF, SAVP, 
SAPVF, etc...), it's got to be the case, but I think it should be explicit.

Otherwise clients end up having to use RTSP always for safety.

> decide if keep-alive can be done and then safely enough.

(...)
> be ensured at all.

Stupid maybe, but it would be insane to mandate that any RTSP server would 
start transrating depending on the client bandwidth. Otherwise, you'd need 
one CPU per client for h264 streams ;)

> A reasonable approach is to at least monitor loss 

That depends. I agree that most users will anyway stop the stream out of 
annoyance if there is noticeable congestion. However, we've had complaints 
from users that some RTSP servers kept streaming when a client lost 
connectivity without shutting down its session cleanly.

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 06 Sep 2007 11:12:18 +0200

> Otherwise clients end up having to use RTSP always for safety.

I think we are in violent agreament. My proposal for this would be that
if a server accepts a SETUP with RTCP ports, it SHALL support RTCP based
RTSP session keep-alive. I will add into the tracker to add this text.

> one CPU per client for h264 streams ;)

Well, now you are silly. There are working solution out there at least
for on-demand content based on switching between pre-encoded version. I
think if you look at most of the major players they have solutions
deployed for this.

> connectivity without shutting down its session cleanly.

That, is clearly a bug. Yet antoher reason for having RTCP and when you
stop getting feedback, you clamp the stream. And then terminate the RTSP
session after the timeout.

I am fully aware that the deployed world is everywhere between the very
unfriendly behavior of simple blasting out the stream as long as the
RTSP session exist and the content doesn't end, and quite advanced
adaptation schemes that almost are TCP-friendly in their congestion
response behavior.

I have added a tracker item for specifying general congestion control
requirments and for the defined media transports in the spec.

Cheers

Magnus Westerlund

---

From: "Jaehwan Kim" <[email-masked]>
Date: Tue, 11 Sep 2007 14:07:22 +0900

> SAPVF, etc...), it's got to be the case, but I think it should be explicit.
[jh] According to 2326, server has the right to choose one of aliveness signal. Therefore, client is recommended to send both, RTCP RR and RTSP OPTIONS(although some dislikes send OPTIONS.) or GET_PARAMETER or something.

>RTSP session keep-alive. I will add into the tracker to add this text.
[jh] yes. So, I tested with many 3GPP players at the beginning: server_port=12000; client_port=2233
The result was that only two vendor's player allowed this.
When I used server_PORT=12000-12001 without RTCP, they started to complain it. Therefore, I think anyway, RTCP is good to have.

> connectivity without shutting down its session cleanly.
 [jh] First, according to RTSP..
---
There is no notion of an RTSP connection; instead, a server maintains
   a session labeled by an identifier. An RTSP session is in no way tied
   to a transport-level connection such as a TCP connection. During an
   RTSP session, an RTSP client may open and close many reliable
   transport connections to the server to issue RTSP requests.
   Alternatively, it may use a connectionless transport protocol such as
   UDP.
---
As for lost connectivity, why don't you send RTSP OPTIONS from server to client periodically, at least just before the timeout period(default is 60seconds)?

Cheers,
Jaehwan

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 11 Sep 2007 09:31:00 +0300

Le Tuesday 11 September 2007 08:07:22 ext Jaehwan Kim, vous avez écrit :
> As for lost connectivity, why don't you send RTSP OPTIONS from server to
> client periodically, at least just before the timeout period(default is
> 60seconds)?

The client is allowed to not maintain a permanent RTSP control connection, so 
the server cannot assume it can send OPTIONS whenever it wants, I think.

-- 
Rémi Denis-Courmont

---

From: "Jaehwan Kim" <[email-masked]>
Date: Tue, 11 Sep 2007 15:57:20 +0900

As long as session is not expired, I think it is possible.
If not, the concept of RTSP protocol sending method from server to client would be wrongly designed.

Cheers,
Jaehwan

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 3:31 PM
To: [email-masked]
Cc: Jaehwan Kim; Magnus Westerlund
Subject: Re: [MMUSIC] RTSP timeout issue

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 11 Sep 2007 11:31:53 +0300

> would be wrongly designed.

And how is the server supposed to send a request to a client that is not
presently connected to it? That's non-sense to me.

-- 
Rémi Denis-Courmont

---

From: "Jaehwan Kim" <[email-masked]>
Date: Tue, 11 Sep 2007 17:49:23 +0900

I read the RFC2326 clause again. You are right.
---
9 Connections

   RTSP requests can be transmitted in several different ways:

     * persistent transport connections used for several
       request-response transactions;
     * one connection per request/response transaction;
     * connectionless mode.

   The type of transport connection is defined by the RTSP URI (Section
   3.2). For the scheme "rtsp", a persistent connection is assumed,
   while the scheme "rtspu" calls for RTSP requests to be sent without
   setting up a connection.

   Unlike HTTP, RTSP allows the media server to send requests to the
   media client. However, this is only supported for persistent
   connections, as the media server otherwise has no reliable way of
   reaching the client. Also, this is the only way that requests from
   media server to client are likely to traverse firewalls.
---

But in case of connectionless mode, if client doesn't disconnect the given TCP session because of connectivity loss, streaming server can not but waiting until the end of RTSP session timeout(default 60 second); and this value could be configurable at SETUP time; default would be much shorter than TCP's.

Frankly speaking, I am not sure how effectively the connectionless mode could be used, given many actual networks which is complicated with Firewall, NAT, and L4.

Cheers,
Jaehwan

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 5:32 PM
To: Jaehwan Kim
Cc: Magnus Westerlund; [email-masked]
Subject: Re: [MMUSIC] RTSP timeout issue

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Sep 2007 16:12:16 +0200

> presently connected to it? That's non-sense to me.

I think the important part of this discussion is:

Yes, RTSP 2.0 needs clear rules for how keep-alive is done. RTSP methods
as default to allow for any transport. For transport or other mechanism
they need to be mandated so that one can trust to not use RTSP methods.

That is what I am proposing to edit into the spec.

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Sep 2007 10:56:45 +0200

> Frankly speaking, I am not sure how effectively the connectionless mode could be used, given many actual networks which is complicated with Firewall, NAT, and L4.

I would like to point out that what we are primarily talking here is
what will go into RTSP 2.0. I agree with that especially for firewalls
or NATs with ALGs dropping the RTSP TCP connection will have
complications in the likely loss of the media transport flows. As I see
the TCP connection not being tightly coupled with the TCP has it
advantages in that it is more failsafe. It is also a requirement for
RTSP proxies to be able to multiplex multiple sessions over the same TCP
connection.

Jaehwan, do you like to see any additional text changes than what I
already proposed in the RTSP 2.0 spec?

Best Regards

Magnus Westerlund