Subject: Re: [rtcweb] Minutes review

From: Justin Uberti <[email-masked]>
Date: Thu, 15 Oct 2015 13:57:41 -0700

I went back and reviewed the recording on this today. The highlights that I
captured.

- regarding use of session-multiplexed FEC (as opposed to
ssrc-multiplexed), Jonathan mentioned that my proposal of 'must-reject' for
BUNDLE is probably inappropriate, and instead should say something along
the lines of 'must reject if it does not support session-multiplexed FEC'.
- regarding use of protection of multiple streams with a single FEC stream,
Bernard noted that for 1.0, leaving this out of scope is fine (i.e. not in
rtcweb-fec), but work should still proceed to figure out a mechanism for
this in the actual flexfec doc.
- Mo Zanaty thought it might be possible to do something in the 1.0
timeframe to allow for multiple stream protection, such as having a single
FEC flow in a m= line that protected multiple primary flows, and offered to
write up a proposal.

If anyone else has any notes on this, please let me know.

I plan to do an update on this document to address the first two points. We
can discuss the third at IETF 94 if a proposal materializes.

On Thu, Aug 6, 2015 at 4:20 PM, Ted Hardie <[email-masked]> wrote:

> Howdy,
>
> The draft minutes are available for review here:
>
> https://www.ietf.org/proceedings/93/minutes/minutes-93-rtcweb
>
> There is a section of discussion related to the FEC presentation which did
> not get minuted, and if folks have notes on that, they would be appreciated
> (the audio in the meetecho recording is a valuable resource, but additional
> notes welcome).
>
> thanks,
>
> Ted
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 15 Oct 2015 17:04:49 -0700

The real complication here is how we signal the FEC information, e.g. what
m= section does it get attached to, and what happens if that m= section
happens to disappear later.

My expectation is that we will have to essentially define a way for a m=
section to have no primary stream but only a repair flow, and then that
repair flow can repair any SSRC in the same RTP session using flexfec. If
we are careful, we could do this without exploding unified plan or freaking
out existing WebRTC endpoints.

On Thu, Oct 15, 2015 at 3:36 PM, Mandyam, Giridhar <[email-masked]
> wrote:

> Regarding the 3rd item, I intended
> https://tools.ietf.org/html/draft-mandyam-rtcweb-fecframebundledssrc-00
> to be the starting point for this.  I think we need to resolve whether such
> a proposal would be better handled in the context of FLEX FEC (
> https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-00 ).
> I believe Mo mentioned this possibility after my presentation, but he can
> confirm.
>
>
>
> BTW, it looks like FLEX FEC has expired (but it also looks like
> draft-ietf-rtcweb-fec has expired as well).
>
>
>
> -Giri
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Justin
> Uberti
> *Sent:* Thursday, October 15, 2015 1:58 PM
> *To:* Ted Hardie; Mo Zanaty (mzanaty); Jonathan Lennox; Bernard Aboba
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] Minutes review
>
>
>
> I went back and reviewed the recording on this today. The highlights that
> I captured.
>
>
>
> - regarding use of protection of multiple streams with a single FEC
> stream, Bernard noted that for 1.0, leaving this out of scope is fine (i.e.
> not in rtcweb-fec), but work should still proceed to figure out a mechanism
> for this in the actual flexfec doc.
>
> I plan to do an update on this document to address the first two points.
> We can discuss the third at IETF 94 if a proposal materializes.
>
>
>