Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)

[Tim Panton <[e-mail]>]

On 14 Nov 2011, at 08:38, Harald Alvestrand wrote:

> On 11/14/2011 04:30 PM, Tim Panton wrote:
>> On 13 Nov 2011, at 22:50, Marc Petit-Huguenin wrote:
>> 
>>> On 11/13/2011 01:46 PM, Miguel Casas-Sanchez wrote:
>>>> İt is indeed very interesting to have interoperability with loads of systems,
>>>> but that should (personal opinion) be left to the applications, and not be
>>>> suggested in a standard that everyone will need to parse. So: keep standard lean
>>>> would be my vote (=leave dtmf out) try and focus on mandatory and really
>>>> nice-to-have features.
>>>> Miguel
>>> I do not know why you and others are singling out DTMF.  I am no fan of building
>>> stuff around carriers needs myself, but DTMF is a codec, no more, no less.  Even
>>> the fast codec switching mechanism is not special - comfort noise use it too,
>>> and a system that would recognize music and dynamically switch between audio and
>>> MIDI would probably be considered innovative.
>> Which gives further weight to my argument that we should be exposing the codec
>> as  a javascript object , the we could have a generic 'notification from this codec instance'
>> callback, instead of doing all these legacy hacks as one-off special cases.
> what would the codec object represent?

The publicly useful state of a current codec instance. 

Properties like - bitrate, error - rate, width, height, quality
complexity, sample-rate, quantity available (possible hardware limits...), 
name, SDP stanza (perhaps), current status (initialized etc) 

Property change notifiers (if the far end changes what it is sending we get a notification here).

Setters for such properties as make sense to set (some might be valid only pre-initialization)

codec specific events  (silence detection, tone detect, typing detect , 
whiteout, dtmf perhaps, movement detection)

And the really controversial one:  an api to allow manipulation of the encoded and
decoded datastreams by inserting filters into the pipeline before or after the codec.
- (Like DMR's streams pre unix SystemV)


> 
> The currently proposed API presents a MediaStreamTrack object.
> How would a codec object relate to the MediaStreamTrack object?
> 

I don't know - let me look at the MediaStreamTrack again and get back to you.

> (this is an api discussion, so probably belongs on the W3C list)

Lets keep it here for now and see if anything solid comes of it.
> 
>               Harald
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb