Subject: [rtcweb] JSEP WGLC: Christer's comments on section 3 - Part I

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Nov 2016 12:54:11 +0000

Hi,

Some initial comments on Section 3. I will comment on the forking stuff in
a separate e-mail.

---

Section 3.2 says:

   "the DTLS-SRTP parameters [RFC5763] sent to a remote party indicate what
   certificate the local side will use in DTLS setup"

1) I am not sure what "parameters" the text is referring to. If it¹s the
fingerprint, I think the text should reference RFC 4572.

2) I think we should simply have a generic statement that, following the
rules in RFC3264, parameters indicate receiving capabilities - unless
explicitly indicated otherwise.

---

Section 3.2 says:

   "JSEP also allows for an answer to be treated as provisional by the
    application.  Provisional answers provide a way for an answerer to
    communicate initial session parameters back to the offerer, in order
    to allow the session to begin, while allowing a final answer to be
    specified later. This concept of a final answer is important to the
    offer/answer model; when such an answer is received, any extra
    resources allocated by the caller can be released, now that the exact
    session configuration is known."

1) I would like explicit text saying that this is a deviation from RFC
3264, where there is no such thing as a provisional answer. I would like
to have a dedicated ³Deviations to RFC3264² (or something similar) section.

2) I would like explicit text saying that the final answer may be
completely different (in terms of candidates, codecs, accepted m- line
etc) from the provisional answer.

3) Related to 2), the final answer may also require NEW resources to be
allocated.

---

Section 3.2 says:

    "To support this, the JSEP media layer
     can provide an offer via the createOffer() method whenever the
     Javascript application needs one for the signaling.  The answerer can
     send back zero or more provisional answers, and finally end the
     offer-answer exchange by sending a final answer.  The state machine
     for this is as follows:"

1) I would like to explicitly note that the generated offer is not applied
(and any previously applied offer is not removed) until
setLocalDescription() is called.

---

Section 3.3 says:

     "In the WebRTC specification, session descriptions are formatted as
      SDP messages."

1) To me it is unclear what an ³SDP message² is, so I suggest we say ³SDP
syntax², as we also do later in the section.

----

Section 3.4 says:

     "In order to give the application control over various common session
      parameters, JSEP provides control surfaces which tell the browser how
      to generate session descriptions.²

1) What is ³control surface²? Are you talking about the interface in
Section 4?

----

Section 3.4.1 talks about ³RtpTranceivers², ³RtpSenders² and
³RtpReceivers².

1) I think they should be introduced in their own section (not within the
Session Description Protocol section).

2) I think it should be explained what an RtpXXX really is. At a minimum
there should be a reference to the appropriate W3C document. But, as there
is text on how they related to SDP m- lines etc, 1 or 2 sentences
describing what they are would also be useful.

---

Section 3.5.2.1 says:

    "The m= line can be identified in one of two ways; either by a m= line
index, or a MID.  The m= line
     index is a zero-based index, with index N referring to the N+1th m=
line in the SDP sent by the entity
     which sent the IceCandidate.  The MID uses the "media stream
identification" attribute, as defined in
     [RFC5888], Section 4, to identify the m= line."

1) Where is the m= line index located?

2) Where is the MID attribute located? Earlier in the section the text
says that the candidate lines are the ONLY
information within the IceCandidiate object.

3) I have some trouble to parse "the SDP sent by the entity which sent the
IceCandidate". What entity?

---

Section 3.5.3 contains requirements regarding what a browser MUST do -
e.g., allowing the application to select what types of ICE candidates are
used.

1) I am not sure why such requirements are listed here. But, in any case,
is there a mechanism for applications for selecting candidate types etc?
If so, what mechanism?

Regards,

Christer

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 Nov 2016 10:43:23 -0700

Thanks for the review, Christer.  I've broken these up into issues #373
through #379 in the github repo, so we can track them there.

regards,

Ted

On Wed, Nov 2, 2016 at 5:54 AM, Christer Holmberg <
[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Nov 2016 18:52:35 +0000

Hi,

Sorry, I forgot you wanted reviewers to create GitHub issues.

Regards,

Christer

Sent from my iPhone

On 2 Nov 2016, at 19.43, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for the review, Christer.  I've broken these up into issues #373 through #379 in the github repo, so we can track them there.

regards,

Ted

On Wed, Nov 2, 2016 at 5:54 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

---

Section 3.2 says:

---

Section 3.2 says:

---

Section 3.2 says:

---

Section 3.3 says:

----

Section 3.4 says:

----

---

Section 3.5.2.1 says:

---

Regards,

Christer

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