RE: Voice codecs

Recognize that we are in fact out of charter scope in SPEERMINT, even if
this is an interesting problem to think about.

"Cost" is a metric we often use in "routing" protocols.  We usually don't
directly attribute the metric to the literal money exchange between parties,
but there is a relationship.  I think including a "cost" metric is not
unreasonable in the algorithm.

To me, the interesting part here is the "two list" aspect of the routing
mechanism.  Usually, the goal is simpler and the path choices more complex.
Other than that, it seems pretty straightforward to have a distributed
resource discovery protocol with all the right characteristics.  It really
does look like a routing protocol: transcoders advertise availability of
their resource within a cloud, with the announcements are propagated within
and between domains.  Costs are domain-relative.  Since the availability of
the resource can change quickly (due to use), it needs to work pretty fast,
but the scale is not really that bad.  You'll need to first look for direct
(X to Z) and then indirect (X to Y, Y to Z) transcoding.  Might be useful to
somehow take into account the various metrics that would allow you to
optimize the choice of Y's if there were more than one.

As I said, it's pretty interesting.

Brian

> -----Original Message-----
> From: Geoff Devine [mailto:gdevine@...]
> Sent: Tuesday, August 01, 2006 11:40 AM
> To: Brian Rosen; richard@...; Drage, Keith (Keith);
> speermint@...
> Subject: RE: [Speermint] Voice codecs
> 
> In your wideband codec transcoding example (a good one, by the way),
> there are only so many possible business arrangements:
> 
> The originator transcodes
> The terminator transcodes
> A transcodes, always
> B transcodes, always
> C, a third party, transcodes
> 
> I think any solution we come up with needs to support all of these
> possibilities.
> 
> Geoff
> 
> -----Original Message-----
> From: Brian Rosen [mailto:br@...]
> Sent: Tuesday, August 01, 2006 11:18 AM
> To: richard@...; 'Drage, Keith (Keith)'; speermint@...
> 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