Voice codecs

headers Stastny Richard | 1 Aug 2006 19:03

>It seems to me that CODEC's are indeed capabilities of networks -- but only
>insofar as to their connection to the PSTN. Establishing policies or
>exchanging these kind of capabilities to determine a best next-hop network
>would be senseless.

Perfectly correct. Codecs are end-device capabilities and an IP-PSTN gateway is also

an end-device, as far as IP is concerned.

So codecs are not an IP network issue

-sta

________________________________

Von: Patrick Melampy [mailto:PMelampy@...]
Gesendet: Di 01.08.2006 18:11
An: 'Geoff Devine'; 'Brian Rosen'; richard@...; 'Drage, Keith
(Keith)'; speermint@...
Betreff: RE: [Speermint] Voice codecs

On problem with "codec policies", is that they are not necessarily
transitive. Transit networks may not support CODEC's that are indeed
supported by the originator/terminator. Even the terminating network may not
support the terminators CODEC capabilities. For example, we current use a
VOIP service, that only uses G.711 for calls going to the PSTN or other IP
Networks. However, when we call another phone, connected to these
"restrictive networks", we can negotiate to G.729.

It seems to me that CODEC's are indeed capabilities of networks -- but only
insofar as to their connection to the PSTN. Establishing policies or
exchanging these kind of capabilities to determine a best next-hop network
would be senseless.

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

_______________________________________________
Speermint mailing list
Speermint@...
https://www1.ietf.org/mailman/listinfo/speermint

Re: Voice codecs