Re: [Wish] WHIP should also allow *media* to be sent over the HTTPS connection

[Alexandre GOUAILLARD <[e-mail]>]

>
> > On Mar 12, 2021, at 7:41 PM, Alexandre GOUAILLARD <[e-mail]>
> wrote:
> >
> > Media management is entirely delegated to the RTCWEB specifications. In
> particular, the use of ICE, and the use of DTLS-SRTP are mandatory. For
> clarification, the use of JSEP, SDP, SDP O/A are also all mandatory.
>
> Alex,
>
> I think you may be missing my point.  A WebRTC stream that happens to
> negotiate COMEDIA transport (with RFC 4571 framing of RTP/RTCP) is still,
> in my mind, a WebRTC stream.  It would be negotiated the same way as any
> other WebRTC stream (using JSEP, SDP, O/A).  But the stream itself wouldn’t
> use datagrams, and thus wouldn’t use ICE (because it wouldn’t need it).
> That’s why I described this as being ‘WHIP-light’ - a subset of the WHIP
> protocol just for this simple class of streams.
>
> Perhaps I have a more expansive view of WebRTC than everyone else, but I
> consider what I’m describing as being a WebRTC stream; albeit a special
> case.
>
>         Ross.
>
>
Ross,

- If you are speaking about Media (e.g. if your question is: "does this
constitute a legitimate webrtc stream"), then you need to bring the
discussion to the RTCWEB group.
- If your media is a legitimate WebRTC stream, then there is nothing
special to discuss about it in this working group either, since we will
handle all WebRTC streams which correspond to our sub use case (one way
only, from a WebRTC end-point to a server, ...).
- if you want to propose a use case or a feature not in scope for the WISH
working group, The right place is the DISPATCH mailing list.

I encourage you to read the following RFC and references therein:
section 2.2 of RFC 8825, which defines the different notions and entities,
to separate browsers from non browsers entities for example,
section 5    of RFC 8825, which mandates DTLS-SRTP,
section 7    of RFC 8825, which mandates, among others, ICE.
If your proposal does not support DTLS-SRTP, and ICE, then it is not a
WebRTC Endpoint (even if Non-Browser).

"
   WebRTC Browser (also called a "WebRTC User Agent" or "WebRTC UA"):

      Something that conforms to both the protocol specification and the
      JavaScript API cited above.

   WebRTC Non-Browser:  Something that conforms to the protocol
      specification but does not claim to implement the JavaScript API.
      This can also be called a "WebRTC device" or "WebRTC native
      application".

   WebRTC Endpoint:  Either a WebRTC browser or a WebRTC non-browser.
      It conforms to the protocol specification.

[...]

   All WebRTC browsers are WebRTC endpoints, so any requirement on a
   WebRTC endpoint also applies to a WebRTC browser.

*(NOTE for *@Sean DuBois <[e-mail]> *=> Note the distinction
between browser and non-browser from the start.*

*This section below is likely the most interesting part for you)*

   A WebRTC non-browser may be capable of hosting applications in a way
   that is similar to the way in which a browser can host JavaScript
   applications, typically by offering APIs in other languages.  For
   instance, it may be implemented as a library that offers a C++ API
   intended to be loaded into applications.  In this case, security
   considerations similar to those for JavaScript may be needed;
   however, since such APIs are not defined or referenced here, this
   document cannot give any specific rules for those interfaces."


"
      5 <https://tools.ietf.org/html/rfc8825#section-5>. Data Framing and
Securing

   The format for media transport is RTP [RFC3550
<https://tools.ietf.org/html/rfc3550>].  Implementation of
   the Secure Real-time Transport Protocol (SRTP) [RFC3711
<https://tools.ietf.org/html/rfc3711>] is *REQUIRED*
   for all implementations.

   The detailed considerations for usage of functions from RTP and SRTP
   are given in [RFC8834 <https://tools.ietf.org/html/rfc8834>].  The
security considerations for the WebRTC
   use case are provided in [RFC8826
<https://tools.ietf.org/html/rfc8826>], and the resulting security
   functions are described in [RFC8827 <https://tools.ietf.org/html/rfc8827>].

"

"
      7 <https://tools.ietf.org/html/rfc8825#section-7>. Connection
Management
      [...]

   WebRTC endpoints *MUST* implement those functions described in
   [RFC8829 <https://tools.ietf.org/html/rfc8829>] that relate to the
network layer (e.g., BUNDLE [RFC8843
<https://tools.ietf.org/html/rfc8843>],
   "rtcp-mux" [RFC5761 <https://tools.ietf.org/html/rfc5761>], and
Trickle ICE [RFC8838 <https://tools.ietf.org/html/rfc8838>]), but
these endpoints
   do not need to support the API functionality described in [RFC8829
<https://tools.ietf.org/html/rfc8829>].

"

   - Dr Alex, Chair.