Subject: Re: [AVT] Comments on draft-ietf-avt-rfc3047-bis-00

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Apr 2006 18:52:34 +0100

Hi,

Did these comments ever get addressed?
Colin

On 14 Sep 2005, at 15:42, Magnus Westerlund wrote:

> Hi,
>
> I have reviewed this draft and have some comments on this.
>
> 1. Section 3 the RTP header fields. This draft is lacking a clear  
> definition for the RTP header fields that are RTP payload format  
> specific or used:
> - To my understanding the RTP marker bit is used as normal for  
> audio. However it does require the clarification that this applies  
> for the first frame in the packet.
> - The RTP Timestamp is also not defined to be timestamp of the  
> first sample part of the first frame in the payload.
> - The RTP sequence number in not necessary for RTP payload handling  
> but this should be indicated.
>
> I would recommend that one creates a sub-section "RTP Header  
> Fields" in section 3.
>
> 2. Section 3.1: This section is missing a normative statement  
> requiring the frames in the payload to be consecutive. Obvious but  
> needs to be indicated.
>
> 3. Section 4: replace the reference to RFC 2048 with one to the now  
> approved draft-freed-media-type-reg and RFC 3555.
>
> 4. Section 4.1: The Media type is missing the parameter "rate" that  
> indicated the sampling frequency used. "rate" is the one recommend  
> for this usage in AVP.
>
> 5. Section 4.1: ptime. Please reference the definition in RFC 2327  
> or rather SDP-new.
>
> 6. Section 4.1: Suggestion: Maybe having maxptime would be useful.  
> In this case please reference SDP-new for it.
>
> 7. Section 4.1: Encoding consideration. As we have discussed in the  
> media types discussion for 3GPP timed text the encoding  
> consideration sections should indicate that this is an "framed"  
> media type. The content is also binary which should be pointed out.  
> Modifying the paragraph in 3GPP timed text can be considered.
>
> 8. Section 4.1: Restrictions on usage. This is an RTP payload  
> format media type and this should be indicated in this field.
>
> 9. Section 5: The clock rate in rtpmap shall be that of rate. And  
> if you have correctly defined "rate" it will provide the limitation  
> of 16 and 32 kHz.
>
> 10. Section 5. Having the sentence say "One optional parameter  
> MUST" is not correct.
>
> 11. Section 5.1: When it comes to offer/answer I think one should  
> point out that it is the combination of "rate" and "bit-rate" that  
> defines the configuration used for a particular payload type and  
> each individual configuration intended to be used must be declared.  
> If you need help writing something useful tell me and I will try to  
> help.
>
> 12. Security consideration section. I would propose the following  
> down trimmed version:
>
>   "RTP packets using the payload format defined in this specification
>    are subject to the security considerations discussed in the RTP
>    specification [3], and any appropriate RTP profile.  This implies
>    that confidentiality of the media streams is achieved by  
> encryption.
>
>    A potential denial-of-service threat exists for data encodings  
> using
>    compression techniques that have non-uniform receiver-end
>    computational load.  The attacker can inject pathological datagrams
>    into the stream which are complex to decode and cause the  
> receiver to
>    be overloaded.  However, this encoding does not exhibit any
>    significant non-uniformity."
>
> Some motivation to the changes. The formulation present in the  
> draft concerning the order of encryption and encoding is not  
> watertight and have made the security ADs raise comments on them.  
> As it is not vital and something that happens automatically when  
> using SRTP or IPSec it can be removed.
>
> Secondly, the last paragraph is common and not specific for a RTP  
> payload format. Thus it is something that shall be addressed ain  
> other places than a specific payload format.
>
>
> Cheers
>
> 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: [email-masked]
>
> _______________________________________________
> 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: "Even, Roni" <[email-masked]>
Date: Tue, 4 Apr 2006 21:15:45 +0300

Collin,
I only did part of them. So I will look at the rest and update
accordingly.
Roni

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 8:53 PM
> To: Magnus Westerlund
> Cc: Even, Roni; IETF AVT WG
> Subject: Re: [AVT] Comments on draft-ietf-avt-rfc3047-bis-00
> 
> Hi,
>