Re: [rtcweb] Minutes review

Justin Uberti <juberti@google.com> Fri, 16 October 2015 00:05 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF561A89C7 for <rtcweb@ietfa.amsl.com>; Thu, 15 Oct 2015 17:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd-eYs75jim5 for <rtcweb@ietfa.amsl.com>; Thu, 15 Oct 2015 17:05:11 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D211A89F5 for <rtcweb@ietf.org>; Thu, 15 Oct 2015 17:05:09 -0700 (PDT)
Received: by vkex70 with SMTP id x70so52341803vke.3 for <rtcweb@ietf.org>; Thu, 15 Oct 2015 17:05:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zIvvSNI5ceQrtrM5i8SuTBNanTRxzM4VqBUrfaSW7lg=; b=LIpJgm5DPh7ICqJbiDJ04axUN2u3LsnEJBF+tA6oMsIY5nEZ0bKXC6mQXfkzTbM3ZA lhPvyPUDsARruym0MAfgTs9apqN4HLZqEv5Ili/nR6JG3vB5n63G+fxXBgjEasITw02L 6xfDhL62gVqapxPA58jjSohe/5uiXiUgahGspAqMUMR8O+NG9KMjNrXSgySCCICqyVKb tJEQXANGuWNlE7PnQehqD2Y7DrMWyh2CFQ2xcnhqHppM1dmRhuwkrlPzejSQphQzpavE R09WTkBUZc6BhS3nwof7OPiINXJl12HcuptHnZ2Nf0GpBE0MU48+N35nqCsTaGNEBy6O 6oSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zIvvSNI5ceQrtrM5i8SuTBNanTRxzM4VqBUrfaSW7lg=; b=K0wF5D1AIC1NwU3UhHCwXMZ2Y4r+4/IJ87Qy8F0CejNFgZJGEqnP4210wY3HpKSg3Q +Mk+QZ0LJVXmAoep122hmwwczMYR7tn5a3uNLPuZB7Xq+xH51sSJO3OTjmUm1wHHmLgU FiX4Kt82AXlA40wbj8GPhTJSwUezHR48hShJr1SF+REABqPIqkvRQfbsbt4w0T4DLW+Y taCUwgj1EvbEEhSlgFUXes88BmUgq0Im96eVAkT7C056BRP5o2NAP0AJki9i43qHiI8o haWl5bN50IdZ5FbRGpfaOtngFnKvES/MXZfhJ4S+NAqzLgMyJfZ4T4DQIXVFKXcnAbYP Z15Q==
X-Gm-Message-State: ALoCoQnajaV57D8e6D/Ef9N57KgDVUAqnLV45CdEuh5RYo9eWr1oO6vu2Je3c80nyItyCXpl2XNd
X-Received: by 10.31.5.144 with SMTP id 138mr8108976vkf.62.1444953908723; Thu, 15 Oct 2015 17:05:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.170.201 with HTTP; Thu, 15 Oct 2015 17:04:49 -0700 (PDT)
In-Reply-To: <1ccfb213094a482db2472117f6f1dffe@NASANEXM01C.na.qualcomm.com>
References: <CA+9kkMA7hREh7+doOW5ss8DUGUFQ8Bma+T_Fw5U2m0D_tNevRA@mail.gmail.com> <CAOJ7v-2v85Yts4XX8RmGsC+Y0K-Mq9+jWzTm0g6VyYC5s4Y5MQ@mail.gmail.com> <1ccfb213094a482db2472117f6f1dffe@NASANEXM01C.na.qualcomm.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 15 Oct 2015 17:04:49 -0700
Message-ID: <CAOJ7v-2Bdw5B_vQ67+Z7Hn=KMDgPzeGyZ+2Y_Eg__yTvb=DBUg@mail.gmail.com>
To: "Mandyam, Giridhar" <mandyam@qti.qualcomm.com>
Content-Type: multipart/alternative; boundary="001a1143ef6272a2af05222d8ce5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/rmSVqg7rWmqoYzwEfLCBdm_mSEc>
Cc: Jonathan Lennox <jonathan@vidyo.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Bernard Aboba <Bernard.Aboba@microsoft.com>
Subject: Re: [rtcweb] Minutes review
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 00:05:13 -0000

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 <mandyam@qti.qualcomm.com
> 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:rtcweb-bounces@ietf.org] *On Behalf Of *Justin
> Uberti
> *Sent:* Thursday, October 15, 2015 1:58 PM
> *To:* Ted Hardie; Mo Zanaty (mzanaty); Jonathan Lennox; Bernard Aboba
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] Minutes review
>
>
>
> 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 <ted.ietf@gmail.com> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>