Re: [MMUSIC] RTSP timeout issue

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

RÃmi Denis-Courmont skrev:
> Le Wednesday 05 September 2007 14:33:27 Magnus Westerlund, vous avez Ãcrit :
>> 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.
> 
> 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.

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.

> 
>> 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.
> 
> (...)
>> 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.
> 
> 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 ;)

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.

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

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

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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic