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

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

Agree fully. The SDP o/a is IMO there to set up media streams already 
agreed on (including level of protection) using other means.

On 2011-09-12 04:58, Roman Shpount wrote:
> I guess what I do not understand in this discussion is why do we need to
> negotiate all of this in the offer/answer. We need something that can
> interop with offer answer, but no more then that. The client JavaScript
> application should have control and ability to specify what kind of
> offer is generated. We can use the exisitng HTTP connection to get all
> the additional restrictions and options for the call. It is normally
> known to the application if the security is needed and supported. The
> functionality of figuring out device capabilities and user intent of
> this call (secure call to the bank or public video chat) should be left
> to the application and should not be part of this specification. What's
> currently is missing is ability to transmit and receive media. The rest
> of the features, such as getting events including new call event from
> the server, sending events to the server, maintaining a persistent
> connection from behind firewall and NAT is already present in the
> current web infrastructure. We do not need a new signaling protocol or
> standard. We do not need to add an existing signaling protocol not
> implemented by the browser such as SIP. It adds no new functionality and
> makes standard bigger and more difficult to comply. All that is needed
> is media.
> _____________
> Roman Shpount
>
>
> On Sun, Sep 11, 2011 at 9:39 AM, Timothy B. Terriberry
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>         * The level of media protection to use (NONE, SDES-SRTP or
>         DTLS-SRTP) should be set by the web app
>
>
>     Why wouldn't this devolve to, "Don't communicate anything. Instead,
>     try to create a PeerConnection with DTLS-SRTP, and when that fails,
>     try to create a second one with NONE," in the actual webapp.
>
>     Or, more likely, since NONE will have a better chance of working
>     with legacy devices, "Try to create a PeerConnection with NONE, and
>     when that fails, try to create a second one with DTLS-SRTP."
>     Assuming anyone bothers with the second step. Having the choice of
>     SDES-SRTP or DTLS-SRTP will also make it more likely people won't
>     bother with either, as they won't know which one to use. We can try
>     to create incentives with browser chrome, but there's only so much
>     that can do.
>
>     _________________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>