JavaScript Session Establishment Protocol (JSEP)
draft-uberti-rtcweb-rfc8829bis-05
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9429.
|
|
---|---|---|---|
Authors | Justin Uberti , Cullen Fluffy Jennings , Eric Rescorla | ||
Last updated | 2024-04-11 (Latest revision 2023-09-21) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Proposed Standard | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-02)
by Joel Halpern
Ready w/issues
OPSDIR Last Call review
(of
-02)
by Qin Wu
Has issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Sean Turner | ||
Shepherd write-up | Show Last changed 2022-03-09 | ||
IESG | IESG state | Became RFC 9429 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | Murray Kucherawy | ||
Send notices to | sean@sn3rd.com | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | No IANA Actions |
draft-uberti-rtcweb-rfc8829bis-05
Uberti, et al. Expires 24 March 2024 [Page 61] RFC 8829 JSEP September 2023 5.8.1. Session-Level Parsing First, the session-level lines are checked and parsed. These lines MUST occur in a specific order, and with a specific syntax, as defined in [RFC4566], Section 5. Note that while the specific line types (e.g., "v=", "c=") MUST occur in the defined order, lines of the same type (typically "a=") can occur in any order. The following non-attribute lines are not meaningful in the JSEP context and MAY be discarded once they have been checked. * The "c=" line MUST be checked for syntax, but its value is only used for ICE mismatch detection, as defined in [RFC8445], Section 5.4. Note that JSEP implementations should never encounter this condition because ICE is required for WebRTC. * The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines MUST be checked for syntax, but their values are not otherwise used. The remaining non-attribute lines are processed as follows: * The "v=" line MUST have a version of 0, as specified in [RFC4566], Section 5.1. * The "o=" line MUST be parsed as specified in [RFC4566], Section 5.2. * The "b=" line, if present, MUST be parsed as specified in [RFC4566], Section 5.8, and the bwtype and bandwidth values stored. Finally, the attribute lines are processed. Specific processing MUST be applied for the following session-level attribute ("a=") lines: * Any "a=group" lines are parsed as specified in [RFC5888], Section 5, and the group's semantics and mids are stored. * If present, a single "a=ice-lite" line is parsed as specified in [RFC8839], Section 5.3, and a value indicating the presence of ice-lite is stored. * If present, a single "a=ice-ufrag" line is parsed as specified in [RFC8839], Section 5.4, and the ufrag value is stored. * If present, a single "a=ice-pwd" line is parsed as specified in [RFC8839], Section 5.4, and the password value is stored. Uberti, et al. Expires 24 March 2024 [Page 62] RFC 8829 JSEP September 2023 * If present, a single "a=ice-options" line is parsed as specified in [RFC8839], Section 5.6, and the set of specified options is stored. * Any "a=fingerprint" lines are parsed as specified in [RFC8122], Section 5, and the set of fingerprint and algorithm values is stored. * If present, a single "a=setup" line is parsed as specified in [RFC4145], Section 4, and the setup value is stored. * If present, a single "a=tls-id" line is parsed as specified in [RFC8842], Section 5, and the attribute value is stored. * Any "a=identity" lines are parsed and the identity values stored for subsequent verification, as specified in [RFC8827], Section 5. * Any "a=extmap" lines are parsed as specified in [RFC5285], Section 5, and their values are stored. Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize. As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. Once all the session-level lines have been parsed, processing continues with the lines in "m=" sections. 5.8.2. Media Section Parsing Like the session-level lines, the media section lines MUST occur in the specific order and with the specific syntax defined in [RFC4566], Section 5. The "m=" line itself MUST be parsed as described in [RFC4566], Section 5.14, and the <media>, <port>, <proto>, and <fmt> values stored. Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: * As with the "c=" line at the session level, the "c=" line MUST be parsed according to [RFC4566], Section 5.7, but its value is not used. * The "b=" line, if present, MUST be parsed as specified in [RFC4566], Section 5.8, and the bwtype and bandwidth values stored. Uberti, et al. Expires 24 March 2024 [Page 63] RFC 8829 JSEP September 2023 Specific processing MUST also be applied for the following attribute lines: * If present, a single "a=ice-ufrag" line is parsed as specified in [RFC8839], Section 5.4, and the ufrag value is stored. * If present, a single "a=ice-pwd" line is parsed as specified in [RFC8839], Section 5.4, and the password value is stored. * If present, a single "a=ice-options" line is parsed as specified in [RFC8839], Section 5.6, and the set of specified options is stored. * Any "a=candidate" attributes MUST be parsed as specified in [RFC8839], Section 5.1, and their values stored. * Any "a=remote-candidates" attributes MUST be parsed as specified in [RFC8839], Section 5.2, but their values are ignored. * If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in [RFC8840], Section 8.1, and its presence or absence flagged and stored. * Any "a=fingerprint" lines are parsed as specified in [RFC8122], Section 5, and the set of fingerprint and algorithm values is stored. If the "m=" <proto> value indicates use of RTP, as described in Section 5.1.2 above, the following attribute lines MUST be processed: * The "m=" <fmt> value MUST be parsed as specified in [RFC4566], Section 5.14, and the individual values stored. * Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in [RFC4566], Section 6, and their values stored. * If present, a single "a=ptime" line MUST be parsed as described in [RFC4566], Section 6, and its value stored. * If present, a single "a=maxptime" line MUST be parsed as described in [RFC4566], Section 6, and its value stored. * If present, a single direction attribute line (e.g., "a=sendrecv") MUST be parsed as described in [RFC4566], Section 6, and its value stored. * Any "a=ssrc" attributes MUST be parsed as specified in [RFC5576], Section 4.1, and their values stored. Uberti, et al. Expires 24 March 2024 [Page 64] RFC 8829 JSEP September 2023 * Any "a=extmap" attributes MUST be parsed as specified in [RFC5285], Section 5, and their values stored. * Any "a=rtcp-fb" attributes MUST be parsed as specified in [RFC4585], Section 4.2, and their values stored. * If present, a single "a=rtcp-mux" attribute MUST be parsed as specified in [RFC5761], Section 5.1.3, and its presence or absence flagged and stored. * If present, a single "a=rtcp-mux-only" attribute MUST be parsed as specified in [RFC8858], Section 3, and its presence or absence flagged and stored. * 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. * If present, a single "a=rtcp" attribute MUST be parsed as specified in [RFC3605], Section 2.1, but its value is ignored, as this information is superfluous when using ICE. * If present, "a=msid" attributes MUST be parsed as specified in [RFC8830], Section 3.2, and their values stored, ignoring any "appdata" field. If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. * Any "a=imageattr" attributes MUST be parsed as specified in [RFC6236], Section 3, and their values stored. * Any "a=rid" lines MUST be parsed as specified in [RFC8851], Section 10, and their values stored. * If present, a single "a=simulcast" line MUST be parsed as specified in [RFC8853], and its values stored. Otherwise, if the "m=" <proto> value indicates use of SCTP, the following attribute lines MUST be processed: * The "m=" <fmt> value MUST be parsed as specified in [RFC8841], Section 4.3, and the application protocol value stored. * An "a=sctp-port" attribute MUST be present, and it MUST be parsed as specified in [RFC8841], Section 5.2, and the value stored. Uberti, et al. Expires 24 March 2024 [Page 65] RFC 8829 JSEP September 2023 * If present, a single "a=max-message-size" attribute MUST be parsed as specified in [RFC8841], Section 6, and the value stored. Otherwise, use the specified default. Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize. As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. 5.8.3. Semantics Verification Assuming that parsing completes successfully, the parsed description is then evaluated to ensure internal consistency as well as proper support for mandatory features. Specifically, the following checks are performed: * For each "m=" section, valid values for each of the mandatory-to- use features enumerated in Section 5.1.1 MUST be present. These values MAY be either present at the media level or inherited from the session level. - ICE ufrag and password values, which MUST comply with the size limits specified in [RFC8839], Section 5.4. - A tls-id value, which MUST be set according to [RFC8842], Section 5. If this is a re-offer or a response to a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. - A DTLS setup value, which MUST be set according to the rules specified in [RFC5763], Section 5 and MUST be consistent with the selected role of the current DTLS connection, if one exists and is being continued. - DTLS fingerprint values, where at least one fingerprint MUST be present. * All rid-ids referenced in an "a=simulcast" line MUST exist as "a=rid" lines. * Each "m=" section is also checked to ensure that prohibited features are not used. Uberti, et al. Expires 24 March 2024 [Page 66] RFC 8829 JSEP September 2023 * If the RTP/RTCP multiplexing policy is "require", each "m=" section MUST contain an "a=rtcp-mux" attribute. If an "m=" section contains an "a=rtcp-mux-only" attribute, that section MUST also contain an "a=rtcp-mux" attribute. * If an "m=" section was present in the previous answer, the state of RTP/RTCP multiplexing MUST match what was previously negotiated. If this session description is of type "pranswer" or "answer", the following additional checks are applied: * The session description MUST follow the rules defined in [RFC3264], Section 6, including the requirement that the number of "m=" sections MUST exactly match the number of "m=" sections in the associated offer. * For each "m=" section, the media type and protocol values MUST exactly match the media type and protocol values in the corresponding "m=" section in the associated offer. If any of the preceding checks failed, processing MUST stop and an error MUST be returned. 5.9. Applying a Local Description The following steps are performed at the media engine level to apply a local description. If an error is returned, the session MUST be restored to the state it was in before performing these steps. First, "m=" sections are processed. For each "m=" section, the following steps MUST be performed; if any parameters are out of bounds or cannot be applied, processing MUST stop and an error MUST be returned. * If this "m=" section is new, begin gathering candidates for it, as defined in [RFC8445], Section 5.1.1, unless it is definitively being bundled (either (1) this is an offer and the "m=" section is marked as bundle-only or (2) it is an answer and the "m=" section is bundled into another "m=" section). * Or, if the ICE ufrag and password values have changed, trigger the ICE agent to start an ICE restart as described in [RFC8445], Section 9, and begin gathering new candidates for the "m=" section. If this description is an answer, also start checks on that media section. * If the "m=" section <proto> value indicates use of RTP: Uberti, et al. Expires 24 March 2024 [Page 67] RFC 8829 JSEP September 2023 - If there is no RtpTransceiver associated with this "m=" section, find one and associate it with this "m=" section according to the following steps. Note that this situation will only occur when applying an offer. o Find the RtpTransceiver that corresponds to this "m=" section, using the mapping between transceivers and "m=" section indices established when creating the offer. o Set the value of this RtpTransceiver's mid property to the MID of the "m=" section. - If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in [RFC5761], Section 5.1.3. - For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in [RFC5285], Section 6. - If the MID header extension is supported, prepare to demux RTP streams intended for this "m=" section based on the MID header extension, as described in [RFC9143], Section 15. - For each specified media format, establish a mapping between the payload type and the actual media format, as described in [RFC3264], Section 6.1. In addition, prepare to demux RTP streams intended for this "m=" section based on the media formats supported by this "m=" section, as described in [RFC9143], Section 9.2. - For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type, as described in Sections 8.6 and 8.7 of [RFC4588]. - If the direction attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in Section 5.11 below. 5.10. Applying a Remote Description The following steps are performed to apply a remote description. If an error is returned, the session MUST be restored to the state it was in before performing these steps. Uberti, et al. Expires 24 March 2024 [Page 68] RFC 8829 JSEP September 2023 If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickleIceCandidates property to be "true". Otherwise, set this property to "false". The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds or cannot be applied, processing MUST stop and an error MUST be returned. * For any specified "CT" bandwidth value, set this value as the limit for the maximum total bitrate for all "m=" sections, as specified in [RFC4566], Section 5.8. Within this overall limit, the implementation can dynamically decide how to best allocate the available bandwidth between "m=" sections, respecting any specific limits that have been specified for individual "m=" sections. * For any specified "RR" or "RS" bandwidth values, handle as specified in [RFC3556], Section 2. * Any "AS" bandwidth value ([RFC4566], Section 5.8) MUST be ignored, as the meaning of this construct at the session level is not well defined. For each "m=" section, the following steps MUST be performed; if any parameters are out of bounds or cannot be applied, processing MUST stop and an error MUST be returned. * If the ICE ufrag or password changed from the previous remote description: - If the description is of type "offer", the implementation MUST note that an ICE restart is needed, as described in [RFC8839], Section 4.4.1.1.1. - If the description is of type "answer" or "pranswer", then check to see if the current local description is an ICE restart, and if not, generate an error. If the PeerConnection state is "have-remote-pranswer" and the ICE ufrag or password changed from the previous provisional answer, then signal the ICE agent to discard any previous ICE checklist state for the "m=" section. Finally, signal the ICE agent to begin checks. * If the current local description indicates an ICE restart but neither the ICE ufrag nor the password has changed from the previous remote description (as prescribed by [RFC8445], Section 9), generate an error. Uberti, et al. Expires 24 March 2024 [Page 69] RFC 8829 JSEP September 2023 * Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their connectivity checks. * Pair any supplied ICE candidates with any gathered local candidates, as described in [RFC8445], Section 6.1.2, and start connectivity checks with the appropriate credentials. * If an "a=end-of-candidates" attribute is present, process the end- of-candidates indication as described in [RFC8838], Section 14. * If the "m=" section <proto> value indicates use of RTP: - If the "m=" section is being recycled (see Section 5.2.2), disassociate the currently associated RtpTransceiver by setting its mid property to "null", and discard the mapping between the transceiver and its "m=" section index. - If the "m=" section is not associated with any RtpTransceiver (possibly because it was disassociated in the previous step), either find an RtpTransceiver or create one according to the following steps: o If the "m=" section is sendrecv or recvonly, and there are RtpTransceivers of the same type that were added to the PeerConnection by addTrack and are not associated with any "m=" section and are not stopped, find the first (according to the canonical order described in Section 5.2.1) such RtpTransceiver. o If no RtpTransceiver was found in the previous step, create one with a recvonly direction. o Associate the found or created RtpTransceiver with the "m=" section by setting the value of the RtpTransceiver's mid property to the MID of the "m=" section, and establish a mapping between the transceiver and the index of the "m=" section. If the "m=" section does not include a MID (i.e., the remote endpoint does not support the MID extension), generate a value for the RtpTransceiver mid property, following the guidance for "a=mid" mentioned in Section 5.2.1. - For each specified media format that is also supported by the local application, 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 Uberti, et al. Expires 24 March 2024 [Page 70] RFC 8829 JSEP September 2023 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 application, it MUST be ignored. - For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type, as described in [RFC4588], Section 4. If any referenced primary payload types are not present, this MUST result in an error. Note that RTX payload types may refer to primary payload types that are not supported by the local media implementation, in which case the RTX payload type MUST also be ignored. - For each specified fmtp parameter that is supported by the local implementation, enable them on the associated media formats. - For each specified Synchronization Source (SSRC) that is signaled in the "m=" section, prepare to demux RTP streams intended for this "m=" section using that SSRC, as described in [RFC9143], Section 9.2. - For each specified RTP header extension that is also supported by the local application, 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 application, it MUST be ignored. - For each specified RTCP feedback mechanism that is also supported by the local application, enable them on the associated media formats. - For any specified "TIAS" ("Transport Independent Application Specific Maximum") bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending media, as specified in [RFC3890]. If a "TIAS" value is not present but an "AS" value is specified, generate a "TIAS" value using this formula: TIAS = AS * 1000 * 0.95 - (50 * 40 * 8) The 1000 changes the unit from kbps to bps (as required by TIAS), and the 0.95 is to allocate 5% to RTCP. An estimate of header overhead is then subtracted out, in which the 50 is Uberti, et al. Expires 24 March 2024 [Page 71] RFC 8829 JSEP September 2023 based on 50 packets per second, the 40 is based on typical header size (in bytes), and the 8 converts bytes to bits. Note that "TIAS" is preferred over "AS" because it provides more accurate control of bandwidth. - For any "RR" or "RS" bandwidth values, handle as specified in [RFC3556], Section 2. - Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined. - If the "m=" section is of type "audio": o For each specified "CN" media format, configure silence suppression for all supported media formats with the same clock rate, as described in [RFC3389], Section 5, except for formats that have their own internal silence suppression mechanisms. Silence suppression for such formats (e.g., Opus) is controlled via fmtp parameters, as discussed in Section 5.2.3.2. o For each specified "telephone-event" media format, enable dual-tone multifrequency (DTMF) transmission for all supported media formats with the same clock rate, as described in [RFC4733], Section 2.5.1.2. If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats. o For any specified "ptime" value, configure the available media formats to use the specified packet size when sending. If the specified size is not supported for a media format, use the next closest value instead. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in Section 5.11 below. 5.11. Applying an Answer In addition to the steps mentioned above for processing a local or remote description, the following steps are performed when processing a description of type "pranswer" or "answer". For each "m=" section, the following steps MUST be performed: Uberti, et al. Expires 24 March 2024 [Page 72] RFC 8829 JSEP September 2023 * If the "m=" section has been rejected (i.e., the <port> value is set to zero in the answer), stop any reception or transmission of media for this section, and, unless a non-rejected "m=" section is bundled with this "m=" section, discard any associated ICE components, as described in [RFC8839], Section 4.4.3.1. * If the remote DTLS fingerprint has been changed or the value of the "a=tls-id" attribute has changed, tear down the DTLS connection. This includes the case when the PeerConnection state is "have-remote-pranswer". If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated. If an ICE restart is performed without a change in the tls-id value or fingerprint, then the same DTLS connection is continued over the new ICE channel. Note that although JSEP requires that answerers change the tls-id value if and only if the offerer does, non-JSEP answerers are permitted to change the tls- id value as long as the offer contained an ICE restart. Thus, JSEP implementations that process DTLS data prior to receiving an answer MUST be prepared to receive either a ClientHello or data from the previous DTLS connection. * If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any underlying ICE components, once they are active. * If the "m=" section <proto> value indicates use of RTP: - If the "m=" section references RTCP feedback mechanisms that were not present in the corresponding "m=" section in the offer, this indicates a negotiation problem and MUST result in an error. However, new media formats and new RTP header extension values are permitted in the answer, as described in [RFC3264], Section 7 and [RFC5285], Section 6. - If the "m=" 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. - If the "m=" section has Reduced-Size RTCP enabled, configure the RTCP transmission for this "m=" section to use Reduced-Size RTCP, as specified in [RFC5506]. Uberti, et al. Expires 24 March 2024 [Page 73] RFC 8829 JSEP September 2023 - If the direction attribute in the answer indicates that the JSEP implementation should be sending media ("sendonly" for local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is also locally supported, as discussed in Sections 6.1 and 7 of [RFC3264], and start transmitting RTP media using that format once the underlying transport layers have been established. If an SSRC has not already been chosen for this outgoing RTP stream, choose a unique random one. If media is already being transmitted, the same SSRC SHOULD be used unless the clock rate of the new codec is different, in which case a new SSRC MUST be chosen, as specified in [RFC7160], Section 4.1. - The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams, including the payload type for the send media format chosen above. 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 MID header extension has been negotiated, include it in the outgoing RTP streams, as indicated in [RFC9143], Section 15. If the RtpStreamId or RepairedRtpStreamId header extensions have been negotiated and rid-ids have been established, include these header extensions in the outgoing RTP streams, as indicated in [RFC8851], Section 4. - If the "m=" section is of type "audio", and silence suppression was (1) configured for the send media format as a result of processing the remote description and (2) also enabled for that format in the local description, use silence suppression for outgoing media, in accordance with the guidance in Section 5.2.3.2. If these conditions are not met, silence suppression MUST NOT be used for outgoing media. - If simulcast has been negotiated, send the appropriate number of Source RTP Streams as specified in [RFC8853], Section 5.3.3. - If the send media format chosen above has a corresponding "rtx" media format or a FEC mechanism has been negotiated, establish a redundancy RTP stream with a unique random SSRC for each Source RTP Stream, and start or continue transmitting RTX/FEC packets as needed. Uberti, et al. Expires 24 March 2024 [Page 74] RFC 8829 JSEP September 2023 - If the send media format chosen above has a corresponding "red" media format of the same clock rate, allow redundant encoding using the specified format for resiliency purposes, as discussed in [RFC8854], Section 3.2. Note that unlike RTX or FEC media formats, the "red" format is transmitted on the Source RTP Stream, not the redundancy RTP stream. - Enable the RTCP feedback mechanisms referenced in the media section for all Source RTP Streams using the specified media formats. Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified in [RFC4585], Section 4.2. When sending RTCP feedback, follow the rules and recommendations from [RFC8108], Section 5.4.1 to select which SSRC to use. - If the direction attribute in the answer indicates that the JSEP implementation should not be sending media ("recvonly" for local answers, "sendonly" for remote answers, or "inactive" for either type of answer), stop transmitting all RTP media, but continue sending RTCP, as described in [RFC3264], Section 5.1. * If the "m=" section <proto> value indicates use of SCTP: - If an SCTP association exists and the remote SCTP port has changed, discard the existing SCTP association. This includes the case when the PeerConnection state is "have-remote- pranswer". - If no valid SCTP association exists, prepare to initiate an SCTP association over the associated ICE component and DTLS connection, using the local SCTP port value from the local description and the remote SCTP port value from the remote description, as described in [RFC8841], Section 10.2. If the answer contains valid bundle groups, discard any ICE components for the "m=" sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these "m=" sections accordingly, as described in [RFC9143], Section 7.4. If the description is of type "answer" and there are still remaining candidates in the ICE candidate pool, discard them. 6. Processing RTP/RTCP When bundling, associating incoming RTP/RTCP with the proper "m=" section is defined in [RFC9143], Section 9.2. When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. Uberti, et al. Expires 24 March 2024 [Page 75] RFC 8829 JSEP September 2023 Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m=" section(s) and further processing of the RTP/RTCP is done at the RtpTransceiver level. This includes using the RID mechanism [RFC8851] and its associated RtpStreamId and RepairedRtpStreamId identifiers to distinguish between multiple encoded streams and determine which Source RTP stream should be repaired by a given redundancy RTP stream. 7. Examples Note that this example section shows several SDP fragments. To accommodate RFC line-length restrictions, some of the SDP lines have been split into multiple lines, where leading whitespace indicates that a line is a continuation of the previous line. In addition, some blank lines have been added to improve readability but are not valid in SDP. More examples of SDP for WebRTC call flows, including examples with IPv6 addresses, can be found in [SDP4WebRTC]. 7.1. Simple Example This section shows a very simple example that sets up a minimal audio/video call between two JSEP endpoints without using Trickle ICE. The example in the following section provides a more detailed example of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to Bob's endpoint. The messages from the JavaScript application in Alice's browser to the JavaScript in Bob's browser, abbreviated as "AliceJS" and "BobJS", respectively, are assumed to flow over some signaling protocol via a web server. The JavaScript on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; Trickle ICE is not used. The user agents (JSEP implementations) in Alice's and Bob's browsers, abbreviated as "AliceUA" and "BobUA", respectively, are both using the default bundle policy of "balanced" and the default RTCP mux policy of "require". Uberti, et al. Expires 24 March 2024 [Page 76] RFC 8829 JSEP September 2023 // set up local media state AliceJS->AliceUA: create new PeerConnection AliceJS->AliceUA: addTrack with two tracks: audio and video AliceJS->AliceUA: createOffer to get offer AliceJS->AliceUA: setLocalDescription with offer AliceUA->AliceJS: multiple onicecandidate events with candidates // wait for ICE gathering to complete AliceUA->AliceJS: onicecandidate event with null candidate AliceJS->AliceUA: get |offer-A1| from pendingLocalDescription // |offer-A1| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |offer-A1| WebServer->BobJS: signaling with |offer-A1| // |offer-A1| arrives at Bob BobJS->BobUA: create a PeerConnection BobJS->BobUA: setRemoteDescription with |offer-A1| BobUA->BobJS: ontrack events for audio and video tracks // Bob accepts call BobJS->BobUA: addTrack with local tracks BobJS->BobUA: createAnswer BobJS->BobUA: setLocalDescription with answer BobUA->BobJS: multiple onicecandidate events with candidates // wait for ICE gathering to complete BobUA->BobJS: onicecandidate event with null candidate BobJS->BobUA: get |answer-A1| from currentLocalDescription // |answer-A1| is sent over signaling protocol // to Alice BobJS->WebServer: signaling with |answer-A1| WebServer->AliceJS: signaling with |answer-A1| // |answer-A1| arrives at Alice AliceJS->AliceUA: setRemoteDescription with |answer-A1| AliceUA->AliceJS: ontrack events for audio and video tracks // media flows BobUA->AliceUA: media sent from Bob to Alice AliceUA->BobUA: media sent from Alice to Bob The SDP for |offer-A1| looks like: Uberti, et al. Expires 24 March 2024 [Page 77] RFC 8829 JSEP September 2023 v=0 o=- 4962303333179871722 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 203.0.113.100 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:47017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:ETEn a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:actpass a=tls-id:91bbf309c0990a6bec11e38ba2933cee a=rtcp:10101 IN IP4 203.0.113.100 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10101 typ host a=end-of-candidates m=video 10102 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 203.0.113.100 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 Uberti, et al. Expires 24 March 2024 [Page 78] RFC 8829 JSEP September 2023 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:47017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:BGKk a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:actpass a=tls-id:91bbf309c0990a6bec11e38ba2933cee a=rtcp:10103 IN IP4 203.0.113.100 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host a=end-of-candidates The SDP for |answer-A1| looks like: v=0 o=- 6729291447651054566 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 203.0.113.200 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=ice-ufrag:6sFv a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 Uberti, et al. Expires 24 March 2024 [Page 79] RFC 8829 JSEP September 2023 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:active a=tls-id:eec3392ab83e11ceb6a0990c903fbb19 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host a=end-of-candidates m=video 10200 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 203.0.113.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 7.2. Detailed Example This section shows a more involved example of a session between two JSEP endpoints. Trickle ICE is used in full trickle mode, with a bundle policy of "must-bundle", an RTCP mux policy of "require", and a single TURN server. Initially, both Alice and Bob establish an audio channel and a data channel. Later, Bob adds two video flows -- one for his video feed and one for screen sharing, both supporting FEC -- with the video feed configured for simulcast. Alice accepts these video flows but does not add video flows of her own, so they are handled as recvonly. Alice also specifies a maximum video decoder resolution. // set up local media state AliceJS->AliceUA: create new PeerConnection AliceJS->AliceUA: addTrack with an audio track AliceJS->AliceUA: createDataChannel to get data channel AliceJS->AliceUA: createOffer to get |offer-B1| AliceJS->AliceUA: setLocalDescription with |offer-B1| // |offer-B1| is sent over signaling protocol to Bob Uberti, et al. Expires 24 March 2024 [Page 80] RFC 8829 JSEP September 2023 AliceJS->WebServer: signaling with |offer-B1| WebServer->BobJS: signaling with |offer-B1| // |offer-B1| arrives at Bob BobJS->BobUA: create a PeerConnection BobJS->BobUA: setRemoteDescription with |offer-B1| BobUA->BobJS: ontrack event with audio track from Alice // candidates are sent to Bob AliceUA->AliceJS: onicecandidate (host) |offer-B1-candidate-1| AliceJS->WebServer: signaling with |offer-B1-candidate-1| AliceUA->AliceJS: onicecandidate (srflx) |offer-B1-candidate-2| AliceJS->WebServer: signaling with |offer-B1-candidate-2| AliceUA->AliceJS: onicecandidate (relay) |offer-B1-candidate-3| AliceJS->WebServer: signaling with |offer-B1-candidate-3| WebServer->BobJS: signaling with |offer-B1-candidate-1| BobJS->BobUA: addIceCandidate with |offer-B1-candidate-1| WebServer->BobJS: signaling with |offer-B1-candidate-2| BobJS->BobUA: addIceCandidate with |offer-B1-candidate-2| WebServer->BobJS: signaling with |offer-B1-candidate-3| BobJS->BobUA: addIceCandidate with |offer-B1-candidate-3| // Bob accepts call BobJS->BobUA: addTrack with local audio BobJS->BobUA: createDataChannel to get data channel BobJS->BobUA: createAnswer to get |answer-B1| BobJS->BobUA: setLocalDescription with |answer-B1| // |answer-B1| is sent to Alice BobJS->WebServer: signaling with |answer-B1| WebServer->AliceJS: signaling with |answer-B1| AliceJS->AliceUA: setRemoteDescription with |answer-B1| AliceUA->AliceJS: ontrack event with audio track from Bob // candidates are sent to Alice BobUA->BobJS: onicecandidate (host) |answer-B1-candidate-1| BobJS->WebServer: signaling with |answer-B1-candidate-1| BobUA->BobJS: onicecandidate (srflx) |answer-B1-candidate-2| BobJS->WebServer: signaling with |answer-B1-candidate-2| BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-3| BobJS->WebServer: signaling with |answer-B1-candidate-3| WebServer->AliceJS: signaling with |answer-B1-candidate-1| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| WebServer->AliceJS: signaling with |answer-B1-candidate-2| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-2| WebServer->AliceJS: signaling with |answer-B1-candidate-3| Uberti, et al. Expires 24 March 2024 [Page 81] RFC 8829 JSEP September 2023 AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-3| // data channel opens BobUA->BobJS: ondatachannel event AliceUA->AliceJS: ondatachannel event BobUA->BobJS: onopen AliceUA->AliceJS: onopen // media is flowing between endpoints BobUA->AliceUA: audio+data sent from Bob to Alice AliceUA->BobUA: audio+data sent from Alice to Bob // some time later, Bob adds two video streams // note: no candidates exchanged, because of bundle BobJS->BobUA: addTrack with first video stream BobJS->BobUA: addTrack with second video stream BobJS->BobUA: createOffer to get |offer-B2| BobJS->BobUA: setLocalDescription with |offer-B2| // |offer-B2| is sent to Alice BobJS->WebServer: signaling with |offer-B2| WebServer->AliceJS: signaling with |offer-B2| AliceJS->AliceUA: setRemoteDescription with |offer-B2| AliceUA->AliceJS: ontrack event with first video track AliceUA->AliceJS: ontrack event with second video track AliceJS->AliceUA: createAnswer to get |answer-B2| AliceJS->AliceUA: setLocalDescription with |answer-B2| // |answer-B2| is sent over signaling protocol // to Bob AliceJS->WebServer: signaling with |answer-B2| WebServer->BobJS: signaling with |answer-B2| BobJS->BobUA: setRemoteDescription with |answer-B2| // media is flowing between endpoints BobUA->AliceUA: audio+video+data sent from Bob to Alice AliceUA->BobUA: audio+video+data sent from Alice to Bob The SDP for |offer-B1| looks like: Uberti, et al. Expires 24 March 2024 [Page 82] RFC 8829 JSEP September 2023 v=0 o=- 4962303333179871723 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:57017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:ATEn a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:actpass a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=application 0 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 a=bundle-only |offer-B1-candidate-1| looks like: ufrag ATEn index 0 mid a1 attr candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host |offer-B1-candidate-2| looks like: Uberti, et al. Expires 24 March 2024 [Page 83] RFC 8829 JSEP September 2023 ufrag ATEn index 0 mid a1 attr candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx raddr 203.0.113.100 rport 10100 |offer-B1-candidate-3| looks like: ufrag ATEn index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 198.51.100.100 rport 11100 The SDP for |answer-B1| looks like: Uberti, et al. Expires 24 March 2024 [Page 84] RFC 8829 JSEP September 2023 v=0 o=- 7729291447651054566 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=ice-ufrag:7sFv a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:active a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 |answer-B1-candidate-1| looks like: ufrag 7sFv index 0 mid a1 attr candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host |answer-B1-candidate-2| looks like: Uberti, et al. Expires 24 March 2024 [Page 85] RFC 8829 JSEP September 2023 ufrag 7sFv index 0 mid a1 attr candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx raddr 203.0.113.200 rport 10200 |answer-B1-candidate-3| looks like: ufrag 7sFv index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 198.51.100.200 rport 11200 The SDP for |offer-B2| is shown below. In addition to the new "m=" sections for video, both of which are offering FEC and one of which is offering simulcast, note the increment of the version number in the "o=" line; changes to the "c=" line, indicating the local candidate that was selected; and the inclusion of gathered candidates as a=candidate lines. v=0 o=- 7729291447651054566 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 v1 v2 a=group:LS a1 v1 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.200 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=ice-ufrag:7sFv a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: Uberti, et al. Expires 24 March 2024 [Page 86] RFC 8829 JSEP September 2023 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:actpass a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host a=candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx raddr 203.0.113.200 rport 10200 a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 198.51.100.200 rport 11200 a=end-of-candidates m=application 12200 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.200 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104 c=IN IP4 192.0.2.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=rtpmap:104 flexfec/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=rid:1 send a=rid:2 send a=rid:3 send a=simulcast:send 1;2;3 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104 c=IN IP4 192.0.2.200 a=mid:v2 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 Uberti, et al. Expires 24 March 2024 [Page 87] RFC 8829 JSEP September 2023 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=rtpmap:104 flexfec/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:81317484-2ed4-49d7-9eb7-1414322a7aae The SDP for |answer-B2| is shown below. In addition to the acceptance of the video "m=" sections, the use of a=recvonly to indicate one-way video, and the use of a=imageattr to limit the received resolution, note the use of setup:passive to maintain the existing DTLS roles. v=0 o=- 4962303333179871723 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 v1 v2 a=group:LS a1 v1 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.100 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:57017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:ATEn a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:passive Uberti, et al. Expires 24 March 2024 [Page 88] RFC 8829 JSEP September 2023 a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host a=candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx raddr 203.0.113.100 rport 10100 a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 198.51.100.100 rport 11100 a=end-of-candidates m=application 12100 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.100 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v1 a=recvonly a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v2 a=recvonly a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid Uberti, et al. Expires 24 March 2024 [Page 89] RFC 8829 JSEP September 2023 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli 7.3. Early Transport Warmup Example This example demonstrates the early-warmup technique described in Section 4.1.10.1. Here, Alice's endpoint sends an offer to Bob's endpoint to start an audio/video call. Bob immediately responds with an answer that accepts the audio/video "m=" sections but marks them as sendonly (from his perspective), meaning that Alice will not yet send media. This allows the JSEP implementation to start negotiating ICE and DTLS immediately. Bob's endpoint then prompts him to answer the call, and when he does, his endpoint sends a second offer, which enables the audio and video "m=" sections, and thereby bidirectional media transmission. The advantage of such a flow is that as soon as the first answer is received, the implementation can proceed with ICE and DTLS negotiation and establish the session transport. If the transport setup completes before the second offer is sent, then media can be transmitted by the callee immediately upon answering the call, minimizing perceived post-dial delay. The second offer/answer exchange can also change the preferred codecs or other session parameters. This example also makes use of the "relay" ICE candidate policy described in Section 3.5.3 to minimize the ICE gathering and checking needed. // set up local media state AliceJS->AliceUA: create new PeerConnection with "relay" ICE policy AliceJS->AliceUA: addTrack with two tracks: audio and video AliceJS->AliceUA: createOffer to get |offer-C1| AliceJS->AliceUA: setLocalDescription with |offer-C1| // |offer-C1| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |offer-C1| WebServer->BobJS: signaling with |offer-C1| // |offer-C1| arrives at Bob BobJS->BobUA: create new PeerConnection with "relay" ICE policy BobJS->BobUA: setRemoteDescription with |offer-C1| BobUA->BobJS: ontrack events for audio and video // a relay candidate is sent to Bob AliceUA->AliceJS: onicecandidate (relay) |offer-C1-candidate-1| AliceJS->WebServer: signaling with |offer-C1-candidate-1| Uberti, et al. Expires 24 March 2024 [Page 90] RFC 8829 JSEP September 2023 WebServer->BobJS: signaling with |offer-C1-candidate-1| BobJS->BobUA: addIceCandidate with |offer-C1-candidate-1| // Bob prepares an early answer to warm up the // transport BobJS->BobUA: addTransceiver with null audio and video tracks BobJS->BobUA: transceiver.setDirection(sendonly) for both BobJS->BobUA: createAnswer BobJS->BobUA: setLocalDescription with answer // |answer-C1| is sent over signaling protocol // to Alice BobJS->WebServer: signaling with |answer-C1| WebServer->AliceJS: signaling with |answer-C1| // |answer-C1| (sendonly) arrives at Alice AliceJS->AliceUA: setRemoteDescription with |answer-C1| AliceUA->AliceJS: ontrack events for audio and video // a relay candidate is sent to Alice BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1| BobJS->WebServer: signaling with |answer-B1-candidate-1| WebServer->AliceJS: signaling with |answer-B1-candidate-1| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| // ICE and DTLS establish while call is ringing // Bob accepts call, starts media, and sends // new offer BobJS->BobUA: transceiver.setTrack with audio and video tracks BobUA->AliceUA: media sent from Bob to Alice BobJS->BobUA: transceiver.setDirection(sendrecv) for both transceivers BobJS->BobUA: createOffer BobJS->BobUA: setLocalDescription with offer // |offer-C2| is sent over signaling protocol // to Alice BobJS->WebServer: signaling with |offer-C2| WebServer->AliceJS: signaling with |offer-C2| // |offer-C2| (sendrecv) arrives at Alice AliceJS->AliceUA: setRemoteDescription with |offer-C2| AliceJS->AliceUA: createAnswer AliceJS->AliceUA: setLocalDescription with |answer-C2| AliceUA->BobUA: media sent from Alice to Bob Uberti, et al. Expires 24 March 2024 [Page 91] RFC 8829 JSEP September 2023 // |answer-C2| is sent over signaling protocol // to Bob AliceJS->WebServer: signaling with |answer-C2| WebServer->BobJS: signaling with |answer-C2| BobJS->BobUA: setRemoteDescription with |answer-C2| The SDP for |offer-C1| looks like: v=0 o=- 1070771854436052752 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=ice-ufrag:4ZcD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=fingerprint:sha-256 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF a=setup:actpass a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=video 0 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 0.0.0.0 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 Uberti, et al. Expires 24 March 2024 [Page 92] RFC 8829 JSEP September 2023 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=bundle-only |offer-C1-candidate-1| looks like: ufrag 4ZcD index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 0.0.0.0 rport 0 The SDP for |answer-C1| looks like: v=0 o=- 6386516489780559513 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendonly a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:751f239e-4ae0-c549-aa3d-890de772998b a=ice-ufrag:TpaA a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ Uberti, et al. Expires 24 March 2024 [Page 93] RFC 8829 JSEP September 2023 a=fingerprint:sha-256 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D a=setup:active a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=video 9 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 0.0.0.0 a=mid:v1 a=sendonly a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:751f239e-4ae0-c549-aa3d-890de772998b |answer-C1-candidate-1| looks like: ufrag TpaA index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 0.0.0.0 rport 0 The SDP for |offer-C2| looks like: v=0 o=- 6386516489780559513 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.200 a=mid:a1 Uberti, et al. Expires 24 March 2024 [Page 94] RFC 8829 JSEP September 2023 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:751f239e-4ae0-c549-aa3d-890de772998b a=ice-ufrag:TpaA a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ a=fingerprint:sha-256 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D a=setup:actpass a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 0.0.0.0 rport 0 a=end-of-candidates m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:751f239e-4ae0-c549-aa3d-890de772998b The SDP for |answer-C2| looks like: Uberti, et al. Expires 24 March 2024 [Page 95] RFC 8829 JSEP September 2023 v=0 o=- 1070771854436052752 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.100 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=ice-ufrag:4ZcD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=fingerprint:sha-256 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF a=setup:passive a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 0.0.0.0 rport 0 a=end-of-candidates m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 a=rtpmap:103 rtx/90000 a=fmtp:103 apt=101 Uberti, et al. Expires 24 March 2024 [Page 96] RFC 8829 JSEP September 2023 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 8. Security Considerations The IETF has published separate documents [RFC8827] [RFC8826] describing the security architecture for WebRTC as a whole. The remainder of this section describes security considerations for this document. While formally the JSEP interface is an API, it is better to think of it as an Internet protocol, with the application JavaScript being untrustworthy from the perspective of the JSEP implementation. Thus, the threat model of [RFC3552] applies. In particular, JavaScript can call the API in any order and with any inputs, including malicious ones. This is particularly relevant when one considers the SDP that is passed to setLocalDescription. While correct API usage requires that the application pass in SDP that was derived from createOffer or createAnswer, there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior. One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those candidates even if they are not sent to the other side. Thus, for instance, it is not possible to prevent the remote peer from learning your public IP address by removing server-reflexive candidates. Applications that wish to conceal their public IP address MUST instead configure the ICE agent to use only relay candidates. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References Uberti, et al. Expires 24 March 2024 [Page 97] RFC 8829 JSEP September 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <https://www.rfc-editor.org/info/rfc3605>. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>. [RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, DOI 10.17487/RFC3890, September 2004, <https://www.rfc-editor.org/info/rfc3890>. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <https://www.rfc-editor.org/info/rfc4145>. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>. Uberti, et al. Expires 24 March 2024 [Page 98] RFC 8829 JSEP September 2023 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>. [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <https://www.rfc-editor.org/info/rfc5124>. [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, <https://www.rfc-editor.org/info/rfc5285>. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-editor.org/info/rfc5761>. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-editor.org/info/rfc5888>. [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, DOI 10.17487/RFC6236, May 2011, <https://www.rfc-editor.org/info/rfc6236>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>. [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, <https://www.rfc-editor.org/info/rfc6716>. [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <https://www.rfc-editor.org/info/rfc6904>. [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, <https://www.rfc-editor.org/info/rfc7160>. Uberti, et al. Expires 24 March 2024 [Page 99] RFC 8829 JSEP September 2023 [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, <https://www.rfc-editor.org/info/rfc7587>. [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, <https://www.rfc-editor.org/info/rfc7742>. [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, <https://www.rfc-editor.org/info/rfc7850>. [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, <https://www.rfc-editor.org/info/rfc7874>. [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, <https://www.rfc-editor.org/info/rfc8108>. [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, <https://www.rfc-editor.org/info/rfc8122>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>. [RFC8826] Rescorla, E., "Security Considerations for WebRTC", RFC 8826, DOI 10.17487/RFC8826, January 2021, <https://www.rfc-editor.org/info/rfc8826>. [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, <https://www.rfc-editor.org/info/rfc8827>. Uberti, et al. Expires 24 March 2024 [Page 100] RFC 8829 JSEP September 2023 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., "JavaScript Session Establishment Protocol (JSEP)", RFC 8829, DOI 10.17487/RFC8829, January 2021, <https://www.rfc-editor.org/info/rfc8829>. [RFC8830] Alvestrand, H., "WebRTC MediaStream Identification in the Session Description Protocol", RFC 8830, DOI 10.17487/RFC8830, January 2021, <https://www.rfc-editor.org/info/rfc8830>. [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, January 2021, <https://www.rfc-editor.org/info/rfc8834>. [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", RFC 8838, DOI 10.17487/RFC8838, January 2021, <https://www.rfc-editor.org/info/rfc8838>. [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021, <https://www.rfc-editor.org/info/rfc8839>. [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)", RFC 8840, DOI 10.17487/RFC8840, January 2021, <https://www.rfc-editor.org/info/rfc8840>. [RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport", RFC 8841, DOI 10.17487/RFC8841, January 2021, <https://www.rfc-editor.org/info/rfc8841>. [RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", RFC 8842, DOI 10.17487/RFC8842, January 2021, <https://www.rfc-editor.org/info/rfc8842>. Uberti, et al. Expires 24 March 2024 [Page 101] RFC 8829 JSEP September 2023 [RFC8851] Roach, A.B., Ed., "RTP Payload Format Restrictions", RFC 8851, DOI 10.17487/RFC8851, January 2021, <https://www.rfc-editor.org/info/rfc8851>. [RFC8852] Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", RFC 8852, DOI 10.17487/RFC8852, January 2021, <https://www.rfc-editor.org/info/rfc8852>. [RFC8853] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in Session Description Protocol (SDP) and RTP Sessions", RFC 8853, DOI 10.17487/RFC8853, January 2021, <https://www.rfc-editor.org/info/rfc8853>. [RFC8854] Uberti, J., "WebRTC Forward Error Correction Requirements", RFC 8854, DOI 10.17487/RFC8854, January 2021, <https://www.rfc-editor.org/info/rfc8854>. [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)", RFC 8858, DOI 10.17487/RFC8858, January 2021, <https://www.rfc-editor.org/info/rfc8858>. [RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>. [RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 9143, DOI 10.17487/RFC9143, February 2022, <https://www.rfc-editor.org/info/rfc9143>. 10.2. Informative References [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, September 2002, <https://www.rfc-editor.org/info/rfc3389>. [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, <https://www.rfc-editor.org/info/rfc3556>. Uberti, et al. Expires 24 March 2024 [Page 102] RFC 8829 JSEP September 2023 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, DOI 10.17487/RFC3960, December 2004, <https://www.rfc-editor.org/info/rfc3960>. [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, <https://www.rfc-editor.org/info/rfc4568>. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>. [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 2006, <https://www.rfc-editor.org/info/rfc4733>. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <https://www.rfc-editor.org/info/rfc5245>. [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <https://www.rfc-editor.org/info/rfc5506>. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <https://www.rfc-editor.org/info/rfc5576>. [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>. [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>. Uberti, et al. Expires 24 March 2024 [Page 103] RFC 8829 JSEP September 2023 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>. [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, <https://www.rfc-editor.org/info/rfc6464>. [RFC8828] Uberti, J. and G. Shieh, "WebRTC IP Address Handling Requirements", RFC 8828, DOI 10.17487/RFC8828, January 2021, <https://www.rfc-editor.org/info/rfc8828>. [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>. [SDP4WebRTC] Nandakumar, S. and C. F. Jennings, "Annotated Example SDP for WebRTC", Work in Progress, Internet-Draft, draft-ietf- rtcweb-sdp-14, 17 December 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb- sdp-14>. [TS26.114] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction (Release 16)", 3GPP TS 26.114 V16.3.0, September 2019, <https://www.3gpp.org/DynaReport/26114.htm>. [W3C.webrtc] Jennings, C., Ed., Boström, H., Ed., and J. Bruaroey, Ed., "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium Recommendation, January 2021, <https://www.w3.org/TR/2021/REC-webrtc-20210126/>. Appendix A. SDP ABNF Syntax For the syntax validation performed in Section 5.8, the following list of ABNF definitions is used: Uberti, et al. Expires 24 March 2024 [Page 104] RFC 8829 JSEP September 2023 +=========================+==========================+ | Attribute | Reference | +=========================+==========================+ | ptime | Section 6 of [RFC4566] | +-------------------------+--------------------------+ | maxptime | Section 6 of [RFC4566] | +-------------------------+--------------------------+ | rtpmap | Section 6 of [RFC4566] | +-------------------------+--------------------------+ | recvonly | Section 9 of [RFC4566] | +-------------------------+--------------------------+ | sendrecv | Section 9 of [RFC4566] | +-------------------------+--------------------------+ | sendonly | Section 9 of [RFC4566] | +-------------------------+--------------------------+ | inactive | Section 9 of [RFC4566] | +-------------------------+--------------------------+ | fmtp | Section 9 of [RFC4566] | +-------------------------+--------------------------+ | rtcp | Section 2.1 of [RFC3605] | +-------------------------+--------------------------+ | setup | Section 4 of [RFC4145] | +-------------------------+--------------------------+ | fingerprint | Section 5 of [RFC8122] | +-------------------------+--------------------------+ | rtcp-fb | Section 4.2 of [RFC4585] | +-------------------------+--------------------------+ | extmap | Section 7 of [RFC5285] | +-------------------------+--------------------------+ | mid | Section 4 of [RFC5888] | +-------------------------+--------------------------+ | group | Section 5 of [RFC5888] | +-------------------------+--------------------------+ | imageattr | Section 3.1 of [RFC6236] | +-------------------------+--------------------------+ | extmap (encrypt option) | Section 4 of [RFC6904] | +-------------------------+--------------------------+ | candidate | Section 5.1 of [RFC8839] | +-------------------------+--------------------------+ | remote-candidates | Section 5.2 of [RFC8839] | +-------------------------+--------------------------+ | ice-lite | Section 5.3 of [RFC8839] | +-------------------------+--------------------------+ | ice-ufrag | Section 5.4 of [RFC8839] | +-------------------------+--------------------------+ | ice-pwd | Section 5.4 of [RFC8839] | +-------------------------+--------------------------+ | ice-options | Section 5.6 of [RFC8839] | Uberti, et al. Expires 24 March 2024 [Page 105] RFC 8829 JSEP September 2023 +-------------------------+--------------------------+ | msid | Section 3 of [RFC8830] | +-------------------------+--------------------------+ | rid | Section 10 of [RFC8851] | +-------------------------+--------------------------+ | simulcast | Section 5.1 of [RFC8853] | +-------------------------+--------------------------+ | tls-id | Section 4 of [RFC8842] | +-------------------------+--------------------------+ Table 1: SDP ABNF References Acknowledgements Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and Peter Thatcher provided significant text for this document. Bernard Aboba, Adam Bergkvist, Jan-Ivar Bruaroey, Dan Burnett, Ben Campbell, Alissa Cooper, Richard Ejzak, Stefan Håkansson, Ted Hardie, Christer Holmberg, Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant Narayanan, Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson, Sean Turner, and Magnus Westerlund all provided valuable feedback on this document. Authors' Addresses Justin Uberti Email: justin@uberti.name Cullen Jennings Cisco 400 3rd Avenue SW Calgary AB T2P 4H2 Canada Email: fluffy@iii.ca Eric Rescorla (editor) Mozilla Email: ekr@rtfm.com Uberti, et al. Expires 24 March 2024 [Page 106]