Subject: [rtcweb] Comments on draft-ietf-rtcweb-jsep-09

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Mar 2015 17:47:10 -0500

Hi,

I have reviewed draft-ietf-rtcweb-jsep-09 and have some comments.

1. Section 3.4.4:

   JSEP applications typically inform the browser to begin ICE gathering
   via the information supplied to setLocalDescription, as this is where
   the app specifies the number of media streams, and thereby ICE
   components, for which to gather candidates.  However, to accelerate
   cases where the application knows the number of ICE components to use
   ahead of time, it may ask the browser to gather a pool of potential
   ICE candidates to help ensure rapid media setup.

I wonder why this is not using the number of added media stream tracks
to the peerconnection as an indication to how big draw on the pool there
will be?

2. Section 4.1.1:

This section defines: balanced, max-compat and max-bundle. The Transport
draft defines in Section 4.1 the following:

   A sending implementation MUST be able to support the following
   configurations:

   o  multiplex all media and data on a single 5-tuple (fully bundled)

   o  send each media stream on its own 5-tuple and data on its own
      5-tuple (fully unbundled)

I am missing the policy related to the last of these bullets (fully
unbundled).

3. Section 4.1.2:

The
   exact handling of subsequent offer generation is detailed in
   Section 5.2.2. below.

I suggest that you remove the below. Section 5.2.2 is quite far away.

4. Section 5.1.1:

I think you can remove R-16 for now. If people are missing
specifications, then lets add them at the point when we realize that we
are missing it.

5. Section 5.1.3:

   o  The profile in any "m=" line in any answer MUST exactly match the
      profile provided in the offer.

I think I understand the reasons for this and works fine for the remote
peer getting a offer, and then producing an answer. This works less well
if checked on the offerer. Because, then what was offered, is not the
same that is received in the answer. I think this must be clarified to
apply to the one generating an answer and being a JSEP endpoint.

6. Section 5.2.1

   o  An "a=setup" line, as specified in [RFC4145], Section 4, and
      clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
      The role value in the offer MUST be "actpass".

So this is correct if the setup is for the DTLS. But, what is one has
another protocol that uses a=setup? I think you should scope this rule
to anything that uses DTLS.

7. Section 5.2.1:

   o  An "a=ssrc" line, as specified in [RFC5576], Section 4.1,
      indicating the SSRC to be used for sending media, along with the
      mandatory "cname" source attribute, as specified in Section 6.1,
      indicating the CNAME for the source.  The CNAME must be generated
      in accordance with [RFC7022].  [OPEN ISSUE: How are CNAMEs
      specified for MSTs?  Are they randomly generated for each
      MediaStream?  If so, can two MediaStreams be synced?  See:
      https://github.com/rtcweb-wg/jsep/issues/4]

So, to my understanding all MSTs in the same MS MUST have the same
CNAME. All MST from one endpoint will have the same CNAME. But, for
multi-party centralized conferencing the endpoint will receive multiple
different MS. Each MS can have a different CNAME. So an offer or answer
from a MCU can contain multiple CNAMEs.

8. Section 5.2.1:

For simplicity, if both RTX and FEC
      are supported, the FEC SSRC MUST be the same as the RTX SSRC.

I wonder if this will actually work. The issue I see is that one have an
SSRC with only RTX or repair packets, a missing sequence number
indicates that you lost one packet of the type used. If you mix RTX and
FEC then a missing packet can be either. Thus, the right response to
this loss can't be determined. In addition if one have a mechanism that
requires concurrent sequence numbers then it will also not work. I am
also uncertain how this interact with mechanisms for determining when to
flush the FEC source block.

SSRCs aren't particular expensive, so I think you rather have the FEC
and RTX on separate SSRCs.

9. Section 5.2.1:
   Once all m= sections have been generated, a session-level "a=group"
   attribute MUST be added as specified in [RFC5888].  This attribute
   MUST have semantics "BUNDLE", and MUST include the mid identifiers of
   each m= section.  The effect of this is that the browser offers all
   m= sections as one BUNDLE group.  However, whether the m= sections
   are bundle-only or not depends on the BUNDLE policy.

This text is not supporting a policy of fully unbundle.

10. Section 5.2.2:

   o  If any MediaStreamTracks have been removed, either through the
      removeStream method or by removing them from an added MediaStream,
      their m= sections MUST be marked as recvonly by changing the value
      of the [RFC3264] directional attribute to "a=recvonly".

Should "removeStream" be "removeTrack" or should both be mentioned?

11. Section 5.2.2:
   The "a=group:BUNDLE" attribute MUST include the mid identifiers
   specified in the BUNDLE group in the most recent answer, minus any m=
   sections that have been marked as rejected, plus any newly added or
   re-enabled m= sections.  In other words, the BUNDLE attribute must
   contain all m= sections that were previously bundled, as long as they
   are still alive, as well as any new m= sections.

This appears to need to be reformulate to deal with sessions where
bundle has been rejected completely.

12. I am quite unclear how the a=candidate processing is intended to
work. The GenerateOffer can't fill it in as the gathering is defined to
happen when you do setLocal. So, are there empty a=candidates or are
they set by the setLocal.

13. Section 5.6.2:

  o  The "b=" line, if present, MUST be parsed as specified in
      [RFC4566], Section 5.8, and the bwtype and bandwidth values
      stored.

There can be multiple b= lines with different modifiers.

14. Section 6.

Proto needs to be on this list I think. If one are doing munching for
legacy systems.

15. Page 53:

The definition of telephone-event appears to miss a=fmtp attribute.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------