Subject: Re: [AVT] Action item: CN payload format

From: Dave Lindbergh <[email-masked]>
Date: Tue, 28 Aug 2001 19:43:59 -0400

Steve/all,

I'd like to retain the existing language in draft-ietf-avt-rtp-cn-03.txt, with a small addition to fix the problem you pointed
out.

I think the -03 language is consistent with the existing RTP 
model, and it represents a significant simplification when 
using codecs at other than 8000 Hz sample rates (such as 
G.722.1).

Per Steve's post, 
 > The clock frequency is dependent on the format of data carried as 
 > payload and is specified statically in the profile or payload 
 > format specification that defines the format, or MAY be specified 
 > dynamically for payload formats defined through non-RTP means. 
 > [SDP is an example of "non-RTP means".] 

Yes, but note that draft-ietf-avt-rtp-cn-03, or the eventual RFC,
is _also_ an example of "non-RTP-means".

Again, from Steve's post:
 >The RTP A/V profile specifies for audio encodings: 
 > 
 > When used with a sampling rate other than that for which a static 
 > payload type is defined, non-RTP means beyond the scope of this memo 
 > MUST be used to define a dynamic payload type and MUST indicate the 
 > selected RTP timestamp clock rate, which is usually the same as the 
 > sampling rate for audio. 

draft-ietf-avt-rtp-cn-03 is defining a static payload type 
(13), so it seems that this paragraph does not apply in this 
case.  -03 specifies exactly what the receiver should expect 
the sample rate to be for PT 13; there is no confusion.

 > - There may be a problem with method proposed in -03: many audio 
 > sessions are likely to be silent when they first start (e.g., 
 > before the callee says "Hello" on a telephone session). 
 > Therefore, the first packet might be a CN packet, with no other 
 > codec packet to precede it and establish the RTP timestamp clock 
 > rate. 

Yes, a good point.  I propose that the -03 draft be modified to 
say that at least one "normal" codec packet must be sent before 
the CN packet is sent (on a given port).  This should resolve 
the ambiguity in the situation you describe.

My view is the -03 text (with some revision as just mentioned)
provides a worthwhile simplification without breaking anything
either conceptually or in practice.  

Further thoughts on this?

--Dave

-------------------------------------------------------------------
Dave Lindbergh                       Email: [email-masked]
PictureTel Corporation               Voice: +1 978 292 4351
100 Minuteman Road, MS 713           Fax:   +1 978 292 3328
Andover MA 01810  USA                H.320 video by arrangement
PGP fingerprint:  C8 3E 28 69 53 0A 4B 87  EF E0 11 CD AC 87 4D CD
-------------------------------------------------------------------

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

---

From: Stephen Casner <[email-masked]>
Date: Tue, 28 Aug 2001 18:11:48 -0700 (PDT)

Dave,

> using codecs at other than 8000 Hz sample rates (such as

I'd like to understand how it is a significant simplification.  Given
that G.722.1 requires a dynamic payload type, how is it significantly
harder to also map a dynamic payload type for CN at the matching clock
rate?

> is _also_ an example of "non-RTP-means".

No, the semantics of the payload type are definitely part of RTP.  The
phrase "non-RTP means" refers to control protocols such as SIP, SDP,
RTSP (see the definition of that term in Section 3 of the RTP spec).

> the sample rate to be for PT 13; there is no confusion.

This paragraph says that a static payload type specifies the (fixed)
sampling rate.  The -03 draft specifies that the sampling rate
associated with the static payload type 13 can vary.  This is a
conflict.

> either conceptually or in practice.

I agree that the idea that is proposed in -03 could be workable.
However, it breaks the assumption that a payload type has a fixed RTP
clock rate associated with it.  That would require a change to the RTP
spec and to the A/V profile.  I don't think we should do that without
strong motivation, and I don't think the motivation in this case is
strong.
							-- Steve

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 29 Aug 2001 15:04:47 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Lindbergh
> Sent: Tuesday, August 28, 2001 7:44 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [AVT] Action item: CN payload format
> 
> 
> Steve/all,
> 
> I'd like to retain the existing language in 
> draft-ietf-avt-rtp-cn-03.txt, with a small addition to fix 
> the problem you pointed out.
> 
> Yes, but note that draft-ietf-avt-rtp-cn-03, or the eventual 
> RFC, is _also_ an example of "non-RTP-means".
> 
I really don't like this special case requirement.
 
> My view is the -03 text (with some revision as just 
> mentioned) provides a worthwhile simplification without 
> breaking anything either conceptually or in practice.  
> 
I think going back to the -01 language as suggested by Colin is in fact
much simpler, bacause it eliminates all these special cases. I'd rather
always have to know the sampling rate per payload type, than have to
know in which cases I can infer one from the other.

Dave.