[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avt] draft-ietf-avt-rfc2793bis-04 RTP Payload for text conversation is submitted
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
Gunnar.Hellstrom@Omnitor.se
--------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt