(no subject)

I'm increasingly of the opinion that the merits of adding a non-encrypted
mode are less and less attractive. It's more work all round with marginal
payoff.
On Dec 26, 2013 11:07 AM, "Peter Thatcher" <pthatcher@google.com> wrote:

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