jiebi/CodeConvo huggingface dataset:
5.1.3. For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ <del> RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of </del> <ins> RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of </ins> these two profiles for each media m= line they produce in an offer. <del> For data m= sections, JSEP endpoints must support both the "UDP/TLS/ SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two </del> <ins> For data m= sections, JSEP endpoints must support both the "UDP/DTLS/ SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two </ins> profiles for each data m= line they produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually
compatible mode and use AVP timing, i.e., "trr-int=4". For data m= sections, JSEP endpoints MUST support receiving the <del> "UDP/ TLS/SCTP", "TCP/TLS/SCTP", or "DTLS/SCTP" (for backwards </del> <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
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 <del> default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as </del> <ins> default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as </ins> specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport.
Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" <del> and the <proto> field MUST be set to "UDP/TLS/SCTP" if the default candidate uses UDP transport, or "TCP/TLS/SCTP" if the default </del> <ins> and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default </ins> candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in
BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- bundle-negotiation.  Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will <del> offer a single BUNDLE group across all media sections.  However, by specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non-BUNDLE-aware endpoint. When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: </del> <ins> offer a single BUNDLE group across all media section; use of this single transport is contingent upon the answerer accepting BUNDLE. However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non- BUNDLE-aware endpoint.  When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: </ins> The first media section of each type (audio, video, or application) will contain transport parameters, which will allow
present, but an "AS" value is specified, generate a "TIAS" value using this formula: <del> TIAS = AS * 0.95 - 50 * 40 * 8 </del> <ins> TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 </ins> The 50 is based on 50 packets per second, the 40 is based on an <del> estimate of total header size, 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 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". </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.
The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver <del> that has been added to the PeerConnection via the addTrack, addTransceiver, and setRemoteDescription methods.  [[OPEN ISSUE: move discussion of setRemoteDescription to the subsequent-offer section.]] This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTranscievers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . </del> <ins> that has been added to the PeerConnection.  This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique
as defined in RFC5245, Section 4.1.1, unless it has been marked as bundle-only. <del> Or, if the ICE ufrag and password values have changed, trigger the ICE Agent to start an ICE restart and begin gathering new candidates for the media section, as defined in RFC5245, Section 9.1.1.1, unless it has been marked as bundle-only. </del> <ins> Or, if the ICE ufrag and password values have changed, and it has not been marked as bundle-only, trigger the ICE Agent to start an ICE restart, and begin gathering new candidates for the media section as described in RFC5245, Section 9.1.1.1.  If this description is an answer, also start checks on that media section as defined in RFC5245, Section 9.3.1.1. </ins> If the media section proto value indicates use of RTP:
parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. <del> If the description is of type "offer", and the ICE ufrag or password changed from the previous remote description, as described in Section 9.1.1.1 of RFC5245, mark that an ICE restart is needed. </del> <ins> If the ICE ufrag or password changed from the previous remote description, then an ICE restart is needed, as described in Section 9.1.1.1 of RFC5245 If the description is of type "offer", mark that an ICE restart is needed.  If the description is of type "answer" and the current local description is also an ICE restart, then signal the ICE agent to begin checks as described in Section 9.3.1.1 of RFC5245.  An answer MUST change the ufrag and password in an answer if and only if ICE is restarting, as described in Section 9.2.1.1 of RFC5245. </ins> Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their
4.1.3. <del> [TODO] </del> <ins> The addTransceiver method adds a new RTPTransceiver to the PeerConnection.  If a MediaStreamTrack argument is provided, then the transceiver will be configured with that media type and the track will be attached to the transceiver.  Otherwise, the application MUST explicitly specify the type; this mode is useful for creating recvonly transceivers as well as for creating transceivers to which a track can be attached at some later point.  At the time of creation, the application can also specify a transceiver direction attribute, a set of MediaStreams which the transceiver is associated with (allowing LS group assignments), and a set of encodings for the media (used for simulcast as desccribed in sec.simulcast). </ins> 4.1.4.
For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of <del> RFC5285.  If any indicated RTP header extension is unknown, this MUST result in an error. </del> <ins> RFC5285.  If any indicated RTP header extension is not supported, this MUST result in an error. </ins> 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. <del> For each specified payload type, establish a mapping between 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. </del> <ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in RFC3264, Section 6.1.  If any indicated media format is not supported, 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
section by setting the value of the RtpTransceiver's mid 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 type ID and the actual media format.  [TODO - Justin to add more to explain mapping.]  If any indicated payload type is unknown, it MUST be ignored.  [TODO: should fail on answers] </del> <ins> For each specified media format that is also supported by the local implementation, establish a mapping between the specified payload type and the media format, as described in RFC3264, Section 6.1.  Specifically, this means that the implementation records the payload type to be used in outgoing RTP packets when sending each specified media format, as well as the relative preference for each format that is indicated in their ordering.  If any indicated media format is not supported by the local implementation, it MUST be ignored. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload <del> type, as described in RFC4588.  If any referenced primary payload types are not present, this MUST result in an error. </del> <ins> type, as described in RFC4588, Section 4.  If any referenced primary payload types are not present, this MUST result in an error. </ins> For each specified fmtp parameter that is supported by the <del> local implementation, enable them on the associated payload types. </del> <ins> local implementation, enable them on the associated media formats. For each specified RTP header extension that is also supported by the local implementation, establish a mapping between the extension ID and URI, as described in RFC5285, Section 5. Specifically, this means that the implementation records the extension ID to be used in outgoing RTP packets when sending each specified header extension.  If any indicated RTP header extension is not supported by the local implementation, it MUST be ignored. </ins> For each specified RTCP feedback mechanism that is supported by <del> the local implementation, enable them on the associated payload types. </del> <ins> the local implementation, enable them on the associated media formats. </ins> For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending
[TODO: handling of CN, telephone-event, "red"] <del> If the media section if of type audio: </del> <ins> If the media section is of type audio: </ins> For any specified "ptime" value, configure the available <del> payload types to use the specified packet size.  If the specified size is not supported for a payload type, use the </del> <ins> media formats to use the specified packet size.  If the specified size is not supported for a media format, use the </ins> next closest value instead. Finally, if this description is of type "pranswer" or "answer",
If the media section proto value indicates use of RTP: <ins> If the media section references any media formats, RTP header extensions, or RTCP feedback mechanisms that were not present 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 any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in RFC5761, Section 5.1.3.  Otherwise,
the RTCP transmission for this media section to use reduced- size RTCP, as specified in RFC5506. <ins> [TODO: enable appropriate rtcp-fb mechanisms] </ins> If the directional attribute in the answer is of type "sendrecv" or "sendonly", prepare to start transmitting media <del> using the specified primary SSRC and one of the selected payload types, once the underlying transport layers have been established.  If RID values are specified, include the RID header extension in the RTP streams, as indicated in I-D.ietf- mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic- sdp-simulcast, Section 6.2.2.  If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </del> <ins> using the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, once the underlying transport layers have been established.  [TODO: add discusssion of RED/FEC/RTX/CN] The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams.  Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the RID header extension has been negotiated, and RID values are specified, include the RID header extension in the outgoing RTP streams, as indicated in I-D.ietf-mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic-sdp-simulcast, Section 6.2.2. If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </ins> If the media section proto value indicates use of SCTP:
Each "a=mid" line MUST stay the same. <del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. </del> <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same unless the "IceRestart" option (sec.options-handling was specified.  Note that it's not clear why you would actually want to do this, since at this point ICE has not yet started and is thus unlikely to need a restart. </ins> For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same.
resources allocated by the caller can be released, now that the exact session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. <del> Provisional answers, on the other hand, do no such deallocation results; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> Provisional answers, on the other hand, do no such deallocation; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack
transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below. <ins> Note that while setDirection sets the direction attribute of the transceiver immediately (sec.transceiver-direction), this attribute does not immediately affect whether the transceiver's RtpSender will send or its RtpReceiver will receive.  The direction in effect is represented by the currentDirection attribute, which is only updated when an answer is applied. </ins> 4.2.4. The direction method returns the last value passed into setDirection.
If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.1. <del> If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. </del> <ins> If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error. </ins> For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of
local description is supplied, and the number of transports currently in use does not match the number of transports needed by the local description, the PeerConnection will create transports as needed and <del> begin gathering candidates for them. </del> <ins> either withdraw an appropriate number of ICE candidates from the candidate pool or begin gathering candidates if sufficient pre- gathered candidates are not available. </ins> If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final),
The 50 is based on 50 packets per second, the 40 is based on an 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 <del> 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </del> <ins> 5% to RTCP.  "TIAS" is used in preference to "AS" because it provides more accurate control of bandwidth. </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.
If the media section has been rejected (i.e. port is set to zero in the answer), stop any reception or transmission of media for <del> this section, and discard any associated ICE components, as </del> <ins> this section, and, if there was no accepted media section bundled with this media section, discard any associated ICE components, as </ins> described in Section 9.2.1.3 of RFC5245. If the remote DTLS fingerprint has been changed or the dtls-id has
session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. Provisional answers, on the other hand, do no such deallocation; as a <del> result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> result, multiple dissimilar provisional answers, with their own codec choices, transport parameters, etc., can be received and applied during call setup.  Note that the final answer itself may be different than any received provisional answers. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack
JSEP implementations must comply with the specifications listed below that govern the creation and processing of offers and answers. <del> The first set of specifications is the "mandatory-to-implement" set. All implementations must support these behaviors, but may not use all of them if the remote side, which may not be a JSEP endpoint, does not support them. The second set of specifications is the "mandatory-to-use" set.  The local JSEP endpoint and any remote endpoint must indicate support for these specifications in their session descriptions. </del> 5.1.1. <del> Implementations of JSEP MUST conform to I-D.ietf-rtcweb-rtp-usage. This list of mandatory-to-implement specifications is derived from the requirements outlined in that document and from I-D.ietf-rtcweb- security-arch. RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RFC5764, TCP/DTLS/RTP/SAVPF RFC7850, "UDP/DTLS/SCTP" I-D.ietf- mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE implementation MUST be a Full implementation, not a Lite implementation. RFC5763 MUST be implemented to signal DTLS certificate fingerprints. RFC5888 MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and MediaStreamTracks in a standard way. The bundle mechanism in I-D.ietf-mmusic-sdp-bundle-negotiation MUST be supported to signal the ability to multiplex RTP streams on a single UDP port, in order to avoid excessive use of port number resources. The SDP attributes of "sendonly", "recvonly", "inactive", and "sendrecv" from RFC4566 MUST be implemented to signal information about media direction. RFC5576 MUST be implemented to signal RTP SSRC values and grouping semantics. RFC4585 MUST be implemented to signal RTCP based feedback. RFC5761 MUST be implemented to signal multiplexing of RTP and RTCP. RFC5506 MUST be implemented to signal reduced-size RTCP messages. RFC4588 MUST be implemented to signal RTX payload type associations. RFC3556 MUST be supported for control of RTCP bandwidth limits. The SDES SRTP keying mechanism from RFC4568 MUST NOT be implemented, as discussed in I-D.ietf-rtcweb-security-arch. As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines. 5.1.2. </del> All session descriptions handled by JSEP implementations, both local and remote, MUST indicate support for the following specifications. If any of these are absent, this omission MUST be treated as an
DTLS RFC6347 or DTLS-SRTP RFC5763, MUST be used, as appropriate for the media type, as specified in <del> 5.1.3. </del> <ins> The SDES SRTP keying mechanism from RFC4568 MUST NOT be used, as discussed in I-D.ietf-rtcweb-security-arch. 5.1.2. </ins> <del> For media m= sections, JSEP implementations MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer.  For data m= sections, implementations MUST support both the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two profiles for each data m= line they </del> <ins> For media m= sections, JSEP implementations MUST support the "UDP/TLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they </ins> produce in an offer.  Because ICE can select either TCP or UDP <del> transport depending on network conditions, both advertisements are </del> <ins> transport depending on network conditions, this advertisement is </ins> consistent with ICE eventually selecting either either UDP or TCP. Unfortunately, in an attempt at compatibility, some endpoints
section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <del> 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. </del> <ins> If the m= section is not bundled into another m= section, its "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate, as indicated in RFC5761, Section 5.1.3.  If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial offer 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
If the type is not correct for the current state, processing MUST stop and an error MUST be returned. <ins> The SessionDescription is then checked to ensure that its contents are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in sec.modifying-sdp; otherwise, processing MUST stop and an error MUST be returned. </ins> Next, the SessionDescription is parsed into a data structure, as described in the sec.parsing-a-desc section below.  If parsing fails for any reason, processing MUST stop and an error MUST be