jiebi/CodeConvo huggingface dataset:
Change:
Also making the "need-ice-restart" bit get set for ANY policy change, rather than just more restrictive changes, to go along with this warning.
Needs merge to master
LGTM
lgtm
LGTM
If a candidate is in use and Policy changes such that this candidate is not longer allowed, do we have text that says to stop using that candidate and restart ice?
yes, I think this is covered in the setConfiguration text. Do you want to look and see if there is anything missing?
The current text says no ICE restart happens here, and it's not clear it should, since the cat is already out of the bag. Eric is going to look at adding a warning mentioning this.
Discussed in Kirkland and we think it is simplest to trigger ICE restart regardless of which way the policy changes.

Discussion:
a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. <del> Any changes to the ICE candidate policy also affect the next gathering phase.  If the policy is being made more liberal (i.e., more permitted candidates), and an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set.  If the policy is being made more strict, no ICE restart is needed, and the bit will not be set.  Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </del> <ins> Any change to the ICE candidate policy affects the next gathering phase.  If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set.  Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </ins> Any changes to the ICE candidate pool size take effect immediately; if increased, additional candidates are pre-gathered;
Change:
Change position of initial paragraph on handling of bundled m= sections; simplify some text; remove discussion of ICE restart option in answers.
NAME FYI

Discussion:
Note that gathering phases only gather the candidates needed by new/recycled/restarting m= lines; other m= lines continue to use <del> their existing candidates. </del> <ins> their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= lines referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp-bundle-negotiation. </ins> 3.4.2.

supply them to its ICE Agent.  This triggers the ICE Agent to start using the new remote candidates for connectivity checks. <del> When BUNDLE is in use, candidates (both in-SDP and trickle) are only exchanged for and associated with the m= section referenced by the sender's BUNDLE-tag, as described in I-D.ietf-mmusic-sdp-bundle- negotiation </del> 3.4.2.1. As with session descriptions, the syntax of the IceCandidate object

Each "a=mid" line MUST stay the same. <del> If the m= section is not bundled into another m= section (i.e., it is either not bundled or it possesses the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless </del> <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless </ins> the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= <del> section is bundled into another m= section, it MUST NOT have any ICE credentials. </del> <ins> 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, for each candidate that has been gathered during the most recent gathering

values MUST be used, as described in the initial answer section above. <del> If the m= section is not bundled into another m= section (i.e., it is either not bundled or it possesses the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= section is bundled into another m= section, it MUST NOT contain any ICE credentials. </del> <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in RFC5245, Section 9.2.1.1.  If the 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, for each candidate that has been gathered during the most recent gathering
Change:
Seems like an important distinction. I went with "MUST NOT emit", though "MUST omit" could work too.
wow lgtm

Discussion:
the remote VAD algorithm. If the "VoiceActivityDetection" option is specified, with a value of <del> "false", the browser MUST NOT omit "CN" codecs.  For codecs that have </del> <ins> "false", the browser MUST NOT emit "CN" codecs.  For codecs that have </ins> their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired.  For example, when
Change:
Specifically, "addIceCandidate" and "Applying a Remote Description".
I'm fine this however it ends up. I will r+ this and people can merge it once it is done. Thanks
Just adding a still LGTM
lgtm once my comment from today is addressed

Discussion:
and/or pending remote description according to the rules defined for Trickle ICE.  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 all media descriptions in the last remote description. </ins> This call will result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity being established.

candidates, as described in Section 5.7 of RFC5245 and start connectivity checks with the appropriate credentials. <ins> If an "a=end-of-candidates" attribute is present, process the end- of-candidates indication as described in I-D.ietf-ice-trickle Section 11. </ins> If the media section proto value indicates use of RTP: [TODO: header extensions]
Change:
This is all strictly editorial and I think if either of you give it a quick scan, you can just merge it
LGTM - will merge

Discussion:
are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- <del> D.shieh-rtcweb-ip-handling. </del> <ins> D.ietf-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime

As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to <del> at most 360p.  In this case, the implemention would generate this </del> <ins> at most 360p.  In this case, the implementation would generate this </ins> attribute: a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0]

Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level. </del> <ins> TODO: identity, rtcp-rsize, rtcp-mux, and any other attributes valid at session level. </ins> Once all the session-level lines have been parsed, processing continues with the lines in media sections.

If present, a single "a=setup" line is parsed as specified in RFC4145, Section 4, and the setup value is stored. <del> If the "m=" proto value indicates use of RTP, as decribed in the </del> <ins> If the "m=" proto value indicates use of RTP, as described in the </ins> sec.profile-names section above, the following attribute lines MUST be processed:

extension, as described in I-D.ietf-mmusic-msid, Section 3.2. For each specified payload type, establish a mapping between <del> the payload type ID and the actual media format, as descibed in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </del> <ins> the payload type ID and the actual media format, as described in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload
Change:
Replaces URL
NAME this just flattens all the changes in last PR to the final thin and puts it onto new base with no merge issue. Still needs changes to align with new sender / receiver objects
PTAL
LGTM
LGTM

Discussion:
D.ietf-ice-trickle, Section 4, is only included if such an option was present in the offer. <del> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one referenced RtpTransceiver, a group of type "LS" MUST be added that contains the mid values for each RtpTransceiver added with that MediaStream.  In some cases this may result in adding a mid to a given LS group that was not in that LS group in the associated offer.  Although this is not allowed by RFC5888, it is allowed when implementing this specification.  [[OPEN ISSUE: This is still under discussion.  See: https://github.com/rtcweb-wg/jsep/issues/162.]] </del> <ins> The next step is to generate session-level lip sync groups as defined in RFC5888, Section 7.  For each group of type "LS" present in the offer, determine which of the local RtpTransceivers identified by that group's mid values reference a common local MediaStream (as specified in the addTrack and addTransceiver methods).  If at least two such RtpTransceivers exist, a group of type "LS" with the mid values of these RtpTransceivers MUST be added.  Otherwise, this indicates a difference of opinion between the offerer and answerer regarding lip sync status, and as such, the offered group MUST be ignored and no corresponding "LS" group generated. </ins> The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in RFC3264, Section 6.  For
Change:
LG modulo comment
LGTM
Split from URL Something for the "Setting a remote description section"
(For clarity, the proper outcome is for the answerer to reject the m= line in the offer with no matching codecs, as discussed in IETF 95)
NAME asked about how the sendonly case should be handled. The minutes say but I'm not sure if we need to add any text for this. Peter, do you recall the details here?

Discussion:
RFC3264, Section 6., and further processing for this m= section can be skipped. <del> Provided that is not the case, 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: </del> <ins> 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: </ins> The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates
Change:
Fixes URL
fixed the typos - LGTM
The spec is clear on that the MID has precedence over m= line index when coordinating candidates with m= lines. But it is not clear on what would happen if the MID has a value can't be matched to an m= line (while potentially the m= line index is valid).
I suspect that should result in some sort of invalid value error.
Right, I think we should return an error from addIceCandidate in this case. If you wanted a different result, you should have used the correct mid :-)
I agree to the above, just want it clarified.

Discussion:
The addIceCandidate method provides a remote candidate to the ICE Agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for <del> Trickle ICE.  Connectivity checks will be sent to the new candidate. </del> <ins> Trickle ICE.  If the MID, m-line index, or candidate string provided in the ICE candidate is invalid, an error is generated.  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
Change:
I'd suggest that we try to move forward with this and leave the exact ruleset as an open issue pending Peter's investigation.
OK, I updated the PR to have the MST text. I think we had Cullen's r+ so ready to merge?
Merging this and will file an issue on the algorithm.

Discussion:
4.1.2. <del> [TODO] </del> <ins> The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other tracks in the same MediaStream, so that they can be added to the same "LS" group when creating an offer or answer.  addTrack attempts to minimize the number of transceivers as follows: The track will be attached to the first compatible transceiver (of the same media type) which has never had a direction of "sendonly" or "sendrecv".  If no such transceiver exists, then one will be constructed as described in sec.addTransceiver. </ins> 4.1.3.
Change:
Also restructured the "rejecting media descriptions" sections since there are now four things that can cause it to be rejected.
I think this does a good job clarifying these edge cases and is the behavior we want.
lgtm
LGTM
I just realized this may not be complete. Even if max-bundle is used, shouldn't one media description be accepted? This would ensure the same result regardless of whether the max-bundle endpoint is the offerer or answerer. It would also prevent a remote offer from being rejected if it didn't include a "BUNDLE" group simply because there was only one media description.
Deficiencies should be addressed by this PR (apologies for missing them on the first pass): URL

Discussion:
all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints. </del> <ins> endpoints.  When acting as answerer, the implementation will reject any m= section that is not in a bundle group. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST

The browser will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather.  When <del> acting as answerer, the browser will reject any m= section that does not provide an "a=rtcp-mux" attribute. </del> <ins> acting as answerer, the implementation will reject any m= section that does not contain an "a=rtcp-mux" attribute. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to

there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. <del> For each offered m= section, if the associated RtpTransceiver has been stopped, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6., and further processing for this m= section can be skipped. For each offered m= section, if no supported codec is present in the offer, the corresponding m= section in the answer MUST be marked as </del> <ins> For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as </ins> rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6., and further processing for this m= section can <del> be skipped. </del> <ins> be skipped: The associated RtpTransceiver has been stopped. No supported codec is present in the offer. The bundle policy is "max-bundle" and the m= section is not in a bundle group. The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute. </ins> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the
Change:
If a non-bundle offer is received, and "max-bundle" is used, the first m= section should be accepted and all others rejected. This will ensure the same result whether or not the "max-bundle" endpoint is the offerer or answerer (ignoring some unlikely corner cases), and will prevent a lone media description from being rejected if the remote offer didn't contain a bundle group simply because it wasn't necessary. Also added equivalent rules for the "balanced" bundle policy.
This LGTM
This isn't exactly what I had in mind for 'balanced', but this might not be an issue in practice. If the answerer needs to handle multiple m= lines that are unbundled, it can set max-compat.
lgtm

Discussion:
The result is that if there are N distinct media types, then candidates will be gathered for for N media streams.  This policy balances desire to multiplex with the need to ensure basic audio <del> and video can still be negotiated in legacy cases. </del> <ins> and video can still be negotiated in legacy cases.  When acting as answerer, if there is no bundle group in the offer, the implementation will reject all but the first m= section of each type. </ins>

all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints.  When acting as answerer, the implementation will reject any m= section that is not in a bundle group. </del> <ins> endpoints.  When acting as answerer, if there if no bundle group in the offer, the implementation will reject all but the first m= section. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST

No supported codec is present in the offer. <del> The bundle policy is "max-bundle" and the m= section is not in a bundle group. </del> <ins> The bundle policy is "max-bundle", the m= section is not in a bundle group, and this is not the first m= section. The bundle policy is "balanced", the m= section is not in a bundle group, and this is not the first m= section for this media type. </ins> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.
Change:
This is an update of Fippo's
See PR
LGTM
lgtm with comma

Discussion:
TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 The 50 is based on 50 packets per second, the 40 is based on an <del> estimate of total header size, the 1000 is to change the unit from kbps to bps and the 0.95 is to allocate 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </del> <ins> estimate of total header size, the 1000 changes the unit from kbps to bps (as required by TIAS) and the 0.95 is to allocate 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.
Change:
Oh, I see: Issue .
Rewrote to remove some typos, and overall simplification
From the interim, there was some confusion on whether ignoring a=rtcp prohibited unmuxed RTCP; the intention here was that a=rtcp is superfluous because the RTCP port/IP information is carried in a=candidate lines. Suggest we just spell out this rationale explicitly.
That is, unless we use a=rtcp:0 to indicate exclusive.
This appears to be section 5.6.2's statement: If present, a single "a=rtcp" attribute MUST be parsed as specified in [RFC3605], Section 2.1, but its value is ignored. (This is no longer on page 52) Would work?

Discussion:
flagged and stored. If present, a single "a=rtcp" attribute MUST be parsed as <del> specified in RFC3605, Section 2.1, but its value is ignored. </del> <ins> specified in RFC3605, Section 2.1, but its value is ignored, as this information is superfluous when using ICE. </ins> If present, a single "a=msid" attribute MUST be parsed as specified in I-D.ietf-mmusic-msid, Section 3.2, and its value
Change:
Not ready yet.
LGTM with editorial comment as above.
Please apply same presence/absence treatment for all
http://rtcweb-URL [TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level.]
(session-level, specifically)

Discussion:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> TODO: identity, rtcp-rsize, rtcp-mux, and any other attributes valid at session level. </del> Once all the session-level lines have been parsed, processing continues with the lines in media sections.

specified in RFC5761, Section 5.1.1, and its presence or absence flagged and stored. <ins> If present, a single "a=rtcp-mux-only" attribute MUST be parsed as specified in I-D.ietf-mmusic-mux-exclusive, Section 3, and its presence or absence flagged and stored. </ins> If present, a single "a=rtcp-rsize" attribute MUST be parsed as specified in RFC5506, Section 5, and its presence or absence flagged and stored.
Change:
Can you separate this from the ICE changes that are also in this PR?
Oops, yeah
NAME PTAL
LGTM
See URL

Discussion:
the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. <del> A direction attribute for the associated RtpTransceiver as described by sec.offer-dirattr. </del> <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each supported codec, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The audio and video codecs that

setting of the "vad" value in the signaling of the client to mixer audio level header extension described in RFC6464, Section 4. <del> 5.2.4. RFC3264 direction attributes (defined in Section 6.1) in offers are chosen according to the states of the RtpSender and RtpReceiver of a given RtpTransceiver, as follows: </del> 5.3. When createAnswer is called, a new SDP description must be created

the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. <del> A direction attribute for the associated RtpTransceiver described by sec.answer-dirattr. </del> <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and

VoiceActivityDetection to true would result in an answer with CN codecs and "usedtx=0"). <del> 5.3.4. RFC3264 direction attributes (defined in Section 6.1) in answers are chosen according to the direction attribute in the remote offer and the states of the RtpSender and RtpReceiver of the corresponding RtpTransceiver, as follows: </del> 5.4. When a SessionDescription is supplied to setLocalDescription, the
Change:
NAME See above
LGTM when outstanding comment addressed
JSEP currently has this: createDataChannel [TODO] We need this text before WGLC, so it's being added to the punchlist.

Discussion:
4.1.4. <del> [TODO] </del> <ins> The createDataChannel method creates a data channel and attaches it to the PeerConnection.  If no data channel currently exists for this PeerConnection, then a new offer/answer exchange is required.  All data channels on a given PeerConnection share the same SCTP/DTLS association and therefore the same m= section, so subsequent creation of data channels does not have any impact on the JSEP state. The createDataChannel method also includes a number of arguments which are used by the PeerConnection (e.g., maxPacketLifetime) but are not reflected in the SDP and do not affect the JSEP state. </ins> 4.1.5.