Subject: [avt] draft-ietf-avt-rfc2793bis-04 RTP Payload for text conversation is submitted

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 27 Apr 2004 11:55:25 +0200

A new version of the draft-ietf-avt-rfc2793bis is submitted to
internet-drafts.

Here is a summary of changes from version -03 on request from comments:

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

Done

>
> 2. The correct page breaks are missing.

Done

> 3. The author list contains a blank line.

Done.

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

Done.

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

Done.

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

Done.

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

Done

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

Done.

> 9. Same as 8 but for section 3.2.

Done.

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

Done.

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

Done.

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

Done.

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

Done. Section 3.5 is removed completely since the FEC seems to be neccesary
in 4.3 but not in 3.5.

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

Done.

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

Done.

> 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

Done and clarified in the parameters section

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

Done.

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

Done.

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

Done

> 20. Congenstion concerns need to be sharpened

Done

The restructuring made according to comment 7 caused many small edits in
many places in the document.

Please review the file that will hopefully soon be published by
internet-drafts.

Best regards
Gunnar Hellström
-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

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