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

[stephen botzko <[e-mail]>]

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

We will NOT know if an ITU codec tandems with this codec with acceptable
quality unless we test the combination.  The ITU does not warrant that their
codecs will tandem with anything.  No one does.

And even in a VOIP framework, the audio will be transcoded sometimes.  At
least some VOIP infrastructures are set up to use specific codecs (for
instance G.729) and transcode anything else to that format.  And certainly
this audio will be transcoded when it enters a cellular or PSTN network.

If you end up with a free internet codec, but everyone has to carry all the
royalty-bearing codecs also (so that transcoding is never needed), then it
seems to me that you are not accomplishing your goal.  I think tandeming has
to be tested, precisely because we expect implementations to include devices
which only support this codec.

Stephen Botzko

On Sun, Mar 28, 2010 at 1:30 PM, Marc Petit-Huguenin <[e-mail]>wrote:

> 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
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>