Re: [AVT] Comments on IPMR payload

["Elena Berlizova" <[e-mail]>]

Hello,

 

We have just requested for submission the Internet-Draft "RTP Payload
Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-02.txt"
http://www.ietf.org/proceedings/staging/draft-ietf-avt-rtp-ipmr-02.txt 

 

The submission status is here
https://datatracker.ietf.org/idst/status.cgi?submission_id=12719. 

 

As far as the comments concerns:

 

1.       The document MUST have a IANA consideration section. You can
add it as section 5, currently missing

[SPIRIT DSP] added

2.      In the introduction section I suggest you add some text
describing the codec. 

[SPIRIT DSP]added

3.      In section 2.1.2 when describing R "If R=0 then speech TOC is
the last section of the payload header". This sentence is not inline
with the payload format described above. TOC is not part of the header.

[SPIRIT DSP] ok, fixed

4.      In section 2.1.2 when describing E bit you mention teRxFrType,
what is this, there is no reference to this parameter.

[SPIRIT DSP] removed

5.      The last sentence of 2.1.5 you mention special flag, what is
special flag?

[SPIRIT DSP] removed

In 2.1.7 you say that GetFrameInfo is described in [1] yet [1] does not
point to a document but to a web page where I could not see the
information.
[SPIRIT DSP] removed

6.      In 2.2.1 the last sentence you add a padding but A=0 in the
header so why padding.

[SPIRIT DSP] We suggest that payload itself shoud be byte-aligned. Even
if data sections inside payload are not aligned. We think this is common
practice, for example ARM
(http://tools.ietf.org/html/draft-ietf-avt-rtp-amr-bis-06#section-4.3.5.
1
<http://tools.ietf.org/html/draft-ietf-avt-rtp-amr-bis-06#section-4.3.5.
1> )

7.      In 2.2.2 the text says that BR and CR =0 but the diagram has
BR=1 and CR=2

[SPIRIT DSP] fixed

8.      Section 2.2.3 specifies extended format but does not have any
description of when it is used or any  optional payload extension. If
there are none yet you should not specify it at this time and when you
have optional payload extension you can add it to the draft.

[SPIRIT DSP] ok, let's remove it

9.      Section 3, media subtype registration is not complete, the
registration template in defined in RFC 4288 and RFC 4855. You can look
at an example in other payload specifications.

[SPIRIT DSP] fixed

10.   Section 3.1 change the title to  Registration of media subtype
audio/ip-mr_v2.5

[SPIRIT DSP] fixed

11.   Is having v2.5 hints that you will need to register other
versions. In this case I suggest you add an optional payload subtype
parameter version and have the default as 2.5.

[SPIRIT DSP] We think we need to keep 'audio/ip-mr_v2.5' because some
customers already deploy it.

 

We look forward your recommendations. 

Yours sincerely 
Elena Berlizova 

________________________________

From: Roni Even [mailto:[e-mail]] 
Sent: Sunday, February 15, 2009 12:02 PM
To: 'IETF AVT WG'
Cc: Elena Berlizova; Slava Borilin
Subject: Comments on IPMR payload

 

Hi,

I reviewed the draft I have some comments mostly editorial.

As a general comment you can look at one of the latest payload
specification approved like G.719 as an example. Look also at the layout
like to document headers and the table of contents

 

These are the specific comments

 

 

12.   The document MUST have a IANA consideration section. You can add
it as section 5, currently missing

13.   In the introduction section I suggest you add some text describing
the codec. 

14.   In section 2.1.2 when describing R "If R=0 then speech TOC is the
last section of the payload header". This sentence is not inline with
the payload format described above. TOC is not part of the header.

15.   In section 2.1.2 when describing E bit you mention teRxFrType,
what is this, there is no reference to this parameter.

16.   The last sentence of 2.1.5 you mention special flag, what is
special flag?

17.   In 2.1.7 you say that GetFrameInfo is described in [1] yet [1]
does not point to a document but to a web page where I could not see the
information.

18.   In 2.2.1 the last sentence you add a padding but A=0 in the header
so why padding.

19.   In 2.2.2 the text says that BR and CR =0 but the diagram has BR=1
and CR=2

20.   Section 2.2.3 specifies extended format but does not have any
description of when it is used or any  optional payload extension. If
there are none yet you should not specify it at this time and when you
have optional payload extension you can add it to the draft.

21.   Section 3, media subtype registration is not complete, the
registration template in defined in RFC 4288 and RFC 4855. You can look
at an example in other payload specifications.

22.   Section 3.1 change the title to  Registration of media subtype
audio/ip-mr_v2.5

23.   Is having v2.5 hints that you will need to register other
versions. In this case I suggest you add an optional payload subtype
parameter version and have the default as 2.5.

 

 

Regards

Roni Even