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

[philkerr@elec.gla.ac.uk]

Thanks Colin,

Quoting Colin Perkins <csp@csperkins.org>:

> 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!

It was, but can be changed so it 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?

Yes.

> 
> > > - 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?

Agreed.

> 
> > > - 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?

A reference needs to be added pointing back to the website.

Cheers

Phil

> 
> Cheers,
> -- 
> Colin Perkins
> csp@csperkins.org
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

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