|
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 |