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

[Roman Shpount <[e-mail]>]

I think we should provide a way in JavaScript API to specify if encryption
is required. We should be able to negotiate an open channel connection as
well as encrypted one, if for not other reason then for debugging. It would
be extremely hard to debug and troubleshoot any issues if all communications
are encrypted.

On the Offer/Answer side of the question, I don't think the question is to
support or not support offer answer. I think what we should try to
accomplish is a JavaScript API that allows to create solutions that will
interop with offer answer. We can have API methods that provide additional
media negotiation capabilities and it will be up to an application to decide
if offer/answer interoperability is required for it or if other more feature
complete or convenient API should be used. Not all the calls originated from
the RTC client will need to be connected to old PSTN devices, but ability to
be able to connect to old PSTN devices without using a media proxy is highly
desired.
_____________
Roman Shpount


On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox <[e-mail]> wrote:

> Indeed.
>
> More generally, the question is: should it be possible to send an offer
> that by default does DTLS/SAVPF for RTCWeb, but also can fall back to other
> RTP profiles to support legacy devices?
>
> If yes, then either browsers need to support CapNeg, or RTCWeb needs to use
> something other than SDP Offer/Answer.
>
> If no, then supporting interop, without a media gateway, with other
> non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.)
> becomes IMO a lot less compelling.
>
> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Thursday, September 08, 2011 2:35 AM
> To: Randell Jesup; Jonathan Lennox
> Cc: [e-mail]
> Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)]
>
>
> Hi,
>
> >>>You could make forced-encryption the default, and allow the
> >>>application control over whether to allow it is turned off for
> >>>specific cases, like a PSTN call, or under the server's control.
> >>>Signalling is secure, so it could even use a direct optional
> >>>downgrade from SAVP* to AVP* (i.e.
> >>>similar to the best-effort-strp draft)
> >>This has implications for the parallel thread about the use of SDP
> >>offer/answer.
> >>
> >>The solution MMUSIC has standardized for best-effort SRTP is SDP
> >>CapNeg, RFC 5939.  Do we want to require CapNeg support in browsers?
> >
> >Yeah, ok, I'm not going there.  :-)  It's probably not needed for this
> >use-case anyways.
>
> The same question exists for AVPF, which has been suggested to be mandated.
>
> Regards,
>
> Christer
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>