RE: [Sipping] Use cases of multi-transcoding
"Burger, Eric" <eburger@cantata.com> Fri, 23 June 2006 20:17 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fts5U-0002xi-Q3; Fri, 23 Jun 2006 16:17:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fts5S-0002xF-Pg for sipping@ietf.org; Fri, 23 Jun 2006 16:17:06 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fts5R-0000YR-5f for sipping@ietf.org; Fri, 23 Jun 2006 16:17:06 -0400
X-IronPort-AV: i="4.06,170,1149480000"; d="scan'208"; a="34556004:sNHT39611688"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sipping] Use cases of multi-transcoding
Date: Fri, 23 Jun 2006 16:18:32 -0400
Message-ID: <330A23D8336C0346B5C1A5BB196666470317AB24@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] Use cases of multi-transcoding
Thread-Index: AcZEZtSZUd6e0vnUSlyPo2buWI8EAxSPyuuA
From: "Burger, Eric" <eburger@cantata.com>
To: sipping@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0153373647=="
Errors-To: sipping-bounces@ietf.org
Disclaimer #1: We love, I mean, we really LOVE multi-transcoding! I get off (or at least my stock value goes up) every time I get to sell four operators a transcoding IP gateway (our IMG 1010, if you want to buy one :)) because they all want to have "their" codec running in their network. Item #2: We all think this is stupid. Hey, the Internet is all about end-to-end, and nothing goes on in the middle. Comment #3: "Let the open market decide." Well, the open market decided. Operators want to run single codecs and, responding to demand, we've got the gear for them. Point #4: Well, it turns out that microeconomics really *is* working here. It turns out if your endpoints predominantly use a single codec, it is way more economical to normalize "foreign" codecs into the predominant codec. This is a result of the way equipment manufacturers have to pay for the hardware, software, and licenses for multiple codecs. It can be much more economical to normalize the odd codec at the boarder than to put the capability to handle all possible codecs into all of your endpoints. Point #5: Point number 4 is an issue of Network Engineering, not physics. In plain English, what is right for my network may be totally wrong for your network. THERE IS NO RIGHT ANSWER. Silly Plan for Action #6: If you really want to have "Internet codecs," I would offer one takes the following steps: 1. Lobby your government to ban G.7xx 2. Lobby your government to ban G.7xx-WB 3. Lobby your government to seize the property rights of IPR holders in so-called "free" codecs, like iLBC and speex, so that when the patent trolls surface, we do not get any nasty surprises. [On point 6.3, I absolutely have NOT done a patent search, but technologies like LPC, ADPCM, voice feature extraction, vocal tract modeling, etc. have all been patented. I have not looked at the details of iLBC or speex, but I would be surprised if they do NOT build on the IPR of the past 20 years to accomplish their task.] As an equipment manufacturer, at least I know the 23 entities to pay for an AMR license and the 14 entities to pay for a H.264 license. Are you going to indemnify me for iLBC and speex? Real Proposal #7: What is really needed is an end-to-end signaling protocol. Who knows - it may just turn out that both endpoints speak the same protocol. Oh! I forgot: that is called "SIP." I really don't mind if you want to put in B2BUA's at your boarder. If you have a little pipe (like a wireless network), I really DO expect you to want to use a low-bit-rate codec through the network, even if both endpoints can do a 1.5Mb/s ultra-high-fidelity, 12-channel surround sound codec with Sensoround(tm). On the other hand, be prepared to spend some money with me for some IMG 1010's and a SBC or two from our partners :-) ________________________________________ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com] Sent: Friday, March 10, 2006 11:49 AM To: Kang Tae-Gyu; Henry Sinnreich; Albrecht.Schwarz@alcatel.de Cc: sipping@ietf.org Subject: RE: [Sipping] Use cases of multi-transcoding Folks: I am just reacting to default codec vs. codecs in the Open market. The important points are as follows: 1. Is it worthwhile to bear the burden of price and (degrading) quality/QoS through supporting all possible codecs and transcoding by general public if there is no default codec? 2. Is not the objective of the standardization to improve the price and quality/QoS for the sake of mass marketing? 3. If the default codec is not chosen, who is going to be benefited? Will the mass population of the whole world reap benefits as the IETF is after if the default codec is not chosen? 4. Is it not the time the SIP/SIPPING and IETF Best regards, Radhika ________________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Kang Tae-Gyu Sent: Thursday, March 09, 2006 10:38 PM To: Henry Sinnreich; Albrecht.Schwarz@alcatel.de Cc: sipping@ietf.org Subject: RE: [Sipping] Use cases of multi-transcoding Henry, in line Thanks, Kang ---------------------------------- It seems there are several issues in this debate (in increasing order of disruption ☺ ): 1. Are there too many codecs around? If yes, what is the minimum number of codecs that should be supported? What is the recommended default codec? (As mentioned, my pick is iLBC as the default and SPEEX for wideband). --> Yes, there are too many codecs; G.711 in PSTN, AMR in GSM/3GPP, EVRC, QCELP or SMV in 3GPP2, G.723.1, G.729, G.711, internet Low Bit Rate Codec (iLBC) for narrowband VoIP, AMR-WB in 3GPP, VMR-WB in 3GPP2, G.729EV in ITU-T SG 16 Question 10, a wideband codec in ITU-T SG 16 Question 9, AAC(Advanced Audio Coding), and Speex. --> I wonder whether we are able to select a default codec. I believe that open market is better than closed one. 2. Can transcoding between domains be avoided or at least minimized? (Hint: Avoided at all cost). --> I agree with you that we should make an effort to avoide or at least minimized transcoding between domains even if we have a default speech codec. --> But, minimized transcoding is inevitable in real networks. --> So, my draft is a kind of efforts for minimizing transcoding in multi-network, multi-ITSP, multi-terminal verdor, and multi-codec existence environment. 3. Why are intermediate VoIP domains necessary at all, when e2e services like Skype have proven to be successful and having the best audio quality (apart from the e2e QoS debate)? Editorial: Intermediate VoIP domains are IMHO a revenue objective, but have no technical justification on the e2e Internet and no amount of politics can prevail in the long term over sound technology. --> I prefer to share a VoIP industry rather than to dominate by powerful something. ________________________________________ From: Kang Tae-Gyu [mailto:tgkang@etri.re.kr] Sent: Tuesday, March 07, 2006 1:30 AM To: Henry Sinnreich; Albrecht.Schwarz@alcatel.de Cc: sipping@ietf.org Subject: RE: [Sipping] Use cases of multi-transcoding Hi, Henry If industry has a specific "internet codec", SIP/SDP will be more simple signaling protocol. But, I believe that SIP/SDP tries to support any codec and any media. I think that the making default codec is another issue. Thanks, Kang -------------------------------------------------------- The numerous wireline legacy ITU-T G.7xx codecs and other countless codecs deployed for mobile phones are a disgrace IMHO. The industry would be better off adopting "Internet codecs": The iLBC RFC 3951 and RFC 3952 as the default codec and SPEEX for variable rate wideband (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-avt-rtp-speex- 00.txt). Thanks, Henry -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] Sent: Tuesday, February 21, 2006 8:29 AM To: Kang Tae-Gyu Cc: sipping@ietf.org Subject: Re: [Sipping] Use cases of multi-transcoding Hi Kang, just a comment to the transcoding scenario between two different WB codecs (WB1<->WB2). Transcoding as such should be avoided because it is inherently decreasing the audio/speech quality ("adds e.g., delay impairments and Ie, equipment impairment factors") and an "expensive" network function. There must be therefore an agreed justifaction, particularly for WB1<->WB2 transcoding scenarios! Transcoding between two different NB codecs (NB1<->NB2) is often inevitable. The difference with WB codecs is that terminals "should support a fallback mode to a NB codec" in my opinion. There are two possibilities: NB mode is part of the WB codec modes of operation (e.g., G.729EV with G.729A as NB mode), or separate NB codec (e.g., terminal concept according G.725). The inconsistent "WB1<->WB2" E2E scenario might then lead to fallbacks to (default) NB codecs. In case of a then "NB1<->NB2" inconsistency to NB transcoding in the network. Comments? Albrecht "Kang Tae-Gyu" <tgkang@etri.re. To: <sipping@ietf.org> kr> cc: xupeili@huawei.com, rohan@ekabal.com, Gonzalo.Camarillo@ericsson.com, dean.willis@softarmor.com 21.02.2006 03:12 Subject: [Sipping] Use cases of multi-transcoding Please respond to Kang Tae-Gyu Hello, I would like to discuss about the use case of multi-transcoding. First of all, I am sorry for that I could not answer about its use case when I received the question from the floor, IETF 64 Vancouver meeting, because of poor English. Also, thank you for the minutes(chairmen and note takers). There are three kinds of use cases of multi-transcoding. - one or two more heterogeneous networks - one or two more ITSPs - one or two more wideband speech codecs There are one or two more heterogeneous networks: enterprise networks using IP-PBX, ITSP(Internet Telephony Service Provider), IMS in 3GPP2, PacketCable, and Wibro. They will not use a common codec. So, they need multi transcoding such as; - use case 1: A(a) - IP PBX T1(a-b) - ITSP T2(b-c, b-d) - IMS T3(a-d, d-e) - D(d) - use case 2: A(a) - IP PBX T1(a-b) - ITSP T2(b-c, b-d) - PacketCable T4(c-d) - F(d) - use case 3: E(e) - IMS T3(a-d, e-d) - ITSP T2(b-c, b-d) - Wibro T4(a-d, d-c) - G(c) There are one or two more ITSPs or SBC because all of internet telephony subscribers will not subscribe only one ITSP. There are a lot of domestic ITSPs and international ITSPs or ITXP. Internet telephony should be supported any kind of terminal vendor even though it supports any specific codec. It also supports multi call forwarding service. So, they need multi transcoding such as; - use case 4: C(c) - ITSP T2(c-b, b-d) - ITSP T6(b-a, b-d) - ITSP7 T7(a-d, d-e) - G(d) There are one or two more wideband speech codecs. There has been developing one or two more wideband speech codecs for internet telephony: AMR-WB in 3GPP, VMR-WB in 3GPP2, G.729EV in ITU-T SG 16 Question 10, a wideband codec in ITU-T SG 16 Question 9, and AAC in ISO/IEC. In this convention, Capital letter means a node and lowercase(a, b, c, d, and e) means a codec. A wideband codec encodes voice using 16,000 samples per second (50 ~ 7,000Hz), as opposed to the 8,000 samples per second (300 ~ 3,400Hz) by narrowband codec. A voice quality of wideband codec is better than one of narrowband codec due to support wider band. A tandem transcoding means to encode narrowband codec such as G.711. So, it makes down sampling and worse the voice quality. If two parties(calling party and called party) have two different wideband codecs, transcoders should transcode a wideband codec to another wideband codec without tandem transcoding. If we use a common codec with G.711(tandem), there is no more need multi-transcoding. But, we need a multi-transcoding for supplying a wideband speech high quality to each sides. - use case 5: wideband codec to wideband codec without tandem transcoding Multi transcoding signaling can be useful for internet telephony environments supported by standard; an example VoIP network in quality of service for next generation Voice over IP networks, MSF-TR-QoS-001.final, 2003 Feb, and Telecommunications and Internet Protocol Harmonization over Networks (TIPHON) Release 3; End-to-End Quality of Service in TIPHON Systems; Part 3: Signalling and Control of End-to-End Quality of Service (QoS)-V2.1.2, 2002. Multi trascoder can cover the use case using one or two more conference bridge transcoding model. We would like to discuss open these use cases or another use case. Comments are welcome. Thanks, Kang _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
_______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] Use cases of multi-transcoding Kang Tae-Gyu
- Re: [Sipping] Use cases of multi-transcoding Albrecht.Schwarz
- RE: [Sipping] Use cases of multi-transcoding Henry Sinnreich
- RE: [Sipping] Use cases of multi-transcoding Nathan Allen Stratton
- RE: Re: [Sipping] Use cases of multi-transcoding Kang Tae-Gyu
- RE: [Sipping] Use cases of multi-transcoding LAI, SHOU WEN -HCHBJ
- RE: [Sipping] Use cases of multi-transcoding Kang Tae-Gyu
- RE: [Sipping] Use cases of multi-transcoding Kang Tae-Gyu
- RE: [Sipping] Use cases of multi-transcoding Henry Sinnreich
- RE: [Sipping] Use cases of multi-transcoding Roy, Radhika R.
- RE: [Sipping] Use cases of multi-transcoding Drage, Keith (Keith)
- RE: [Sipping] Use cases of multi-transcoding Brian Rosen
- RE: [Sipping] Use cases of multi-transcoding Henry Sinnreich
- Re: [Sipping] Use cases of multi-transcoding Tom-PT Taylor
- RE: [Sipping] Use cases of multi-transcoding Michael Hammer (mhammer)
- Re: [Sipping] Use cases of multi-transcoding Stephen Sprunk
- RE: [Sipping] Use cases of multi-transcoding Kang Tae-Gyu
- RE: [Sipping] Use cases of multi-transcoding Roy, Radhika R.
- RE: [Sipping] Use cases of multi-transcoding Burger, Eric