Subject: [AVT] Comments on draft-ietf-avt-rtp-uemclip-02.txt

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Mon, 7 Jan 2008 16:31:00 +0100

Hi

Here are some comments on draft-ietf-avt-rtp-uemclip-02.txt

* Section 2

It seems it is a 20-ms framed coder. You should state it.
Is there a reference to the coder spec?

* Section 3.1, the paragraph on the timestamp is not very clear.

"the RTP timestamp MUST advance based on a multiple of 8 kHz ..."
I think the word 'clock' is missing somewhere.
It would be clearer to talk about the RTP timestamp clock that is 8 or 16 kHz, and explain how it is chosen.

* Section 3.3.1

  - In figure 3, I think you could remove all the "0 1 2 3 ..." in the fields.
The classical rule is to use network byte order. If it is the case, simply state it and simplify the figure.

  - ID : For it to be useful, it should be a MUST. What is the intent of this field?

  - BS : it is not clear how it is used when multiple frames are packed. By the way, is this field really needed? It seems redundant with the payload size.

  - MX and PC : add reference to the describing sections

* Sections 3.3.1.1 and 3.3.1.2

 - It could be interesting to have informational text on the goal and the way to use these fields.
For example how is computed PW1 or PW2? How could V1 and V2 be different? ...
I think more documentation is desirable.

 - Again, I'm not sure it helps to have the "0 1 2..." in the fields on the figures.

 - R3 : reserved bit are usually set to zero

* Section 3.3.2

 - Is SB really useful? I think with CI, FI and QI and figure 3 you can deduce the sub layer size?

 - Figure 3 : CI is set to zero but the text says it should be "0x1"

* Section 5

"UEMCLIP does not have any built-in mechanism for reducing the bandwidth"
-> I don't think it is true since you can remove high level layers if you want.

* Section 6.1

 - this part should be self-contained so when referring Sections, you should add "of RFC XXXX"

* Section 6.2

I'm not sure the "Bandwidth" paragraph is needed.

* Section 6.3.2

It is a little incorrect to state "In the example below, the ptime is set to 60, and this
   means that there are 3 frames in each packet."

RFC 3264 says "If the ptime attribute is present for a stream, it indicates the
   desired packetization interval that the offerer would like to
   receive."

Regard,
Aurelien

________________________________

De : Colin Perkins [mailto:[email-masked]] 
Envoyé : vendredi 21 décembre 2007 16:21
À : AVT WG
Objet : [AVT] Working group last call: draft-ietf-avt-rtp-uemclip-02.txt

This is to announce a working group last call on the RTP Payload Format for the UEMCLIP Speech Codec <draft-ietf-avt-rtp-uemclip-02.txt>. Please send any final comments on this draft to the mailing list by 18 January 2008. If no substantive issues are raised by that time, we intend to ask the IESG to publish this as a Proposed Standard RFC. 

-- 
Colin Perkins <http://csperkins.org/> 

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 13 Jan 2008 15:39:12 +0000

[Speaking as an individual only]

On 21 Dec 2007, at 15:20, Colin Perkins wrote:
> This is to announce a working group last call on the RTP Payload  
> Format for the UEMCLIP Speech Codec <draft-ietf-avt-rtp- 
> uemclip-02.txt>. Please send any final comments on this draft to  
> the mailing list by 18 January 2008. If no substantive issues are  
> raised by that time, we intend to ask the IESG to publish this as a  
> Proposed Standard RFC.

I have a number of comments on this draft, which I believe it would  
be useful to clarify:

Please expand the acronym UEMCLIP in the document title, to conform  
to RFC Editor guidelines.

Section 2 (1st paragraph): Transcoding is only an issue when  
interoperating with a narrowband terminal through a gateway device,  
when there is no possibility of negotiating a common (narrowband)  
codec. The text should be clarified to explain that this is an  
unusual scenario, and that most interoperability scenarios will  
negotiate a common codec, and so not use transcoding.

Section 3 (4th paragraph) states "this information SHOULD be  
exchanged", but says nothing about what to do if the information is  
not exchanged. The draft should either explain what to do when the  
information is not exchanged, or change the SHOULD to a MUST.

Section 3.1: Can you please clarify if the timestamp rate is fixed  
for the duration of a session, as the maximum sampling rate of the  
chosen mode set?

Section 3.2: The RTP transport protocol doesn't specify an MTU,  
rather the size of RTP packets should not exceed the path MTU.

Section 3.3.1: What is the purpose of the ID field? It would seem to  
be redundant with the RTP payload type, and so can be removed.

Section 3.3.1.2: What is the purpose of the Check Bit? It would seem  
that rather than setting a bit to indicate that the payload should be  
ignored, an MCU should simply not send the packet. The resulting gap  
in the RTP sequence number space will inform the receiver of the  
missing data, and trigger packet loss concealment.

Section 4: This section should mention that an RTP device that is  
transcoding between UEMCLIP and G.711 is an RTP translator in the  
sense of RFC 3550, and that all the requirement of that RFC for  
translators apply. In particular, a transcoding device of this sort  
MUST rewrite RTCP packets, not just the RTP media packets.

Section 5: Cannot a UEMCLIP sender reduce its bandwidth by reducing  
the number of layers transmitted? This would seem useful for  
congestion control.

Section 6.1: The sampling rate ("rate") is a required media type  
parameter, and should be added with a reference to section 6.2.1.

Section 6.1 ("Interoperability considerations"): This media format is  
not interoperable with G.711 u-law. Rather, it may be readily  
transcoded to G.711 u-law. Please clarify.

Section 6.2 ("Payload Type"): This draft cannot mandate that a  
dynamic payload type be chosen, since that is the role of an RTP  
Profile. The discussion of the RTP Payload Type in section 3.1 is  
sufficient; there is no need to further explain it here.

Section 6.3.2: Please expand the examples to be complete, valid, SDP  
files.

-- 
Colin Perkins
http://csperkins.org/

---

From: yusuke hiwasaki <[email-masked]>
Date: Wed, 16 Jan 2008 01:21:05 +0900

Dear Aurelien,

> Is there a reference to the coder spec?

Indeed, it is a 20-ms framed coder. I will add a description that it
operates at 20-ms frame. The coder spec is obtainable from the
authors, but will be disclosed under certain terms of
conditions. Should I be specific about it?

> It would be clearer to talk about the RTP timestamp clock that is 8 or 16 kHz, and explain how it is chosen.

Ok, I will try to specify at an appropriate place. My understanding is
that the "timestamp" advance at the "clock rate", and will reflect it
accordingly.

> The classical rule is to use network byte order. If it is the case, simply state it and simplify the figure.

I will change the figures as suggested.

>   - ID : For it to be useful, it should be a MUST. What is the intent of this field?

This field is a redundant information to inform the decoder that what
it is actually trying to decode a UEMCLIP bitstream. Authors would
like to keep it as it is now.

>   - BS : it is not clear how it is used when multiple frames are packed. By the way, is this field really needed? It seems redundant with the payload size.

It will only indicate the byte size in a frame, not the payload
size. 

>   - MX and PC : add reference to the describing sections

Those subsections will be referenced.

> I think more documentation is desirable.

As described, the PW1 is specifically used for the mixing information
and only indicates the power indices current frame (note, it is only
indices, and I believe how to encode this field would be out of the
scope of this document). On the other hand, PW2 is power of any frames
that the field K points at.

Regarding V1 and V2, to obtain the best achievable quality, we believe
that using different criterion is favourable for mixing and PLC. This
means that those can have different values in a frame. I have
clarified that those flags may be different (where it used to be "may
be as same").

>  - R3 : reserved bit are usually set to zero

I agree, but this one needs to be set otherwise. Since it specifies a
default value, I think it should be ok as is now.

>  - Is SB really useful? I think with CI, FI and QI and figure 3 you can deduce the sub layer size?

Yes, but this field is reserved for future use. Or perhaps I should
set it as "reserved" and write down the default values to avoid
confusions? 

>  - Figure 3 : CI is set to zero but the text says it should be "0x1"

My mistake. This will be fixed to "0" in the updated version.

> -> I don't think it is true since you can remove high level layers if you want.

You are right. I will enhance this section and try to clarify how
bandwidth can be reduced.

>  - this part should be self-contained so when referring Sections, you should add "of RFC XXXX"

Will be changed as suggested.

> I'm not sure the "Bandwidth" paragraph is needed.

It seems that recent RFCs regarding RTP payload type specs don't have
this paragraph. I will delete it.

>    desired packetization interval that the offerer would like to

I will try to improve the statement.

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

---

From: yusuke hiwasaki <[email-masked]>
Date: Wed, 16 Jan 2008 01:21:32 +0900

Dear Colin,

Thank you very much for your comments. Replies inline:

At Sun, 13 Jan 2008 15:39:12 +0000,
> to RFC Editor guidelines.

I will reflect it (and read the guidelines again).

> negotiate a common codec, and so not use transcoding.

Yes, as you point out, for one-to-one negotiations, it is of course
sensible to negotiate a common codec. One of the target applications
of this codec was for MCU scenarios (of course the opportunity is less
than one-to-one, but I am less inclined to call it "unusual").  I
should perhaps clarify in this respect.

> information is not exchanged, or change the SHOULD to a MUST.

I was assuming that it will be exchanged, but I was wrong, because the
clock rate is optional. I will change this SHOULD to MUST. 

> for the duration of a session, as the maximum sampling rate of the  

The timestamp was assumed to be fixed. I will change the text.

> rather the size of RTP packets should not exceed the path MTU.

It will be reflected.

> be redundant with the RTP payload type, and so can be removed.

This field is redundant, but it is inform the decoder that what it is
actually trying to decode a UEMCLIP bitstream. Although it may seem
redundant, authors prefer to have it as it is.

> missing data, and trigger packet loss concealment.

There are cases where packet-loss may occur when arriving to an MCU,
and if the MCU is a signal mixer, the MCU might send a packet
generated by a best effort. However, this means that the packet sent
out from MCU may try to convey information of this particular location
where the packet is lost. This is why Check bits are required.

It is also useful for upward-transcoding from G.711, where all the
information is not calculated (however, as pointed out, this may be an
unnecessary procedure, though).

Regarding these fields, authors would like to keep those as it is.

> MUST rewrite RTCP packets, not just the RTP media packets.

I will do so (as you pointed out later, I was misusing the term
"interoperable", where it is in fact a "transcoding" or
"translating"). I will change the description together with Section
6.1. 

> the number of layers transmitted? This would seem useful for  

My fault (this was also commented in another mail). I will delete this
sentence and add a paragraph to describing this.

> parameter, and should be added with a reference to section 6.2.1.

It will be reflected.

> transcoded to G.711 u-law. Please clarify.

I misused the term "interoperability". I will fix the description
here.

> sufficient; there is no need to further explain it here.

I will delete the paragraph (I thoughtlessly did a copy-and-paste from
a payload spec).

> Section 6.3.2: Please expand the examples to be complete, valid, SDP  

Although it might have be incomplete examples, I am not sure if there
were "invalid" examples (it would have been nice if you could point it
out), but I will surely revise the examples and hope that the updated
version is ok.

Best regards,
yusuke

---

From: <[email-masked]>
Date: Thu, 17 Jan 2008 16:07:27 +0100

>	Section 6.1: The sampling rate ("rate") is a required media type parameter,
> and should be added with a reference to section 6.2.1.

Hi

I have a related question (actually broader than UEMCLIP payload): is it also true for the parameter "channels". Is it mandatory to put it the the media type registration? Or is it implicit?
Secondary question: can we use the SDP notation XXX/16000/2 if there is no "channels" parameter in the media type XXX?

Aurélien

---

From: Colin Perkins <[email-masked]>
Date: Mon, 21 Jan 2008 21:57:14 +0000

Yusuke,

Thank you for your response. Some comments inline - I've deleted the  
points on which we seem to have reached agreement.

On 15 Jan 2008, at 16:21, yusuke hiwasaki wrote:
> At Sun, 13 Jan 2008 15:39:12 +0000, Colin Perkins wrote:
...
> redundant, authors prefer to have it as it is.

Why? It just wastes bits - the RTP payload type identifies the bit  
stream as being UEMCLIP.

> Regarding these fields, authors would like to keep those as it is.

Okay, but I think you need to explain the use case further.

> out), but I will surely revise the examples and hope that the updated

Sorry - I wasn't clear. The examples are valid fragments of SDP  
files, but it would be desirable to make them valid complete SDP files.

-- 
Colin Perkins
http://csperkins.org/