Subject: RE: [AVT] Re: Comments on draft-ietf-avt-rtp-h264-00.txt

From: "CURET Dominique FTRD/DMI/REN" <[email-masked]>
Date: Mon, 25 Nov 2002 15:37:24 +0100

Hi Stephan

an editorial comment on the table xxx:
I think that:
 MTAP16 might be 0x1A instead of 0x20
 MTAP24 might be 0x1B instead of 0x21
 MTAP32 might be 0x1C instead of 0x22

sincerely

Dominique Curet
FT R&D  Rennes,   Laboratoire DMI/PIA
Tel :  (33) 2 99 12 40 05 
Fax : (33) 2 99 12 40 98 
E-mail : [email-masked]
Mail : FT R & D ,  DMI/PIA 
4, rue du clos Courtel BP 91226 
35512 Cesson-Sévigné Cedex, FRANCE 

-----Message d'origine-----
De : Stephan Wenger [mailto:[email-masked]]
Envoyé : mardi 5 novembre 2002 20:50
À : Magnus Westerlund
Cc : IETF AVT WG; [email-masked]; thomas Stockhammer
Objet : [AVT] Re: Comments on draft-ietf-avt-rtp-h264-00.txt

Hi Magnus,

Thanks for your comments.  Some replies inside.

At 03:11 PM 11/4/2002 +0100, Magnus Westerlund wrote:
>[...]
>
>1. I can't quite understand how the STAP and MTAP are going to be used. 
>How are the fields arranged? It could also be clearer that STAP and MTAP 
>are NALU headers them self with some fields of there own. [...]
>It seem that there can be some variations on the MTAP scheme. One could 
>use one MTAP header per NALU so only the needed size would be used. 
>However that would probably not, be any more efficient.

I'm not really clear on this comment, but I would certainly agree that more 
examples would be helpful.  There are also some terminology issues that 
need to be resolved.  I agree, some work is needed.  Let's have a lunch in 
Atlanta that help me to fully understand your concerns.

>2. RTP header values. I can't understand that this specification should 
>hard code the three fields of version, padding and extension. In the case 
>of version, that should be set according to the RTP version used. And this 
>specification will refer and be defined for version 2. Why must it be 
>forbidden to pad a H.264 payload? If no concrete reason exist this is up 
>to the application and should be set in accordance with the RTP spec. 
>There might be requirements to pad for certain transport or encryption 
>schemes. Also the use of extension header I don't see that the payload 
>format has anything to do with. Let the field be set in accordance with 
>RTP spec.

My understanding is as follows:
Version should be hard-coded to two.  A new version of RTP (if one ever is 
designed) will very likely make this payload spec obsolete.  This is 
in-line with most other payload RFCs.
Padding and Extension: with these two it is always a tradeoff between 
implementation complexity and flexibility.  Our choice was to restrict the 
spec to the minimum to make decoder design as simple as possible -- hence 
both are off.  We are willing to relax those restrictions if this is desirable.

>3. The security consideration. It should mention the fragility of the 
>parameter sets. If I as an attacker of a video stream ensures that the PSI 
>data is in error, that will totally destroy the quality of the stream. It 
>is a point of weakness and should be authenticated and integrity protected.

A damaged or lost (or intentionally altered) parameter set does not hurt 
the integrity of a well-designed system beyond the video 
reproduction.  Hence I don't see a security issue here.  And, when you read 
H.264, you will find an ample amount of language stressing the importance 
of parameter sets.  I don't believe any action is required in the draft, 
and certainly not in the Security section.

>4. Section 10.3 The packet duplication is normally due to the network and 
>not the UDP.

Packet Duplication is meant here as a tool, used intentionally, to increase 
the chances that a certain packet makes it to the receiver.  Meaning, an 
sender transmits the same RTP packet twice (with the same timestamp, 
sequence number, etc. etc.).  For the receiver this looks like as the 
duplication has occurred in the network.  But if one packet is lost, the 
other is still available.

>5. For the first open issue I would like to have some clarification on how 
>the MTAP is packed before giving any opinion.
>6. When will we see a MIME parameter definition and how to include it in SDP?

Soon :-)  I usually leave this stuff to the very end.  Particularly in 
projects where more then one standardization body wants to have a say how 
its stuff is called.

Again, thanks for your remarks.

Stephan

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

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 26 Nov 2002 00:23:13 +0100

Oh yes.  I mentioned this in Atlanta.  Will be fixed in the next 
version.  (And, of course, MTAP8 and MTAP32 are gone).

Stephan