Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FED3A0BAC; Wed, 8 Apr 2020 08:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.102 X-Spam-Level: *** X-Spam-Status: No, score=3.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qDOUk5e6Hg6u; Wed, 8 Apr 2020 08:48:32 -0700 (PDT) Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) (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 3D2263A0BA1; Wed, 8 Apr 2020 08:48:29 -0700 (PDT) Received: from HERTELLT (cpe-98-5-223-142.buffalo.res.rr.com [98.5.223.142]) by host105.olm1.com (Postfix) with ESMTPSA id 9DB22B93C3E; Wed, 8 Apr 2020 11:48:27 -0400 (EDT) From: To: "'Benjamin Kaduk'" , "'Barry Leiba'" Cc: "'Roni Even \(A\)'" , "'The IESG'" , "'Catherine Meadows'" , "'IETF SecDir'" , , "'Ali Begen'" , , , "'Dave Satterlee \(Vocal\)'" , "'IETF discussion list'" , , References: <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> <20191125064606.GL32847@mit.edu> <00c601d5e339$965ebd90$c31c38b0$@vocal.com> <20200214194321.GF43385@kduck.mit.edu> In-Reply-To: <20200214194321.GF43385@kduck.mit.edu> Date: Wed, 8 Apr 2020 11:48:26 -0400 Message-ID: <002b01d60dbd$25675f80$70361e80$@vocal.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002C_01D60D9B.9E56D0F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLglFUw/9Hrg4xFnJGl+gKOw+IttgKP/a5DAUK4sQ4C/qBe9QJw6xekAqUwBBcB6AFNSwEOtkf1AdJM/WIBsvGQ0QGhq9LkpYGDUMA= Content-Language: en-us Archived-At: X-Mailman-Approved-At: Thu, 16 Apr 2020 22:29:36 -0700 Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 15:48:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002C_01D60D9B.9E56D0F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002D_01D60D9B.9E56D0F0" ------=_NextPart_001_002D_01D60D9B.9E56D0F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, With this social distancing situation, I'm finally catching up on open = items myself. I have made the changes as we have discussed and = incorporated your suggestions. I believe the changes are fully = contained in the two paragraphs below: Section 2 (last paragraph) - Clarification for octet count (was) In order to accommodate a varying amount of TSVCIS augmented speech data, it is only necessary to specify the number of octets containing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using 15 and 35 packed octet parameters [TSVCIS]. =20 (now) In order to accommodate a varying amount of TSVCIS augmented speech data, an octet count specifies the number of octets representing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using a fixed set of 15 and 35 packed octet parameters in a standardized order [TSVCIS]. =20 Section 3.1 (first sentence in last paragraph) - Clarification for CODA, = CODB (was) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an end-to-end framing bit. (now) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an alternating 1/0 end-to-end framing bit. =20 Ben, I believe this addresses your comments and requests for = clarifications as per our email discussion chain below. Thanks for you comments and with your concurrence (and my home = computer's cooperation), I will post a new draft hopefully acceptable = for final approval. Regards to all and stay on the good side of Darwin. Victor -----Original Message----- From: Benjamin Kaduk =20 Sent: Friday, February 14, 2020 2:43 PM To: victor.demjanenko@vocal.com; 'Barry Leiba' Cc: 'Roni Even (A)' ; 'The IESG' ; = 'Catherine Meadows' ; 'IETF SecDir' = ; draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' = ; avtcore-chairs@ietf.org; avt@ietf.org; = 'Dave Satterlee (Vocal)' ; 'IETF discussion = list' ; draft-ietf-payload-tsvcis.all@ietf.org Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) Hi Barry, As Victor notes, this one was/is waiting on me; he did reply (offlist) = on 15 January but I seem to have missed it amid a deluge of other mail that = arrived at that time. Thanks for the reminder, and thanks Victor for = re-sending the comments. (inline) On Fri, Feb 14, 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com = wrote: > HI Barry, >=20 > Thanks for recalling this was still outstanding. I had emailed Ben = just after the holidays and did not realize we had no response. The = below is what we suggested to Ben to address concerns he raised. >=20 > -------------------- > Hi Ben, >=20 > Hope your holidays were good. Our were both good and busy. = Deliveries for two NASA projects and the holidays kept us from = responding sooner. But we do want to get this draft completed. >=20 > With your permission, I=E2=80=99d like to address your comments = directly, resolve what changes we should make and then publish a new = version with a summary of our out-of-band discussions. We don=E2=80=99t = have a lot of experience with drafting such documents and would like to = know exactly what is needed to make this draft acceptable. >=20 > I believe there are two comments/issues to address: >=20 > 1) CODA, CODB >=20 > Your comment ends by stating: =E2=80=9C(Or, of course, the use of = CODB as an alternating 1/0 bit as the framing usage could be documented = instead.)=E2=80=9D We can do this as follows: >=20 > (original) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an end-to-end framing > bit. Frame decoding would remain distinct as CODA being zero on its > own would indicate a 7-byte frame for either 2400 or 600 bps rate = and > the use of 600 bps speech coding could be deduced from the RTP > timestamp (and anticipated by the SDP negotiations). >=20 > (adding =E2=80=9Calternating 1/0=E2=80=9D) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an alternating 1/0 = end-to-end framing > bit. Frame decoding would remain distinct as CODA being zero on its > own would indicate a 7-byte frame for either 2400 or 600 bps rate = and > the use of 600 bps speech coding could be deduced from the RTP > timestamp (and anticipated by the SDP negotiations). >=20 > I think this change would be sufficient to address your concern about = what to expect for CODB. This looks like the minimal sufficient change, yes. (I use "minimal" because I would say more if I was writing it, but I don't think I can = insist that you write it the way I would -- it's your document after = all!) > 2. Packing and unpacking >=20 > You are correct that I am trying to vaguely describe a middle layer = shim that is neither RTP nor speech coder. So it definitely does need = to be clear. The vagueness comes from the speech coder description = being a FOUO document. Its now unclassified so I can potentially say = more (and I did make some enhancements of the parameter description = already). =20 >=20 > So I am trying to understand exactly what you think is vague in our = current description: >=20 > TSVCIS augmented speech data is derived from the signal processing > and data already performed by the MELPe speech coder. For the > purposes of this specification, only the general parameter nature = of > TSVCIS will be characterized. Depending on the bandwidth available > (and FEC requirements), a varying number of TSVCIS-specific speech > coder parameters need to be transported. These are first = byte-packed > and then conveyed from encoder to decoder. >=20 > Byte packing of TSVCIS speech data into packed parameters is > processed as per the following example: >=20 > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) >=20 > MSB LSB > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | H | G | F | E | D | C | B | A |=20 > +------+------+------+------+------+------+------+------+ >=20 > This packing method places the three-bit field "first" in the = lowest > bits followed by the next five-bit field. Parameters may be split > between octets with the most significant bits in the earlier octet. > Any unfilled bits in the last octet MUST be filled with zero. [not actually relevant to the Discuss part, but if there is always = exactly one 3-bit parameter and one 5-bit parameter, then this text = allowing splitting across octets will never be used and is potentially = confusing to mention.] > In order to accommodate a varying amount of TSVCIS augmented speech > data, it is only necessary to specify the number of octets = containing > the packed TSVCIS parameters. The encoding to do so is presented=20 > in I think the "only necessary to specify the number of octets" is the key = stumbling point, for me -- I need to know the number of octets as well = as the order of the parameters within the list, which is more = information than just the number of octets. > Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using 15 and 35 packed octet parameters [TSVCIS]. =20 I think I failed to internalize the "two configurations using 15 and 35 = packed octet parameters" the first time I read the document, as this = does help give the reader a clue that [TSVCIS] gives a good picture of = what parameters go where. So it seems like we could easily append to = that, for "using a fixed set of 15 and 35 packed octet parameters in a = fixed order [TSVCIS]" and that would resolve my concerns. > The speech coder description of the parameters is the following: >=20 > =20 >=20 > So the three bit pitch is first (bits 56 to 58), followed by a five = bit amplitude (bits 59 to 63) and then an array of spectral components, = each 8-bit wide (starting at bit 64). [And maybe TSVCIS specifes that the spectral components are derived from = some fundamental harmonic decomposition that naturally quantizes to a = number-of-parameters/accuracy tradeoff with a natural order. If so, we = could also rely on that instead of my proposed change above; let me know = if you want to explore that path further.] > Based on this information, I=E2=80=99m not sure what we should add to = our=20 > draft to make the description of packing/unpacking clearer. Can you=20 > make any suggestions or does this table help you with what you did not = > know? (I don=E2=80=99t think I should put this table into the draft = RFC=20 > however.) Hopefully the above helps to clarify. Thanks, and sorry for the delay. -Ben > Thanks for your attention and comments. >=20 > Victor & Dave >=20 >=20 >=20 > -----Original Message----- > From: Barry Leiba > Sent: Friday, February 14, 2020 7:38 AM > To: Benjamin Kaduk > Cc: victor.demjanenko@vocal.com; Roni Even (A) ; = > The IESG ; Catherine Meadows=20 > ; IETF SecDir ;=20 > draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > ; avtcore-chairs@ietf.org; avt@ietf.org;=20 > Dave Satterlee (Vocal) ; IETF discussion=20 > list ; draft-ietf-payload-tsvcis.all@ietf.orgygv=20 > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = > (with DISCUSS and COMMENT) >=20 > This is still outstanding, since November. Victor, where are we on = this one? >=20 > Barry >=20 > On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk wrote: > > > > Hi Victor, > > > > On Tue, Nov 19, 2019 at 03:14:21PM -0500, = victor.demjanenko@vocal.com wrote: > > > Hi Ben, > > > > > > Sorry I overlooked sending you a response. I would like to=20 > > > address the two concerns you have by explaining what the speech = coders are doing. > > > > Thanks for the extra clarifications. To supply one of my own: I'm=20 > > not concerned that the protocol doesn't work as implemented, but=20 > > just want to make sure that the document includes enough information = > > to admit new implementations without guesswork. That is to say,=20 > > "either tell me how to do it or tell me where to look that tells me = how to do it". > > > > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit=20 > > > beyond the 54-bit frame for MELP 600 as a frame sync which = alternates between frames. > > > With two or more MELP 600bps frames in one RTP packet, if any=20 > > > frame indicates 600 bps by CODA being 0 and CODB being 1, then we=20 > > > know the stream is 600bps. If there is a single frame in an RTP=20 > > > packet, you can still deduce this by looking at every other RTP=20 > > > packet (every other MELP 600bps > > > frame) and by the timestamp advance. Most likely the two ends=20 > > > would negotiate 600 bps in SDP anyways so there really should not=20 > > > be a problem. I know it's not pretty but its workable. I hope=20 > > > this explanation helps you with the concerns for this issue. > > > > In this case, the use as an "end-to-end framing bit" (i.e., the=20 > > alternating behavior you describe above) is not explicitly stated;=20 > > one might imagine a scheme where the framing usage is to have the=20 > > bit cycle through 1, 1, 0, and 0, or some other scheme. I'd suggest = > > to note in the document that if any instance of (CODA, CODB) =3D=3D = (0,=20 > > 1) is observed, then the 600bps mode is in use. It might also be=20 > > helpful to include the observation that two successive MELPe=20 > > payloads with CODA =3D=3D CODB =3D=3D 0 indicates the 2400bps mode = (and that=20 > > seeing them in a single RTP packet is decisive, whereas additional=20 > > information about packet non-loss would be needed in the=20 > > one-MELPe-frame-per-RTP-packet case), but that would be a fair bit=20 > > of additional text and might be diminishing returns. (Or, of=20 > > course, the use of CODB as an alternating 1/0 bit as the framing=20 > > usage could be documented > > instead.) > > > > > As for the TSVCIS parameter packing/unpacking, this is really=20 > > > simple. There is exactly on three bit parameter, exactly one five = > > > bit parameter and a variable number of eight bit parameters. In=20 > > > our view, the speech coder itself (or a wrapper for it) is=20 > > > responsible for preparing the block of octets. RTP then just=20 > > > transports it. On receive, the complementary wrapper reverses the = packing operation. > > > I hope this clarifies and explains the simplicity. > > > > That's exactly what I expected to happen; however, it's not what I=20 > > believe the current text of the document is describing. =20 > > Specifically, I think that the current text implies that the=20 > > "preparing the block of octets" and "complementary wrapper reverses=20 > > the packing operation" are supposed to be part of the RTP payload=20 > > format that this document describes, but this document does not have = > > enough information to actually perform those operations reversibly. = > > If the packing is to be done in the speech coder, then this document = > > doesn't need to talk about the packing at all (e.g., at the end of=20 > > Section 2); if we need to keep the packing/wrapper in this document=20 > > then we need to indicate that there's a defined priority order for=20 > > the (8-octet) TSVCIS parameters in the TSVCIS references, to allow = the packing/unpacking to be deterministic. > > > > Thanks, > > > > Ben > > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Thursday, October 31, 2019 8:12 PM > > > To: Barry Leiba > > > Cc: victor.demjanenko@vocal.com; Roni Even (A)=20 > > > ; The IESG ; Catherine=20 > > > Meadows ; IETF SecDir=20 > > > ; draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > > > ; avtcore-chairs@ietf.org;=20 > > > avt@ietf.org; Dave Satterlee (Vocal) ;=20 > > > IETF discussion list ;=20 > > > draft-ietf-payload-tsvcis.all@ietf.org > > > Subject: Re: Benjamin Kaduk's Discuss on > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > I don't think so, unfortunately. > > > > > > I do see the clarification about CODB's potential for deviation=20 > > > from Table 1, that only the 600 bps MELPe is allowed to deviate,=20 > > > and that CODA gets us to "it's one of 2400 or 600 bps" and the RTP = > > > timestamp disambiguates that > > > 600 bps is in use. But, it seems that this means that the=20 > > > recipient in general should not rely on CODB to differentiate 600=20 > > > from 2400 bps, and instead is more robustly implemented by=20 > > > *always* using the RTP timestamp to detect 600 bps, since that=20 > > > will always work and CODB will sometimes not work under conditions = > > > not fully specified here. So, if we are unwilling or unable to=20 > > > clarify what those conditions are (e.g., whether at a minimum=20 > > > mutual agreement is required), then I think we need to describe=20 > > > this procedure of consulting the RTP timestamp as the default = behavior and avoid giving the impression that CODB should be used to do = so. > > > > > > Additionally, I don't see anything to address my concern about=20 > > > TSVCIS parameter decoding. To be clear, the procedure I see this=20 > > > document describing is that: > > > - TSVCIS gives parameters (and their lengths in bits) to the codec > > > described in this document > > > - this document specifies how to densely encode those parameters = into a > > > byetstream > > > - RTP transmits that encoded bytestream to the peer > > > - the codec specified by this is responsible for turning that = encoded > > > bystream back into a list of TSVCIS parameters (and their length = > > > in bits) > > > > > > I don't see how that last step is attainable with only the=20 > > > information provided by this document. I *assume* that one of the = > > > TSVCIS specifications has a canonical (ordered) listing of=20 > > > parameters, and that the list of parmeters given to this codec in=20 > > > the first step will always be an initial prefix of that list, but=20 > > > that's just me guessing at how to make sense of the stated=20 > > > procedure given insufficient information. I don't think it's=20 > > > appropriate to make the reader of an RFC guess at what to do; we=20 > > > need to either say how to do it or give a pointer to an external = reference that does. > > > > > > -Ben > > > > > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > > > Ben, does the -04 version address everything? > > > > > > > > Barry > > > > > > > > On Thu, Oct 24, 2019 at 1:42 PM = wrote: > > > > > > > > > > I forgot to address security comments in one email. The = changes are: > > > > > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > This RTP payload format and the TSVCIS decoder do not = exhibit any > > > > > significant non-uniformity in the receiver-side = computational > > > > > complexity for packet processing and thus are unlikely to = pose a > > > > > denial-of-service threat due to the receipt of pathological = data. > > > > > Additionally, the RTP payload format does not contain any = active > > > > > content. > > > > > > > > > > (now) > > > > > This RTP payload format and the TSVCIS decoder, to the best = of our > > > > > knowledge, do not exhibit any significant non-uniformity in = the > > > > > receiver-side computational complexity for packet = processing and thus > > > > > are unlikely to pose a denial-of-service threat due to the = receipt of > > > > > pathological data. Additionally, the RTP payload format = does not > > > > > contain any active content. > > > > > > > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > Please see the security considerations discussed in = [RFC6562] > > > > > regarding VAD and its effect on bitrates. > > > > > > > > > > (now) > > > > > Please see the security considerations discussed in = [RFC6562] > > > > > regarding Voice Activity Detect (VAD) and its effect on = bitrates. > > > > > > > > > > Victor > > > > > > > > > > -----Original Message----- > > > > > From: victor.demjanenko@vocal.com=20 > > > > > > > > > > Sent: Thursday, October 24, 2019 10:05 AM > > > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > > > ; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > ; avtcore-chairs@ietf.org;=20 > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Hi Everyone, > > > > > > > > > > First we want to thank everyone for their review and comments=20 > > > > > for this > > > draft RFC. We believe we reviewed all the comments and=20 > > > suggestions and incorporated them adequately in the next draft=20 > > > (04). We'd like to send out this list of exact changes in case=20 > > > anyone has additional comments or thinks the clarifications are=20 > > > inadequate. We would be most happy to address concerns before = publishing draft 04 tomorrow. > > > > > > > > > > With so many emails from a half dozen or more reviewers, we=20 > > > > > apologize > > > that we cannot address each sender individually. We hope this=20 > > > detail is sufficient for everyone. > > > > > > > > > > Again, many thanks to all. > > > > > > > > > > Victor & Dave > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -------------------------- > > > > > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > > > > > (was) > > > > > Best current practices for writing an RTP payload format > > > > > specification were followed [RFC2736]. > > > > > > > > > > (now) > > > > > Best current practices for writing an RTP payload format > > > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > > > > > (was) > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > > and how they are protected by forward error correction = (FEC) > > > > > techniques (using block codes). At the RTP transport = layer, only the > > > > > speech coder related bits need to be considered and are = conveyed in > > > > > unencrypted form. In most IP-based network deployments, = standard > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link = encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP = speech > > > > > contents. Further, it is desirable to support the highest = voice > > > > > quality between endpoints which is only possible without = the overhead > > > > > of FEC. > > > > > > > > > > TSVCIS augmented speech data is derived from the signal = processing > > > > > and data already performed by the MELPe speech coder. For = the > > > > > purposes of this specification, only the general parameter = nature of > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > > (and FEC requirements), a varying number of TSVCIS specific = speech > > > > > coder parameters need to be transported. These are first = byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > (now) > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > > and how they are protected by forward error correction = (FEC) > > > > > techniques (using block codes). At the RTP transport = layer, only the > > > > > speech-coder-related bits need to be considered and are = conveyed in > > > > > unencrypted form. In most IP-based network deployments, = standard > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link = encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP = speech > > > > > contents. > > > > > > > > > > TSVCIS augmented speech data is derived from the signal = processing > > > > > and data already performed by the MELPe speech coder. For = the > > > > > purposes of this specification, only the general parameter = nature of > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > > (and FEC requirements), a varying number of TSVCIS-specific = speech > > > > > coder parameters need to be transported. These are first = byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by=20 > > > > > reviewer > > > > > > > > > > (was) > > > > > When more than one codec data frame is > > > > > present in a single RTP packet, the timestamp is, as = always, that of > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > (now) > > > > > When more than one codec data frame is > > > > > present in a single RTP packet, the timestamp specified is = that of > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP=20 > > > > > 600 end-to-end framing bit > > > > > > > > > > (was) > > > > > It should be noted that CODB for both the 2400 and 600 bps = modes MAY > > > > > deviate from the values in Table 1 when bit 55 is used as = an end-to- > > > > > end framing bit. Frame decoding would remain distinct as = CODA being > > > > > zero on its own would indicate a 7-byte frame for either = rate and the > > > > > use of 600 bps speech coding could be deduced from the RTP = timestamp > > > > > (and anticipated by the SDP negotiations). > > > > > > > > > > (now) > > > > > It should be noted that CODB for MELPe 600 bps mode MAY = deviate from > > > > > the value in Table 1 when bit 55 is used as an end-to-end = framing > > > > > bit. Frame decoding would remain distinct as CODA being = zero on its > > > > > own would indicate a 7-byte frame for either 2400 or 600 = bps rate and > > > > > the use of 600 bps speech coding could be deduced from the = RTP > > > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by=20 > > > > > reviewers > > > > > > > > > > (was) > > > > > The TSVCIS augmented speech data as packed parameters MUST = be placed > > > > > immediately after a corresponding MELPe 2400 bps payload in = the same > > > > > RTP packet. The packed parameters are counted in octets = (TC). In > > > > > the preferred placement, shown in Figure 6, a single = trailing octet > > > > > SHALL be appended to include a two-bit rate code, CODA and = CODB, > > > > > (both bits set to one) and a six-bit modified count (MTC). = The > > > > > special modified count value of all ones (representing a = MTC value of > > > > > 63) SHALL NOT be used for this format as it is used as the = indicator > > > > > for the alternate packing format shown next. In a standard > > > > > implementation, the TSVCIS speech coder uses a minimum of = 15 octets > > > > > for parameters in octet packed form. The modified count = (MTC) MUST > > > > > be reduced by 15 from the full octet count (TC). Computed = MTC =3D TC- > > > > > 15. This accommodates a maximum of 77 parameter octets = (maximum > > > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > > > > > (now) > > > > > The TSVCIS augmented speech data as packed parameters MUST = be placed > > > > > immediately after a corresponding MELPe 2400 bps payload in = the same > > > > > RTP packet. The packed parameters are counted in octets = (TC). The > > > > > preferred placement SHOULD be used for TSVCIS payloads with = TC less > > > > > than or equal to 77 octets, is shown in Figure 6. In the = preferred > > > > > placement, a single trailing octet SHALL be appended to = include a > > > > > two-bit rate code, CODA and CODB, (both bits set to one) = and a six- > > > > > bit modified count (MTC). The special modified count value = of all > > > > > ones (representing a MTC value of 63) SHALL NOT be used for = this > > > > > format as it is used as the indicator for the alternate = packing > > > > > format shown next. In a standard implementation, the = TSVCIS speech > > > > > coder uses a minimum of 15 octets for parameters in octet = packed > > > > > form. The modified count (MTC) MUST be reduced by 15 from = the full > > > > > octet count (TC). Computed MTC =3D TC-15. This = accommodates a maximum > > > > > of 77 parameter octets (maximum value of MTC is 62, 77 is = the sum of > > > > > 62+15). > > > > > > > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder = frames > > > > > (each consisting of MELPe and TSVCIS coder data) followed = by zero or > > > > > one MELPe comfort noise frame. The presence of a comfort = noise frame > > > > > can be determined by its rate code bits in its last octet. > > > > > > > > > > (now) > > > > > A TSVCIS RTP packet payload consists of zero or more = consecutive > > > > > TSVCIS coder frames (each consisting of MELPe 2400 and = TSVCIS coder > > > > > data), with the oldest frame first, followed by zero or one = MELPe > > > > > comfort noise frame. The presence of a comfort noise frame = can be > > > > > determined by its rate code bits in its last octet. > > > > > > > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by=20 > > > > > reviewers > > > > > > > > > > (was) > > > > > TSVCIS coder frames in a single RTP packet MAY be of = different coder > > > > > bitrates. With the exception for the variable length = TSVCIS > > > > > parameter frames, the coder rate bits in the trailing byte = identify > > > > > the contents and length as per Table 1. > > > > > > > > > > (now) > > > > > TSVCIS coder frames in a single RTP packet MAY have varying = TSVCIS > > > > > parameter octet counts. Its packed parameter octet count = (length) is > > > > > indicated in the trailing byte(s). All MELPe frames in a = single RTP > > > > > packet MUST be of the same coder bitrate. For all MELPe = coder > > > > > frames, the coder rate bits in the trailing byte identify = the > > > > > contents and length as per Table 1. > > > > > > > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > > > > > > > Section 4.1 - Change controller is now > > > > > > > > > > (now) > > > > > Change controller: IETF, contact > > > > > > > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > > > > > (was) > > > > > A primary application of TSVCIS is for radio communications = of voice > > > > > conversations, and discontinuous transmissions are normal. = When > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet = transmissions may > > > > > cease and resume frequently. RTP synchronization source = (SSRC) > > > > > sequence number gaps indicate lost packets to be filled by = PLC, while > > > > > abrupt loss of RTP packets indicates intended discontinuous > > > > > transmissions. > > > > > > > > > > (now) > > > > > A primary application of TSVCIS is for radio communications = of voice > > > > > conversations, and discontinuous transmissions are normal. = When > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet = transmissions may > > > > > cease and resume frequently. RTP synchronization source = (SSRC) > > > > > sequence number gaps indicate lost packets to be filled by = Packet > > > > > Loss Concealment (PLC), while abrupt loss of RTP packets = indicates > > > > > intended discontinuous transmissions. Resumption of voice > > > > > transmission SHOULD be indicated by the RTP marker bit (M) = set to 1. > > > > > > > > > > > > > > > Section 10 - Added reference > > > > > > > > > > (added) > > > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload = Format", > > > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > > > . > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > ----------------------------- > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Roni Even (A) > > > > > Sent: Sunday, October 6, 2019 2:09 AM > > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk'=20 > > > > > ; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > ; avtcore-chairs@ietf.org;=20 > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Hi, > > > > > About the reference to TSVCIS. > > > > > The RTP payload is about how to encapsulate the payload in an=20 > > > > > RTP > > > packet. The objective is to define how an RTP stack can insert the = > > > tsvcis frames and extract the tsvcis frames from the RTP packet. > > > Typically it is not required to understand the payload structure=20 > > > in order to be able to perform the encapsulation. > > > > > This is why the reference to the payload is Informational and=20 > > > > > we did not require to have it publically available. If there=20 > > > > > is a need to understand the payload itself for the=20 > > > > > encapsulating than we need more information in the RTP payload = > > > > > specification and a publically available normative reference.=20 > > > > > I think this is not the case here > > > > > > > > > > Roni Even > > > > > > > > > > AVTCore co-chair (ex Payload) > > > > > > > > > > -----Original Message----- > > > > > From: victor.demjanenko@vocal.com=20 > > > > > [mailto:victor.demjanenko@vocal.com] > > > > > Sent: Saturday, October 05, 2019 12:18 AM > > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; = > > > 'Dave Satterlee (Vocal)' > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Everyone, > > > > > > > > > > Thanks for the comments. I think I mis-understood the=20 > > > > > ambiguity with > > > respect to to changing rates within a RTP packet. That was not=20 > > > plan. An RTP packet must have MELP speech frames of the same = rate. > > > What is possible is that the amount of augmented TSVCIS speech=20 > > > data may vary from one speech frame to the next. This allows for=20 > > > a dynamic VDR as suggested by the NRL paper. So an RTP packet may = > > > have varying TSVCIS data but must always have MELPe 2400 data. > > > > > > > > > > Again backwards parsing is necessary but the timestamp=20 > > > > > uniformly > > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > > > > > The NRL is a good public reference on the VDR aspects. The=20 > > > > > actual > > > TSVCIS spec we had was FOUO so we could not replicate its detail. = > > > (I believe a later spec is public or at least partially public. I = > > > am trying to get this.) The opaque data is pretty obvious with = the TSVCIS spec in hand. > > > > > > > > > > We will address the issues/concerns raised next week. Other=20 > > > > > business > > > had priority. > > > > > > > > > > Thank you and enjoy the weekend. > > > > > > > > > > Regards, > > > > > > > > > > Victor & Dave > > > > > > > > > > -----Original Message----- > > > > > From: Benjamin Kaduk via Datatracker > > > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > > > To: The IESG > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > > > > > ; avtcore-chairs@ietf.org;=20 > > > > > ali.begen@networked.media; avt@ietf.org > > > > > Subject: Benjamin Kaduk's Discuss on = draft-ietf-payload-tsvcis-03: > > > > > (with DISCUSS and COMMENT) > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-payload-tsvcis-03: Discuss > > > > > > > > > > When responding, please keep the subject line intact and reply = > > > > > to all email addresses included in the To and CC lines. (Feel=20 > > > > > free to cut this introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found = here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > DISCUSS: > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > > > > > > I support Magnus' point about the time-ordering of adjacent=20 > > > > > frames in a > > > packet. > > > > > > > > > > Additionally, I am not sure that there's quite enough here to=20 > > > > > be > > > interoperably implementable. Specifically, we seem to be lacking=20 > > > a description of how an encoder or decoder knows which TSVCIS=20 > > > parameters, and in what order, to byte-pack or unpack, = respectively. > > > One might surmise that there is a canonical listing in [TSVCIS],=20 > > > but this document does not say that, and furthermore [TSVCIS] is = only listed as an informative reference. > > > (I couldn't get my hands on my copy, at least on short notice.) =20 > > > If we limited ourselves to treating the TSVCIS parameters as an=20 > > > entirely opaque blob (codec, convey these N octets to the peer=20 > > > with the appropriate one- or two-byte trailer for payload type=20 > > > identification and framing), that would be interoperably=20 > > > implementable, since the black-box bits are up to some other codec = to interpret. > > > > > > > > > > In a similar vein, we mention but do not completely specify=20 > > > > > the > > > potential for using CODB as an end-to-end framing bit, in Section > > > 3.1 (see Comment), which is not interoperably implementable = without further details. > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > COMMENT: > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > > > > > > Where is [TSVCIS] available? > > > > > > > > > > Is [NRLVDR] the same as > > > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL = > > > > > in the > > > references would be helpful. > > > > > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and = > > > > > the first > > > thing to get dropped under bandwidth pressure? The abstract and=20 > > > introduction imply this by calling out MELPe 2400 bps speech=20 > > > parameters explicitly, but Section 3 says that TSVCIS augments=20 > > > standard 600, 1200, and > > > 2400 bps MELP frames. > > > > > > > > > > It's helpful that Section 3.3 gives some general guidance for=20 > > > > > decoding > > > this payload type ("[t]he way to determine the number of=20 > > > TSVCIS/MELPe frames is to identify each frame type and length"),=20 > > > but I think some generic considerations would be very helpful to=20 > > > the reader much earlier, along the lines of "MELPe and TSVCIS data = > > > payloads are decoded from the end, using the CODA and CODB (and,=20 > > > if necessary, CODC and others) bits to determine the type of = payload. > > > For MELPe payloads the type also indicates the payload length,=20 > > > whereas for TSVCIS data an additional length field is present, in=20 > > > one of two possible formats. A TSVCIS coder frame consists of a=20 > > > MELPe data payload followed by zero or one TSVCIS data payload;=20 > > > after the TSVCIS payload's presence/length is determined, then the = > > > preceding MELPe payload can be determined and decoded. Per=20 > > > Section 3.3, multiple TSVCIS frames can be present in a single RTP = packet." > > > This (or something like it) would also serve to clarify the role = of the COD* bits, which is otherwise only implicitly introduced. > > > > > > > > > > Section 1.1 > > > > > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for=20 > > > > > some > > > reason an Informational document and not part of BCP 36?!). > > > > > > > > > > Section 2 > > > > > > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > > and how they are protected by forward error correction = (FEC) > > > > > techniques (using block codes). At the RTP transport = layer, only the > > > > > speech coder related bits need to be considered and are = conveyed in > > > > > unencrypted form. In most IP-based network deployments,=20 > > > > > standard > > > > > > > > > > Am I reading this correctly that this text is just summarizing = > > > > > what's in > > > the TSVCIS spec in terms of what needs to be in unencrypted form,=20 > > > so the "only the speech coder related bits[...]" is not new=20 > > > information from this document? I'm not sure I agree with the=20 > > > conclusion, regardless -- won't the > > > (MELPe) speech coder bits be enough to convey the semantic content = > > > of the audio stream, something that one might desire to keep = confidential? > > > > > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link = encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP = speech > > > > > contents. Further, it is desirable to support the highest = voice > > > > > quality between endpoints which is only possible without = the overhead > > > > > of FEC. > > > > > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > > (and FEC requirements), a varying number of TSVCIS specific = speech > > > > > coder parameters need to be transported. These are first = byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > Per the Discuss point, how do I know which parameters need to=20 > > > > > be > > > transported, and in what order? > > > > > > > > > > Byte packing of TSVCIS speech data into packed parameters = is > > > > > processed as per the following example: > > > > > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is > > > > > LSB) > > > > > > > > > > MSB = LSB > > > > > 0 1 2 3 4 5 6 7 > > > > > = +------+------+------+------+------+------+------+------+ > > > > > | H | G | F | E | D | C | B | A = | > > > > > =20 > > > > > +------+------+------+------+------+------+------+------+ > > > > > > > > > > This packing method places the three-bit field "first" in = the lowest > > > > > bits followed by the next five-bit field. Parameters may = be split > > > > > between octets with the most significant bits in the = earlier octet. > > > > > Any unfilled bits in the last octet MUST be filled with = zero. > > > > > > > > > > I agree with Adam that this is very unclear. A is the MSB of=20 > > > > > the > > > three-bit field but the LSB of the octet overall? > > > > > We probably need an example of splitting a parameter across=20 > > > > > octets as > > > well, to get the bit ordering right. > > > > > > > > > > Section 3.1 > > > > > > > > > > It should be noted that CODB for both the 2400 and 600 bps = modes MAY > > > > > deviate from the values in Table 1 when bit 55 is used as = an end-to- > > > > > end framing bit. Frame decoding would remain distinct as=20 > > > > > CODA being > > > > > > > > > > Where is the use of CODB as an end-to-end framing bit defined? = =20 > > > > > If we're > > > going to provide neither a complete description of how to do it=20 > > > nor a reference to a better description, we probably shouldn't = mention it at all. > > > > > > > > > > Section 3.2 > > > > > > > > > > RTP packet. The packed parameters are counted in octets = (TC). In > > > > > the preferred placement, shown in Figure 6, a single = trailing octet > > > > > SHALL be appended to include a two-bit rate code, CODA and=20 > > > > > CODB, > > > > > > > > > > I'd consider saying something about this being the preferred=20 > > > > > format > > > > > ("placement") due to its shorter length than the alternative,=20 > > > > > and say > > > that it "SHOULD be used for TSVCIS payloads with TC less than or=20 > > > equal to 77 octetes". > > > > > > > > > > Section 3.3 > > > > > > > > > > When a longer packetization interval is used, is that=20 > > > > > indicated by > > > signaling or RTP timestamps or otherwise? > > > > > > > > > > TSVCIS coder frames in a single RTP packet MAY be of = different coder > > > > > bitrates. With the exception for the variable length = TSVCIS > > > > > parameter frames, the coder rate bits in the trailing byte = identify > > > > > the contents and length as per Table 1. > > > > > > > > > > Maybe also note that the penultimate octet gives the length = there? > > > > > > > > > > Information describing the number of frames contained in an = RTP > > > > > packet is not transmitted as part of the RTP payload. The = way to > > > > > determine the number of TSVCIS/MELPe frames is to identify = each frame > > > > > type and length thereby counting the total number of octets = within > > > > > the RTP packet. > > > > > > > > > > terminology nit: if a frame is the combination of MELPe and=20 > > > > > TSVCIS > > > payload data units then there are two layres of decoding to get a=20 > > > length for the frame, since we have to get the TSVCIS length and = then the MELPe length. > > > > > > > > > > Section 4.2 > > > > > > > > > > Parameter "ptime" cannot be used for the purpose of=20 > > > > > specifying the > > > > > > > > > > nit: missing article ("The parameter") > > > > > > > > > > will be impossible to distinguish which mode is about to be = used > > > > > (e.g., when ptime=3D68, it would be impossible to = distinguish if the > > > > > packet is carrying one frame of 67.5 ms or three frames of = 22.5 ms). > > > > > > > > > > So how is the operating mode determined, then? > > > > > (I think this is the same question I asked above) > > > > > > > > > > Section 4.4 > > > > > > > > > > For example, if offerer bitrates are "2400,600" and answer = bitrates > > > > > are "600,2400", the initial bitrate is 600. If other = bitrates are > > > > > provided by the answerer, any common bitrate between the = offer and > > > > > answer MAY be used at any time in the future. Activation = of these > > > > > other common bitrates is beyond the scope of this document. > > > > > > > > > > It seems important to specify whether this requires a new O/A=20 > > > > > exchange > > > or can be done "spontaneously" by just encoding different frame = types. > > > > > (It seems like the latter is possible, on first glance, and=20 > > > > > this is implied by Section 3.3's discussion of mixing them in=20 > > > > > a single > > > > > packet.) > > > > > > > > > > Section 5 > > > > > > > > > > Please expand PLC at first use (not second). > > > > > > > > > > Section 6 > > > > > > > > > > I don't understand the PLC usage. Is the idea that a=20 > > > > > receiver, on > > > seeing an SSRC gap, constructs fictitious PLC frames to "fill the = gap" > > > > > and passes the resulting stream to the decoder? > > > > > > > > > > Section 8 > > > > > > > > > > and important considerations in [RFC7201]. Applications = SHOULD use > > > > > one or more appropriate strong security mechanisms. The = rest of this > > > > > section discusses the security-impacting properties of the = payload > > > > > format itself. > > > > > > > > > > I thought we described TSVCIS itself (much earlier in the > > > > > document) as > > > requiring encryption for some data; wouldn't that translate to a = "MUST" > > > > > here and not a "SHOULD"? > > > > > > > > > > > > > > > > > > > =20 ------=_NextPart_001_002D_01D60D9B.9E56D0F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT)

Hi = Ben,

With this = social distancing situation, I'm finally catching up on open = items myself.  I have made the changes as we have discussed and = incorporated your = suggestions.  I believe the changes are fully contained in the two = paragraphs below:

Section 2 (last = paragraph) - Clarification for octet count

(was)

In order to = accommodate a varying amount of TSVCIS augmented = speech

data, it = is only necessary to specify the number of octets

containing = the packed TSVCIS parameters.  The encoding to do so = is

presented in = Section 3.2.  TSVCIS specifically uses the NRL VDR in = two

configurations = using 15 = and 35 packed octet parameters [TSVCIS].  =

(now)

In order to = accommodate a varying amount of TSVCIS augmented = speech

data, an = octet count specifies the number of octets = representing

the packed = TSVCIS parameters.  The encoding to do so is presented = in

Section = 3.2.  TSVCIS specifically uses the NRL VDR in two

configurations = using a = fixed set of 15 and 35 packed octet

parameters = in a standardized order [TSVCIS].  =


Section 3.1 = (first sentence in last paragraph) - Clarification for CODA, = CODB

(was)

It should be = noted that CODB for MELPe 600 bps mode MAY deviate = from

the value in = Table 1 when bit 55 is used as an end-to-end framing = bit.

(now)

It should be = noted that CODB for MELPe 600 bps mode MAY deviate = from

the value in = Table 1 when bit 55 is used as an alternating = 1/0

end-to-end = framing bit. 

Ben, I believe = this addresses your comments and requests for clarifications as per our = email discussion chain below.

Thanks for you = comments and with your concurrence (and my home computer's cooperation), = I will post a new draft hopefully acceptable for final = approval.

Regards to all = and stay on = the good side of Darwin.

Victor


-----Original = Message-----

From: Benjamin = Kaduk <kaduk@mit.edu>

Sent: Friday, = February 14, 2020 2:43 PM

To: = victor.demjanenko@vocal.com; 'Barry Leiba' = <barryleiba@computer.org>

Cc: 'Roni Even = (A)' <roni.even@huawei.com>; 'The IESG' <iesg@ietf.org>; = 'Catherine Meadows' <catherine.meadows@nrl.navy.mil>; 'IETF = SecDir' <secdir@ietf.org>; draft-ietf-payload-tsvcis@ietf.org; = 'Ali Begen' <ali.begen@networked.media>; avtcore-chairs@ietf.org; = avt@ietf.org; 'Dave Satterlee (Vocal)' <Dave.Satterlee@vocal.com>; = 'IETF discussion list' <ietf@ietf.org>; = draft-ietf-payload-tsvcis.all@ietf.org

Subject: Re: = Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS = and COMMENT)

Hi = Barry,

As Victor = notes, this one was/is waiting on me; he did reply (offlist) = on

15 January but = I seem to have missed it amid a deluge of other mail that arrived at = that time.  Thanks for the reminder, and thanks Victor for = re-sending the comments.

(inline)

On Fri, Feb 14, = 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com = wrote:

> HI = Barry,

> =

> Thanks for = recalling this was still outstanding.  I had emailed Ben just after = the holidays and did not realize we had no response.  The below is = what we suggested to Ben to address concerns he = raised.

> =

> = --------------------

> Hi = Ben,

> =

> Hope your = holidays were good.  Our were both good and busy.  Deliveries = for two NASA projects and the holidays kept us from responding = sooner.  But we do want to get this draft = completed.

> =

> With your = permission, I=E2=80=99d like to address your comments directly, resolve = what changes we should make and then publish a new version with a = summary of our out-of-band discussions.  We don=E2=80=99t have a = lot of experience with drafting such documents and would like to know = exactly what is needed to make this draft acceptable.

> =

> I believe = there are two comments/issues to address:

> =

> = 1)    CODA, CODB

> =

> Your = comment ends by stating:  =E2=80=9C(Or, of course, the use of CODB = as an alternating 1/0 bit as the framing usage could be documented = instead.)=E2=80=9D  We can do this as follows:

> =

> = (original)

> It should = be noted that CODB for MELPe 600 bps mode MAY deviate = from

>    the value in Table 1 when bit 55 = is used as an end-to-end framing

>    bit. Frame decoding would remain = distinct as CODA being zero on its

>    own would indicate a 7-byte = frame for either 2400 or 600 bps rate and

>    the use of 600 bps speech coding = could be deduced from the RTP

>    timestamp (and anticipated by = the SDP negotiations).

> =

> (adding = =E2=80=9Calternating 1/0=E2=80=9D)

> It should = be noted that CODB for MELPe 600 bps mode MAY deviate = from

>    the value in Table 1 when bit 55 = is used as an alternating 1/0 end-to-end framing

>    bit. Frame decoding would remain = distinct as CODA being zero on its

>    own would indicate a 7-byte = frame for either 2400 or 600 bps rate and

>    the use of 600 bps speech coding = could be deduced from the RTP

>    timestamp (and anticipated by = the SDP negotiations).

> =

> I think = this change would be sufficient to address your concern about what to = expect for CODB.

This looks like = the minimal sufficient change, yes.  (I use = "minimal"

because I would = say more if I was writing it, but I don't think I can insist that you = write it the way I would -- it's your document after = all!)

> = 2.    Packing and unpacking

> =

> You are = correct that I am trying to vaguely describe a middle layer shim that is = neither RTP nor speech coder.  So it definitely does need to be = clear.  The vagueness comes from the speech coder description being = a FOUO document.  Its now unclassified so I can potentially say = more (and I did make some enhancements of the parameter description = already). 

> =

> So I am = trying to understand exactly what you think is vague in our current = description:

> =

> TSVCIS = augmented speech data is derived from the signal = processing

>    and data already performed by = the MELPe speech coder.  For the

>    purposes of this specification, = only the general parameter nature of

>    TSVCIS will be = characterized.  Depending on the bandwidth = available

>    (and FEC requirements), a = varying number of TSVCIS-specific speech

>    coder parameters need to be = transported.  These are first byte-packed

>    and then conveyed from encoder = to decoder.

> =

>    Byte packing of TSVCIS speech = data into packed parameters is

>    processed as per the following = example:

> =

>       Three-bit = field: bits A, B, and C (A is MSB, C is LSB)

>       Five-bit = field: bits D, E, F, G, and H (D is MSB, H is LSB)

> =

>        &nbs= p;   = MSB           &nbs= p;            = ;            =           = LSB

>        &nbs= p;    0      = 1      2      = 3      4      = 5      6      = 7

>         = +------+------+------+------+------+------+------+------+

>         = |   H  |   G  |   F  = |   E  |   D  |   C  = |   B  |   A  |

>         = +------+------+------+------+------+------+------+------+

> =

>    This packing method places the = three-bit field "first" in the lowest

>    bits followed by the next = five-bit field.  Parameters may be split

>    between octets with the most = significant bits in the earlier octet.

>    Any unfilled bits in the last = octet MUST be filled with zero.

[not actually = relevant to the Discuss part, but if there is always exactly one 3-bit = parameter and one 5-bit parameter, then this text allowing splitting = across octets will never be used and is potentially confusing to = mention.]

>    In order to accommodate a = varying amount of TSVCIS augmented speech

>    data, it is only necessary to = specify the number of octets containing

>    the packed TSVCIS = parameters.  The encoding to do so is presented

> = in

I think the = "only necessary to specify the number of octets" is the key = stumbling point, for me -- I need to know the number of octets as well = as the order of the parameters within the list, which is more = information than just the number of octets.

>    Section 3.2.  TSVCIS = specifically uses the NRL VDR in two

>    configurations using 15 and 35 = packed octet parameters [TSVCIS]. 

I think I = failed to internalize the "two configurations using 15 and 35 = packed octet parameters" the first time I read the document, as = this does help give the reader a clue that [TSVCIS] gives a good picture = of what parameters go where.  So it seems like we could easily = append to that, for "using a fixed set of 15 and 35 packed octet = parameters in a fixed order [TSVCIS]" and that would resolve my = concerns.

> The speech = coder description of the parameters is the following:

> =

>  =

> =

> So the = three bit pitch is first (bits 56 to 58), followed by a five bit = amplitude (bits 59 to 63) and then an array of spectral components, each = 8-bit wide (starting at bit 64).

[And maybe = TSVCIS specifes that the spectral components are derived from some = fundamental harmonic decomposition that naturally quantizes to a = number-of-parameters/accuracy tradeoff with a natural order.  If = so, we could also rely on that instead of my proposed change above; let = me know if you want to explore that path further.]

> Based on = this information, I=E2=80=99m not sure what we should add to our =

> draft to = make the description of packing/unpacking clearer.  Can you =

> make any = suggestions or does this table help you with what you did not =

> = know?  (I don=E2=80=99t think I should put this table into the = draft RFC

> = however.)

Hopefully the = above helps to clarify.

Thanks, and = sorry for the delay.

-Ben

> Thanks for = your attention and comments.

> =

> Victor = & Dave

> =

> =

> =

> = -----Original Message-----

> From: = Barry Leiba <barryleiba@computer.org>

> Sent: = Friday, February 14, 2020 7:38 AM

> To: = Benjamin Kaduk <kaduk@mit.edu>

> Cc: = victor.demjanenko@vocal.com; Roni Even (A) <roni.even@huawei.com>; =

> The IESG = <iesg@ietf.org>; Catherine Meadows

> = <catherine.meadows@nrl.navy.mil>; IETF SecDir = <secdir@ietf.org>;

> = draft-ietf-payload-tsvcis@ietf.org; Ali Begen

> = <ali.begen@networked.media>; avtcore-chairs@ietf.org; = avt@ietf.org;

> Dave = Satterlee (Vocal) <Dave.Satterlee@vocal.com>; IETF discussion =

> list = <ietf@ietf.org>;  draft-ietf-payload-tsvcis.all@ietf.orgygv =

> Subject: = Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: =

> (with = DISCUSS and COMMENT)

> =

> This is = still outstanding, since November.  Victor, where are we on this = one?

> =

> = Barry

> =

> On Mon, = Nov 25, 2019 at 1:46 AM Benjamin Kaduk <kaduk@mit.edu> = wrote:

> = >

> > Hi = Victor,

> = >

> > On = Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com = wrote:

> > > = Hi Ben,

> > = >

> > > = Sorry I overlooked sending you a response.  I would like to =

> > > = address the two concerns you have by explaining what the speech coders = are doing.

> = >

> > = Thanks for the extra clarifications.  To supply one of my own: I'm =

> > not = concerned that the protocol doesn't work as implemented, but =

> > just = want to make sure that the document includes enough information =

> > to = admit new implementations without guesswork.  That is to say, =

> > = "either tell me how to do it or tell me where to look that tells me = how to do it".

> = >

> > > = WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit =

> > > = beyond the 54-bit frame for MELP 600 as a frame sync which alternates = between frames.

> > > = With two or more MELP 600bps frames in one RTP packet, if any =

> > > = frame indicates 600 bps by CODA being 0 and CODB being 1, then we =

> > > = know the stream is 600bps.  If there is a single frame in an RTP =

> > > = packet, you can still deduce this by looking at every other RTP =

> > > = packet (every other MELP 600bps

> > > = frame) and by the timestamp advance.  Most likely the two ends =

> > > = would negotiate 600 bps in SDP anyways so there really should not =

> > > = be a problem.  I know it's not pretty but its workable.  I = hope

> > > = this explanation helps you with the concerns for this = issue.

> = >

> > In = this case, the use as an "end-to-end framing bit" (i.e., the =

> > = alternating behavior you describe above) is not explicitly stated; =

> > one = might imagine a scheme where the framing usage is to have the =

> > bit = cycle through 1, 1, 0, and 0, or some other scheme.  I'd suggest =

> > to = note in the document that if any instance of (CODA, CODB) =3D=3D (0, =

> > 1) is = observed, then the 600bps mode is in use.  It might also be =

> > = helpful to include the observation that two successive MELPe =

> > = payloads with CODA =3D=3D CODB =3D=3D 0 indicates the 2400bps mode (and = that

> > = seeing them in a single RTP packet is decisive, whereas additional =

> > = information about packet non-loss would be needed in the =

> > = one-MELPe-frame-per-RTP-packet case), but that would be a fair bit =

> > of = additional text and might be diminishing returns.  (Or, of =

> > = course, the use of CODB as an alternating 1/0 bit as the framing =

> > usage = could be documented

> > = instead.)

> = >

> > > = As for the TSVCIS parameter packing/unpacking, this is really =

> > > = simple.  There is exactly on three bit parameter, exactly one five =

> > > = bit parameter and a variable number of eight bit parameters.  In =

> > > = our view, the speech coder itself (or a wrapper for it) is =

> > > = responsible for preparing the block of octets.  RTP then just =

> > > = transports it.  On receive, the complementary wrapper reverses the = packing operation.

> > > = I hope this clarifies and explains the simplicity.

> = >

> > = That's exactly what I expected to happen; however, it's not what I =

> > = believe the current text of the document is describing.  =

> > = Specifically, I think that the current text implies that the =

> > = "preparing the block of octets" and "complementary = wrapper reverses

> > the = packing operation" are supposed to be part of the RTP payload =

> > = format that this document describes, but this document does not have =

> > = enough information to actually perform those operations = reversibly. 

> > If = the packing is to be done in the speech coder, then this document =

> > = doesn't need to talk about the packing at all (e.g., at the end of =

> > = Section 2); if we need to keep the packing/wrapper in this document =

> > then = we need to indicate that there's a defined priority order for =

> > the = (8-octet) TSVCIS parameters in the TSVCIS references, to allow the = packing/unpacking to be deterministic.

> = >

> > = Thanks,

> = >

> > = Ben

> = >

> > = >

> > > = -----Original Message-----

> > > = From: Benjamin Kaduk <kaduk@mit.edu>

> > > = Sent: Thursday, October 31, 2019 8:12 PM

> > > = To: Barry Leiba <barryleiba@computer.org>

> > > = Cc: victor.demjanenko@vocal.com; Roni Even (A)

> > > = <roni.even@huawei.com>; The IESG <iesg@ietf.org>; Catherine =

> > > = Meadows <catherine.meadows@nrl.navy.mil>; IETF SecDir =

> > > = <secdir@ietf.org>; draft-ietf-payload-tsvcis@ietf.org; Ali Begen =

> > > = <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

> > > = avt@ietf.org; Dave Satterlee (Vocal) <Dave.Satterlee@vocal.com>; =

> > > = IETF discussion list <ietf@ietf.org>;

> > > = draft-ietf-payload-tsvcis.all@ietf.org

> > > = Subject: Re: Benjamin Kaduk's Discuss on

> > > = draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

> > = >

> > > = I don't think so, unfortunately.

> > = >

> > > = I do see the clarification about CODB's potential for deviation =

> > > = from Table 1, that only the 600 bps MELPe is allowed to deviate, =

> > > = and that CODA gets us to "it's one of 2400 or 600 bps" and the = RTP

> > > = timestamp disambiguates that

> > > = 600 bps is in use.  But, it seems that this means that the =

> > > = recipient in general should not rely on CODB to differentiate 600 =

> > > = from 2400 bps, and instead is more robustly implemented by =

> > > = *always* using the RTP timestamp to detect 600 bps, since that =

> > > = will always work and CODB will sometimes not work under conditions =

> > > = not fully specified here.  So, if we are unwilling or unable to =

> > > = clarify what those conditions are (e.g., whether at a minimum =

> > > = mutual agreement is required), then I think we need to describe =

> > > = this procedure of consulting the RTP timestamp as the default behavior = and avoid giving the impression that CODB should be used to do = so.

> > = >

> > > = Additionally, I don't see anything to address my concern about =

> > > = TSVCIS parameter decoding.  To be clear, the procedure I see this =

> > > = document describing is that:

> > > = - TSVCIS gives parameters (and their lengths in bits) to the = codec

> > = >   described in this document

> > > = - this document specifies how to densely encode those parameters into = a

> > = >   byetstream

> > > = - RTP transmits that encoded bytestream to the peer

> > > = - the codec specified by this is responsible for turning that = encoded

> > = >   bystream back into a list of TSVCIS parameters (and = their length

> > > = in bits)

> > = >

> > > = I don't see how that last step is attainable with only the =

> > > = information provided by this document.  I *assume* that one of the =

> > > = TSVCIS specifications has a canonical (ordered) listing of =

> > > = parameters, and that the list of parmeters given to this codec in =

> > > = the first step will always be an initial prefix of that list, but =

> > > = that's just me guessing at how to make sense of the stated =

> > > = procedure given insufficient information.  I don't think it's =

> > > = appropriate to make the reader of an RFC guess at what to do; we =

> > > = need to either say how to do it or give a pointer to an external = reference that does.

> > = >

> > > = -Ben

> > = >

> > > = On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba = wrote:

> > > = > Ben, does the -04 version address everything?

> > > = >

> > > = > Barry

> > > = >

> > > = > On Thu, Oct 24, 2019 at 1:42 PM <victor.demjanenko@vocal.com> = wrote:

> > > = > >

> > > = > > I forgot to address security comments in one email.  The = changes are:

> > > = > >

> > > = > > Section 8, second paragraph - Suggested edit by = reviewer

> > > = > >

> > > = > > (was)

> > > = > >    This RTP payload format and the TSVCIS = decoder do not exhibit any

> > > = > >    significant non-uniformity in the = receiver-side computational

> > > = > >    complexity for packet processing and thus = are unlikely to pose a

> > > = > >    denial-of-service threat due to the receipt = of pathological data.

> > > = > >    Additionally, the RTP payload format does = not contain any active

> > > = > >    content.

> > > = > >

> > > = > > (now)

> > > = > >    This RTP payload format and the TSVCIS = decoder, to the best of our

> > > = > >    knowledge, do not exhibit any significant = non-uniformity in the

> > > = > >    receiver-side computational complexity for = packet processing and thus

> > > = > >    are unlikely to pose a denial-of-service = threat due to the receipt of

> > > = > >    pathological data. Additionally, the RTP = payload format does not

> > > = > >    contain any active = content.

> > > = > >

> > > = > >

> > > = > > Section 8, third paragraph - Suggested edit by = reviewer

> > > = > >

> > > = > > (was)

> > > = > >    Please see the security considerations = discussed in [RFC6562]

> > > = > >    regarding VAD and its effect on = bitrates.

> > > = > >

> > > = > > (now)

> > > = > >    Please see the security considerations = discussed in [RFC6562]

> > > = > >    regarding Voice Activity Detect (VAD) and = its effect on bitrates.

> > > = > >

> > > = > > Victor

> > > = > >

> > > = > > -----Original Message-----

> > > = > > From: victor.demjanenko@vocal.com

> > > = > > <victor.demjanenko@vocal.com>

> > > = > > Sent: Thursday, October 24, 2019 10:05 AM

> > > = > > To: 'Roni Even (A)' <roni.even@huawei.com>; 'Benjamin = Kaduk'

> > > = > > <kaduk@mit.edu>; 'The IESG' = <iesg@ietf.org>

> > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen'

> > > = > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

> > > = > > avt@ietf.org; 'Dave Satterlee (Vocal)'

> > > = > > <Dave.Satterlee@vocal.com>

> > > = > > Subject: RE: Benjamin Kaduk's Discuss on

> > > = > > draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

> > > = > >

> > > = > > Hi Everyone,

> > > = > >

> > > = > > First we want to thank everyone for their review and comments =

> > > = > > for this

> > > = draft RFC.  We believe we reviewed all the comments and =

> > > = suggestions and incorporated them adequately in the next draft =

> > > = (04).  We'd like to send out this list of exact changes in case =

> > > = anyone has additional comments or thinks the clarifications are =

> > > = inadequate.  We would be most happy to address concerns before = publishing draft 04 tomorrow.

> > > = > >

> > > = > > With so many emails from a half dozen or more reviewers, we =

> > > = > > apologize

> > > = that we cannot address each sender individually.  We hope this =

> > > = detail is sufficient for everyone.

> > > = > >

> > > = > > Again, many thanks to all.

> > > = > >

> > > = > > Victor & Dave

> > > = > >

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --------------------------

> > > = > >

> > > = > > Section 1.1 - Suggested reference to RFC 8088 = added.

> > > = > >

> > > = > > (was)

> > > = > >    Best current practices for writing an RTP = payload format

> > > = > >    specification were followed = [RFC2736].

> > > = > >

> > > = > > (now)

> > > = > >    Best current practices for writing an RTP = payload format

> > > = > >    specification were followed [RFC2736] = [RFC8088].

> > > = > >

> > > = > >

> > > = > > Section 2, paragraphs 3 and 4 - Suggested edits by = reviewers

> > > = > >

> > > = > > (was)

> > > = > >    In addition to the augmented speech data, = the TSVCIS specification

> > > = > >    identifies which speech coder and framing = bits are to be encrypted,

> > > = > >    and how they are protected by forward error = correction (FEC)

> > > = > >    techniques (using block codes).  At the = RTP transport layer, only the

> > > = > >    speech coder related bits need to be = considered and are conveyed in

> > > = > >    unencrypted form.  In most IP-based = network deployments, standard

> > > = > >    link encryption methods (SRTP, VPNs, FIPS = 140 link encryptors or Type

> > > = > >    1 Ethernet encryptors) would be used to = secure the RTP speech

> > > = > >    contents.  Further, it is desirable to = support the highest voice

> > > = > >    quality between endpoints which is only = possible without the overhead

> > > = > >    of FEC.

> > > = > >

> > > = > >    TSVCIS augmented speech data is derived from = the signal processing

> > > = > >    and data already performed by the MELPe = speech coder.  For the

> > > = > >    purposes of this specification, only the = general parameter nature of

> > > = > >    TSVCIS will be characterized.  = Depending on the bandwidth available

> > > = > >    (and FEC requirements), a varying number of = TSVCIS specific speech

> > > = > >    coder parameters need to be = transported.  These are first byte-packed

> > > = > >    and then conveyed from encoder to = decoder.

> > > = > >

> > > = > > (now)

> > > = > >    In addition to the augmented speech data, = the TSVCIS specification

> > > = > >    identifies which speech coder and framing = bits are to be encrypted,

> > > = > >    and how they are protected by forward error = correction (FEC)

> > > = > >    techniques (using block codes).  At the = RTP transport layer, only the

> > > = > >    speech-coder-related bits need to be = considered and are conveyed in

> > > = > >    unencrypted form.  In most IP-based = network deployments, standard

> > > = > >    link encryption methods (SRTP, VPNs, FIPS = 140 link encryptors or Type

> > > = > >    1 Ethernet encryptors) would be used to = secure the RTP speech

> > > = > >    contents.

> > > = > >

> > > = > >    TSVCIS augmented speech data is derived from = the signal processing

> > > = > >    and data already performed by the MELPe = speech coder.  For the

> > > = > >    purposes of this specification, only the = general parameter nature of

> > > = > >    TSVCIS will be characterized.  = Depending on the bandwidth available

> > > = > >    (and FEC requirements), a varying number of = TSVCIS-specific speech

> > > = > >    coder parameters need to be = transported.  These are first byte-packed

> > > = > >    and then conveyed from encoder to = decoder.

> > > = > >

> > > = > >

> > > = > > Section 3, last sentence paragraph 3 - Suggested edit by =

> > > = > > reviewer

> > > = > >

> > > = > > (was)

> > > = > >    When more than one codec data frame = is

> > > = > >    present in a single RTP packet, the = timestamp is, as always, that of

> > > = > >    the oldest data frame represented in the RTP = packet.

> > > = > >

> > > = > > (now)

> > > = > >    When more than one codec data frame = is

> > > = > >    present in a single RTP packet, the = timestamp specified is that of

> > > = > >    the oldest data frame represented in the RTP = packet.

> > > = > >

> > > = > >

> > > = > > Section 3.1, last paragraph - Clarified permission for MELP =

> > > = > > 600 end-to-end framing bit

> > > = > >

> > > = > > (was)

> > > = > >    It should be noted that CODB for both the = 2400 and 600 bps modes MAY

> > > = > >    deviate from the values in Table 1 when bit = 55 is used as an end-to-

> > > = > >    end framing bit.  Frame decoding would = remain distinct as CODA being

> > > = > >    zero on its own would indicate a 7-byte = frame for either rate and the

> > > = > >    use of 600 bps speech coding could be = deduced from the RTP timestamp

> > > = > >    (and anticipated by the SDP = negotiations).

> > > = > >

> > > = > > (now)

> > > = > >    It should be noted that CODB for MELPe 600 = bps mode MAY deviate from

> > > = > >    the value in Table 1 when bit 55 is used as = an end-to-end framing

> > > = > >    bit. Frame decoding would remain distinct as = CODA being zero on its

> > > = > >    own would indicate a 7-byte frame for either = 2400 or 600 bps rate and

> > > = > >    the use of 600 bps speech coding could be = deduced from the RTP

> > > = > >    timestamp (and anticipated by the SDP = negotiations).

> > > = > >

> > > = > >

> > > = > > Section 3.2, first paragraph - Clarifications requested by =

> > > = > > reviewers

> > > = > >

> > > = > > (was)

> > > = > >    The TSVCIS augmented speech data as packed = parameters MUST be placed

> > > = > >    immediately after a corresponding MELPe 2400 = bps payload in the same

> > > = > >    RTP packet.  The packed parameters are = counted in octets (TC).  In

> > > = > >    the preferred placement, shown in Figure 6, = a single trailing octet

> > > = > >    SHALL be appended to include a two-bit rate = code, CODA and CODB,

> > > = > >    (both bits set to one) and a six-bit = modified count (MTC).  The

> > > = > >    special modified count value of all ones = (representing a MTC value of

> > > = > >    63) SHALL NOT be used for this format as it = is used as the indicator

> > > = > >    for the alternate packing format shown = next.  In a standard

> > > = > >    implementation, the TSVCIS speech coder uses = a minimum of 15 octets

> > > = > >    for parameters in octet packed form.  = The modified count (MTC) MUST

> > > = > >    be reduced by 15 from the full octet count = (TC).  Computed MTC =3D TC-

> > > = > >    15.  This accommodates a maximum of 77 = parameter octets (maximum

> > > = > >    value of MTC is 62, 77 is the sum of = 62+15).

> > > = > >

> > > = > > (now)

> > > = > >    The TSVCIS augmented speech data as packed = parameters MUST be placed

> > > = > >    immediately after a corresponding MELPe 2400 = bps payload in the same

> > > = > >    RTP packet.  The packed parameters are = counted in octets (TC).  The

> > > = > >    preferred placement SHOULD be used for = TSVCIS payloads with TC less

> > > = > >    than or equal to 77 octets, is shown in = Figure 6.  In the preferred

> > > = > >    placement, a single trailing octet SHALL be = appended to include a

> > > = > >    two-bit rate code, CODA and CODB, (both bits = set to one) and a six-

> > > = > >    bit modified count (MTC).  The special = modified count value of all

> > > = > >    ones (representing a MTC value of 63) SHALL = NOT be used for this

> > > = > >    format as it is used as the indicator for = the alternate packing

> > > = > >    format shown next.  In a standard = implementation, the TSVCIS speech

> > > = > >    coder uses a minimum of 15 octets for = parameters in octet packed

> > > = > >    form.  The modified count (MTC) MUST be = reduced by 15 from the full

> > > = > >    octet count (TC).  Computed MTC =3D = TC-15.  This accommodates a maximum

> > > = > >    of 77 parameter octets (maximum value of MTC = is 62, 77 is the sum of

> > > = > >    62+15).

> > > = > >

> > > = > >

> > > = > > Section 3.3, first paragraph - Suggested edit by = reviewer

> > > = > >

> > > = > > (was)

> > > = > >    A TSVCIS RTP packet consists of zero or more = TSVCIS coder frames

> > > = > >    (each consisting of MELPe and TSVCIS coder = data) followed by zero or

> > > = > >    one MELPe comfort noise frame.  The = presence of a comfort noise frame

> > > = > >    can be determined by its rate code bits in = its last octet.

> > > = > >

> > > = > > (now)

> > > = > >    A TSVCIS RTP packet payload consists of zero = or more consecutive

> > > = > >    TSVCIS coder frames (each consisting of = MELPe 2400 and TSVCIS coder

> > > = > >    data), with the oldest frame first, followed = by zero or one MELPe

> > > = > >    comfort noise frame.  The presence of a = comfort noise frame can be

> > > = > >    determined by its rate code bits in its last = octet.

> > > = > >

> > > = > >

> > > = > > Section 3.3, fourth paragraph - Clarification requested by =

> > > = > > reviewers

> > > = > >

> > > = > > (was)

> > > = > >    TSVCIS coder frames in a single RTP packet = MAY be of different coder

> > > = > >    bitrates.  With the exception for the = variable length TSVCIS

> > > = > >    parameter frames, the coder rate bits in the = trailing byte identify

> > > = > >    the contents and length as per Table = 1.

> > > = > >

> > > = > > (now)

> > > = > >    TSVCIS coder frames in a single RTP packet = MAY have varying TSVCIS

> > > = > >    parameter octet counts.  Its packed = parameter octet count (length) is

> > > = > >    indicated in the trailing byte(s).  All = MELPe frames in a single RTP

> > > = > >    packet MUST be of the same coder = bitrate.  For all MELPe coder

> > > = > >    frames, the coder rate bits in the trailing = byte identify the

> > > = > >    contents and length as per Table = 1.

> > > = > >

> > > = > >

> > > = > > Section 4.1 - Editor note removed

> > > = > >

> > > = > >

> > > = > > Section 4.1 - Change controller is now

> > > = > >

> > > = > > (now)

> > > = > >    Change controller: IETF, contact = <avt@ietf.org>

> > > = > >

> > > = > >

> > > = > > Section 5, first paragraph - Suggested edits by = reviewers

> > > = > >

> > > = > > (was)

> > > = > >    A primary application of TSVCIS is for radio = communications of voice

> > > = > >    conversations, and discontinuous = transmissions are normal.  When

> > > = > >    TSVCIS is used in an IP network, TSVCIS RTP = packet transmissions may

> > > = > >    cease and resume frequently.  RTP = synchronization source (SSRC)

> > > = > >    sequence number gaps indicate lost packets = to be filled by PLC, while

> > > = > >    abrupt loss of RTP packets indicates = intended discontinuous

> > > = > >    transmissions.

> > > = > >

> > > = > > (now)

> > > = > >    A primary application of TSVCIS is for radio = communications of voice

> > > = > >    conversations, and discontinuous = transmissions are normal.  When

> > > = > >    TSVCIS is used in an IP network, TSVCIS RTP = packet transmissions may

> > > = > >    cease and resume frequently.  RTP = synchronization source (SSRC)

> > > = > >    sequence number gaps indicate lost packets = to be filled by Packet

> > > = > >    Loss Concealment (PLC), while abrupt loss of = RTP packets indicates

> > > = > >    intended discontinuous transmissions.  = Resumption of voice

> > > = > >    transmission SHOULD be indicated by the RTP = marker bit (M) set to 1.

> > > = > >

> > > = > >

> > > = > > Section 10 - Added reference

> > > = > >

> > > = > > (added)

> > > = > >    [RFC8088]  Westerlund, M., "How to = Write an RTP Payload Format",

> > > = > = >           &nb= sp;   RFC 8088, DOI 10.17487/RFC8088, May = 2017,

> > > = > = >           &nb= sp;   <http://www.rfc-editor.org= /info/rfc8088>.

> > > = > >

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > -----------------------------

> > > = > >

> > > = > >

> > > = > > -----Original Message-----

> > > = > > From: Roni Even (A) = <roni.even@huawei.com>

> > > = > > Sent: Sunday, October 6, 2019 2:09 AM

> > > = > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' =

> > > = > > <kaduk@mit.edu>; 'The IESG' = <iesg@ietf.org>

> > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen'

> > > = > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

> > > = > > avt@ietf.org; 'Dave Satterlee (Vocal)'

> > > = > > <Dave.Satterlee@vocal.com>

> > > = > > Subject: RE: Benjamin Kaduk's Discuss on

> > > = > > draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

> > > = > >

> > > = > > Hi,

> > > = > > About the reference to TSVCIS.

> > > = > > The RTP payload is about how to encapsulate the payload in an =

> > > = > > RTP

> > > = packet. The objective is to define how an RTP stack can insert the =

> > > = tsvcis frames and  extract the tsvcis frames from the RTP = packet.

> > > = Typically it is not required to understand the payload structure =

> > > = in order to be able to perform the encapsulation.

> > > = > > This is why the reference to the payload is Informational and =

> > > = > > we did not require to have it publically available.  If = there

> > > = > > is a need to understand the payload itself for the =

> > > = > > encapsulating than we need more information in the RTP payload =

> > > = > > specification and a publically available normative reference. =

> > > = > > I think this is not the case here

> > > = > >

> > > = > > Roni Even

> > > = > >

> > > = > > AVTCore co-chair (ex Payload)

> > > = > >

> > > = > > -----Original Message-----

> > > = > > From: victor.demjanenko@vocal.com

> > > = > > [mailto:victor.demjanenko@voca= l.com]

> > > = > > Sent: Saturday, October 05, 2019 12:18 AM

> > > = > > To: 'Benjamin Kaduk'; 'The IESG'

> > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen';

> > > = avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; =

> > > = 'Dave Satterlee (Vocal)'

> > > = > > Subject: RE: Benjamin Kaduk's Discuss on

> > > = > > draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

> > > = > >

> > > = > > Everyone,

> > > = > >

> > > = > > Thanks for the comments.  I think I mis-understood the =

> > > = > > ambiguity with

> > > = respect to to changing rates within a RTP packet.  That was not =

> > > = plan.  An RTP packet must have MELP speech frames of the same = rate.

> > > = What is possible is that the amount of augmented TSVCIS speech =

> > > = data may vary from one speech frame to the next.  This allows for =

> > > = a dynamic VDR as suggested by the NRL paper.  So an RTP packet may =

> > > = have varying TSVCIS data but must always have MELPe 2400 = data.

> > > = > >

> > > = > > Again backwards parsing is necessary but the timestamp =

> > > = > > uniformly

> > > = increments 22.5msec per combined MELP/TSVCIS speech = frame.

> > > = > >

> > > = > > The NRL is a good public reference on the VDR aspects.  = The

> > > = > > actual

> > > = TSVCIS spec we had was FOUO so we could not replicate its detail.  =

> > > = (I believe a later spec is public or at least partially public.  I =

> > > = am trying to get this.)  The opaque data is pretty obvious with the = TSVCIS spec in hand.

> > > = > >

> > > = > > We will address the issues/concerns raised next week.  = Other

> > > = > > business

> > > = had priority.

> > > = > >

> > > = > > Thank you and enjoy the weekend.

> > > = > >

> > > = > > Regards,

> > > = > >

> > > = > > Victor & Dave

> > > = > >

> > > = > > -----Original Message-----

> > > = > > From: Benjamin Kaduk via Datatracker = <noreply@ietf.org>

> > > = > > Sent: Wednesday, October 2, 2019 10:40 PM

> > > = > > To: The IESG <iesg@ietf.org>

> > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen =

> > > = > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

> > > = > > ali.begen@networked.media; avt@ietf.org

> > > = > > Subject: Benjamin Kaduk's Discuss on = draft-ietf-payload-tsvcis-03:

> > > = > > (with DISCUSS and COMMENT)

> > > = > >

> > > = > > Benjamin Kaduk has entered the following ballot position = for

> > > = > > draft-ietf-payload-tsvcis-03: Discuss

> > > = > >

> > > = > > When responding, please keep the subject line intact and reply =

> > > = > > to all email addresses included in the To and CC lines. (Feel =

> > > = > > free to cut this introductory paragraph, = however.)

> > > = > >

> > > = > >

> > > = > > Please refer to

> > > = > > https:= //www.ietf.org/iesg/statement/discuss-criteria.html

=

> > > = > > for more information about IESG DISCUSS and COMMENT = positions.

> > > = > >

> > > = > >

> > > = > > The document, along with other ballot positions, can be found = here:

> > > = > > http= s://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/=

> > > = > >

> > > = > >

> > > = > >

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --

> > > = > > DISCUSS:

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --

> > > = > >

> > > = > > I support Magnus' point about the time-ordering of adjacent =

> > > = > > frames in a

> > > = packet.

> > > = > >

> > > = > > Additionally, I am not sure that there's quite enough here to =

> > > = > > be

> > > = interoperably implementable.  Specifically, we seem to be lacking =

> > > = a description of how an encoder or decoder knows which TSVCIS =

> > > = parameters, and in what order, to byte-pack or unpack, = respectively.

> > > = One might surmise that there is a canonical listing in [TSVCIS], =

> > > = but this document does not say that, and furthermore [TSVCIS] is only = listed as an informative reference.

> > > = (I couldn't get my hands on my copy, at least on short notice.)  =

> > > = If we limited ourselves to treating the TSVCIS parameters as an =

> > > = entirely opaque blob (codec, convey these N octets to the peer =

> > > = with the appropriate one- or two-byte trailer for payload type =

> > > = identification and framing), that would be interoperably =

> > > = implementable, since the black-box bits are up to some other codec to = interpret.

> > > = > >

> > > = > > In a similar vein, we mention but do not completely specify =

> > > = > > the

> > > = potential for using CODB as an end-to-end framing bit, in = Section

> > > = 3.1 (see Comment), which is not interoperably implementable without = further details.

> > > = > >

> > > = > >

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --

> > > = > > COMMENT:

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --

> > > = > >

> > > = > > Where is [TSVCIS] available?

> > > = > >

> > > = > > Is [NRLVDR] the same as

> > > = > > https://ap= ps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ?  A URL =

> > > = > > in the

> > > = references would be helpful.

> > > = > >

> > > = > > Is additional TSVCIS data only present after 2400bps MELPe and =

> > > = > > the first

> > > = thing to get dropped under bandwidth pressure?  The abstract and =

> > > = introduction imply this by calling out MELPe 2400 bps speech =

> > > = parameters explicitly, but Section 3 says that TSVCIS augments =

> > > = standard 600, 1200, and

> > > = 2400 bps MELP frames.

> > > = > >

> > > = > > It's helpful that Section 3.3 gives some general guidance for =

> > > = > > decoding

> > > = this payload type ("[t]he way to determine the number of =

> > > = TSVCIS/MELPe frames is to identify each frame type and length"), =

> > > = but I think some generic considerations would be very helpful to =

> > > = the reader much earlier, along the lines of "MELPe and TSVCIS data =

> > > = payloads are decoded from the end, using the CODA and CODB (and, =

> > > = if necessary, CODC and others) bits to determine the type of = payload.

> > > = For MELPe payloads the type also indicates the payload length, =

> > > = whereas for TSVCIS data an additional length field is present, in =

> > > = one of two possible formats.  A TSVCIS coder frame consists of a =

> > > = MELPe data payload followed by zero or one TSVCIS data payload; =

> > > = after the TSVCIS payload's presence/length is determined, then the =

> > > = preceding MELPe payload can be determined and decoded.  Per =

> > > = Section 3.3, multiple TSVCIS frames can be present in a single RTP = packet."

> > > = This (or something like it) would also serve to clarify the role of the = COD* bits, which is otherwise only implicitly = introduced.

> > > = > >

> > > = > > Section 1.1

> > > = > >

> > > = > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for =

> > > = > > some

> > > = reason an Informational document and not part of BCP = 36?!).

> > > = > >

> > > = > > Section 2

> > > = > >

> > > = > >    In addition to the augmented speech data, = the TSVCIS specification

> > > = > >    identifies which speech coder and framing = bits are to be encrypted,

> > > = > >    and how they are protected by forward error = correction (FEC)

> > > = > >    techniques (using block codes).  At the = RTP transport layer, only the

> > > = > >    speech coder related bits need to be = considered and are conveyed in

> > > = > >    unencrypted form.  In most IP-based = network deployments,

> > > = > > standard

> > > = > >

> > > = > > Am I reading this correctly that this text is just summarizing =

> > > = > > what's in

> > > = the TSVCIS spec in terms of what needs to be in unencrypted form, =

> > > = so the "only the speech coder related bits[...]" is not new =

> > > = information from this document?  I'm not sure I agree with the =

> > > = conclusion, regardless -- won't the

> > > = (MELPe) speech coder bits be enough to convey the semantic content =

> > > = of the audio stream, something that one might desire to keep = confidential?

> > > = > >

> > > = > >    link encryption methods (SRTP, VPNs, FIPS = 140 link encryptors or Type

> > > = > >    1 Ethernet encryptors) would be used to = secure the RTP speech

> > > = > >    contents.  Further, it is desirable to = support the highest voice

> > > = > >    quality between endpoints which is only = possible without the overhead

> > > = > >    of FEC.

> > > = > >

> > > = > > I think I'm missing a step in how this conclusion was = reached.

> > > = > >

> > > = > >    TSVCIS will be characterized.  = Depending on the bandwidth available

> > > = > >    (and FEC requirements), a varying number of = TSVCIS specific speech

> > > = > >    coder parameters need to be = transported.  These are first byte-packed

> > > = > >    and then conveyed from encoder to = decoder.

> > > = > >

> > > = > > Per the Discuss point, how do I know which parameters need to =

> > > = > > be

> > > = transported, and in what order?

> > > = > >

> > > = > >    Byte packing of TSVCIS speech data into = packed parameters is

> > > = > >    processed as per the following = example:

> > > = > >

> > > = > >       Three-bit field: bits A, = B, and C (A is MSB, C is LSB)

> > > = > >       Five-bit field: bits D, E, = F, G, and H (D is MSB, H is

> > > = > > LSB)

> > > = > >

> > > = > = >            = MSB           &nbs= p;            = ;            =           = LSB

> > > = > = >           &nb= sp; 0      1      = 2      3      = 4      5      = 6      7

> > > = > >         = +------+------+------+------+------+------+------+------+

> > > = > >         |   = H  |   G  |   F  |   = E  |   D  |   C  |   = B  |   A  |

> > > = > >         =

> > > = > > = +------+------+------+------+------+------+------+------+

> > > = > >

> > > = > >    This packing method places the three-bit = field "first" in the lowest

> > > = > >    bits followed by the next five-bit = field.  Parameters may be split

> > > = > >    between octets with the most significant = bits in the earlier octet.

> > > = > >    Any unfilled bits in the last octet MUST be = filled with zero.

> > > = > >

> > > = > > I agree with Adam that this is very unclear.  A is the = MSB of

> > > = > > the

> > > = three-bit field but the LSB of the octet overall?

> > > = > > We probably need an example of splitting a parameter across =

> > > = > > octets as

> > > = well, to get the bit ordering right.

> > > = > >

> > > = > > Section 3.1

> > > = > >

> > > = > >    It should be noted that CODB for both the = 2400 and 600 bps modes MAY

> > > = > >    deviate from the values in Table 1 when bit = 55 is used as an end-to-

> > > = > >    end framing bit.  Frame decoding would = remain distinct as

> > > = > > CODA being

> > > = > >

> > > = > > Where is the use of CODB as an end-to-end framing bit = defined? 

> > > = > > If we're

> > > = going to provide neither a complete description of how to do it =

> > > = nor a reference to a better description, we probably shouldn't mention = it at all.

> > > = > >

> > > = > > Section 3.2

> > > = > >

> > > = > >    RTP packet.  The packed parameters are = counted in octets (TC).  In

> > > = > >    the preferred placement, shown in Figure 6, = a single trailing octet

> > > = > >    SHALL be appended to include a two-bit rate = code, CODA and

> > > = > > CODB,

> > > = > >

> > > = > > I'd consider saying something about this being the preferred =

> > > = > > format

> > > = > > ("placement") due to its shorter length than the = alternative,

> > > = > > and say

> > > = that it "SHOULD be used for TSVCIS payloads with TC less than or =

> > > = equal to 77 octetes".

> > > = > >

> > > = > > Section 3.3

> > > = > >

> > > = > > When a longer packetization interval is used, is that =

> > > = > > indicated by

> > > = signaling or RTP timestamps or otherwise?

> > > = > >

> > > = > >    TSVCIS coder frames in a single RTP packet = MAY be of different coder

> > > = > >    bitrates.  With the exception for the = variable length TSVCIS

> > > = > >    parameter frames, the coder rate bits in the = trailing byte identify

> > > = > >    the contents and length as per Table = 1.

> > > = > >

> > > = > > Maybe also note that the penultimate octet gives the length = there?

> > > = > >

> > > = > >    Information describing the number of frames = contained in an RTP

> > > = > >    packet is not transmitted as part of the RTP = payload.  The way to

> > > = > >    determine the number of TSVCIS/MELPe frames = is to identify each frame

> > > = > >    type and length thereby counting the total = number of octets within

> > > = > >    the RTP packet.

> > > = > >

> > > = > > terminology nit: if a frame is the combination of MELPe and =

> > > = > > TSVCIS

> > > = payload data units then there are two layres of decoding to get a =

> > > = length for the frame, since we have to get the TSVCIS length and then = the MELPe length.

> > > = > >

> > > = > > Section 4.2

> > > = > >

> > > = > >    Parameter "ptime" cannot be used = for the purpose of

> > > = > > specifying the

> > > = > >

> > > = > > nit: missing article ("The = parameter")

> > > = > >

> > > = > >    will be impossible to distinguish which mode = is about to be used

> > > = > >    (e.g., when ptime=3D68, it would be = impossible to distinguish if the

> > > = > >    packet is carrying one frame of 67.5 ms or = three frames of 22.5 ms).

> > > = > >

> > > = > > So how is the operating mode determined, = then?

> > > = > > (I think this is the same question I asked = above)

> > > = > >

> > > = > > Section 4.4

> > > = > >

> > > = > >    For example, if offerer bitrates are = "2400,600" and answer bitrates

> > > = > >    are "600,2400", the initial = bitrate is 600.  If other bitrates are

> > > = > >    provided by the answerer, any common bitrate = between the offer and

> > > = > >    answer MAY be used at any time in the = future.  Activation of these

> > > = > >    other common bitrates is beyond the scope of = this document.

> > > = > >

> > > = > > It seems important to specify whether this requires a new O/A =

> > > = > > exchange

> > > = or can be done "spontaneously" by just encoding different = frame types.

> > > = > > (It seems like the latter is possible, on first glance, and =

> > > = > > this is implied by Section 3.3's discussion of mixing them in =

> > > = > > a single

> > > = > > packet.)

> > > = > >

> > > = > > Section 5

> > > = > >

> > > = > > Please expand PLC at first use (not second).

> > > = > >

> > > = > > Section 6

> > > = > >

> > > = > > I don't understand the PLC usage.  Is the idea that a =

> > > = > > receiver, on

> > > = seeing an SSRC gap, constructs fictitious PLC frames to "fill the = gap"

> > > = > > and passes the resulting stream to the = decoder?

> > > = > >

> > > = > > Section 8

> > > = > >

> > > = > >    and important considerations in = [RFC7201].  Applications SHOULD use

> > > = > >    one or more appropriate strong security = mechanisms.  The rest of this

> > > = > >    section discusses the security-impacting = properties of the payload

> > > = > >    format itself.

> > > = > >

> > > = > > I thought we described TSVCIS itself (much earlier in = the

> > > = > > document) as

> > > = requiring encryption for some data; wouldn't that translate to a = "MUST"

> > > = > > here and not a "SHOULD"?

> > > = > >

> > > = > >

> > > = > >

> > = >

> <<...>>

------=_NextPart_001_002D_01D60D9B.9E56D0F0-- ------=_NextPart_000_002C_01D60D9B.9E56D0F0 Content-Type: text/plain; name="changes_04_05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="changes_04_05.txt" Section 2 (first sentence in last paragraph) - Clarification for octet count (was) In order to accommodate a varying amount of TSVCIS augmented speech data, it is only necessary to specify the number of octets containing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using 15 and 35 packed octet parameters [TSVCIS]. (now) In order to accommodate a varying amount of TSVCIS augmented speech data, an octect count specifies the number of octets representing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using a fixed set of 15 and 35 packed octet parameters in a fixed order [TSVCIS]. Section 3.1 (first sentence in last paragraph) - Clarification for CODA, CODB (was) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an end-to-end framing bit. (now) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an alternating 1/0 end-to-end framing bit. ------=_NextPart_000_002C_01D60D9B.9E56D0F0--