From nobody Thu Oct 6 12:06:06 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6808C129745; Thu, 6 Oct 2016 12:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 5zr5iw9qoqer; Thu, 6 Oct 2016 12:05:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 58BF71293F0; Thu, 6 Oct 2016 12:05:59 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u96J5roe084575 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Oct 2016 14:05:55 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Spencer Dawkins , The IESG References: <147250463644.19013.26103564099771157.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <39635e26-cfeb-dff2-f084-27758dd411b6@nostrum.com> Date: Thu, 6 Oct 2016 14:05:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147250463644.19013.26103564099771157.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-avtext-rid@ietf.org, avtext@ietf.org, avtext-chairs@ietf.org, Jonathan Lennox Subject: Re: [avtext] Spencer Dawkins' No Objection on draft-ietf-avtext-rid-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 19:06:00 -0000 Sorry for the delay in responding here. On 8/29/16 16:03, Spencer Dawkins wrote: > In this text from the Introduction, > > RTP sessions frequently consist of multiple streams, > > would it be possible to add a word or two explaining why this happens? If > it's true that this happens because multiple media types, or codecs, or > ... are in use in the same RTP session, that's the level of detail I'm > thinking about. The most relevant reasons for what we're working on here are simulcast, layered encodings, and redundancy streams, all of which are mentioned in the introduction already. With that in mind, it's not clear to me what you're asking to have added. > In this text: > > At the same time, when redundancy RTP streams are in use, > > could you provide a reference for redundancy RTP streams? I'm guessing > this is using RFC 7198, but that's just a guess. The Terminology section calls out : ..."redundancy RTP stream" are used as defined in {{RFC7656}}. Is that sufficient, or do you want additional text? > I was impressed that you included this, > > These > redundant RTP streams may also contain their own unique RtpStreamId. > > but (of course) started wondering why you'd do that - can the RtpStreamId > for a redundancy RTP stream appear as a RepairedRtpStreamId for a third > RTP stream? Or is there some other reason to assign an RtpStreamId? This design is the result of a couple of countervailing forces on the mechanism. One sought to have a single ID per "thing that is rendered to the user," which would be a source RTP stream, including all of its redundancy streams. This design was driven in large part by the API exposed to web applications via the WebRTC APIs. Another school of thought sought to have a unique ID per RTP stream [1], so that future SDP mechanisms would have the ability to refer to RTP streams at the smallest level of granularity possible, should they need to. The current design, with two kinds of identifiers, is the result of some rather careful consensus building to satisfy both camps: redundancy relationships can be signaled as part of the RTP (allowing the API to refer to the whole cohort with a single ID), while redundancy streams can be uniquely referred to by future extensions. /a ___ [1] The terminology here isn't awesome, but at least it's precise -- you just need RFC7656 to untangle it From nobody Thu Oct 6 12:30:23 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A421293F4; Thu, 6 Oct 2016 12:30:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147578222226.23856.15113333530571267889.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 12:30:22 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rid-09.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 19:30:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions of the IETF. Title : RTP Stream Identifier Source Description (SDES) Authors : Adam Roach Suhas Nandakumar Peter Thatcher Filename : draft-ietf-avtext-rid-09.txt Pages : 9 Date : 2016-10-06 Abstract: This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rid-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rid-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 6 13:55:19 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0644129437; Thu, 6 Oct 2016 13:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 jkmDVqYVcEXu; Thu, 6 Oct 2016 13:55:16 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 5A5EB1293F3; Thu, 6 Oct 2016 13:55:16 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id e20so9804710ybb.0; Thu, 06 Oct 2016 13:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MdpMpmH5IuQgPbB7dW59kGg3160Jb1gbE0WlV7io3ck=; b=p2VAZRsD+kceEc4xJHn0mE/nS74PmxlH/yB5Ec2VfOhawLAWMkUz7GoZGiIn8T65Ou OIO4uo1ssRNjb+A3zDIgosmnwRVBKsejsRZ2JC+ZW7AaiF/AyBokb6o7+cdXW47jy2IO C3omzrIefyTQKbizGHscq549nsS1Rhre7qxQntDrHKZatZPHezMJYFkyQuIFsL167R9W B8hTIYcebGbFYnTG7aX+lAEz3gQMwKplki6u/upo4wqJ/T0JIetNPTaheXNttS0G8BeS adBvtRAjjQ5iY/4SGRBOPtdDvP4sOGdm6ec8VKLLhtea/bFrfLqKnKq3D1ko9sktZQ4X 3bBQ== 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; bh=MdpMpmH5IuQgPbB7dW59kGg3160Jb1gbE0WlV7io3ck=; b=Kf+0UTY1UuMYwQePSzDXdKYUlMh00maWRzIzm//2pr2vd/kABtCL1Kbk3mFzCz+P6x twxQPMPl58ivFQ2kVbkIBrrpzLfipPcic2G5FU4FV12Xjr4y3yvtc78h6Ufuv3h0FiQM eAXw9JS67OfG7+a6qn3XxJ76Yiaf8S0UUFlqt4m7t+HH5SWsP+BMSCc8TWcBzIdJL4t2 MQVuW+2FVgGuDsaNnTl2+MWoIlrnaOq8kUwGjujSd53lhH0Dv2IGWdt5XG9766i24XVc sfACN73UFMvgiPn+htXllv5HDrij+lijLEIrwg/HwfsyLn3MRACpkk+D4dIno1GV3gUr QH4Q== X-Gm-Message-State: AA6/9Rmq7EnZUsxQz5w0ATKwnF9eSNhG4JjIZifiADPuEg4qx1GXo9EDbQWNttz+baL5Aa99GDPFJ/Fbswuhbg== X-Received: by 10.37.3.142 with SMTP id 136mr13156205ybd.198.1475787315636; Thu, 06 Oct 2016 13:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.24.86 with HTTP; Thu, 6 Oct 2016 13:55:15 -0700 (PDT) In-Reply-To: <39635e26-cfeb-dff2-f084-27758dd411b6@nostrum.com> References: <147250463644.19013.26103564099771157.idtracker@ietfa.amsl.com> <39635e26-cfeb-dff2-f084-27758dd411b6@nostrum.com> From: Spencer Dawkins at IETF Date: Thu, 6 Oct 2016 15:55:15 -0500 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a11c00f3ab66d64053e388222 Archived-At: Cc: draft-ietf-avtext-rid@ietf.org, avtext@ietf.org, avtext-chairs@ietf.org, The IESG , Jonathan Lennox Subject: Re: [avtext] Spencer Dawkins' No Objection on draft-ietf-avtext-rid-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 20:55:18 -0000 --001a11c00f3ab66d64053e388222 Content-Type: text/plain; charset=UTF-8 Hi, Adam, On Thu, Oct 6, 2016 at 2:05 PM, Adam Roach wrote: > Sorry for the delay in responding here. > > On 8/29/16 16:03, Spencer Dawkins wrote: > >> In this text from the Introduction, >> >> RTP sessions frequently consist of multiple streams, >> would it be possible to add a word or two explaining why this >> happens? If >> it's true that this happens because multiple media types, or codecs, or >> ... are in use in the same RTP session, that's the level of detail I'm >> thinking about. >> > > The most relevant reasons for what we're working on here are simulcast, > layered encodings, and redundancy streams, all of which are mentioned in > the introduction already. That's true. > With that in mind, it's not clear to me what you're asking to have added. I was thinking of one level up from the specific reasons that are sprinkled around later in the introduction. I was guessing at some of the reasons ("multiple media types, or multiple codecs, or ..."). If there's no limit to the reasons why an RTP session needed more than one stream, it may not be possible to explain that at a higher level. And if there's no limit, that wouldn't surprise me a bit. > In this text: >> >> At the same time, when redundancy RTP streams are in use, >> could you provide a reference for redundancy RTP streams? I'm guessing >> this is using RFC 7198, but that's just a guess. >> > > The Terminology section calls out : > > ..."redundancy RTP stream" are used as defined in {{RFC7656}}. > > Is that sufficient, or do you want additional text? I was asking for a reference on first use, which is in the Introduction. The alternative is that people would need to keep reading until they get to the reference in the Terminology section. Do the right thing :-) > > I was impressed that you included this, >> >> These >> redundant RTP streams may also contain their own unique RtpStreamId. >> but (of course) started wondering why you'd do that - can the >> RtpStreamId >> for a redundancy RTP stream appear as a RepairedRtpStreamId for a third >> RTP stream? Or is there some other reason to assign an RtpStreamId? >> > > This design is the result of a couple of countervailing forces on the > mechanism. One sought to have a single ID per "thing that is rendered to > the user," which would be a source RTP stream, including all of its > redundancy streams. This design was driven in large part by the API exposed > to web applications via the WebRTC APIs. Another school of thought sought > to have a unique ID per RTP stream [1], so that future SDP mechanisms would > have the ability to refer to RTP streams at the smallest level of > granularity possible, should they need to. The current design, with two > kinds of identifiers, is the result of some rather careful consensus > building to satisfy both camps: redundancy relationships can be signaled as > part of the RTP (allowing the API to refer to the whole cohort with a > single ID), while redundancy streams can be uniquely referred to by future > extensions. This is helpful background, thanks. I was asking a more limited question. If someone has RtpStreamId A repaired by RtpStreamId B RtpStreamId B repaired by RtpStreamId C should an implementation be surprised? That's what wasn't clear to me from the text. > /a > > ___ > [1] The terminology here isn't awesome, but at least it's precise -- you > just need RFC7656 to untangle it > Indeed! I was present for some of the discussions that made it obvious that RFC was needed, but moved from RAI to TSV when work started on it. Thanks for the pointer. :-) Thanks, Spencer --001a11c00f3ab66d64053e388222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Adam,

On Thu, Oct 6, 2016 at 2:05 PM, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:
Sorry for the delay in r= esponding here.

On 8/29/16 16:03, Spencer Dawkins wrote:
In this text from the Introduction,

=C2=A0 =C2=A0 RTP sessions frequently consist of multiple streams,
=C2=A0 =C2=A0 would it be possible to add a word or two explaining why this= happens? If
it's true that this happens because multiple media types, or codecs, or=
... are in use in the same RTP session, that's the level of detail I= 9;m
thinking about.

 The most relevant reasons for what we're working on here are simulcast,= layered encodings, and redundancy streams, all of which are mentioned in t= he introduction already.

That's true.<= /div>
=C2=A0
With that in mind, it&= #39;s not clear to me what you're asking to have added.

I was thinking of one level up from the specific reasons t= hat are sprinkled around later in the introduction. I was guessing at some = of the reasons ("multiple media types, or multiple codecs, or ..."= ;).=C2=A0

If there's no limit to the reasons w= hy an RTP session needed more than one stream, it may not be possible to ex= plain that at a higher level. And if there's no limit, that wouldn'= t surprise me a bit.


In this text:

=C2=A0 =C2=A0 At the same time, when redundancy RTP streams are in use,
=C2=A0 =C2=A0 could you provide a reference for redundancy RTP streams? I&#= 39;m guessing
this is using RFC 7198, but that's just a guess.

The Terminology section calls out :

..."redundancy RTP stream" are used as defined in {{RFC7656}}.
Is that sufficient, or do you want additional text?

I was asking for a reference on first use, which is in the Introdu= ction. The alternative is that people would need to keep reading until they= get to the reference in the Terminology section. Do the right thing :-)
=C2=A0

I was impressed that you included this,

=C2=A0 =C2=A0 These
=C2=A0 =C2=A0 redundant RTP streams may also contain their own unique RtpSt= reamId.
=C2=A0 =C2=A0 but (of course) started wondering why you'd do that - can= the RtpStreamId
for a redundancy RTP stream appear as a RepairedRtpStreamId for a third
RTP stream? Or is there some other reason to assign an RtpStreamId?

This design is the result of a couple of countervailing forces on the mecha= nism. One sought to have a single ID per "thing that is rendered to th= e user," which would be a source RTP stream, including all of its redu= ndancy streams. This design was driven in large part by the API exposed to = web applications via the WebRTC APIs. Another school of thought sought to h= ave a unique ID per RTP stream [1], so that future SDP mechanisms would hav= e the ability to refer to RTP streams at the smallest level of granularity = possible, should they need to. The current design, with two kinds of identi= fiers, is the result of some rather careful consensus building to satisfy b= oth camps: redundancy relationships can be signaled as part of the RTP (all= owing the API to refer to the whole cohort with a single ID), while redunda= ncy streams can be uniquely referred to by future extensions.<= div>
This is helpful background, thanks.

=
I was asking a more limited question. If someone has=C2=A0
<= br>
RtpStr= eamId A repaired by RtpStreamId B
RtpStreamId B repaired by RtpStreamId C<= /div>

should an implementation be surprised? That= 9;s what wasn't clear to me from the text.
=C2=A0
/a

___
[1] The terminology here isn't awesome, but at least it's precise -= - you just need RFC7656 to untangle it

Indeed! I was prese= nt for some of the discussions that made it obvious that RFC was needed, bu= t moved from RAI to TSV when work started on it. Thanks for the pointer. :-= )

Than= ks,

Sp= encer
--001a11c00f3ab66d64053e388222-- From nobody Thu Oct 6 14:18:37 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832DC12978A; Thu, 6 Oct 2016 14:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 GEQ0uzOl4ZET; Thu, 6 Oct 2016 14:18:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9635C129776; Thu, 6 Oct 2016 14:18:28 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u96LIOmk097313 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Oct 2016 16:18:25 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Spencer Dawkins at IETF References: <147250463644.19013.26103564099771157.idtracker@ietfa.amsl.com> <39635e26-cfeb-dff2-f084-27758dd411b6@nostrum.com> From: Adam Roach Message-ID: Date: Thu, 6 Oct 2016 16:18:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF7232ECF999A341A02EF875" Archived-At: Cc: draft-ietf-avtext-rid@ietf.org, avtext@ietf.org, avtext-chairs@ietf.org, The IESG , Jonathan Lennox Subject: Re: [avtext] Spencer Dawkins' No Objection on draft-ietf-avtext-rid-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 21:18:30 -0000 This is a multi-part message in MIME format. --------------BF7232ECF999A341A02EF875 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/6/16 15:55, Spencer Dawkins at IETF wrote: > Hi, Adam, > > On Thu, Oct 6, 2016 at 2:05 PM, Adam Roach > wrote: > > Sorry for the delay in responding here. > > On 8/29/16 16:03, Spencer Dawkins wrote: > > In this text from the Introduction, > > RTP sessions frequently consist of multiple streams, > would it be possible to add a word or two explaining why > this happens? If > it's true that this happens because multiple media types, or > codecs, or > ... are in use in the same RTP session, that's the level of > detail I'm > thinking about. > > > The most relevant reasons for what we're working on here are > simulcast, layered encodings, and redundancy streams, all of which > are mentioned in the introduction already. > > > That's true. > > With that in mind, it's not clear to me what you're asking to have > added. > > > I was thinking of one level up from the specific reasons that are > sprinkled around later in the introduction. I was guessing at some of > the reasons ("multiple media types, or multiple codecs, or ..."). > > If there's no limit to the reasons why an RTP session needed more than > one stream, it may not be possible to explain that at a higher level. > And if there's no limit, that wouldn't surprise me a bit. Yeah, there's really no limit. RFC 3550, section 5.2, basically says "any time these conditions don't apply to you, you can multiplex several streams on a single session." It's done a lot, and new reasons seem to come up with some regularity. The reasons for doing so vary pretty widely, and include things like correlation, fate sharing, and reducing the number of ports consumed (both on hosts and on NATs). I think that a treatment of the reasons multiplexing happens would be either way too large for the introduction -- overwhelming the discussion of the actual RID mechanism -- or so poorly covered as to do readers a disservice. > > > In this text: > > At the same time, when redundancy RTP streams are in use, > could you provide a reference for redundancy RTP streams? > I'm guessing > this is using RFC 7198, but that's just a guess. > > > The Terminology section calls out : > > ..."redundancy RTP stream" are used as defined in {{RFC7656}}. > > Is that sufficient, or do you want additional text? > > > I was asking for a reference on first use, which is in the > Introduction. The alternative is that people would need to keep > reading until they get to the reference in the Terminology section. Do > the right thing :-) So you want it to read something like "At the same time, when redundancy RTP streams (see [RFC7656]) are in use, we also..." Is that right? > > I was impressed that you included this, > > These > redundant RTP streams may also contain their own unique > RtpStreamId. > but (of course) started wondering why you'd do that - can > the RtpStreamId > for a redundancy RTP stream appear as a RepairedRtpStreamId > for a third > RTP stream? Or is there some other reason to assign an > RtpStreamId? > > > This design is the result of a couple of countervailing forces on > the mechanism. One sought to have a single ID per "thing that is > rendered to the user," which would be a source RTP stream, > including all of its redundancy streams. This design was driven in > large part by the API exposed to web applications via the WebRTC > APIs. Another school of thought sought to have a unique ID per RTP > stream [1], so that future SDP mechanisms would have the ability > to refer to RTP streams at the smallest level of granularity > possible, should they need to. The current design, with two kinds > of identifiers, is the result of some rather careful consensus > building to satisfy both camps: redundancy relationships can be > signaled as part of the RTP (allowing the API to refer to the > whole cohort with a single ID), while redundancy streams can be > uniquely referred to by future extensions. > > > This is helpful background, thanks. > > I was asking a more limited question. If someone has > > RtpStreamId A repaired by RtpStreamId B > RtpStreamId B repaired by RtpStreamId C > > > should an implementation be surprised? That's what wasn't clear to me > from the text. I think that depends entirely on the repair mechanism. It doesn't make sense with any that are currently defined, but I don't think anything precludes it from happening in the future. I could be wrong on either count. /a --------------BF7232ECF999A341A02EF875 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/6/16 15:55, Spencer Dawkins at IETF wrote:
Hi, Adam,

On Thu, Oct 6, 2016 at 2:05 PM, Adam Roach <adam@nostrum.com> wrote:
Sorry for the delay in responding here.

On 8/29/16 16:03, Spencer Dawkins wrote:
In this text from the Introduction,

    RTP sessions frequently consist of multiple streams,
    would it be possible to add a word or two explaining why this happens? If
it's true that this happens because multiple media types, or codecs, or
... are in use in the same RTP session, that's the level of detail I'm
thinking about.

 The most relevant reasons for what we're working on here are simulcast, layered encodings, and redundancy streams, all of which are mentioned in the introduction already.

That's true.
 
With that in mind, it's not clear to me what you're asking to have added.

I was thinking of one level up from the specific reasons that are sprinkled around later in the introduction. I was guessing at some of the reasons ("multiple media types, or multiple codecs, or ..."). 

If there's no limit to the reasons why an RTP session needed more than one stream, it may not be possible to explain that at a higher level. And if there's no limit, that wouldn't surprise me a bit.

Yeah, there's really no limit. RFC 3550, section 5.2, basically says "any time these conditions don't apply to you, you can multiplex several streams on a single session." It's done a lot, and new reasons seem to come up with some regularity. The reasons for doing so vary pretty widely, and include things like correlation, fate sharing, and reducing the number of ports consumed (both on hosts and on NATs). I think that a treatment of the reasons multiplexing happens would be either way too large for the introduction -- overwhelming the discussion of the actual RID mechanism -- or so poorly covered as to do readers a disservice.




In this text:

    At the same time, when redundancy RTP streams are in use,
    could you provide a reference for redundancy RTP streams? I'm guessing
this is using RFC 7198, but that's just a guess.

 The Terminology section calls out :

..."redundancy RTP stream" are used as defined in {{RFC7656}}.

Is that sufficient, or do you want additional text?

I was asking for a reference on first use, which is in the Introduction. The alternative is that people would need to keep reading until they get to the reference in the Terminology section. Do the right thing :-)

So you want it to read something like "At the same time, when redundancy RTP streams (see [RFC7656]) are in use, we also..." Is that right?



 

I was impressed that you included this,

    These
    redundant RTP streams may also contain their own unique RtpStreamId.
    but (of course) started wondering why you'd do that - can the RtpStreamId
for a redundancy RTP stream appear as a RepairedRtpStreamId for a third
RTP stream? Or is there some other reason to assign an RtpStreamId?

 This design is the result of a couple of countervailing forces on the mechanism. One sought to have a single ID per "thing that is rendered to the user," which would be a source RTP stream, including all of its redundancy streams. This design was driven in large part by the API exposed to web applications via the WebRTC APIs. Another school of thought sought to have a unique ID per RTP stream [1], so that future SDP mechanisms would have the ability to refer to RTP streams at the smallest level of granularity possible, should they need to. The current design, with two kinds of identifiers, is the result of some rather careful consensus building to satisfy both camps: redundancy relationships can be signaled as part of the RTP (allowing the API to refer to the whole cohort with a single ID), while redundancy streams can be uniquely referred to by future extensions.

This is helpful background, thanks.

I was asking a more limited question. If someone has 

RtpStreamId A repaired by RtpStreamId B
RtpStreamId B repaired by RtpStreamId C

should an implementation be surprised? That's what wasn't clear to me from the text.

I think that depends entirely on the repair mechanism. It doesn't make sense with any that are currently defined, but I don't think anything precludes it from happening in the future. I could be wrong on either count.

/a
--------------BF7232ECF999A341A02EF875-- From nobody Thu Oct 6 14:28:09 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F478129450; Thu, 6 Oct 2016 14:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 u2WyReBk36zp; Thu, 6 Oct 2016 14:28:00 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 37E1512943C; Thu, 6 Oct 2016 14:28:00 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u124so21139875ywg.3; Thu, 06 Oct 2016 14:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VPER9EYK4aCFkNbsL+gcQFjN58ply3BwuYkQG1oJBto=; b=cbn4Y7GFkOsEvHluYrM/E9OZvVNC9+B//kH3A4dUhkcmf8dWfOhPLHH9BVvXnU+uKV 97xha4LJMDTQP8sK1e1kWeZyf5MUVmF1N45f1QRsmj8oHb0zsFnuqWiHigc6pUT4SOBS svnJAr2WzZCFXXUdX8AovuKT+WRkeqt8zMs0lInkBpOKUl0nVIxABon2sl5xlScjn3NS u088utVIjL5pzseJ33GDHFy9/G0J/9gEhAXih6P5s/LTywTGf19SNF/N1asgRw9w33YI mkmVS2sV4HGatlJw/qxvexsG9E+FubNCxSFO11JyfE8JTaC2vCy722D3RtzG7b0zI690 BuoQ== 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; bh=VPER9EYK4aCFkNbsL+gcQFjN58ply3BwuYkQG1oJBto=; b=H+501SlrviLTX3m9V5MEXqxQUY+lEmZiS2LkGCAxz6mGFol74sLsFYp982vInn0b9/ qDLl9V4m+tdZ9F+C9DuptiAQf6KQS8M88KMLRcmtFAIg6A6U1bnMbsONZqQ36Tcu0PI7 TrLgKB2g2Vl7OspjOGIxojUUSyr6NCxpoqaOR2eGe1ddcbTKr+PQ9EEa4gTkXzEdEvcE k3SMqy9g9W1dGY/4rJ0gu212u2jxcy2814SseC9aOVmOSBVUhSTVQXnIAlTDcdTyh8Vz ooSpwZgHO57WwPdEF7lj0sByYOUgzg/GsIZ8SWlmLaucDW9/ugKbW6gMMIWX7fCXpa0d 2OxA== X-Gm-Message-State: AA6/9Rkhx+CjJ60TS5pz0+2a1M1pF3MnPkJguzJpdPAM+vh1jAbckv1LsYaMq1O1O3BuJsVsOzELnoEfk0rc/Q== X-Received: by 10.13.204.139 with SMTP id o133mr12647387ywd.61.1475789279473; Thu, 06 Oct 2016 14:27:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.24.86 with HTTP; Thu, 6 Oct 2016 14:27:59 -0700 (PDT) In-Reply-To: References: <147250463644.19013.26103564099771157.idtracker@ietfa.amsl.com> <39635e26-cfeb-dff2-f084-27758dd411b6@nostrum.com> From: Spencer Dawkins at IETF Date: Thu, 6 Oct 2016 16:27:59 -0500 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a114f0028c43455053e38f780 Archived-At: Cc: draft-ietf-avtext-rid@ietf.org, avtext@ietf.org, avtext-chairs@ietf.org, The IESG , Jonathan Lennox Subject: Re: [avtext] Spencer Dawkins' No Objection on draft-ietf-avtext-rid-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 21:28:02 -0000 --001a114f0028c43455053e38f780 Content-Type: text/plain; charset=UTF-8 Hi, Adam, On Thu, Oct 6, 2016 at 4:18 PM, Adam Roach wrote: > On 10/6/16 15:55, Spencer Dawkins at IETF wrote: > > Hi, Adam, > > On Thu, Oct 6, 2016 at 2:05 PM, Adam Roach wrote: > >> Sorry for the delay in responding here. >> >> On 8/29/16 16:03, Spencer Dawkins wrote: >> >>> In this text from the Introduction, >>> >>> RTP sessions frequently consist of multiple streams, >>> would it be possible to add a word or two explaining why this >>> happens? If >>> it's true that this happens because multiple media types, or codecs, or >>> ... are in use in the same RTP session, that's the level of detail I'm >>> thinking about. >>> >> >> The most relevant reasons for what we're working on here are simulcast, >> layered encodings, and redundancy streams, all of which are mentioned in >> the introduction already. > > > That's true. > > >> With that in mind, it's not clear to me what you're asking to have added. > > > I was thinking of one level up from the specific reasons that are > sprinkled around later in the introduction. I was guessing at some of the > reasons ("multiple media types, or multiple codecs, or ..."). > > If there's no limit to the reasons why an RTP session needed more than one > stream, it may not be possible to explain that at a higher level. And if > there's no limit, that wouldn't surprise me a bit. > > > Yeah, there's really no limit. RFC 3550, section 5.2, basically says "any > time these conditions don't apply to you, you can multiplex several streams > on a single session." It's done a lot, and new reasons seem to come up with > some regularity. The reasons for doing so vary pretty widely, and include > things like correlation, fate sharing, and reducing the number of ports > consumed (both on hosts and on NATs). I think that a treatment of the > reasons multiplexing happens would be either way too large for the > introduction -- overwhelming the discussion of the actual RID mechanism -- > or so poorly covered as to do readers a disservice. > Thanks for helping me understand your thinking. I agree with you. If you DO happen to see a pony, I'd like one, but ... > > > >> In this text: >>> >>> At the same time, when redundancy RTP streams are in use, >>> could you provide a reference for redundancy RTP streams? I'm >>> guessing >>> this is using RFC 7198, but that's just a guess. >>> >> >> The Terminology section calls out : >> >> ..."redundancy RTP stream" are used as defined in {{RFC7656}}. >> >> Is that sufficient, or do you want additional text? > > > I was asking for a reference on first use, which is in the Introduction. > The alternative is that people would need to keep reading until they get to > the reference in the Terminology section. Do the right thing :-) > > > So you want it to read something like "At the same time, when redundancy > RTP streams (see [RFC7656]) are in use, we also..." Is that right? > That's what I was thinking. I found myself guessing what was being referred to, and the reference on first use would have helped me do the right thing. > > > > >> >> I was impressed that you included this, >>> >>> These >>> redundant RTP streams may also contain their own unique RtpStreamId. >>> but (of course) started wondering why you'd do that - can the >>> RtpStreamId >>> for a redundancy RTP stream appear as a RepairedRtpStreamId for a third >>> RTP stream? Or is there some other reason to assign an RtpStreamId? >>> >> >> This design is the result of a couple of countervailing forces on the >> mechanism. One sought to have a single ID per "thing that is rendered to >> the user," which would be a source RTP stream, including all of its >> redundancy streams. This design was driven in large part by the API exposed >> to web applications via the WebRTC APIs. Another school of thought sought >> to have a unique ID per RTP stream [1], so that future SDP mechanisms would >> have the ability to refer to RTP streams at the smallest level of >> granularity possible, should they need to. The current design, with two >> kinds of identifiers, is the result of some rather careful consensus >> building to satisfy both camps: redundancy relationships can be signaled as >> part of the RTP (allowing the API to refer to the whole cohort with a >> single ID), while redundancy streams can be uniquely referred to by future >> extensions. > > > This is helpful background, thanks. > > I was asking a more limited question. If someone has > > RtpStreamId A repaired by RtpStreamId B > RtpStreamId B repaired by RtpStreamId C > > > should an implementation be surprised? That's what wasn't clear to me from > the text. > > > I think that depends entirely on the repair mechanism. It doesn't make > sense with any that are currently defined, but I don't think anything > precludes it from happening in the future. I could be wrong on either count. > Ah, I see your problem. You can't say whether that makes sense *in this spec*. That makes perfect sense to me. I wonder if it's worth saying that, but you're doing pretty well at doing the right thing, so I'm sure you will here, too. And thanks for your help. Spencer --001a114f0028c43455053e38f780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Adam,

On Thu, Oct 6, 2016 at 4:18 PM, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:
=20 =20 =20
On 10/6/16 1= 5:55, Spencer Dawkins at IETF wrote:
Hi, Adam,

On Thu, Oct 6, 2016 at 2:05 PM, Adam Roach <adam@nostrum.com> wrote:
Sorry for the delay in responding here.

On 8/29/16 16:03, Spencer Dawkins wrote:
In this text from the Introduction,

=C2=A0 =C2=A0 RTP sessions frequently consist of multiple streams,
=C2=A0 =C2=A0 would it be possible to add a word or two explaining why this happens? If
it's true that this happens because multiple media types, or codecs, or
... are in use in the same RTP session, that's the level of detail I'm
thinking about.

 The most relevant reasons for what we're working on here are simulcast, layered encodings, and redundancy streams, all of which are mentioned in the introduction already.

That's true.
=C2=A0
With that in mind, it's not clear to me what you're asking= to have added.

I was thinking of one level up from the specific reasons that are sprinkled around later in the introduction. I was guessing at some of the reasons ("multiple media types, or multiple codecs, or ..."= ).=C2=A0

If there's no limit to the reasons why an RTP session needed more than one stream, it may not be possible to explain that at a higher level. And if there's no limit, that wouldn't surprise me a bit.

 Yeah, there's really no limit. RFC 3550, section 5.2, basically say= s "any time these conditions don't apply to you, you can multipl= ex several streams on a single session." It's done a lot, and new reasons seem to come up with some regularity. The reasons for doing so vary pretty widely, and include things like correlation, fate sharing, and reducing the number of ports consumed (both on hosts and on NATs). I think that a treatment of the reasons multiplexing happens would be either way too large for the introduction -- overwhelming the discussion of the actual RID mechanism -- or so poorly covered as to do readers a disservice.
Thanks for helping me understand your thinking. I agree with y= ou. If you DO happen to see a pony, I'd like one, but ...
=C2= =A0



In this text:

=C2=A0 =C2=A0 At the same time, when redundancy RTP strea= ms are in use,
=C2=A0 =C2=A0 could you provide a reference for redundanc= y RTP streams? I'm guessing
this is using RFC 7198, but that's just a guess.

 The Terminology section calls out :

..."redundancy RTP stream" are used as defined in {{RFC7656}}.

Is that sufficient, or do you want additional text?

I was asking for a reference on first use, which is in the Introduction. The alternative is that people would need to keep reading until they get to the reference in the Terminology section. Do the right thing :-)

 So you want it to read something like "At the same time, when redundancy RTP streams (see [RFC7656]) are in use, we also..." Is that right?

That's what I was= thinking. I found myself guessing what was being referred to, and the refe= rence on first use would have helped me do the right thing.
=C2= =A0


=C2=A0

I was impressed that you included this,

=C2=A0 =C2=A0 These
=C2=A0 =C2=A0 redundant RTP streams may also contain thei= r own unique RtpStreamId.
=C2=A0 =C2=A0 but (of course) started wondering why you&#= 39;d do that - can the RtpStreamId
for a redundancy RTP stream appear as a RepairedRtpStreamId for a third
RTP stream? Or is there some other reason to assign an RtpStreamId?

 This design is the result of a couple of countervailing forces on the mechanism. One sought to have a single ID per "thing that is rendered to the user," which wou= ld be a source RTP stream, including all of its redundancy streams. This design was driven in large part by the API exposed to web applications via the WebRTC APIs. Another school of thought sought to have a unique ID per RTP stream [1], so that future SDP mechanisms would have the ability to refer to RTP streams at the smallest level of granularity possible, should they need to. The current design, with two kinds of identifiers, is the result of some rather careful consensus building to satisfy both camps: redundancy relationships can be signaled as part of the RTP (allowing the API to refer to the whole cohort with a single ID), while redundancy streams can be uniquely referred to by future extensions.

This is helpful background, thanks.

I was asking a more limited question. If someone has=C2=A0=

RtpStreamId A repaired by RtpStreamId B
RtpStreamId B repaired by RtpStreamId C

should an implementation be surprised? That's what wasn't clear to me from the text.

 I think that depends entirely on the repair mechanism. It doesn't make sense with any that are currently defined, but I don't think anything precludes it from happening in the future. I could be wrong on either count.

Ah, I see your p= roblem. You can't say whether that makes sense *in this spec*. That mak= es perfect sense to me. I wonder if it's worth saying that, but you'= ;re doing pretty well at doing the right thing, so I'm sure you will he= re, too.

And thanks for your help.=C2=A0

Spencer=C2=A0
--001a114f0028c43455053e38f780-- From nobody Tue Oct 11 18:22:35 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5235F1296B3 for ; Tue, 11 Oct 2016 18:22:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147623535333.32039.15576921250617043694.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2016 18:22:33 -0700 From: IETF Secretariat Archived-At: Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 01:22:33 -0000 Changed milestone "Submit Update to Codec Control Messages in the RTP Audio-Visual Profile with Feedback (RFC5104) with Layered Codecs as Proposed Standard", resolved as "Done", added draft-ietf-avtext-avpf-ccm-layered to milestone. URL: https://datatracker.ietf.org/wg/avtext/charter/ From nobody Tue Oct 18 15:28:20 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E812947C; Tue, 18 Oct 2016 15:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=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 EBnmZX3L1_RA; Tue, 18 Oct 2016 15:28:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C56D31294DC; Tue, 18 Oct 2016 15:28:16 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9IMSCJf016987 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 18 Oct 2016 17:28:14 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Spencer Dawkins at IETF References: <147250463644.19013.26103564099771157.idtracker@ietfa.amsl.com> <39635e26-cfeb-dff2-f084-27758dd411b6@nostrum.com> From: Adam Roach Message-ID: Date: Tue, 18 Oct 2016 17:28:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-avtext-rid@ietf.org, avtext@ietf.org, avtext-chairs@ietf.org, The IESG , Jonathan Lennox Subject: Re: [avtext] Spencer Dawkins' No Objection on draft-ietf-avtext-rid-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 22:28:19 -0000 On 10/6/16 16:27, Spencer Dawkins at IETF wrote: > Ah, I see your problem. You can't say whether that makes sense *in > this spec*. That makes perfect sense to me. I wonder if it's worth > saying that, but you're doing pretty well at doing the right thing, so > I'm sure you will here, too. I've kind of turned this over in my mind a few times, and I'm afraid that anything I could say here would make things more confusing. As far as I can tell, the prospect that the repair stream structure you describe might arise is kind of remote; and, if it does arise, I think it'll be clear enough to the authors of any such mechanism to describe how it works with RID. For the time being, because it's just such an esoteric sounding kind of thing, I suspect that trying to describe it will confuse more people than it helps. Which is to say: unless you feel strongly that a change is needed here, I think the document is ready to ship. /a From nobody Tue Oct 18 19:57:15 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3111294AC; Tue, 18 Oct 2016 19:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 emYD1oCoeQuI; Tue, 18 Oct 2016 19:57:12 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 85CD9129499; Tue, 18 Oct 2016 19:57:12 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u124so7954630ywg.3; Tue, 18 Oct 2016 19:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LPsTKjUBPJ5l80mQEBvjRyPXOD/fuFjJo2+VCeGnZik=; b=PG7ETV/znfFGIJemuapvut5Kwvyk1eR8MAPRufF3w19bw3VoZfcaYWbgv28YcDuco/ 39Hf/ENQoXPtVI0UWWLQkmXE/W3obyQ/RunCM+PKMDIMMC4z42GNnrD9d28//fyNCdOx 3fd8ku5JG187QBvH4Zsw+jP1dd3X3v2SrT3R/esqtq0XxEJFAT7KM6uGtT7n3+DXcpgj TnlV06HPnAVmWjdGfve1za0jTSlu6WaI6c3bvP/DmPZ+luWYtdfzffSLTWNbtM0PgaVT 4XvH+LvppW+RB6+o7zkJqLEQA3a5Y9ixgQVNV1hnFjYiVqutunYovP1eFORz1AbHDGIm hpvA== 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; bh=LPsTKjUBPJ5l80mQEBvjRyPXOD/fuFjJo2+VCeGnZik=; b=YUSU8X6++Xcyok4AExDeNCAQT1pJfKORSIjq8aeElZxjHP+iJw8LcRAltVrdvIqwqQ KoTfOKg3fzwWwdHnrG2dtkUHWc6aaIPJRLkDGaV/CjWFAeqW92+MJyU2TJLa3lzlg13N +JMB3LdQproNfwZuHAlKLIvfkccgw+Lhfe44VXw9BRz/s+eavE9i89hZ1FDyuVOciRXZ 2dr7h3pMfoIuBsQnM/kuMSBie1UhKj7WxNBQ8vufNkikG1qogolDUJsmrgWNBKwbjcv8 SlUIm3vjtUoILXOM0ME31CWqOYouOb9mD64H9PEK0PKsgQuQTB+WsJupgBPVlOMKJ9nb OM1w== X-Gm-Message-State: AA6/9RkbXYJwWPmflEJ27Lozs40CyLAlqhqhTBV+QnGXwZgzSawyWDSJdjK+8nPG3wHGPVJJsAHgYCQZIWpefw== X-Received: by 10.129.99.2 with SMTP id x2mr3841284ywb.106.1476845831803; Tue, 18 Oct 2016 19:57:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.47.215 with HTTP; Tue, 18 Oct 2016 19:57:10 -0700 (PDT) Received: by 10.37.47.215 with HTTP; Tue, 18 Oct 2016 19:57:10 -0700 (PDT) In-Reply-To: References: <147250463644.19013.26103564099771157.idtracker@ietfa.amsl.com> <39635e26-cfeb-dff2-f084-27758dd411b6@nostrum.com> From: Spencer Dawkins at IETF Date: Tue, 18 Oct 2016 21:57:10 -0500 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a1141b8cc3159e2053f2ef7e6 Archived-At: Cc: draft-ietf-avtext-rid@ietf.org, avtext@ietf.org, Jonathan Lennox , The IESG , avtext-chairs@ietf.org Subject: Re: [avtext] Spencer Dawkins' No Objection on draft-ietf-avtext-rid-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 02:57:14 -0000 --001a1141b8cc3159e2053f2ef7e6 Content-Type: text/plain; charset=UTF-8 Adam, On Oct 18, 2016 17:28, "Adam Roach" wrote: > > On 10/6/16 16:27, Spencer Dawkins at IETF wrote: >> >> Ah, I see your problem. You can't say whether that makes sense *in this spec*. That makes perfect sense to me. I wonder if it's worth saying that, but you're doing pretty well at doing the right thing, so I'm sure you will here, too. > > > > I've kind of turned this over in my mind a few times, and I'm afraid that anything I could say here would make things more confusing. As far as I can tell, the prospect that the repair stream structure you describe might arise is kind of remote; and, if it does arise, I think it'll be clear enough to the authors of any such mechanism to describe how it works with RID. For the time being, because it's just such an esoteric sounding kind of thing, I suspect that trying to describe it will confuse more people than it helps. > > Which is to say: unless you feel strongly that a change is needed here, I think the document is ready to ship. I don't feel strongly that a change is needed. I was pushing on what looked like a corner case, and it is one, but it's not one you can nail down *in this spec*. So I agree with you that the spec is ready to ship without text changes to address my comment. I really appreciate you educating me on how this fits together, as well as considering my comments. Tell the RFC editor I said "hi" ;-) Spencer --001a1141b8cc3159e2053f2ef7e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Adam,

On Oct 18, 2016 17:28, "Adam Roach" <adam@nostrum.com> wrote:
>
> On 10/6/16 16:27, Spencer Dawkins at IETF wrote:
>>
>> Ah, I see your problem. You can't say whether that makes sense= *in this spec*. That makes perfect sense to me. I wonder if it's worth= saying that, but you're doing pretty well at doing the right thing, so= I'm sure you will here, too.
>
>
>
> I've kind of turned this over in my mind a few times, and I'm = afraid that anything I could say here would make things more confusing. As = far as I can tell, the prospect that the repair stream structure you descri= be might arise is kind of remote; and, if it does arise, I think it'll = be clear enough to the authors of any such mechanism to describe how it wor= ks with RID. For the time being, because it's just such an esoteric sou= nding kind of thing, I suspect that trying to describe it will confuse more= people than it helps.
>
> Which is to say: unless you feel strongly that a change is needed here= , I think the document is ready to ship.

I don't feel strongly that a change is needed. I was pus= hing on what looked like a corner case, and it is one, but it's not one= you can nail down *in this spec*.

So I agree with you that the spec is ready to ship without t= ext changes to address my comment.

I really appreciate you educating me on how this fits togeth= er, as well as considering my comments.

Tell the RFC editor I said "hi" ;-)

Spencer

--001a1141b8cc3159e2053f2ef7e6-- From nobody Wed Oct 19 06:54:27 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF69512999F; Wed, 19 Oct 2016 06:54:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147688525893.8836.6939175189818475334.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2016 06:54:18 -0700 Archived-At: Cc: avtext@ietf.org, Jonathan Lennox , avtext-chairs@ietf.org, draft-ietf-avtext-rid@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [avtext] Protocol Action: 'RTP Stream Identifier Source Description (SDES)' to Proposed Standard (draft-ietf-avtext-rid-09.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 13:54:19 -0000 The IESG has approved the following document: - 'RTP Stream Identifier Source Description (SDES)' (draft-ietf-avtext-rid-09.txt) as Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ Technical Summary This document defines and registers two new RTCP Source Description items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. It also defines and registers corresponding RTP Header Extension Elements. Working Group Summary The document went through an initial last call, during which there were some objections to the design. The authors and the objectors met together at the Buenos Aires IETF meeting, and worked out a slightly altered design which satisfied everyone. A second last call produced only minor requests for changes, which were addressed, and several people confirmed that they had no issues with the draft. Document Quality The document was reviewed by several AVText members, which resulted in the current design. The mechanism defined by the document is expected to be mandated by WebRTC. It is already implemented in Firefox and is planned to be implemented in Chrome. Personnel The document Shepherd is Jonathan Lennox. The Responsible Area Director is Ben Campbell. From nobody Wed Oct 19 22:42:48 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF5D1293F9 for ; Wed, 19 Oct 2016 22:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BmoeuDdGCDDx for ; Wed, 19 Oct 2016 22:42:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568231294BA for ; Wed, 19 Oct 2016 22:42:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTM53777; Thu, 20 Oct 2016 05:42:42 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 20 Oct 2016 06:42:42 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.199]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 20 Oct 2016 13:42:37 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext] Request for agenda time for AVTExt IETF97 Thread-Index: AdIqlMFkrEYkpqbpSWSw4dvvzzh9Zw== Date: Thu, 20 Oct 2016 05:42:35 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86FE7407@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.210] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86FE7407nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58085953.00B7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.199, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a9cc0704fbae7e9a51b84050c7e92b6a Archived-At: Cc: Jonathan Lennox Subject: [avtext] Request for agenda time for AVTExt IETF97 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 05:42:48 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86FE7407nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The AVTExt working group scheduled in IETF 97 is going to meet from 9:30 to= 11:00, on Thursday, November 17, 2016, together with AVTCORE. Please send Jonathan and me any proposals and requests for agenda time. Thank you! Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB86FE7407nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,<= /p>

 

The AVTExt working group sch= eduled in IETF 97 is going to meet from 9:30 to 11:00, on Thursday, Novembe= r 17, 2016, together with AVTCORE.

 

Please send Jonathan and me = any proposals and requests for agenda time.

 

Thank you!=

 

Rachel

--_000_51E6A56BD6A85142B9D172C87FC3ABBB86FE7407nkgeml513mbxchi_-- From nobody Fri Oct 21 16:25:25 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5671296CA; Fri, 21 Oct 2016 16:21:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207670.28214.18208039244559624202.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:16 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] avtext - Requested session has been scheduled for IETF 97 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:17 -0000 Dear Rachel Huang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. avtext Session 1 (1:00:00) Thursday, Morning Session I 0930-1100 Room Name: Park Ballroom 2 size: 125 --------------------------------------------- Special Note: 09:30-10:15 Request Information: --------------------------------------------------------- Working Group Name: Audio/Video Transport Extensions Area Name: Applications and Real-Time Area Session Requester: Rachel Huang Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: avtcore mmusic payload rtcweb rmcat dispatch perc netvc Second Priority: artarea codec quic plus taps tsvwg Special Requests: --------------------------------------------------------- From nobody Mon Oct 31 10:17:54 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F52B129469 for ; Mon, 31 Oct 2016 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.297, SPF_PASS=-0.001] autolearn=no autolearn_force=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 RGA914TQtZgP for ; Mon, 31 Oct 2016 10:17:52 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8D5129413 for ; Mon, 31 Oct 2016 10:17:52 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9VHEZKn002890; Mon, 31 Oct 2016 13:17:48 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 26cmvjskyq-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Oct 2016 13:17:48 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 31 Oct 2016 12:17:47 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: [avtext] Request for agenda time for AVTExt IETF97 Thread-Index: AdIqlMFkrEYkpqbpSWSw4dvvzzh9ZwJL9nwA Date: Mon, 31 Oct 2016 17:17:46 +0000 Message-ID: <718657CA-8CE9-41E8-B74C-248B032F67AB@vidyo.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86FE7407@nkgeml513-mbx.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86FE7407@nkgeml513-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_718657CA8CE941E8B74C248B032F67ABvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610310308 Archived-At: Subject: Re: [avtext] Request for agenda time for AVTExt IETF97 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 17:17:53 -0000 --_000_718657CA8CE941E8B74C248B032F67ABvidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, At this time we have not received any requests for agenda time at AVTExt fo= r IETF 97. Please let Rachel and me know if you want to present or discuss anything in= the AVTExt session. Otherwise we will cancel the session. (We will still= present a status slide during the AVTCore meeting.) On Oct 20, 2016, at 1:42 AM, Huangyihong (Rachel) > wrote: Dear all, The AVTExt working group scheduled in IETF 97 is going to meet from 9:30 to= 11:00, on Thursday, November 17, 2016, together with AVTCORE. Please send Jonathan and me any proposals and requests for agenda time. Thank you! Rachel --_000_718657CA8CE941E8B74C248B032F67ABvidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <26C08D34708DE5419804F297CB173F53@vidyo.com> Content-Transfer-Encoding: quoted-printable
Hello all,

At this time we have not received any requests for agenda t= ime at AVTExt for IETF 97.

Please let Rachel and me know if you want to present or dis= cuss anything in the AVTExt session.  Otherwise we will cancel the ses= sion.  (We will still present a status slide during the AVTCore meetin= g.)


--_000_718657CA8CE941E8B74C248B032F67ABvidyocom_-- From nobody Mon Oct 31 14:47:52 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F20E129B29; Mon, 31 Oct 2016 14:47:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795046651.23193.2070361815432103504.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 14:47:46 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-framemarking-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:47:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions of the IETF. Title : Frame Marking RTP Header Extension Authors : Espen Berger Suhas Nandakumar Mo Zanaty Filename : draft-ietf-avtext-framemarking-03.txt Pages : 10 Date : 2016-10-31 Abstract: This document describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media encryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-framemarking/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-framemarking-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-framemarking-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/