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

From: "Jae-Yong Lee" <[email-masked]>
Date: Thu, 1 May 2003 17:57:37 +0900

Hello all,

I regret not being able to respond earlier.
It took some time to contact all the Korean operators and reconfirm 
their opinions related to this issue.
As the representative of Korean operators (SKT/KTF/LGT) for file 
format issues in 3GPP2, I'd like to clarify the current situation for
Korean operators and deliver our opinions on this issue. 
(I cc:ed relevant people from the operators.)

>> 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).  

This is not correct.
The EVRC storage format described in the evrc-smv draft is utilized 
for Korean operators in such way as described in the current 3GPP2 
FFMS specification, which is actually the only way for EVRC media 
storage in the 3GPP2 multimedia file format (.3g2).
The way of storing EVRC media in .3g2 file is exactly same as the 
way described in the evrc-smv draft except for the magic number, 
"#!EVRC\n", which will not be included in the .3g2 file format. 
That is conceptually same as AMR storage in 3GPP file format. 
One of the most important rationale behind this is to facilitate the 
conversion of 3GPP2 files from/to EVRC-only files (.3g2 <-> .evc),
which may be very helpful for some applications, e.g., MMS.

Having said that, Nextreaming is not the only one that implements 
and uses it. The relevant terminal and system vendors for Korean 
operators have completed implementation based on this format and 
verified interop. 
Korean operators (also many others in 3GPP2 as far as I understand) 
have been waiting for the evrc-smv draft with the storage method to be 
approved as an RFC and are looking forward to it.
We also share the opinion that the evrc-smv internet draft is
independent
of the possible registration of MIME type for .qcp. 

BR,

Jay

> -----Original Message-----
> From: Adam Li [mailto:[email-masked]]
> Sent: Thursday, April 24, 2003 5:34 PM
> To: 'Colin Perkins'
> Cc: [email-masked]; 'Scott Bradner'; 'Allison Mankin';
> [email-masked]; Jae-Yong Lee; [email-masked];
> [email-masked]
> Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) 
> 
> 
> 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
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Colin Perkins
> > Sent: Wednesday, April 23, 2003 6:52 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,
> > 
> > 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
> > 
> > 
> > 
> > --> "Adam Li" writes:
> > >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
> > >
> > >
> > >> -----Original Message-----
> > >> 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,
> > >>
> > >> 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
> > >>
> > >>
> > >>
> > >>
> > >> --> "Adam Li" writes:
> > >> >
> > >> >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
> > >> _______________________________________________
> > >> Audio/Video Transport Working Group
> > >> [email-masked]
> > >> https://www1.ietf.org/mailman/listinfo/avt
> > >
> > >_______________________________________________
> > >Audio/Video Transport Working Group
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/avt
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/avt
> 
> 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt