JavaScript Session Establishment Protocol (JSEP)
draft-uberti-rtcweb-rfc8829bis-03
The information below is for an old version of the document.
| 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 | 2022-12-12 (Latest revision 2022-09-21) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| 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) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Murray Kucherawy | ||
| Send notices to | sean@sn3rd.com | ||
| IANA | IANA review state | IANA OK - No Actions Needed |
draft-uberti-rtcweb-rfc8829bis-03
" 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 25 March 2023 [Page 64]
RFC 8829 JSEP September 2022
* 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 25 March 2023 [Page 65]
RFC 8829 JSEP September 2022
* 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 25 March 2023 [Page 66]
RFC 8829 JSEP September 2022
* 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 25 March 2023 [Page 67]
RFC 8829 JSEP September 2022
- 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 25 March 2023 [Page 68]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 69]
RFC 8829 JSEP September 2022
* 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 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
Uberti, et al. Expires 25 March 2023 [Page 70]
RFC 8829 JSEP September 2022
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.
- 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 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.
- For each specified RTCP feedback mechanism that is supported by
the local implementation, 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 25 March 2023 [Page 71]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 72]
RFC 8829 JSEP September 2022
* 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 25 March 2023 [Page 73]
RFC 8829 JSEP September 2022
- 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 25 March 2023 [Page 74]
RFC 8829 JSEP September 2022
- 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 25 March 2023 [Page 75]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 76]
RFC 8829 JSEP September 2022
// 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 25 March 2023 [Page 77]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 78]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 79]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 80]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 81]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 82]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 83]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 84]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 85]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 86]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 87]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 88]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 89]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 90]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 91]
RFC 8829 JSEP September 2022
// |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 25 March 2023 [Page 92]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 93]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 94]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 95]
RFC 8829 JSEP September 2022
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 25 March 2023 [Page 96]
RFC 8829 JSEP September 2022
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 we consider 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 25 March 2023 [Page 97]
RFC 8829 JSEP September 2022
[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 25 March 2023 [Page 98]
RFC 8829 JSEP September 2022
[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 25 March 2023 [Page 99]
RFC 8829 JSEP September 2022
[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 25 March 2023 [Page 100]
RFC 8829 JSEP September 2022
[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 25 March 2023 [Page 101]
RFC 8829 JSEP September 2022
[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 25 March 2023 [Page 102]
RFC 8829 JSEP September 2022
[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 25 March 2023 [Page 103]
RFC 8829 JSEP September 2022
[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. Jennings, "Annotated Example SDP for
WebRTC", Work in Progress, Internet-Draft, draft-ietf-
rtcweb-sdp-14, 17 December 2020,
<https://www.ietf.org/archive/id/draft-ietf-rtcweb-sdp-
14.txt>.
[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 25 March 2023 [Page 104]
RFC 8829 JSEP September 2022
+=========================+==========================+
| 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 25 March 2023 [Page 105]
RFC 8829 JSEP September 2022
+-------------------------+--------------------------+
| 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 25 March 2023 [Page 106]