Re: [AVT] Re: draft-ietf-avt-rtp-amr-13.txt -- please include link to source code

Hi, all

I am totally puzzled by this "reference impl to AMR codec" discussion.
Please note, what is being talked about is NOT the ref implementation of
this AVT payload RFC. Rather, we are talking about the ref
implementation of the codec itself.

If there is really a need for a better reference to the codec ref
implementation, should that be the responsibility of the codec
definition document, i.e., 3GPP AMR spec? Why should IETF be asked to
fix the (so indicated) inadequate cross-reference between two 3GPP
documents?

regards,
-Qiaobing

Magnus Westerlund wrote:
> 
> James,
> 
> Well, lets try to add this during the authors 48 hours. Below is a
> proposal for changes in the spec for the WG and authors to consider.
> This will inform the reader that there exist reference implementations.
> I also included links to the correct directory.
> 
> How to do with the MIME section I am not sure. The reason is that the
> reference codec implementation  is not directly capable of handling in
> the file format specified to be used by the MIME type. I would also like
> the scenario to be as simple as you picture it. But even with the
> reference implementation it is at least a couple of days of work to get
> a working implementation even in a nice framework. So is something more
> informative than the current, go look in the payload format
> specification, needed?
> 
> Regards
> 
> Magnus W.
> 
> Adding a single sentence to the following paragraph:
> 
> 3.1. The Adaptive Multi-Rate (AMR) Speech Codec
> 
>    The AMR codecs was originally developed and standardized by the
>    European Telecommunications Standards Institute (ETSI) for GSM
>    cellular systems. It is now chosen by the Third Generation
>    Partnership Project (3GPP) as the mandatory codec for third
>    generation (3G) cellular systems [1]. A reference implementation
>    is available in either floating-point code [25] or fix-point code
>    [26].
> 
> Adding a single sentence to the following paragraph
> 
> 3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec
> 
>    The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was
>    originally developed by 3GPP to be used in GSM and 3G cellular
>    systems. A reference implementation is available in either
>    floating-point code [27] or fix-point code [28].
> 
> Add to the reference section 11.1 the following
> 
>    [25] 3GPP TS 26.104, "ANSI-C code for the floating-point Adaptive
>         Multi-Rate (AMR) speech codec", version 4.3.0 (2002-03),
>         3rd Generation Partnership Project (3GPP),
>         "ftp://ftp.3gpp.org/specs/latest/Rel-4/26_series/".
> 
>    [26] 3GPP TS 26.073, "AMR speech Codec; C-source code", version
>         4.1.0 (2001-12), 3rd Generation Partnership Project (3GPP),
>         "ftp://ftp.3gpp.org/specs/latest/Rel-4/26_series/".
> 
>    [27] 3GPP TS 26.204, "ANSI-C code for the floating-point Adaptive
>         Multi-Rate (AMR) wideband speech codec", version 5.0.0
>         (2002-03), 3rd Generation Partnership Project (3GPP),
>         "ftp://ftp.3gpp.org/specs/latest/Rel-5/26_series/".
> 
>    [28] 3GPP TS 26.173, "ANSI-C code for the Adaptive Multi Rate (AMR)
>         Wideband speech codec", version 5.4.0 (2002-03),
>         3rd Generation Partnership Project (3GPP),
>         "ftp://ftp.3gpp.org/specs/latest/Rel-5/26_series/".
> 
> James Salsman wrote:
> 
> > Magnus,
> >
> > Thank you for your reply:
> >
> >> I am not convinced that a informative reference to the implementation
> >> directly from the payload format is necessary. There exist ways of
> >> finding the reference implementation, it is for example referenced in
> >> the AMR main spec TS 26.090. If the draft was not approved and in the
> >> rfc-editors queue I would be less inclined to avoid doing this change.
> >
> >
> > The worst that can happen is that you will be the author of two RFCs
> > instead of one. Would you rather ask the editors for an additional
> > reference included (not a huge request) or would you rather be the
> > author of a mime type registration that could have had a pointer to
> > working code but didn't? Trust me, including working code is something
> > that the rfc editors really like, because the audience loves it.
> >
> > Imagine these two scenarios. Joe Random Tech gets a message with MIME
> > type Audio/AMR or audio/amrnb and so he goes to the MIME type
> > registration
> > and sees that [scenario 1:] the source code may or may not be available
> > or [scenario 2:] the source code is a few (dozen key)clicks away. Which
> > is the superior RFC user experience? Which is the superior
> > interoperability experience for your company's products?
> >
> >> A direct link to to the specification is anyway out of the question. The
> >> reason is that the specification may be changed in the future and then a
> >> new version number will be given. Somebody may find a bug in the
> >> reference implementation (not that unlikely) and a change request is
> >> sent in. It that change request is approved the updated specification
> >> will be given the version number 4.2.0 which will result in that the
> >> filename becomes 26073-420.zip. Due to this a direct link can not be
> >> used.
> >
> >
> > Unless the old versions are going to be deleted, it would be nice to get
> > the reference code. The idea of a multi-rate vocoder is a very important
> > one, and I feel it is very important to allow quick access to code for
> > those who might have any influence on its development, e.g., most people.
> >
> >> Magnus Westerlund
> >>
> >> Multimedia Technologies, Ericsson Research ERA/T/VA
> >> ----------------------------------------------------------------------
> >> Ericsson Radio Systems AB | Phone +46 8 4048287
> >> Torshamsgatan 23 | Fax +46 8 7575550
> >> S-164 80 Stockholm, Sweden | mailto: [email protected]
> >
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email protected]
> https://www1.ietf.org/mailman/listinfo/avt
----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email protected]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo