7.  Note that this example section shows several SDP fragments.  To format in 72 columns, some of the lines in SDP have been split into multiple lines, where leading whitespace indicates that a line is a More examples of SDP for WebRTC call flows can be found in I- D.nandakumar-rtcweb-sdp. <del> 7.1. </del>  This section shows a very simple example that sets up a minimal audio / video call between two browsers and does not use trickle ICE.  The The SDP for |answer-A1| looks like: <del> 7.2. </del>  This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way) <del> 8. </del>  The IETF has published separate documents I-D.ietf-rtcweb-security- arch I-D.ietf-rtcweb-security describing the security architecture Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. <del> 9. </del>  This document requires no actions from IANA.

I think this is close enough to merge it, put it out in a draft, and see what the WG things
This LGTM.
overall, this looks like it's on the right track. Main question (for NAME really) is whether this should be turned more into prose rather than a W3C-style algorithm. (i.e. "First, check this. Then, do that. Next, do this other thing. Finally, drop the packet.")
Peter, if there is anything I can do to help on this one today. Ping me and I will make it top priority.
A response to Bernard's comment about when the tables are constructed: I think it's clear that the tables need to be constructed after the transport exists, but before the first packet is routed. But an implementation could choose whether to construct it right after the transport is created or right before the first packet is routed. I don't think we need to specify that. You do bring up a really good point about updating the table over time. We know entries can be added by setLocalDescription/setRemoteDescription and removed by setLocalDescription/setRemoteDescription and URL But that's not covered at all by the text written so far.
FYI, I updated this to address Bernard's comment about updating the tables over time. I added a paragraph saying what the results of updates should be, but leaves the when and how up to the implementation.
Cover MID, RID, unsignaled SSRCs, and RTCP. Related to and .
Suggest doing this in a new Section 5.10 on demux.
Actually, now that I think about it, we don't need to specify how to handle RID at all. We could just way "receive all the source RTP streams that come in and use RtpStreamID and RepairedRtpStreamID to correlate source RTP streams and repair RTP streams". In other words, the RIDs don't need to be signalled to the receiver. If I'm correct about this, we can have a simplified version: When an RtpReceiver is added, removed, or has its parameters modified, the following is done:
We had discussion during IETF that there is a need for a RTP media plane specification related to simulcast and the different types of RTP middleboxes to clarify where the various SDES items need to occur and which types of SSRC, MID and RID switching behavior that can occur on the various legs. This will clearly spark discussion as there was diverse views between Emil Ivov, Bernard Aboba, and Jonathan Lennox. Varun Singh had observed I think 4 different behaviours.
Need to not forget the case where there are multiple ports that help disambiguate.
For the case of multiple ports: I think all we need to do is point out that the algorithm applies to each of the RtpReceivers listening on a given port. In other words, demux is per-port. And obviously if you have only one RtpReceiver per port, there's nothing to do except check that the PT is known, which I think the algorithm I posted covers.
This looks reasonable except that the style is a bit inconsistent. specifically: for each encoding e in r.getParameters().encodings: receiverbyssrc[URL] = r
Here's some possible text, with slightly tweaked pseudo-code to match: When an RTP packet is received by a transport (typically a DtlsTransport), that packet MUST be routed to the correct RtpReceiver. For each transport, the following steps MUST be followed to prepare to route packets: Construct a table mapping MID to RtpReceiver. For each RtpReceiver configured to receive from this transport, let the key be the RtpReceiver's MID, and the value be the RtpReceiver. Construct a table mapping SSRC to RtpReceiver. For each RtpReceiver configured to receive from this transport, and for each SSRC that RtpReceiver is configured to receive, let the key be the SSRC and the value be the RtpReceiver. Construct a table mapping Payload Type to RtpReceiver. For each RtpReceiver configured to receive from this transport, and for each Payload Type that RtpReceiver is configured to receive, let the key be the Payload Type and the value be the RtpReceiver. For each RTP packet received, the following steps MUST be followed to route the packet: If the packet has a MID and that MID is not in the table mapping MID to RtpReceiver, drop the packet and stop. If the packet has a MID and that MID is in the table mapping MID to RtpReceiver, update the SSRC mapping table to include an entry mapping the packet's SSRC to the RtpReceiver. If the packet's SSRC is in the SSRC mapping table, route the packet to the mapped RtpReceiver and stop. If the packet's Payload Type is in the Payload Type table, update the the SSRC mapping table to include an entry mapping the packet’s SSRC to the RtpReceiver. Deliver the packet to the RtpReceiver and stop. Drop the packet. Note: When designing these steps, a troubling possible use case was if the MIDs were lost in signaling, but still sent in RTP packets. But a packet would only be sent with MIDs if an answer were sent with MIDs in it. If there are no MIDs in the answer, then MIDs would not be present in the RTP. And if MIDs are in the answer, they weren't lost from the signaling. In other words, this case will not happen. This would correspond to pseudocode something like this:
PR: URL
Resolved by
Submitted some thoughts. As usual, the devil is the details. This overall LGTM. A handful of editorial comments. LGTM

7. <ins> Note: The following algorithm does not yet have WG consensus but is included here as something concrete for the working group to discuss. When an RTP packet is received by a transport and passes SRTP authentication, that packet needs to be routed to the correct RtpReceiver.  For each transport, the following steps MUST be followed to prepare to route packets: Construct a table mapping MID to RtpReceiver for each RtpReceiver configured to receive from this transport. Construct a table mapping SSRC to RtpReceiver for each RtpReceiver configured to receive from this transport and for each SSRC that RtpReceiver is configured to receive.  Some of the SSRCs may be presesnt in the m= section corresponding to that RtpReceiver in the remote description. Construct a table mapping payload type to RtpReceiver for each RtpReceiver configured to receive from this transport and for each payload type that RtpReceiver is configured to receive.  The payload types of a given RtpReceiver are found in the m= section corresponding to that RtpReceiver in the local description.  If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description. For each RTP packet received, the following steps MUST be followed to route the packet: If the packet has a MID and that MID is not in the table mapping MID to RtpReceiver, drop the packet and stop. If the packet has a MID and that MID is in the table mapping MID to RtpReceiver, update the SSRC mapping table to include an entry mapping the packet's SSRC to the RtpReceiver. If the packet's SSRC is in the SSRC mapping table, route the packet to the mapped RtpReceiver and stop. If the packet's payload type is in the payload type table, update the the SSRC mapping table to include an entry mapping the packet's SSRC to the RtpReceiver.  Deliver the packet to the RtpReceiver and stop. Otherwise, drop the packet. After packets are routed to the RtpReceiver, further processing of the RTP packets is done at the RtpReceiver level.  This includes using I-D.ietf-mmusic-rid to determine which RTP streams depend on or repair other RTP streams. As RtpTransceivers (and, thus, RtpReceivers) are added, removed, stopped, or reconfigured, the tables above must also be updated. 8. </ins> Note that this example section shows several SDP fragments.  To format in 72 columns, some of the lines in SDP have been split into multiple lines, where leading whitespace indicates that a line is a More examples of SDP for WebRTC call flows can be found in I- D.nandakumar-rtcweb-sdp.  <ins> 8.1. </ins> This section shows a very simple example that sets up a minimal audio / video call between two browsers and does not use trickle ICE.  The The SDP for |answer-A1| looks like:  <ins> 8.2. </ins> This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way)  <ins> 9. </ins> The IETF has published separate documents I-D.ietf-rtcweb-security- arch I-D.ietf-rtcweb-security describing the security architecture Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates.  <ins> 10. </ins> This document requires no actions from IANA.


Agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for Trickle ICE.  If the MID, m-line index, or candidate string provided <del> in the ICE candidate is invalid, an error is generated.  Connectivity checks will be sent to the new candidate. </del>  This method can also be used to provide an end-of-candidates indication (as defined in I-D.ietf-ice-trickle) to the ICE Agent for

…sane peer.
NAME PTAL.
Just a quick drive-by review. LGTM with nits

Agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for Trickle ICE.  If the MID, m-line index, or candidate string provided  <ins> in the ICE candidate is invalid, an error is generated.  If present, ufrag is used to determine which generation of ICE candidates the candidate belongs to; this resolves ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is present and does not match any remote description, an error is generated.  If the ufrag is absent, the candidate MUST be assumed to belong to the most recently applied remote description.  Connectivity checks will be sent to the new candidate. </ins> This method can also be used to provide an end-of-candidates indication (as defined in I-D.ietf-ice-trickle) to the ICE Agent for


line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations <del> creating an ICE Candidate object MUST populate both of these fields. Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (as it could have come from a non-JSEP endpoint). </del>  3.5.3. Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid <del> attribute to the MID of the m= section. </del>  For each specified payload type that is also supported by the local implementation, establish a mapping between the payload

LGTM
PTAL
In the WebRTC 1.0 spec we have text talking about generating a mid if the remote description is missing one. That text has a faulty link to a JSEP (as described in issue w3c/webrtc-pc/issues/698). I can't seem to find any text in JSEP about this. Should there be such text? I did find text that said that an answer only should have a mid if the offer did.
OK, I agree we need some additional text in 3.5.2.1 to indicate that if a MID is not negotiated in SDP, a MID is locally generated (but not included in SDP).
Fixed by
Thank you!

line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations  <ins> creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a-remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (the non-JSEP remote endpoint case). </ins> 3.5.3. Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid  <ins> attribute to the MID of the m= section.  If the m= section does not include a MID (i.e., the remote side does not support the MID extension), generate a value for the RtpTransceiver mid attribute, following the guidance for "a=mid" mentioned in sec.initial-offers. </ins> For each specified payload type that is also supported by the local implementation, establish a mapping between the payload


set of ICE candidates.  Bundle-only m= sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. <del> For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they MUST all have the same RFC4572 fingerprint value, or this value MUST be a session-level attribute. </del>  Each m= section should be generated as specified in RFC4566, Section 5.14.  For the m= line itself, the following rules MUST be "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.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. </del>  An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

and
whoops, didn't realize that eric hadn't reviewed before I merged. NAME want to take a quick look?
This updates 4572 so needs to be referenced. Also see URL
This changes the requirements around use of .
Dup of
Minor nits.

set of ICE candidates.  Bundle-only m= sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates.  <ins> For DTLS, all m= sections MUST use all the certificate(s) that have been specified for the PeerConnection; as a result, they MUST all have the same I-D.ietf-mmusic-4572-update fingerprint value(s), or these value(s) MUST be session-level attributes. </ins> Each m= section should be generated as specified in RFC4566, Section 5.14.  For the m= line itself, the following rules MUST be "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4.  <ins> One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.


gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. <del> Each m= section MUST include the following attribute lines: </del>  An "a=mid" line, as specified in RFC5888, Section 4.  When generating mid values, it is RECOMMENDED that the values be 3 specific usage for each media type is outlined in Sections 4 and 5. <del> "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the offer MUST be "actpass". An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux- exclusive Section 4, if and only if the RTP/RTCP multiplexing policy is "require". An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. </del> For each supported RTP header extension, an "a=extmap" line, as specified in RFC5285, Section 5.  The list of header extensions that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp- Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section.  Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being bundled must use unique ICE credentials and candidates.  Each m= <del> section MUST include the following: </del>  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 specific usage for each media type is outlined in Sections 4 and 5. <del> "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the answer MUST be "active" or "passive"; the "active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. If present in the offer, an "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4.3. If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. </del> For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in RFC5285, Section 5. The list of header extensions that SHOULD/MUST be supported is simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC.  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 "application" and the <proto> and "fmt" fields MUST be set to exactly Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included <del> 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

NAME NAME Is this approximately right?
Looks close enough to me - lets land this then tune with future PRs
LG with nits

gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1.  <ins> I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, Section 8.1 of I-D.ietf-mmusic-sdp-bundle-negotiation specifies that attributes of category IDENTICAL or TRANSPORT should not be repeated in bundled m= sections. The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section: </ins> An "a=mid" line, as specified in RFC5888, Section 4.  When generating mid values, it is RECOMMENDED that the values be 3 specific usage for each media type is outlined in Sections 4 and 5.  For each supported RTP header extension, an "a=extmap" line, as specified in RFC5285, Section 5.  The list of header extensions that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp- Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. <ins> The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag.  (In initial offers, this means those "m=" sections which do not contain an "a=bundle-only" attribute. "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. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the offer MUST be "actpass". An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. [TODO: rtcp-fb?] </ins> Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being bundled must use unique ICE credentials and candidates.  Each m=  <ins> section MUST contain the following attributes (which are of attribute types other than IDENTICAL and TRANSPORT): </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 specific usage for each media type is outlined in Sections 4 and 5.  For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in RFC5285, Section 5. The list of header extensions that SHOULD/MUST be supported is simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <ins> Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): "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. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the answer MUST be "active" or "passive"; the "active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. </ins> 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 "application" and the <proto> and "fmt" fields MUST be set to exactly Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included  <ins> under the conditions described 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


information.  However, SDP allows many types of lines, not all of which are relevant to JSEP applications.  For each line, the implementation will first ensure it is syntactically correct <del> according its defining ABNF, check that it conforms to RFC4566 and </del>  RFC3264 semantics, and then either parse and store or discard the <del> provided value, as described below.  A partial list of ABNF definitions for SDP attributes can found in: </del>  <del> [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. </del>  5.7.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, 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. </del>  The "c=" line MUST be checked for syntax but its value is not used.  This supersedes the guidance in RFC5245, Section 6.1, to not used by this specification; they MUST be checked for syntax but their values are not used. <del> The remaining lines are processed as follows: </del>  The "v=" line MUST have a version of 0, as specified in RFC4566, Section 5.1. The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored. <del> Specific processing MUST be applied for the following session-level attribute ("a=") lines: </del>  Any "a=group" lines are parsed as specified in RFC5888, Section 5, and the group's semantics and mids are stored. in RFC5245, Section 15.5, and the set of specified options is stored.  Any "a=fingerprint" lines are parsed as specified in RFC4572, Section 5, and the set of fingerprint and algorithm values is stored. specified in I-D.ietf-mmusic-msid, Section 3.2, and its value stored. <del> Any "a=candidate" attributes MUST be parsed as specified in RFC5245, Section 4.3, and their values stored. Any "a=remote-candidates" attributes MUST be parsed as specified in RFC5245, Section 4.3, but their values are ignored. If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in I-D.ietf-ice-trickle, Section 8.2, and its presence or absence flagged and stored. </del> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

Rewrite intro to be clearer Move table to appendix Fix some parsing instructions that were in the wrong place
LGTM (other than the little bad xml issue)

information.  However, SDP allows many types of lines, not all of which are relevant to JSEP applications.  For each line, the implementation will first ensure it is syntactically correct  <ins> according to its defining ABNF, check that it conforms to RFC4566 and </ins> RFC3264 semantics, and then either parse and store or discard the  <ins> provided value, as described below. </ins>  <ins> If any line is not well-formed, or cannot be parsed as described, the parser MUST stop with an error and reject the session description, even if the value is to be discarded.  This ensures that implementations do not accidentally misinterpret ambiguous SDP. </ins> 5.7.1. same type (typically "a=") can occur in any order, and their ordering is not meaningful.  <ins> The following non-attribute lines are 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 not used by this specification; they MUST be checked for syntax but their values are not used.  <ins> The remaining non-attribute lines are processed as follows: </ins> The "v=" line MUST have a version of 0, as specified in RFC4566, Section 5.1. The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored.  <ins> Finally, the attribute lines are processed.  Specific processing MUST be applied for the following session-level attribute ("a=") lines: </ins> Any "a=group" lines are parsed as specified in RFC5888, Section 5, and the group's semantics and mids are stored. in RFC5245, Section 15.5, and the set of specified options is stored. <ins> Any "a=candidate" attributes MUST be parsed as specified in RFC5245, Section 15.1, and their values stored. Any "a=remote-candidates" attributes MUST be parsed as specified in RFC5245, Section 15.2, but their values are ignored. If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in I-D.ietf-ice-trickle, Section 8.2, and its presence or absence flagged and stored. </ins> Any "a=fingerprint" lines are parsed as specified in RFC4572, Section 5, and the set of fingerprint and algorithm values is stored. specified in I-D.ietf-mmusic-msid, Section 3.2, and its value stored.  Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.


3.4.2. RtpSenders allow the application to control how RTP media is sent. <del> In particular, the application can control whether an RtpSender is active or not, which affects the directionality attribute of the associated m= section. </del> 3.4.3. RtpReceivers allows the application to control how RTP media is <del> received.  In particular, the application can control whether an RtpReceiver is active or not, which affects the directionality attribute of the associated m= section. </del>  3.5. policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. <del> If the RtpSender of the RtpTransceiver associated with this m=section is active: </del>  An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> If the RtpTransceiver's RtpSender is active, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified.  The "a=rid" line is specified in I-D.ietf-mmusic-rid, and its direction MUST be "send".  If the application has chosen a RID value, it MUST be used as the rid-identifier; otherwise a RID value MUST be generated by the implementation.  When generating RID values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 11.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. If the RtpTransceiver's RtpSender is active and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in I-D.ietf-mmusic-sdp-simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. </del>  The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. <del> If the RtpSender of the RtpTransceiver associated with this m=section is active: </del>  An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. RtpTransceiver. If no RtpTransceiver was found in the previous step, create <del> one with an inactive RtpSender and active RtpReceiver. </del>  Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid

Reference transceiver direction as opposed to "active" senders/receivers We initially thought there would be an "active" bit on senders/receivers to control the direction of a media description, but instead we now have a "setDirection" API on the transceiver. So we should reference that.
lgtm

3.4.2. RtpSenders allow the application to control how RTP media is sent.  3.4.3. RtpReceivers allows the application to control how RTP media is  <ins> received. </ins> 3.5. policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line.  <ins> If the RtpTransceiver has a sendrecv or sendonly direction: </ins> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC.  <ins> If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified.  The "a=rid" line is specified in I- D.ietf-mmusic-rid, and its direction MUST be "send".  If the application has chosen a RID value, it MUST be used as the rid- identifier; otherwise a RID value MUST be generated by the implementation.  When generating RID values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 11.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in I-D.ietf-mmusic-sdp- simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. </ins> The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1.  <ins> If the RtpTransceiver has a sendrecv or sendonly direction: </ins> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. RtpTransceiver. If no RtpTransceiver was found in the previous step, create  <ins> one with a recvonly direction. </ins> Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid


Construct a table mapping MID to RtpReceiver for each RtpReceiver configured to receive from this transport. <del> Construct a table mapping SSRC to RtpReceiver for each RtpReceiver configured to receive from this transport and for each SSRC that RtpReceiver is configured to receive.  Some of the SSRCs may be presesnt in the m= section corresponding to that RtpReceiver in the remote description. </del>  Construct a table mapping payload type to RtpReceiver for each RtpReceiver configured to receive from this transport and for each the RtpReceiver whose m= section appears earliest in the local description.  For each RTP packet received, the following steps MUST be followed to route the packet: MID to RtpReceiver, drop the packet and stop. If the packet has a MID and that MID is in the table mapping MID <del> to RtpReceiver, update the SSRC mapping table to include an entry mapping the packet's SSRC to the RtpReceiver. </del>  <del> If the packet's SSRC is in the SSRC mapping table, route the packet to the mapped RtpReceiver and stop. </del>  If the packet's payload type is in the payload type table, update <del> the the SSRC mapping table to include an entry mapping the packet's SSRC to the RtpReceiver.  Deliver the packet to the RtpReceiver and stop. </del>  Otherwise, drop the packet.  After packets are routed to the RtpReceiver, further processing of the RTP packets is done at the RtpReceiver level.  This includes <del> using I-D.ietf-mmusic-rid to determine which RTP streams depend on or repair other RTP streams. As RtpTransceivers (and, thus, RtpReceivers) are added, removed, stopped, or reconfigured, the tables above must also be updated. </del>  7.

Fixes URL URL
LGTM
I made a bunch of edits to cover how the different types of RTCP packets should be handled, including compound RTCP packets. I also tweaked the RTP text slightly to be more consistent with the RTCP text. NAME NAME NAME PTAL.
NAME can you take a look?
LGTM
Fixed by
If the RTCP SDES has a MID value, update the SSRC mapping table for that SSRC to map to the receiver associated with that MID
This LGTM

Construct a table mapping MID to RtpReceiver for each RtpReceiver configured to receive from this transport.  <ins> Construct a table mapping incoming SSRC to RtpReceiver for each RtpReceiver configured to receive from this transport and for each SSRC that RtpReceiver is configured to receive.  Some of the SSRCs may be present in the m= section corresponding to that RtpReceiver in the remote description. Construct a table mapping outgoing SSRC to RtpSender for each RtpSender configured to transmit from this transport and for each SSRC that RtpSender is configured to use when sending. </ins> Construct a table mapping payload type to RtpReceiver for each RtpReceiver configured to receive from this transport and for each the RtpReceiver whose m= section appears earliest in the local description. <ins> As RtpTransceivers (and, thus, RtpReceivers) are added, removed, stopped, or reconfigured, the tables above must also be updated. </ins> For each RTP packet received, the following steps MUST be followed to route the packet: MID to RtpReceiver, drop the packet and stop. If the packet has a MID and that MID is in the table mapping MID  <ins> to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that MID. </ins>  <ins> If the packet's SSRC is in the incoming SSRC mapping table, deliver the packet to the associated RtpReceiver and stop. </ins> If the packet's payload type is in the payload type table, update  <ins> the the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that payload type.  In addition, deliver the packet to the associated RtpReceiver and stop. </ins> Otherwise, drop the packet. <ins> For each RTCP packet received (including each RTCP packet that is part of a compound RTCP packet), the following type-specific handling MUST be performed to route the packet: If the packet is of type SR, and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC.  In addition, for each report block in the report whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC. If the packet is of type RR, for each report block in the packet whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC. If the packet is of type SDES, and the sender SSRC for the packet is found in the incoming SSRC table, deliver the packet to the RtpReceiver associated with that SSRC.  In addition, for each chunk in the packet that contains a MID that is in the table mapping MID to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the SSRC for that chunk to the RtpReceiver associated with that MID.  (This case can occur when RTCP for a source is received before any RTP packets.) If the packet is of type BYE, for each SSRC indicated in the packet that is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC. If the packet is of type RTPFB or PSFB, as defined in RFC4585, and the media source SSRC for the packet is found in the outgoing SSRC table, deliver the packet to the RtpSender associated with that SSRC. </ins> After packets are routed to the RtpReceiver, further processing of the RTP packets is done at the RtpReceiver level.  This includes  <ins> using I-D.ietf-mmusic-rid to distinguish between multiple Encoded Streams, as well as determine which Source RTP stream should be repaired by a given Redundancy RTP stream.  If the RTP packet's PT does not match any codec in use by the RtpReceiver, the packet will be dropped. </ins> 7.


feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. <del> 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 Section 4.9 of I-D.ietf-rtcweb-rtp-usage. 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 RFC5576, section 4.2, with semantics set to "FID" and including the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </del> If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. <del> 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 Section 4.9 of I-D.ietf- rtcweb-rtp-usage. 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 RFC5576, section 4.2, with semantics set to "FID" and including the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </del> If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to <del> zero and the "a=msid", "a=ssrc", and "a=ssrc-group" lines removed. </del>  <del> For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same if they are present in the current description. </del>  Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same. </del>  For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. MUST stay the same. If any RtpTransceiver has been stopped, the port MUST be set to <del> zero and the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be removed. </del>  If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. <del> 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 Section 4.9 of I-D.ietf- rtcweb-rtp-usage. If RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FID" and including the primary and RTX SSRCs. If FEC has been negotiated for this m= section, another "a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </del> Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same. </del>  5.3.3.

a=ssrc and a=ssrc-group.
NAME note I still assume you might receive a=ssrc because it might come from non-JSEP endpoints. LMK if you want that removed.

feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1.  If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.  If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to  <ins> zero and the "a=msid" line removed. </ins>  <ins> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same if they are present in the current description. </ins> Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted.  <ins> For RtpTransceivers that are still present, the "a=msid" line MUST stay the same. </ins> For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. MUST stay the same. If any RtpTransceiver has been stopped, the port MUST be set to  <ins> zero and the "a=msid" line MUST be removed. </ins> If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.  Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted.  <ins> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same. </ins> 5.3.3.


header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <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 been gathered. </del> A direction attribute which is the same as that of the associated transceiver. An "a=dtls-id" line, as specified in I-D.ietf-mmusic-dtls-sdp Section 5.2.  An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. in active use, then that pair MUST be used, even if ICE has not yet completed.  Note that this differs from the guidance in RFC5245, Section 9.1.2.2, which only refers to offers created when <del> ICE has completed.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </del>  Each "a=mid" line MUST stay the same. section is bundled into another m= section, it still MUST NOT contain any ICE credentials.  If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be The RTCP feedback extensions MUST only include those that are present in the most recent answer.  The "a=rtcp-mux" line MUST only be added if present in the most recent answer. 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 been gathered. </del> A direction attribute which is the same as that of the associated transceiver. Section 5.3. If present in the offer, an "a=rtcp-mux" line, as specified in <del> RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. </del>  If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. RFC5245, Section 4.3.  Note, however, that the m= line protocol need not match the default candidate, because this protocol value must instead match what was supplied in the offer, as described <del> above.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is enabled in the answer.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described in the initial answer section </del> above. The media formats on the m= line MUST be generated in the same m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials.  If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be

LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin

header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11.  A direction attribute which is the same as that of the associated transceiver. An "a=dtls-id" line, as specified in I-D.ietf-mmusic-dtls-sdp Section 5.2. <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 been gathered. </ins> An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. in active use, then that pair MUST be used, even if ICE has not yet completed.  Note that this differs from the guidance in RFC5245, Section 9.1.2.2, which only refers to offers created when  <ins> ICE has completed.  In each case, if no RTP candidates have yet been gathered, dummy values MUST be used, as described above. </ins> Each "a=mid" line MUST stay the same. section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> If the m= section is not bundled into another m= section, an "a=rtcp" attribute line MUST be added with of the default RTCP candidate, as indicated in RFC5761, section 5.1.3. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be The RTCP feedback extensions MUST only include those that are present in the most recent answer. <ins> The "a=rtcp" line MUST be added if the most recent answer did not include an "a=rtcp-mux" line; otherwise it MUST NOT be added. </ins> The "a=rtcp-mux" line MUST only be added if present in the most recent answer. in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer.  A direction attribute which is the same as that of the associated transceiver. Section 5.3. If present in the offer, an "a=rtcp-mux" line, as specified in  <ins> RFC5761, Section 5.1.1.  Otherwise, 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 been gathered). </ins> If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. RFC5245, Section 4.3.  Note, however, that the m= line protocol need not match the default candidate, because this protocol value must instead match what was supplied in the offer, as described  above. The media formats on the m= line MUST be generated in the same m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> If the m= section is not bundled into another m= section and RTCP multiplexing is not active, an "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate. If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial answer section above. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be


An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. <del> [TODO: rtcp-fb?] </del> Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default

IDENTICAL-PT or SPECIAL which means that they should be in all the m= sections.
NAME can you look into this? Should be straightforward to resolve.

An "a=rtcp-rsize" line, as specified in RFC5506, Section 5.  Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default


affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer. <del> TODO: Write example showing how this might be used and how it affects offers/answers/reoffers.  Maybe something like: "sendonly" remote offer, setDirection("sendonly"), "inactive" answer, "sendonly" reoffer. </del>  4.2.4. header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <del> A direction attribute, determined by applying the rules regarding the offered direction specified in RFC3264, Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. </del>  For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264, in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. <del> A direction attribute which is the same as that of the associated transceiver. </del>  For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264,

Also, fixes problem where my previous change to explain the directional attribute for answers was accidentally applied to the offer section.
Not clear whether this should be an example, i.e., in the Examples section, or perhaps just an aside in the setDirection section.

affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer.  <ins> When creating offers, the transceiver direction is directly reflected in the output, even for reoffers.  When creating answers, the transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below. </ins> 4.2.4. header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11.  <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264, in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer.  <ins> A direction attribute, determined by applying the rules regarding the offered direction specified in RFC3264, Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. </ins> For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264,


cases, the value of the RtpTransceiver's mid attribute MUST be set to null.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a <del> RtpTransceiver MUST NOT be removed if the RtpTransceiver's RtpSender was activated by the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </del>  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or

This still refers to RtpSenders being "activated", a concept that isn't defined anywhere. I replaced this with "track attached to the transceiver" since that's the terminology that's used elsewhere.

cases, the value of the RtpTransceiver's mid attribute MUST be set to null.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a  <ins> RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </ins> A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or


have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. <del> Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. </del>  Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically

This is OK with me but fine if we want to call out identity or anything that is different.
How's this?
LGTM
S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST

have semantics "BUNDLE", and MUST include the mid identifiers of each m= section.  <ins> Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical.  This promotes readability, especially if one of a set of initially identical attributes is subsequently changed. </ins> Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically


6. <del> Note: This section is still very early and is likely to significantly change as we get a better understanding of a) the use cases for this b) the implications at the protocol level c) feedback from implementors on what they can do. </del>  The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription, since endpoint are not exceeded (e.g. asking for a resolution greater than what the endpoint can encode): <del> disable BUNDLE (a=group) disable RTCP mux (a=rtcp-mux) change send resolution or frame rate change desired recv resolution or frame rate change maximum total bandwidth (b=) [OPEN ISSUE: need to clarify if this is CT or AS - see section 5.8 of RFC4566] remove desired AVPF mechanisms (a=rtcp-fb) remove RTP header extensions (a=extmap) change media send/recv state (a=sendonly/recvonly/inactive) </del>  <del> For example, an application could implement call hold by adding an a=inactive attribute to its local description, and then applying and signaling that description. </del>  The application can also modify the SDP to reduce the capabilities in <del> the offer it sends to the far side in any way the application sees fit, as long as it is a valid SDP offer and specifies a subset of what the browser is expecting to do. </del>  As always, the application is solely responsible for what it sends to the other party, and all incoming SDP will be processed by the

Sure, I can do that.
Justin and I discussed on the call and this is still borked due to some git pilot error.
PTAL now.
LGTM
Section 6 indicates that programmers can edit the SDP and lists changes which can and cannot be made. It explicitly is preliminary and needs to be fleshed out.
There are three categories - must reject, must act on , and ones that the browser can do whatever it wants but if it is not acted on then an error is generated
General approach is most things are in the "browser can do what it wants case"
Discussed in DC: this applies only to changes on the local side; the gap between createOffer/createAnswer and setLocalDescription. Proposed path is to mandate one of two actions: Accept the changes and apply them Reject the changes outright We will enumerate certain changes that fall into either category, but these lists will not be exhaustive. All unspecified changes will either be accepted or rejected, and that decision will be left to the browser, but they cannot be ignored. Obviously, some types of changes will be ignored. For instance, reordering of a= lines might not be detected as a change. These might carry semantics (as a=group-id does), but we can't require perfect detection.

6.  <ins> It is possible to change elements in the SDP returned from createOffer before passing it to setLocalDescription.  When an implementation receives modified SDP it MUST either: Accept the changes and adjust its behavior to match the SDP. Reject the changes and return an error via the error callback. Changes MUST NOT be silently ignored. </ins> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription, since endpoint are not exceeded (e.g. asking for a resolution greater than what the endpoint can encode):  <ins> [[OPEN ISSUE: This is a placeholder for other modifications, which we may continue adding as use cases appear.]] </ins>  <ins> Implementations MAY choose to either honor or reject any elements not listed in the above two categories, but must do so explicitly as described at the beginning of this section.  Note that future standards may add new SDP elements to the list of elements which must be accepted or rejected, but due to version skew, applications must be prepared for implementations to accept changes which must be rejected and vice versa. </ins> The application can also modify the SDP to reduce the capabilities in  <ins> the offer it sends to the far side or the offer that it installs from the far side in any way the application sees fit, as long as it is a valid SDP offer and specifies a subset of what was in the original offer.  This is safe because the answer is not permitted to expand capabilities and therefore will just respond to what is actually in the offer. </ins> As always, the application is solely responsible for what it sends to the other party, and all incoming SDP will be processed by the


allocated to the senders and setting maximum media bit-rate boundaries. <del> TODO: any others? </del> As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.

I think there may still be more work to do here, but we can track in the existing bug () rather than a TODO.
Raised by Magnus.
URL
R-10 (a=ssrc) should probably be removed or adjusted to reflect the fact that JSEP won't generate these lines.
I'm starting on this one
We need to look at the PR started on this and see if this is something we want to do or if we should go the direction of just calling out the non obvious implementation requirements here.
This seems fixed. Closing it
Cullen to inspect document and ensure all relevant SDP RFCs are cited in the generating/parsing offer/answer sections (using full list in )
Is this resolved by ?
Yes. Closing.

allocated to the senders and setting maximum media bit-rate boundaries.  As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.


RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e., a default value of "trr- int=0".  Otherwise, assume that AVPF is being used in an AVP <del> compatible mode and use AVP timing, i.e., "trr-int=4". </del>  For data m= sections, JSEP endpoints MUST support receiving the <del> "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards </del>  compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile

Adding link to
Originally raised by Magnus: Otherwise, assume that AVPF is being used in an AVP compatible mode and use AVP timing, i.e., "trr-int=4". I find this sentence confusing. I think this should be clarified to say: Otherwise, assume that AVPF is being used in an AVP compatible mode, i.e. use AVPF timing configured with a "trr-int=4". Section 5.1.3: Spurious space in: For data m= sections, JSEP endpoints MUST support receiving the "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles.
NAME PR wanted.
NAME the text here was trying to indicate that "AVP timing" was a minimum interval of 4 seconds. With the proposed change, the paragraph becomes confusing, as both parts reference "AVPF timing". What do you suggest we do?
ping NAME
NAME the text you quote appears to be correct. The important aspect is that AVPF becomes compatible with AVP if one uses trr-int=4.0. Where if AVPF (SAVPF) is offered one should use either the default trr-int=0, or negotiate another value. I assume what you find confusing is this part "assume that AVPF is being used in an AVP compatible mode". A possible change could be to change that third sentence to read: "If AVP is offered, then use AVPF in an AVP compatible mode, i.e. set trr-int=4000 (4 s). Does this solve the issue?
I think slight change here would address Justin's comment

RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e., a default value of "trr- int=0".  Otherwise, assume that AVPF is being used in an AVP  <ins> compatible mode and use a value of "trr-int=4000". </ins> For data m= sections, JSEP endpoints MUST support receiving the  <ins> "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards </ins> compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile


The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section: <del> An "a=mid" line, as specified in RFC5888, Section 4.  When generating mid values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. </del>  A direction attribute which is the same as that of the associated transceiver. D.ietf-mmusic-rid, and its direction MUST be "send".  If the application has chosen a RID value, it MUST be used as the rid- identifier; otherwise a RID value MUST be generated by the <del> implementation.  When generating RID values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 11.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. </del>  If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast"

NAME PTAL
NAME ready for you
And I think the RID one is: URL
NAME PTAL
o An "a=mid" line, as specified in [RFC5888], Section 4. When generating mid values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11. Just to note that to my understanding we are having discussion if this should be referencing a more specific generation algorithm. Such a change is likely to affect text on RID also: Section 5.2.1: The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. I would request that we don't use the quite confusing "SHOULD/MUST" and instead write something like: mechanisms that are recommended or mandated to be supported
So proposed plan is we use some of the text Magnus wrote in other comment on this one and bs sepific about no PII or device ID and sugest some ways to solve are random or seuential
Editorial, but someone needs to go find the text.
Note that the resolution to this may be here, in Bundle, or in Security Architecture document; authors are requested to discuss. The same text would likely be needed in any case. Magnus Westerlund has proposed the following text for Bundle: "The identfication-tag when included in the RTP MID SDES item, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag MUST NOT contain any user related information for privacy reasons, nor hardware based identifiers. That as such information could enable tracking of the sending end point. The identification-tag is used to route the media stream to the right application functionality, thus is important that the value received is the one intended by the sender. Malicious modifications can result in that a media stream is wrongly attributed or fails to be played. Thus, verifying integrity and the authenticity of the source are RECOMMENDED to prevent these attacks on the application. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201]." This clarifies that the MID should have no PII and should not enable tracking of the sending end point. If this advice is followed, the usual requirement to encrypt SDES items in the presence of encrypted RTCP might be waived, if there is consensus that this confidentiality would not serve any purpose commensurate with the difficulty involved. This is permitted by this text in RFC 7941: If the security level is chosen to be different for an SDES item in RTCP and an RTP header extension, it is important to justify the exception and to consider the security properties as the worst in each aspect for the different configurations. This text requires, however, that a justification be provided. It seems best that this justification originate in the RTCWEB working group, no matter where it is eventually documented.
Here's the existing text on generating mid values. We can augment this to simply say to use non-identifying information.

The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:  <ins> An "a=mid" line, as specified in RFC5888, Section 4.  All mid values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-mmusic-sdp- bundle-negotiation, Section 14. </ins> A direction attribute which is the same as that of the associated transceiver. D.ietf-mmusic-rid, and its direction MUST be "send".  If the application has chosen a RID value, it MUST be used as the rid- identifier; otherwise a RID value MUST be generated by the  <ins> implementation.  RID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per- PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 3.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. </ins> If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast"


(e.g. a finite number of decoders), createOffer should return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those <del> resources.  Because this method may need to inspect the system state to determine the currently available resources, it may be implemented as an async operation. </del>  Calling this method may do things such as generate new ICE credentials, but does not result in candidate gathering, or cause Session descriptions generated by createAnswer must be immediately usable by setLocalDescription; like createOffer, the returned <del> description should reflect the current state of the system.  Because this method may need to inspect the system state to determine the currently available resources, it may need to be implemented as an async operation. </del>  Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media

Section 4.1.5 createOffer: The statement about this being async is either a requirement or out of scope. I'd suggest out of scope (it is purely an API property); the alternative is saying "it is an async operation".

(e.g. a finite number of decoders), createOffer should return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those  <ins> resources. </ins> Calling this method may do things such as generate new ICE credentials, but does not result in candidate gathering, or cause Session descriptions generated by createAnswer must be immediately usable by setLocalDescription; like createOffer, the returned  <ins> description should reflect the current state of the system. </ins> Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media


If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header <del> extension, as described in I-D.ietf-mmusic-msid, Section 3.2. </del>  For each specified media format, establish a mapping between the payload type and the actual media format, as described in

The text in -14 says: If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension, as described in [I-D.ietf-mmusic-msid], Section 3.2. This should reference the BUNDLE specification, not the MSID specification, I believe.

If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header  <ins> extension, as described in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 14. </ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in


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 <del> the mandatory constraints, this SHOULD be represented by x=0 and y=0 </del>  values. The rules here express a single set of preferences, and therefore,

Section 3.6.1 "no resolutions .. SHOULD be represented by x=0 and y=0 values". Is there any reason not to make this a MUST?
Makes sense.
+1

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  <ins> the mandatory constraints, this MUST be represented by x=0 and y=0 </ins> values. The rules here express a single set of preferences, and therefore,


in the corresponding media section in the offer, this indicates a negotiation problem and MUST result in an error. <del> 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, prepare to transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. </del>  If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced-

Originally raised by Magnus 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, prepare to transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. I think this should say "any RTCP ICE component"..
agreed
I have a related question: Should ICEbis describe the procedures for discarding an ICE media stream or component (as needed for BUNDLE and RTCP mux negotiation)? Or is it obvious enough already what this implies?
This LGTM but see comment

in the corresponding media section in the offer, this indicates a negotiation problem and MUST result in an error.  <ins> If the media section has RTCP mux enabled, discard the RTCP ICE component, if one exists, and begin or continue muxing RTCP over the RTP ICE component, as specified in RFC5761, Section 5.1.3.  Otherwise, prepare to transmit RTCP over the RTCP ICE component; if no RTCP ICE component exists, because RTCP mux was previously enabled, this MUST result in an error. </ins> If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced-


multiplexing or non-multiplexing endpoints. The browser will only gather RTP candidates.  This halves the <del> number of candidates that the offerer needs to gather.  When acting as answerer, the implementation will reject any m= section that does not contain an "a=rtcp-mux" attribute. </del>  The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to section for this media type or in the same bundle group as the first m= section for this media type. <del> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute. </del> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed: not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified.  If this session description is of type "pranswer" or "answer", the following additional checks are applied: exactly match the media type and protocol values in the corresponding m= section in the associated offer.  5.8. The following steps are performed at the media engine level to apply

This will happen when applying either an offer or an answer, for consistency. Also, any "semantics verification" failure will now result in an error, which was assumed but not explicitly stated. Fixes issue .
This is a good start, but you'll also want to update 4.1.1, 5.3.1 to reflect this (new) policy. Note though that this will end up being inconsistent with the handling of max-bundle as it is described in 4.1.1, although I still think this is the right approach.
Updated 4.1.1. I thought I already made the needed change to 5.3.1, what else needs to be changed?
I may be overlooking something, but I don't think this behavior is documented anywhere. I think the choices, in order of harshness, are: Silently fails, and you don't get RTCP negotiationneeded fires, and the m= section is port-zeroed in the next offer setRemoteDescription throws an error I'd lean towards the middle option, but that assumes that applications listen to negotiationneeded.
I lean toward the last option, as a violation of an invariant set by the offerer.
Agree that this should be documented somewhere.
+1 on the throw an error option
The general policy that we discussed here in Seattle was that any spec violation should lead to a setRD exception, not a zero port. For the rtcp-mux-only doc, we probably should have some language that makes rtcp-mux in the answer a MUST.
Resolved by

multiplexing or non-multiplexing endpoints. The browser will only gather RTP candidates.  This halves the  <ins> number of candidates that the offerer needs to gather.  Applying a description with an m= section that does not contain an "a=rtcp- mux" attribute will cause an error to be returned. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to section for this media type or in the same bundle group as the first m= section for this media type.  Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed: not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. <ins> If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied: exactly match the media type and protocol values in the corresponding m= section in the associated offer. <ins> If any of the preceding checks failed, processing MUST stop and an error MUST be returned. </ins> 5.8. The following steps are performed at the media engine level to apply


Section 6.2, with a "send" simulcast stream description that lists each desired encoding, and no "recv" simulcast stream description. The m= section will also include an "a=rid" attribute for each <del> encoding, as specfied in I-D.ietf-mmusic-rid, Section 4; the use of </del>  RID identifiers allows the individual encodings to be disambiguated even though they are all part of the same m= section. transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and createAnswer.  Note that setCodecPreferences does not directly affect <del> which codec the implemtation decides to send.  It only affects which codecs the implementation indicates that it prefers to receive, via the offer or answer.  Even when a codec is excluded by </del>  setCodecPreferences, it still may be used to send until the next offer/answer exchange discards it. followed: The port value is set to the port of the default ICE candidate for <del> this m= section, but given that no candidates have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </del>  To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the Section 5). The m= line MUST be followed immediately by a "c=" line, as specified <del> in RFC4566, Section 5.7.  Again, as no candidates have yet been gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </del>  I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates <del> have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </del>  The <proto> field MUST be set to exactly match the <proto> field for the corresponding m= line in the offer. Section 5). The m= line MUST be followed immediately by a "c=" line, as specified <del> in RFC4566, Section 5.7.  Again, as no candidates have yet been gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </del>  If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription.  If precise control over <del> the SDP is needed, the aformentioned createOffer/createAnswer options or RTPSender APIs MUST be used. </del>  Note that the application MAY modify the SDP to reduce the capabilities in the offer it sends to the far side (post-

NAME I fixed this.
Section 5.2.1 CreateOffer "given that no candidates have yet been gathered" - when people remember the pre-gathered candidate pool, this can be confusing. Suggest adding a note at the top of this section saying that CreateOffer doesn't cause candidate gathering and does not take candidates from the pre-gathered pool, and thus, no candidates are available at the initial call to CreateOffer. All subsequent references to "no candidates have yet been gathered" in this section should be replaced with "no candidates are available". This also affects section 5.3.1 CreateAnswer.
lgtm

Section 6.2, with a "send" simulcast stream description that lists each desired encoding, and no "recv" simulcast stream description. The m= section will also include an "a=rid" attribute for each  <ins> encoding, as specified in I-D.ietf-mmusic-rid, Section 4; the use of </ins> RID identifiers allows the individual encodings to be disambiguated even though they are all part of the same m= section. transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and createAnswer.  Note that setCodecPreferences does not directly affect  <ins> which codec the implementation decides to send.  It only affects which codecs the implementation indicates that it prefers to receive, via the offer or answer.  Even when a codec is excluded by </ins> setCodecPreferences, it still may be used to send until the next offer/answer exchange discards it. followed: The port value is set to the port of the default ICE candidate for  <ins> this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </ins> To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the Section 5). The m= line MUST be followed immediately by a "c=" line, as specified  <ins> in RFC4566, Section 5.7.  Again, as no candidates are available yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </ins> I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates  <ins> are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </ins> The <proto> field MUST be set to exactly match the <proto> field for the corresponding m= line in the offer. Section 5). The m= line MUST be followed immediately by a "c=" line, as specified  <ins> in RFC4566, Section 5.7.  Again, as no candidates are available yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </ins> If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription.  If precise control over  <ins> the SDP is needed, the aforementioned createOffer/createAnswer options or RTPSender APIs MUST be used. </ins> Note that the application MAY modify the SDP to reduce the capabilities in the offer it sends to the far side (post-


RFC4568 MUST NOT be implemented to signal SDES SRTP keying information. <del> The RFC5888 grouping framework MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. </del>  I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and

Fixed
Cullen, I did some git history rewriting to remove the unnecessary flip-flop around this bullet entry and push -f ed.
LGTM
Section 5.1.1 R-16: TODOs should be deleted before Last Call :-) Also sugggest renumbering the trailing sentence as R-16. Section 5.1.2: Suggest using a different letter on the numbering. U-1 and U-2?

RFC4568 MUST NOT be implemented to signal SDES SRTP keying information.  <ins> RFC5888 MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. </ins> I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and


media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences.  Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in I-D.ietf- rtcweb-audio(see Section 3) and I-D.ietf-rtcweb-video(see The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST only include codecs present in the most recent answer which have not been excluded by the codec preferences of the associated <del> transceiver. </del>  The media formats on the m= line MUST be generated in the same order as in the current local description. If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences or <del> not present in the offer. </del>  Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in I-D.ietf-

Fixes issue .
Note that I made this a MAY and not a MUST, because the only precedent for a MUST in codec selection is with regards to the mandatory codecs.
This seems like it still needs some more work, as we discussed earlier.
I added some more informative text about non-JSEP endpoints. Does this address your concerns Ekr? There are still some questions about when (if ever) a JSEP endpoint is allowed to include previously discarded codecs in an offer (issue ), but this PR should at least address issue .
Browser offer MCU, VP9, and VP10. MCU answers with VP10. Offer / answer completes. Later the MCU offers VP9 to browser on m-line that was currently use VP10. What does the browser do? A strict reading of spec might suggest that since MCU only offered VP9, and current is VP10, the m-line should be rejected. Do we need to change this ? Is it OK for browser to respond with VP9.
Previously I've heard people say "the non-JSEP endpoint can do whatever it wants with codecs." For example, in the thread for issue .
It is definitely OK for the browser to accept the VP9 in the updated offer and I would go further and say that it must accept VP9 in such an updated offer if it is capable of doing so. The spec should make it clear that browsers MUST accept such codec changes in updated offers.
If we solve this, should resolve.
Originally raised by Magnus. If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description. I think this is a bad advice. I think it should say that if this is the case, PT should not be used to try to determine which m= section it belongs to. I think wrongly attributing a packet is worse than dropping it in cases where the information is incomplete. This rule can result in that one associate an SSRC with the wrong m= section.
there is another bug on this too - I agree we could change this
Obsoleted by events - moved to BUNDLE
With changes above

media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences. <ins> The media formats in the answer MAY include codecs present in the offer that were discarded in a previous offer/answer exchange. This is necessary for compatibility with third- party call control and SIP use cases. </ins> Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in I-D.ietf- rtcweb-audio(see Section 3) and I-D.ietf-rtcweb-video(see The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST only include codecs present in the most recent answer which have not been excluded by the codec preferences of the associated  <ins> transceiver.  Note that non-JSEP endpoints are not subject to these restrictions, and might offer media formats that were not present in the most recent answer, as specified in RFC3264, Section 8.  Therefore, JSEP endpoints MUST be prepared to receive such offers. </ins> The media formats on the m= line MUST be generated in the same order as in the current local description. If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences or  <ins> not present in the offer.  Note that non-JSEP endpoints are not subject to this restriction, and might add media formats in the answer that are not present in the offer, as specified in RFC3264, Section 6.1.  Therefore, JSEP endpoints MUST be prepared to receive such answers. </ins> Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in I-D.ietf-


implementations will not transmit non-square pixels, but SHOULD receive and render such video with the correct aspect ratio. However, sample aspect ratio has no impact on the size negotiation <del> described below; all dimensions assume square pixels. </del>  3.6.1.

LGTM
LGTM
The text says "all dimensions assume square pixels". Given the affordance for non-square pixels elsewhere, I think this should say "all dimensions are measured in pixels, whether square or not".
Agreed.

implementations will not transmit non-square pixels, but SHOULD receive and render such video with the correct aspect ratio. However, sample aspect ratio has no impact on the size negotiation  <ins> described below; all dimensions are measured in pixels, whether square or not. </ins> 3.6.1.


3.4.2. RtpSenders allow the application to control how RTP media is sent.  3.4.3. <del> RtpReceivers allows the application to control how RTP media is received. </del>  3.5. If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media are available to </del>  send, this will result in the starting of media transmission. 4.1.9. If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media are available to </del>  send, this will result in the starting of media transmission. 4.1.10.

Attempts to address issue . Also changed "control" to "inspect" in RtpReceiver description, since an RtpReceiver is readonly and doesn't let an application control anything.
LGTM
Originally raised by Christer Section 3.4.1 talks about ³RtpTranceivers², ³RtpSenders² and ³RtpReceivers². 1) I think they should be introduced in their own section (not within the Session Description Protocol section). 2) I think it should be explained what an RtpXXX really is. At a minimum there should be a reference to the appropriate W3C document. But, as there is text on how they related to SDP m- lines etc, 1 or 2 sentences describing what they are would also be useful.
Section 3.4.1 is its own section, and explains what the RtpTransceiver is. Agree that Sections 3.4.2/3.4.3 (on senders/receivers) could be expanded somewhat. NAME FYI
Resolved by

3.4.2. RtpSenders allow the application to control how RTP media is sent. <ins> An RtpSender is conceptually responsible for the outgoing RTP stream(s) described by an m= section.  This includes encoding the attached MediaStreamTrack, sending RTP media packets, and generating/ processing RTCP for the outgoing RTP streams(s). </ins> 3.4.3.  <ins> RtpReceivers allow the application to inspect how RTP media is received.  An RtpReceiver is conceptually responsible for the incoming RTP stream(s) described by an m= section.  This includes processing received RTP media packets, decoding the incoming stream(s) to produce a remote MediaStreamTrack, and generating/ processing RTCP for the incoming RTP stream(s). </ins> 3.5. If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final),  <ins> and the media directions are compatible, and media is available to </ins> send, this will result in the starting of media transmission. 4.1.9. If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final),  <ins> and the media directions are compatible, and media is available to </ins> send, this will result in the starting of media transmission. 4.1.10.