Subject: [rtcweb] API requirements

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Jul 2012 14:10:27 -0700

We have just submitted a draft for discussion in the rtcweb working group:

    <http://tools.ietf.org/html/draft-thomson-rtcweb-api-reqs-00>

This draft describes the information that must pass between browser
and application in order to establish real-time communications.  This
is not user-facing requirements (-rtcweb-use-cases-and-requirements)
or an outright API specification (-jsep).

The goal here is to enable the creation and consumption of streams of
media packets within the security constraints.  The draft describes
the minimum necessary set of information only to achieve this end.

In related news, Microsoft just joined the W3C Web Real-Time
Communications Working Group.  Once a few clerical issues are
addressed, new W3C proposals that address these requirements will
follow.

--Martin

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 09 Jul 2012 15:29:52 -0700

> addressed, new W3C proposals that address these requirements will

This is excellent news. Welcome aboard!

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 19 Jul 2012 11:56:04 +0200

> the minimum necessary set of information only to achieve this end.
Thanks for submitting this!

I must admit to being quite confused by the actual requirements in the 
draft - I have no idea what use case they're intending to enable, and 
thus I have no idea why the authors have chosen MUST rather than SHOULD 
or MAY as the requirement levels.

For instance.

    ICE-5  The application MUST be able to add STUN attributes to the
           STUN messages that are sent for connectivity checks.

What application does this enable? What are the security implications?

    MED-1   The application MUST be able to select the UDP flow that an
            RTP stream uses.

    MED-2   The application MUST be able select the UDP flow that RTCP
            for a given RTP stream uses.

What application does this enable, compared to mechanisms that assign 
RTP and RTCP to a given UDP flow and report the results back?

    MED-7   The application MUST be able to specify the RTP packet type
            that is used to identify codecs in RTP streams, both inbound
            and outbound.

Again, what application does this enable, compared to mechanisms that 
assign a packet type and inform the application of which one was chosen?

> addressed, new W3C proposals that address these requirements will
Looking forward to seeing the proposals, and seeing your proposals for 
how they can be pursued without impacting the progress of the present 
specifications and implementations!

>
> --Martin
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Jul 2012 09:40:10 -0700

On 19 July 2012 02:56, Harald Alvestrand <[email-masked]> wrote:
> I must admit to being quite confused by the actual requirements in the draft
> - I have no idea what use case they're intending to enable, and thus I have
> no idea why the authors have chosen MUST rather than SHOULD or MAY as the
> requirement levels.

The point was to describe the minimal set of information that needs to
pass between application and browser in order to accomplish the tasks
described in (draft-rtcweb-use-cases-...) using the protocols and
security mechanisms described in (-rtp-usage and -security-*).  This
aims to be more specific than Section 10 of -rtp-usage and to cover
the other features.

It's a -00 draft.  We acknowledge that the rationale is a little light
(read: not there).

> What application does this enable?

This would enable proprietary STUN extensions that include session
identification, authorization, bandwidth negotiation, data transfer,
and other purposes.  Primarily, this is associated with the
"connectivity check" made to a STUN server.

> What are the security implications?

I'm sure you can invent some if you think about it hard enough.  As I
understand it, the application is in complete control over the
username fragment, so this adds no greater advantage to an application
than is already present.  This is just added flexibility that will
enable greater interoperability.  As long as the browser ensures that
the STUN packet fits within the defined size limit, there are none.

> What application does this enable, compared to mechanisms that assign RTP
> and RTCP to a given UDP flow and report the results back?

This is another interoperability requirement.  What you say is only
true if both peers perform compatible allocations.  You will note that
by moving candidates between m= lines, JSEP already offers this
capability.  Assuming of course that the browsers implement that.

> Again, what application does this enable, compared to mechanisms that assign
> a packet type and inform the application of which one was chosen?

Same reason as above.

> Looking forward to seeing the proposals, and seeing your proposals for how
> they can be pursued without impacting the progress of the present

I'm still working on this.  Don't expect the impossible though.