[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Re: Comments on draft-ietf-avt-rtp-ac3-03.txt
Hi Brian,
Here is my response, see inline.
Link, Brian wrote:
Hi Magnus,
I have looked through your comments. Thanks for the many that supply
clarifying text or help the I-D conform to AVT expectations. For most of
the comments, I'll incorporate your suggested text in the next version
of the I-D. Here are a few of your comments where I have questions:
1. Status of this memo: You need to update the boilerplate.
Please use the text from RFC 3978 and 3979.
I believe this was correct in the -03 version. I used the boilerplate I
found in RFC 3978 and the file passed Idnits. If you see something
specifically wrong, please let me know.
"This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667."
I reacted to this one. Because RFC 3667 is obsoleted. I think you can
remove this text. Because I think it has to do with the statement in
section 5.4 which you have included at the recommended place at the end
of the draft.
3. Section 3, timestamp: I think the enumeration of the
sampling rate should using "or" instead of "and". The reason
I comment on this is that a defined payload type and thus a
single payload can't use different sampling frequencies . If
different sampling frequencies needs to be supported on the
same connection multiple payload types must be defined.
I moved the sentence in question to section 2.1 where sampling rates and
frame durations are discussed which I think is a better way to satisfy
your concern.
Okay, a clarification was all I needed.
10. Section 5.1, subtype name: Are there is a reason why this
is registered in the vendor space, instead of in the general
IETF tree? As we are having the specification of the payload
format in IETF they are generally approved registered in the
standards tree. I am especially concerned how we are going to
handle the ownership/change controlling of this type.
Can you explain more about the concern here? I don't think I have a
strong opinion on this issue, but will need to check with some
stakeholders. Part of my motivation for using the vendor tree is my
understanding that that would reduce the time to RFC. (I'm still trying
to beat a deadline to reference this eventual RFC in a DLNA
specification.)
The reason is that this payload format will become an IETF proposed
standard. It will be under IETF change control. In this case it
inappropriate to use Dolby's vendor tree. The expectancy is that this
type will be used commonly. Thus I think moving it into the IETF tree by
changing the type to "ac3" seems more appropriate. I use ac3 because the
codec seems all through the document be called that.
In this case I think using a IETF tree will actually save time.
Otherwise there will definitely be questions why a payload format going
for proposed standard uses a vendor type.
12. Section 5.1: Ptime: Why isn't the normal definition in SDP (RFC
2327) referenced here?
13. Section 5.1: Maxptime: Why isn't the definition in RFC
3267 referenced? IF sdp-new is published before this
document, one could reference that.
Would it be acceptable to remove the text about ptime and maxptime from
this payload format definition? I think those sentences got carried into
the document from a template used by an earlier author. I don't see a
need to alter the normal definitions, or even call them out (or
duplicate them) in this document. (If this is acceptable, then I would
leave out the sentence about ptime/maxptime from comment 17; and leave
out references to RFC 2327 and RFC 3267 from comment 22.)
I would be fine with simple having
ptime: see RFC 2327 [x]
maxptime: see RFC 3267 [y]
15. Section 5.1: Please remove the File extension, mac file
type code, and OID registration. That is unless you intend to
register a file format at the same time. However in that case
you need to reference a file format definition and an
analyzes if registration under the same name is appropriate
or not must be performed.
This change is fine. Can you point me at some guidelines for the
analysis you mention? I would like to understand what I might best do
(in the future) to register a file type.
No, not really. There is a debate about this and what will be allowed,
etc. So lets take that discussion later, when we hopefully has resolved
the issues.
19. Section 6. Is there any any manipulation an attacker
could perform to a audio frame that would result in that the
codec crashes or uses significant more processing or memory
to handle that frame. Examples of these would be to
manipulate BSI, or dynamic range control. If the answer is
yes, then this needs to be pointed out. This due to the
Denial of Service threat that then exist.
AC-3 decoders are required to identify and ignore malformed frames. I
think the worst that can happen is that a decoder will mute and enter a
state in which it searches for a sync word at the beginning of a new
frame. I'll look into this a little more to confirm my understanding and
add some wording to this effect.
Okay, that sounds good
21. I am missing a congestion control section. This should
indicate what operations I can perform to reduce the bit-rate
and/or packet rate of the transmission.
I wasn't aware this was required. Can you point me to some guidelines
(and example text) so I'll understand what is needed here?
Well, we try to get these in. The intention is to provide implementors
with an indication of what they can do to reduced the bit-rate when
faced with congestion control.
One example of this text is from BV draft:
The general congestion control considerations for transporting RTP
data apply to BV16 and BV32 audio over RTP as well, see RTP [1]
and any applicable RTP profile like AVP [7]. BV16 and BV32 do not
have any built-in mechanism for reducing the bandwidth. Packing
more frames in each RTP payload can reduce the number of packets
sent and hence the overhead from IP/UDP/RTP headers, at the
expense of increased delay and reduced error robustness against
packet losses.
This is appropriate text if you don't really have any possibilities to
change the bit-rate. If you have possibilities to vary the bit-rate from
the codec please indicate this. Also any other tricks besides
packetization.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt