Change:
Isn't actpass always offered? Not sure I understand the context here.
My understanding is the JSEP compliant implementations are suppose to always use 'actpass' in offers. But you may interop with something which will only present it's current role in a subsequent offer.
If that's the intent, I think that rationale should be spelled out in the text here.
NAME
LGTM
OK, so this took a bit of research to get clear on. First, let me state what I believe the rules are: JSEP endpoints MUST always send actpass in offers. This is defined in http://rtcweb-URL and never modified in 5.2.2 In initial answers, JSEP endpoints (a) MUST send active or passive. (b) if the other side sent something other than actpass, MUST send the complement (c) if the other side sent actpass, SHOULD send active. http://rtcweb-URL In subsquent answers, JSEP endpoints: (a) MUST send active or passive. (b) MUST send something consistent with the current state http://rtcweb-URL The text we are working on here is the initial answer text, therefore, I think that rule 3(b) does not apply, which, I believe, makes the current text correct.
NAME
The explanation from EKR above looks right to me
Actually, 5763 requires it to always be actpass, so we can remove the non-JSEP section. Ugh, but the revision does not require it: URL
I think we have two options here: Get dtls-sdp modified (the offending text is in) URL URL Make JSEP handle this condition, as above. Does anyone know why we changed the rules in dtls-sdp? NAME ^^?
I would have to check the archives in order to find out why we relaxed the must-use-actpass-in-initial-offer rule. Most likely people didn't see a need for not allowing other values. Having said that, JSEP can always mandate sending "actpass" in initial offers. A JSEP implementation must of course still be prepared to receive something else.
That's probably fine, as long as dtls-sdp ensures that everyone has to handle actpass in offers. I don't want people trying to avoid implementing part of the spec by only supporting passive mode or some such.
If you think there is some text indicating that support of "actpass" is optional, that should be corrected.
OK, after all that discussion, I think we need to keep the text that says only JSEP endpoints are guaranteed to do this, but they wwill always do so, which means, I believe that the current text is right, modulo the repeated "the" which the new commit fixes.
Page 52, bullet starting "An 'a=setup' line": add the words "when allowed" to the end of the bullet.
Text is 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 answer MUST be "active" or "passive"; the "active" role is RECOMMENDED. Fix per adam.

Discussion:
An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. <del> The role value in the answer MUST be "active" or "passive"; the "active" role is RECOMMENDED. </del> <ins> The role value in the answer MUST be "active" or "passive".  When the offer contains the "actpass" value, as will always be the case with JSEP endpoints, the answerer SHOULD use the "active" role. Offers from non-JSEP endpoints MAY send other values for "a=setup", in which case the answer MUST use a value consistent with the value in the offer. </ins> An "a=tls-id" line, as specified in I-D.ietf-mmusic-dtls-sdp Section 5.3.