Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01

[Jonathan Lennox <[e-mail]>]

On Sep 24, 2013, at 1:03 PM, John Lindsay <[e-mail]>
 wrote:

> Hi Jonathon
> 
> Thanks for reviewing this and the points raised.
> 
> I agree on re-reading that the delivery method test is a bit abstract
> and maybe doesn't add anything, by delivery method we mean the algorithm
> selected e.g. Standard or Enhanced APTX.
> As I think this is clear to the reader I think these lines could be
> removed.

Okay.

> Hence I propose changing some sections to remove these references.
> 
> 6.2
> From
>      The required parameters "variant" and "bitresolution" MUST be
>      included in the SDP "a=fmtp" attribute and MUST follow the
>      delivery-method that applies. 
> To
>      The required parameters "variant" and "bitresolution" MUST be
>      included in the SDP "a=fmtp" attribute.

Seems good.

> From
>      The optional parameters "stereo-channel-pairs", "embedded-
>      autosync-channels", "embedded-aux-channels", and "maxptime" when
>      present, MUST be included in the SDP "a=fmtp" attribute and MUST
>      follow the delivery-method that applies. 
> To
>      The optional parameters "stereo-channel-pairs", "embedded-
>      autosync-channels", "embedded-aux-channels",  MUST be 
>      included in the SDP "a=fmtp" attribute.

You lost the "when present" in your edit, which I assume should still be there.

> SDP-Mapping
> 
> Agreed this should have its own SDP a=attribute, suggest changing
> section 6.2 from
> 
>     The parameter "maxptime" when present, MUST be included in the 
>      SDP "a=maxptime" attribute.

That seems good.

> Marker bit.
> 
> Again this can be changed as per RFC3551, as we have no use for this in
> our profile (RFC3550) it can follow the recommendations of RFC 3551
> where it will be zero for most of the intended applications that we can
> see. 
> 
> Suggest changing section 5.1 from
> 
>  o  M - This payload format defines no use for this bit. Senders
>      SHOULD set this bit to zero in each outgoing packet.
> 
>  o  M - As per [RFC3551]

A bit vague, since RFC 3551 has other usages of the M bit for video.  I'd suggest "As per [RFC3551] Section 4.1".


> Payload types
> As I understand it the avtcore group has been discussing a new RFC that
> will update RFC3551 due to conflicts but it is currently unpublished
> work. What recommendations does the group have for the doc on this?
> Currently I feel we reflect what is stated in RFC3551?

I'd just say "A dynamic payload type MUST be used", and drop the reference to the range.

> Aux data
> The Aux data channel can be used for whatever the codec user requires
> and is not defined by this draft, it provides a point to point channel
> and is embedded within the Audio payload at 1/4 of the Audio sampling
> rate?

The problem with "whatever the codec user requires" is that it's "whatever the sender wants", not "whatever the receiver wants" -- so the receiver might have no idea what the sender is putting in this channel.  Unless you're assuming that both sides are under the same administrative control, this seems to me like it can to interoperability problems.

What is this channel commonly used for, and how is it configured?

> To get access to this you would have to decode the audio payload, for
> which you would need either a standard of Enhanced apt-X codec. Hence we
> feel any security issues are minimal? What is the feeling of the
> workgroup?

Again, it's what it's used for, and whether you can always guarantee that the other end isn't sending you something hostile if the channel is used for some sort of active data.  (Don't assume security-through-obscurity; i.e., the apt-X codec being proprietary doesn't mean that a bad guy can't encode or decode it.)

> 
> Section 3 of the doc provides an overview of the codecs operation. The
> aim of the draft is how to packetize Standard or Enhanced apt-X over RTP
> not to explain the operation of the codec. Further details are likely to
> be proprietary to CSR and interested parties would need to talk to CSR
> directly about obtaining licenses and setting up NDA's for further
> information. 

That's fine -- but does CSR have any public (non-technical) data sheets that can be cited, or anything else that an interested party can use to figure out how to contact CSR to decide whether they want to begin this process?  I see for instance <http://www.csr.com/sites/default/files/white-papers/aptx_lossless_whitepaper1.pdf> -- citing that (or something better) as an informative reference for background on apt-X would seem reasonable.

> 
> Please feel free to comment on the above.
> 
> Thanks
> 
> John
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Jonathan Lennox
> Sent: 16 September 2013 19:36
> To: Ali C. Begen (abegen)
> Cc: [e-mail]
> Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01
> 
> The document discusses that a number of items are dependent on the
> "delivery method", and says that the delivery method can be negotiated
> through offer/answer.  However, the delivery method parameter is never
> actually defined anywhere.  Either delivery method needs to be defined,
> or discussion of it needs to be removed, depending on whether or not
> delivery-method was actually meant to be included in the final spec.
> 
> The SDP mapping says that maxptime is encoded in the fmtp parameter.
> This is incorrect; as specified by RFC 4566, maxptime is carried in its
> own SDP a= attribute.
> 
> The RTP header section says that the marker bit is not used.  Unless
> there's a good reason for this, I suggest that instead the usual RFC
> 3551 marker bit semantic for audio be applied (i.e., the marker bit is
> set for end of silence / beginning of talkspurt).  If there's a reason
> this semantic is inappropriate, it should be explained.
> 
> The RTP header section also says that the RTP dynamic payload types can
> only be in the range 96 - 127.  This is incorrect; that's the primary
> range, but other values can be used once that range is exhausted.  See,
> e.g., the recent discussion on the avtcore list.
> 
> No information is given about the semantic content of the data carried
> in the auxiliary data channel.  Is the semantic of this data defined by
> the codec, or would it need to be described or negotiated in SDP?
> (Doing neither, i.e. providing an arbitrary data channel with no
> mechanism for describing or negotiating its content, seems likely to
> lead to interoperability problems.)  Also, are there any security
> considerations introduced by the auxiliary data channel?
> 
> It would be good to have a reference to some document by CSR plc
> describing the apt-X codecs, even if they don't include full proprietary
> details of the workings of the codec.
> 
> On Sep 16, 2013, at 9:08 AM, "Ali C. Begen (abegen)" <[e-mail]>
> wrote:
> 
>> (As a WG co-chair)
>> 
>> I am starting WGLC for the following draft (version 01). 
>> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/
>> 
>> It is a short document. If you have comments, agreements or
> disagreements, please let the list know in either case.
>> 
>> The deadline for the WGLC is September 30th.
>> 
>> -acbegen
>> _______________________________________________
>> payload mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/payload
>> 
> 
> --
> Jonathan Lennox
> [e-mail]
> 
> 
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload