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

[Paul Kyzivat <[e-mail]>]

On 9/11/11 4:49 AM, Stefan Håkansson LK wrote:
> 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.

I think I can buy this approach up to this point - that the JS in the 
browser can know that something special is required because its an 
interop case.

The harder point is knowing *what* is required in the interop case.
If the goal is to avoid needing a media gateway in this case, then what 
is required will be determined as part of the O/A. Or it can 
contractually negotiated for each different federation target.

Hadriel seems to be arguing that a media gateway will always be needed 
in the federation case. Making that assumption will certainly simplify 
rtcweb, but it also ensures a cost for federation. It is essentially the 
same cost that is incurred when sip users and service providers require 
the use of SBCs at their borders. So far that has been a cost that 
people have willingly paid.

This can be abstracted as a partitioning of the features covered by RFC 
3264 O/A into categories:
- features to be entirely fixed for rtcweb
- features to be chosen/negotiated by the web application using
   application-specific logic and communicated to the browser via JS
   prior to session establishment.
- features to be negotiated via o/a by the browser
- features to be negotiated via o/a in JS running in the browser

Then the discussion has been about people arguing for different 
partitionings - mostly extremes. Some that I am seeing:

1) (Cullen) everything should be negotiated by o/a in the browser.
    (Presumably with some interaction with JS for ICE candidate
    selection.) The logical conclusion of this (I'm not sure Cullen
    is arguing for this) is that capneg must be included and used
    to handle the security negotiation.

2) (Hadriel?) The security mechanism, and use of ICE,
    is fixed for rtcweb. ICE candidate selection and all the
    rest of o/a is handled in JS.

(That is just a stab - sorry if I have mis-characterized. Please jump in 
and correct me.)

This is a fundamental decision to make. When federating, features that 
are chosen prior to session establishment will be the result of private 
agreements and result in a form of balkanization. When federating via 
sip to a target that doesn't have fixed values for features that must be 
pre-agreed, the only option will be a media gateway.

	Thanks,
	Paul

> 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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>