RE: Voice codecs

Sure, but I point out that even when transcoding between AMR and EvRC, using
a strictly linear PCM, rather than the g.711 encoding, is quite helpful.
When it's wideband, it's more helpful.  You can also optimize a number of
sampling rate issues if you are not forced to an 8Khz sample rate in the
middle.  Depending on the exact pair, there may be other filtering
mechanisms that can improve quality.

Brian

> -----Original Message-----
> From: Albrecht.Schwarz@... [mailto:Albrecht.Schwarz@...]
> Sent: Tuesday, August 01, 2006 11:29 AM
> To: Brian Rosen
> Cc: 'Drage, Keith (Keith)'; richard@...; speermint@...
> Subject: RE: [Speermint] Voice codecs
> 
> 
> Just a technical comment concerning transcoding between codec types X and
> Z.
> In many cases isn't a direct transcoding X-to-Z possible.
> In general you need a "common denominator format" Y, used "transcoder
> internally" only. Transcoding relates then to X-to-Y-to-Z.
> 
> Note: Y could be e.g. "linear PCM encoding" (= linearized G.711) in case
> of
> narrowband audio codec types. Format Y could be a criteria for codec
> selection or transcoder selection respectively.
> 
> - Albrecht
> 
> 
> 
> 
> 
>                       "Brian Rosen"
>                       <br <at> brianrosen.n         To:
> <richard@...>, "'Drage, Keith \(Keith\)'" <drage@...>,
>                       et>                      <speermint@...>
>                                                cc:
>                       01.08.2006 17:17         Subject: RE: [Speermint]
> Voice codecs
> 
> 
> 
> 
> 
> Nope, it's more interesting than that.  Sure, each domain has a policy of
> what codecs it allows on its network, but if you want to avoid double
> transcoding, you want to know, really, what is happening on both sides of
> the peering, to see if you can optimize it.
> 
> Suppose A allows g.711 and AMR, and B allows g.711 and EvRC.  You know
> what
> is really going to happen.  The AMR handsets get transcoded to g.711 on A,
> the EvRC handsets get transcoded to g.711 on B and they "work".
> 
> But what you really want to know is whether there is a transcoder
> available
> on either side (or in the middle) for EvRC to AMR and vice versa.
> 
> If that example doesn't convince you, suppose A's list was g.711 and AMR-
> WB
> and B's list was g.711 and VMR-WB.
> 
> So, you don't want to force A or B to transcode to the federation's list
> if
> you can figure out what the "right" thing to do is.
> 
> You want to take the list of codecs the originating endpoint really can
> do,
> and the similar list from the terminating endpoint, and see if you can
> discover a resource that can bridge across the lists.
> 
> This isn't a policy issue really.
> 
> Brian
> 
> 
> 
> > -----Original Message-----
> > From: Richard Shockey [mailto:richard@...]
> > Sent: Tuesday, August 01, 2006 10:42 AM
> > To: 'Brian Rosen'; 'Drage, Keith (Keith)'; speermint@...
> > Subject: RE: [Speermint] Voice codecs
> >
> >
> >
> > Interesting problem but easily solvable.
> >
> > The issue as I see it is we have to separate anything that looks like
> > policy
> > and capabilities discovery from the basic issue if connectivity.
> >
> > Now one issue we have is how do you discover the acceptable codecs for a
> > particular federation.
> >
> > OK that is a simple database issue. Presumably based on the domain part
> of
> > the SIP URI how do you issue a query?
> >
> > I'm starting to think IRIS begins to look good here as the mechanism for
> > discovery of policy related information re a TN or a domain.
> >
> > When we did some work in the US ENUM forum we decided to specify that
> the
> > US
> > ENUM implementation in e164.arpa would use a IRIS database for what
> would
> > essentially be Line Level and or Whois like data associated with a E.164
> > number.
> >
> > We knew this would eventually be essential. Say you cannot connect to a
> > particular URI' what is the contact data associated with that URI you
> need
> > to report a problem etc.
> >
> > It would seem perfectly reasonable to construct various XML schemas
> > various
> > capabilities of federations and then query those. You have to have a
> > response mechanism that is structured and right now IRIS is the best
> > candidate we have for structured database queries.
> >
> >
> > http://www.ietf.org/html.charters/crisp-charter.html
> >
> >
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@...]
> > > Sent: Tuesday, August 01, 2006 8:33 AM
> > > To: 'Drage, Keith (Keith)'; speermint@...
> > > Subject: RE: [Speermint] Voice codecs
> > >
> > > I read this a couple of times before I grokked it.  I think you are
> > right
> > > in
> > > the big picture, but maybe not in the practical world we live in now.
> > >
> > > Ideally, you would like to "search" the available transcoder inventory
> > > among
> > > the originating, terminating, and possibly
> > > services-within-the-peering-fabric domains to see if you can find an
> > > available resource that bridge directly between the endpoint's actual
> > > capabilities.  We don't have any protocol mechanisms which would do
> > that.
> > > That involves a distributed discovery mechanism with two lists -- find
> > me
> > > an
> > > available transcoder that can bridge between any codec on list A and
> any
> > > codec on list B, and while we're at it, optimize two such discoveries
> > > simultaneously.  Ideally, you would like both sides of one call to go
> > > through the same resource, and not two different ones.
> > >
> > > Do we need to get to this new protocol before we have something
> > functional
> > > in SPEERMINT?  I think not.  Many interdomain wireless call today
> would
> > > transcode twice (from one wireless codec to G.711, across the PSTN to
> > > another carrier and transcode from G.711 to its codec).  We often do
> > this
> > > even if they are the same codec on both carriers.  I suspect we do the
> > > same
> > > thing for now, and work towards a better way.  I think the better way
> is
> > > not
> > > a SPEERMINT charter item, but perhaps we could write a requirements
> doc
> > > for
> > > someone else.
> > >
> > > It's an interesting problem.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Drage, Keith (Keith) [mailto:drage@...]
> > > > Sent: Tuesday, August 01, 2006 8:13 AM
> > > > To: Brian Rosen; speermint@...
> > > > Subject: RE: [Speermint] Voice codecs
> > > >
> > > > That is why I think that if we mandate transcoders, we should also
> > make
> > > > sure we have studied the issues to allow us to have the minimum
> number
> > > > of transcodes, and if that means new protocol, then so be it.
> > > >
> > > > Regards
> > > >
> > > > Keith
> > > >
> > > > > -----Original Message-----
> > > > > From: Brian Rosen [mailto:br@...]
> > > > > Sent: 31 July 2006 19:39
> > > > > To: 'Geoff Devine'; 'Livingood, Jason'; speermint@...
> > > > > Cc: 'Ed Okerson'; 'Lipford,Mark A [CTO]'
> > > > > Subject: RE: [Speermint] Voice codecs
> > > > >
> > > > > Okay, makes sense.  So, maybe it's more like, the federation
> > > > > agrees on minimal codec support, and participants must be
> > > > > prepared to transcode to that minimal set if their endpoints need
> > it.
> > > > >
> > > > > I don't think you can mandate anything that guarantees only
> > > > > one transcode.
> > > > > However desirable it may be.
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Geoff Devine [mailto:gdevine@...]
> > > > > > Sent: Monday, July 31, 2006 2:28 PM
> > > > > > To: Livingood, Jason; Brian Rosen; speermint@...
> > > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus
> > Darilion;
> > > > > > Henry Sinnreich
> > > > > > Subject: RE: [Speermint] Voice codecs
> > > > > >
> > > > > > In your codec architecture example, you say that the originator
> > may
> > > > > > have some strange and wonderful codec that is not supported by
> the
> > > > > > peer network.  I'd point out that the other 50% of the time,
> that
> > > > > > endpoint is the terminator in the call, not the originator.
> > > > >  I would
> > > > > > think that transcoding would be something that is
> > > > > negotiated as part
> > > > > > of the peering business arrangement.  In terms of $ per port,
> > > > > > transcoding is a relatively costly operation and somebody
> > > > > is going to
> > > > > > have to purchase and operate the transcoding equipment.
> > > > > >
> > > > > > Transcoding, like echo cancellation, is something you want to
> > avoid
> > > > > > doing extra times since it degrades voice quality.  A path
> > > > > that goes,
> > > > > > say, from AMR to G.711 to iLBC is going to have a lower MOS
> > > > > score than
> > > > > > a path that goes AMR to iLBC.  Ideally, you don't want to
> > > > > transcode at
> > > > > > all since that gives you the least impairment and the least
> delay.
> > > > > >
> > > > > > Geoff
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Livingood, Jason
> [mailto:Jason_Livingood@...]
> > > > > > Sent: Monday, July 31, 2006 9:47 AM
> > > > > > To: Brian Rosen; speermint@...
> > > > > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff
> Devine;
> > > > > > Klaus Darilion; Henry Sinnreich
> > > > > > Subject: RE: [Speermint] Voice codecs
> > > > > >
> > > > > > Brian wrote:
> > > > > >
> > > > > > > I did say something in my message which may have escaped some
> > > > > > > notice.  I said "origination side".  One of the things
> > > > > you have to
> > > > > > > get right on any kind of part like transcoding is what
> > > > > assumptions
> > > > > > > are made.  You can assume the origination side does it, the
> > > > > > > destination side does it or the peering fabric itself does it.
> > I
> > > > > > > think it's essential to choose one, or we won't have
> > > > > > > interoperability.  More than one is always possible, but at
> > least
> > > > > > > one is required.  I think origination side is best: it means
> > that
> > > > > > > across the peering fabric, there is at least one common codec.
> > > > > >
> > > > > > So, it is looking convincingly now that WG consensus is against
> a
> > > > > > lowest common denominator codec.  
> > > > > >
> > > > > > But Brian raises an interesting question here.  Somewhere in our
> > > > > > drafts (several of them) we *may* need to consider optional
> > > > > inclusion
> > > > > > of a transcoding function and describe how it might be
> > > > > implemented.
> > > > > > When we take up that discussion, I think Brian poses an
> > > > > interesting question.
> > > > > >
> > > > > > If I consider it from the perspective of some operator that
> > > > > is using
> > > > > > all the major codecs in my endpoints, and someone connects
> > > > > with some
> > > > > > obscure codec then I can see an arguement for having the
> > originator
> > > > > > perform any transcoding.  (And if that is indeed the case,
> > > > > it may even
> > > > > > be like lots of other stuff an originating network may or
> > > > > may not do
> > > > > > that we don't care about and call out of scope.)
> > > > > >
> > > > > > Jason
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Speermint mailing list
> > > > > Speermint@...
> > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > Speermint@...
> > > https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> Speermint mailing list
> Speermint@...
> https://www1.ietf.org/mailman/listinfo/speermint
> 
>