Subject: [avtext] RTP Duplication work

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 19 Mar 2013 14:12:44 +0000

As you may already know, there are 3 drafts regarding the RTP duplication
work.

https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/

http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/

http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/

The bottom two (mmusic) drafts will be updated today/tomorrow with some
fixes and clarifications based on the comments received in the mmusic list.

The top (avtext) draft will also be updated right after the mmusic
revisions. And hopefully these revisions will address all the
open/remaining issues. Our goal is to finish all three drafts soon.

In this email, I would like to ask for input for the avtext document.
Since day one, our mail goal has been to develop a solution that addressed
the majority of the use cases that are deployed today. Our requirements
were to support temporal and spatial redundancy for RTP streams. We wanted
both session and ssrc-level grouping for the original and duplicate
streams.
1) We used the a=group attribute when the original and its duplicate RTP
stream(s) were described in separate m lines (and these m lines would only
carry one RTP stream).
2) We used the a=ssrc-group attribute when the original and its duplicate
RTP stream(s) were all part of the same m line (in this case there could
be other non-duplicate RTP streams in the same m line)

At some point, we also considered duplication grouping across m lines that
have multiple RTP streams. However, support for this kind of grouping has
not been clearly defined in mmusic yet, and it looks like it will take a
while before a solution can emerge.

As the authors, we believe that complicating the implementation of the
drafts listed above with something that may never be needed in practice is
a bad design and should not be done. So, we would like to proceed with the
support for only rather simple grouping methods (as described above).

Please respond to this email if you disagree with this change. As there is
another SDO pursuing a similar work, time is of essence here and we would
like to finish this draft as quickly as possible.

Thanks.
-acbegen