Subject: [AVT] Comments on draft-hiwasaki-avt-rtp-uemclip-00

From: "Even, Roni" <[email-masked]>
Date: Fri, 3 Nov 2006 20:32:33 +0200

Hi,
I read the draft and it is a good start. I have a couple of editorial
comments

1. The structure of the document it terms of section can be better. Look
at http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-howto-00.txt
or one of the new payload specifications for the required section and
the order.

2. The introduction section should be expanded and the convention should
be in a separate section.

3. In section 2 "The main goal of the development" replace with "The
main goal of this codec"

4. In section 2 "Fs is the sampling frequency in Hz" should be KHz

5. In section 2 "As will be described in Section 3, UEMCLIP bitstream
contains internal headers and other side-information apart from the
layer data.  This results in total bit-rate larger than the sum of the
each layers shown in the above table.  The detail of the internal
headers and auxiliary information will be described later in Section
3.1." 
Replace with
"UEMCLIP bitstream contains internal headers and other side-information
apart from the layer data.  This results in total bit-rate larger than
the sum of the layers shown in the above table.  The detail of the
internal headers and auxiliary information are described in Section
3.1."

6. In general the RTP payload can be used in different systems not only
in SIP. Examples are other SDP based signaling like H.248/MEGACO or
H.323 systems. So the payload description can give SDP as an example for
signaling but should not mandate usage only in SIP unless an explanation
is included. The SDP usage is in a separate section. This comment is
relevant to the whole document and for example in section 2 "The
supported modes would differ from the implementations, thus the sender
and the receiver must exchange what mode is to be used for transmission.
For this reason, using SIP is RECOMMENDED.  The guideline of the SIP
negotiation procedure will be given in Section 5." 

Should be

"The supported modes would differ from the implementations, thus the
sender and the receiver must exchange what mode to use for transmission.
The guideline of the SDP based negotiation procedure is in Section 5." 

7. Maybe change the title of section 3 to media packetization

8. For the frame description in section 3, use words instead of BNF.
Like a UEMCLIP frame is composed of a main header followed by one or
more sub-layers.

9. You have figure 1 and 3 not figure 2. In figure 3 there is a
subheader not described in the frame description.

10. In section 3 before figure 3 you mention layer ID but it is not
defined.

11. In section 3.1 you have the main header as 10 bytes, figure 3 and 4
shows 9 bytes.

12. In section 3.1 you have "packet size" which field is "packet size"

13. Power #1 - what is the meaning of this field, is it relevant to
G.711

14. VAD flag #2 - why have it if the same as V1 and is redundant

15. Frame indicator (K) - What do you mean by the frame offset of U2 and
P2. Offset from where. In figure 4 and in the text U2 is one byte after
K and P2 follows or am I missing something.

16. What is P1 or P2 is it relevant to G.711 frame. If this is part of
the codec information you should have a reference to it. But since you
want anyone to be able to get the G.711 from this codec bitstream you
should explain the meaning of the header fields and how to extract G.711
maybe in a separate section.

17. You have ES as 8 bits but to me it looks like EH can be bigger the
8*EH since SB is also given as a bit and LD is 8*SB and LD is part of
EH.

18. In section 3.1 explain Sublayer in words and not in BNF.

19. The document should show the RTP header and should have the media
type definition, mapping of parameters to SDP and offer answer logic.
See comment number 1.

20. In section 5.2.1 "fixmode" and "dynmode" paragraphs (3rd and 4th)
have the same text.

21. Section 5.3 Offer answer model considerations should explain how to
get a common mode. What parameters must be the same and how to use
different payload types to offer options. 

"For matters that are not specified in the document, the implementors
MUST follow the guidelines described as follows" This sentence is not
needed. You can reference other document for explanation of the modes
but this section should describe the offer answer flows. 

22. "When packet interval (ptime) other than 20 is offered, it is an
error and an answerer MUST explicitly answer 20." You can specify
instead the ptime SHOULD be 20

23. "Since the current implementation of UEMCLIP encoder does not
      support mode changes after instantiations, transmitters SHOULD not
      change the modes after establishing the session.  Changing the
      mode number MUST be restricted to the mode numbers that are
      specified with "dynmode" by the answerer (note that the decoder
      can always decode bitstreams in other modes."

This paragraph is not clear. If the answer selects one mode then other
modes cannot be used. If the answer include more then one mode the
encoder can switch but if the encoder cannot switch then it will not
switch. So the paragarpg does not add any information.

24 For the IANA media type registration look for examples in other
payload type like RFC4587, your text should be similar.

Thanks
Roni Even 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: yusuke hiwasaki <[email-masked]>
Date: Tue, 07 Nov 2006 04:30:52 +0900

Dear Roni,

Thank you very much for your comments. I'm very grateful that you
checked through the draft in quite detail.

The reply comments are put in-line, however, please take into account
that unanswered comments does not mean that it is being ignored, but
means that it will be reflected in the next draft submission.

At Fri, 3 Nov 2006 20:32:33 +0200,
> 4. In section 2 "Fs is the sampling frequency in Hz" should be KHz

Yes, it should not be Hz, but I am thinking that perhaps it should be
"kHz" with a small "k". Here, I am assuming that the large "K" means
2^10, and small "k" as 10^3. Would that be ok?

> 7. Maybe change the title of section 3 to media packetization

Ok, but the title might not fit the outlines indicated in
draft-ietf-avt-rtp-howto-00.txt. I will try to figure out a solution.

> subheader not described in the frame description.

The BNF expression somehow got the figure number "2", but this did not
show up in the formatted result. Because the BNF expression will be
taken out in the next draft, this will be fixed automatically.

About the figure 3, what I meant "sub-header + sub-layer" was the
"sub-layer data" described in Section 3.2. I will take out
"sub-header" expressions from this figure.

> 10. In section 3 before figure 3 you mention layer ID but it is not

When I said "layer ID", I was meaning as a combination of channel,
frequency and quality indices. Since the expression is misleading, the
sentence will changed and be placed in Section 3.2.

> 11. In section 3.1 you have the main header as 10 bytes, figure 3 and 4

There was a mistake in Figure 3 (now Fig.2) and 4 (now Fig.3). It
should be 10 bytes as stated, because of an extra reserved byte.

> 12. In section 3.1 you have "packet size" which field is "packet

I meant "Byte size" (BS) as "packet size". The sentence is wrong
anyways (the value should be subtracted by 3, not 5) and the
description will be merged into "BS" description.

> K and P2 follows or am I missing something.
(snip) 
> maybe in a separate section.

Although not clearly stated in the current draft, the fields in main
header from C1 to PW1 are intended for use in hubs (MCUs or mixing
server) for mixing multiple locations (mixing info.), and C2 to PW2
are intended for packet-loss concealment (PLC). These fields are
encoded from G.711 signals, by a UEMCLIP encoder.

This feature is one of the advantages of using UEMCLIP, because by
calculating those auxiliary information at the encoder, we can avoid
load that arises on the mixing server. What a UEMCLIP mixer does is
that it fully mixes the G.711 part while selecting the enhancement
layers of an active location from judgments based on the mixing
info. Thus a (pseudo) wideband speech mixing can easily be performed
at the mixing hubs.

Again, V1 and V2 are redundant because those are intended for mixing
and PLC, respectively. The current implementation of our codec sets
the same value for those, thus either can be left out. However, in the
future, we might have a different value that fit better for each
purpose. This also applies to PW1 and PW2 too.

> 8*EH since SB is also given as a bit and LD is 8*SB and LD is part of

Sorry for awkward explanations. LD is not a part of EH, but rather,
belongs to sub-layer data. Sub-layer data are placed after the
main-header (and the main-header which includes EH). Thus the field
order should be:

... | PW2 | ES | EH | CI | FI | QI | R4 | SB | LD | CI | ...

This means that the main-header can have a size larger than 10 bytes,
because EH can be elastic. This leaves us some room for future
extensions. Currently our implementation has 0x00 set to ES, which
means that EH has zero length (thus the main-header size is 10 bytes).
I will certainly try to fix the explanations in the next version.

Best regards,
Yusuke
-- 
============
Yusuke Hiwasaki, NTT Cyber Space Labs.
[email-masked]
Tel: +81-422-59-4815 (Fax: +81-422-60-7811)