[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Re: I-D ACTION:draft-ietf-avt-rfc2793bis-07.txt
A new draft for packetization of text conversation has been submitted for publication.
It will be draft-ietf-avt-rfc2793bis-08.txt
Most of the changes were from comments for clarity by Colin.
The following changes were made from the -07 version.
>> A URL for the earlier version is:
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-07.txt
>
1.
>
>The boilerplate in the "Status of this Memo" section is incorrect,
>since it references both RFC 2026 and RFCs 3667 and 3668.
The paragraph referencing RFC 2026 is now deleted.
2.
>
>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.
Adjusted sentence:
"It MAY be used simultaneously with other media streams, transmitted as separate RTP
sessions, as required in real-time multimedia applications".
>
3.
>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".
New text:
"An audio/t140c conversation RTP payload format consists of a 16-bit "T140block counter"
carried in network byte order (see RFC 791[12] Annex B),"
4.
>
>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.
This area is not well understood by designers. The explanation on its application here is
needed. The paragraph is replaced with this elaborated one:
Note that the usual RTP semantics apply with regards to switching
payload formats within an RTP session. A sender MAY switch between
"audio/t140c" and some other format within an RTP session, but MUST
NOT send overlapping data using two different audio formats within
an RTP session. This does not prohibit an implementation from being
split into two logical parts to send overlapping data, each part
using a different SSRC and sending its own RTP and RTCP (such an
end point will appear to others in the session as two participants
with different SSRC, but the same RTCP SDES CNAME). Further details
around using multiple payloads in an RTP session can be found in RFC
3550 [2].
4.
>
>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.
It did not say that the loss MUST be kept within specified limits. It said that a method
MUST be implemented...
Reworded to:
"Consideration must be devoted to keeping loss of text caused by packet loss within
acceptable limits. ( See ITU-T F.700 Annex 3. [17])"
5.
>
>Section 4, second paragraph: Suggest removing the comma in "... SHOULD
>be transmitted, if the application..." for clarity.
Done
>
6.
>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".
Added this sentence:
"If end-to-end network conditions allow, text data MAY be sent without additional
protection."
7.
Also a sentence in 4.2 looked superflous
"For the audio/t140c payload format, this rule allows the T140block counters
for the redundant T140blocks to be retrieved."
It was deleted.
>
8.
>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.
Inserted clarification:
"Since sequence numbers are not provided in the redundant header and since the sequence
number space is shared by all audio payload types within an RTP session, a sequence number
in the form of a T140block counter is added to the T140block for transmission. This allows
the redundant T140block data corresponding to missing primary data to be retrieved and
used properly into the stream of received T140block data when using the audio/t140c
payload format.
"
>
9.
>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.
Inserted "non-empty"
"All non-empty redundant data block MUST contain the same data as a T140block previously
transmitted as primary data, and be identified with a T140block counter equating to the
original T140block counter for that T140block."
>
10.
>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.
Changed the 5.2 paragraph simply to:
"An empty T140block contains no data, neither T.140 data nor a T140block counter."
>
11.
>Section 5.3, third paragraph reworded:
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.
>
12.
>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?
To resolve this logic hole, we now limit changes in redundancy level to occur only after
an idle period by this new sentence:
"Change of the general redundancy level MUST only be done after an idle period."
I hope the new version -08 will be out soon, and that everybody feels it is mature now.
Regards
Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom at Omnitor.se
--------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt