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

[Justin Uberti <[e-mail]>]

On Tue, Nov 15, 2011 at 7:35 AM, Tim Panton <[e-mail]> wrote:

>
> 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.
>

Please, at least move this discussion to a new thread.

>
>