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

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

Gunnar,

On 8 Jul 2004, at 18:58, Gunnar Hellstrom wrote:
Thanks for your patience.
I have prepared a new version according to your comments and my answers below.
Ready to submit.
... 
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.

This misses an important point, which that this is useful for multimedia applications. I suggest: "It MAY be used simultaneously with other media streams, transmitted as separate RTP sessions, as required in real-time multimedia applications".

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

I suggest phrasing this as "... consists of a 16-bit 'T140block counter' carried in network byte order (see RFC 791 Annex B [12])" as that is the phrasing used in other RFCs. Your alternate wording makes it sound as if something unusual is happening, when the intent is to specify that the normal rules apply.

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

This helps, but I still think the rest of the paragraph is unclear, and will encourage incorrect implementations. How about something like:

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

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

I suggest keeping the paragraph in it's original position, and making the "SHOULD" a "MUST", but otherwise that looks okay.

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


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