Subject: RE: [Speermint] Voice codecs

From: "Brian Rosen" <[email-masked]>
Date: Tue, 1 Aug 2006 08:33:13 -0400

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:[email-masked]]
> Sent: Tuesday, August 01, 2006 8:13 AM
> To: Brian Rosen; [email-masked]
> 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:[email-masked]]
> > Sent: 31 July 2006 19:39
> > To: 'Geoff Devine'; 'Livingood, Jason'; [email-masked]
> > 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:[email-masked]]
> > > Sent: Monday, July 31, 2006 2:28 PM
> > > To: Livingood, Jason; Brian Rosen; [email-masked]
> > > 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:[email-masked]]
> > > Sent: Monday, July 31, 2006 9:47 AM
> > > To: Brian Rosen; [email-masked]
> > > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >

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

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 1 Aug 2006 10:42:15 -0400

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

> Sent: Tuesday, August 01, 2006 8:33 AM
> To: 'Drage, Keith (Keith)'; [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 1 Aug 2006 11:17:42 -0400

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

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 10:42 AM
> To: 'Brian Rosen'; 'Drage, Keith (Keith)'; [email-masked]
> > I read this a couple of times before I grokked it.  I think you are
> right
> > in
> > That involves a distributed discovery mechanism with two lists -- find
> me
> > an

---

From: [email-masked]
Date: Tue, 1 Aug 2006 17:28:39 +0200

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"                                                                                               
                      <[email-masked]         To:      <[email-masked]>, "'Drage, Keith \(Keith\)'" <[email-masked]>,      
                      et>                      <[email-masked]>                                                               
                                               cc:                                                                                
                      01.08.2006 17:17         Subject: RE: [Speermint] Voice codecs                                              

Brian

> > thing for now, and work towards a better way.  I think the better way
is
> > not

---

From: "Geoff Devine" <[email-masked]>
Date: Tue, 1 Aug 2006 11:39:35 -0400

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:[email-masked]] 
Sent: Tuesday, August 01, 2006 11:18 AM
To: [email-masked]; 'Drage, Keith (Keith)'; [email-masked]
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.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 1 Aug 2006 11:45:37 -0400

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 11:29 AM
> To: Brian Rosen
> Cc: 'Drage, Keith (Keith)'; [email-masked]; [email-masked]
>                       <[email-masked]         To:
> <[email-masked]>, "'Drage, Keith \(Keith\)'" <[email-masked]>,
>                       et>                      <[email-masked]>
>                                                cc:
> > When we did some work in the US ENUM forum we decided to specify that
> the
> > US
> > > a SPEERMINT charter item, but perhaps we could write a requirements
> doc
> > > for
> > > someone else.
> > >
> > > > > > From: Livingood, Jason
> [mailto:[email-masked]]

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 1 Aug 2006 11:57:02 -0400

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

> Sent: Tuesday, August 01, 2006 11:40 AM
> To: Brian Rosen; [email-masked]; Drage, Keith (Keith);
> [email-masked]

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 1 Aug 2006 17:54:31 +0200

>internally" only. Transcoding relates then to X-to-Y-to-Z.

I have a deja vu
 
This remindes me of loop back trunks ;-)
 
-sta

---

From: "Patrick Melampy" <[email-masked]>
Date: Tue, 1 Aug 2006 12:11:02 -0400

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:[email-masked]] 
Sent: Tuesday, August 01, 2006 11:40 AM
To: Brian Rosen; [email-masked]; Drage, Keith (Keith);
[email-masked]

Geoff

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, August 01, 2006 11:18 AM
To: [email-masked]; 'Drage, Keith (Keith)'; [email-masked]
Subject: RE: [Speermint] Voice codecs

Brian

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 1 Aug 2006 14:12:48 +0200

Regards

Keith

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 1 Aug 2006 19:03:18 +0200

>exchanging these kind of capabilities to determine a best next-hop network

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:[email-masked]]
Gesendet: Di 01.08.2006 18:11
An: 'Geoff Devine'; 'Brian Rosen'; [email-masked]; 'Drage, Keith (Keith)'; [email-masked]
Betreff: RE: [Speermint] Voice codecs

-----Original Message-----
From: Geoff Devine [mailto:[email-masked]]
Sent: Tuesday, August 01, 2006 11:40 AM
To: Brian Rosen; [email-masked]; Drage, Keith (Keith);
[email-masked]

Geoff

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, August 01, 2006 11:18 AM
To: [email-masked]; 'Drage, Keith (Keith)'; [email-masked]
Subject: RE: [Speermint] Voice codecs

Brian

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 1 Aug 2006 10:22:30 -0700

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:[email-masked]] 
Sent: Tuesday, August 01, 2006 5:13 AM
To: Brian Rosen; [email-masked]
Subject: RE: [Speermint] Voice codecs

Regards

Keith

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 1 Aug 2006 13:46:04 -0400

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

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 1:23 PM
> To: Drage, Keith (Keith); Brian Rosen; [email-masked]
> Cc: Greg Herlein; Ed Okerson; Jean-Marc Valin

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 1 Aug 2006 11:01:09 -0700

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:[email-masked]] 
Sent: Tuesday, August 01, 2006 10:46 AM
To: Henry Sinnreich; 'Drage, Keith (Keith)'; [email-masked]
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
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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 01 Aug 2006 17:15:32 -0400

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

I agree.

> transcoders for backward compatibility with legacy equipment.

I think we should definitely explore this option.

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.

> debated here, but they will instantly perceive the quality of the

I agree.

-andy

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 1 Aug 2006 15:05:12 -0700

>> 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:[email-masked]] 
Sent: Tuesday, August 01, 2006 2:16 PM
To: Henry Sinnreich
Cc: Drage, Keith (Keith); Brian Rosen; [email-masked]; Ed Okerson;
Jean-Marc Valin
Subject: Re: [Speermint] Voice codecs

I agree.

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

-andy

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 1 Aug 2006 18:29:13 -0400

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

---

From: [email-masked]
Date: Wed, 2 Aug 2006 08:20:37 +0200

>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" <[email-masked]>, "Geoff Devine"               
                      <Richard.Stastny         <[email-masked]>, "Brian Rosen" <[email-masked]>,                    
                      @oefeg.at>               <[email-masked]>, "Drage, Keith \(Keith\)" <[email-masked]>,                 
                                               <[email-masked]>                                                               
                      01.08.2006 19:03         cc:                                                                                
                                               Subject: Re: [Speermint] Voice codecs                                              

>exchanging these kind of capabilities to determine a best next-hop network

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

-sta

Von: Patrick Melampy [mailto:[email-masked]]
Gesendet: Di 01.08.2006 18:11
An: 'Geoff Devine'; 'Brian Rosen'; [email-masked]; 'Drage, Keith
(Keith)'; [email-masked]
Betreff: RE: [Speermint] Voice codecs

supported by the originator/terminator. Even the terminating network may

-----Original Message-----
From: Geoff Devine [mailto:[email-masked]]
Sent: Tuesday, August 01, 2006 11:40 AM
To: Brian Rosen; [email-masked]; Drage, Keith (Keith);
[email-masked]

Geoff

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, August 01, 2006 11:18 AM
To: [email-masked]; 'Drage, Keith (Keith)'; [email-masked]
Subject: RE: [Speermint] Voice codecs

Brian