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

[Roman Shpount <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>