Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

[Stefan Håkansson LK <[e-mail]>]

In my mind I had built a slightly different model of how this would work. In essence, the SDP o/a would not be allowed to negotiate encryption or not, that should be set when creating the PeerConnection object:

* The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) should be set by the web app when a PeerConnection object is created (possibly part of the configuration string)
* One pre-requisite for the PeerConnection to enter the “open” state (and for streams to be set up) must be that the same level of protection is selected by both peer apps
* We should never allow any SDP o/a to negotiate away from the selected level of protection.

This would work just fine in the most common use cases as it is the same app, served by the same server, running in both browsers, and since support of NONE, SDES-SRTP and DTLS-SRTP in browsers should be mandated. The service provider/app developer decides.

The tricky part would be interop. But if we take the ‘browser to browser, but the app coming from different sources’ case, the two teams developing the apps must communicate any way to make them interop. Agreeing on whether to use NONE, SDES-SRTP or DTLS-SRTP is just one detail to agree on.

Developers of apps to interop with legacy must acquire enough info about the system to interop with to make the right setting of PeerConnection for the specific case.

Remember, the primary target for this activity is browser-to-browser. This should be simple and straightforward for the app developer. That the app developer would have to think a bit more for interop cases is quite OK IMO.

Stefan
________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Randell Jesup [[e-mail]]
Sent: Sunday, September 11, 2011 4:03 AM
To: [e-mail]
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

On 9/10/2011 8:16 PM, Christer Holmberg wrote:
>
>> The exact same thing could arise if we had somebody with an urgent
>> desire to do secure media with fallback to insecure media in SIP.
>> All the arguments against capneg would be exactly the same.
>>
>> The problem is that people aren't finding capneg a usable solution to
>> this problem, just the way that people didn't find SDPng a solution to
>> the inadequacies of SDP.
>>
>> While it is possible for rtcweb to adopt its own solution to the
>> problem, that only solves half the problem. And it then creates an
>> interop problem with SIP.
> A send-a-new-offer-if-the-first-offers-fails mechanism would be backward compatible - assuming the offerer can guess why the first offer failed.
>
> Also, using the AVP and RTP profiles, together with attributes that specifies the AVPF and SRTP stuff would also work. Of course, it goes against the current AVPF and SRTP specifications, and since current legacy deployments would not understand such attributes, they would always end up using AVP and RTP.

I think what you've speced here is basically similar to the
draft-best-effort-srtp proposal.


--
Randell Jesup
[e-mail]

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb