Subject: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?

From: "codec issue tracker" <[email-masked]>
Date: Tue, 23 Mar 2010 17:20:08 -0000

#1: Application: 2.1.  Point to point calls supporting transcoding?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     
------------------------------------+---------------------------------------
 Question: Shall the point-to-point call support transcoding?

 If not, please add something like
 "This scenario does not include the use case of using a VoIP-PSTN gateway
 to connected to legacy telephone systems. In those cases, the gateway
 would make an audio conversion from broadband Internet voice to the frugal
 1930’s 3.1 kHz audio bandwidth. Interconnections to the PSTN will most
 likely stick with its legacy codecs to avoid transcoding."

-- 
Ticket URL: <http://tools.ietf.org/wg/codec/trac/ticket/1>
codec <http://tools.ietf.org/codec/>

---

From: James Rafferty <[email-masked]>
Date: Tue, 23 Mar 2010 17:31:51 -0400

Hi, 

In my view, this is dodging the real issue.  I believe there WILL be transcoding for point to point calls between wireline and wireless networks, where the connection is IP on both sides and multiple wide band codecs are used.  

For that matter, there will also be cases where a PSTN - IP gateway is needed, but that's not usually defined as transcoding.    

James

James Rafferty 
Product Line Director, Integrated Media Gateways 
Dialogic, Inc.  
15 Crawford Street 
Needham, MA 02494 
USA 

Tel:    781 433 9462
Mobile: 781 929 3895
Fax:    781 433 9268
Email:  [email-masked]
Web:    www.dialogic.com
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of codec issue tracker
Sent: Tuesday, March 23, 2010 10:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?

_______________________________________________
codec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/codec

---

From: "Christian Hoene" <[email-masked]>
Date: Tue, 23 Mar 2010 14:53:29 -0700

Hi James,

>In my view, this is dodging the real issue.  I believe there WILL be transcoding for point to point
>calls between wireline and wireless networks, where the connection is IP on both sides and multiple
>wide band codecs are used.

Could you elaborate a bit more on this scenario? Do you mean that the wireline has -for example- Skype phone with the Internet codec and the wireless end will have an LTE codec? Of course, both sides will use IP.

>For that matter, there will also be cases where a PSTN - IP gateway is needed, but that's not usually

As a manufacturer of IP-to-IP gateways your insight knowledge is highly appreciated.
 
With best regards,

  Christian Hoene

>This e-mail is intended only for the named recipient(s) and may contain information that is
>privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege,
>confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use,
>dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not
>named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.
>

---

From: James Rafferty <[email-masked]>
Date: Tue, 23 Mar 2010 19:14:00 -0400

Christian, 

Please see my comments below. 

James

-----Original Message-----
From: Christian Hoene [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 2:53 PM
To: James Rafferty
Cc: [email-masked]
Subject: RE: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?

Hi James,

JR - Yes, the example of Skype from the desktop connecting to a mobile phone with wideband audio (say G.722.2) is an example.  In order for that to happen, there would likely be a border element at the network edge (what the Speermint architecture calls a Data Border Element) which negotiates the transcoding to take place in real time.  Another use case example would be where an enterprise IP phone uses a wideband codec when calling to a mobile phone, again requiring transcoding to take place to complete the call, if the two handsets do not support a common HD codec.   

 
With best regards,

  Christian Hoene

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 24 Mar 2010 09:08:09 -0700

Hi all,

the well known reasons for avoiding transcoding/tandem-coding are:

1) It decreases the conversational quality by decreasing speech quality and increasing transmission delay. Thus, it is in the interest of users/customers to avoid transcoding.
2) It violates Internet's end-to-end principle and thus increasing system complexity and costs. Thus, an Internet codec shall not consider operation modes of transcoding, typically.
3) Codecs must be optimized towards transcoding, which is a time consuming tasks. Thus, it is in the interest of codec developers and tester to avoid the additional cost of verifying the transcoding scenarios.

Of course, we are not living in an perfect world and there are many valid reasons to install transcoding gateways to manage proper interaction between two remote sides/operators. If it is required to do so, there are multiple options:

1) The gateway tries to negotiate a proper codec that is supported by both sides.
2) Two ITU-T codecs, which are very well optimized towards tandem-coding conditions, are selected.
3) Only, as a last resort, it might be needed to transcode between an Internet-codec and other codecs.

I am not yet convinced that option 3) will happen frequently, especially considering the facts that the Internet codec is intended towards IP-to-IP use cases.  Also, it is quite easy to include additional traditional codecs beside the Internet codec into a phone or gateways. In addition, the costs of updating the software of a phone or gateway to support the Internet codec might not be very high because of the lack of IPR fees.

Thus, I would recommend to consider transcoding as a requirement of very low priority, as it is going to be used seldom. It shall be ensured that the Internet codecs does not "fail" during tandeming but that not particular effort is invested to make the Internet codec work particular well for transcoding.

Having this say, it is appreciate if volunteers will test the Internet codec in tandem conditions so that the codec design can be influenced.

With best regards,

 Christian

---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
http://www.net.uni-tuebingen.de/

>From: James Rafferty [mailto:[email-masked]]
>Sent: Tuesday, March 23, 2010 4:14 PM
>To: Christian Hoene
>Cc: [email-masked]
>Could you elaborate a bit more on this scenario? Do you mean that the wireline has -for example- Skype
>phone with the Internet codec and the wireless end will have an LTE codec? Of course, both sides will
>use IP.
>
>JR - Yes, the example of Skype from the desktop connecting to a mobile phone with wideband audio (say
>G.722.2) is an example.  In order for that to happen, there would likely be a border element at the
>network edge (what the Speermint architecture calls a Data Border Element) which negotiates the
>transcoding to take place in real time.  Another use case example would be where an enterprise IP
>phone uses a wideband codec when calling to a mobile phone, again requiring transcoding to take place
>to complete the call, if the two handsets do not support a common HD codec.
>

---

From: James Rafferty <[email-masked]>
Date: Wed, 24 Mar 2010 14:50:07 -0400

Christian, 

I'm familiar with the theoretical arguments about why to avoid transcoding, but when standards organizations (e.g 3GPP) or service providers only provide support for certain specified codecs over their networks, you either drop the call which requires a different codec or transcode it.  

So, you may not think that transcoding will commonly happen, but in my experience, it is not at all uncommon when crossing from one network to another.  
I will be surprised if wideband codecs offer a different experience, since the early selections for different use cases have already resulted in different codecs, and the IETF "Codec" codec will add yet another.  

Vendors of products on these network edges will take the steps needed to get endpoints to communicate (as driven by their service provider customers), even if it requires a codec change to complete the call.  

James

-----Original Message-----
From: Christian Hoene [mailto:[email-masked]] 
Sent: Wednesday, March 24, 2010 9:08 AM
To: James Rafferty; [email-masked]
Subject: RE: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?

Hi all,

With best regards,

 Christian

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 24 Mar 2010 21:22:47 -0700

Hi James,

>From: James Rafferty [mailto:[email-masked]]
...
>Vendors of products on these network edges will take the steps needed to get endpoints to communicate
>(as driven by their service provider customers), even if it requires a codec change to complete the
>call.

So, the main requirement in these cases is the interoperability. Conversational quality is of lesser importance.
Thus, we need not particular quality requirements beside that it works OK?

Christian

>1) It decreases the conversational quality by decreasing speech quality and increasing transmission
>delay. Thus, it is in the interest of users/customers to avoid transcoding.
>2) It violates Internet's end-to-end principle and thus increasing system complexity and costs. Thus,
>an Internet codec shall not consider operation modes of transcoding, typically.
>3) Codecs must be optimized towards transcoding, which is a time consuming tasks. Thus, it is in the
>interest of codec developers and tester to avoid the additional cost of verifying the transcoding
>scenarios.
>
>Of course, we are not living in an perfect world and there are many valid reasons to install
>transcoding gateways to manage proper interaction between two remote sides/operators. If it is
>required to do so, there are multiple options:
>
>I am not yet convinced that option 3) will happen frequently, especially considering the facts that
>the Internet codec is intended towards IP-to-IP use cases.  Also, it is quite easy to include
>additional traditional codecs beside the Internet codec into a phone or gateways. In addition, the
>costs of updating the software of a phone or gateway to support the Internet codec might not be very
>high because of the lack of IPR fees.
>
>Thus, I would recommend to consider transcoding as a requirement of very low priority, as it is going
>to be used seldom. It shall be ensured that the Internet codecs does not "fail" during tandeming but
>that not particular effort is invested to make the Internet codec work particular well for
>transcoding.
>
>>>For that matter, there will also be cases where a PSTN - IP gateway is needed, but that's not
>usually
>>>defined as transcoding.
>>

---

From: James Rafferty <[email-masked]>
Date: Wed, 24 Mar 2010 16:59:46 -0400

Hi Christian, 

See below (JR).  

James

-----Original Message-----
From: Christian Hoene [mailto:[email-masked]] 
Sent: Wednesday, March 24, 2010 9:23 PM
To: James Rafferty; [email-masked]
Subject: RE: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?

Hi James,

...

JR - An ability to interop is the first consideration and quality is still important; the customer will expect (whether reasonable or not) better than PSTN quality if wideband codecs are being used by both endpoints.  

Christian

>James
<snip>

---

From: stephen botzko <[email-masked]>
Date: Wed, 24 Mar 2010 14:22:01 -0700

Seems to me that there are two cases here - single gateway, and double
gateway.:In the double gateway case, Endpoint A connects to Endpoint B via a
gateway pair using PSTN.  The audio is converted to G.711 narrowband by the
first gateway, and back to the internet codec by the second.  The best
quality that can result is G.711, and the acoustic bandwidth is also limited
to narrowband, even though both endpoints can not see the G.711 hop.  Users
may have other expectations, but they cannot be met.

In any event, measuring the tandeming quality performance of this codec with
all other standard or popular) codecs would be a very tedious exercise, and
IMHO not practical.   We'd have to pick one or two codecs and let it go at
that.

Stephen Botzko

On Wed, Mar 24, 2010 at 1:59 PM, James Rafferty <[email-masked]
> wrote:

> So, the main requirement in these cases is the interoperability.
> Conversational quality is of lesser importance.
> JR - An ability to interop is the first consideration and quality is still
> important; the customer will expect (whether reasonable or not) better than
> PSTN quality if wideband codecs are being used by both endpoints.
>
> Christian
>
> >
> >James
> >
> <snip>

---

From: James Rafferty <[email-masked]>
Date: Wed, 24 Mar 2010 17:46:24 -0400

Stephen,

The "two gateway" or back-to-back gateway case will inevitably degrade quality to be G.711 level or worse.  The IP - IP case where there is no PSTN codec conversion  is the much more interesting one for the marketplace.  I'd agree picking a limited set of HD codecs (for example, G.722 and G.722.2) for these tandeming purposes is the practical approach.

James
James Rafferty

Tel:    781 433 9462
Mobile: 781 929 3895
Fax:    781 433 9268
Email:  [email-masked]<mailto:[email-masked]>
Web:    www.dialogic.com<http://www.dialogic.com>
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.

From: stephen botzko [mailto:[email-masked]]
Sent: Wednesday, March 24, 2010 2:22 PM
To: James Rafferty
Cc: Christian Hoene; [email-masked]
Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?

Seems to me that there are two cases here - single gateway, and double gateway.:In the double gateway case, Endpoint A connects to Endpoint B via a gateway pair using PSTN.  The audio is converted to G.711 narrowband by the first gateway, and back to the internet codec by the second.  The best quality that can result is G.711, and the acoustic bandwidth is also limited to narrowband, even though both endpoints can not see the G.711 hop.  Users may have other expectations, but they cannot be met.

In any event, measuring the tandeming quality performance of this codec with all other standard or popular) codecs would be a very tedious exercise, and IMHO not practical.   We'd have to pick one or two codecs and let it go at that.

Stephen Botzko

On Wed, Mar 24, 2010 at 1:59 PM, James Rafferty <[email-masked]<mailto:[email-masked]>> wrote:
Hi Christian,

See below (JR).

James

-----Original Message-----
From: Christian Hoene [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 24, 2010 9:23 PM
To: James Rafferty; [email-masked]<mailto:[email-masked]>
Subject: RE: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?
Hi James,

>From: James Rafferty [mailto:[email-masked]<mailto:[email-masked]>]
...

Christian

<snip>
_______________________________________________
codec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/codec

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 25 Mar 2010 09:14:33 -0700

Hi,
 
it might be interesting to have a look on the decision of the ITU-T regarding the requirements of the ITU-T G.718. The document TD
314 (WP 3/16) (Geneva, 22 April - 2 May 2008 ) lists in “TABLE A: Performance requirements and objectives for an embedded audio
coding algorithm” 

Parameter
Requirement
Objective
Priority

9. Interoperability for speech

Interoperability with other ITU-T speech encoding standards and 
Interoperability  with 2G and 3G mobile radio systems is desirable.
 
Interoperability with G.722.2 @ 12,65 kb/s is of particular interest.

In the second phase of characterization “Annex 1: Initial List of Test Conditions for Optimization/Characterization Phase II” lists
the following test conditions,
 
*   NB self tandeming at R1 and at R2
*   WB self tandeming at R1 and at R5
*   NB Cross tandeming with G729A input
*   WB Cross tandeming with [email-masked] input 
*   WB Cross tandeming with G722@64kbps input
To my understanding, the common consensus on this list is to have similar requirements as G.718 and to consider at least cross
tandeming conditions with [email-masked] in the characterization phase.
 
With best regards,
 
 Christian

 
---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
 <http://www.net.uni-tuebingen.de/> http://www.net.uni-tuebingen.de/
 
From: James Rafferty [mailto:[email-masked]] 
Sent: Wednesday, March 24, 2010 2:46 PM
To: stephen botzko
Cc: Christian Hoene; [email-masked]
Subject: RE: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?
 
Stephen, 
 
The “two gateway” or back-to-back gateway case will inevitably degrade quality to be G.711 level or worse.  The IP – IP case where
there is no PSTN codec conversion  is the much more interesting one for the marketplace.  I’d agree picking a limited set of HD
codecs (for example, G.722 and G.722.2) for these tandeming purposes is the practical approach.  
 
James
James Rafferty 

Tel:    781 433 9462
Mobile: 781 929 3895
Fax:    781 433 9268
Email:  james.rafferty <mailto:[email-masked]> @dialogic.com
Web:    www.dialogic.com
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt
from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the
internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are
not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.

Seems to me that there are two cases here - single gateway, and double gateway.:In the double gateway case, Endpoint A connects to
Endpoint B via a gateway pair using PSTN.  The audio is converted to G.711 narrowband by the first gateway, and back to the internet
codec by the second.  The best quality that can result is G.711, and the acoustic bandwidth is also limited to narrowband, even
though both endpoints can not see the G.711 hop.  Users may have other expectations, but they cannot be met.

In any event, measuring the tandeming quality performance of this codec with all other standard or popular) codecs would be a very
tedious exercise, and IMHO not practical.   We'd have to pick one or two codecs and let it go at that.

Stephen Botzko

On Wed, Mar 24, 2010 at 1:59 PM, James Rafferty <[email-masked]> wrote:
Hi Christian,

See below (JR).

James

-----Original Message-----
From: Christian Hoene [mailto:[email-masked]]
Sent: Wednesday, March 24, 2010 9:23 PM
To: James Rafferty; [email-masked]
Subject: RE: [codec] #1: Application: 2.1. Point to point calls supporting transcoding?
Hi James,

...

So, the main requirement in these cases is the interoperability. Conversational quality is of lesser importance.
Thus, we need not particular quality requirements beside that it works OK?
JR - An ability to interop is the first consideration and quality is still important; the customer will expect (whether reasonable
or not) better than PSTN quality if wideband codecs are being used by both endpoints.

Christian

<snip>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 28 Mar 2010 08:49:15 -0700

I think that transcoding must be an explicit non-goal for this codec.  If you do
transcoding, there you are probably doing it in some hardware that you are
selling.  There is no shortage of ITU codecs that supports transcoding, and
paying royalties for them is not an issue when you are licensing your code as
part of an hardware product.

This Internet codec is designed for the FOSS developers or at least for pure
software developers, the one that cannot bundle their software with some
harwdare, and so cannot afford to pay royalties but also do not care about
transcoding.

Keep the codec as simple as possible (but not simpler) so it has a chance to be
really royalty-free.

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org