Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03

From: "Elena Berlizova" <[email-masked]>
Date: Wed, 13 May 2009 16:46:29 +0400

Hi,

Please find the responses below:

1.         The draft should have an author name at the top, not just SPIRIT SDP, there is an author name at the end Sergey Ikonin.

2.         You describe the payload but it is not clear to me how do you know the size of each speech frame. It may be good to explain it if you can.

[Comment] The size of coded speech frame is variable. The Encoder's algorithm decides what size of each frame is and returns it after encoding. In order to save bandwidth the size is not placed into payload obviously. But Decoder can calculate size by the content of coded frame and returns it to the top level application. This way we can get a size of each frame. Moreover there is a special service function that returns frame size without total decoding. Should the explanation be inserted into the draft? 

3.         In section 3 RTP payload format you should start with a section on RTP header usage. See for example RFC 5404.

[Comment] will be corrected 

4.         In the security consideration you can use the first two paragraph from RFC 5404 security section.

[Comment] will be corrected 

5.         You can add a section on congestion control, this codec can handle congestion so it will be good to mention it.

[Comment] will be corrected 

6.         You can add to section 5.2 a subsection on offer answer considerstions

[Comment] We believe all needed signaling is already implemented in-band. So there is no special consideration in this section indented.

Perhaps it'd be reasonable to add something like this:

Offer/Answer Considerations

No special considerations should be given for the use of IP-MR within the offer/answer model.

Some nits

1.         In section 2  "This making the bit stream scalable and allows reduce ..."

2.         In section 2 " But because of the scalable nature of IP-MR codec there is no need to duplicate the whole previous frame - only the core layer may be retransmitted."

3.         In section 3.2 "BR (3 bits): base rate for core layer of frame(s) in this packet using the table for CR. "

Yours sincerely 
Elena Berlizova 

________________________________

From: Roni Even [mailto:[email-masked]] 
Sent: Monday, April 27, 2009 10:13 PM
To: [email-masked]
Subject: Comments on draft-ietf-avt-rtp-ipmr-03

Hi, 

I reviewed the draft and have the following comments most are editorial

1.      The draft should have an author name at the top, not just SPIRIT SDP, there is an author name at the end Sergey Ikonin.

2.      You describe the payload but it is not clear to me how do you know the size of each speech frame. It may be good to explain it if you can.

3.      In section 3 RTP payload format you should start with a section on RTP header usage. See for example RFC 5404.

4.      In the security consideration you can use the first two paragraph from RFC 5404 security section.

5.      You can add a section on congestion control, this codec can handle congestion so it will be good to mention it.

6.      You can add to section 5.2 a subsection on offer answer considerstions

Some nits

1.      In section 2  "This making the bit stream scalable and allows reduce ..."

2.      In section 2 " But because of the scalable nature of IP-MR codec there is no need to duplicate the whole previous frame - only the core layer may be retransmitted."

3.      In section 3.2 "BR (3 bits): base rate for core layer of frame(s) in this packet using the table for CR. "

Thanks

Roni Even

---

From: Roni Even <[email-masked]>
Date: Wed, 13 May 2009 20:02:42 +0300

Hi Elena,

I am OK with your responses, on number 2 it will be good to give some
explanation in the draft and as for number 6 leave it as is.

Please update the draft and I will start WGLC

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Elena
Berlizova
Sent: Wednesday, May 13, 2009 3:46 PM
To: [email-masked]
Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03

Hi,

 

1.         The draft should have an author name at the top, not just SPIRIT
SDP, there is an author name at the end Sergey Ikonin.

2.         You describe the payload but it is not clear to me how do you
know the size of each speech frame. It may be good to explain it if you can.

[Comment] The size of coded speech frame is variable. The Encoder's
algorithm decides what size of each frame is and returns it after encoding.
In order to save bandwidth the size is not placed into payload obviously.
But Decoder can calculate size by the content of coded frame and returns it
to the top level application. This way we can get a size of each frame.
Moreover there is a special service function that returns frame size without
total decoding. Should the explanation be inserted into the draft? 

3.         In section 3 RTP payload format you should start with a section
on RTP header usage. See for example RFC 5404.

4.         In the security consideration you can use the first two paragraph
from RFC 5404 security section.

5.         You can add a section on congestion control, this codec can
handle congestion so it will be good to mention it.

6.         You can add to section 5.2 a subsection on offer answer
considerstions

[Comment] We believe all needed signaling is already implemented in-band. So
there is no special consideration in this section indented.

No special considerations should be given for the use of IP-MR within the
offer/answer model.

Some nits

1.         In section 2  "This making the bit stream scalable and allows
reduce ."

2.         In section 2 " But because of the scalable nature of IP-MR codec
there is no need to duplicate the whole previous frame - only the core layer
may be retransmitted."

3.         In section 3.2 "BR (3 bits): base rate for core layer of frame(s)
in this packet using the table for CR. "

Yours sincerely 
Elena Berlizova 

  _____  

Hi, 

1.       The draft should have an author name at the top, not just SPIRIT
SDP, there is an author name at the end Sergey Ikonin.

2.       You describe the payload but it is not clear to me how do you know
the size of each speech frame. It may be good to explain it if you can.

3.       In section 3 RTP payload format you should start with a section on
RTP header usage. See for example RFC 5404.

4.       In the security consideration you can use the first two paragraph
from RFC 5404 security section.

5.       You can add a section on congestion control, this codec can handle
congestion so it will be good to mention it.

6.       You can add to section 5.2 a subsection on offer answer
considerstions

Some nits

1.       In section 2  "This making the bit stream scalable and allows
reduce ."

2.       In section 2 " But because of the scalable nature of IP-MR codec
there is no need to duplicate the whole previous frame - only the core layer
may be retransmitted."

3.       In section 3.2 "BR (3 bits): base rate for core layer of frame(s)
in this packet using the table for CR. "

Thanks

Roni Even

---

From: "Elena Berlizova" <[email-masked]>
Date: Fri, 22 May 2009 13:21:59 +0400

Hi 

The undated version -04 of the Internet draft for Payload format for
IP-MR codec has been posted and now it's available at
http://tools.ietf.org/html/draft-ietf-avt-rtp-ipmr-04. 

All the comments have been taken into account. 

Thank you.

Yours sincerely 
Elena Berlizova 

From: Roni Even [mailto:[email-masked]] 
Sent: Wednesday, May 13, 2009 9:03 PM
To: Elena Berlizova; [email-masked]
Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03

Hi Elena,

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elena Berlizova
Sent: Wednesday, May 13, 2009 3:46 PM
To: [email-masked]
Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03

Hi,

 

1.         The draft should have an author name at the top, not just
SPIRIT SDP, there is an author name at the end Sergey Ikonin.

2.         You describe the payload but it is not clear to me how do you
know the size of each speech frame. It may be good to explain it if you
can.

[Comment] The size of coded speech frame is variable. The Encoder's
algorithm decides what size of each frame is and returns it after
encoding. In order to save bandwidth the size is not placed into payload
obviously. But Decoder can calculate size by the content of coded frame
and returns it to the top level application. This way we can get a size
of each frame. Moreover there is a special service function that returns
frame size without total decoding. Should the explanation be inserted
into the draft? 

3.         In section 3 RTP payload format you should start with a
section on RTP header usage. See for example RFC 5404.

4.         In the security consideration you can use the first two
paragraph from RFC 5404 security section.

[Comment] We believe all needed signaling is already implemented
in-band. So there is no special consideration in this section indented.

No special considerations should be given for the use of IP-MR within
the offer/answer model.

Some nits

reduce ..."

2.         In section 2 " But because of the scalable nature of IP-MR
codec there is no need to duplicate the whole previous frame - only the
core layer may be retransmitted."

3.         In section 3.2 "BR (3 bits): base rate for core layer of
frame(s) in this packet using the table for CR. "

Yours sincerely 
Elena Berlizova 

Hi, 

2.      You describe the payload but it is not clear to me how do you
know the size of each speech frame. It may be good to explain it if you
can.

4.      In the security consideration you can use the first two
paragraph from RFC 5404 security section.

Some nits

reduce ..."

2.      In section 2 " But because of the scalable nature of IP-MR codec
there is no need to duplicate the whole previous frame - only the core
layer may be retransmitted."

3.      In section 3.2 "BR (3 bits): base rate for core layer of
frame(s) in this packet using the table for CR. "

Thanks

Roni Even