Subject: [AVT] Comments on draft-ietf-avt-rfc2793bis-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Nov 2003 11:53:19 +0100

Hi,

I have some comments on the draft.

1. The abstract should probably be rewritten, I think the second 
paragraph is not relevant enough for this, while the RTP payload format 
for gateways are not mentioned at all.

2. I think the TOC is long enough to have it alone on the second page, 
i.e. I would propose that one start the introduction chapter on page 3.

3. The third last paragraph in chapter 1 seems to be a clear motivation 
for using TCP to transport text. I think there need to be some further 
elaboration on the reasons for using RTP, because the second last 
paragraph is not a obvious result of the previous one.

4. Chapter 1, last paragraph, last sentence "and introduces a means of 
transporting text
   interleaved with voice within the same RTP session.". Is " a means" 
correct english?

5. In section 2, a reference to the complete information for RFC 2119 
would be nice.

6. Section 3:   "When transport of T.140 text session data in RTP is 
desired, the
   payloads as described in this specification SHOULD be used." This 
sentence seems a bit strange. I don't think using normative words about 
using this payload format real has any meaning.

7. Section 3.1, "This format is primarily used when text is transmitted 
on a separate
   RTP session dedicated for the transmission of text and not shared
   with other media, such as audio, DTMF, etc.  IP textphone devices
   most commonly use this format."

I think the restriction this payload format imposes on the media stream 
should be clearly documented in this section.

8. Section 3.2: "This T140block counter may be utilized to detect lost 
characters." I think one should clearly indicate that the counter if for 
detecting not lost characters but lost T140 blocks. I also think the 
comments made in the WG session in Minneapolis that the last block 
before a switch to another audio format can't be detected.

9. Section 3.6, "Note, also, that incoming text from a PSTN circuit 
might be at a higher bit-rate than can be played out on an egress PSTN 
circuit." The scenario and what is meant in this sentence is not clear.

10. Section 3.7; "For profiles that use dynamic payload type number 
assignment, this payload format is identified by the name "T140" (see 
section 8). If redundancy is used per RFC 2198, the Payload Type MUST 
indicate that payload format ("RED")." I think that one should be 
clearer. We are using MIME type according to the definition in chapter 
8, and also RED has its MIME type that can be used to identify the name. 
Therefore I would reformulate the sentences to: "For profiles that use 
dynamic payload type number assignment, this payload format can be 
identified by the MIME types "text/T140" and "audio/T140" (see section 
8). If redundancy is used per RFC 2198, another payload type number 
needs to be provided for the redundancy format. MIME types for 
identifying RFC 2198 are available in RFC 3555 and RFC YYYY." Where RFC 
YYYY is the RFC number for the text/RED registration.

11. Section 3.7, The RTP sequence number: redefining the RTP sequence 
number through normative text is not good. Please provide a reference to 
RFC 3550 and then you can have the informative text.

12. Section 3.7: "Timestamp: The RTP Timestamp encodes the approximate 
instance of entry of the primary text in the packet. A clock frequency 
of 1000
     Hz MUST be used for text/t140.  The clock frequency may be 
specified for audio/t140 and is generally set to be 8000 Hz, as that is 
most common for audio."

In the last sentence above, it says: The clock frequency may be ... This 
is unclear, it needs normative language, making it clear that the rate 
MAY be set to any value, if not specified by out of band mechanism a RTP 
TS rate value of 8000 SHALL be used.

12.5. Section 3.7, why is the marker bit not defined?

13. Section 3.8: What is the following text doing in this chapter?
  "When redundant transmission of the data according to RFC 2198 is
   desired, the RTP header is followed by one or more redundant data
   block headers, one for each redundant data block to be included.
   Each of these headers provides the timestamp offset and length of the
   corresponding data block plus a payload type number indicating this
   payload format ("T140").  Redundant data older than 16383 divided by
   the clock frequency MUST not be transmitted."

It would seem to belong in section describing the usage of RED. I think 
there are more things in regards to usage of RED, like section 3.9,  
that can be collected in a separate chapter clarifying that it concerns 
the usage of RED for t140.

14. Section 4.1 "A maximum buffering time of 500 ms is specified." Where 
is it specified?

15. Section 5: Another comment from the WG meeting in Minneapolis, was 
the need to make it clear that although the MIME parameter CPS  the 
instantaneous reception rate might be higher due to jitter.

16. Section 8.1, as text/t140 in RFC 2793 does not have rate, and it is 
not need (due to fixed rate), I would remove it. The mapping to SDP 
chapter can simply explain that one simply puts in the rate.

17. There should also be an interoperability consideration regarding CPS 
parameter.

Cheers

Magnus

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