|
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 From:
Roni Even [mailto:Even.roni at huawei.com] 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:
avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Elena Berlizova 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 From:
Roni Even [mailto:ron.even.tlv at gmail.com] 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 |