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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 16 Sep 2013 13:08:02 +0000

(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

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 16 Sep 2013 14:36:22 -0400

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)" <[email-masked]> wrote:

> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
> 

--
Jonathan Lennox
[email-masked]

---

From: "John Lindsay" <[email-masked]>
Date: Tue, 24 Sep 2013 18:03:10 +0100

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.

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.

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.

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.

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]

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?

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?
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?

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. 

Please feel free to comment on the above.

Thanks

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Lennox
Sent: 16 September 2013 19:36
To: Ali C. Begen (abegen)
Cc: [email-masked]
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)" <[email-masked]>
wrote:

> It is a short document. If you have comments, agreements or
disagreements, please let the list know in either case.

--
Jonathan Lennox
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 24 Sep 2013 20:36:08 +0000

> As I think this is clear to the reader I think these lines could be

Okay.

>      included in the SDP "a=fmtp" attribute.

Seems good.

>      included in the SDP "a=fmtp" attribute.

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

>      SDP "a=maxptime" attribute.

That seems good.

>      SHOULD set this bit to zero in each outgoing packet.

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

> 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.

> and is embedded within the Audio payload at 1/4 of the Audio sampling

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?

> feel any security issues are minimal? What is the feeling of the

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.)

> directly about obtaining licenses and setting up NDA's for further

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.

---

From: "John Lindsay" <[email-masked]>
Date: Wed, 25 Sep 2013 13:09:11 +0100

Hi Jonathon

Editorial comments noted and will be included in next draft.
Specifically the missing "when present"  and "As per [RFC3551] Section
4.1" notes.
Payload types, ok, agreed, again will be added to next draft.

In terms of Aux data the majority of users in the EBU ACIP workgroup
(where the requests for an apt-X RFC originated ) are codec
manufacturers typically aiming at a studio to transmitter (STL)
application, (however apt-x over RTP obviously has other uses). Hence
the majority of the current users we know of will uses the aux data
channel to transmit RS232 data  up to 1/4 sampling rate typically
containing RDS data. It will be up to the implementer of the solution to
decide what data the channel is used for and typically the units would
be used in a complete network hence all the equipment is generally
controlled by one broadcaster.

>From a security point of view the aux channel travels in the compressed
audio stream and encapsulated in an RTP packet hence security concerns
for the aux channel are exactly the same as the audio channel and pose
no different risk? As above its generally an RS232 data channel with a
Protocol, hence if malicious data were to be sent in this channel it
would be up to end equipment to decide if it was protocol compliant
legitimate data and hence to decode or not. 

I have taken a look at CSR's website, CSR's main focus is Bluetooth
audio and they operate in a more commercial environment than apt-X's
previous 25 year history in broadcast audio. Hence the data on apt-X and
Enhanced apt-X now more reflects this focus. However some useful links
may be.

http://www.csr.com/products/60/aptx
http://www.csr.com/products/58/aptx-enhanced

Regards

John

-----Original Message-----
From: Jonathan Lennox [mailto:[email-masked]] 
Sent: 24 September 2013 21:36
To: John Lindsay
Cc: <[email-masked]>; Ali C. Begen (abegen); Hartmut Foerster
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01

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

> and maybe doesn't add anything, by delivery method we mean the 
> algorithm selected e.g. Standard or Enhanced APTX.

Okay.

Seems good.

>      included in the SDP "a=fmtp" attribute.

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

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.
> 

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.

> and is embedded within the Audio payload at 1/4 of the Audio sampling 

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.

> 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.)

> 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_white
paper1.pdf> -- citing that (or something better) as an informative
reference for background on apt-X would seem reasonable.

> 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.
> This is incorrect; as specified by RFC 4566, maxptime is carried in 
> its own SDP a= attribute.
> 

> 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.
> 

> 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?
> describing the apt-X codecs, even if they don't include full 
> proprietary details of the workings of the codec.
>