[rtcweb] SDP lines (JSEP Issue 27)

[Adam Roach <[e-mail]>]

Back in Hawaii, I took an action item to look over the various SDP lines 
to analyze their applicability to JSEP [1]. tl;dr: I think what we have 
in the document right now is correct and sufficient, pending the outcome 
of the b= conversation.

----------

I did my own analysis of SDP without having recently re-read the JSEP 
document, with the intention of providing a sanity check. The only thing 
I say below that isn't already covered by 4566 is k= (which is already 
governed by the "no SDES" normative language) and documenting the 
various fields that are of no interest for JSEP use cases (s=, i=, u=, 
e=, p=, z=, and t=).

v=
   MUST set to 0. MUST verify that value is 0 on receipt, treat as 
malformed if not.

o=, c=, m=, a=
   Encoded and used as described in SDP. There is no reason to surface 
the 'o=' username to the application.

s=
   MUST send, MUST verify presence on receipt, treat as malformed if 
not. I see no reason to have API surface to set or read this.

i=, u=, e=, p=, z=, r=
   SHOULD NOT send, MUST ignore. MUST treat as malformed if not in 
correct order.

t=
   MUST include exactly one, of the form "t=0 0". MUST verify that at 
least one t= line is present on receipt (and is syntactically valid), 
but otherwise ignored.

b=
   Ask Magnus.

k=
   MUST NOT send. If present at session level, MUST reject all media 
lines. If present at media level, MUST reject that media line.


In comparing these recommendations with JSEP section 5.2.1, I note that 
they are congruent with the existing language, modulo the ongoing 
conversation around "b=" (which will presumably reach its own 
conclusions). JSEP currently doesn't mention the ordinality of t= lines, 
but this seems pretty harmless.

Section 5.6 in its present form appears to cover the various "malformed" 
cases I describe above.

____
[1] https://github.com/rtcweb-wg/jsep/issues/27#issuecomment-62786027

/a