[AVT] Comments on draft-ahmadi-avt-rtp-vmr-wb-00.txt

[Magnus Westerlund <[e-mail]>]

Hi Sassan,

I have a number of comments on the draft you have submitted.

1. First the draft does not follow the ID nits, the lines are too long:
	http://www.ietf.org/ID-nits.html

2. The section on the VMR-WB coded need further improvements in the 
language.

3. You define a the usage of AMR-WB modes within this payload format. I 
don't see the reason for doing this. Having looked at your scenarios I 
would solve this differently.

a. The IP end point to IP end-point. In this case there is no need for 
the interoperability mode. The end-point either supports VMR-WB fully or 
not at all. Therefore there seem to be little reason to switch to a 
constricted compatibility mode.

b. The WMR-WB on circuit switched side over a gateway. In this case the 
IP end-point either handles the full VMR-WB codec and the VMR modes can 
be used. If the other end-point only supports AMR-WB then one can use 
the AMR-WB payload format over the IP transport, using the AMR-WB mode 
set flag to restrict the modes to the single or three supported ones.

c. In the gateway scenario to gateway scenario. In this case either 
VMR-WB or AMR-WB can be used depending on what is used. The gateways can 
in the signalling declare that they support both.

Do you how any other case which motives this interoperability to be sent 
using the VMR format and not AMR-WB?

3. Section 8, figure 2: The stack is presented as RTP/UDP/IP/VMR-WB 
instead of VMR-WB/RTP/UDP/IP

4. Section 9, first paragraph: What is meant with the sentence: "The 
only differences are in the non-interoperable interconnections where NO 
IWF is required."?

5. Section 9.1, paragraph 4, last sentence: "The default input/output
sampling rate is 16 kHz. Note that during a session, the sampling rate
SHALL not be changed.". I can agree that the sampling rate shall not be 
changed for a given payload type. However over RTP the sampling rate 
could be changed through the switching of payload types. Therefore I 
think you should reconsider the SHALL NOT. Please not that in this case 
the NOT would be normative and therefore needs to be upper case.

6. Section 9.3.1: CMR definition: "Therefore, the network MAY
overwrite the mode request depending on the network conditions." This 
sentence is can definitely be misinterpret. Changing the CMR filed 
between RTP ingress point and egress would mean that one performs a 
layer violation that has several problems with it. For example security 
mechanisms, and checksums would drop a packet being changed. I assume 
that you are meaning a circuit switched node, prior to transport over 
RTP can change the CMR field. Please clarify this. Also needs to be 
consider for the type 15 in the CMR table (3).

7. Section 9.3.1, fourth paragraph: "With a given sampling rate (i.e., 
8/16 kHz), the encoder can switch between wide band or narrowband 
operation modes without prior knowledge of the decoder." What do you 
mean with this sentence? You can probably simplest achieve this through 
RTP payload type switching.

8. Section 9.3.2: How does the Q bit relates to the VMR modes?

9. Have you really considered the need for the bandwidth efficient mode?

10. I find the definition of the file format strange. I can certainly 
not have considered the implications of defining multiple magic keys. We 
would only have one, the multi-channel for AMR-WB files if it hadn't 
been so that we added this support to late, so that there where already 
other public specifications that assumed the single channel structure. 
So I would strongly recommend that you define only one magic key. Have 
you also considered the need for this simplistic file format and your 
requirements for a file format?

11. I don't see how you can redefine the AMR-WB format here. If you need 
a file format that can transport also AMR-WB then you will have to put 
this in your own format. I guess that your problem is that any AMR-WB 
file only using the interoperable modes are a valid AMR file, but any 
AMR-WB file is not a interoperable file. Depending on you needs you need 
to think of what the appropriate solution is.

12. There are missing padding bits in the section 10.3 figure.


13. Section 11, the chapter title. What is (Network controlled Mode 
Switching) doing in the title?

14. Section 12.2 Should talk not only about authentication of sources 
but also integrity protection. They are two different functionality, 
however often provided by the same security mechanism.

15. Section 13.1: I don't think you have need for some of the AMR-WB 
parameters. This relates to my concerns about the need for 
interoperability mode.

16. Section 13.1: The sampling frequency parameter could be replaced by 
a required rate parameter instead. the important here is that the actual 
used sampling rate probably needs to be put into the RTP timestamp, 
unless you have desire to make switching very simple and use 16khz for 
both sampling rates.

17. Section 14. The maxptime attribute is not a new attribute, it is 
defined in RFC 3267 and shall be referenced to that specification.

18. I know that the ISOC copyright allows for derived work. However I 
think one should extend the courtesy to acknowledge the massive 
borrowing of text from RFC 3267 that this draft has done.

19. Informative References: Reference 15 can be replace by the TFRC RFC 
reference now.


As a general comment I think that when borrowing this amount of text 
from another specification one should still think on what requirements 
one have and what is needed and what is not. There is still a lot of 
work for you to clear up a lot of small errors.

I welcome more discussion about the need for the interoperability modes.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



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