(no subject)

On Sun, Dec 22, 2013 at 4:44 PM, Bernard Aboba
<Bernard.Aboba@microsoft.com>wrote:

> On Fri, Dec 6, 2013 at 8:35 AM, Roman Shpount <rshpount@turbobridge.com
> >wrote:
>
> >> a) Would this allow plain RTP and SCTP? If we can wire plain transports,
> >> can we wire SCTP and RTP directly to ICE?
> >>
>
> Peter Thatcher replied:
>
> >I think the answer to that is "no" for browsers.  DTLS would still be
> >required.  Mobile apps and other endpoints could, of course, do whatever
> >they want.
>
> [BA] I agree that the answer should be "no" for the ORTC API as
> implemented in a browser.   However, in a server scenario (e.g. node.js
> modules used to build a WebRTC-legacy gateway) or in a mobile application
> (e.g. "ortclib")  it could be quite useful to be able to support
> unencrypted RTP or SRTP/SDES key exchange, possibly without ICE.
>
> To avoid confusion between the ORTC browser API and future server/mobile
> functionality, it is probably best to focus the current ORTC API spec and
> examples purely on the browser case.  However, server requirements and
> functionality is something to keep in the back of our minds.


> Roman said:
>
> > b) There is a current discussion going on about changing ICE consent with
> > DTLS consent. How would this work in ORTC if DTLS is optional?
>
> Peter answered:
>
> > In general, ability to remove DTLS from the transport path would cause a
> > substantial security debate. It might be better to have ICE/DTLS
> transport
> > and provide new replacement transports in the future when they are
> > available and deemed secure.
>
> [BA]  For browser uses, DTLS will always be required to protect SCTP as
> well as for DTLS/SRTP key exchange.   But in a server scenario, one might
> want to enable an RTCRtpSender/Receiver object to have an rtpTransport
> attribute that represented an alternative transport.
>


​I agree with all of that: DTLS required for browsers, but an API flexible
enough for new replacement transports in the future or different kinds of
transports for native/mobile/server apps.