Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt

[Roni Even <[e-mail]>]

Hi Magnus,
Read the draft, I liked the analysis on the different multiplexing of RTP
streams (Session, SSRC and payload type).

Some review comments

1. The introduction talks about multistream and simulcast. I noticed that it
only talks about how to define the alternatives in terms of the stream but
is not saying how to understand the semantics of the streams, for example
which camera in Telepresence and in simulcast you assume that all
alternative provide the same view (just resolution change, but can also use
different view of the room). This is fine and is being discussed in CLUE at
the moment and should be out of scope here but it may cause the SDP to be
even larger. 

2. On the SDP syntax it may be better when you have more than one m-line to
have all the descriptions which repeats in all m-line appear st the SDP
session level with local identifier and use the identifier in the m-lines.
Maybe based on grouping.


3. In section 1.1 "Todays SDP signalling support for this is basically the
directionality attribute which indicates an end-point intend to send media
or not.  No indication of how many media streams." My understanding so far
was that the number of PT in the m-line is the maximum number of streams
that can be sent in an RTP session. This  goes also to the discussion on
support of multiple SSRCs. I think that today video conferencing endpoint is
doing a second offer answer to fix the PT it will use based on the first
offer answer exchange. 

4. The above still does not address the multiple SSRC for the same PT and I
already mentioned it in the past that I think that a lot of product today
will not handle it good. I think that this is a rare case today at least in
centralized video conferencing since the MCU (or RTP mixer if exist) will
use its own SSRC to send the mixed/switched media.

5. In section 3.2 second paragraph you talk about the receivers controlling
what the relay will send but this will make the relay something else than
RTP translator.

6. On the bandwidth support. Currently the definition is the b= is a
receiver capability. I am not sure why you need the sender one, you claim
that there is no way to control the actual bw but the receiver can use RTCP
CCM flow control to tell the sender to reduce the rate. As for the syntax,
my preference is for TIAS semantics and not the one you proposed. 

7. In the last sentence of 7.2.1 you say "This enables a simple fallback
solution to exclude a legacy client from all simulcast versions except one,
whichever is most suitable for the application". My view is that currently
when there are several m-lines of the same media type there is no definition
which one to choose if the answerer do not understand the semantics of the
offer and can support only one stream.


Roni Even



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Magnus Westerlund
> Sent: Tuesday, July 05, 2011 1:54 PM
> To: IETF AVTCore WG
> Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-
> multistream-and-simulcast-00.txt
> 
> WG,
> 
> As an individual Bo Burman and I have written this internet draft that
> discusses multistream and simulcast issues and proposes a set of
> extensions to resolve the issues. Feedback is much appreciated.
> 
> Cheers
> 
> Magnus