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

[Marc Petit-Huguenin <[e-mail]>]

On 03/28/2010 09:40 AM, Michael Knappe wrote:
> Marc,
> 
> This is not about the codec itself being involved in transcoding operations,
> but instead testing our proposed codec chained (tandemed) with other codecs
> in typical mixed topologies (e.g. Cell network to voip network) to ensure we
> do not incur severe deleterious quality issues. This does not need to be
> extensively tested against all known codecs, a few representative codecs
> would suffice. Given the expected quality of our proposed codec I wouldn't
> expect any issues here, but worth testing nonetheless.

Sorry, but I still do not understand the need for this testing.  In a cell
network to VoIP topology, the codec selected must be an ITU codec which we
already know are working fine for transcoding.  In a VoIP to VoIP topology the
codec selected is the one defined by this WG and by definition no transcoding is
needed.  And that's it, no test needed, because nobody will use it this way.

One case for transcoding could be made for a voicemail:  A voicemail receives
calls from both ITU and CODEC's codec.  One may think that in this case
transcoding would be needed, but in fact the original destination of the call
supports both codecs, so the voicemail simply records in whatever format is
used.  The original destination uses an ITU codec if the call was from a cell
network and the CODEC's codec if it was from the Internet.  Again, no
transcoding needed.

Another case is that if a voicemail records with the CODEC's codec because the
destination was on the Internet, but the destination wants to listen the
voicemail from another device, one which is on the cell network, then
transcoding would be needed.  A good solution in this case is for the Internet
device to send two streams to the voicemail, one with each codec.  RFC 3264 can
be used for this, but a better way would be to use the ITU codec as a redundant
codec. Because this is streaming and not interactive the destination cannot
request to repeat if packets are lost, and so redundancy is kind of mandatory in
this case. Anyway playing/recording a voicemail is not an interactive activity
but a streaming one, which the CODEC charter explicitly excluded as goal, so the
CODEC's codec should not be used with a voicemail.

Unless there is a something that is not said here (and my paranoid mind already
have multiple theories), I would make it a goal to explicitly *not* do this test.

> 
> Mike
> 
> 
> ----- Original Message ----- From: [e-mail]
> <[e-mail]> To: Christian Hoene <[e-mail]> Cc:
> [e-mail] <[e-mail]>; 'James Rafferty'
> <[e-mail]> Sent: Sun Mar 28 11:49:15 2010 Subject: Re:
> [codec] #1: Application: 2.1. Point to point calls supporting transcoding?
> 
> 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.
> 
> On 03/24/2010 09:08 AM, Christian Hoene wrote:
>> 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 [phone] 
>> http://www.net.uni-tuebingen.de/
>> 
>>> -----Original Message----- From: James Rafferty
>>> [mailto:[e-mail]] Sent: Tuesday, March 23, 2010 4:14
>>> PM To: Christian Hoene Cc: [e-mail] Subject: RE: [codec] #1:
>>> Application: 2.1. Point to point calls supporting transcoding?
>>> 
>>> Christian,
>>> 
>>> Please see my comments below.
>>> 
>>> James
>>> 
>>> -----Original Message----- From: Christian Hoene
>>> [mailto:[e-mail]] Sent: Tuesday, March 23, 2010 2:53 PM To:
>>> James Rafferty Cc: [e-mail] Subject: RE: [codec] #1: Application:
>>> 2.1. Point to point calls supporting transcoding?
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>>> For that matter, there will also be cases where a PSTN - IP gateway is
>>>> needed, but that's not usually defined as transcoding.
>>> 
>>> As a manufacturer of IP-to-IP gateways your insight knowledge is highly
>>> appreciated.
>>> 
>>> With best regards,
>>> 
>>> Christian Hoene
>>> 
>>> 
>>> 
>>>> 
>>>> James
>>>> 
>>>> James Rafferty Product Line Director, Integrated Media Gateways 
>>>> Dialogic, Inc. 15 Crawford Street Needham, MA 02494 USA
>>>> 
>>>> Tel:    [phone] Mobile: [phone] Fax:    [phone] Email:
>>>> [e-mail] 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: [e-mail]
>>>> [mailto:[e-mail]] On Behalf Of codec issue tracker Sent:
>>>> Tuesday, March 23, 2010 10:20 AM To: [e-mail] Cc:
>>>> [e-mail] Subject: [codec] #1: Application: 2.1. Point to point
>>>> calls supporting transcoding?
>>>> 
>>>> #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."
> 


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