Subject: [MMUSIC] RTSP 2.0: RTP/RTCP and RTSP separation issues

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Nov 2007 14:48:00 +0100

The specification talks about the possibility of the RTP sender and the
controlling RTSP server being possible to deploy with minimal
integration. However, adding a number of features such as RTP-Info
synchronization information and RTCP based keep-alive prevents this
separation from being realized.

I see two possible solution for this:

A) Remove the notion that RTP and RTSP can be separated to any higher
degree.

B) Remove the normative demand for actually having the RTSP server
provide the functionalities preventing this. This will result in less
clarity in what information sources to trust. For that to work more
explicit information on which sources can be trusted needs to be included.

I would proposed to go with A.

Feedback appreciated!

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: Ross Finlayson <[email-masked]>
Date: Mon, 19 Nov 2007 08:01:23 -0700

>I would proposed to go with A.

I agree.  The protocol specification needs to describe what is 
actually implemented, and implementable, and avoid random speculation 
about unimplemented 'possibilities'.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Joe Pallas <[email-masked]>
Date: Mon, 19 Nov 2007 10:54:02 -0800

> I would proposed to go with A.

I don't completely understand how the issue around option B is one of  
trust.  The description of RTP-Info implies that the issue is one of  
latency (until RTCP packets are received) and a hint about where a  
discontinuity is in the stream.  it's unfortunate that RTP doesn't  
have a way to express this information in-band; this seems to mean  
that an RTSP client controlling a multicast RTP stream will get  
useful information from the RTSP server that it cannot deliver to the  
RTP clients that require it.

There's also been enough discussion about potential problems using  
RTCP for keep-alives that I would argue against it in any case.

That said, I have no strong objection to option A provided that it  
does not erode the transport-protocol independence of RTSP.  It must  
remain clear that RTSP does not presume or expect that RTP will be  
used for media transport.

joe

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Nov 2007 13:29:27 +0100

See below!

Joe Pallas skrev:
> discontinuity is in the stream.  it's unfortunate that RTP doesn't have
> a way to express this information in-band; this seems to mean that an
> RTSP client controlling a multicast RTP stream will get useful
> information from the RTSP server that it cannot deliver to the RTP
> clients that require it.

Sorry, I wasn't clear on this. The issue exist when you can't guarantee
there existing an interface between the RTP sender and the RTSP server
which is capable of transferring the synchronization information needed
for RTP-Info. In that case the client can't know if it needs to rely on
only RTCP or also can use RTP-Info. Similar issues exist for several
other pieces of information. But is primarily about having multiple
sources and the problem of defining how they are used.

> 
> There's also been enough discussion about potential problems using RTCP
> for keep-alives that I would argue against it in any case.

So you argue that RTCP keep-alive should not be used for RTSP keep-alive
at all? Can we split this into a separate thread and could you be so
kind to provide a summary of these issues. I can't recall them.

> 
> That said, I have no strong objection to option A provided that it does
> not erode the transport-protocol independence of RTSP.  It must remain
> clear that RTSP does not presume or expect that RTP will be used for
> media transport.

Fully agreed, RTSP is not dependent on a particular media transport
mechanism.

Cheers

Magnus Westerlund