[AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01

[Magnus Westerlund <[e-mail]>]

Hi,

(Primarily as individual, but the WG home question is as WG chair)

I have reviewed this draft and some comments on it.

1. If this solution proposal is to be taken forward I think it needs to
be discussed in AVTCORE. The reason is that it has several RTP details
that needs to be figured out to make stream duplication issue free in a
general usage. I will take up a few of these issues in the below comments.

2. One aspect this document has is a relation to what is discussed in
draft-westerlund-avtcore-multistream-and-simulcast-00. Stream
duplication both results in a certain form of multi-stream and also has
a similar but slightly different semantics to simulcast in that the
streams are two representations of a single original media source. In
this case they are clones, but not true duplicates due to that RTP
doesn't handle try duplicates well.

3. Another issue that also the authors has identified is the question of
what one do when one has multiple media streams from the same end-point.
And in a general case one can't use the CNAME to separate the sources.
The reason is that two media sources that has a common timing
(synchronization) context do needs to indicate that by having the same
CNAME. Thus there are need for some additional mechanism to ensure that
SSRC carrying RTP media streams that are duplicates of each other do in
fact be labeled explicitly. I also note that a SDP based solution is not
sufficient to resolve this issue. I think we need something in RTP, so
that SSRC collisions can be handled.

4. In addition there is a few questions how this duplication really
should set some RTP fields. Is the duplication only working on Sequence
number level? There seem to be additional questions, for example in the
need to have RTP timestamp considerations between the streams. They need
to point identically into the joint timeline. Otherwise outages, or
receiver taking synch from one and not the other stream can end up with
different synchronizations. Becomes especially interesting to discuss
when the time shifted transmission.

5. The draft also discussed Payload Type differences and have them in
the SDP examples. I don't see how that is appropriate. If the streams
are true encoding duplicates then they should use the same payload type
configuration, and thus a single payload type should be sufficient and
in fact recommended, unless the source encoding truly changes.

6. I think it is worth discussing also the benefits of SSRC multiplexed
versus the session multiplexed. In multicast context there is clear
benefits from a control and congestion perspective to have session
multiplexed versions and these mapped onto different multicast groups
enabling a receiver to choose one or both streams.

7. Thus I think the signalling aspects of this is the minor part.
Although there clearly are some aspects of this needing discussion. For
example clearer offer/answer rules for handling these.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------