[AVT] Comments on draft-ietf-avt-ulp-10.txt

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi Adam,

I have reviewed the draft and has only one really substantial issue 
which the WG needs to resolve. So lets start with that:

1. Section 14.1 and 14.2: I would like to remove practice to define RTP 
session in the a=fmtp line, this applies both for the normal session 
multiplex case and for RTSP usage. The reason is that when defining RTP 
session without using a complete "m=" block, it gets problematic to 
define other properties of that stream. For example, it is not clear 
what properties the FEC session inherits from the original data session. 
Also it becomes impossible to specify different values for like:
- Used profile
- RTCP bandwidth
- AVPF feedback types
- ...

Therefore my proposal is that we remove the usage of the a=fmtp line, 
and instead rely on grouping the stream together using "Grouping of 
media lines" RFC 3388. I haven't looked into this properly, but it might 
be beneficial to create a new grouping attribute expressing that the 
sessions are grouped due to FEC, or if FID should be used.

2. Section 2, FEC Header: I think it might be beneficial to be explicit 
in the definition of the FEC header that it is not an RTP header.

3. Section 7.3: SSRC: Currently I think the SSRC must be the same. I 
would also think a reference here to some motivation would be good.

4. Section 7.3: Sequence number: The text in this bullet is only true 
for the session multiplexed case. In the redundant encoding case, it may 
not be true.

5. Section 9.1: I would switch place of bullet 14 and 15. That way the 
recovery follows the rebuilding of the packet from the first bit to the 
last.

6. Section 11: The last paragraph needs an addition, that points out 
that congestion control will need to follow what is defined in RTP and 
any applicable profile.

7. Section 12.1: The mime type has one required parameter: rate. The 
rate as you nicely explain, must be set. However, it doesn't need to 
have the same rate, unless using RFC 2198 multiplexing. So I think a 
SHOULD have the same TS rate as the original media. However from RTP 
perspective, letting a session multiplexed FEC stream use its own TS 
rate, would work, or?

8. Section 12.2, 12.3, 12.4: The first paragraph after "Optional 
Parameters" does not fully apply, as it contains a lot of audio specific 
examples.

9. Section 13.2: I have problems with the following paragraph:
  "Because the FEC data is sent in the same packets as the protected
   payload, the ULP header of the FEC packets is not used. The FEC data
   is associated with the protected payload by being bundled in the
   same stream."

Especially the first sentence does not make sense for me. What is the 
ULP header? It seems that in the few occurrences that exist, it has the 
same meaning as FEC header. And that must be there.

10. Section 14.2: The aggregated, non-aggregated RTSP URL bullet list is 
somewhat incorrect. If it remains, after resolving issue 1, I can give 
you more detailed feedback on it.

11. Section 17: You will need to add "STD 64" to your reference 3.

12. Section 17.1: I would count, ref 8 as an informative due to its 
usage in the text.

So its looks very good. Resolving issue 1, and fixing the editorial, it 
should be ready for WGLC.

Cheers

Magnus

--

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com

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