[AVT] Comments on draft-ietf-avt-rfc2793bis-03.txt

[Magnus Westerlund <[e-mail]>]

Hi,

Here is my comments from a review of this draft. As this draft was 
intended I will be extra hard on the ID nits, see link on:
http://www.ietf.org/ID.html

1. The whole draft has 15 extra left columns. This can't be there, there 
is a strict requirement on maximum of 72 columns of text.

2. The correct page breaks are missing.

3. The author list contains a blank line.

4. The first line in the left column of the header says AVT Working 
Group. Of historic reasons it should say "Network Working Group"

5. The updated boiler plate according to RFC 3667 and RFC 3668 must be 
used.

6. The RFC editor notes on the first page, are to early. Please move 
them back, at least to after the TOC. But this is also commonly a 
section at the end of the draft.

7. Section 3. I think this section is mixing to many things into one 
brew. I have previously complained on the structure. I think that a 
simple restructuring of the draft would help immensely. I would propose 
the following:
In section 3 define the RTP payload format, RTP header fields, and other 
things directly related to the payload.

Create a new section for on usage of RFC 2198 redundancy. This would 
basically be moving section, 3.4, 3.5, 3.8, 3.9 and parts of 4.3 into 
this new section.

8. Section 3.1: I think this section need to be a bit clearer on what it 
defines. Currently it says:

   "A text conversation RTP packet as specified by the text/t140 payload
    format consists of an RTP header as defined in RFC 3550 [2] followed
    immediately by a block of T.140 data, referred to as a "T140block"
    (see section 3.3).  There are no additional headers specific to this
    payload format."

I would suggest that this is reformulated to:

The text/t140 conversation RTP payload format consists of one and only 
one block of T.140 data, referred to as a "T140block" (see section 3.3). 
There are no additional headers specific to this payload format. The 
fields in the RTP header is set as defined in section 3.7.

The problem with the old text is that it doesn't clearly define what the 
RTP payload was. Instead it defined an RTP packet, which when combined 
with RFC 2198 never exist in the described form. Because then the RTP 
header has its field defined per RFC 2198, and also the payload is per 
RFC 2198. Also due to text later in the discussion on usage of the 
redundancy there is need for a clear understanding of what the RTP 
payload is.

9. Same as 8 but for section 3.2.

10. Section 3.4: "The T140blocks MAY be transmitted redundantly 
according to the payload format defined in RFC 2198 [3]." Please replace 
  "T140blocks" with the "t140 RTP payloads". Reason is that RFC 2198 
sends RTP payloads redundantly.

11. Section 3.6: "Association of RTP streams is dependent on the 
particular session application and is outside the scope of this 
document." Please remove "session".

12. Section 4.2: "With both text/t140 and audio/t140, the loss of the 
last packet of a sequence of packets cannot be detected until the next 
text packet is transmitted." Please replace transmitted, with received. 
The receiver needs to get a new sequence number or T140 block counter to 
be able to determine if things has become lost.

13. Section 4.3:
   "As an alternative (or in addition) to redundancy, Forward Error
    Correction mechanisms MAY be used when transmitting text, as per RFC
    2733 [8] or any other mechanism with the purpose of increasing the
    reliability of text transmission."

This text is redundant with section 3.5. Please gather things in one place.

14. Section 5.
   "To control the character transmission rate, the MIME parameter "cps="
    in the "fmtp" attribute [7] is defined (see section 8 ). It is used
    in SDP with the following syntax: "

The parameter is named "cps" not "cps=" The equal sign is a result of 
the name value pair that is used in fmtp lines.

15. Section 5, last paragraph. The network is another reason why a 
receiver may receive higher character rates. For example buffering that 
is more quickly sent than gathered could give this behaviour.

16. Section 6.3:
   "Below is an example of SDP similar to the above example, but also
    utilizing RFC 2198 to provide redundancy for the text packets:

        m=text 11000 RTP/AVP 98 100
        a=rtpmap:98 t140/1000
        a=rtpmap:100 red/1000
        a=fmtp:100 98/98 "

I think one should point out in this text that one signals only that one 
will use on layer of text redundancy. IF one would use three levels of 
redundancy then the fmtp line would read:
    a=fmtp:100 98/98/98/98

17. Section 11, The SRTP reference is only informative. A normative 
reference is something that one has a normative dependency of in this 
specification.

18. Don't forget to update section 13, and 14.

And please go through the ID-Nits list. I have not checked everything on 
this list, but I expect you to do it.

Cheers



-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


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