Re:

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.

Received on Monday, 23 December 2013 00:45:47 UTC