Subject: [clue] comments on draft-lennox-clue-rtp-usage-04

From: "Roni Even" <[email-masked]>
Date: Wed, 6 Jun 2012 22:50:54 +0300

Hi,

After reading the draft I had some comments and question but before I would
like  to understand the whole model you are proposing here.

I understand that what guides you is that all the streams in the conference
may share one SSRC space. Each possible stream will have a unique SSRC and
there each stream can be mapped to one captures. This will be true even if
the RTP streams are sent from the same capture device but they are mapped to
different media captures. I see that this may cause a big number of streams.

I am also wondering if all the participants will get all the media capture
descriptions from all the conference participants since if they do not know
all the captures then they cannot have the capture IDs mapping. 

My other comments:

1.  In section 1 you talk about large number of streams. In section 3 you
mention dozen of streams in multipoint. I assume that the number of RTP
streams depends on the RFC5117 topology.

2.  Section 4 about RTCP requirements for CLUE talks about the RTCP message
distribution but it is based on a specific RFC5117 topology. I think that
looking just at the RTP level for application logic of an MCU is not
covering the options.  MCUs using Topo-video-switch-mcu or more common
topo-rtcp-terminating-MCU use other tools to provide information about the
conference participants like conference event package. These addresses
better the cases where there are multiple participants with multiple
streams.

3.  In section 5 there is a requirement that all media streams within a CLUE
call must have a unique SSRC. I understand that the proposal here is to
require a one to one mapping between an SSRC and Media capture. So if I have
a zoom out capture and a zoom in capture coming from the same capture device
they will have different SSRC. As far as I know zooming the camera does not
create a new source, so current system will not use a different SSRC in this
case.

4.  In section 6 you conclude that CLUE messaging needs to be able to
indicate the RTP session in which a requested capture is intended to be
received. I am not sure why it is different for non CLUE case based on
Magnus RTP session multiplexing. If I understand this section, it says that
CLUE provides a way to describe the content of the stream (main,
presentation) similar to the content attribute but the streams can be
delivered using single or multi RTP sessions, I think this can be described
also in SDP (you may need to associate the content attribute with the SSRC)
and it will be useful also for non CLUE usage so it should be done in SDP.

5.  Section 7 taking about multipoint unbound is based on a topology that is
not specified. I agree that restarting an RTP stream will lead to a new SSRC
but I do not think that changing encoder resource will always cause it since
it depends who handles the RTP layer and not the media encoding.

6.  In section 8 I do not understand the first paragraph. Why should the
sender send more streams than the receiver requested? In the second part it
depends if it involves a new SSRC. This is topology dependent, the MCU may
always send using its SSRC and the switch will be transparent (there will be
an IDR here), the indication of the new source can be done by different
layer. 

7.  In section 9 it looks to me that requirements 1 and 2 say that
everything is allowed. (must not be necessary does not give any requirement)

8.  In section 9 requirement 6 by assign you mean that it is sent in the
stream.

9.  In section 9 I do not understand what is requirement 7 for.

10.In section 9 requirement 9, the sender may be able to do it but the
requirement should be that he first will need to know that the receiver can
handle it. It looks to me that the same stream is sent once for two media
captures, so this is ability to map an RTP stream to multiple media
capturers.

11.In section 9 requirement 10, do you mean before or after RTP SRTP
processing.?

12.Section 10 talk only about two topologies which are RTP yet like I said
above part of the topic here has to do with MCU application level logic and
the other RFC5117 topologies are also optional solutions. I do not agree
with the last paragraph of section 10 since it does described in RFC5117.
Also see my comment on requirement 9.

13.In section 10.1 the receiver need to know in advance which streams he
will get to allocate resource. I think this is true not only to CLUE. If the
receiver selects the capture he will receive then he will know the required
resources. 

14.In section 10.1 propose to map SSRC to capture but if you map capture to
SSRC it will be a table with the size of the maximum number of captures.

15.In 10.2.3.1 first paragraph if the receiver will not see the capture ID
he will continue to display as the wrong capture.

Thanks

Roni