Subject: RE: [Speermint] Voice codecs

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Fri, 28 Jul 2006 09:32:11 -0500

I concur with Jason that a set of lowest common denominator codecs needs
to be recommended/supported to allow fastest VoIP peering to work. 
Let us make this minimum set of list.
For example, the minimum set of codec list = {G.711, EvRC, ...}

Thank you.

Sohel Khan 

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Friday, July 28, 2006 7:46 AM
To: Klaus Darilion; Henry Sinnreich
Cc: [email-masked]; Greg Herlein; Ed Okerson; Lipford, Mark A [CTO]
Subject: RE: [Speermint] Voice codecs

We ought to at least recognize that in the VoIP server & equipment
market G.711 is probably the one with widest deployment (someone will
now surely cite Skype downloads as a datapoint, I am very familiar with
it and wish someone from eBay/Skype was participating here).  In
wireless, it appears AMR is biggest (due to use by GSM), with EVRC in
second place.  This group is not going to be able to push implementation
of one codec or another (nor should we), whether we like the business
model or social model represented by that codec or not.  We do want to
figure out how to get the most people VoIP peering the fastest, and that
may (or may not) necessitate some lowest common denominator codecs.
That is far from a foregone conclusion and is a subject that will have
to be worked out by the WG over time.

This of course would not preclude use of other codecs and then endpoints
could use SIP to (normally) negotiate a different / preferred codec that
may be newer, lower bandwidth, higher fidelity, less expensive to
license, etc.

This may also be a moot point in the near future.  A recent conversation
with an endpoint maker gave me the impression that it will be pretty
easy to have all of the codecs we have mentioned here in a very low cost
endpoint in the near future.  Any hardware makers wish to comment on the
futures / possibilities?

So keep up the discussion... 

Jason 

> -----Original Message-----
> From: Klaus Darilion [mailto:[email-masked]]
> Sent: Thursday, July 27, 2006 6:58 PM
> To: Henry Sinnreich
> Cc: [email-masked]; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]
> Subject: RE: [Speermint] Voice codecs
> 
> On Thu, July 27, 2006 22:59, Henry Sinnreich said:
> > Mark Lipford writes:
> >
> >> I am OK with SPEEX and iLBC as defaults
> >
> > Thanks and I am very happy we can come closer to an
> agreement on this!
> >
> > Are there any other opinions on using SPEEX and iLBC (RFC
> 3951 and RFC
> > 3952) as defaults for IP-IP broadband?
> 
> Yes. Please count the number of terminal adaptor and SIP hardphones 
> that support SPEEX and iLBC versus G.711.
> 
> regards
> klaus
> 
> 
> >
> > Thanks again, Henry
> >
> > -----Original Message-----
> > From: Lipford, Mark A [CTO] [mailto:[email-masked]]
> > Sent: Thursday, July 27, 2006 3:27 PM
> > To: Henry Sinnreich
> > Cc: Khan, Sohel Q [CTO]; [email-masked]; Greg Herlein; Francois 
> > Menard; Ed Okerson
> > Subject: RE: [Speermint] Voice codecs
> >
> > See inline
> >
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:[email-masked]]
> > Sent: Thursday, July 27, 2006 3:01 PM
> > To: Lipford, Mark A [CTO]
> > Cc: Khan, Sohel Q [CTO]; [email-masked]; Greg Herlein; Francois 
> > Menard; Ed Okerson
> > Subject: RE: [Speermint] Voice codecs
> >
> > Mark Lipford writes:
> >
> >> Can we support some mechanism for support codec
> negotiations with a
> >> default "fall back" to G.711
> >
> > Technically, the uncompressed G.711 (1960's PCM) is definitely the 
> > worst choice for a default:
> >
> > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have
> > BB?)
> > - Highest bandwidth consumed: Almost 90 kb/s with
> RTP/UDP/IP overhead
> > - There are better mechanisms for Fax.
> >
> > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and
> what are
> > your selection criteria? Can you explain?
> > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I 
> > used
> > G.711 due to 19 years in Telco :-)  The main point I was wanting to 
> > try and gain some agreement around is that narrowband (i.e.
> 3GPP and
> > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and 
> > AMR.  The I-D I am looking at is about Requirements for VoIP 
> > interconnection.  If this is the case it appears that support for 
> > these codecs seems to make some sense.  Again, as far as
> SEEX and iLBC
> > are concerned that's OK, I'm just an old telco guy.
> >
> >
> >
> > Thanks, Henry
> >
> > -----Original Message-----
> > From: Lipford, Mark A [CTO] [mailto:[email-masked]]
> > Sent: Thursday, July 27, 2006 1:46 PM
> > To: Francois Menard; Henry Sinnreich
> > Cc: Khan, Sohel Q [CTO]; [email-masked]; Greg Herlein;
> Ed Okerson
> > Subject: RE: [Speermint] Voice codecs
> >
> > This is in response to the question to Sohel regarding Broadband.
> >
> > Yes, we are very involved in broadband, and believe
> wireless broadband
> > will become extremely active in the next few years, but the
> reality is
> > that in the 3G work both EVRC and AMR are both widely deployed and 
> > with IMS deployments starting to "spring up" around the
> global it is
> > probably important to also consider these needs.
> >
> > Can we support some mechanism for support codec negotiations with a 
> > default "fall back" to G.711 or some other well known default?
> >
> > I do believe that we need to also consider the narrowband
> deployments.
> >
> > Thanks
> >
> > -----Original Message-----
> > From: Francois Menard [mailto:[email-masked]]
> > Sent: Thursday, July 27, 2006 1:41 PM
> > To: Henry Sinnreich
> > Cc: Khan, Sohel Q [CTO]; [email-masked]; Greg Herlein;
> Ed Okerson
> > Subject: Re: [Speermint] Voice codecs
> >
> >
> > I come from Sherbrooke and you know I vote hands down for Speex
> >
> > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet 
> > than people are willing to give him credit for.
> >
> > F.
> >
> > --
> > Francois D. Menard
> > Project Manager/Charge de projet
> > Xit telecom inc.
> > 1350 Royale # 800
> > Trois-Rivieres, QC, G9A 4J4
> > Tel: +1 819 374 2556 x 268
> > Cell: +1 819 692 1383
> > [email-masked]
> >
> >
> > On Thu, 27 Jul 2006, Henry Sinnreich wrote:
> >
> >> Sohel,
> >>
> >>> A minimum set of Codecs needs to be supported that includes EvRC.
> >>
> >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and
> > SPEEX?
> >>
> >> - Open source code?
> >> - Licensing fees?
> >> - Audio bandwidth?
> >> - Audio quality package?
> >> - APIs and codec abstraction for developers?
> >> - Independent lab quality assessments, etc.?
> >>
> >> More generic:
> >>
> >> How do all such closed, licensed, _narrowband voice only_ codecs
> > benefit
> >> global Internet communications and why should the IETF care?
> >>
> >> Have you heard of broadband? :-)
> >> (Note: I am a happy EVDO Sprint user).
> >>
> >> Thanks, Henry
> >>
> >> -----Original Message-----
> >> From: Khan, Sohel Q [CTO] [mailto:[email-masked]]
> >> Sent: Thursday, July 27, 2006 10:28 AM
> >> To: Jean-Francois Mule; [email-masked]
> >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt
> >>
> >>
> >> These issues were discussed before; however, I am trying to reopen 
> >> the discussion.
> >>
> >> Section 3.3:
> >>
> >> On Codec requirements:
> >> A minimum set of Codecs needs to be supported that includes EvRC.
> >>
> >> On Editor's note:
> >> Fax, DTMF signaling, TTY/TDD, instant messaging, and
> presence need to
> > be
> >> supported.
> >>
> >>
> >> Thank you.
> >>
> >> Sohel Khan, Ph.D.
> >> Technology Strategist
> >> Sprint-Nextel
> >> 913-794-1470 (office)
> >> 913-486-3145 (cell)
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Speermint mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/speermint
> >>
> >> _______________________________________________
> >> Speermint mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/speermint
> >>
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> 
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 28 Jul 2006 10:45:19 -0400

Sohel

I think this is a mistake.  

If I were, just to pick an example, the GSMA, and I "sponsored" a peering
system, just for GSMA members, then I don't want EvRC or G.711 in my fabric.

If I am organizing an IM Peering system, then I don't want ANY voice codec.

If I am organizing a video conferencing peering system, I need something
quite a bit different than what a VoIP peering system needs.

SPEERMINT documents should work well for these federations.  This is why I
don't think we can specify an actual codec list.

I'd LIKE to do it, because I'd like to be able to build one thing that works
with all federations, but if GSMA is a federation and the IM guys make one,
EvRC just doesn't fit, no way, no how.

If there was a real minimum, it would have to be G.711 alone, no other
codec, but the IM guys would really squeal.

Brian

> Sent: Friday, July 28, 2006 10:32 AM
> To: Livingood, Jason; Klaus Darilion; Henry Sinnreich
> Cc: [email-masked]; Greg Herlein; Ed Okerson

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 28 Jul 2006 16:55:34 +0200

In principle I like Brians idea that each federation defines its minimum set of codecs they use
 
But keeping in mind the transit case, we may also need a minimum set defined
so we should look at large groups of potential "customers" od speermint
and define "their" codec
 
which is as I got from this discussion: G.711, AMR and EvRC (sofar)
 
Richard

________________________________

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Fr 28.07.2006 16:45
An: 'Khan, Sohel Q [CTO]'; 'Livingood, Jason'; 'Klaus Darilion'; 'Henry Sinnreich'
Cc: [email-masked]; 'Greg Herlein'; 'Ed Okerson'
Betreff: RE: [Speermint] Voice codecs

Sohel

Brian

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 28 Jul 2006 17:02:23 +0200

Another possibility would be to let each federation define their codecs
and in the transit case the originating network is oblidged to do transcoding
(also as Brian suggests)
 
Richard

Von: Stastny Richard [mailto:[email-masked]]
Gesendet: Fr 28.07.2006 16:55
An: Brian Rosen
Cc: [email-masked]
Betreff: Re: [Speermint] Voice codecs

Richard

Sohel

Brian

---

From: Daryl Malas <[email-masked]>
Date: Fri, 28 Jul 2006 09:50:39 -0600

I generally agree with Richard and Brian's comments.  I don't understand
this conversation. Does RFC 3261 say all SIP UA's MUST support G.711 or
any other codec?   This doesn't make any sense to me.  When I setup a
peering relationship with someone, I'm going to say..."Hey, I use the
"X" codec....I hope you do too, or we'll have to do some transcoding!"
I might suggest another method too...as defined in RFC 3261, a peer
could send an OPTIONS message to query for supported codecs, then
determine which one it supports and then send the appropriate codec in
the SDP.  I think much of this will be sorted out in setting up the
peering relationship....as far as "Transit" peers...uh...oh...here we go
again. ;-)  Transits will naturally occur as peers are members of more
than one federation and opt to offer hosted signaling functions for
agreed upon peers in other federations.  Transcoding may have to occur
here for any hosted media functions.  I just think explaining how this
might occur is a good step, but saying any codec is a MUST is a mistake.

Daryl