Re: [Sipping] Use cases of multi-transcoding

["Tom-PT Taylor" <[e-mail]>]

You really want to restart the IPR wars??? We got saddled with an 
inferior codec (G.723.1) back in 1997 simply because the IPR coalition 
about that codec prevailed.

Roy, Radhika R. wrote:
> Hi, Kang, Henry, and all:
> 
>  
> 
> It is the time to select "DEFAULT" codec by the IETF for the Internet.
> SIPPING/SIP WG needs to mandate this. 
> 
>  
> 
> (In olden days, ITU-T defined their default G.711 audio codec for the IP
> Network mandating PSTN network interoperability [ridiculous!!]. Then IMTC
> did something mandating a lower-speed codec.)
> 
>  
> 
> Some proposals are coming from your side. Can we get the consensus to
> mandate these requirements for the Internet to the benefit of the users?
> 
>  
> 
> Best regards,
> 
> Radhika
> 
>  
> 
>   _____  
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Henry Sinnreich
> Sent: Tuesday, March 07, 2006 9:24 AM
> To: Kang Tae-Gyu; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Sipping] Use cases of multi-transcoding
> 
>  
> 
> 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).
> 
>  
> 
> 2.	Can transcoding between domains be avoided or at least minimized?
> (Hint: Avoided at all cost).
> 
>  
> 
> 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.
> 
> Thanks, Henry
> 
>   _____  
> 
> From: Kang Tae-Gyu [mailto:[e-mail]] 
> Sent: Tuesday, March 07, 2006 1:30 AM
> To: Henry Sinnreich; [e-mail]
> Cc: [e-mail]
> 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-
> <ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-avt-rtp-speex-
> 
> 00.txt).
> 
> Thanks, Henry
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]
> <mailto:[e-mail]> ]
> Sent: Tuesday, February 21, 2006 8:29 AM
> To: Kang Tae-Gyu
> Cc: [e-mail]
> 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"
> 
>                       <[e-mail].         To:      <[e-mail]>
> 
>                       kr>                      cc:      [e-mail],
> [e-mail], [e-mail],     
>                                                [e-mail]
> 
>                       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
> <https://www1.ietf.org/mailman/listinfo/sipping> 
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping> 
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 
>  
> <http://umail.etri.re.kr/External_ReadCheck.aspx?email=[e-mail]&name
> =Henry+Sinnreich&fromemail=[e-mail]&messageid=%3C8ebc20e7-ea62-438c
> [e-mail]%3E> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP