Subject: [rtcweb] SDP lines (JSEP Issue 27)

From: Adam Roach <[email-masked]>
Date: Mon, 30 Mar 2015 11:09:33 -0500

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 30 Mar 2015 13:18:43 -0600

> On Mar 30, 2015, at 10:09 AM, Adam Roach <[email-masked]> wrote:
> 
> i=, u=, e=, p=, z=, r=
>  SHOULD NOT send, MUST ignore.

I don't think MUST ignore is correct. First to be clear, I'm not saying the browser needs to do anything with the info in theses lines. 

I think MAY ignore or not typically used by a webrtc browser might be a better way to say it. For example, if rtcweb device was taking a streaming video session via webrtc protocols, it might make sense for it to use the i= or u= particularly if the SDP had originally come from an RTSP stream that was gatewayed to WebRTC. Similarly if a browser reported the full SDP it had received in some stats interface, I would expect it not to ignore the lines but actually report what it was it received. 

To be clear, I'm not saying the browser needs to do anything with the info in theses lines - it's fine to ignore them. But that's very different from all webrtc things must ignore them. (and I agree with SHOULD NOT send part)

---

From: Adam Roach <[email-masked]>
Date: Mon, 30 Mar 2015 14:36:04 -0500

> To be clear, I'm not saying the browser needs to do anything with the info in theses lines - it's fine to ignore them. But that's very different from all webrtc things must ignore them. (and I agre…

I think we're in agreement about the principle, but might be at cross 
purposes regarding the venue: I agree that non-browsers may well have 
reasons to use these fields, but I don't think this document has much 
bearing on what those implementations do; at least, not as it currently 
describes itself.

 From the introduction section, JSEP "describes how the W3C WEBRTC 
RTCPeerConnection interface is used to control the setup, management and 
teardown of a multimedia session." So, in the context of *this* 
document, it would *appear* that we're in agreement that the proper 
normative behavior is to ignore the values in these lines. So I can see 
why we might be quibbling about "SHOULD" versus "MUST," but your 
objection seems much broader than that.

If our difference of opinion here arises from differing views about 
intended scope for the JSEP document, then we need to start a broader 
conversation around, minimally, the introduction section of the current 
draft.

/a