Subject: [AVT] draft-ietf-avt-rtp-vmr-wb-03: Editorial things

From: Magnus Westerlund <[email-masked]>
Date: Mon, 06 Sep 2004 14:31:07 +0200

Hi,

Some editorial changes that would be desirable for correctness or 
readability:

E1: Section 3, first sentence: Why not put the reference bracket to the 
VMR spec directly after the first VMR-WB in this section, rather than at 
the current place, when it is hard to understand that it is actually the 
VMR-WB reference.

E2: Section 3: There is some confusion in the second and following 
paragraphs to what is meant with mode. As a VMR-WB mode is quite 
different from a AMR-WB mode, I think there should be clarification on 
this. As I see it, the VMR-WB modes, are working modes, that control 
which encoding rates that may be used, and how the selection between 
them should be done. The encoding rates are indicated in the RTP payload 
format for each speech frame, and is equal to the AMR-WB's concept of 
modes. Please clarify.

E3: Section 5.1, last paragraph: I think it is appropriate to enter 
reference to section 6 that explains that header-free and octet-aligned 
payload formats are explain there. I would like something like this:

  Also both header-free and octet-aligned payload
    formats, see section 6, can be utilized.

E4: Section 5.2:
The gateway can
    alternatively set a different CMR value, if desired, as one
    means to control congestion on the IP network.

I think one needs to clarify in which direction the above sentence talks 
about. Traffic from the circuit switched side, or from the IP side.

E5: Section 6, last paragraph: This sentence is in error, compared to 
statement in section 6.4.

E6: Section 6.3.2, CMR:

CMR value 15
    indicates that no mode request is present, and other values are
    reserved for future use.

I think one should ad a clarifying "unused" between other and values. 
Otherwise it might be misinterpreted as the only value that is specified 
is the "no mode request".

E7: Section 6.3.3, last paragraph:

For multi-channel sessions, the ToC entries of all frames
    from a frame-block are placed in the ToC in consecutive.

Either a missing "order" at the end, or move consecutive earlier and 
change its form.

E8: Section 7.3: The example is not byte aligned, I think some one 
removed the padding bits from the AMR example but did not change the 
frame length to match a VMR-WB mode.

E9: Section 10: Second paragraph:
    The data format and parameters are specified for both real-time
    transport in RTP and for storage type applications such as
    e-mail attachments.

This sentence is not correct. Neither the data formats or the parameters 
do apply to both usage domains. They are different and this should be 
clarified. See other mail about MIME type clarifications.

E10: Section 10.2:

       The parameter "channels" SHOULD
       be specified subsequent to the MIME subtype and RTP clock rate.

I think this sentence should be changed to:

The parameter "channels" SHOULD
       be specified subsequent to the MIME subtype and RTP clock rate as 
a encoding parameter in the a=rtpmap attribute.

E11: Reference [10]. This is a normative reference as you depend on the 
channel order. Please move it to the right list.

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

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

---

From: [email-masked]
Date: Tue, 7 Sep 2004 22:34:31 -0700

Hi Magnus

Thanks for your comments.

> the current place, when it is hard to understand that it is 

OK!

> format for each speech frame, and is equal to the AMR-WB's concept of 

Each "VMR-WB mode" (shown in Table 2) is a combination of the permissible encoding rates (shown in Table 3) to obtain a certain quality and average bit rate.

Each "AMR-WB codec mode" is a fixed encoding rate (i.e., 6.60, 8.85, 12.65, etc.).

The concept of mode is different in VMR-WB and AMR-WB. I tried to use the terminologies used in their corresponding specs to be clear and consistent. I will try to further clarify.

>     formats, see section 6, can be utilized.

OK!

> about. Traffic from the circuit switched side, or from the IP side.

OK! It must be the traffic from the non-IP side to the IP terminal.

> statement in section 6.4.

I remove the last paragraph of Section 6. I think Section 6.4 is sufficient.

> is the "no mode request".

OK!

> Either a missing "order" at the end, or move consecutive earlier and 

OK!

> frame length to match a VMR-WB mode.

You are right!

> clarified. See other mail about MIME type clarifications.

OK! In fact, MIME parameters are needed only for the RTP payload and the storage format does not need any MIME parameter (I will explain in my next reply).

> a encoding parameter in the a=rtpmap attribute.

OK!

> channel order. Please move it to the right list.

OK!

I will submit a new revision based on your comments shortly. I hope all comments and issues are captured in the new revision and it is ready for the WG last call.

Regards

-Sassan Ahmadi