Subject: [Speermint] Speermint] requirements: codec

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 13 Sep 2006 15:46:50 -0600

All,

Reading the codec related threads since June, we got some pretty good
discussion and feedback from many folks (individuals, VSPs, and vendors
included).

It seems that the following represents the current wg consensus for the
minimum codec requirements for VoIP interconnects:
	- mandatory support of RTP *and* RTCP on UAs attached to the
VSPs;
	- the support of some compatible codecs between VSPs is
recommended but the actual choice of common codecs between VSPs is
outside the scope of speermint. 
Transcoding should be avoided by proposing commonly deployed codecs in
codec negotiation procedures.  If the population of UAs attached to a
VSP does not support the G.711 codec, the VSP should, at a minimum,
support transcoding to G.711.

Is this inline with what folks read? 
Any comments? Is this worth keeping or beefing up?

Thanks,
Jean-Francois.

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

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 13 Sep 2006 18:00:15 -0400

Just so I understand this summary correctly beyond RTP/RTCP...

1) Codec selection is out of speermint scope and is a matter of local
policy, possibly of a Federation or of a direction interconnection
relationship. I am completely onboard with this one.

2) In order to avoid transcoding (cuz it's evil) the proposal would be
to state that a UA registered to a VSP should have support for commonly
deployed codecs, or at a minimum G711, BUT if G711 is not supported, to
support transcoding to G711?

#2 seems a little contradictory to me, or did I misunderstand the
summary?!?!

-AU

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 5:47 PM
To: [email-masked]
Subject: [Speermint] Speermint] requirements: codec

All,

Thanks,
Jean-Francois.

---

From: Daryl Malas <[email-masked]>
Date: Wed, 13 Sep 2006 16:01:10 -0600

I don't think RTCP should be mandatory, as there are arguably better
methods for monitoring audio quality.  Some of these include a
combination of ITU-T P.862 and P.563.  From my perspective, RTCP does
not help us identify much of anything.  For example, RTCP may tell you
their is a delta between packets sent and received, but it will not tell
you where the problem occurred, and whether or not it actually affected
the audio quality.

I agree with the rest of your assertion.  Thanks for compiling the
results...--Daryl

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 13 Sep 2006 15:20:34 -0700

> If the population of UAs attached to a VSP does not support the G.711
codec

I suggest to replace G.711 with G.729 since under bandwidth constraints,
the performance will actually be better. 

Since both the G.729 and the G.711 can support only 3.1 kHz voice
bandwidth, peering partners may also do the SDP negotiation of a
wideband audio codec such as SPEEX or any other open source, IETF known
wideband audio codec such as in RFC 4298 for example.

We don't want to condemn peering partners to using 40 year old codecs
designed for TDM PCM and ADPCM systems that have long disappeared from
the list of new equipments.

Thanks, Henry

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 5:47 PM
To: [email-masked]
Subject: [Speermint] Speermint] requirements: codec

All,

Thanks,
Jean-Francois.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 18:46:18 -0400

No no no.

The proposal if you don't have common codecs is to transcode to G.711. The
reason you want G.711 is because Codec A - G.711 - Codec B introduces less
error than any other codec IF YOU CODEC A AND B ARE ARBITRARY.  Better yet
would be a 16 bit straight linear PCM at 8KHz, and better than that would be
16 bit linear PCM at some multiple of both original and terminating sample
rates, but I think that is going too far.

EvRC to G.729 to AMR would be much worse than EvRC to G.711 to AMR.

G.711 is on nearly everyone's list, still.  You would be hard pressed to
find a device that could do G.729 that could not do G.711.

I'm not even sure that putting any wideband codec in common use would be
better than G.711.  I'm not even sure it would be better in the case of
Wideband Codec A - Wideband Codec Common - Wideband codec B.  Again, a
linear 16 bit, 16Khz PCM would be better, and a 32 bit would be better yet.

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Wednesday, September 13, 2006 6:21 PM
> To: Jean-Francois Mule; [email-masked]
> Subject: RE: [Speermint] Speermint] requirements: codec
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 13 Sep 2006 20:53:31 -0400

> the list of new equipments.

I agree with Henry.  Though I wouldn't mind adding another codec to  
the list that would be found to be more agreeable to mobile/cellular  
operators (I don't care what, but the freer the better).

-andy

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Wed, 13 Sep 2006 20:52:20 -0500

Brian is correct. If you are not transcoding on behalf of the end-point,
than transcoding to G.711 will minimize distortion, and give better
end-to-end performance. 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 6:46 PM
To: 'Henry Sinnreich'; 'Jean-Francois Mule'; [email-masked]
Subject: RE: [Speermint] Speermint] requirements: codec

No no no.

The proposal if you don't have common codecs is to transcode to G.711.
The
reason you want G.711 is because Codec A - G.711 - Codec B introduces
less
error than any other codec IF YOU CODEC A AND B ARE ARBITRARY.  Better
yet
would be a 16 bit straight linear PCM at 8KHz, and better than that
would be
16 bit linear PCM at some multiple of both original and terminating
sample
rates, but I think that is going too far.

I'm not even sure that putting any wideband codec in common use would be
better than G.711.  I'm not even sure it would be better in the case of
Wideband Codec A - Wideband Codec Common - Wideband codec B.  Again, a
linear 16 bit, 16Khz PCM would be better, and a 32 bit would be better
yet.

---

From: Jason Livingood <[email-masked]>
Date: Wed, 13 Sep 2006 23:08:39 -0400

Let's have this discussion at the interim.

Jason

---

From: "Geoff Devine" <[email-masked]>
Date: Thu, 14 Sep 2006 06:56:07 -0400

Henry Sinnreich wrote:
> I suggest to replace G.711 with G.729 since under bandwidth
> constraints, the performance will actually be better.

_AUDIO_ performance will be much worse.  G.729 produces noticeable
degradation in human speech and falls over completely with audio inputs
like music-on-hold.  None of the narrowband compression codecs perform
as well as G.711.  G.729e is the best of the lot but it doesn't
reproduce music-on-hold all that well, either.  Unless you want to
mandate a wideband codec, clunky-old G.711 is still the winner in an
audio quality bake-off.

Geoff

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 6:21 PM
To: Jean-Francois Mule; [email-masked]
Subject: RE: [Speermint] Speermint] requirements: codec

codec

Thanks, Henry

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 5:47 PM
To: [email-masked]
Subject: [Speermint] Speermint] requirements: codec

All,

Thanks,
Jean-Francois.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 14 Sep 2006 09:37:30 -0700

I like the attached wording, except can we forget the ancient G.711 in
the 21st century :-)>

Just delete the mention of G.711?

Thanks, Henry

-----Original Message-----
From: Jason Livingood [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 11:09 PM
To: Jean-Francois Mule; [email-masked]
Subject: Re: [Speermint] Speermint] requirements: codec

Jason

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 14 Sep 2006 13:20:00 -0500

Henry,

Transcoding 101: everything gets transcoded to G711. X-->Z, means X-->
G.711 --> Z. So, if you are not transcoding on behalf of the end point
Xcoding to G.711 is the best bet.

Cheers,

Martin 

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 12:38 PM
To: Jason Livingood; Jean-Francois Mule; [email-masked]
Subject: RE: [Speermint] Speermint] requirements: codec

Thanks, Henry

-----Original Message-----
From: Jason Livingood [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 11:09 PM
To: Jean-Francois Mule; [email-masked]
Subject: Re: [Speermint] Speermint] requirements: codec

Jason

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 15 Sep 2006 13:44:53 -0700

Martin,

> G.711 is the best bet

G.711 is unfortunately not the best bet from a QoS perspective since
with its ~90 kb/s bandwidth is much more likely to get into packet loss
than G.729 with its ~30 kHz bandwidth. G.729 has also packet loss
concealment 
mechanisms and other refinements that G.711 does not have.

As for fax that was mentioned in this discussion, the right approach is
given in RFC 3362 - Real-time Facsimile (T.38).

Thanks, Henry

-----Original Message-----
From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 2:20 PM
To: Henry Sinnreich; Jason Livingood; Jean-Francois Mule;
[email-masked]

Henry,

Cheers,

Martin 

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 12:38 PM
To: Jason Livingood; Jean-Francois Mule; [email-masked]
Subject: RE: [Speermint] Speermint] requirements: codec

Thanks, Henry

-----Original Message-----
From: Jason Livingood [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 11:09 PM
To: Jean-Francois Mule; [email-masked]
Subject: Re: [Speermint] Speermint] requirements: codec

Jason

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Sep 2006 17:03:16 -0400

Henry

Please consider that bandwidth in the core of any carrier's network is not a
problem.  It may be a problem at the edges.  The transcoders are in the
core, or at least are at the boundary, with a high bandwidth uplink.  The
purpose of the G.711 is to facilitate A -> common -> B.  That is a
core-to-core transaction.

You will NOT LIKE any form of compressed codec in the middle.  You want to
go the other way (16 bit linear PCM, high sample rate).  EvRC/AMR to G.729
to anything will sound terrible.

Brian

> Sent: Friday, September 15, 2006 4:45 PM
> To: Dolly, Martin C, ALABS; Jason Livingood; Jean-Francois Mule;
> [email-masked]

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 15 Sep 2006 16:01:16 -0700

Martin,

G.711 is unfortunately not the best bet from a QoS perspective since
with its ~90 kb/s bandwidth is much more likely to get into packet loss
than G.729 with its ~30 kHz bandwidth. This scenario may happen on poor
access links (Brian Rosen's note about no errors in the middle, which is
true).
 
G.729 has also packet loss concealment mechanisms and other refinements
that G.711 does not have.

G.729 has two drawbacks:

1. There are license fees that have to be absorbed in the cost of the
IP-PSTN calls,

2. Conversion to mobile network codecs (EvRC or AMR) may not work as
well as with G.711.

IP-IP works best with variable rate wideband audio codecs and SPEEX is
my 1st choice.

Whatever the merits of the above, a true peering design must have a
network-to-codec matrix with some defaults recommended by SPEERMINT.

I hope this discussion has helped so we do not gloss over the codecs in
any peering design.

Thanks, Henry

-----Original Message-----
From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 2:20 PM
To: Henry Sinnreich; Jason Livingood; Jean-Francois Mule;
[email-masked]

Henry,

Cheers,

Martin 

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 12:38 PM
To: Jason Livingood; Jean-Francois Mule; [email-masked]
Subject: RE: [Speermint] Speermint] requirements: codec

Thanks, Henry

-----Original Message-----
From: Jason Livingood [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 11:09 PM
To: Jean-Francois Mule; [email-masked]
Subject: Re: [Speermint] Speermint] requirements: codec

Jason

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Sep 2006 21:05:11 -0400

> I hope this discussion has helped so we do not gloss over the codecs in

Actually, I think it has served to muddy the waters.

A while ago, I thought we agreed that codec choice was a federation choice,
and not an IETF choice.  One of the characteristics of a federation was what
its codec policies are, and if you join, you have to obey them. 

I keep pointing out that all codec discussions seem to be only about voice,
and even ignore the audio part of a videoconference federation, or the text
codec of an IM federation, etc.

I don't think any SPEERMINT doc should mention any specific codec.  I think
it should not mandate ANYTHING except that a federation must have a codec
policy to permit interoperability among federation members.  It could go
farther and suggest (SHOULD) that the federation choose a codec to be used
when no transcode is available to go directly from A to B.

Brian

---

From: Andrew Newton <[email-masked]>
Date: Fri, 15 Sep 2006 21:34:55 -0400

> its codec policies are, and if you join, you have to obey them.

If you want to avoid transcoding (and I hope everybody does), you  
need a recommendation for what the UAs need to support.  With few  
exceptions, UAs will not be specific to any particular peering  
federation, SIP fabric, or VSP.

-andy

---

From: Francois Menard <[email-masked]>
Date: Fri, 15 Sep 2006 20:45:26 -0500 (EST)

Furthermore, if VoIP has one chance in hell to take over the PSTN, it has 
to eventually sound better than PSTN.  Speex does that.

F.

--
Francois D. Menard
Project Manager/Charge de projet
Xit telecom inc.
1350 Royale # 800
Trois-Rivieres, QC, G9A 4J4
Tel: +1 819 374 2556 x 268
Cell: +1 819 692 1383
[email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Sep 2006 22:21:06 -0400

I don't think that is realistic.

Most wireless devices, specifically, will implement the codecs that their
systems support, and that's it.  A CDMA-2000 device is not implementing the
GSM codecs.  Similarly, a normal desktop device is unlikely to implement
either.  You won't get the wireless guys to implement a non-compressed
codec, and so far, I think it's highly likely they would do anything like
G,729.

I think that is probably okay.

If there was a recommendation, despite Henry's protestations, I would think
it would be "if possible, implement G.711)".  

I would love to wave a magic wand and say everyone implements SPEEX.
I think we really, seriously blew it when we did not make VoIP mean
wideband.

I don't think its going to happen.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, September 15, 2006 9:35 PM
> To: Brian Rosen
> Cc: 'Henry Sinnreich'; 'Dolly, Martin C, ALABS'; 'Jason Livingood'; 'Jean-
> Francois Mule'; [email-masked]
> Subject: Re: [Speermint] Speermint] requirements: codec - corrected
> 
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sat, 16 Sep 2006 01:00:16 -0400

Hello,

That was my understanding too. What it _seemed_ we agreed on was that
things would work out when the interconnection actually happened based
on the federation policies and/or some kind of contract.

Regards,

Reinaldo

> Sent: Friday, September 15, 2006 6:05 PM
> To: 'Henry Sinnreich'; 'Dolly, Martin C, ALABS'; 'Jason 
> Livingood'; 'Jean-Francois Mule'; [email-masked]
> Subject: RE: [Speermint] Speermint] requirements: codec - corrected
> 
> > I hope this discussion has helped so we do not gloss over 
> the codecs 
> > in any peering design.
> 
> A while ago, I thought we agreed that codec choice was a 
> federation choice, and not an IETF choice.  One of the 
> characteristics of a federation was what its codec policies 
> are, and if you join, you have to obey them. 
> 
> I keep pointing out that all codec discussions seem to be 
> only about voice, and even ignore the audio part of a 
> videoconference federation, or the text codec of an IM 
> federation, etc.
> 
> I don't think any SPEERMINT doc should mention any specific 
> codec.  I think it should not mandate ANYTHING except that a 
> federation must have a codec policy to permit 
> interoperability among federation members.  It could go 
> farther and suggest (SHOULD) that the federation choose a 
> codec to be used when no transcode is available to go 
> directly from A to B.
> 
> Brian
> 
>

---

From: "Geoff Devine" <[email-masked]>
Date: Sat, 16 Sep 2006 16:32:55 -0400

I'd also add that packet loss concealment over G.711 is the norm these
days.  It is not part of the ITU-T spec but every DSP silicon vendor and
codec algorithm shop I've ever looked at has a flavor of it.  Packet
loss concealment is not particular to G.729.  

It would be nice to use 16-bit linear at a 5 mSec sample rate as our
common tongue in the core but that kind of audio fidelity is not going
to really be needed until we start using wideband codecs and high
fidelity telephone handsets.  Until then, most networks are likely to
stick with inexpensive two tin cans and a string encoding technology &
G.711.

Geoff
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, September 15, 2006 5:03 PM
To: 'Henry Sinnreich'; 'Dolly, Martin C, ALABS'; 'Jason Livingood';
'Jean-Francois Mule'; [email-masked]
Subject: RE: [Speermint] Speermint] requirements: codec

Henry

Please consider that bandwidth in the core of any carrier's network is
not a
problem.  It may be a problem at the edges.  The transcoders are in the
core, or at least are at the boundary, with a high bandwidth uplink.
The
purpose of the G.711 is to facilitate A -> common -> B.  That is a
core-to-core transaction.

You will NOT LIKE any form of compressed codec in the middle.  You want
to
go the other way (16 bit linear PCM, high sample rate).  EvRC/AMR to
G.729
to anything will sound terrible.

Brian