[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Re: I-D ACTION:draft-ietf-avt-rfc2793bis-07.txt
Colin,
Thanks for your patience.
I have prepared a new version according to your comments and my answers below.
Ready to submit.
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
--------------------------------------------
>-----Original Message-----
>From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]On Behalf Of
>Colin Perkins
>Sent: Monday, July 05, 2004 3:10 PM
>To: IETF AVT WG
>Subject: [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.
The paragraph referencing RFC 2026 is now deleted.
>
>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.
Proposed sentence:
It MAY be used simultaneously with other media streams, transmitted as separate RTP
sessions.
>
>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".
I think also the bit order shall be specified. Proposed text:
"An audio/t140c conversation RTP payload format consists of a 16-bit "T140block counter"
with bit and byte order according to normal habits in IP communication,transmitted in
network bit and byte order as specified in rfc 791[12] Annex B,"
>
>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. I suggest keeping it and adding this sentence:
" Further details around using multiple payloads in a RTP session is found in RFC 3550
[2]."
>
>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])"
>
>Section 4, second paragraph: Suggest removing the comma in "... SHOULD
>be transmitted, if the application..." for clarity.
Done
>
>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."
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.
>
>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.
Proposed 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.
"
>
>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."
>
>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."
>
>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.
Done
>
>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?
You are right in realizing that side effect. The words are there for telling how to
maintain a low risk for false detection of loss over idle times longer than 16 seconds.
The empty T140blocks sent last before the idle period are then too old to be tranmitted.
If they were missed before the idle period, and not sent after, we would detect the
sequence number gap and insert a marker for loss for a character that we do not care
about.
The most common reason to not send the usual number of redundant generations will be this
situation, after an idle period when redundant empty data is too old to be transmitted. We
protect that from generating loss detection by the rule saying that"
If redundancy is used with the text/t140 format, and a packet is received with fewer
redundancy levels than normally in the session, it SHOULD be treated as if one empty
T140block has been received for each excluded level in the received packet. This is
because the only occasion when a T140block is excluded from transmission is when it is an
empty T140block that has become too old to be transmitted."
For that case, the false detection of loss is prevented.
But if the application decides that the network is excellent, and the redundancy level can
be lowered, it will also appear as a lowering of the redundancy level. By the current rule
it will be regarded as reception of an empty t140block. If the primary packet
corresponding to that position was lost, we have a slight risk to not mark a position with
the loss indicator where real loss occurred.
This kind of change of level should be very rare, so that the risk of not marking loss
occurring just when you decided that the network is excellent seems very low. Therefore we
could ignore it.
But the smart reader apparently discovers the logic gap here. So, it should be covered.
I suggest that we limit changes in redundancy level to occur only after an idle period by
this new sentence: "Change of the general redundancy level SHOULD only be done after an
idle period."
Another way would be to regard missing redundancy levels as transmission of empty blocks
only for the first few packets after an idle period. I did not succeed to express that.
/
Gunnar
>
>--
>Colin Perkins
>http://csperkins.org/
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt at ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt