Re: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt

[Colin Perkins <csp@csperkins.org>]

Hi,

(inline)

--> David.Leon@nokia.com writes:
...
>>  - Section 4 is unclear how RTCP for the retransmission stream is handled.
>>    Is the sender expected to send periodic SDES and SR reports? BYEs? 
>
>We have been working under the assumption that the retransmission stream
>MUST follow the same RTCP rules as any other RTP stream.  We can of course
>write this in the draft.  My understanding is that a payload format cannot
>modify the RTCP rules. Only a profile document can specify different rules.
>Is it so?

Yes, but the draft gave me the impression something different was intended.
A sentence to clarify would be helpful.

>>  - In section 5.3, the description of how to associate streams when SSRC
>>    multiplexing is used seems error-prone. Would it not be possible to
>>    signal the mapping explicitly?
>
>There could only be an error in the association if two streams use the
>same CNAME, same payload type and retransmit the same packet number at the
>same time. The probability is intuitively very low, in particular given
>that these two streams should have chosen different initial packet sequence
>numbers. If in addition the receiver follows the draft recommendation of
>not requesting the same sequence number for these two streams at the same
>time, the risk of the association to fail seems negligible.
>
>The only way I can see how to make the mapping more explicit, would be to
>add the original stream SSRC in the retransmission payload header. This
>would make the payload header 6 bytes instead of 2 bytes. I'd rather keep
>the payload header as it is now. 

Can we not prohibit the situation from occuring? You can always choose to
use non-clashing payload types, to avoid the problem?

>>  - In section 6.1, when the original and retransmission streams are sent
>>    in the same RTP session, how are the RTCP timing rules modified? Does
>>    the sender get twice the RTCP bandwidth since it appears as two SSRCs?
>
>Here again, we thought that the RTP retransmission stream had to be
>treated like any other RTP stream as far as the RTCP timing rules are
>concerned. This means that we can't specify the fraction of the RTCP
>bandwidth available for the retransmission stream separatly. The original
>stream and the retransmission stream are seen as two independent senders
>that are sharing the RTCP bandwidths allocated to senders in the session as
>would any other sender do.

Okay, but the draft says "the receiver sends report blocks for the original
and the retransmission streams in the same RTCP RR packet". It is not clear
that two separate RTP sessions are used.

>>  - In section 6.2, a pointer to the RTCP Reporting Extensions draft may be
>>    appropriate, since that defines a receiver RTT report.
>
>My concern is that this would introduce one more dependency.

Doesn't have to be a normative reference...

>>  - In section 8, note that the correct syntax is 
>> "a=fmtp:<number> ...".
>
>Could you please point out which line in Section 8 is incorrect?

It says:
	a=fmtp <number>: rtx-time=<rtx-time-val> 
but should be:
	a=fmtp:<number>  rtx-time=<rtx-time-val> 

(i.e. the ":" is in the wrong place)


>>  - In section 12, how does this draft affect SRTP? Is it possible to use 
>>    the two formats together?
>
>We'll try to draft something on that. My understanding is that the
>retransmission stream is seen as any other stream by SRTP and there should
>thus be no problem. 

I was not clear if retransmitting packets caused problems for SRTP; maybe
one of the SRTP authors can comment on any potential security issue?

Cheers,
Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt