From nobody Tue Sep 8 05:30:39 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37D53A0C51 for ; Tue, 8 Sep 2020 05:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 s77NAsVaN-2R for ; Tue, 8 Sep 2020 05:30:36 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 B863A3A0C4C for ; Tue, 8 Sep 2020 05:30:35 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id u4so18884058ljd.10 for ; Tue, 08 Sep 2020 05:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4ubK8IBfxx9kAg+d9afEVP9xYmjZC/ASy9rA6V+s1G4=; b=EMXLH1x1wdPDImA1c08HQ1oRt/MtzgvBrHMy3oKdQEI/X6Nxzd1tH+oS0OJNKFdhep tKBCwC0y3cct8oDZQ2+hPW9yaGto6YwBAtf5ktmC60hD1ZjgRfC+LiGZQ6UTwd117Yea lnARGm2S6nilGq58XhVrEilwT4yEMtNJVlQhLkSeIc0MlOh9Ou61HGEk/mEPQjbEzSZ/ 6wH3IukMn2qVBsQjYZiDVZkzxODcKNP3MJzzPc1XIyYH0FCpgf2ez390PFgYUN9XqNs0 l2FdHOhIuxcYglBSSsEABOK3mp2A9ETFIv5awsNmGnyW228029VnQjSAfm6XxJfezTWI iCqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4ubK8IBfxx9kAg+d9afEVP9xYmjZC/ASy9rA6V+s1G4=; b=jOe11Do5HFk9ApxKZYQVjjOJ7Ws7WhX4QtrybIlzeHPely82A8dWNG/l9obCD8uJ1v LXyGMgIULon9sk7W6Xt+6k/x2Np7J/5REe6LdK1ba3Sbgt6ygv7rEOHfC1rZhTZ6xDRP TmzlxeDTYBPbAvzx9p2AJXG33P3HcGtvtoXGJcxCeZ1E01mIcSWSWMWrxsoGXoquwn6w Byy7r1KjKC5lC0CJf6gzlOzgso9u8o1kY9hXePrZoTqNAgSPWYEord8p5SXVutmBg3fX 5yr6X6LCiOrq9jdNF11pz/BYqJTC6GRpoOH3/ZWM2Wl0VuYn7BLWNYXySZbehVmF+YO5 cD/g== X-Gm-Message-State: AOAM532P2+wUaxTtw6q9LCxuO+sX1HpROKYQ0ZZX6cxdqfpodHjPqxXM T1QyeJvNve7cMLbKPlKwzqmgjbkebq23JU2V/5JqPJ91tx3z7A== X-Google-Smtp-Source: ABdhPJzWmbUQDLveKUGePVrOPPKM/kQgx3v+sL5ZehZHQXNjXBC96iMjy9WeMFb4Pgk5pO0LOl9yR/6qUmXgO7jLJX0= X-Received: by 2002:a05:651c:1032:: with SMTP id w18mr12990351ljm.238.1599568233393; Tue, 08 Sep 2020 05:30:33 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Tue, 8 Sep 2020 05:30:24 -0700 Message-ID: To: DISPATCH list Content-Type: multipart/alternative; boundary="0000000000005872ad05aecc8043" Archived-At: Subject: Re: [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2020 12:30:38 -0000 --0000000000005872ad05aecc8043 Content-Type: text/plain; charset="UTF-8" Sergio said: "SFRAME content should be treated just as an opaque payload and when used within RTP, there should no additional identification inside the SFRAME payload itself (except the ones strictly needed for encrypting/decrypting)." [BA] But the SFRAME content (RTCEncodedVideoFrame.data) isn't treated as opaque today, correct? I am thinking of the first three octets of data, which cannot be encrypted. Isn't that expected to contain the VP8 Payload Header? "What I think it is missing in the charter is define what will happen if we find that there is any piece missing in RTP to be able to use SFRAME with it. Should we produce them within this group or just write the requirements and liaise with the appropriate ietf group so they are completed there?" [BA] I think we have a decent idea of what kind of RTP info we are talking about. Basically, this is the information used by the SFU in order to decide whether to forward or drop the packet. The info is inserted before data within each RTP packet (e.g. VP8 payload descriptor and/or frame forwarding RTP header extension), correct? If so, this can be handled by a reference within the SFrame specifications. "In no way SFRAME should be required to have knowledge about SSRCS." [BA] I think you mean that we don't want SSRCs to be used to identify the keys. As we saw in PERC this creates backwards compatibility issues in SFUs with respect to SSRC modification. But some "knowledge" of SSRCs is required in the system. An RTP packetizer needs to fill in the SSRC field in the RTP header, and this info will also be available to the depacketizer. Also, the RTCEncodedVideoFrameMetadata includes both SSRCs and CSRCs (see: https://w3c.github.io/webrtc-insertable-streams/) "There are several ways of performing that without imposing any limitations on the SFU. Some of which would require extra specification work, but I would not like to jump directly into the technical proposals while still discussing about the charter." [BA] I agree that this doesn't seem like a Charter issue. It is more about what information the SFU has available to it (e.g. RTP header, RTP header extensions and possibly a portion of the payload). Based on this information, the SFU needs to be able to decide whether to drop or forward an RTP packet or whether to attempt repair. However, from the SFU's point of view, the repair process operates normally, correct? --0000000000005872ad05aecc8043 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sergio said:=C2=A0

=
"SFRAME content should be treated just as an opaque payload and when u=
sed=20
within RTP, there should no additional identification inside the SFRAME=20
payload itself (except the ones strictly needed for encrypting/decrypting).=
"
[BA] But the SFRAME content (RTCEncodedVideoFrame.dat=
a) isn't treated as opaque today, correct? 
I am thinkin=
g of the first three octets of data, which cannot be encrypted. Isn't t=
hat expected to contain the VP8 Payload Header?
"What I=
 think it is missing in the charter is define what will happen if=20
we find that there is any piece missing in RTP to be able to use SFRAME=20
with it. Should we produce them within this group or just write the=20
requirements and liaise with the appropriate ietf group so they are=20
completed there?"
[BA] I think we have a decent idea of=
 what kind of RTP info we are talking about.  Basically, this is the inform=
ation used by the SFU in order to decide whether to forward or drop the pac=
ket.  The info is inserted before data within each RTP packet (e.g. VP8 pay=
load descriptor and/or frame forwarding RTP header extension), correct? 
If so, this can=
 be handled by a reference within the SFrame specifications.
"In no way SFRAME should be required to have knowledge about SS=
RCS."
[BA] I think you mean that we don't want SSRC=
s to be used to identify the keys. As we saw in PERC this creates backwards=
 compatibility issues in SFUs with respect to SSRC modification. But some &=
quot;knowledge" of SSRCs is required in the system. 
=
An RTP packetizer needs to fill in the SSRC field in the RTP header, and th=
is info will also be available to the depacketizer. Also, the RTCEncodedVid=
eoFrameMetadata includes both SSRCs and CSRCs (see: https://w3c.github.io/webrtc-insertab=
le-streams/)
"There are several ways of performing =
that without imposing any=20
limitations on the SFU. Some of which would require extra specification=20
work, but I would not like to jump directly into the technical proposals=20
while still discussing about the charter."

[BA] I agree that this doesn't seem like a Charter issue. It is more ab=
out what information the SFU has available to it (e.g. RTP header, RTP head=
er extensions and possibly a portion of the payload). Based on this informa=
tion, the SFU needs to be able to decide whether to drop or forward an RTP =
packet or whether to attempt repair. However, from the SFU's point of v=
iew, the repair process operates normally, correct?=20
--0000000000005872ad05aecc8043--