[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] RTSP timeout issue



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

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