Re: [codec] #21: Supporting Wireless Links?

["codec issue tracker" <[e-mail]>]

#21: Supporting Wireless Links?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:  jean-marc.valin@…             
     Type:  defect                  |      Status:  new                           
 Priority:  major                   |   Milestone:                                
Component:  requirements            |     Version:                                
 Severity:  -                       |    Keywords:                                
------------------------------------+---------------------------------------
Changes (by hoene@…):

  * owner:  => jean-marc.valin@…


Comment:

 [Benjamin:]
 > Me too; I'd also like some clarification as to whether we're talking
 > about (a) > existing Bluetooth headsets or
 > ... If (a)
 > ... I'm surprised that such a retrofit is even conceivable.  If it is
 > in fact possible, I would very much appreciate instructions on how to
 > experiment with new codecs on existing headsets.  Once we know how to
 > build test rigs, we can see what the complexity requirement there is.
 > If we can't test it, I don't think we can target it.

 [Raymond]: I was definitely talking about (b), not (a).

 [Raymond]: Correction: I never argued that we should add a "Bluetooth
 mode".
 ...
 Bluetooth headset was merely given as an example.

 Considering that there are a very large number of Bluetooth headset users
 and that the current Bluetooth headsets can already be used for making
 VoIP phone calls, it would be great if the IETF codec can be implemented
 in future Bluetooth headsets to avoid the additional coding distortion and
 delay associated with transcoding. However, with that said, I didn't mean
 to push a "Bluetooth mode" for the IETF codec. I merely wanted to use
 Bluetooth headset as an example to make a point that a low codec
 complexity is desirable and a high codec complexity can have negative
 consequences.

 [Christian]:
 > The week before, we were discussing whether to consider Bluetooth and
 > Wireless IP as use cases. It seems to be a rough consensus that
 > wireless IP is in-scope and that Bluetooth is out-of-scope because it
 > requires too special optimizations. However, battery powered, wireless
 > devices might require low-complexity and low-bandwidth (and are
 > in-scope?).

 [Raymond]: I read an article that says that PC was the big thing in the
 decade of 1990-2000, Internet was the big thing in the decade of 2000-
 2010, and Mobile Internet will be the next big thing in the decade of
 2010- 2020. Judging from the recent trends in smart phones, netbooks, and
 Tablets/iPad, it seems that Mobile Internet indeed will be the next big
 thing this decade.  Given this, I think battery-powered wireless Internet-
 capable devices should be in-scope, and low codec complexity is an
 important consideration in these devices.

 CONSENSUS: Wireless IP is in scope; non-IP Bluetooth is out.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/21#comment:2>
codec <http://tools.ietf.org/codec/>