described in RFC4566, Section 5.  The SDP is read, line-by-line, and converted to a data structure that contains the deserialized information.  However, SDP allows many types of lines, not all of <del> which are relevant to JSEP applications, and the ones that are not specifically referenced below MAY be ignored.  Implementations MAY also act on such lines, in accordance with the specification that defines them.  For each line, the implementation will first ensure it is syntactically correct according its defining ABNF [TODO: reference], and then either parse the data value to store for later use, or ignore the value and move on.  If the line is not well- formed, or cannot be parsed as described, the parser MUST stop with an error and reject the session description.  This ensures that implementations do not accidentally misinterpret ambiguous SDP. </del>  5.6.1. same type (typically "a=") can occur in any order, and their ordering is not meaningful. <del> For non-attribute (non-"a=") lines, their sequencing and syntax are checked, as mentioned above, but the only line whose value MUST be parsed and stored is the "c=" line.  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=?] </del>  Specific processing MUST be applied for the following session-level attribute ("a=") lines: Any "a=rtcp-fb" attributes MUST be parsed as specified in RFC4585, Section 4.2., and their values stored. <del> Any "a=rtcp-mux" attribute MUST be parsed as specified in RFC5761, Section 5.1.1, and its presence or absence flagged and stored. </del>  TODO: a=rtcp-rsize, a=rtcp, a=msid, a=candidate, a=end-of- candidates bounds, or cannot be applied, processing MUST stop and an error MUST be returned. <del> If the ICE ufrag and password values changed, trigger the ICE Agent to start an ICE restart and begin gathering new candidates, as defined in RFC5245, Section X.Y. If the media section proto value indicates use of RTP: If the RTCP mux parameter is set, discard any RTCP transport, and begin muxing RTCP over the RTP transport, as specified in RFC5761, Section X.Y. [if answer] Set RTP header extension receive state, ensure all are known Set PT demux Set receive codecs, ensure all are known Set up RTX (verify apt) Set local directional state If the media section proto value indicates use of SCTP: Set local SCTP pseudo-port </del>  Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section

NAME NAME PTAL and let me know if you think this is on the right track. If so, I will flesh out in whatever time I have on Sunday.
This seems like it's on the right track. My biggest concern is whether we really want to require people to ignore values which we also prescribe values for. For instance, you say that the impl should discard the c= line, but S 5.2.1 is very prescriptive about the c= line contents. I recognize that valid (non-JSEP) implementations might produce other values for the c= line but I wonder if we really want to ignore them.
What would one do with the c= line? We make our c= lines in a certain way for the benefit of dumb remote endpoints. JSEP endpoints aren't so encumbered.
I guess you would validate that it properly reflected one of the candidates (if any) in the m= section. I'm torn here, because it seems like if we totally ignore these values we contribute to them just getting more and more bogus. But on the other hand, validating them for consistency also seems like a problem.
With that said, Firefox seems to basically ignore these values.
It wouldn't be hard to verify c=; we would have to store the value, and then deal with it during the "Verifying Consistency" section. However this could be a slippery slope; should we validate that t= values are not garbage, etc?
"It wouldn't be hard to verify c=; we would have to store the value, and then deal with it during the "Verifying Consistency" section. However this could be a slippery slope; should we validate that t= values are not garbage, etc?" Fair enough. OTOH there's a hygiene argument about rejecting bogus stuff early so it doesn't get into the ecosystem is not contaminated. Maybe we should say that these lines can be checked for consistency? I don't feel strongly about this.
I am strongly on the side of "be strict in what you accept, or else people will turn your ecosystem into a cesspool", but I have a hard time getting excited about extensively validating stuff that is going to be ignored anyway. Saying that the application MAY do additional consistency checks seems like a reasonable balance; I'll see if I can craft some text around that.
I am currently working on an edit that tries to address the points raised here, look for it in ~30 min.
OK, I took another shot at this. Now, I sort lines into things that JSEP specifically cares about and MUST be acted on, and things that JSEP doesn't say anything about, and implementations MAY act on them or ignore them.
I finished fleshing out the SDP parsing stuff. It definitely could be tightened up with another editorial pass, but I think it mostly defines what needs to happen at the parse stage, and is worth keeping; we can polish it later. The apply-local-description stuff is still quite primitive and we might want to pull it for this rev.
I will be in the office by 8:30 PT tomorrow - ping me and we can figure out how to land this from the current state.
working my way thought the latest ...
Based on the comments right now, I am planning on making the following changes: Specifically mention SDP general rules and specific ABNF in "syntactically correct" section mark session-level b= as open issue clean up "if valid" text clarify a couple places as to whether multiple values are OK (e.g. rtcp-mux) LMK if you disagree or have additional things you want to see.
I suggest that you also put in some sort of general "This is a draft" disclaimer. Other than that, I'm fine with proceeding as you propose. I'll be around for another 30-60 minutes and then out for lunch. Back around 2-2:30ish.
I'm around next two hours then in meeting till late. To me the most important thing is to make this clear we are not picking a few parts of SDP to implement but instead we are doing SDP. So I am nok OK with things like "ignore everything but what is mentioned here". I am OK with the way we use SDP here means that X,Y, are never used. I view what I am saying here matches WG consensus
This doesn't seem philosophically unreasonable, but at this point I suggest we focus on what's actionable. Are there specific things that are still in this PR that you object to? If so, let's call them out and fix them and merge it. In this spirit, you and Justin have my proxy to merge any variant of this PR that you mutually agree upon. I'm happy to review to the extent I am around, but don't not submit b/c of me.
As a check list of things I think we need to mention ... somewhere in this text I think we need to say browser need to support RFC2833 RFC3264 RFC4566 ietf-mmusic-msid ietf-mmusic-sdp-bundle-negotiation RFC5761 RFC3605 ietf-payload-rtp-opus RFC3551 RFC4145 RFC5245 RFC5576 RFC5506 RFC6465 RFC6464 ietf-mmusic-trickle-ice ietf-mmusic-sctp-sdp ietf-rtcweb-data-channel ietf-payload-vp8 ietf-mmusic-sdp-simulcast RFC7022 I've missed a few there (like 264) but I think that is bunch of them
I expect to talk about each of these in detail in the parse/apply sections, but the laundry list already exists in URL
Cullen, regarding "I am nok OK with things like "ignore everything but what is mentioned here". I am OK with the way we use SDP here means that X,Y, are never used": The current text says that this spec defines how JSEP deals with the specific lines X,Y,Z, but implementations MAY process other lines in accordance with their definitions. Does that work for you? Cullen - answering in this comment to see how that works ... The part I am having the problem is is saying "you can ignore anything not mentioned here". I'm not agaoins pointing out specific lines which the SDP spec says are useless in WebRTC context, I just don't want to be redefining SDP here.
OK. Working on editing this all now - expect an update circa 3:00 PM PT
New version of this PR has been pushed that addresses (I believe) all points discussed today.
reading
Overall I think this has uncovered a bunch of stuff that I think we need to discuss in Dallas, so I'd like to find a way to land this, with whatever disclaimers are appropriate. I plan to remove the apply-local stuff before submitting, will work on removing it now.
apply-local stuff gutted
talking to EKR and trying to resolve something
Justin, Cullen and I talked and his principal concern is defaulting to ignoring stuff not listed. I think the way to fix this is to just list all (15 or so) non a= lines and their disposition. i didn't have time here, but PR puts in the framework and then we should be able to resolve these quickly, leaving the controversial ones for IETF. wdyt? See

described in RFC4566, Section 5.  The SDP is read, line-by-line, and converted to a data structure that contains the deserialized information.  However, SDP allows many types of lines, not all of  <ins> which are relevant to JSEP applications.  For each line, the implementation will first ensure it is syntactically correct according its defining ABNF [TODO: reference], check that it conforms to RFC4566 and RFC3264 semantics, and then either parse and store or discard the provided value, as described below.  [TODO: ensure that every line is listed below.]  If the line is not well-formed, or cannot be parsed as described, the parser MUST stop with an error and reject the session description.  This ensures that implementations do not accidentally misinterpret ambiguous SDP. </ins> 5.6.1. same type (typically "a=") can occur in any order, and their ordering is not meaningful.  <ins> 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 The remaining lines are processed as follows: The "c=" line MUST be parsed and stored. [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=?] </ins> Specific processing MUST be applied for the following session-level attribute ("a=") lines: Any "a=rtcp-fb" attributes MUST be parsed as specified in RFC4585, Section 4.2., and their values stored.  <ins> If present, a single "a=rtcp-mux" line MUST be parsed as specified in RFC5761, Section 5.1.1, and its presence or absence flagged and stored. </ins> TODO: a=rtcp-rsize, a=rtcp, a=msid, a=candidate, a=end-of- candidates bounds, or cannot be applied, processing MUST stop and an error MUST be returned.  <ins> TODO </ins> Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section


The application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- <del> bundle-negotiation.  By specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together.  The set of available policies is as follows: The application will BUNDLE all media streams of the same type together.  That is, if there are multiple audio and multiple video MediaStreamTracks attached to a PeerConnection, all but the first audio and video tracks will be marked as bundle-only, and candidates will only be gathered for N media streams, where N is the number of distinct media types.  When talking to a non-BUNDLE- aware endpoint, only the non-bundle-only streams will be negotiated.  This policy balances desire to multiplex with the need to ensure basic audio and video still works in legacy cases. Data channels will be in a separate bundle group. The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. The application will BUNDLE all of its media streams, including data channels, on a single transport.  All streams other than the first will be marked as bundle-only.  This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. </del>  As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST

LGTM
Holding my review until Martin's comments are addressed
lgtm with comments above
seems clear that there is one: Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in [RFC5888]. This attribute MUST have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. The effect of this is that the browser offers all m= sections as one BUNDLE group. However, whether the m= sections are bundle-only or not depends on the BUNDLE policy. seems clear that "balanced" means >1 The application will BUNDLE all media streams of the same type together. That is, if there are multiple audio and multiple video MediaStreamTracks attached to a PeerConnection, all but the first audio and video tracks will be marked as bundle-only, and candidates will only be gathered for N media streams, where N is the number of distinct media types. When talking to a non-BUNDLE-aware endpoint, only the non-bundle-only streams will be negotiated. This policy balances desire to multiplex with the need to ensure basic audio and video still works in legacy cases. Data channels will be in a separate bundle group. Justin and EKR believe the number should always be 1. Need to fix the text to make this clear.
Right, seems like we need to change 4.1.1 to say the application will try to BUNDLE all media streams, but can fall back to the unbundled case where audio, video, and data are on separate transports. We should also have a sentence somewhere that indicates that only a single bundle group is ever offered.
Control of # of bundle groups is left as something for the future; we would need an additional policy, or some other thing to frob, perhaps on rtpsender.
First I think browsers need to be able to correctly respond to more than one bundle (which may mean rejecting the bundle), but I want to leave it open that an browser impelmetion is allowed to create more than one bundle. If you read the mux atributes draft you will see there are many cases where the browser might choose to create more than one bundle.
Which section?
Well if you ever want to do any of things that are not allowed to be in the same bundle, you end up wanting two bundles.

The application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp-  <ins> bundle-negotiation.  Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will offer a single BUNDLE group across all media sections.  However, by specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non-BUNDLE-aware endpoint. When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: The first media section of each type (audio, video, or application) will contain transport parameters, which will allow an answerer to unbundle that section.  The second and any subsequent media section of each type will be marked bundle-only. The result is that if there are N distinct media types, then candidates will be gathered for for N media streams.  This policy balances desire to multiplex with the need to ensure basic audio and video can still be negotiated in legacy cases. All media sections will contain transport parameters; none will be marked as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. Only the first media section will contain transport parameters; all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST


3.1. JSEP does not specify a particular signaling model or state machine, <del> other than the generic need to exchange SDP media descriptions in the </del>  fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to Changes MUST NOT be silently ignored. <del> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del>  The number, type and port number of m= lines.

LGTM!
JSEP on two occasions says "SDP media description" where it seems "SDP session description" or similar would be more appropriate. "media description" seem to reference m-lines rather than the full SDP in other documents (4566, 3264).
agree - see if that pull request fixes it
to my understanding it does fix it!

3.1. JSEP does not specify a particular signaling model or state machine,  <ins> other than the generic need to exchange session descriptions in the </ins> fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to Changes MUST NOT be silently ignored.  <ins> The following elements of the session description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines.


the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a <del> response to a "offer", or an update to a previously sent "pranswer". </del>  The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that 4.1.5. The setLocalDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as its local configuration.  The type field indicates whether the blob should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </del>  This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to 4.1.6. The setRemoteDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as the desired remote configuration.  As in setLocalDescription, the type field of the indicates how the blob should be processed. </del>  This API changes the local media state; among other things, it sets up local resources for sending and encoding media.

lgtm
need to be to "an" like in line 854?? URL
Fixed by
The word Blob is missing? URL

the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a  <ins> response to an "offer", or an update to a previously sent "pranswer". </ins> The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that 4.1.5. The setLocalDescription method instructs the PeerConnection to apply  <ins> the supplied session description as its local configuration.  The type field indicates whether the description should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </ins> This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to 4.1.6. The setRemoteDescription method instructs the PeerConnection to apply  <ins> the supplied session description as the desired remote configuration. As in setLocalDescription, the type field of the description indicates how it should be processed. </ins> This API changes the local media state; among other things, it sets up local resources for sending and encoding media.


offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. <del> The browser will only gather RTP candidates.  [[OPEN ISSUE: how should the answerer behave.  https://github.com/rtcweb-wg/jsep/ issues/114]] This halves the number of candidates that the offerer needs to gather. </del>  4.1.2.

...14
LGTM
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed

offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints.  <ins> The browser will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather.  When acting as answerer, the browser will reject any m= section that does not provide an "a=rtcp-mux" attribute. </ins> 4.1.2.


3.1. JSEP does not specify a particular signaling model or state machine, <del> other than the generic need to exchange SDP media descriptions in the </del>  fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to 3.5.  Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device.  For example, SIP RFC3261 defines both a "Parallel Search" and "Sequential Search". Start exchanging media with a given remote peer, and free any resources in the offer that are not being used. <del> 3.5.1. </del>  Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one with a timer; at this point, the application could reapply the existing remote description as a final answer. <del> 3.5.2. </del>  Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a <del> response to a "offer", or an update to a previously sent "pranswer". </del>  The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that 4.1.5. The setLocalDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as its local configuration.  The type field indicates whether the blob should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </del>  This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to 4.1.6. The setRemoteDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as the desired remote configuration.  As in setLocalDescription, the type field of the indicates how the blob should be processed. </del>  This API changes the local media state; among other things, it sets up local resources for sending and encoding media. the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in <del> accordance with RFC7022.  [OPEN ISSUE: How are CNAMEs specified for MSTs?  Are they randomly generated for each MediaStream?  If so, can two MediaStreams be synced?  See: https://github.com/ rtcweb-wg/jsep/issues/4] </del>  If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be <del> used for sending media. </del>  If a local MediaStreamTrack has been associated, and RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX Changes MUST NOT be silently ignored. <del> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del>  The number, type and port number of m= lines.

This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.

3.1. JSEP does not specify a particular signaling model or state machine,  <ins> other than the generic need to exchange session descriptions in the </ins> fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to 3.5. <ins> RTP CNAME values provide a canonical name for the RTP endpoint, allowing other RTP endpoints to determine which RTP streams are using the same clock and thus which clock sources can be used that to synchronize media playout. Any MediaStreamTracks which have different clock sources MUST have different CNAMEs [TODO: need a reference for this.]  Any MediaStreamTracks which are in different PeerConnection objects MUST have different CNAMEs; this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME.  For simplicity, MediaStreamTracks in the same PeerConnection which have the same clock source SHOULD have the same CNAME. 3.6. </ins> Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device.  For example, SIP RFC3261 defines both a "Parallel Search" and "Sequential Search". Start exchanging media with a given remote peer, and free any resources in the offer that are not being used.  <ins> 3.6.1. </ins> Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one with a timer; at this point, the application could reapply the existing remote description as a final answer.  <ins> 3.6.2. </ins> Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a  <ins> response to an "offer", or an update to a previously sent "pranswer". </ins> The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that 4.1.5. The setLocalDescription method instructs the PeerConnection to apply  <ins> the supplied session description as its local configuration.  The type field indicates whether the description should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </ins> This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to 4.1.6. The setRemoteDescription method instructs the PeerConnection to apply  <ins> the supplied session description as the desired remote configuration. As in setLocalDescription, the type field of the description indicates how it should be processed. </ins> This API changes the local media state; among other things, it sets up local resources for sending and encoding media. the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in  <ins> accordance with RFC7022 and sec.cname. </ins> If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be  <ins> used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in accordance with RFC7022 and sec.cname. </ins> If a local MediaStreamTrack has been associated, and RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX Changes MUST NOT be silently ignored.  <ins> The following elements of the session description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines.


not meaningful in the JSEP context and MAY be discarded once they have been checked.  TODO The remaining lines are processed as follows: <del> The "c=" line MUST be parsed and stored. </del> [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. Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: <del> The "c=" line, if present, MUST be parsed as specified in RFC4566, Section 5.7, and its contents stored. </del>  The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored.

NAME is this OK? NAME
lgtm with the one comment above
Ignored is the wrong word to use here. The value is not used is true but ignored is just simply not true.
Hmm.... We're not checking it and not doing anything with it. I'm happy to use another word, but I'm going to need you to suggest one. , Cullen Jennings EMAIL wrote:
NAME please r+ if you are happy. NAME please merge if you are happy.
I really don't care but it like 1 of the 3 things I raised got fixed
I see I missed the trickle thing. What else is there? , Cullen Jennings EMAIL wrote:
Around line 2216 I had another change "SHOULD be ignored" to "is not used". I think we are running into the limitations of using github for review here.
Indeed, I think I missed it. , Cullen Jennings EMAIL wrote:
NAME I think this is ready to merge if you are still happy.
LGTM
lgtm with minor change
When JSEP recommends that lines are ignored (absent some syntax validation), it violates a rule in RFC 5245 regarding mismatch processing. 5245 requires that the values for port and IP address in and correspond to a candidate that appears in the media section. Consensus in Dallas was to prohibit checking of the value in against and , which requires an explicit mention in the draft, since this is different to what 5245 says.
The sole point of mismatch processing is to allow applications to see if some SBC messed with their addresses: If the agent is not proceeding with ICE because there were a=candidate attributes, but none that matched the default destination of the media stream, the agent MUST include an a=ice- mismatch attribute in its answer. Not proceeding with ICE isn't an option here, and this is somewhat problematic with trickle ice (at least the initial 0.0.0.0 candidate), so I think ignoring makes sense.

not meaningful in the JSEP context and MAY be discarded once they have been checked. <ins> The "c=" line MUST be checked for syntax but its value is not used.  This supersedes the guidance in RFC5245, Section 6.1, to use "ice-mismatch" to indicate mismatches between "c=" and the candidate lines; because JSEP always uses ICE, "ice-mismatch" is not useful in this context. </ins> TODO The remaining lines are processed as follows:  [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. Following the "m=" line, specific processing MUST be applied for the following non-attribute lines:  <ins> As with the "c=" line at the session level, the "c=" line MUST be parsed according to RFC4566, Section 5.7, but its value is not used. </ins> The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored.


In order to determine the limits on what video resolution a receiver wants to receive, it will intersect its decoder hard limits with any mandatory constraints that have been applied to the associated <del> MediaStreamTrack.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing createAnswer call.  For the offerer, since it does not know about any remote MediaStreamTracks until it receives theanswer, this implies that it can only set these constraints after the initial offer-answer exchange is complete, and as a result, a new offer-answer is needed to communicate them. The resulting resolution space formed by intersecting the decoder hard limits with any mandatory constraints will be used as the x= and y= values for the generated "a=imageattr" attribute for the associated MediaStreamTrack.  With only one set of preferences expressed, the q= value is not important; it SHOULD be set to 1.0. If the intersection is the null set, i.e., there are no resolutions that are permitted by both the decoder and the mandatory constraints, this SHOULD be represented using x=0 and y=0 values. </del>  The "a=imageattr" field is payload type specific.  When all video codecs supported have the same capabilities, use of a single attribute, with the wildcard payload type (*), is RECOMMENDED. However, when the supported video codecs have differing capabilities, <del> a specific "a=imageattr" attribute is inserted for each payload type. </del>  As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to

Still needs updates to createOffer/Answer.
Travis still seems sad.
Since I won't be on the call, I give this my preemptive LGTM, provided you at least look at my comments (and maybe reject them) and fix the build
Eric, did you want to take another look at this?
There one sentence I think we need to deal with (see other comment) but rest of this LGTM
It still seems like my proposed change of replacing "the initial offer-answer exchange is complete, and as a result, a new offer-answer is needed to communicate them" with "receiving the initial answer or pr-answer. " would make this more or less right for both cases and as the API developers, or does not develop, for this then we can fill in more details
Well, as far as I can tell, you can't do it after the pr-answer, since you can't do an offer at that stage.
NAME PTAL at PR . I think with this change we are ready to go. If that makes you happy, merge in PR into here and then merge this PR.
With EKR's this LGTM
OK, I will push the buttons now.
OK, I worked this over a bit to incorporate PR and also handle the case where the decoder hard limits are not known. The changes are minor but I will hold off for the next few hours to get a sanity check from one of you.
LGTM
I will read it and get back to you I 30 minutes
LGTM
Fixed merge conflict and merged.

In order to determine the limits on what video resolution a receiver wants to receive, it will intersect its decoder hard limits with any mandatory constraints that have been applied to the associated  <ins> MediaStreamTrack.  If the decoder limits are unknown, e.g. when using a software decoder, the mandatory constraints are used directly.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing createAnswer call. Any constraints set after setLocalDescription is used to set the answer will result in a new offer-answer exchange.  For the offerer, because it does not know about any remote MediaStreamTracks until it receives the answer, the offer can only reflect decoder hard limits. If the offerer wishes to set mandatory constraints on video resolution, it must do so after receiving the answer, and the result will be a new offer-answer to communicate them. If there are no known decoder limits or mandatory constraints, the "a=imageattr" attribute SHOULD be omitted. Otherwise, an "a=imageattr" attribute is created with "recv" direction, and the resulting resolution space formed by intersecting the decoder limits and constraints is used to specify its minimum and maximum x= and y= values.  If the intersection is the null set, i.e., there are no resolutions that are permitted by both the decoder and the mandatory constraints, this SHOULD be represented by x=0 and y=0 values. The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important.  It SHOULD be set to 1.0. </ins> The "a=imageattr" field is payload type specific.  When all video codecs supported have the same capabilities, use of a single attribute, with the wildcard payload type (*), is RECOMMENDED. However, when the supported video codecs have differing capabilities,  <ins> specific "a=imageattr" attributes MUST be inserted for each payload type. </ins> As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to


MediaStreamTrack.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing <del> createAnswer call.  For the offerer, since it does not know about any remote MediaStreamTracks until it receives theanswer, this implies that it can only set these constraints after the initial offer-answer exchange is complete, and as a result, a new offer-answer is needed to communicate them. </del>  The resulting resolution space formed by intersecting the decoder hard limits with any mandatory constraints will be used as the x= and

LGTM - I think that makes it clear what can and can not work.
lgtm

MediaStreamTrack.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing  <ins> createAnswer call.  Any constraints set after setLocalDescription is used to set the answer will result in a new offer-answer exchange. For the offerer, because it does not know about any remote MediaStreamTracks until it receives the answer, the offer can only reflect decoder hard limits.  If the offerer wishes to set mandatory constraints on video resolution, it must do so after receiving the answer and the result will be a new offer-answer to communicate them. </ins> The resulting resolution space formed by intersecting the decoder hard limits with any mandatory constraints will be used as the x= and


maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6. <del> If this m= section is for video media, an "a=imageattr" line, as specified in sec.imageattr. </del>  For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate

LGTM
G. Section 5.2.1: This section contains the following: Each m= section MUST include the following attribute lines: o If this m= section is for video media, an "a=imageattr" line, as specified in Section 3.6. But, Section 3.6 does not mandate that a=imageattr always is included. Thus the text must be modified to allow the selective inclusion of the attribute based on what needs to be said.
Agreed; although 3.6 allows it to be omitted, we should update the text in 5.2.1 to avoid confusion.

maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6.  <ins> If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate


3.5. <del> RTP CNAME values provide a canonical name for the RTP endpoint, allowing other RTP endpoints to determine which RTP streams are using the same clock and thus which clock sources can be used that to synchronize media playout. Any MediaStreamTracks which have different clock sources MUST have different CNAMEs [TODO: need a reference for this.]  Any MediaStreamTracks which are in different PeerConnection objects MUST have different CNAMEs; this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME.  For simplicity, MediaStreamTracks in the same PeerConnection which have the same clock source SHOULD have the same CNAME. 3.6. </del> Video size negotiation is the process through which a receiver can use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard constrain what it receives due to application preferences, e.g. a specific size for the window in which the video will be displayed. <del> 3.6.1. </del>  In order to determine the limits on what video resolution a receiver wants to receive, it will intersect its decoder hard limits with any a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] <del> 3.6.2. </del>  RFC6236 defines "a=imageattr" to be an advisory field.  This means that it does not absolutely constrain the video formats that the In the special case of receiving a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the track. <del> 3.7. </del>  Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device.  For example, SIP Start exchanging media with a given remote peer, and free any resources in the offer that are not being used. <del> 3.7.1. </del>  Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one with a timer; at this point, the application could reapply the existing remote description as a final answer. <del> 3.7.2. </del>  Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple An "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating <del> the CNAME for the source.  The CNAME must be generated in accordance with RFC7022 and sec.cname. </del>  If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for <del> the source.  The CNAME must be generated in accordance with RFC7022 and sec.cname. </del>  If a local MediaStreamTrack has been associated, and RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX

fixes URL fixes URL
The CNAME section said nothing by the time I had removed the stuff that was wrong so I just removed the section and updated the relevant references to point at rtp-usage
lgtm
LGTM
H. Section 5.2.1: o An "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source. The CNAME must be generated in accordance with [RFC7022] and Section 3.5. I think this document shouldn't make normative statement to how CNAMEs shall be generated. That last sentence points to RFC7022, but that is not the whole story. If you like to point to how CNAMEs are to be generated then say that Section 4.9 of RTP-usage is the place to determine that.
Agree that JSEP should point at the relevant sections in rtp-usage, and any redundant text in JSEP should be removed.
A. Section 3.5: RTP CNAME Semantics RTP CNAME values provide a canonical name for the RTP endpoint, allowing other RTP endpoints to determine which RTP streams are using the same clock and thus which clock sources can be used that to synchronize media playout. Any MediaStreamTracks which have different clock sources MUST have different CNAMEs [TODO: need a reference for this.] Any MediaStreamTracks which are in different PeerConnection objects MUST have different CNAMEs; this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME. For simplicity, MediaStreamTracks in the same PeerConnection which have the same clock source SHOULD have the same CNAME. The main problem is that this is out-of-synch (Pardon the pun) with what RTP-usage specifies. See Section 4.9: I think the relevant is the following: Taking the discussion in Section 11 into account, a WebRTC Endpoint MUST NOT use more than one RTCP CNAME in the RTP sessions belonging to single RTCPeerConnection (that is, an RTCPeerConnection forms a synchronisation context). RTP middleboxes MAY generate RTP packet streams associated with more than one RTCP CNAME, to allow them to avoid having to resynchronize media from multiple different endpoints part of a multi-party RTP session. So lets look at the normative statements in JSEP: "Any MediaStreamTracks which have different clock sources MUST have different CNAMEs [TODO: need a reference for this.]" This is not allowed by an WebRTC endpoint, which must use only a single CNAME. Although a RTP middlebox can forward multiple CNAMEs, the WebRTC endpoint is instead required to perform re-synchronization into the used clock based of the other streams. "Any MediaStreamTracks which are in different PeerConnection objects MUST have different CNAMEs; this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME." This one is correct, but I don't quite understand the "this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME." part. First of all what is a "call". Secondly, what type of linking are you considering here? "For simplicity, MediaStreamTracks in the same PeerConnection which have the same clock source SHOULD have the same CNAME." The SHOULD needs to be a MUST. Main conclusion, point more to section 4.9 of RTP-usage.
So lets separate out a few things here. There is what a webrtc browser generates, and there is what it needs to be able to receive. I think we are mostly talking about what it needs to generate here. I'm wondering if perhaps we have to clarify a bit of that. I'm not sure I agree with RTP Usage on one PC MUST use just one CNAME. What do you do if you have video from two camera with different clock sources in a single PC? I think the case people were thinking about was where the camera each had their own clock source and they drifted independent of each other. Not sure if I think this case is relevant or not but I suspect that is where it was coming from. We need to sort this out and get the two specs in sync. On the linking ... this was a privacy concern. If I call both facebook (not anonymous) and also FBI tip line in an anonymous way, can Facebook and FBI collude to link the two together and realize that the person who called FBI was same person that called Facebook. That was all that was meant by linking. Agree we need to phrase this in some clearer way.
Agree with OP; related to ; I think we should point to 4.9 from our section on CNAMEs, remove redundant text from JSEP, and possibly, remove our section altogether (if no longer useful).
NAME "What do you do if you have video from two camera with different clock sources in a single PC? " We had discussion about this. I am fairly certain that I was a proponent for supporting multiple CNAMEs, but we got push-back. What RTP-usage defines means that the implementation will have to synchronize that second time domain with its local and manage offsets and clock drift. Regarding the linking, there is text in RTP usage about that security issue and there are requirements on CNAME generation to handle that in RTP-usage. I think NAME proposal is the right one here.
OK - we will move the draft to that
Have a look at URL

3.5.  Video size negotiation is the process through which a receiver can use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard constrain what it receives due to application preferences, e.g. a specific size for the window in which the video will be displayed.  <ins> 3.5.1. </ins> In order to determine the limits on what video resolution a receiver wants to receive, it will intersect its decoder hard limits with any a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0]  <ins> 3.5.2. </ins> RFC6236 defines "a=imageattr" to be an advisory field.  This means that it does not absolutely constrain the video formats that the In the special case of receiving a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the track.  <ins> 3.6. </ins> Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device.  For example, SIP Start exchanging media with a given remote peer, and free any resources in the offer that are not being used.  <ins> 3.6.1. </ins> Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one with a timer; at this point, the application could reapply the existing remote description as a final answer.  <ins> 3.6.2. </ins> Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple An "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating  <ins> the CNAME for the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf-rtcweb-rtp-usage. </ins> If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for  <ins> the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf-rtcweb-rtp-usage. </ins> If a local MediaStreamTrack has been associated, and RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX


"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no <del> effect; support for DTLS-SRTP is determined by the presence of the "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. </del>  The use of AVPF or AVP simply controls the timing rules used for RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. <del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature. </del>  An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4. <del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature. </del>  An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

LGTM
lgtm
In URL 'certificates' is a set, and the PeerConnection selects which certificate to use. The SDP should have one 'a=fingerprint' line per certificate, and that is not reflected in the JSEP draft AFAICU.
Prague: One a=fingerprint line per cert, but we can go down to a single cert one DTLS has been established. The DTLS cert has to match one of the supplied a=fingerprints. (NAME correct as necessary)
PR added for allowing multiples. Processing rules go in the TBD applying section

"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no  <ins> effect; support for DTLS-SRTP is determined by the presence of one or more "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. </ins> The use of AVPF or AVP simply controls the timing rules used for RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4.  <ins> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4.  <ins> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.


and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" <del> value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </del>  Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an <del> "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in I-D.ietf-rtcweb-data-protocol. [OPEN ISSUE: the -01 of this document is missing this information.] </del>  Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to <del> "application" and the <proto> field MUST be set to exactly match the field in the offer; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </del>  Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an <del> "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in I-D.ietf-rtcweb-data-protocol. [OPEN ISSUE: the -01 of this document is missing this information.] </del>  If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as

Did not carefully review but looks fine to me
lgtm
Section 5.2.1 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. [OPEN ISSUE: the -01 of this document is missing this information.]
According to -07, a=sctpmap is no more, and replaced with a=fmtp, plus a=sctp-port. We still need to reference the appropriate string for the m= line.

and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt"  <ins> value MUST be set to "webrtc-datachannel" as specified in I-D.ietf- mmusic-sctp-sdp, Section 4.1. </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an  <ins> "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp- sdp, Section 4.1. </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to  <ins> "application" and the <proto> and "fmt" fields MUST be set to exactly match the fields in the offer. </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an  <ins> "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp- sdp, Section 4.1. </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as


in the attribute, and transmit it untouched if so.  If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to <del> satisfy the criteria.  In rare cases, where a receiver requires a minimum resolution which is greater than the native resolution of the video, the sender SHOULD apply upscaling in order to provide that resolution.  The sender SHOULD NOT apply upscaling in any other cases. If there is no appropriate scaling mechanism that allows the received criteria to be satisfied, the sender MUST NOT transmit the track. </del>  In the special case of receiving a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the track.

LGTM with the change indicated above.
I rearranged the text a bit to make the policy concept more clear. PTAL.
LGTM
LGTM
For example, some decoders may have min limits, expressed in imageattr. By default, upscaling can be used for this, but there should be some control to turn this off (e.g. don't want to send "HD" video that is just upscaled to HD)
Thoughts on if default should be upscale is allowed or not allowed ?
Generally it seems like a bad practice so I would default to not.

in the attribute, and transmit it untouched if so.  If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to  <ins> satisfy the criteria. If the receiver requires a minimum resolution which is greater than the native resolution of the video, upscaling is needed, but this may not be appropriate in all cases.  To address this concern, the application can set an upscaling policy for each sent track.  For this case, if upscaling is permitted by policy, the sender SHOULD apply upscaling in order to provide the desired resolution. Otherwise, the sender MUST NOT apply upscaling.  The sender SHOULD NOT upscale in other cases, even if the policy permits it. If there is no appropriate and permitted scaling mechanism that allows the received criteria to be satisfied, the sender MUST NOT transmit the track. </ins> In the special case of receiving a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the track.


These values MAY either be present at the media level, or inherited from the session level. <del> ICE ufrag and password values </del>  <del> DTLS fingerprint and setup values </del>  If this session description is of type "pranswer" or "answer", the following additional checks are applied: The session description must follow the rules defined in RFC3264, <del> Section 6. </del>  <del> For each m= section, the protocol value MUST exactly match the protocol value in the corresponding m= section in the associated offer. </del>  5.7. bounds, or cannot be applied, processing MUST stop and an error MUST be returned. <del> TODO </del>  Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section 5.8. <del> TODO </del>  5.9. <del> TODO </del>  6.

Still have a bunch of stuff to flesh out, but wanted to get this out for initial review. NAME NAME
Looks like good stuff to me. - The text in start of section 5 seem fine for making it clear that this does not override the referenced specs.
Thanks for the comments. Ran out of time to resolve them today but will take another shot at it Saturday.
Updated based on comments. I'd like to go ahead and merge this ASAP, and then hopefully still get another rev in before the deadline.
I'm fine with merging what we have here right now.
The text relies on the phrase "most recent gathering phase" to describe which candidates are present in SDP. Justin enumerated a few cases where the browser gathers a completely new set of candidates for an m= section (or component thereof): when a new m= section is added (which happens for a new RTCPeerConnection obviously) when an m= section did have a port of 0, but is repurposed for new media (basically the same scenario as above) ICE restart This needs a clearer definition, or maybe just a single clear description of what it means to do this. This can probably tie into the whole process of describing when candidate events fire and the interaction between that and setLocalDescription.
Martin, could you give us a PR that would satisfy you

These values MAY either be present at the media level, or inherited from the session level.  <ins> ICE ufrag and password values, which MUST comply with the size limits specified in RFC5245, Section 15.4. </ins>  <ins> DTLS setup value, which MUST be set according to the rules specified in RFC5763, Section 5, and MUST be consistent with the selected role of the current DTLS connection, if one exists.[TODO: may need revision, i.e., use of actpass DTLS fingerprint values, where at least one fingerprint MUST be present. Each m= section is also checked to ensure prohibited features are not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied: The session description must follow the rules defined in RFC3264,  <ins> Section 6, including the requirement that the number of m= sections MUST exactly match the number of m= sections in the associated offer. </ins>  <ins> For each m= section, the media type and protocol values MUST exactly match the media type and protocol values in the corresponding m= section in the associated offer. </ins> 5.7. bounds, or cannot be applied, processing MUST stop and an error MUST be returned.  <ins> If this media section is new, begin gathering candidates for it, as defined in RFC5245, Section 4.1.1, unless it has been marked as bundle-only. Or, if the ICE ufrag and password values have changed, trigger the ICE Agent to start an ICE restart and begin gathering new candidates for the media section, as defined in RFC5245, Section 9.1.1.1, unless it has been marked as bundle-only. If the media section proto value indicates use of RTP: If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.1. If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. For each specified RTP header extension, establish a mapping between the extension ID and URI.  If any indicated RTP header extension is unknown, this MUST result in an error.  [TODO: ref] If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension.  [TODO: ref] For each specified payload type, establish a mapping between the payload type ID and the actual media format.  [TODO: ref] If any indicated payload type is unknown, this MUST result in an error. For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type.  [TODO: ref] If any referenced primary payload types are not present, this MUST result in an error. If the directional attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media. </ins> Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section 5.8.  <ins> The following steps are performed at the media engine level to apply a remote description. For each media section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. If the description is of type "offer", and the ICE ufrag or password changed from the previous remote description, [TODO: ref], mark that an ICE restart is needed. Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their connectivity checks. Pair any supplied ICE candidates with any gathered local candidates, as described in [TODO: ref] and start connectivity checks with the appropriate credentials. If the media section proto value indicates use of RTP: [TODO: header extensions] For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format.  [TODO: ref] If any indicated payload type is unknown, it MUST be ignored.  [TODO: should fail on answers] For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type.  [TODO: ref] If any referenced primary payload types are not present, this MUST result in an error. For each specified fmtp parameter that is supported by the local implementation, enable them on the associated payload types. For each specified RTCP feedback mechanism that is supported by the local implementation, enable them on the associated payload types. For any specified "TIAS" bandwidth value, set this value as the maximum RTP bitrate to be used when sending media.  If a "TIAS" value is not present, but an "AS" value is, generate a TIAS a value using this formula: [TODO: convert AS to TIAS]. [TODO: handling of CN, telephone-event, "red"] If the media section if of type audio: For any specified "ptime" value, configure the available payload types to use the specified packet size.  If the specified size is not supported for a payload type, use the next closest value instead. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section below. </ins> 5.9.  <ins> In addition to the steps mentioned above for processing a local or remote description, the following steps are performed when processing a description of type "pranswer" or "answer". For each media section, the following steps MUST be performed: If the media section has been rejected (i.e. port is set to zero in the answer), stop any reception or transmission of media for this section, and discard any associated ICE components.  [TODO: ref] If the remote DTLS fingerprint has been changed, tear down the existing DTLS connection. If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any underlying ICE components, once they are active. If the media section proto value indicates use of RTP: If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in RFC5761, Section 5.1.3.  Otherwise, transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced- size RTCP, as specified in [TODO: ref] If the directional attribute in the answer is of type "sendrecv" or "sendonly", prepare to start transmitting media using the specified primary SSRC and one of the selected payload types, once the underlying transport layers have been established.  Otherwise, stop transmitting RTP media, although RTCP should still be sent.  [TODO: ref] If the media section proto value indicates use of SCTP: If no SCTP association yet exists, prepare to initiate a SCTP association over the associated ICE component and DTLS connection, using the local SCTP port value from the local description, and the remote SCTP port value from the remote description.  [TODO: ref] If the answer contains valid BUNDLE groups, discard any ICE components for the m= sections that will be bundled onto the primary ICE components in each BUNDLE, and begin muxing these m= sections accordingly.  [TODO: ref] If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. </ins> 6.


BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following: <del> If present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. </del>  An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet

It goes something like and so on. But it is not clear if the answer can contain an line if there was none in the offer.
Quoth RFC 5888: Mid Value in Answers The "mid" attribute is an identifier for a particular media stream. Therefore, the "mid" value in the offer MUST be the same as the "mid" value in the answer. Besides, subsequent offers (e.g., in a re-INVITE) SHOULD use the same "mid" value for the already existing media streams. So the answer seems to be "no"
Given the quote from 5888, is it fair to conclude that URL should be resolved with "null" for the mid property on the transceiver if there has been no mid in the SDP? .mid was just an example, the same text is present for e.g. rtcp-mux, ice-option:trickle, rtcp-size.

BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following:  <ins> If and only if present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. </ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet


both <start-time> and <stop-time> SHOULD be set to zero, e.g. "t=0 0". <del> An "a=msid-semantic:WMS" line MUST be added, as specified in I- D.ietf-mmusic-msid, Section 4. </del>  The next step is to generate m= sections, as specified in RFC4566 Section 5.14, for each MediaStreamTrack that has been added to the "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. </del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. mmusic-sctp-sdp, Section 4.1. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", <del> "a=ice-options", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc- datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del>  Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST The first step in generating an initial answer is to generate session-level attributes.  The process here is identical to that <del> indicated in the Initial Offers section above. </del>  The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> If the "trickle" ICE option is present in the offer, an "a=ice- options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4. </del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. match the fields in the offer. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", <del> "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc- datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del>  If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> TODO: msid-semantic, identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level. </del>  Once all the session-level lines have been parsed, processing continues with the lines in media sections. 5.8.  The following steps are performed at the media engine level to apply a remote description. ICE components in each BUNDLE, and begin muxing these m= sections accordingly.  [TODO: ref] <del> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. </del> 6. It is possible to change elements in the SDP returned from

This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.

both <start-time> and <stop-time> SHOULD be set to zero, e.g. "t=0 0".  <ins> An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. </ins> The next step is to generate m= sections, as specified in RFC4566 Section 5.14, for each MediaStreamTrack that has been added to the "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4.  An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. mmusic-sctp-sdp, Section 4.1. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",  <ins> "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp- port" line referencing the SCTP port number as defined in I-D.ietf- mmusic-sctp-sdp, Section 4.1. </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST The first step in generating an initial answer is to generate session-level attributes.  The process here is identical to that  <ins> indicated in the Initial Offers section above, except that the "a=ice-options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4 is only included if such an option was present in the offer. </ins> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4.  An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. match the fields in the offer. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",  <ins> "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.  <ins> TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level. </ins> Once all the session-level lines have been parsed, processing continues with the lines in media sections. 5.8. <ins> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. </ins> The following steps are performed at the media engine level to apply a remote description. ICE components in each BUNDLE, and begin muxing these m= sections accordingly.  [TODO: ref]  6. It is possible to change elements in the SDP returned from


triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration.  When a new gathering phase starts, the ICE Agent will notify the application that gathering is occurring through an event.  Then, when each new ICE candidate becomes available, the ICE Agent will supply parameters are changed: Any changes to the STUN/TURN servers to use affect the next <del> gathering phase.  If gathering has already occurred, this will cause the next call to createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used. If the ICE candidate pool has a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </del>  Any changes to the ICE candidate policy also affect the next <del> gathering phase, in similar fashion to the server changes described above.  Note though that changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </del>  Any changes to the ICE candidate pool size take effect immediately; if increased, additional candidates are pre-gathered;

From EMAIL: Question 1: Should this be interpreted literally, to mean "the next call, and only the next call to createOffer will generate new ICE credentials"? If so, there are various situations wherein one could encounter unexpected behavior. For example: Before createOffer is called, a remote offer is received that triggers an ICE restart. Should the next call to createOffer trigger another, superfluous ICE restart? createOffer is called twice, without setting the local description (and kicking off a new gathering phase). Should the second call generate new credentials, or only the first? I would propose a slight change, such as: "this will cause subsequent calls to createOffer to generate new ICE credentials, until a new gathering phase has started." This would more clearly represent the intent of the original rule, in my opinion. Question 2: The next paragraph states "Any changes to the ICE candidate policy also affect the next gathering phase, in similar fashion to the server changes described above." Does this mean that changes to the candidate policy will also cause an ICE restart, according to the same rules? I assume so, but figure it's worth asking.
On , any changes should set a needs-ice-restart bit, which is only cleared by setLD with new ICE credentials (although, possibly only by setLD + setRD, since the setLD could be rolled back) On , if the ICE policy is being made more restrictive, no ICE restart is needed. Obviously if less restrictive, then the needs-ice-restart bit will be set.
Both you proposed resolutions look good to me

triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration. <ins> When the ICE configuration changes in a way that requires a new gathering phase, a 'needs-ice-restart' bit is set.  When this bit is set, calls to the createOffer API will generate new ICE credentials. This bit is cleared by a call to the setLocalDescription API with new ICE credentials from either an offer or an answer, i.e., from either a local- or remote-initiated ICE restart. </ins> When a new gathering phase starts, the ICE Agent will notify the application that gathering is occurring through an event.  Then, when each new ICE candidate becomes available, the ICE Agent will supply parameters are changed: Any changes to the STUN/TURN servers to use affect the next  <ins> gathering phase.  With the exception of the initial state where ICE gathering has not yet occurred, the 'needs-ice-restart' bit mentioned in sec.ice-gather-overview will be set.  This will cause the next call to createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used.  If the ICE candidate pool has a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </ins> Any changes to the ICE candidate policy also affect the next  <ins> gathering phase.  If the policy is being made more liberal (i.e., more permitted candidates), the 'needs-ice-restart' bit will be set.  If the policy is being made more strict, no ICE restart is needed, and the bit will not be set.  Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </ins> Any changes to the ICE candidate pool size take effect immediately; if increased, additional candidates are pre-gathered;


little location information as possible (note that these choices come with corresponding operational costs).  To accomplish this, the browser MUST allow the application to restrict which ICE candidates <del> are used in a session.  In addition, administrators may also wish to control the set of ICE candidates, and so the browser SHOULD also allow control via local policy, with the most restrictive policy prevailing. </del>  There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level. <del> Although it can be overridden by local policy, the default ICE candidate policy MUST be set to allow all candidates, as this minimizes use of application STUN/TURN server resources. </del>  If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-

Not sure if this is done but what is there LGTM
Yes, I think this is complete.
LGTM
URL talks about browser local policy. It should make this more concrete by referring to URL as the source of this policy.
Do you see it as normatively depending on that or more just "useful implementor advice can be found in ..."
I guess it depends on what we think the purpose of the ip-handling draft is. If we think all browsers should implement this, then it should be a normative dependency. I'll make a PR as such and we can debate the details there.
I think if it is something all browser need to implement, then we probably just want to move the normative text into this draft.
I think there is enough text that it warrants being in its own document.

little location information as possible (note that these choices come with corresponding operational costs).  To accomplish this, the browser MUST allow the application to restrict which ICE candidates  <ins> are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- D.shieh-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level.  <ins> The default ICE candidate policy MUST be set to allow all candidates, as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </ins> If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-


receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm.  5.3. When createAnswer is called, a new SDP description must be created 5.3.3.1. Silence suppression in the answer is handled as described in <del> sec.voiceactivitydetection1. </del>  5.4.

We reviewed the handling for G.729 and it's similar to Opus; there's a dtx=foo fmtp parameter to control receipt of DTX. I suggest we leave this parameter to createOffer as an indication on whether you want the remote side to use DTX, and add a frob on RtpSender (TBD exactly where) to directly control whether you use DTX. That frob is out of scope for this PR. For the PSAP/E911 case, the call will typically be over PCMU, and so it's covered through either of a) setting this parameter (which drops CN from the offered codecs), or b) the PSAP not responding with CN in the answer. So that's not an issue. We may need to add some text in the handling-a-remote-description section to make it clear that if the remote side says to use DTX (either through presence of CN, or usedtx=1), DTX MUST be engaged by the browser. We could also spell out the no-DTX case, if desired.
So plan is make this just about SDP, both offer and answer, along lines of Justin text. Then file issue to deal with happens with RTP sender.
Put in all Justin's comments from prev review.
In some codecs (e.g., Opus) requests to not do silence suppression are advisory. We should consider whether we require browsers to respect them so that counterparties which need the browser to not do silence suppression can force that.
I think it would make the most sense for this to behave identically regardless of codec. IOW, if not offered, it can't be indicated in the answer. The answer can of course reject a proposal to use VAD (currently via AnswerOptions), but there could perhaps be another surface for this.
Decision in Kirkland: if offer indicates no VAD (either through lack of CN, or usedtx=0), answer MUST not specify VAD. This is done on a per-codec basis, e.g. if answerer receives CN + usedtx=0, and answerer says Vad:True, answer will have CN + usedtx=0.
Fixed by

receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. <ins> If the "VoiceActivityDetection" option is specified, with a value of "false", the browser MUST NOT omit "CN" codecs.  For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired.  For example, when using the Opus codec, the "usedtx=0" parameter would be specified in the offer. Note that setting the "VoiceActivityDetection" parameter when generating an offer is a request to receive audio with silence suppression.  It has no impact on whether the local endpoint does silence suppression for the audio it sends. The "VoiceActivityDetection" option does not have any impact on the setting of the "vad" value in the signaling of the client to mixer audio level header extension described in RFC6464, Section 4. </ins> 5.3. When createAnswer is called, a new SDP description must be created 5.3.3.1. Silence suppression in the answer is handled as described in  <ins> sec.voiceactivitydetection1, with one exception: if support for silence suppression was not indicated in the offer, the VoiceActivityDetection parameter has no effect, and the answer should be generated as if VoiceActivityDetection was set to false.  This is done on a per-codec basis (e.g., if the offerer somehow offered support for CN but set "usedtx=0" for Opus, setting VoiceActivityDetection to true would result in an answer with CN codecs and "usedtx=0"). </ins> 5.4.