Subject: [AVT] Comments on draft-ietf-avt-rtp-retransmission-02.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 05 Jul 2002 16:16:18 +0200

Hi,

I would once more remind people of my previous two mails regarding the 
retransmission drafts. Haven't you looked at them please do that as they 
are relevant.

Have you thought of allowing to use SEL payloads with this type of 
retransmission? It seems possible and gives a possibility to preserve 
back-channel bandwidth if it is scarce.

Section 4.
The references to multicast usage is lacking notice about feedback 
explosion. The type of retransmission in multicast that you described 
can only practical in small groups. This should be addressed.

What possibilities exist of using one retransmission session for 
multiple original streams/sessions? It will save ports compared to 
having one session for each original media session. It will also allow 
for more bandwidth be assigned to RTCP traffic to report lost 
retransmissions. The only constraint I can think of is that SSRC must be 
unique between sessions. Also having unique original PTs would be an 
advantage but not required.

Section 5.
The format is identical to Selret's format RTX with X=1 therefore I 
would strongly recommend that you reference that instead. This would 
make implementation easier in the future.

Is there any motivation of the SHOULD instead of a MUST regarding the 
SSRC that is used in the retransmission session. What is the rule if 
they are not identical between the original and retransmission?

Section 6.1
Shouldn't the should in the second paragraph be uppercase one?

The usage of T_rr_interval in the feedback should be addressed in this 
section. As I understand it the feedback implementation should be told 
that there is feedback to send and therefore the it will schedule 
without taking T_rr_interval into account.

Section

Section 9.
This section is very thin and lacks much today. It needs to specify how 
the payload format is used. It also has to explain how the 
retransmission session is connected to the original session. If only a 
single session is retransmitted in the same session perhaps a rule on 
locality could be used. If multiple retransmission streams is in the 
same session another mechanism is needed. Due to port handling in RTSP 
the port numbers can't be used.

What is the motivation that the retransmission channel uses the same 
media type as the original media? It could be application for all as it 
is application stream.

How are you going to address timestamp rate  changes for the RTX flow? 
This is again the case of the original stream switching codec to one of 
a different rate.

Shouldn't rtx be register for media type application.

Section 10:
The MIME registrations should have the AVT as author/change controller 
also.

Section 11:
Due to the method used for retransmission there is a possibility for two 
time pads between the original stream and the retransmitted one unless 
they use different keys when encrypting using SRTP.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Rahul Agarwal <[email-masked]>
Date: Fri, 05 Jul 2002 15:25:10 -0700

At 04:16 PM 7/5/2002 +0200, Magnus Westerlund wrote:
>explosion. The type of retransmission in multicast that you described can 
>only practical in small groups. This should be addressed.
>
>What possibilities exist of using one retransmission session for multiple 
>original streams/sessions? It will save ports compared to having one 
>session for each original media session. It will also allow for more 
>bandwidth be assigned to RTCP traffic to report lost retransmissions. The 
>only constraint I can think of is that SSRC must be unique between 
>sessions. Also having unique original PTs would be an advantage but not 
>required.
>
>Section 5.
>The format is identical to Selret's format RTX with X=1 therefore I would 
>strongly recommend that you reference that instead. This would make 
>implementation easier in the future.
>
>Is there any motivation of the SHOULD instead of a MUST regarding the SSRC 
>that is used in the retransmission session. What is the rule if they are 
>not identical between the original and retransmission?

[Rahul]: SHOULD is probably used to cover the case where re-transmissions 
are done on the *same* session by employing SSRC multiplexing (Appendix A).

>that there is feedback to send and therefore the it will schedule without 
>taking T_rr_interval into account.
>
>Section
>
>Section 9.
>the payload format is used. It also has to explain how the retransmission 
>session is connected to the original session. If only a single session is 
>retransmitted in the same session perhaps a rule on locality could be 
>used. If multiple retransmission streams is in the same session another 
>mechanism is needed. Due to port handling in RTSP the port numbers can't 
>be used.
>
>What is the motivation that the retransmission channel uses the same media 
>type as the original media? It could be application for all as it is 
>application stream.
>
>This is again the case of the original stream switching codec to one of a 
>different rate.
>
>The MIME registrations should have the AVT as author/change controller also.
>
>Section 11: