[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AVT] Re: I-D ACTION:draft-ietf-avt-rfc2793bis-07.txt

On 28 Jun 2004, at 20:30, Internet-Drafts at ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: RTP Payload for Text Conversation
	Author(s)	: G. Hellstrom, P. Jones
	Filename	: draft-ietf-avt-rfc2793bis-07.txt
	Pages		: 25
	Date		: 2004-6-25
	
This memo describes how to carry real time text conversation
   session contents in RTP packets. Text conversation session contents
   are specified in ITU-T Recommendation T.140.

   Two payload formats are described. One for transmitting text on a
   separate RTP session dedicated for the transmission of text, and
   one for transmitting audio and text data within one single RTP
   session.

   This RTP payload description recommends a method to include
   redundant text from already transmitted packets in order to reduce
   the risk of text loss caused by packet loss.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-07.txt

While this version addresses some of my previous comments, I still have a number of concerns:

The boilerplate in the "Status of this Memo" section is incorrect, since it references both RFC 2026 and RFCs 3667 and 3668.

Section 3.1, second paragraph: Please clarify that the text "It MAY be used simultaneously with other media streams..." refers to several different RTP sessions at once, rather than several streams intermixed within a single session.

Section 3.3, first paragraph: The new text "with bit and byte order according to normal habits in IP communication..." would be clearer as "in network byte order".

Section 3.6, last paragraph: I think this new paragraph is unclear, will only cause confusion. Suggest removing it, as it is just a description of standard RTP semantics.

Section 4: Suggest rewording the new paragraph starting "A method MUST be used for ensuring that loss of text caused by packet loss is kept within acceptable limits..." as "Implementations should try to ensure that loss of text caused by packet loss is within acceptable limits (e.g. see ITU-T F.700 Annex 3)". It may not be possible to ensure that loss is kept within acceptable limits, depending on the network, so saying that an implementation "MUST" ensure this does not make sense.

Section 4, second paragraph: Suggest removing the comma in "... SHOULD be transmitted, if the application..." for clarity.

Section 4, third paragraph: Not all networks need additional protection, and the draft should note this rather than insisting that some form of protection is used in all cases. Suggest adding "If network conditions allow, text data MAY be sent with no additional protection".

Section 4.3, first paragraph: The T140block counter is not required to allow a receiver to properly merge the various streams, but to allow a receiver to decide if a missing packet was text or another audio format. Please clarify, since this paragraph is incorrect as written.

Section 4.3, second paragraph indicates that each redundant block contains a T140block counter. This contradicts section 5.2, which requires empty blocks not have a block counter.

Section 5.2, second paragraph indicates that an empty T140block does not have a block counter. This contradicts Section 3.3, which says that the block counter is always present.

Section 5.3, third paragraph: as previously noted, I suggest this is reworded as:

	With text/t140 the loss of packets is usually detected by comparison
 	of the sequence of RTP packets as they arrive. Any discrepancy MAY be
	used to indicate loss. The highest RTP sequence number received may
	also be compared with that in RTCP reports, as an additional check for
	loss of the last packet before an idle period.

Section 5.3, 6th and 7th paragraphs: what are the interactions between these two paragraphs? It would seem that a receiver could infer that an empty T140 block has been received due to a change in the level of redundancy?

--
Colin Perkins
http://csperkins.org/


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt