Subject: [AVT] The storage format of EVRC/SMV vocoder (resent)

From: "Adam Li" <[email-masked]>
Date: Tue, 22 Apr 2003 00:31:29 -0700

Dear Steve, Colin, AVT'ers,

The issue of the storage format of the EVRC and SMV vocoders in the MIME
registration has came up a while ago, and has caused the last minute
holding of the MIME registration for these two vocoders. The issue has
been discussed thoroughly here on the mailing list in the San Francisco
meeting. The reasons of each side of the argument have been well
presented. Now it may be time to make a decision?

Like many other issues in our AVT WG, the decision here is ultimately
relying on the judgment of our chairs. During the two and half years
that this draft is being developed in the AVT, the course of the draft
has benefited greatly from your guidance. After the open and ego-free
discuss that our chairs called upon at the meeting session, it may be
another good time to hear the opinions from the chairs and get some help
on the decision from their experience and vision on which one will
reflect the consensus of the AVT and would be most beneficial to the
whole Internet and telecom industry who will use our specification.

Below is the summary of the rationales for each of the choices:

  draft-ieft-avt-evrc-smv-03.txt    |    draft-garudadri-qcp-00.txt
------------------------------------+--------------------------------
(1) Mature specification, been      | (1) Brand new ID
    developed for 2.5 years in AVT  |
------------------------------------+--------------------------------
(2) Covers both EVRC and SMV        | (2) Only cover EVRC
------------------------------------+--------------------------------
(3) Referred to by 3GPP2(*) FFMS    | (3) 
    specifications                  |
------------------------------------+--------------------------------
(4) Implemented and used by many 3G | (4) Supported in Eudora
    telecom operators (e.g., SKT,   |
    KTF, LGT). The interoperability |
    has been tested among them.     |
------------------------------------+--------------------------------
(5) Simple and efficient design,    | (5)
    quick to implement              |
------------------------------------+--------------------------------
(6) Registration already in IANA,   | (6)
------------------------------------+--------------------------------
(7) Supported and developed by 7    | (7) Supported and developed by
    companies and universities      |     Qualcomm
    (including Qualcomm)            |
------------------------------------+--------------------------------
(8) No IP related to this format    | (8) IP situation unclear
------------------------------------+--------------------------------

(*) ERVC and SMV are both vocoders developed and defined in the
international consortium 3GPP2 (http://www.3gpp2.org) for the next
generation wireless network cdma2000.

Thank you very much.

Adam

PS. This is a resent of the previous message, which did not seem to go
through maybe because of the long cc list. If you think anyone is missed
out, please let me know. Thanks.

> -----Original Message-----
> From: Adam Li [mailto:[email-masked]]
> Sent: Saturday, March 15, 2003 9:20 PM
> To: 'Ietf-Avt'
> Cc: [email-masked]'; 'Scott Bradner'; 'Colin Perkins'; 'Allison
> Mankin'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; 'magnus.westerlund@era-
> t.ericsson.se'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]'
> Subject: Issues for the file format for EVRC/SMV vocoder
> 
> Hi folks,
> 
> The topic of the file format for EVRC/SMV vocoders hopefully will be
> discussed in this meeting at San Francisco. Below is a list of the
> issues that might be related to this topic. They are listed here as
> potential issues for you to consider before the discussion at the
> meeting.
> 
> (1) Technically differences. Is there much difference in efficiency
> and performance between the format in draft-ietf-avt-evrc-smv and
> draft-garudadri-qcp? Are the differences simply on the file syntax?
> 
> (2) Completeness. For EVRC codec data, formats defined in both
> document can handle it. For SMV codec data, the format defined in
> draft-ietf-avt-evrc-smv is currently the only file format that
> handles SMV data. draft-garudadri-qcp does not handle SMV at this
> time.
> 
> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv has
> its first version submitted to AVT on November 2000. It has been
> actively worked on all these years, and is co-authored by people
> from seven companies and universities. It is currently on the RFC
> editor's queue. draft-garudadri-qcp is submitted in February 2003.
> Will there be concerns about the maturity of the drafts,
> particularly the handling of SMV codec hasn't been written in the
> later draft yet?
> 
> (4) The recognition. Since EVRC and SMV codec are designed in 3GPP2
> for their CDMA networks, formats recognized by them are likely to be
> the most widely used format for those codecs. Which of the formats,
> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has
> been considered by 3GPP2 for the format for storing EVRC and SMV
> data?
> 
> (5) Document organization. Even though this is a rather minor point,
> but would there be enough reasons to trade-off for the additional
> complexity for having the MIME registration of EVRC/SMV refering to
> a separate and yet to be complete draft?
> 
> Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If
> we want to consider deleting the file format that is in the draft
> for almost two years in the last minute before it becomes an RFC and
> using another yet to be complete new draft instead, we should be
> providing ourselves with the clear justification for doing so.
> 
> I will not be there for the discussion unfortunately since I have
> not made the plan to attend in advance. However, I hope the list of
> potential issues above might be useful for us to discuss and
> consider.
> 
> Wish we have a fruitful meeting in San Francisco.
> 
> Adam

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Apr 2003 13:27:23 -0400

Adam,

The format specified in draft-garudadri-qcp-00.txt clearly needs to be
published, and to have a MIME type registered, since it has been used by
several applications for some years now. 

What is unclear is whether draft-ieft-avt-evrc-smv-03.txt should refer to
that format, or if it should continue to use the alternative format. The
usual arguments apply: having two formats is clearly worse than one, but
there may be technical or political reasons why the new format is to be
preferred for some uses. 

As the minutes from the recent AVT meeting note, the main users of the
format in draft-ieft-avt-evrc-smv-03.txt seem to be 3GPP2. It is currently
unclear if they have implementations of the file format, and if they chose
it for technical reasons or because it it was the only format they knew. We
are hoping to get input from them, to clarify their position.

Colin

---

From: "Adam Li" <[email-masked]>
Date: Tue, 22 Apr 2003 23:45:12 -0700

Dear Colin,

Thank you very much for your email. We all have agreed on the fact that
.QCP is used by Eudora while .EVC/.SMV are used by 3G service providers.

However, I have difficulty seeing the rationale for your opinion that
the registration of .QCP is clearly needed while the registration of
.EVC/.SMV is the opposite. Would you mind explain to us AVT'ers your
rationales and pointing out the factors that we missed in the discussion
so we can better understand your opinions?

With all the factors that have been expressed on this issue which are
summarized in the previous email, it does not seem that the major
consensus is inclining that way. Maybe we missed something?

Your opinion is very much appreciated.

Adam

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Colin Perkins
> Sent: Tuesday, April 22, 2003 10:27 AM
> To: Adam Li
> Cc: [email-masked]; 'Scott Bradner'; 'Allison Mankin';
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent)
> 
> Adam,
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 23 Apr 2003 09:52:17 -0400

Adam,

My understanding is that there have been implementations of the QCP format
for several years now, but the MIME type has not been registered. The MIME
type should be registered, to document this use.

This is independent of whether the EVRC/SMV file format is also registered.

Colin

---

From: Randall Gellens <[email-masked]>
Date: Wed, 23 Apr 2003 15:29:55 -0700

>    draft-ieft-avt-evrc-smv-03.txt    |    draft-garudadri-qcp-00.txt

I'm not sure it makes sense to call a specification "mature" based on 
the amount of time between inception and standardization.  That is, I 
believe "mature" refers to the amount of time multiple interoperating 
implementations have been deployed.

I also do not believe it is accurate to imply that the qcp format is 
not mature simply because the Internet Draft is new.  In reality, the 
specification has been available for some years now, and there are a 
number of implementations which do interoperate.

The qcp format covers QCELP 13K as well as EVRC.  An updated version 
covers SMV as well.

My understanding is that the 3GPP2 FFMS specifications refer to both 
(it is waiting on RFC publications for both).

The qcp format is supported by PureVoice and QuickTime, both 
available on Windows and Macs.   Also, a large number of CDMA 
handsets deployed today create and play qcp files and use this to 
interoperate.  A number of services and tools on the web use the qcp 
format (often calling it PureVoice).

My information on the implementation of the evrc-smv draft's format 
is that Nextreaming uses this as an internal intermediate format 
prior to generating ".3g2" files (as specified in the 3GPP2 FFMS 
specification, which include both formats).  That is, my 
understanding is that this implementation is not used to exchange 
data.  If my understanding is not correct, please let me know.  Can 
you please provide more information on the telecom operators (e.g., 
SKT,  KTF, LGT) implementations that you refer to, and if these 
implementations are used to exchange data in the format specified in 
the evrc-smv draft?

The text in the qcp draft is more confusing than it should be.  An 
updated version is about to be published which replaces the pseudo-C 
description with clear ABNF, showing that the two formats are 
actually very close.  In essence, the qcp format is the same as the 
evrc-smv format, except that some additional data is present at the 
start of the file.  But in both formats, individual vocoder frames 
are stored with a preceding byte which describes the frame size.

The qcp format is supported/implemented by QuickTime, PureVoice, and 
numerous handset vendors and operators, plus a number of web services.

There is no IP associated with the the qcp format.  (The draft 
includes an explicit statement that it is in full compliance with all 
provisions of Section 10 of RFC2026.)

---

From: Randall Gellens <[email-masked]>
Date: Wed, 23 Apr 2003 15:33:49 -0700

At 11:45 PM -0700 4/22/03, Adam Li wrote:

>   We all have agreed on the fact that

This isn't accurate.  As I noted in my earlier message to the list, 
the QCP format is used by QuickTime and PureVoice, as well as a large 
number of CDMA handsets, and a number of web services.  (Please see 
my earlier message for more detailed comments.)
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Misery loves company, but company does not reciprocate.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Adam Li" <[email-masked]>
Date: Thu, 24 Apr 2003 01:34:12 -0700

Dear Colin,

Thank you very much for your email. I completely agree with you that
these two drafts are rather independent drafts which are not necessarily
exclusive of each other. As you mentioned, both formats have been used
by one or more applications in the software and telecom industries, and
we all agree with you that it will be very helpful to listen to the
opinions of the industries which will rely upon IETF for the protocol
standards.

The registration MIME type of the EVRC and SMV codec has been halted at
IANA in the last minute because of the new draft on this storage format
issue. From the perspective of participants in IETF and as
engineers/researchers, we all wish to see the RTP payload format for
these codecs being used rather than proprietary formats being
implemented in the systems which will cause the interoperability
problems later. It will be particularly disturbing if this would happen
while the international standards are waiting to replace the "Work in
progress" with "RFC xxxx".

The RTP payload type specification for EVRC and SMV has been in working
in AVT for 2.5 years, and is now stalled at RFC editor's queue. Two and
a half years is a long time in the telecommunication industry, and it is
a long time for Internet community too. 

I believe whatever proposal one supports, we all hope to see a swift
ending to this issue with a fair conclusion while giving each of the
proposed format the objective consideration it deserves.

Thank you very much,

Adam

> Sent: Wednesday, April 23, 2003 6:52 AM
> To: Adam Li
> >> The format specified in draft-garudadri-qcp-00.txt clearly needs
> to
> >> be
> >> that format, or if it should continue to use the alternative
> format.
> >> The
> >> usual arguments apply: having two formats is clearly worse than
> one,
> >> but
> >> there may be technical or political reasons why the new format is
> to
> >> be
> >> preferred for some uses.
> >>
> >> As the minutes from the recent AVT meeting note, the main users
> of
> >> the
> >> unclear if they have implementations of the file format, and if
> they
> >> chose
> >> it for technical reasons or because it it was the only format
> they
> >> knew. We
> >> >The issue of the storage format of the EVRC and SMV vocoders in
> the
> >> MIME
> >> >holding of the MIME registration for these two vocoders. The
> issue
> >> has
> >> >has benefited greatly from your guidance. After the open and
> ego-
> >> free
> >> >discuss that our chairs called upon at the meeting session, it
> may
> >> be
> >> >another good time to hear the opinions from the chairs and get
> some
> >> help
> >> >------------------------------------+---------------------------
> ---
> >> --
> >> >------------------------------------+---------------------------
> ---
> >> --
> >> >------------------------------------+---------------------------
> ---
> >> --
> >> >------------------------------------+---------------------------
> ---
> >> --
> >> >------------------------------------+---------------------------
> ---
> >> --
> >> >------------------------------------+---------------------------
> ---
> >> --
> >> >------------------------------------+---------------------------
> ---
> >> --
> >> >(7) Supported and developed by 7    | (7) Supported and
> developed
> >> by
> >> >------------------------------------+---------------------------
> ---
> >> --
> >> >------------------------------------+---------------------------
> ---
> >> --
> >> >
> >> >PS. This is a resent of the previous message, which did not seem
> to
> >> go
> >> >through maybe because of the long cc list. If you think anyone
> is
> >> missed
> >> >> The topic of the file format for EVRC/SMV vocoders hopefully
> will
> >> be
> >> >> issues that might be related to this topic. They are listed
> here
> >> as
> >> >> for their CDMA networks, formats recognized by them are likely
> to
> >> be
> >> >> complexity for having the MIME registration of EVRC/SMV
> refering
> >> to
> >> >> for almost two years in the last minute before it becomes an
> RFC
> >> and
> >> >> not made the plan to attend in advance. However, I hope the
> list
> >> of