[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] draft-herlein-speex-rtp-profile-01



Hi,

--> philkerr@elec.gla.ac.uk writes:
...
> Quoting Colin Perkins <csp@csperkins.org>:
> > --> philkerr@elec.gla.ac.uk writes:
> > > Dear all,
> > > 
> > > An -01 update to draft-herlein-speex-rtp-profile is now available:
> > > 
> > > http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt
> > > 
> > > Comments and feedback welcomed.
> > 
> > I have a number of questions and comments:
...
> > - The definition of the Padding bit in the RTP header is unusual. It
> >   may be better to state that padding MAY be used in the usual RTP
> >   manner, unless there is a specific reason why a different padding
> >   scheme is needed?
> 
> Changing the Padding bit to MAY should be fine.

The main issue is the text "P is set if the total packet size is less than
the MTU" which implies that padding is used to bring the packet size up to
the MTU. I'm assuming that is not intended!

> > - The use of the M bit in the RTP header to signify comfort noise is
> > also
> >   unusual. This is not necessarily inappropriate, but it is important
> >   to consider if the advantages of this use outweigh the costs of being
> >   different to other audio payload formats (which use the M bit to
> >   signal the first packet after a silent period).
> 
> Its use was suggested by Henning Schulzrinne to the other Speex draft
> authors and I've based it on their notes and Section 4.1 of RFC 1890.  If
> there is some discrepency in its use, as highlighted in the feedback by 
> Michael Ramalho, then we may need to look at this section again to
> determine best practice.

Does my reply to Michael clarify?

> > - The definition of the timestamp says "Speex uses 20 msec frames and a
> >   variable sampling rate clock". Does this mean that the sample rate
> >   can change at anytime within a session? Or is the sample rate chosen
> >   from one of a number of values, and then fixed within the session?
> 
> There is a fixed range of values for the sample rate but the rate may
> change mid session.  

It's easier from the point of view of RTP and signalling in SDP if each
different sample rate is sent using a different payload type number. In
SDP, something like:

	m=audio 49170 RTP/AVP 97 98
	a=rtpmap:97 speex/8000
	a=rtpmap:98 speex/16000

Might be useful to make this mandatory in the draft?

> > - Section 3.2 is unclear if the bit rate and sample rate are coupled.
> > Can
> >   Speex vary the compression ratio to change the bit rate without
> >   changing the sampling rate?
> 
> I will need to check this just to make sure.
> 
...
> > - Section 6 (use with H.323) is not appropriate in an IETF document.
> > You
> >   can include a reference to an ITU - or other - document explaining
> >   how to use Speex with H.323, but the IETF can't mandate use of H.245
> >   parameters.
> 
> Agreed.  I presume we can also link back to a Speex document if further
> explanation is required, with the usual proviso about linking to URLs as
> mentioned in the ID-nits.

Correct. How is Speex itself being referenced?

Cheers,
-- 
Colin Perkins
csp@csperkins.org

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