Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Andrew Allen <aallen@blackberry.com> Fri, 15 March 2013 13:55 UTC

Return-Path: <prvs=778627bb81=aallen@blackberry.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4717821F85A1 for <rtcweb@ietfa.amsl.com>; Fri, 15 Mar 2013 06:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.185
X-Spam-Level:
X-Spam-Status: No, score=-5.185 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS8bjxTsLX4x for <rtcweb@ietfa.amsl.com>; Fri, 15 Mar 2013 06:55:30 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBC221F859A for <rtcweb@ietf.org>; Fri, 15 Mar 2013 06:55:29 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-e0-51432841f108
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id D4.A1.13213.24823415; Fri, 15 Mar 2013 08:55:14 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 08:55:13 -0500
From: Andrew Allen <aallen@blackberry.com>
To: "HKaplan@acmepacket.com" <HKaplan@acmepacket.com>
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAgQ3Oi2P7DjEKDSnUvQoKufpilc9aAgAAGtgCAAH5yAP//tpYYgABsYoCAAKyWnw==
Date: Fri, 15 Mar 2013 13:55:13 +0000
Message-ID: <BBF5DDFE515C3946BC18D733B20DAD2338D2B9A1@XMB104ADS.rim.net>
In-Reply-To: <21233D03-64FD-43D0-863E-18FC55BD0924@acmepacket.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsXC5Zyvpeuk4RxoMOOmpMWXhmSLuZefs1u0 /vzGbLH2XzuQNeMKm8WRrWuZHdg8Nk3ezOYx5fdGVo8lS34yebQ8O8nmcevBJLYA1qgGRpuk xJKy4Mz0PH07m8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE5EoFl8zi5JzEzNzUIiWFzBRb JRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r5Bnsr2thYWqpa6hk p5vQyZNxYU4za8Fz6Yo9+26wNTBeE+ti5OSQEDCR2DDtAguELSZx4d56ti5GLg4hgTYmicWz 9rBDOJsZJebd6QarYhPQkth/eDoTiC0iYCrx93I3WAezwFdGiS3rjgIVcXAIC8RLNJ8qhKhJ kJjyYw4zhB0m0d50mxHEZhFQlVi/cjkriM0r4CHx4MVOJpBWTgEniT3Py0DCjAKyErvPXgdb xSwgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxXCVpT4u/c7K0S9nsSNqVPYIGxtiWULXzNDrBKU ODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjEK5mYUG5gZJucl6xVl5urlpZZsYgSlFEcNgx2M 799bHGIU4GBU4uHNEXMOFGJNLCuuzD3EKMHBrCTC+/GiU6AQb0piZVVqUX58UWlOavEhRldg QExkluJOzgemu7ySeGMDA9wcJXHeMk2gIQLpwOSTnZpakFoEM4eJgxNkD5eUSDEwhaQWJZaW ZMSDEl18MTDVSTUw9rkqlm3KrDt94JzluhlT3vuxMLCvuC0UL/jL4t1+Gf+yv/YLjj/+MVXk wNlFaY8fHa49cCsmLnC/151ilo0zJ6R+1Hf8FvGzavuCDU2nC/K71qw1D354weel01yZuB25 l+19j326LrltV8Hm9+tdAn/KX50jFmmz4W2LYlvstIJjbx+cuGGZvlaJpTgj0VCLuag4EQAt +bzRagMAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "xavier.marjou@orange.com" <xavier.marjou@orange.com>
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2013 13:55:31 -0000

My response was directed to the current deployment situation and the comment/concern that currently the pre standard RTCweb browser implementations do not support Codecs used in some legacy networks.

While the technology may be there and the products even available they are not widely deployed today so currently there is not a business case for browser vendors to include these codecs as today practical interoperability is not possible.

Right now browser implementors are focused solely on achieving interoperability between browsers I expect. The additional codecs for legacy interop will I expect come in the future when the infrastructure is deployed to make this possible and if the right business case is there to make it commercially viable.

Andrew

----- Original Message -----
From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
Sent: Thursday, March 14, 2013 05:37 PM Central Standard Time
To: Andrew Allen
Cc: koen.vos@skype.net <koen.vos@skype.net>et>; espeberg@cisco.com <espeberg@cisco.com>om>; stephane.proust@orange.com <stephane.proust@orange.com>om>; xavier.marjou@orange.com <xavier.marjou@orange.com>om>; rtcweb@ietf.org <rtcweb@ietf.org>
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01


On Mar 14, 2013, at 5:09 PM, Andrew Allen <aallen@blackberry.com>
 wrote:

> Koen is right that there are many more obstacles to RTCweb and legacy network interop than just a common codec. First there will need to be RTCweb signaling gateways to interface between the RTCweb signaling and the legacy networks (SIP, H.323 etc) and there will need to be in place mechanisms for peering, federation and address resolution between networks as well as service agreements in place between the players.
> 
> Until those are resolved supporting codecs used in those networks is pointless.

There are already WebRTC-SIP gateways, as I think you know.  I know of two SBC vendors who are in customer labs with it, for example, and there are probably more.  And yes at least one of them, and probably both, can transcode the audio... though it's by no means free.  I don't know if the business case justifies the cost or not for WebRTC use-cases - it appears to in some cases, not others.

It costs far more than has been discussed on this list though, because we think like engineers and consider the cost as a CAPEX issue; whereas in practice the OPEX costs often dwarf the CAPEX ones.  In some data centers, for example, the local Real-Estate costs dwarf CAPEX too, and using less rack-space can pay for a product in no time. (there's an entire company out there that built its business leveraging this fact, replacing POTS switches with much-higher-density ones purely based on rack-space usage savings)

Anyway... moving on to your other point of federation/peering/etc. - I think the use-case that mobile operators have in mind is fairly obvious, and it clearly doesn't have that problem.  Whether you agree with helping that use-case or not is up to you and the rest of this WG, of course.  I'm just noting that peering isn't an obstacle for it.

-hadriel
p.s. Transcoding video, on the other hand, is untenable for pretty much anyone.  I have never heard of a business-case which justifies it, because it simply doesn't scale.  Except for maybe companies that live on other revenue sources, for whom all of this stuff is a rounding error in their IT budget. ;)


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.