Subject: [AVT] Working group last call: draft-ietf-avt-evrc-smv-00.txt

From: Colin Perkins <[email-masked]>
Date: Fri, 01 Mar 2002 01:09:14 -0500

This is to announce a working group last call on the RTP Payload Format 
for EVRC and SMV Vocoders <draft-ietf-avt-evrc-smv-00.txt>. Please send 
any final comments to the mailing list by 15th March 2002. 

At the end of this period, if there are no comments requiring changes to
the draft, we intend to submit this document to the IESG for publication 
as a proposed standard RFC.

Colin and Steve

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

---

From: Stephen Casner <[email-masked]>
Date: Fri, 8 Mar 2002 00:33:00 -0800 (PST)

Just to be clear, the requirement for at least one review by a working
group participant not directly associated with the draft applies to
this WG last call, too.  We just neglected to mention it in the
announcement below.
							-- Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Mar 2002 13:02:28 +0100

Hi everyone!

I have reviewed the EVRC and SMV documents and have the following 
comments/questions:

1. section 3.2 First paragraph after table. Last sentence says that SMV 
in mode 0 has an average bit rate of  4.2 kbps should that not be 7.2 
kbps according to the table above?

2. section 4, initial paragraph: "The RTP payload data MUST be 
transmitted in packets of one of the
   following two types." I don't think it is the RTP payload that must 
be transmitted rather the speech frames.

3. What is the design rationale behind using only three bits for the LLL 
and NNN field in the payload header and then have two reserved bits? Is 
it investigated that there is no improvement of having interleaving 
using longer lengths than 8?

4. section 5.1 paragraph after table. "A ToC entry with a reserved Frame 
Type value SHOULD be considered invalid and substituted with an erasure 
frame." I don't believe this is a possible solution on the receiver 
side. If there is an error in the TOC it will be impossible to know if 
any remaining speech frames are in synch. There fore all remaining 
speech frames must be marked as erased or the whole packet discarded. I 
also recommend that a sanity check is performed on the receiver side. 
The received packet length and what the payload header size plus the 
speech frames length indicated by the TOC must match. If there are not a 
error somewhere in the TOC is probable and that can result in severe 
degrading of speech quality.

5. Section 6, sixth paragraph.  "Given a time-ordered sequence of output 
frames from the EVRC codec
   numbered 0..n, a bundling value B (in the Count field), ..." The 
parenthesis is misleading, the value B is the number of frames in a 
packet, the count field is one value lower as it is defined. Propose 
that the text in the parenthesis is change to clarify that it is the 
number of frames in a packet.

6. Section 8 first paragraph. "While an erasure frame MUST NOT be 
transmitted by an RTP sender, ..." I am a little curios about the MUST 
NOT for sending erasure frames. There exist a legal reason to send 
erasure frames in my opinion. The case with a gateway between a circuit 
switched network and a IP network. When some error in the circuit 
switched network result in a frame loss it could forward that 
information by using an erasure frame instead of a blank frame.

7. section 9.1 fourth paragraph. What is the motivation for recommending 
4 or 5 as interleaving length. Shouldn't a interleaving length of 8 be 
the most robust?

8. section 9.2, fifth and sixth paragraph. In my eyes it looks wrong to 
use a mode request with an unknown value to set the mode. Isn't it 
better to ignore such a mode request?

9. The reference [2], SMV codec. I can't find the specification on the 
3GGP2 web site's specification page, shouldn't be slightly below the 
EVRC spec?

10. section 10.1 third paragraph. "The ToC field is expanded to one 
octet by setting the left-
   most four bits of the octet to zero." Isn't it better to change the 
sentence to: "The ToC field is expanded to one octet by setting the four 
most significant bits of the octet to zero." The use of left in a bit 
pattern can be misinterpreted.

11. Section 11. This section should be expanded with more text similar 
to what can be found in section 8.3 in the AMR draft.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/T/VA
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]