Subject: [rtcweb] JSEP Section 5.4 and Friends

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 24 Mar 2015 13:48:55 -0500

Few quick initial comments.

Section 3.2 -
[Suhas]
   a. The state machine captures successful scenarios alone. Would it be
worthwhile to capture error states ?

    b. The state themselves are not defined anywhere. The State names
across Section 3.2 and Section 5.4 are not uniform.

Section 5.4 says

   - Next, the SessionDescription is parsed into a data structure, as
   described in the Section 5.6
   <https://tools.ietf.org/id/draft-ietf-rtcweb-jsep-09.html#sec.parsing-a-desc>section
   below. If parsing fails for any reason, processing MUST stop and an error
   MUST be returned.

[Suhas]     Should we add a note to say that the remote offer MUST be
rejected by the JSEP application when the application of Answer fails.

Section 5.6

The "c=" line MUST be parsed and stored.
[Suhas]   Should we say anything out connection address being Unicast vs
Multicast.

For non-attribute (non-"a=") lines, their sequencing, syntax, and
semantics, are checked, as mentioned above. The following lines are not
meaningful in the JSEP context and MAY be discarded once they have been
checked.

   - TODO

[Suhas]. These can be added here u=, e=, p=, r=, z=, k=

[OPEN ISSUE: For example, because session-level bandwidth is ambiguous when
multiple media streams are present, a "b=" line at session level is not
useful and its value SHOULD be ignored. [OPEN ISSUE: is this WG consensus?
Are there other non-a= lines that we need to do more than just syntactical
validation, e.g. v=?]

[Suhas] For b= handling, I agree that having them specified at the media
level makes sense. The draft should however say if any of RFC4566 or
RFC3556 b= attributes are missing at the media level, what needs to be the
expected behavior

Section 5.6.2
The "b=" line, if present, MUST be parsed as specified in [RFC4566]
<https://tools.ietf.org/id/draft-ietf-rtcweb-jsep-09.html#RFC4566>, Section
5.8, and the bwtype and bandwidth values stored.
[Suhas]  We also need to add RFC3556 references here.
Also we need to add ice-options for media section.

Section 5.6.3
[Suhas]    "Semantics verification" is not defined and the intent behind
the text in this section is unclear.

Section 5.9
[Suhas]  Is underspecified (WIP)

Just a crazy thought .. Would it help in defining a registry of SDP
attributes for RTCWeb usage.. This helps today's and future SDP attributes
that gets defined for RTCWeb usage to go to a single place for reference.
Also makes it easier to add new attributes to the registry in the future.

Thanks
Suhas