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

[David.Leon@nokia.com]

Hi Colin,

Thanks for the review.


> 
> I've just read the -04 version of the retransmission draft. 
> It seems to be
> in reasonably good shape, but I do have some questions and comments:
> 
>  - At the end of section 3.1, after discussing the choice 
> between SSRC and
>    session multiplexing, the draft states "both multiplexing 
> approaches
>    SHOULD be supported". Is this intended to be a requirement 
> for both the
>    sender and receiver? 

Yes. We can write this explicitly.


> 
>  - In section 4, the draft mentions the possibility that the 
> retransmission
>    stream may include packets with multiple clock rates. How 
> is this to be
>    signalled in the SDP?

The retransmission RTP stream is no different from the original RTP stream in this regard. If multiple payload types are used, each payload type must be declared in the SDP and its clockrate is given by the rtpmap attribute.

> 
>  - In section 4, the draft states that and profile-specific 
> payload header
>    must be included in the retransmitted packet. Is this sent 
> before the
>    OSN payload header or after it?

The retransmission payload header should precede the payload of the original packet, including its payload header. This needs to be clarified in the draft.

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

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


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


>  - In section 8, note that the correct syntax is 
> "a=fmtp:<number> ...".

Could you please point out which line in Section 8 is incorrect?

> 
>  - 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 also think it would be appropriate if this draft describes 
> the level of
> reliability that can be expected from a session using 
> retransmission, and
> perhaps describes when this is acceptable, and when TCP 
> should be used?

Ok.


Thanks.


David.

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