Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt

["Christian Hoene" <[e-mail]>]

Hello Colin,

thank you for your comments. Frans De Bont has corrected the draft
accordingly. Inline you find responses to the mentioned issues.

Any other issue open? 

With best regards,

 Christian

--
Dr.-Ing. Christian Hoene
University of Tübingen, Chair of Communication Networks
Research Group Interactive Communication Systems (ICS)
Sand 13, 72076 Tübingen, Germany
Tel [phone], www.net.uni-tuebingen.de

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Monday, December 19, 2011 5:42 PM
> To: Christian Hoene
> Cc: [e-mail]
> Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt
> 
> Christian,
> 
> Some comments on this version:
> 
> - Section 3 is background, but is written in a way that could be
interpreted as
> making a series of normative requirements (e.g., “SBC can use four or
eight
> subbands. The decoder shall support both; the encoder shall support at
least
> 8 subbands”). Be clear whether these are normative requirements made by
> this document, or by the SBC codec specification or the SBC A2DP profile.

All of these requirements are from the SBC codec specification [A2DPV12]. 
[FdB] In Section 3 the origin of the encoder and decoder requirements has
been made more clear.

> 
> - The draft uses “CAN” throughout, but this is not an RFC 2119 keyword.
> What is meant?

[FdB] The "CAN"'s have been replaced by "MUST"'s.

> 
> - Need to mandate the behaviour if the fields in the frame header don’t
> match the SDP negotiated values.
[FdB] I think that the fields in the frame header MUST be compatible with
the  SDP negotiated values.
[Christian Hoene] We added a sentence to drop those frames if they are not
the same.

> It would be better if these parameters
> were only specified in the SDP, rather than duplicating them in-band and
in
> the signalling.

[Christian Hoene] Agreed. We had similar discussions but in the end we
decided to adopt [A2DPV12] without any changes.

> 
> - Media type registration: “MIME type” -> “Media type”, since this is more
> general than Internet mail.

[FdB] Ok.

> 
> - The formatting of the “optional parameters” section of the media type
> registration is unclear. Is this supposed to include the capabilities
parameter?
> Is the capabilities parameter really optional? Section 7.2 seems to
require it.

[FdB] Formatting of the "required/optional parameters" sections has been
changed to make them more clear. In Section 7.2 it is now described that the
capabilities parameter needs only be included in the SDP parameters if it is
present.

>
> 
> - The change controller cannot be the AVT working group, since that no
> longer exists

[FdB] This has been changed to: "IETF Audio/Video Transport Payloads working
group delegated from the IESG".
 
> 
> - Section 7.1.1 refers to the “a=rtpmap:” attribute for the rate and
channel
> parameters, but section 7.1 doesn’t define these parameters. Need to add
> them in the required parameters section of the media type registration.

[FdB] The parameters "rate" and "channels" have been added to section 7.1
and are used in section 7.2.