IETF speermint Working Group

Richard Shockey | 1 Aug 2006 16:42

Picon

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

(Continue reading)

Brian Rosen | 1 Aug 2006 17:17

RE: 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@...

(Continue reading)

Hadriel Kaplan | 2 Aug 2006 00:29

RE: Voice codecs

To me the codec issue is just too complex to deal with in Speermint.  It has
cost, demand, performance, and other issues which are different for
everyone, hard to quantify, and harder to cover generically in a BCP.  

For instance, your example assumes xcoding from AMR to EVRC would be the
best/optimal outcome.  It may be from a voice quality perspective, but may
not be from a cost perspective. (and it may even be the same quality)  It's
not a one-size-fits-all.   Also, I disagree that both will xcode to 711 in
your example... it depends.

IMHO, the "protocol" for discovering the codec capabilities of each side
already exists: it's SDP.  The advantage of using it beyond the obvious KISS
principle is it allows a provider to have a mixture of devices and codecs
instead of normalizing to one codec policy for all devices all the time.
It's even used today for including xcoders dynamically per call, but there's
no question it's not perfect for everyone/every-case.  Obviously there are
advantages to knowing the set ahead of time, but I would think that's an
issue for much later after much beer. 

-hadriel

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

(Continue reading)

Geoff Devine | 1 Aug 2006 17:39

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

(Continue reading)

Patrick Melampy | 1 Aug 2006 18:11

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

(Continue reading)

Stastny Richard | 1 Aug 2006 19:03

Picon

Re: Voice codecs

>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

(Continue reading)

Albrecht.Schwarz | 2 Aug 2006 08:20

Picon

Picon

Re: Voice codecs


>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

Disagree to the last statement. There are also IP-to-IP gateways, and some
are just media-agnostic, but there are also media-aware IP-to-IP gateway
entities defined.
One example is the MSF "S-SBG to D-SBG Interface Implementation Agreement;
H.248 Profile for Distributed Session Border Gateways": § 5.16.1 is about
transcoding for IP-to-IP.

- Albrecht

                                                                                                                                  
                      "Stastny                                                                                                    
                      Richard"                 To:      "Patrick Melampy" <PMelampy@...>, "Geoff
Devine"               
                      <Richard.Stastny         <gdevine <at> cedarpointcom.com>, "Brian Rosen"
<br@...>,                    
                       <at> oefeg.at>               <richard@...>, "Drage, Keith \(Keith\)"
<drage@...>,                 
                                               <speermint@...>                                                               
                      01.08.2006 19:03         cc:                                                                                
                                               Subject: Re: [Speermint] Voice codecs                                              

>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

(Continue reading)

Khan, Sohel Q [CTO] | 2 Aug 2006 00:44

Picon

RE: Voice codecs


How about the following statements:

"IETF SPEERMINT shall not mandate a codec or a minimum set of codecs.
IETF VoIP peering documents will specify/reference Codec
negotiation/discovery techniques among providers. Members of a
federation will mutually determine a minimum acceptable set of codec and
support of transcoding functions."

"IETF SPEERMINT shall not mandate a codec or a minimum set of codecs.
IETF VoIP peering documents will specify/reference Codec
negotiation/discovery techniques among providers. Members of a
federation will mutually determine a minimum acceptable set of codec and
support of transcoding functions. Trascoding required for a call
originating from outside the federation ...(?).  IETF SPEERMINT may
recommend (as opposed to mandate) the following codecs ... as default"

Thanks.

Sohel Khan

Drage, Keith (Keith | 1 Aug 2006 14:12

Picon

RE: 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;

(Continue reading)

Henry Sinnreich | 1 Aug 2006 19:22

Picon

RE: Voice codecs

It is heartening to see the interest in codecs after all in this group!

> That is why I think that if we mandate transcoders

A much better approach is to mandate SPEEX and only _allow_ (tolerate)
transcoders for backward compatibility with legacy equipment.

See why at: http://speex.org/docs.html and we can discuss the pros and
cons of what is truly the basics of any VoIP peering: Voice quality for
the user.

Users could not care less about all the signaling issues that are
debated here, but they will instantly perceive the quality of the
peering.

Thanks, Henry

-----Original Message-----
From: Drage, Keith (Keith) [mailto:drage@...] 
Sent: Tuesday, August 01, 2006 5: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

(Continue reading)

Andrew Newton | 1 Aug 2006 23:15

Picon

Re: Voice codecs

Henry Sinnreich wrote:
> It is heartening to see the interest in codecs after all in this group!

I agree.

> A much better approach is to mandate SPEEX and only _allow_ (tolerate)
> transcoders for backward compatibility with legacy equipment.

I think we should definitely explore this option.

> See why at: http://speex.org/docs.html and we can discuss the pros and
> cons of what is truly the basics of any VoIP peering: Voice quality for
> the user.

Buried in the FAQ at that site, I found this:

> Can Speex pass DTMF?
> 
> I guess it all depends on the bit-rate used. Though no formal testing has yet been performed, I'd say don't
go below the 15 kbps mode if you want DTMF to be transmitted correctly. DTMF at 8 kbps may work but your
mileage may vary. Also, make sure you don't use the lowest complexity (see SPEEX_SET_COMPLEXITY or -comp
option), as it causes significant noise. 

I'm surprised nobody has mentioned making RFC 2833 mandatory.

> Users could not care less about all the signaling issues that are
> debated here, but they will instantly perceive the quality of the
> peering.

I agree.

(Continue reading)

Henry Sinnreich | 2 Aug 2006 00:05

Picon

RE: Voice codecs

>> Can Speex pass DTMF? 

It is appropriate IMHO to use SPEEX wideband audio in the broadband age
with 16 kHz sampling (44 kb/s bit rate, still less than the 64 kb/s for
G.711), so as to have both better audio and DTMF support.

Thanks, Henry

-----Original Message-----
From: Andrew Newton [mailto:andy@...] 
Sent: Tuesday, August 01, 2006 2:16 PM
To: Henry Sinnreich
Cc: Drage, Keith (Keith); Brian Rosen; speermint@...; Ed Okerson;
Jean-Marc Valin
Subject: Re: [Speermint] Voice codecs

Henry Sinnreich wrote:
> It is heartening to see the interest in codecs after all in this
group!

I agree.

> A much better approach is to mandate SPEEX and only _allow_ (tolerate)
> transcoders for backward compatibility with legacy equipment.

I think we should definitely explore this option.

> See why at: http://speex.org/docs.html and we can discuss the pros and
> cons of what is truly the basics of any VoIP peering: Voice quality
for

(Continue reading)

Brian Rosen | 1 Aug 2006 19:46

RE: Voice codecs

Henry

If you have EvRC on one side and AMR on the other side, SPEEX will only hurt
your quality if you force it in the middle.

I really, truly believe that vendors and carriers who don't offer common
wideband codecs as standard with their products have shot themselves in the
foot.  VoIP should have been positioned as better than "toll" quality.  I'm
a big believer in wideband all around.  I think there are no excuses, the
vendors and carriers just plain blew it, and are stuck on a race to the
bottom with PSTN, when they could have been talking about better service.  

But given the realities, and I'm also big on reality, forcing SPEEX in the
middle is truly a bad idea.

Brian

> -----Original Message-----
> From: Henry Sinnreich [mailto:hsinnrei@...]
> Sent: Tuesday, August 01, 2006 1:23 PM
> To: Drage, Keith (Keith); Brian Rosen; speermint@...
> Cc: Greg Herlein; Ed Okerson; Jean-Marc Valin
> Subject: RE: [Speermint] Voice codecs
> 
> It is heartening to see the interest in codecs after all in this group!
> 
> > That is why I think that if we mandate transcoders
> 
> A much better approach is to mandate SPEEX and only _allow_ (tolerate)
> transcoders for backward compatibility with legacy equipment.

(Continue reading)

Henry Sinnreich | 1 Aug 2006 20:01

Picon

RE: Voice codecs

Brian,

> I'm a big believer in wideband all around.

Then why capitulate for "race to the bottom with PSTN" as you so well
say it?

Folks: Is this sentiment (race to the bottom with PSTN), of giving up,
shared by you and your employers?

If "racing to the bottom" is not in the business plan, take one more
look at http://www.speex.org/comparison.html 

Thanks, Henry

-----Original Message-----
From: Brian Rosen [mailto:br@...] 
Sent: Tuesday, August 01, 2006 10:46 AM
To: Henry Sinnreich; 'Drage, Keith (Keith)'; speermint@...
Cc: 'Greg Herlein'; 'Ed Okerson'; 'Jean-Marc Valin'
Subject: RE: [Speermint] Voice codecs

Henry

If you have EvRC on one side and AMR on the other side, SPEEX will only
hurt
your quality if you force it in the middle.

I really, truly believe that vendors and carriers who don't offer common
wideband codecs as standard with their products have shot themselves in

(Continue reading)

Brian Rosen | 1 Aug 2006 14:33

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

(Continue reading)

Brian Rosen | 1 Aug 2006 17:57

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

(Continue reading)

Albrecht.Schwarz | 1 Aug 2006 17:28

Picon

Picon

RE: 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".

(Continue reading)

Stastny Richard | 1 Aug 2006 17:54

Picon

Re: Voice codecs

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

I have a deja vu

This remindes me of loop back trunks 

-sta

Brian Rosen | 1 Aug 2006 17:45

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
>

(Continue reading)

Return

Return to gmane.ietf.rai.speermint.

Project Web Page

IETF speermint Working Group

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane