One document matched: draft-ietf-rtcweb-jsep-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-ietf-rtcweb-jsep-09" ipr="trust200902">
<front>
<title abbrev="JSEP">Javascript Session Establishment Protocol</title>
<author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization>Google</organization>
<address>
<postal>
<street>747 6th Ave S</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033</code>
<country>USA</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>fluffy@iii.ca</email>
</address>
</author>
<author fullname="Eric Rescorla" initials="E.K." surname="Rescorla" role="editor">
<organization>Mozilla</organization>
<address>
<postal>
<street>331 Evelyn Ave</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>USA</country>
</postal>
<email>ekr@rtfm.com</email>
</address>
</author>
<date day="9" month="March" year="2015" />
<area>RAI</area>
<abstract>
<t>This document describes the mechanisms for allowing a Javascript
application to control the signaling plane of a multimedia session via
the interface specified in the W3C RTCPeerConnection API, and discusses
how this relates to existing signaling protocols.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sec.introduction">
<t>This document describes how the W3C WEBRTC RTCPeerConnection
interface<xref target="W3C.WD-webrtc-20140617"></xref> is used to
control the setup, management and teardown of a multimedia session.</t>
<section title="General Design of JSEP" anchor="sec.general-design-of-jsep">
<t>The thinking behind WebRTC call setup has been to fully specify and
control the media plane, but to leave the signaling plane up to the
application as much as possible. The rationale is that different
applications may prefer to use different protocols, such as the
existing SIP or Jingle call signaling protocols, or something custom
to the particular application, perhaps for a novel use case. In this
approach, the key information that needs to be exchanged is the
multimedia session description, which specifies the necessary
transport and media configuration information necessary to establish
the media plane.</t>
<t>With these considerations in mind, this document describes the
Javascript Session Establishment Protocol (JSEP) that allows for full
control of the signaling state machine from Javascript.
JSEP removes the browser almost entirely from the core signaling flow, which
is instead handled by the Javascript making use of two interfaces:
(1) passing in local and remote session descriptions and (2) interacting
with the ICE state machine.
</t>
<t>In this document, the use of JSEP is described as if it always
occurs between two browsers. Note though in many cases it will
actually be between a browser and some kind of server, such as a
gateway or MCU. This distinction is invisible to the browser; it just
follows the instructions it is given via the API.</t>
<t>JSEP's handling of session descriptions is simple and
straightforward. Whenever an offer/answer exchange is needed, the
initiating side creates an offer by calling a createOffer() API. The
application optionally modifies that offer, and then uses it to set up
its local config via the setLocalDescription() API. The offer is then
sent off to the remote side over its preferred signaling mechanism
(e.g., WebSockets); upon receipt of that offer, the remote party
installs it using the setRemoteDescription() API.</t>
<t>To complete the offer/answer exchange, the remote party uses the createAnswer() API
to generate an appropriate answer, applies it using the
setLocalDescription() API, and sends the answer back to the initiator over
the signaling channel. When the initiator gets that answer, it installs
it using the setRemoteDescription() API, and initial setup is complete. This
process can be repeated for additional offer/answer exchanges.</t>
<t>Regarding ICE <xref target="RFC5245"></xref>, JSEP decouples the
ICE state machine from the overall signaling state machine, as the ICE
state machine must remain in the browser, because only the browser has
the necessary knowledge of candidates and other transport info.
Performing this separation also provides additional flexibility; in
protocols that decouple session descriptions from transport, such as
Jingle, the session description can be sent immediately and the
transport information can be sent when available. In protocols
that don't, such as SIP, the information can be used in the aggregated
form. Sending transport information separately can allow for faster
ICE and DTLS startup, since ICE checks can start as soon as any
transport information is available rather than waiting for all of
it.</t>
<t>Through its abstraction of signaling, the JSEP approach does
require the application to be aware of the signaling process. While
the application does not need to understand the contents of session
descriptions to set up a call, the application must call the right
APIs at the right times, convert the session descriptions and ICE
information into the defined messages of its chosen signaling
protocol, and perform the reverse conversion on the messages it
receives from the other side.</t>
<t>One way to mitigate this is to provide a Javascript library that
hides this complexity from the developer; said library would implement
a given signaling protocol along with its state machine and
serialization code, presenting a higher level call-oriented interface
to the application developer. For example, libraries exist to
adapt the JSEP API into an API suitable for a SIP or XMPP.
Thus, JSEP provides greater control
for the experienced developer without forcing any additional
complexity on the novice developer.</t>
</section>
<section title="Other Approaches Considered" anchor="sec.other-approaches-consider">
<t>One approach that was considered instead of JSEP was to include a
lightweight signaling protocol. Instead of providing session
descriptions to the API, the API would produce and consume messages
from this protocol. While providing a more high-level API, this put
more control of signaling within the browser, forcing the browser to
have to understand and handle concepts like signaling glare. In
addition, it prevented the application from driving the state machine
to a desired state, as is needed in the page reload case.</t>
<t>A second approach that was considered but not chosen was to
decouple the management of the media control objects from session
descriptions, instead offering APIs that would control each component
directly. This was rejected based on a feeling that requiring exposure
of this level of complexity to the application programmer would not be
beneficial; it would result in an API where even a simple example
would require a significant amount of code to orchestrate all the
needed interactions, as well as creating a large API surface that
needed to be agreed upon and documented. In addition, these API points
could be called in any order, resulting in a more complex set of
interactions with the media subsystem than the JSEP approach, which
specifies how session descriptions are to be evaluated and
applied.</t>
<t>One variation on JSEP that was considered was to keep the basic
session description-oriented API, but to move the mechanism for
generating offers and answers out of the browser. Instead of providing
createOffer/createAnswer methods within the browser, this approach
would instead expose a getCapabilities API which would provide the
application with the information it needed in order to generate its
own session descriptions. This increases the amount of work that the
application needs to do; it needs to know how to generate session
descriptions from capabilities, and especially how to generate the
correct answer from an arbitrary offer and the supported capabilities.
While this could certainly be addressed by using a library like the
one mentioned above, it basically forces the use of said library even
for a simple example. Providing createOffer/createAnswer avoids this
problem, but still allows applications to generate their own
offers/answers (to a large extent) if they choose, using the
description generated by createOffer as an indication of the browser's
capabilities.</t>
</section>
</section>
<section title="Terminology" anchor="sec.terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Semantics and Syntax" anchor="sec.semantics-and-syntax">
<section title="Signaling Model" anchor="sec.signaling-model">
<t>JSEP does not specify a particular signaling model or state
machine, other than the generic need to exchange SDP media
descriptions in the fashion described by <xref
target="RFC3264"></xref> (offer/answer) in order for both sides of the
session to know how to conduct the session. JSEP provides mechanisms
to create offers and answers, as well as to apply them to a session.
However, the browser is totally decoupled from the actual mechanism by
which these offers and answers are communicated to the remote side,
including addressing, retransmission, forking, and glare handling.
These issues are left entirely up to the application; the application
has complete control over which offers and answers get handed to the
browser, and when.</t>
<figure anchor="fig-sigModel" title="JSEP Signaling Model">
<artwork><![CDATA[
+-----------+ +-----------+
| Web App |<--- App-Specific Signaling -->| Web App |
+-----------+ +-----------+
^ ^
| SDP | SDP
V V
+-----------+ +-----------+
| Browser |<----------- Media ------------>| Browser |
+-----------+ +-----------+
]]></artwork>
</figure>
</section>
<section title="Session Descriptions and State Machine" anchor="sec.session-descriptions-and-">
<t>In order to establish the media plane, the user agent needs
specific parameters to indicate what to transmit to the remote side,
as well as how to handle the media that is received. These parameters
are determined by the exchange of session descriptions in offers and
answers, and there are certain details to this process that must be
handled in the JSEP APIs.</t>
<t>Whether a session description applies to the local side or the
remote side affects the meaning of that description. For example, the
list of codecs sent to a remote party indicates what the local side is
willing to receive, which, when intersected with the set of codecs the
remote side supports, specifies what the remote side should send.
However, not all parameters follow this rule; for example, the DTLS-SRTP
parameters <xref target="RFC5763"></xref> sent to a remote party
indicate what certificate the local side will use in DTLS setup, and
thereby what the remote party should expect to receive; the remote party
will have to accept these parameters, with no option to choose different
values.
</t>
<t>In addition, various RFCs put different conditions on the format of
offers versus answers. For example, an offer may propose an arbitrary
number of media streams (i.e. m= sections), but an answer must contain
the exact same number as the offer.</t>
<t>Lastly, while the exact media parameters are only known only after
an offer and an answer have been exchanged, it is possible for the
offerer to receive media after they have sent an offer and before they
have received an answer. To properly process incoming media in this
case, the offerer's media handler must be aware of the details of the
offer before the answer arrives.</t>
<t>Therefore, in order to handle session descriptions properly, the
user agent needs: <list style="numbers">
<t>To know if a session description pertains to the local or
remote side.</t>
<t>To know if a session description is an offer or an answer.</t>
<t>To allow the offer to be specified independently of the
answer.</t>
</list> JSEP addresses this by adding both setLocalDescription and
setRemoteDescription methods and having session description objects
contain a type field indicating the type of session description being
supplied. This satisfies the requirements listed above for both the
offerer, who first calls setLocalDescription(sdp [offer]) and then
later setRemoteDescription(sdp [answer]), as well as for the answerer,
who first calls setRemoteDescription(sdp [offer]) and then later
setLocalDescription(sdp [answer]).</t>
<t>JSEP also allows for an answer to be treated as provisional by the
application. Provisional answers provide a way for an answerer to
communicate initial session parameters back to the offerer, in order
to allow the session to begin, while allowing a final answer to be
specified later. This concept of a final answer is important to the
offer/answer model; when such an answer is received, any extra
resources allocated by the caller can be released, now that the exact
session configuration is known. These "resources" can include things
like extra ICE components, TURN candidates, or video decoders.
Provisional answers, on the other hand, do no such deallocation
results; as a result, multiple dissimilar provisional answers can be
received and applied during call setup.</t>
<t>In <xref target="RFC3264"></xref>, the constraint at the signaling
level is that only one offer can be outstanding for a given session,
but at the media stack level, a new offer can be generated at any
point. For example, when using SIP for signaling, if one offer is
sent, then cancelled using a SIP CANCEL, another offer can be
generated even though no answer was received for the first offer. To
support this, the JSEP media layer can provide an offer via the
createOffer() method whenever the
Javascript application needs one for the signaling.
The answerer can send back zero or more provisional answers, and finally end the
offer-answer exchange by sending a final answer. The state machine for
this is as follows:</t>
<t><figure anchor="fig-state-machine" title="JSEP State Machine">
<artwork><![CDATA[
setRemote(OFFER) setLocal(PRANSWER)
/-----\ /-----\
| | | |
v | v |
+---------------+ | +---------------+ |
| |----/ | |----/
| | setLocal(PRANSWER) | |
| Remote-Offer |------------------- >| Local-Pranswer|
| | | |
| | | |
+---------------+ +---------------+
^ | |
| | setLocal(ANSWER) |
setRemote(OFFER) | |
| V setLocal(ANSWER) |
+---------------+ |
| | |
| |<---------------------------+
| Stable |
| |<---------------------------+
| | |
+---------------+ setRemote(ANSWER) |
^ | |
| | setLocal(OFFER) |
setRemote(ANSWER) | |
| V |
+---------------+ +---------------+
| | | |
| | setRemote(PRANSWER) | |
| Local-Offer |------------------- >|Remote-Pranswer|
| | | |
| |----\ | |----\
+---------------+ | +---------------+ |
^ | ^ |
| | | |
\-----/ \-----/
setLocal(OFFER) setRemote(PRANSWER)
]]></artwork>
</figure></t>
<t>Aside from these state transitions there is no other difference
between the handling of provisional ("pranswer") and final ("answer")
answers.</t>
</section>
<section title="Session Description Format" anchor="sec.session-description-forma">
<t>In the WebRTC specification, session descriptions are formatted as
SDP messages. While this format is not optimal for manipulation from
Javascript, it is widely accepted, and frequently updated with new
features. Any alternate encoding of session descriptions would have to
keep pace with the changes to SDP, at least until the time that this
new encoding eclipsed SDP in popularity. As a result, JSEP currently
uses SDP as the internal representation for its session
descriptions.</t>
<t>However, to simplify Javascript processing, and provide for future
flexibility, the SDP syntax is encapsulated within a
SessionDescription object, which can be constructed from SDP, and be
serialized out to SDP. If future specifications agree on a JSON format
for session descriptions, we could easily enable this object to
generate and consume that JSON.</t>
<t>Other methods may be added to SessionDescription in the future to
simplify handling of SessionDescriptions from Javascript. In the
meantime, Javascript libraries can be used to perform these
manipulations.</t>
<t>Note that most applications should be able to treat the
SessionDescriptions produced and consumed by these various API calls
as opaque blobs; that is, the application will not need to read or
change them. The W3C WebRTC API specification will provide appropriate
APIs to allow the application to control various session parameters,
which will provide the necessary information to the browser about what
sort of SessionDescription to produce.</t>
</section>
<section title="ICE" anchor="sec.ice">
<section title="ICE Gathering Overview" anchor="sec.ice-gather-overview">
<t>JSEP gathers ICE candidates as needed by the application.
Collection of ICE candidates is referred to as a gathering phase,
and this is triggered either by the addition of a new or recycled m=
line to the local session description, or new ICE credentials in the
description, indicating an ICE restart. Use of new ICE credentials can
be triggered explicitly by the application, or implicitly by the
browser in response to changes in the ICE configuration.
</t>
<t>When a new
gathering phase starts, the ICE Agent will notify the application that
gathering is occurring through an event. Then, when each new ICE
candidate becomes available, the ICE Agent will supply it to the
application via an additional event; these candidates will also
automatically be added to the local session description. Finally, when
all candidates have been gathered, an event will be dispatched
to signal that the gathering process is complete.</t>
<t>Note that gathering phases only gather the candidates needed by
new/recycled/restarting m= lines; other m= lines continue to use their
existing candidates.</t>
</section>
<section title="ICE Candidate Trickling" anchor="sec.ice-candidate-trickling">
<t>Candidate trickling is a technique through which a caller may
incrementally provide candidates to the callee after the initial
offer has been dispatched; the semantics of "Trickle ICE" are
defined in <xref target="I-D.ietf-mmusic-trickle-ice"></xref>. This
process allows the callee to begin acting upon the call and setting
up the ICE (and perhaps DTLS) connections immediately, without
having to wait for the caller to gather all possible candidates.
This results in faster media setup in cases where gathering is not
performed prior to initiating the call.</t>
<t>JSEP supports optional candidate trickling by providing APIs, as
described above, that
provide control and feedback on the ICE candidate gathering process.
Applications that support candidate trickling can send the initial
offer immediately and send individual candidates when they get the
notified of a new candidate; applications that do not support this
feature can simply wait for the indication that gathering is
complete, and then create and send their offer, with all the
candidates, at this time.</t>
<t>Upon receipt of trickled candidates, the receiving application
will supply them to its ICE Agent. This triggers the ICE Agent to
start using the new remote candidates for connectivity checks.</t>
<section title="ICE Candidate Format" anchor="sec.ice-candidate-format">
<t>As with session descriptions, the syntax of the IceCandidate
object provides some abstraction, but can be easily converted to
and from the SDP candidate lines.</t>
<t>The candidate lines are the only SDP information that is
contained within IceCandidate, as they represent the only
information needed that is not present in the initial offer (i.e.,
for trickle candidates). This information is carried with the same
syntax as the "candidate-attribute" field defined for ICE. For
example:</t>
<figure>
<artwork><![CDATA[
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host
]]></artwork>
</figure>
<t>The IceCandidate object also contains fields to
indicate which m= line it should be associated with. The m= line can be
identified in one of two ways; either by a m= line index, or a MID.
The m= line index is a zero-based index, with index N referring to the
N+1th m= line in the SDP sent by the entity which sent the IceCandidate.
The MID uses the "media stream identification" attribute, as defined in
<xref target="RFC5888"></xref>, Section 4, to identify the m= line.
JSEP implementations creating an ICE Candidate object MUST populate
both of these fields. Implementations receiving an ICE Candidate
object MUST use the MID if present, or the m= line index, if not
(as it could have come from a non-JSEP endpoint).</t>
</section>
</section>
<section title="ICE Candidate Policy" anchor="sec.ice-candidate-policy">
<t>Typically, when gathering ICE candidates, the browser will gather
all possible forms of initial candidates - host, server reflexive, and
relay. However, in certain cases, applications may want to have more
specific control over the gathering process, due to privacy or related
concerns. For example, one may want to suppress the use of host
candidates, to avoid exposing information about the local network, or
go as far as only using relay candidates, to leak as little
location information as possible (note that these choices come with
corresponding operational costs). To accomplish this, the browser
MUST allow the application to restrict which ICE candidates are used
in a session. In addition, administrators may also wish to control
the set of ICE candidates, and so the browser SHOULD also allow
control via local policy, with the most restrictive policy prevailing.
</t>
<t>There may also be cases where the application wants to change which
types of candidates are used while the session is active. A prime
example is where a callee may initially want to use only relay
candidates, to avoid leaking location information to an arbitrary
caller, but then change to use all candidates (for lower operational
cost) once the user has indicated they want to take the call. For this
scenario, the browser MUST allow the candidate policy to be changed
in mid-session, subject to the aforementioned interactions with local
policy.</t>
<t>To administer the ICE candidate policy, the browser will
determine the current setting at the start of each gathering phase.
Then, during the gathering phase, the browser MUST NOT
expose candidates disallowed by the current policy to the
application, use them as the source of connectivity checks, or
indirectly expose them via other fields, such as the raddr/rport
attributes for other ICE candidates.
Later, if a different policy is specified by the application, the
application can apply it by kicking off a new gathering phase via an
ICE restart.
</t>
</section>
<section title="ICE Candidate Pool" anchor="sec.ice-candidate-pool">
<t>JSEP applications typically inform the browser to begin ICE
gathering via the information supplied to setLocalDescription, as this
is where the app specifies the number of media streams, and thereby
ICE components, for which to gather candidates. However, to accelerate
cases where the application knows the number of ICE components to use
ahead of time, it may ask the browser to gather a pool of potential
ICE candidates to help ensure rapid media setup.
</t>
<t>When setLocalDescription is eventually called, and the
browser goes to gather the needed ICE candidates, it SHOULD start by
checking if any candidates are available in the pool. If there are
candidates in the pool, they SHOULD be handed to the application
immediately via the ICE candidate event. If the pool becomes
depleted, either because a larger-than-expected number of ICE
components is used, or because the pool has not had enough time to
gather candidates, the remaining candidates are gathered as usual.
</t>
<t>One example of where this concept is useful is an application that
expects an incoming call at some point in the future, and wants to
minimize the time it takes to establish connectivity, to avoid
clipping of initial media. By pre-gathering candidates into the pool,
it can exchange and start sending connectivity checks from these
candidates almost immediately upon receipt of a call. Note though that
by holding on to these pre-gathered candidates, which will be kept
alive as long as they may be needed, the application will consume
resources on the STUN/TURN servers it is using.
</t>
</section>
</section>
<section title="Interactions With Forking" anchor="sec.interactions-with-forking">
<t>Some call signaling systems allow various types of forking where an
SDP Offer may be provided to more than one device. For example, SIP
<xref target="RFC3261"></xref> defines both a "Parallel Search" and
"Sequential Search". Although these are primarily signaling level
issues that are outside the scope of JSEP, they do have some impact on
the configuration of the media plane that is relevant. When forking
happens at the signaling layer, the Javascript application responsible
for the signaling needs to make the decisions about what media should
be sent or received at any point of time, as well as which remote
endpoint it should communicate with; JSEP is used to make sure the
media engine can make the RTP and media perform as required by the
application. The basic operations that the applications can have the
media engine do are: <list style="symbols">
<t>Start exchanging media with a given remote peer, but keep all the
resources reserved in the offer.</t>
<t>Start exchanging media with a given remote peer, and free any
resources in the offer that are not being used.</t>
</list></t>
<section title="Sequential Forking" anchor="sec.sequential-forking">
<t>Sequential forking involves a call being dispatched to multiple
remote callees, where each callee can accept the call, but only one
active session ever exists at a time; no mixing of received media is
performed.</t>
<t>JSEP handles sequential forking well, allowing the application to
easily control the policy for selecting the desired remote endpoint.
When an answer arrives from one of the callees, the application can
choose to apply it either as a provisional answer, leaving open the
possibility of using a different answer in the future, or apply it
as a final answer, ending the setup flow.</t>
<t>In a "first-one-wins" situation, the first answer will be applied
as a final answer, and the application will reject any subsequent
answers. In SIP parlance, this would be ACK + BYE.</t>
<t>In a "last-one-wins" situation, all answers would be applied as
provisional answers, and any previous call leg will be terminated.
At some point, the application will end the setup process, perhaps
with a timer; at this point, the application could reapply the
existing remote description as a final answer.</t>
</section>
<section title="Parallel Forking" anchor="sec.parallel-forking">
<t>Parallel forking involves a call being dispatched to multiple
remote callees, where each callee can accept the call, and multiple
simultaneous active signaling sessions can be established as a
result. If multiple callees send media at the same time, the
possibilities for handling this are described in Section 3.1 of
<xref target="RFC3960"></xref>. Most SIP devices today only support
exchanging media with a single device at a time, and do not try to
mix multiple early media audio sources, as that could result in a
confusing situation. For example, consider having a European
ringback tone mixed together with the North American ringback tone -
the resulting sound would not be like either tone, and would confuse
the user. If the signaling application wishes to only exchange media
with one of the remote endpoints at a time, then from a media engine
point of view, this is exactly like the sequential forking case.</t>
<t>In the parallel forking case where the Javascript application
wishes to simultaneously exchange media with multiple peers, the
flow is slightly more complex, but the Javascript application can
follow the strategy that <xref target="RFC3960"></xref> describes
using UPDATE. The UPDATE approach allows the
signaling to set up a separate media flow for each peer that it
wishes to exchange media with. In JSEP, this offer used in the
UPDATE would be formed by simply creating a new PeerConnection and
making sure that the same local media streams have been added into
this new PeerConnection. Then the new PeerConnection object would
produce a SDP offer that could be used by the signaling to perform
the UPDATE strategy discussed in <xref target="RFC3960"></xref>.</t>
<t>As a result of sharing the media streams, the application will
end up with N parallel PeerConnection sessions, each with a local
and remote description and their own local and remote addresses. The
media flow from these sessions can be managed by specifying SDP
direction attributes in the descriptions, or the application can
choose to play out the media from all sessions mixed together. Of
course, if the application wants to only keep a single session, it
can simply terminate the sessions that it no longer needs.</t>
</section>
</section>
</section>
<section title="Interface" anchor="sec.interface">
<t>This section details the basic operations that must be present to
implement JSEP functionality. The actual API exposed in the W3C API may
have somewhat different syntax, but should map easily to these
concepts.</t>
<section title="Methods" anchor="sec.methods">
<section title="Constructor" anchor="sec.constructor">
<t>The PeerConnection constructor allows the application to specify
global parameters for the media session, such as the STUN/TURN servers
and credentials to use when gathering candidates, as well as the
initial ICE candidate policy and pool size, and also the BUNDLE
policy to use.</t>
<t>If an ICE candidate policy is specified, it functions as
described in <xref target="sec.ice-candidate-policy"/>, causing the
browser to only surface the permitted candidates to the application,
and only use those candidates for connectivity checks. The set of
available policies is as follows:
<list style="hanging">
<t hangText="all:">All candidates will be gathered and used.</t>
<t></t>
<t hangText="public:">Candidates with private IP addresses
[RFC1918] will be filtered out. This prevents exposure of
internal network details, at the cost of requiring
relay usage even for intranet calls, if the NAT does not allow
hairpinning as described in [RFC4787], section 6.</t>
<t></t>
<t hangText="relay:">All candidates except relay candidates will
be filtered out. This obfuscates the location information that
might be ascertained by the remote peer from the received
candidates. Depending on how the application deploys its relay
servers, this could obfuscate location to a metro or possibly
even global level.</t>
</list>
Although it can be overridden by local policy, the default ICE
candidate policy MUST be set to allow all candidates, as this
minimizes use of application STUN/TURN server resources.</t>
<t>If a size is specified for the ICE candidate pool, this indicates
the number of ICE components to pre-gather candidates for. Because
pre-gathering results in utilizing STUN/TURN server resources for
potentially long periods of time, this must only
occur upon application request, and therefore the default
candidate pool size MUST be zero.
</t>
<t>The
application can specify its preferred policy regarding use of BUNDLE,
the multiplexing mechanism defined in <xref
target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>.
By specifying a policy from the list below, the application can
control how aggressively it will try to BUNDLE media streams together.
The set of available policies is as follows:
<list style="hanging">
<t hangText="balanced:">The application will BUNDLE all media streams of
the same type together. That is, if there are multiple audio and
multiple video MediaStreamTracks attached to a PeerConnection, all
but the first audio and video tracks will be marked as
bundle-only, and candidates will only be gathered for N media
streams, where N is the number of distinct media types. When
talking to a non-BUNDLE-aware endpoint, only the non-bundle-only
streams will be negotiated. This policy balances desire to
multiplex with the need to ensure basic audio and video still
works in legacy cases. Data channels will be in a separate bundle
group.
</t>
<t></t>
<t hangText="max-compat:"> The application will offer BUNDLE, but mark none
of its streams as bundle-only. This policy will allow all streams
to be received by non-BUNDLE-aware endpoints, but require separate
candidates to be gathered for each media stream.
</t>
<t></t>
<t hangText="max-bundle:">The application will BUNDLE all of its media
streams, including data channels,
on a single transport. All streams other than the first
will be marked as bundle-only. This policy aims to minimize
candidate gathering and maximize multiplexing, at the cost of less
compatibility with legacy endpoints.
</t>
</list>
As it provides the best tradeoff between performance and
compatibility with legacy endpoints, the default BUNDLE policy
MUST be set to "balanced".
</t>
<t>The
application can specify its preferred policy regarding use of RTP/RTCP
multiplexing <xref target="RFC5761"/> using one of the following policies:
<list style="hanging">
<t hangText="negotiate:">The browser will gather both RTP and
RTCP candidates but also will offer "a=rtcp-mux", thus allowing
for compatibility with either multiplexing or non-multiplexing endpoints.</t>
<t hangText="require:">The browser will only gather RTP candidates.
[[OPEN ISSUE: how should the answerer behave.
https://github.com/rtcweb-wg/jsep/issues/114]]
This halves the number of candidates
that the offerer needs to gather.</t>
</list>
</t>
</section>
<section title="createOffer" anchor="sec.createoffer">
<t>The createOffer method generates a blob of SDP that contains a
<xref target="RFC3264"></xref> offer with the supported
configurations for the session, including descriptions of the local
MediaStreams attached to this PeerConnection, the codec/RTP/RTCP
options supported by this implementation, and any candidates that
have been gathered by the ICE Agent. An options parameter may be
supplied to provide additional control over the generated offer.
This options parameter should allow for the following
manipulations to be performed:
</t><t>
<list style="symbols">
<t>To indicate support for a media type even if no
MediaStreamTracks of that type have been added to the session
(e.g., an audio call that wants to receive video.)</t>
<t>To trigger an ICE restart, for the purpose of reestablishing
connectivity.</t>
</list>
</t>
<t>In the initial offer, the generated SDP will contain all desired
functionality for the session (functionality that is supported but
not desired by default may be omitted); for each SDP line, the
generation of the SDP will follow the process defined for generating
an initial offer from the document that specifies the given SDP
line. The exact handling of initial offer generation is detailed in
<xref target="sec.initial-offers"/> below.</t>
<t>In the event createOffer is called after the session is
established, createOffer will generate an offer to modify the
current session based on any changes that have been made to the
session, e.g. adding or removing MediaStreams, or requesting an ICE
restart. For each existing stream, the generation of each SDP line
must follow the process defined for generating an updated offer from
the RFC that specifies the given SDP line. For each new stream,
the generation of the SDP must follow the process of generating an
initial offer, as mentioned above. If no changes have been made, or
for SDP lines that are unaffected by the requested changes, the
offer will only contain the parameters negotiated by the last
offer-answer exchange. The exact handling of subsequent offer
generation is detailed in <xref target="sec.subsequent-offers"/>. below.</t>
<t>Session descriptions generated by createOffer must be immediately
usable by setLocalDescription; if a system has limited resources
(e.g. a finite number of decoders), createOffer should return an
offer that reflects the current state of the system, so that
setLocalDescription will succeed when it attempts to acquire those
resources. Because this method may need to inspect the system state
to determine the currently available resources, it may be
implemented as an async operation.</t>
<t>Calling this method may do things such as generate new ICE
credentials, but does not result in candidate gathering, or cause
media to start or stop flowing.</t>
</section>
<section title="createAnswer" anchor="sec.createanswer">
<t>The createAnswer method generates a blob of SDP that contains a
<xref target="RFC3264"></xref> SDP answer with the supported
configuration for the session that is compatible with the parameters
supplied in the most recent call to setRemoteDescription, which MUST
have been called prior to calling createAnswer.
Like createOffer, the returned blob contains
descriptions of the local MediaStreams attached to this
PeerConnection, the codec/RTP/RTCP options negotiated for this
session, and any candidates that have been gathered by the ICE
Agent. An options parameter may be supplied to provide additional
control over the generated answer.</t>
<t>As an answer, the generated SDP will contain a specific
configuration that specifies how the media plane should be
established; for each SDP line, the generation of the SDP must
follow the process defined for generating an answer from the
document that specifies the given SDP line. The exact handling of
answer generation is detailed in <xref target="sec.generating-an-answer"/>. below.</t>
<t>Session descriptions generated by createAnswer must be
immediately usable by setLocalDescription; like createOffer, the
returned description should reflect the current state of the system.
Because this method may need to inspect the system state to
determine the currently available resources, it may need to be
implemented as an async operation.</t>
<t>Calling this method may do things such as generate new ICE
credentials, but does not trigger candidate gathering or change
media state.</t>
</section>
<section title="SessionDescriptionType" anchor="sec.sessiondescriptiontype">
<t>Session description objects (RTCSessionDescription) may be of
type "offer", "pranswer", or "answer". These types provide
information as to how the description parameter should be parsed,
and how the media state should be changed.</t>
<t>"offer" indicates that a description should be parsed as an
offer; said description may include many possible media
configurations. A description used as an "offer" may be applied
anytime the PeerConnection is in a stable state, or as an update to
a previously supplied but unanswered "offer".</t>
<t>"pranswer" indicates that a description should be parsed as an
answer, but not a final answer, and so should not result in the
freeing of allocated resources. It may result in the start of media
transmission, if the answer does not specify an inactive media
direction. A description used as a "pranswer" may be applied as a
response to an "offer", or an update to a previously sent
"pranswer".</t>
<t>"answer" indicates that a description should be parsed as an
answer, the offer-answer exchange should be considered complete, and
any resources (decoders, candidates) that are no longer needed can
be released. A description used as an "answer" may be applied as a
response to a "offer", or an update to a previously sent
"pranswer".</t>
<t>The only difference between a provisional and final answer is
that the final answer results in the freeing of any unused resources
that were allocated as a result of the offer. As such, the
application can use some discretion on whether an answer should be
applied as provisional or final, and can change the type of the
session description as needed. For example, in a serial forking
scenario, an application may receive multiple "final" answers, one
from each remote endpoint. The application could choose to accept
the initial answers as provisional answers, and only apply an answer
as final when it receives one that meets its criteria (e.g. a live
user instead of voicemail).</t>
<t>"rollback" is a special session description type implying
that the state machine should be rolled back to the previous
state, as described in <xref target="sec.rollback"/>.
The contents MUST be empty.</t>
<section title="Use of Provisional Answers" anchor="sec.use-of-provisional-answer">
<t>Most web applications will not need to create answers using the
"pranswer" type. While it is good practice to send an immediate
response to an "offer", in order to warm up the session transport
and prevent media clipping, the preferred handling for a web
application would be to create and send an "inactive" final answer
immediately after receiving the offer. Later, when the called
user actually accepts the call, the application can create a new
"sendrecv" offer to update the previous offer/answer pair and start
the media flow. While this could also be done with an inactive
"pranswer", followed by a sendrecv "answer", the initial "pranswer"
leaves the offer-answer exchange open, which means that
neither side can send an updated offer during this time.</t>
<t>As an example, consider a typical web application that will
set up a data channel, an audio channel, and a video channel. When
an endpoint receives an offer with these channels, it could send an
answer accepting the data channel for two-way data, and accepting
the audio and video tracks as inactive or receive-only. It could
then ask the user to accept the call, acquire the local media
streams, and send a new offer to the remote side moving the audio
and video to be two-way media. By the time the human has accepted
the call and triggered the new offer, it is likely that the ICE and
DTLS handshaking for all the channels will already have finished.</t>
<t>Of course, some applications may not be able to perform this
double offer-answer exchange, particularly ones that are attempting
to gateway to legacy signaling protocols. In these cases, "pranswer"
can still provide the application with a mechanism to warm up the
transport.</t>
</section>
<section title="Rollback" anchor="sec.rollback">
<t>In certain situations it may be desirable to "undo" a change
made to setLocalDescription or setRemoteDescription. Consider a
case where a call is ongoing, and one side wants to change some of
the session parameters; that side generates an updated offer and
then calls setLocalDescription. However, the remote side, either
before or after setRemoteDescription, decides it does not want to
accept the new parameters, and sends a reject message back to the
offerer. Now, the offerer, and possibly the answerer as well, need
to return to a stable state and the previous local/remote
description. To support this, we introduce the concept of
"rollback".</t>
<t>A rollback discards any proposed changes to the session,
returning the state machine to the stable state, and setting the
modified local and/or remote description back to their previous
values. Any resources or candidates that were allocated by the
abandoned local description are discarded; any media that is
received will be processed according to the previous local and
remote descriptions. Rollback can only be used to cancel proposed
changes; there is no support for rolling back from a stable state to
a previous stable state. Note that this implies that once the answerer
has performed setLocalDescription with his answer, this cannot
be rolled back.
</t>
<t>A rollback is performed by supplying a session description of
type "rollback" with empty contents to either setLocalDescription or
setRemoteDescription, depending on which was most recently used
(i.e. if the new offer was supplied to setLocalDescription, the
rollback should be done using setLocalDescription as well).
</t>
</section>
</section>
<section title="setLocalDescription" anchor="sec.setlocaldescription">
<t>The setLocalDescription method instructs the PeerConnection to
apply the supplied SDP blob as its local configuration. The type
field indicates whether the blob should be processed as an offer,
provisional answer, or final answer; offers and answers are checked
differently, using the various rules that exist for each SDP
line.</t>
<t>This API changes the local media state; among other things, it
sets up local resources for receiving and decoding media. In order
to successfully handle scenarios where the application wants to
offer to change from one media format to a different, incompatible
format, the PeerConnection must be able to simultaneously support
use of both the old and new local descriptions (e.g. support codecs
that exist in both descriptions) until a final answer is received,
at which point the PeerConnection can fully adopt the new local
description, or roll back to the old description if the remote side
denied the change.</t>
<t>This API indirectly controls the candidate gathering process.
When a local description is supplied, and the number of transports
currently in use does not match the number of transports needed by
the local description, the PeerConnection will create transports as
needed and begin gathering candidates for them.</t>
<t>If setRemoteDescription was previous called with an offer, and
setLocalDescription is called with an answer (provisional or final),
and the media directions are compatible, and media are available to
send, this will result in the starting of media transmission.</t>
</section>
<section title="setRemoteDescription" anchor="sec.setremotedescription">
<t>The setRemoteDescription method instructs the PeerConnection to
apply the supplied SDP blob as the desired remote configuration. As
in setLocalDescription, the type field of the indicates how the blob
should be processed.</t>
<t>This API changes the local media state; among other things, it
sets up local resources for sending and encoding media.</t>
<t>If setLocalDescription was previously called with an offer, and
setRemoteDescription is called with an answer (provisional or final),
and the media directions are compatible, and media are available to
send, this will result in the starting of media transmission.</t>
</section>
<section title="localDescription" anchor="sec.localdescription">
<t>The localDescription method returns a copy of the current local
configuration, i.e. what was most recently passed to
setLocalDescription, plus any local candidates that have been
generated by the ICE Agent.</t>
<t>[[OPEN ISSUE: Do we need to expose accessors for both the current and
proposed local description?
https://github.com/rtcweb-wg/jsep/issues/16]]</t>
<t>A null object will be returned if the local description has not
yet been established.</t>
</section>
<section title="remoteDescription" anchor="sec.remotedescription">
<t>The remoteDescription method returns a copy of the current remote
configuration, i.e. what was most recently passed to
setRemoteDescription, plus any remote candidates that have been
supplied via processIceMessage.</t>
<t>[[OPEN ISSUE: Do we need to expose accessors for both the current and
proposed remote description?
https://github.com/rtcweb-wg/jsep/issues/16]]</t>
<t>A null object will be returned if the remote description has not
yet been established.</t>
</section>
<section title="canTrickleIceCandidates" anchor="sec.cantrickle">
<t>
The canTrickleIceCandidates property indicates whether the remote
side supports receiving trickled candidates. There are three
potential values:
<list style="hanging">
<t hangText="null:">No SDP has been received from the other side,
so it is not known if it can handle trickle. This is the initial
value before setRemoteDescription() is called.</t>
<t hangText="true:">SDP has been received from the other side
indicating that it can support trickle.</t>
<t hangText="false:">SDP has been received from the other side
indicating that it cannot support trickle.</t>
</list>
</t>
<t>As described in <xref target="sec.ice-candidate-trickling"/>, JSEP
implementations always provide candidates to the application
individually, consistent with what is needed for Trickle ICE.
However, applications can use the canTrickleIceCandidates property to
determine whether their peer can actually do Trickle ICE, i.e.,
whether it is safe to send an initial offer or answer followed later
by candidates as they are gathered. As "true" is the only value that
definitively indicates remote Trickle ICE support, an application
which compares canTrickleIceCandidates against "true" will by default
attempt Half Trickle on initial offers and Full Trickle on subsequent
interactions with a Trickle ICE-compatible agent.
</t>
</section>
<section title="setConfiguration" anchor="sec.setconfiguration">
<t>The setConfiguration method allows the global configuration of the
PeerConnection, which was initially set by constructor parameters, to
be changed during the session. The effects of this method call depend
on when it is invoked, and differ depending on which specific
parameters are changed:</t>
<t><list style="symbols">
<t>Any changes to the STUN/TURN servers to use affect
the next gathering phase. If gathering has already occurred, this
will cause the next call to createOffer to generate new ICE
credentials, for the purpose of forcing an ICE restart and kicking
off a new gathering phase, in which the new servers will be used.
If the ICE candidate pool has a nonzero size, any existing
candidates will be discarded, and new candidates will be gathered
from the new servers.
</t>
<t>Any changes to the ICE candidate policy also affect the next
gathering phase, in similar fashion to the server changes described
above. Note though that changes to the policy have no effect on
the candidate pool, because pooled candidates are not surfaced to
the application until a gathering phase occurs, and so any
necessary filtering can still be done on any pooled candidates.
</t>
<t>Any changes to the ICE candidate pool size take effect
immediately; if increased, additional candidates are pre-gathered;
if decreased, the now-superfluous candidates are discarded.
</t>
<t>The BUNDLE and RTCP-multiplexing policies MUST NOT be
changed after the construction of the PeerConnection.
</t>
</list></t>
<t>This call may result in a change to the state of the ICE Agent,
and may result in a change to media state if it results in
connectivity being established.</t>
</section>
<section title="addIceCandidate" anchor="sec.addicecandidate">
<t>The addIceCandidate method provides a remote candidate to the ICE
Agent, which, if parsed successfully, will be added to the remote
description according to the rules defined for Trickle ICE.
Connectivity checks will be sent to the new candidate.</t>
<t>This call will result in a change to the state of the ICE Agent,
and may result in a change to media state if it results in
connectivity being established.</t>
</section>
</section>
</section>
<section title="SDP Interaction Procedures" anchor="sec.sdp-interaction-procedure">
<t>This section describes the specific procedures to be followed when
creating and parsing SDP objects.</t>
<section title="Requirements Overview" anchor="sec.requirements-overview">
<t>JSEP implementations must comply with the specifications listed
below that govern the creation and processing of offers and answers.
</t>
<t>The first set of specifications is the "mandatory-to-implement" set.
All implementations must support these behaviors, but may not use all
of them if the remote side, which may not be a JSEP endpoint, does not
support them.</t>
<t>The second set of specifications is the "mandatory-to-use" set.
The local JSEP endpoint and any remote endpoint must indicate support
for these specifications in their session descriptions.</t>
<section title="Implementation Requirements" anchor="sec.implementation-requiremen">
<t>This list of mandatory-to-implement specifications is derived
from the requirements outlined in
<xref target="I-D.ietf-rtcweb-rtp-usage"></xref>.
<list style="format R-%d">
<t><xref target="RFC4566"></xref> is the base SDP specification
and MUST be implemented.</t>
<t><xref target="RFC5764"></xref> MUST be supported for signaling
the UDP/TLS/RTP/SAVPF <xref target="RFC5764"/> and TCP/DTLS/RTP/SAVPF
<xref target="I-D.nandakumar-mmusic-proto-iana-registration"/>
RTP profiles.
</t>
<t><xref target="RFC5245"></xref> MUST be implemented for
signaling the ICE credentials and candidate lines corresponding
to each media stream. The ICE implementation MUST be a Full
implementation, not a Lite implementation.</t>
<t><xref target="RFC5763"></xref> MUST be implemented to signal
DTLS certificate fingerprints.</t>
<t><xref target="RFC4568"></xref> MUST NOT be implemented to
signal SDES SRTP keying information.</t>
<t>The <xref target="RFC5888"></xref> grouping framework MUST
be implemented for signaling grouping information, and MUST be
used to identify m= lines via the a=mid attribute.</t>
<t><xref target="I-D.ietf-mmusic-msid"></xref> MUST be
supported, in order to signal associations between RTP objects
and W3C MediaStreams and MediaStreamTracks in a standard way.
</t>
<t>The bundle mechanism in <xref
target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref> MUST be
supported to signal the ability to multiplex RTP streams on a
single UDP port, in order to avoid excessive use of port number
resources.</t>
<t>The SDP attributes of "sendonly", "recvonly", "inactive", and
"sendrecv" from <xref target="RFC4566"></xref> MUST be
implemented to signal information about media direction.</t>
<t><xref target="RFC5576"></xref> MUST be implemented to signal
RTP SSRC values and grouping semantics.</t>
<t><xref target="RFC4585"></xref> MUST be implemented to signal
RTCP based feedback.</t>
<t><xref target="RFC5761"></xref> MUST be implemented to signal
multiplexing of RTP and RTCP.</t>
<t><xref target="RFC5506"></xref> MUST be implemented to signal
reduced-size RTCP messages.</t>
<t><xref target="RFC4588"></xref> MUST be implemented to signal
RTX payload type associations.</t>
<t><xref target="RFC3556"></xref> with bandwidth modifiers MAY
be supported for specifying RTCP bandwidth as a fraction of the
media bandwidth, RTCP fraction allocated to the senders and
setting maximum media bit-rate boundaries.</t>
<t>TODO: any others?</t>
</list></t>
<t>As required by <xref target="RFC4566"></xref>, Section 5.13, JSEP
implementations MUST ignore unknown attribute (a=) lines.</t>
</section>
<section title="Usage Requirements" anchor="sec.usage-requirements">
<t>All session descriptions handled by JSEP endpoints,
both local and remote, MUST indicate support for the following
specifications. If any of these are absent, this omission MUST be
treated as an error. <list style="format R-%d">
<t>ICE, as specified in <xref target="RFC5245"></xref>,
MUST be used. Note that the remote endpoint may use a Lite
implementation; implementations MUST properly handle remote
endpoints which do ICE-Lite.</t>
<t>DTLS <xref target="RFC6347"/> or DTLS-SRTP <xref target="RFC5763"></xref>,
MUST be used, as appropriate for the media type, as
specified in <xref target="I-D.ietf-rtcweb-security-arch"/></t>
</list></t>
</section>
<section title="Profile Names and Interoperability" anchor="sec.profile-names">
<t>
For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/
RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of
these two profiles for each media m= line they produce in an offer.
For data m= sections, JSEP endpoints must support both the "UDP/DTLS/SCTP"
and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two
profiles for each data m= line they produce in an offer.
Because ICE can select either TCP or UDP transport depending on
network conditions, both advertisements are consistent with
ICE eventually selecting either either UDP or TCP.
</t>
<t>
Unfortunately, in an attempt at compatibility, some endpoints
generate other profile strings even when they mean to support one of
these profiles. For instance, an endpoint might generate "RTP/AVP"
but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating
its willingness to support "(UDP,TCP)/TLS/RTP/SAVPF". In order to
simplify compatibility with such endpoints, JSEP endpoints MUST
follow the following rules when processing the media m= sections in
an offer:
</t>
<t>
<list style="symbols">
<t>The profile in any "m=" line in any answer MUST exactly match the profile
provided in the offer.</t>
<t>Any profile matching the following patterns MUST be accepted:
"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]"</t>
<t>Because DTLS-SRTP is REQUIRED, the choice of SAVP or
AVP has no effect; support for DTLS-SRTP is determined by the presence
of the "a=fingerprint" attribute. Note that lack of an "a=fingerprint"
attribute will lead to negotiation failure.
</t>
<t>The use of AVPF or AVP simply controls the timing
rules used for RTCP feedback. If AVPF is provided, or an "a=rtcp-fb"
attribute is present, assume AVPF timing, i.e. a default value of
"trr-int=0". Otherwise, assume that AVPF is being used in
an AVP compatible mode and use AVP timing, i.e., "trr-int=4".</t>
<t>For data m= sections, JSEP endpoints MUST support receiving the "UDP/
DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards
compatibility) profiles.</t>
</list>
</t>
<t> Note that re-offers by JSEP endpoints MUST use the correct profile
strings even if the initial offer/answer exchange used an (incorrect)
older profile string.</t>
</section>
</section>
<section anchor="sec-create-offer" title="Constructing an Offer">
<t>When createOffer is called, a new SDP description must be created
that includes the functionality specified in <xref
target="I-D.ietf-rtcweb-rtp-usage"></xref>. The exact details of this
process are explained below.</t>
<section title="Initial Offers" anchor="sec.initial-offers">
<t>When createOffer is called for the first time, the result is
known as the initial offer.</t>
<t>The first step in generating an initial offer is to generate
session-level attributes, as specified in <xref
target="RFC4566"></xref>, Section 5. Specifically: <list
style="symbols">
<t>The first SDP line MUST be "v=0", as specified in <xref
target="RFC4566"></xref>, Section 5.1</t>
<t>The second SDP line MUST be an "o=" line, as specified in
<xref target="RFC4566"></xref>, Section 5.2. The value of the
<username> field SHOULD be "-". The value of the
<sess-id> field SHOULD be a cryptographically random
number. To ensure uniqueness, this number SHOULD be at least 64
bits long. The value of the <sess-version> field SHOULD be
zero. The value of the <nettype> <addrtype>
<unicast-address> tuple SHOULD be set to a non-meaningful
address, such as IN IP4 0.0.0.0, to prevent leaking the local
address in this field. As mentioned in <xref
target="RFC4566"></xref>, the entire o= line needs to be unique,
but selecting a random number for <sess-id> is sufficient
to accomplish this.</t>
<t>The third SDP line MUST be a "s=" line, as specified in <xref
target="RFC4566"></xref>, Section 5.3; to match the "o=" line, a
single dash SHOULD be used as the session name, e.g. "s=-".
Note that this differs from the advice in <xref target="RFC4566"/>
which proposes a single space, but as both "o=" and "s="
are meaningless, having the same meaningless value seems clearer.
</t>
<t>Session Information ("i="), URI ("u="), Email Address ("e="),
Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and
Time Zones ("z=") lines are not useful in this context and
SHOULD NOT be included.</t>
<t>Encryption Keys ("k=") lines do not provide sufficient
security and MUST NOT be included.</t>
<t>A "t=" line MUST be added, as specified in <xref
target="RFC4566"></xref>, Section 5.9; both <start-time>
and <stop-time> SHOULD be set to zero, e.g. "t=0 0".</t>
<t>An "a=msid-semantic:WMS" line MUST be added, as specified in
<xref target="I-D.ietf-mmusic-msid"></xref>, Section 4.</t>
</list></t>
<t>The next step is to generate m= sections, as specified in
<xref target="RFC4566"/> Section 5.14, for each
MediaStreamTrack that has been added to the PeerConnection via the
addStream method. (Note that this method takes a MediaStream, which
can contain multiple MediaStreamTracks, and therefore multiple m=
sections can be generated even if addStream is only called once.)
m=sections MUST be sorted first by the order in which the
MediaStreams were added to the PeerConnection, and
then by the alphabetical ordering of the media type for the MediaStreamTrack.
For example, if a MediaStream containing both an audio and a video
MediaStreamTrack is added to a PeerConnection, the resultant m=audio
section will precede the m=video section. If a second MediaStream
containing an audio MediaStreamTrack was added, it would follow
the m=video section.</t>
<t>Each m= section, provided it is not being bundled into
another m= section, MUST generate a unique set of ICE credentials
and gather its own unique set of ICE candidates. Otherwise, it MUST
use the same ICE credentials and candidates as the m= section
into which it is being bundled. Note that this means
that for offers, any m= sections which are not bundle-only
MUST have unique ICE credentials and candidates, since it is
possible that the answerer will accept them without bundling
them.
</t>
<t>For DTLS, all m= sections MUST use the certificate for the
identity that has been specified for the PeerConnection; as a result,
they MUST all have the same <xref target="RFC4572"></xref> fingerprint
value, or this value MUST be a session-level attribute.</t>
<t>Each m= section should be generated as specified in <xref
target="RFC4566"></xref>, Section 5.14. For the m= line itself, the
following rules MUST be followed:<list style="symbols">
<t>The port value is set to the port of the default ICE candidate
for this m= section, but given that no candidates have yet been
gathered, the "dummy" port value of 9 (Discard) MUST be used, as
indicated in <xref target="I-D.ietf-mmusic-trickle-ice"></xref>,
Section 5.1.</t>
<t>To properly indicate use of DTLS, the <proto> field MUST
be set to "UDP/TLS/RTP/SAVPF", as specified in
<xref target="RFC5764"/>, Section 8,
if the default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF",
as specified in<xref target="I-D.nandakumar-mmusic-proto-iana-registration"/>
if the default candidate uses TCP transport.</t>
</list>
</t>
<t>The m= line MUST be followed immediately by a "c=" line, as specified
in <xref target="RFC4566"></xref>, Section 5.7. Again, as no candidates
have yet been gathered, the "c=" line must contain the "dummy" value
"IN IP6 ::", as defined in <xref target="I-D.ietf-mmusic-trickle-ice"></xref>,
Section 5.1.</t>
<t>Each m= section MUST include the following attribute lines:
<list style="symbols">
<t>An "a=mid" line, as specified in <xref
target="RFC5888"></xref>, Section 4. When generating mid values,
it is RECOMMENDED that the values be 3 bytes or less, to allow
them to efficiently fit into the RTP header extension defined in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>,
Section 11.</t>
<t>An "a=rtcp" line, as specified in <xref target="RFC3605"></xref>,
Section 2.1, containing the dummy value "9 IN IP6 ::", because
no candidates have yet been gathered.</t>
<t>An "a=msid" line, as specified in <xref
target="I-D.ietf-mmusic-msid"></xref>, Section 2.</t>
<t>An "a=sendrecv" line, as specified in <xref
target="RFC3264"></xref>, Section 5.1.</t>
<t>For each supported codec, "a=rtpmap" and "a=fmtp" lines, as
specified in <xref target="RFC4566"></xref>, Section 6.
The audio and video codecs that MUST be supported are
specified in <xref
target="I-D.ietf-rtcweb-audio"></xref> (see Section 3) and <xref
target="I-D.ietf-rtcweb-video"></xref> (see Section 5).</t>
<t>If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as
specified in <xref target="RFC4566"></xref>, Section 6.</t>
<t>For each primary codec where RTP retransmission should be
used, a corresponding "a=rtpmap" line indicating "rtx" with the
clock rate of the primary codec and an "a=fmtp" line that
references the payload type of the primary codec, as specified
in <xref target="RFC4588"></xref>, Section 8.1.</t>
<t>For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
as specified in <xref target="RFC4566"></xref>, Section 6. The
FEC mechanisms that MUST be supported are specified in
<xref target="I-D.ietf-rtcweb-fec"></xref>, Section 6, and
specific usage for each media type is outlined in Sections 4
and 5.</t>
<t>"a=ice-ufrag" and "a=ice-passwd" lines, as specified in <xref
target="RFC5245"></xref>, Section 15.4.</t>
<t>An "a=ice-options" line, with the "trickle" option, as
specified in <xref target="I-D.ietf-mmusic-trickle-ice"></xref>,
Section 4.</t>
<t>An "a=fingerprint" line, as specified in <xref
target="RFC4572"></xref>, Section 5; the algorithm used for the
fingerprint MUST match that used in the certificate signature.
</t>
<t>An "a=setup" line, as specified in <xref
target="RFC4145"></xref>, Section 4, and clarified for use in
DTLS-SRTP scenarios in <xref target="RFC5763"></xref>, Section
5. The role value in the offer MUST be "actpass".</t>
<t>An "a=rtcp-mux" line, as specified in <xref
target="RFC5761"></xref>, Section 5.1.1.</t>
<t>An "a=rtcp-rsize" line, as specified in <xref
target="RFC5506"></xref>, Section 5.</t>
<t>For each supported RTP header extension, an "a=extmap" line,
as specified in <xref target="RFC5285"></xref>, Section 5. The
list of header extensions that SHOULD/MUST be supported is
specified in <xref target="I-D.ietf-rtcweb-rtp-usage"></xref>,
Section 5.2. Any header extensions that require encryption MUST
be specified as indicated in <xref target="RFC6904"></xref>,
Section 4.</t>
<t>For each supported RTCP feedback mechanism, an "a=rtcp-fb"
mechanism, as specified in <xref target="RFC4585"></xref>,
Section 4.2. The list of RTCP feedback mechanisms that
SHOULD/MUST be supported is specified in <xref
target="I-D.ietf-rtcweb-rtp-usage"></xref>, Section 5.1.</t>
<t>An "a=ssrc" line, as specified in <xref
target="RFC5576"></xref>, Section 4.1, indicating the SSRC to be
used for sending media, along with the mandatory "cname" source
attribute, as specified in Section 6.1, indicating the CNAME for
the source. The CNAME must be generated in accordance with
<xref target="RFC7022"></xref>. [OPEN ISSUE: How are CNAMEs
specified for MSTs? Are they randomly generated for each
MediaStream? If so, can two MediaStreams be synced?
See: https://github.com/rtcweb-wg/jsep/issues/4]</t>
<t>If RTX is supported for this media type, another "a=ssrc"
line with the RTX SSRC, and an "a=ssrc-group" line, as specified
in <xref target="RFC5576"></xref>, section 4.2, with semantics
set to "FID" and including the primary and RTX SSRCs.</t>
<t>If FEC is supported for this media type, another "a=ssrc"
line with the FEC SSRC, and an "a=ssrc-group" line with semantics
set to "FEC-FR" and including the primary and FEC SSRCs, as
specified in <xref target="RFC5956"></xref>, section 4.3. For
simplicity, if both RTX and FEC are supported, the FEC SSRC
MUST be the same as the RTX SSRC.</t>
<t>[OPEN ISSUE: Handling of a=imageattr]</t>
<t>If the BUNDLE policy for this PeerConnection is set to
"max-bundle", and this is not the first m= section, or the BUNDLE
policy is set to "balanced", and this is not the first m= section
for this media type, an "a=bundle-only" line.</t>
</list></t>
<t>Lastly, if a data channel has been created, a m= section MUST be
generated for data. The <media> field MUST be set to
"application" and the <proto> field MUST be set to
"UDP/DTLS/SCTP" if the default candidate uses UDP transport,
or "TCP/DTLS/SCTP" if the default candidate uses TCP transport <xref
target="I-D.ietf-mmusic-sctp-sdp"></xref>. The "fmt" value
MUST be set to the SCTP port number, as specified in Section 4.1.
[TODO: update this to use a=sctp-port, as indicated in the latest
data channel docs]</t>
<t>Within the data m= section, the "a=mid",
"a=ice-ufrag", "a=ice-passwd", "a=ice-options", "a=candidate",
"a=fingerprint", and "a=setup" lines MUST be included as mentioned
above, along with an "a=sctpmap" line referencing the SCTP port number
and specifying the application protocol indicated in <xref
target="I-D.ietf-rtcweb-data-protocol"></xref>. [OPEN ISSUE: the -01
of this document is missing this information.]</t>
<t>Once all m= sections have been generated, a session-level
"a=group" attribute MUST be added as specified in <xref
target="RFC5888"></xref>. This attribute MUST have semantics
"BUNDLE", and MUST include the mid identifiers of each m= section.
The effect of this is that the browser offers all m= sections as one
BUNDLE group. However, whether the m= sections are bundle-only
or not depends on the BUNDLE policy.
</t>
<t>Attributes which SDP permits to either be at the session
level or the media level SHOULD generally be at the media
level even if they are identical. This promotes readability,
especially if one of a set of initially identical attributes
is subsequently changed.
</t>
<t>Attributes other than the ones specified above MAY be included,
except for the following attributes which are specifically
incompatible with the requirements of <xref
target="I-D.ietf-rtcweb-rtp-usage"></xref>, and MUST NOT be
included: <list style="symbols">
<t>"a=crypto"</t>
<t>"a=key-mgmt"</t>
<t>"a=ice-lite"</t>
</list></t>
<t>Note that when BUNDLE is used, any additional attributes that are
added MUST follow the advice in <xref
target="I-D.ietf-mmusic-sdp-mux-attributes"></xref> on how
those attributes interact with BUNDLE.</t>
<t>Note that these requirements are in some cases stricter than those
of SDP. Implementations MUST be prepared to accept compliant SDP
even if it would not conform to the requirements for generating
SDP in this specification.</t>
</section>
<section title="Subsequent Offers" anchor="sec.subsequent-offers">
<t>When createOffer is called a second (or later) time, or is called
after a local description has already been installed, the processing
is somewhat different than for an initial offer.</t>
<t>If the initial offer was not applied using setLocalDescription,
meaning the PeerConnection is still in the "stable" state, the steps
for generating an initial offer should be followed, subject to the
following restriction: <list style="symbols">
<t>The fields of the "o=" line MUST stay the same except for the
<session-version> field, which MUST increment if the session
description changes in any way, including the addition of
ICE candidates.</t>
</list>
</t>
<t>If the initial offer was applied using setLocalDescription, but
an answer from the remote side has not yet been applied, meaning the
PeerConnection is still in the "local-offer" state, an offer is
generated by following the steps in the "stable" state above, along
with these exceptions: <list style="symbols">
<t>The "s=" and "t=" lines MUST stay the same.</t>
<t>Each "m=" and c=" line MUST be filled in with the port, protocol,
and address of the default candidate for the m= section, as described
in <xref target="RFC5245"></xref>, Section 4.3. Each
"a=rtcp" attribute line MUST also be filled in with the port and
address of the appropriate default candidate, either the
default RTP or RTCP candidate, depending on whether RTCP multiplexing
is currently active or not. Note that if RTCP
multiplexing is being offered, but not yet active, the default RTCP
candidate MUST be used, as indicated in <xref target="RFC5761"></xref>,
section 5.1.3. In each case, if no candidates of the desired
type have yet been gathered, dummy values MUST be used, as
described above.</t>
<t>Each "a=mid" line MUST stay the same.</t>
<t>Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the
same, unless the ICE configuration has changed (either changes to
the supported STUN/TURN servers, or the ICE candidate policy), or
the "IceRestart" option (<xref target="sec.icerestart"/>
was specified.
</t>
<t>Within each m= section, for each candidate that has
been gathered during the most recent gathering phase
(see <xref target="sec.ice-gather-overview"></xref>),
an "a=candidate" line MUST be added, as specified in <xref
target="RFC5245"></xref>, Section 4.3., paragraph 3. If
candidate gathering for the section has completed, an
"a=end-of-candidates" attribute MUST be added, as described in
<xref target="I-D.ietf-mmusic-trickle-ice"></xref>, Section 9.3.
</t>
<t>For MediaStreamTracks that are still present, the "a=msid",
"a=ssrc", and "a=ssrc-group" lines MUST stay the same.</t>
<t>If any MediaStreamTracks have been removed, either through
the removeStream method or by removing them from an added
MediaStream, their m= sections MUST be marked as recvonly by
changing the value of the <xref target="RFC3264"></xref>
directional attribute to "a=recvonly". The "a=msid", "a=ssrc",
and "a=ssrc-group" lines MUST be removed from the associated m=
sections.</t>
<t>If any MediaStreamTracks have been added, and there exist
m= sections of the appropriate media type with no associated
MediaStreamTracks (i.e. as described in the preceding paragraph),
those m= sections MUST be recycled by adding the new
MediaStreamTrack to the m= section. This is done by adding the
necessary "a=msid", "a=ssrc", and "a=ssrc-group" lines to the
recycled m= section, and removing the "a=recvonly" attribute.
</t>
</list></t>
<t>If the initial offer was applied using setLocalDescription, and
an answer from the remote side has been applied using
setRemoteDescription, meaning the PeerConnection is in the
"remote-pranswer" or "stable" states, an offer is generated based on
the negotiated session descriptions by following the steps mentioned
for the "local-offer" state above, along with these exceptions:
[OPEN ISSUE: should this be permitted in the remote-pranswer state?]
<list style="symbols">
<t>If a m= section exists in the current local description, but
does not have an associated local MediaStreamTrack (possibly
because said MediaStreamTrack was removed since the last
exchange), a m= section MUST still be generated in the new offer,
as indicated in <xref target="RFC3264"></xref>, Section 8. The
disposition of this section will depend on the state of the
remote MediaStreamTrack associated with this m= section. If one
exists, and it is still in the "live" state, the new m= section
MUST be marked as "a=recvonly", with no "a=msid" or related
attributes present. If no remote MediaStreamTrack
exists, or it is in the "ended" state, the m= section MUST be
marked as rejected, by setting the port to zero, as indicated in
<xref target="RFC3264"></xref>, Section 8.2.</t>
<t>If any MediaStreamTracks have been added, and there exist
recvonly m= sections of the appropriate media type with no
associated MediaStreamTracks, or rejected m= sections of any
media type, those m= sections MUST be recycled, and a
local MediaStreamTrack associated with these recycled m=
sections until all such existing m= sections have been
used. This includes any recvonly or rejected m= sections
created by the preceding paragraph.</t>
</list></t>
<t>In addition, for each non-recycled, non-rejected m=
section in the new offer, the following adjustments are made based
on the contents of the corresponding m= section in the current
remote description: <list style="symbols">
<t>The m= line and corresponding "a=rtpmap" and "a=fmtp" lines
MUST only include codecs present in the remote description.</t>
<t>The RTP header extensions MUST only include those that are
present in the remote description.</t>
<t>The RTCP feedback extensions MUST only include those that are
present in the remote description.</t>
<t>The "a=rtcp-mux" line MUST only be added if present in the
remote description.</t>
<t>The "a=rtcp-rsize" line MUST only be added if present in the
remote description.</t>
</list></t>
<t>The "a=group:BUNDLE" attribute MUST include the mid identifiers
specified in the BUNDLE group in the most recent answer, minus any
m= sections that have been marked as rejected, plus any newly added
or re-enabled m= sections. In other words, the BUNDLE attribute must
contain all m= sections that were previously bundled, as long as
they are still alive, as well as any new m= sections.</t>
</section>
<section title="Options Handling" anchor="sec.options-handling1">
<t>The createOffer method takes as a parameter an RTCOfferOptions
object. Special processing is performed when generating a SDP
description if the following options are present.</t>
<section title="OfferToReceiveAudio" anchor="sec.offertoreceiveaudio">
<t>If the "OfferToReceiveAudio" option is specified, with an integer
value of N, and M audio MediaStreamTracks have been added to the
PeerConnection, the offer MUST include N non-rejected m= sections
with media type "audio", even if N is greater than M.
This allows the offerer to receive audio, including multiple independent
streams, even when not sending it; accordingly, the directional
attribute on the N-M audio m= sections without associated
MediaStreamTracks MUST be set to recvonly.</t>
<t>If N is set to a value less than M, the offer MUST mark the
m= sections associated with the M-N most recently added
(since the last setLocalDescription) MediaStreamTracks as sendonly.
This allows the offerer to indicate that it does not want to receive
audio on some or all of its newly created streams.
For m= sections that have previously
been negotiated, this setting has no effect. [TODO: refer to
RTCRtpSender in the future]
</t>
<t>For backwards compatibility with pre-standard
versions of this specification, a value of "true"
is interpreted as equivalent to N=1, and "false" as N=0.
</t>
</section>
<section title="OfferToReceiveVideo" anchor="sec.offertoreceivevideo">
<t>If the "OfferToReceiveVideo" option is specified, with an integer
value of N, and M video MediaStreamTracks have been added to the
PeerConnection, the offer MUST include N non-rejected m= sections
with media type "video", even if N is greater than M.
This allows the offerer to receive video, including multiple independent
streams, even when not sending it; accordingly, the directional
attribute on the N-M video m= sections without associated
MediaStreamTracks MUST be set to recvonly.</t>
<t>If N is set to a value less than M, the offer MUST mark the
m= sections associated with the M-N most recently added
(since the last setLocalDescription) MediaStreamTracks as sendonly.
This allows the offerer to indicate that it does not want to receive
video on some or all of its newly created streams.
For m= sections that have previously
been negotiated, this setting has no effect. [TODO: refer to
RTCRtpSender in the future]
</t>
<t>For backwards compatibility with pre-standard
versions of this specification, a value of "true"
is interpreted as equivalent to N=1, and "false" as N=0.
</t>
</section>
<section title="IceRestart" anchor="sec.icerestart">
<t>If the "IceRestart" option is specified, with a value of
"true", the offer MUST indicate an ICE restart by generating new
ICE ufrag and pwd attributes, as specified in <xref
target="RFC5245"></xref>, Section
9.1.1.1. If this option is specified on an initial offer, it
has no effect (since a new ICE ufrag and pwd are already
generated). Similarly, if the ICE configuration has changed, this
option has no effect, since new ufrag and pwd attributes will be
generated automatically. This option is primarily useful for
reestablishing connectivity in cases where failures are detected by
the application.
</t>
</section>
<section title="VoiceActivityDetection" anchor="sec.voiceactivitydetection1">
<t>If the "VoiceActivityDetection" option is specified, with a
value of "true", the offer MUST indicate support for silence
suppression in the audio it receives by including comfort noise
("CN") codecs for each offered audio codec, as specified in <xref
target="RFC3389"></xref>, Section 5.1, except for codecs that have their
own internal silence suppression support. For codecs that have their own
internal silence suppression support, the appropriate fmtp parameters
for that codec MUST be specified to indicate that silence suppression for
received audio is desired. For example, when using the Opus codec, the
"usedtx=1" parameter would be specified in the offer.
This option allows the endpoint to significantly reduce the amount of
audio bandwidth it receives, at the cost of some fidelity, depending on
the quality of the remote VAD algorithm.</t>
</section>
</section>
</section>
<section title="Generating an Answer" anchor="sec.generating-an-answer">
<t>When createAnswer is called, a new SDP description must be created
that is compatible with the supplied remote description as well as the
requirements specified in <xref
target="I-D.ietf-rtcweb-rtp-usage"></xref>. The exact details of this
process are explained below.</t>
<section title="Initial Answers" anchor="sec.initial-answers">
<t>When createAnswer is called for the first time after a remote
description has been provided, the result is known as the initial
answer. If no remote description has been installed, an answer
cannot be generated, and an error MUST be returned.</t>
<t>Note that the remote description SDP may not have been created by
a JSEP endpoint and may not conform to all the requirements listed
in <xref target="sec-create-offer"></xref>. For many cases, this is
not a problem. However, if any mandatory SDP attributes are missing,
or functionality listed as mandatory-to-use above is not present,
this MUST be treated as an error, and MUST cause the affected
m= sections to be marked as rejected.</t>
<t>The first step in generating an initial answer is to generate
session-level attributes. The process here is identical to that
indicated in the Initial Offers section above.</t>
<t>The next step is to generate m= sections for each m= section that
is present in the remote offer, as specified in <xref
target="RFC3264"></xref>, Section 6. For the purposes of this
discussion, any session-level attributes in the offer that are also
valid as media-level attributes SHALL be considered to be present in
each m= section.</t>
<t>The next step is to go through each offered m= section.
If there is a local MediaStreamTrack of the same type which has been
added to the PeerConnection via addStream and not yet associated
with a m= section, and the specific m= section is either sendrecv or
recvonly, the MediaStreamTrack will be associated with the m=
section at this time. MediaStreamTracks are assigned to m=
sections using the canonical order described in
<xref target="sec.initial-offers"/>. If there are more m= sections of a certain
type than MediaStreamTracks, some m= sections will not have an
associated MediaStreamTrack. If there are more MediaStreamTracks of
a certain type than compatible m= sections, only the first N
MediaStreamTracks will be able to be associated in the constructed
answer. The remainder will need to be associated in a subsequent
offer.</t>
<t>For each offered m= section, if the associated remote
MediaStreamTrack has been stopped, and is therefore in state "ended",
and no local MediaStreamTrack has been associated, the corresponding
m= section in the answer MUST be marked as rejected by setting the
port in the m= line to zero, as indicated in
<xref target="RFC3264"></xref>, Section 6., and further processing for
this m= section can be skipped.</t>
<t>Provided that is not the case, each m= section in the answer should
then be generated as specified in <xref
target="RFC3264"></xref>, Section 6.1. For the m= line itself, the following
rules must be followed:<list style="symbols">
<t>The port value would normally be set to the port of the default ICE candidate
for this m= section, but given that no candidates have yet been gathered,
the "dummy" port value of 9 (Discard) MUST be used, as
indicated in <xref target="I-D.ietf-mmusic-trickle-ice"></xref>,
Section 5.1.</t>
<t>The <proto> field MUST be set to exactly match the <proto>
field for the corresponding m= line in the offer.</t>
</list>
</t>
<t>The m= line MUST be followed immediately by a "c=" line, as specified
in <xref target="RFC4566"></xref>, Section 5.7. Again, as no candidates
have yet been gathered, the "c=" line must contain the "dummy" value
"IN IP6 ::", as defined in <xref target="I-D.ietf-mmusic-trickle-ice"></xref>,
Section 5.1.</t>
<t>
If the offer supports BUNDLE, all m= sections to be BUNDLEd must use
the same ICE credentials and candidates; all m= sections not being
BUNDLEd must use unique ICE credentials and candidates. Each
m= section MUST include the following:
<list style="symbols">
<t>If present in the offer, an "a=mid" line, as specified in
<xref target="RFC5888"></xref>, Section 9.1. The "mid" value
MUST match that specified in the offer.</t>
<t>An "a=rtcp" line, as specified in <xref target="RFC3605"></xref>,
Section 2.1, containing the dummy value "9 IN IP6 ::", because
no candidates have yet been gathered.</t>
<t>If a local MediaStreamTrack has been associated, an "a=msid"
line, as specified in <xref
target="I-D.ietf-mmusic-msid"></xref>, Section 2.</t>
<t>Depending on the directionality of the offer, the disposition
of any associated remote MediaStreamTrack, and the presence of an
associated local MediaStreamTrack, the appropriate directionality
attribute, as specified in <xref target="RFC3264"></xref>,
Section 6.1. If the offer was sendrecv, and the remote
MediaStreamTrack is still "live", and there is a local
MediaStreamTrack that has been associated, the directionality MUST be
set as sendrecv. If the offer was sendonly, and the remote
MediaStreamTrack is still "live", the directionality MUST be set
as recvonly. If the offer was recvonly, and a local
MediaStreamTrack has been associated, the directionality MUST be
set as sendonly. If the offer was inactive, the directionality
MUST be set as inactive.</t>
<t>For each supported codec that is present in the offer,
"a=rtpmap" and "a=fmtp" lines, as specified in <xref
target="RFC4566"></xref>, Section 6, and <xref
target="RFC3264"></xref>, Section 6.1.
The audio and video codecs that MUST be supported are
specified in <xref
target="I-D.ietf-rtcweb-audio"></xref> (see Section 3) and <xref
target="I-D.ietf-rtcweb-video"></xref> (see Section 5).
Note that for simplicity, the
answerer MAY use different payload types for codecs than the
offerer, as it is not prohibited by Section 6.1.</t>
<t>If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as
specified in <xref target="RFC4566"></xref>, Section 6.</t>
<t>If "rtx" is present in the offer, for each primary codec
where RTP retransmission should be used, a corresponding
"a=rtpmap" line indicating "rtx" with the clock rate of the
primary codec and an "a=fmtp" line that references the payload
type of the primary codec, as specified in <xref
target="RFC4588"></xref>, Section 8.1.</t>
<t>For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
as specified in <xref target="RFC4566"></xref>, Section 6. The
FEC mechanisms that MUST be supported are specified in
<xref target="I-D.ietf-rtcweb-fec"></xref>, Section 6, and
specific usage for each media type is outlined in Sections 4
and 5.</t>
<t>"a=ice-ufrag" and "a=ice-passwd" lines, as specified in <xref
target="RFC5245"></xref>, Section 15.4.</t>
<t>If the "trickle" ICE option is present in the offer, an
"a=ice-options" line, with the "trickle" option, as specified in
<xref target="I-D.ietf-mmusic-trickle-ice"></xref>, Section
4.</t>
<t>An "a=fingerprint" line, as specified in <xref
target="RFC4572"></xref>, Section 5; the algorithm used for the
fingerprint MUST match that used in the certificate signature.
</t>
<t>An "a=setup" line, as specified in <xref
target="RFC4145"></xref>, Section 4, and clarified for use in
DTLS-SRTP scenarios in <xref target="RFC5763"></xref>, Section
5. The role value in the answer MUST be "active" or "passive";
the "active" role is RECOMMENDED.</t>
<t>If present in the offer, an "a=rtcp-mux" line, as specified
in <xref target="RFC5761"></xref>, Section 5.1.1. If the
"require" RTCP multiplexing policy is set and no "a=rtcp-mux"
line is present in the offer, then the m=line MUST be
marked as rejected by setting the port in the m= line to zero, as
indicated in <xref target="RFC3264"></xref>, Section 6.
</t>
<t>If present in the offer, an "a=rtcp-rsize" line, as specified
in <xref target="RFC5506"></xref>, Section 5.</t>
<t>For each supported RTP header extension that is present in
the offer, an "a=extmap" line, as specified in <xref
target="RFC5285"></xref>, Section 5. The list of header
extensions that SHOULD/MUST be supported is specified in <xref
target="I-D.ietf-rtcweb-rtp-usage"></xref>, Section 5.2. Any
header extensions that require encryption MUST be specified as
indicated in <xref target="RFC6904"></xref>, Section 4.</t>
<t>For each supported RTCP feedback mechanism that is present in
the offer, an "a=rtcp-fb" mechanism, as specified in <xref
target="RFC4585"></xref>, Section 4.2. The list of RTCP feedback
mechanisms that SHOULD/MUST be supported is specified in <xref
target="I-D.ietf-rtcweb-rtp-usage"></xref>, Section 5.1.</t>
<t>If a local MediaStreamTrack has been associated, an "a=ssrc"
line, as specified in <xref target="RFC5576"></xref>, Section
4.1, indicating the SSRC to be used for sending media.</t>
<t>If a local MediaStreamTrack has been associated, and RTX has
been negotiated for this m= section, another "a=ssrc" line with
the RTX SSRC, and an "a=ssrc-group" line, as specified in <xref
target="RFC5576"></xref>, section 4.2, with semantics set to
"FID" and including the primary and RTX SSRCs.</t>
<t>If a local MediaStreamTrack has been associated, and FEC has
been negotiated for this m= section, another "a=ssrc" line with
the FEC SSRC, and an "a=ssrc-group" line with semantics set to
"FEC-FR" and including the primary and FEC SSRCs, as specified in
<xref target="RFC5956"></xref>, section 4.3. For
simplicity, if both RTX and FEC are supported, the FEC SSRC
MUST be the same as the RTX SSRC.</t>
<t>[OPEN ISSUE: Handling of a=imageattr]</t>
</list></t>
<t>If a data channel m= section has been offered, a m= section MUST
also be generated for data. The <media> field MUST be set to
"application" and the <proto> field MUST be set to
exactly match the field in the offer; the "fmt" value
MUST be set to the SCTP port number, as specified in Section 4.1.
[TODO: update this to use a=sctp-port, as indicated in the latest
data channel docs]</t>
<t>Within the data m= section, the "a=mid",
"a=ice-ufrag", "a=ice-passwd", "a=ice-options", "a=candidate",
"a=fingerprint", and "a=setup" lines MUST be included as mentioned
above, along with an "a=sctpmap" line referencing the SCTP port number
and specifying the application protocol indicated in <xref
target="I-D.ietf-rtcweb-data-protocol"></xref>. [OPEN ISSUE: the -01
of this document is missing this information.]</t>
<t>If "a=group" attributes with semantics of "BUNDLE" are offered,
corresponding session-level "a=group" attributes MUST be added as
specified in <xref target="RFC5888"></xref>. These attributes MUST
have semantics "BUNDLE", and MUST include the all mid identifiers from
the offered BUNDLE groups that have not been rejected.
Note that regardless of the presence of "a=bundle-only" in the offer,
no m= sections in the answer should have an "a=bundle-only" line.
</t>
<t>Attributes that are common between all m= sections MAY be moved
to session-level, if explicitly defined to be valid at
session-level.</t>
<t>The attributes prohibited in the creation of offers are also
prohibited in the creation of answers.</t>
</section>
<section title="Subsequent Answers" anchor="sec.subsequent-answers">
<t>When createAnswer is called a second (or later) time, or is called
after a local description has already been installed, the processing
is somewhat different than for an initial answer.</t>
<t>If the initial answer was not applied using setLocalDescription,
meaning the PeerConnection is still in the "have-remote-offer" state,
the steps for generating an initial answer should be followed, subject
to the following restriction: <list style="symbols">
<t>The fields of the "o=" line MUST stay the same except for the
<session-version> field, which MUST increment if the session
description changes in any way from the previously generated answer.
</t>
</list>
</t>
<t>If any session description was previously supplied to
setLocalDescription, an answer is
generated by following the steps in the "have-remote-offer" state above,
along with these exceptions: <list style="symbols">
<t>The "s=" and "t=" lines MUST stay the same.</t>
<t>Each "m=" and c=" line MUST be filled in with the port and
address of the default candidate for the m= section, as described
in <xref target="RFC5245"></xref>, Section 4.3. Note, however,
that the m= line protocol need not match the default candidate,
because this protocol value must instead match what was supplied
in the offer, as described above. Each
"a=rtcp" attribute line MUST also be filled in with the port and
address of the appropriate default candidate, either the
default RTP or RTCP candidate, depending on whether RTCP multiplexing
is enabled in the answer. In each case, if no candidates of the desired
type have yet been gathered, dummy values MUST be used, as
described in the initial answer section above.</t>
<t>Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same.
</t>
<t>Within each m= section, for each candidate that has
been gathered during the most recent gathering phase
(see <xref target="sec.ice-gather-overview"></xref>),
an "a=candidate" line MUST be added, as specified in <xref
target="RFC5245"></xref>, Section 4.3., paragraph 3. If
candidate gathering for the section has completed, an
"a=end-of-candidates" attribute MUST be added, as described in
<xref target="I-D.ietf-mmusic-trickle-ice"></xref>, Section 9.3.
</t>
<t>For MediaStreamTracks that are still present, the "a=msid",
"a=ssrc", and "a=ssrc-group" lines MUST stay the same.</t>
</list>
</t>
</section>
<section title="Options Handling" anchor="sec.options-handling2">
<t>The createAnswer method takes as a parameter an RTCAnswerOptions
object. The set of parameters for RTCAnswerOptions is different than
those supported in RTCOfferOptions;
the OfferToReceiveAudio, OfferToReceiveVideo, and IceRestart
options mentioned in <xref target="sec.options-handling1"></xref> are
meaningless in the context of generating an answer, as there is no need
to generate extra m= lines in an answer, and ICE credentials
will automatically be changed for all m= lines where the offerer chose
to perform ICE restart.</t>
<t>The following options are supported in RTCAnswerOptions.</t>
<section title="VoiceActivityDetection" anchor="sec.voiceactivitydetection2">
<t>Silence suppression in the answer is handled as described in
<xref target="sec.voiceactivitydetection1"></xref>.
</t>
</section>
</section>
</section>
<section title="Processing a Local Description" anchor="sec.processing-a-local-desc">
<t>When a SessionDescription is supplied to setLocalDescription, the
following steps MUST be performed:
<list style="symbols">
<t>First, the type of the SessionDescription is checked against the
current state of the PeerConnection:
<list style="symbols">
<t>If the type is "offer", the PeerConnection state MUST be
either "stable" or "have-local-offer".</t>
<t>If the type is "pranswer" or "answer", the PeerConnection
state MUST be either "have-remote-offer" or
"have-local-pranswer".</t>
</list>
</t>
<t>If the type is not correct for the current state, processing MUST
stop and an error MUST be returned.</t>
<t>Next, the SessionDescription is parsed into a data structure,
as described in the
<xref target="sec.parsing-a-desc"/> section below. If parsing
fails for any reason, processing MUST stop and an error MUST be
returned.
</t>
<t>Finally, the parsed SessionDescription is applied as described in
the <xref target="sec.applying-a-local-desc"/> section below.</t>
</list>
</t>
</section>
<section title="Processing a Remote Description" anchor="sec.processing-a-remote-desc">
<t>When a SessionDescription is supplied to setRemoteDescription, the
following steps MUST be performed:
<list style="symbols">
<t>First, the type of the SessionDescription is checked against the
current state of the PeerConnection:
<list style="symbols">
<t>If the type is "offer", the PeerConnection state MUST be
either "stable" or "have-remote-offer".</t>
<t>If the type is "pranswer" or "answer", the PeerConnection
state MUST be either "have-local-offer" or
"have-remote-pranswer".</t>
</list>
</t>
<t>If the type is not correct for the current state, processing MUST
stop and an error MUST be returned.</t>
<t>Next, the SessionDescription is parsed into a data structure,
as described in the
<xref target="sec.parsing-a-desc"/> section below. If parsing
fails for any reason, processing MUST stop and an error MUST be
returned.
</t>
<t>Finally, the parsed SessionDescription is applied as described in
the <xref target="sec.applying-a-remote-desc"/> section below.</t>
</list>
</t>
</section>
<section title="Parsing a Session Description" anchor="sec.parsing-a-desc">
<t>[The behavior described herein is a draft version, and needs
more discussion to resolve various open issues.]</t>
<t>When a SessionDescription of any type is supplied to
setLocal/RemoteDescription, the implementation must parse it and
reject it if it is invalid. The exact details of this
process are explained below.</t>
<t>The SDP contained in the session description object consists of a
sequence of text lines, each containing a key-value expression,
as described in <xref target="RFC4566"/>, Section 5.
The SDP is read,
line-by-line, and converted to a data structure that contains the
deserialized information. However, SDP allows many types of lines, not
all of which are relevant to JSEP applications.
For each line, the implementation will first ensure it is syntactically
correct according its defining ABNF [TODO: reference], check
that it conforms to <xref target="RFC4566"/> and <xref target="RFC3264"/>
semantics, and then either parse and store or discard the provided value,
as described below.
[TODO: ensure that every line is listed below.]
If the line is not well-formed, or cannot be parsed as described, the parser MUST stop
with an error and reject the session description. This ensures that
implementations do not accidentally misinterpret ambiguous SDP.</t>
<section title="Session-Level Parsing" anchor="sec.session-level-parse">
<t>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 <xref target="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,
and their ordering is not meaningful.</t>
<t>For non-attribute (non-"a=") lines, their sequencing, syntax,
and semantics, are checked, as mentioned above. The following
lines are not meaningful in the JSEP context and
MAY be discarded once they have been checked.
<list>
<t>TODO</t>
</list>
</t>
<t>The remaining lines are processed as follows:
<list>
<t>The "c=" line MUST be parsed and stored.</t>
<t>[OPEN ISSUE: For example, because session-level bandwidth is
ambiguous when multiple media streams are present, a "b=" line at session
level is not useful and its value SHOULD be ignored.
[OPEN ISSUE: is this WG consensus? Are there other non-a= lines that
we need to do more than just syntactical validation, e.g. v=?]
</t>
</list>
</t>
<t>Specific processing MUST be applied for the following session-level
attribute ("a=") lines:
<list style="symbols">
<t>Any "a=group" lines are parsed as specified in
<xref target="RFC5888"/>, Section 5, and the group's semantics
and mids are stored.</t>
<t>If present, a single "a=ice-lite" line is parsed as specified in
<xref target="RFC5245"/>, Section 15.3, and a value indicating
the presence of ice-lite is stored.</t>
<t>If present, a single "a=ice-ufrag" line is parsed as specified in
<xref target="RFC5245"/>, Section 15.4, and the ufrag value is
stored.</t>
<t>If present, a single "a=ice-pwd" line is parsed as specified in
<xref target="RFC5245"/>, Section 15.4, and the password
value is stored.</t>
<t>If present, a single "a=ice-options" line is parsed as specified in
<xref target="RFC5245"/>, Section 15.5, and the set of specified
options is stored.</t>
<t>Any "a=fingerprint" lines are parsed as specified in
<xref target="RFC4572"/>, Section 5, and the set of fingerprint
and algorithm values is stored.</t>
<t>If present, a single "a=setup" line is parsed as specified in
<xref target="RFC4145"/>, Section 4, and the setup value
is stored.</t>
<t>Any "a=extmap" lines are parsed as specified in
<xref target="RFC5285"/>, Section 5, and their values
are stored.</t>
<t>TODO: msid-semantic, identity, rtcp-rsize, rtcp-mux,
and any other attribs valid at session level.</t>
</list>
</t>
<t>
Once all the session-level lines have been parsed, processing
continues with the lines in media sections.
</t>
</section>
<section title="Media Section Parsing">
<t>Like the session-level lines, the media session lines MUST occur
in the specific order and with the specific syntax defined in
<xref target="RFC4566"/>, Section 5.</t>
<t>The "m=" line itself MUST be parsed as described in <xref target="RFC4566"/>,
Section 5.14, and the media, port, proto, and fmt values stored.</t>
<t>Following the "m=" line, specific processing MUST be applied for the
following non-attribute lines:
<list style="symbols">
<t>The "c=" line, if present, MUST be parsed as specified in
<xref target="RFC4566"/>, Section 5.7, and its contents stored.</t>
<t>The "b=" line, if present, MUST be parsed as specified in
<xref target="RFC4566"/>, Section 5.8, and the bwtype and
bandwidth values stored.</t>
</list>
</t>
<t>Specific processing MUST also be applied for the following attribute lines:
<list style="symbols">
<t>If present, a single "a=ice-lite" line is parsed as specified in
<xref target="RFC5245"/>, Section 15.3, and a value indicating
the presence of ice-lite is stored.</t>
<t>If present, a single "a=ice-ufrag" line is parsed as specified in
<xref target="RFC5245"/>, Section 15.4, and the ufrag value is
stored.</t>
<t>If present, a single "a=ice-pwd" line is parsed as specified in
<xref target="RFC5245"/>, Section 15.4, and the password
value is stored.</t>
<t>If present, a single "a=ice-options" line is parsed as specified in
<xref target="RFC5245"/>, Section 15.5, and the set of specified
options is stored.</t>
<t>Any "a=fingerprint" lines are parsed as specified in
<xref target="RFC4572"/>, Section 5, and the set of fingerprint
and algorithm values is stored.</t>
<t>If present, a single "a=setup" line is parsed as specified in
<xref target="RFC4145"/>, Section 4, and the setup value
is stored.</t>
</list>
</t>
<t>If the "m=" proto value indicates use of RTP, as decribed in
the <xref target="sec.profile-names"/> section above, the following
attribute lines MUST be processed:
<list style="symbols">
<t>The "m=" fmt value MUST be parsed as specified in <xref target="RFC4566"/>,
Section 5.14, and the individual values stored.</t>
<t>Any "a=rtpmap" or "a=fmtp" lines
MUST be parsed as specified in <xref target="RFC4566"/>, Section 6,
and their values stored.</t>
<t>If present, a single "a=ptime" line MUST be parsed as described in
<xref target="RFC4566"/>, Section 6, and its value stored.</t>
<t>If present, a single direction attribute line (e.g. "a=sendrecv")
MUST be parsed as described in
<xref target="RFC4566"/>, Section 6, and its value stored.</t>
<t>Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as
specified in <xref target="RFC5576"/>, Sections 4.1-4.2, and their
values stored.</t>
<t>Any "a=extmap" attributes MUST be parsed as specified in
<xref target="RFC5285"/>, Section 5, and their values stored.</t>
<t>Any "a=rtcp-fb" attributes MUST be parsed as specified in
<xref target="RFC4585"/>, Section 4.2., and their values stored.</t>
<t>If present, a single "a=rtcp-mux" line MUST be parsed as specified in
<xref target="RFC5761"/>, Section 5.1.1, and its presence or
absence flagged and stored.</t>
<t>TODO: a=rtcp-rsize, a=rtcp, a=msid, a=candidate, a=end-of-candidates</t>
</list>
</t>
<t>Otherwise, if the "m=" proto value indicats use of SCTP, the following
attribute lines MUST be processed:
<list style="symbols">
<t>The "m=" fmt value MUST be parsed as specified in
<xref target="I-D.ietf-mmusic-sctp-sdp"/>, Section 4.3, and
the application protocol value stored.</t>
<t>An "a=sctp-port" attribute MUST be present, and it MUST be
parsed as specified in <xref target="I-D.ietf-mmusic-sctp-sdp"/>,
Section 5.2, and the value stored.</t>
<t>TODO: max message size</t>
</list>
</t>
</section>
<section title="Semantics Verification">
<t>Assuming 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:
<list style="symbols">
<t>For each m= section, valid values for each of the
mandatory-to-use features enumerated in <xref target="sec.usage-requirements"/> MUST be present. These values MAY either be present at the
media level, or inherited from the session level.
<list style="symbols">
<t>ICE ufrag and password values</t>
<t>DTLS fingerprint and setup values</t>
</list>
</t>
</list>
</t>
<t>If this session description is of type "pranswer" or "answer", the
following additional checks are applied:
<list style="symbols">
<t>The session description must follow the rules defined in
<xref target="RFC3264"/>, Section 6.</t>
<t>For each m= section, the protocol value MUST exactly match the
protocol value in the corresponding m= section in the associated
offer.</t>
</list>
</t>
</section>
</section>
<section title="Applying a Local Description" anchor="sec.applying-a-local-desc">
<t>The following steps are performed at the media engine level to apply a local
description.</t>
<t>First, the parsed parameters are checked to ensure that any modifications
performed fall within those explicitly permitted by
<xref target="sec.configurable-sdp-paramete"/>; otherwise, processing
MUST stop and an error MUST be returned.</t>
<t>Next, media sections are processed. For each media 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.
<list style="symbols">
<t>TODO</t>
</list>
</t>
<t>Finally, if this description is of type "pranswer" or "answer", follow
the processing defined in the <xref target="sec.applying-an-answer"/>
section below.</t>
</section>
<section title="Applying a Remote Description" anchor="sec.applying-a-remote-desc">
<t>TODO</t>
</section>
<section title="Applying an Answer" anchor="sec.applying-an-answer">
<t>TODO</t>
</section>
</section>
<section title="Configurable SDP Parameters" anchor="sec.configurable-sdp-paramete">
<t>
It is possible to change elements in the SDP returned from createOffer
before passing it to setLocalDescription. When an implementation
receives modified SDP it MUST either:
</t>
<t>
<list style="symbols">
<t>Accept the changes and adjust its behavior to match the SDP.</t>
<t>Reject the changes and return an error via the error callback.</t>
</list>
</t>
<t>
Changes MUST NOT be silently ignored.
</t>
<t>The following elements of the SDP media description MUST NOT be
changed between the createOffer and the setLocalDescription (or between
the createAnswer and the setLocalDescription), since they
reflect transport attributes that are solely under browser control, and
the browser MUST NOT honor an attempt to change them:</t>
<t><list style="symbols">
<t>The number, type and port number of m= lines.</t>
<t>The generated ICE credentials (a=ice-ufrag and a=ice-pwd).</t>
<t>The set of ICE candidates and their parameters (a=candidate).</t>
<t>The DTLS fingerprint(s) (a=fingerprint).</t>
</list></t>
<t>The following modifications, if done by the browser to a description
between createOffer/createAnswer and the setLocalDescription, MUST be
honored by the browser:</t>
<t><list style="symbols">
<t>Remove or reorder codecs (m=)</t>
</list></t>
<t>The following parameters may be controlled by options passed into
createOffer/createAnswer. As an open issue, these changes may also be be
performed by manipulating the SDP returned from
createOffer/createAnswer, as indicated above, as long as the
capabilities of the endpoint are not exceeded (e.g. asking for a
resolution greater than what the endpoint can encode):</t>
<t><list style="symbols">
<t>[[OPEN ISSUE: This is a placeholder for other modifications, which
we may continue adding as use cases appear.]]</t></list></t>
<t>Implementations MAY choose to either honor or reject any elements not
listed in the above two categories, but must do so explicitly as
described at the beginning of this section. Note that future standards
may add new SDP elements to the list of elements which must be accepted
or rejected, but due to version skew, applications must be
prepared for implementations to accept changes which must be
rejected and vice versa.</t>
<t>The application can also modify the SDP to reduce the capabilities in
the offer it sends to the far side or the offer that it installs from the
far side in any way the application sees fit, as long as it is a
valid SDP offer and specifies a subset of what was in the original offer.
This is safe because the answer is not permitted to expand capabilities
and therefore will just respond to what is actually in the offer.</t>
<t>As always, the application is solely responsible for what it sends to
the other party, and all incoming SDP will be processed by the browser
to the extent of its capabilities. It is an error to assume that all SDP
is well-formed; however, one should be able to assume that any
implementation of this specification will be able to process, as a
remote offer or answer, unmodified SDP coming from any other
implementation of this specification.</t>
</section>
<section title="Examples" anchor="sec.examples">
<t> Note that this example section shows several SDP fragments. To
format in 72 columns, some of the lines in SDP have been split into
multiple lines, where leading whitespace indicates that a line
is a continuation of the previous line. In addition, some blank lines
have been added to improve readability but are not valid in SDP.</t>
<t> More examples of SDP for WebRTC call flows can be found in <xref
target="I-D.nandakumar-rtcweb-sdp"></xref>. </t>
<section title="Simple Example" anchor="sec.simple-examples">
<t> This section shows a very simple example that sets up a
minimal audio / video call between two browsers and does not use
trickle ICE. The example in the following section provides a
more realistic example of what would happen in a normal browser
to browser connection. </t>
<t> The flow shows Alice's browser initiating the session to
Bob's browser. The messages from Alice's JS to Bob's JS are
assumed to flow over some signaling protocol via a web
server. The JS 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. Both Alice and Bob are using the default policy of balanced. </t>
<t><figure>
<artwork><![CDATA[
// set up local media state
AliceJS->AliceUA: create new PeerConnection
AliceJS->AliceUA: addStream with stream containing 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 value of localDescription
// |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: onaddstream event with remoteStream
// Bob accepts call
BobJS->BobUA: addStream with local media
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 value of localDescription
// |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: onaddstream event with remoteStream
// media flows
BobUA->AliceUA: media sent from Bob to Alice
AliceUA->BobUA: media sent from Alice to Bob
]]></artwork>
</figure></t>
<t>
The SDP for |offer-A1| looks like: </t>
<t>
<figure>
<artwork><![CDATA[
v=0
o=- 4962303333179871722 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 v1
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.1
a=mid:a1
a=rtcp:56501 IN IP4 192.0.2.1
a=msid:47017fee-b6c1-4162-929c-a25110252400
f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
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=maxptime:120
a=ice-ufrag:ETEn1v9DoTMB9J4r
a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
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=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500
typ host
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501
typ host
a=end-of-candidates
m=video 56502 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 192.0.2.1
a=rtcp:56503 IN IP4 192.0.2.1
a=mid:v1
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:BGKkWnG5GmiUpdIV
a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf
a=ice-options:trickle
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=rtcp-mux
a=rtcp-rsize
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7
a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7
a=ssrc-group:FID 1366781083 1366781084
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502
typ host
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503
typ host
a=end-of-candidates
]]></artwork>
</figure>
</t>
<t>
The SDP for |answer-A1| looks like: </t>
<t>
<figure>
<artwork><![CDATA[
v=0
o=- 6729291447651054566 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
m=audio 20000 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.2
a=mid:a1
a=rtcp:20000 IN IP4 192.0.2.2
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
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=maxptime:120
a=ice-ufrag:6sFvz2gdLkEwjZEr
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 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=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host
a=end-of-candidates
m=video 20001 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 192.0.2.2
a=rtcp 20001 IN IP4 192.0.2.2
a=mid:v1
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:6sFvz2gdLkEwjZEr
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 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=rtcp-mux
a=rtcp-rsize
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 3229706345 3229706346
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20001
typ host
a=end-of-candidates
]]></artwork>
</figure>
</t>
</section>
<section title="Normal Examples" anchor="sec.normal-examples">
<t> This section shows a typical example of a session between two
browsers setting up an audio channel and a data channel. Trickle
ICE is used in full trickle mode with a bundle policy of max-bundle,
an RTCP mux policy of require, and a single TURN server.
Later, two video flows, one for the
presenter and one for screen sharing, are added to the session.
This example shows Alice's browser initiating the
session to Bob's browser. The messages from Alice's JS to Bob's
JS are assumed to flow over some signaling protocol via a web
server. </t>
<t><figure>
<artwork><![CDATA[
// set up local media state
AliceJS->AliceUA: create new PeerConnection
AliceJS->AliceUA: addStream that contains 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
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: onaddstream with audio track from Alice
// candidates are sent to Bob
AliceUA->AliceJS: onicecandidate event with |candidate-B1| (host)
AliceJS->WebServer: signaling with |candidate-B1|
AliceUA->AliceJS: onicecandidate event with |candidate-B2| (srflx)
AliceJS->WebServer: signaling with |candidate-B2|
AliceUA->AliceJS: onicecandidate event with |candidate-B3| (relay)
AliceJS->WebServer: signaling with |candidate-B3|
WebServer->BobJS: signaling with |candidate-B1|
BobJS->BobUA: addIceCandidate with |candidate-B1|
WebServer->BobJS: signaling with |candidate-B2|
BobJS->BobUA: addIceCandidate with |candidate-B2|
WebServer->BobJS: signaling with |candidate-B3|
BobJS->BobUA: addIceCandidate with |candidate-B3|
// Bob accepts call
BobJS->BobUA: addStream with local audio stream
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: onaddstream event with audio track from Bob
// candidates are sent to Alice
BobUA->BobJS: onicecandidate event with |candidate-B4| (host)
BobJS->WebServer: signaling with |candidate-B4|
BobUA->BobJS: onicecandidate event with |candidate-B5| (srflx)
BobJS->WebServer: signaling with |candidate-B5|
BobUA->BobJS: onicecandidate event with |candidate-B6| (relay)
BobJS->WebServer: signaling with |candidate-B6|
WebServer->AliceJS: signaling with |candidate-B4|
AliceJS->AliceUA: addIceCandidate with |candidate-B4|
WebServer->AliceJS: signaling with |candidate-B5|
AliceJS->AliceUA: addIceCandidate with |candidate-B5|
WebServer->AliceJS: signaling with |candidate-B6|
AliceJS->AliceUA: addIceCandidate with |candidate-B6|
// data channel opens
BobUA->BobJS: ondatachannel event
AliceUA->AliceJS: ondatachannel event
BobUA->BobJS: onopen
AliceUA->AliceJS: onopen
// media is flowing between browsers
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: addStream with first video stream
BobJS->BobUA: addStream 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: onaddstream event with first video stream
AliceUA->AliceJS: onaddstream event with second video stream
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 browsers
BobUA->AliceUA: audio+video+data sent from Bob to Alice
AliceUA->BobUA: audio+video+data sent from Alice to Bob
]]></artwork>
</figure></t>
<t>
The SDP for |offer-B1| looks like: </t>
<t>
<figure>
<artwork><![CDATA[
v=0
o=- 4962303333179871723 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP6 ::
a=rtcp:9 IN IP6 ::
a=mid:a1
a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
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=maxptime:120
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
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=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 ::
a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
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
]]></artwork>
</figure>
</t>
<t>
The SDP for |candidate-B1| looks like: </t>
<t> <figure>
<artwork><![CDATA[
candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
]]></artwork>
</figure>
</t>
<t>
The SDP for |candidate-B2| looks like: </t>
<t>
<figure>
<artwork><![CDATA[
candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
]]></artwork>
</figure>
</t>
<t>
The SDP for |candidate-B3| looks like: </t>
<t>
<figure>
<artwork><![CDATA[
candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
]]></artwork>
</figure>
</t>
<t>
The SDP for |answer-B1| looks like: </t>
<t>
<figure>
<artwork><![CDATA[
v=0
o=- 7729291447651054566 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP6 ::
a=rtcp:9 IN IP6 ::
a=mid:a1
a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
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=maxptime:120
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 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=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 ::
a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 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
]]></artwork>
</figure>
</t>
<t>
The SDP for |candidate-B4| looks like: </t>
<t> <figure>
<artwork><![CDATA[
candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
]]></artwork>
</figure>
</t>
<t>
The SDP for |candidate-B5| looks like: </t>
<t>
<figure>
<artwork><![CDATA[
candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
]]></artwork>
</figure>
</t>
<t>
The SDP for |candidate-B6| looks like: </t>
<t>
<figure>
<artwork><![CDATA[
candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
]]></artwork>
</figure>
</t>
<t>
The SDP for |offer-B2| looks like:
(note the increment of the version number in the o= line,
and the c= and a=rtcp lines, which indicate the local candidate
that was selected)
</t>
<t>
<figure>
<artwork><![CDATA[
v=0
o=- 7729291447651054566 2 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1 v1 v2
m=audio 64532 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 55.66.77.88
a=rtcp:64532 IN IP4 55.66.77.88
a=mid:a1
a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
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=maxptime:120
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 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:actpass
a=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
a=end-of-candidates
m=application 64532 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 55.66.77.88
a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=fingerprint:sha-256 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:actpass
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
a=end-of-candidates
m=video 64532 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 55.66.77.88
a=rtcp:64532 IN IP4 55.66.77.88
a=mid:v1
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
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=rtcp-mux
a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=ssrc:1366781083 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:1366781084 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 1366781083 1366781084
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
a=end-of-candidates
m=video 64532 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 55.66.77.88
a=rtcp:64532 IN IP4 55.66.77.88
a=mid:v1
a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
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=rtcp-mux
a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=ssrc:2366781083 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:2366781084 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 2366781083 2366781084
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532
a=end-of-candidates
]]></artwork>
</figure>
</t>
<t>
The SDP for |answer-B2| looks like:
(note the use of setup:passive to maintain
the existing DTLS roles, and the use of a=recvonly to
indicate that the video streams are one-way)
</t>
<t>
<figure>
<artwork><![CDATA[
v=0
o=- 4962303333179871723 2 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE a1 d1 v1 v2
m=audio 52546 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44
a=mid:a1
a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
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=maxptime:120
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
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:passive
a=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
a=end-of-candidates
m=application 52546 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 11.22.33.44
a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
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:passive
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
a=end-of-candidates
m=video 52546 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44
a=mid:v1
a=recvonly
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
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:passive
a=rtcp-mux
a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
a=end-of-candidates
m=video 52546 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44
a=mid:v2
a=recvonly
a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
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:passive
a=rtcp-mux
a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546
a=end-of-candidates
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Security Considerations" anchor="sec.security-considerations">
<t>
The IETF has published separate documents
<xref target="I-D.ietf-rtcweb-security-arch"/>
<xref target="I-D.ietf-rtcweb-security"/>
describing the security architecture for WebRTC as a whole.
The remainder of this section describes security considerations
for this document.
</t>
<t>
While formally the JSEP interface is an API, it is better to
think of it is an Internet protocol, with the JS being untrustworthy
from the perspective of the browser. Thus, the threat model of <xref
target="RFC3552"/> applies. In particular, JS can call the API in any
order and with any inputs, including malicious ones. This is
particularly relevant when we consider the SDP which is passed to
setLocalDescription(). While correct API usage requires that the
application pass in SDP which was derived from createOffer() or
createAnswer() (perhaps suitably modified as described in <xref
target="sec.configurable-sdp-paramete"/>, there is no guarantee that
applications do so. The browser MUST be prepared for the JS to pass in
bogus data instead.
</t>
<t>
Conversely, the application programmer MUST recognize that the
JS does not have complete control of browser 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 which wish to conceal their public IP address
should instead configure the ICE agent to use only relay candidates.
</t>
</section>
<section title="IANA Considerations" anchor="sec.iana-considerations">
<t>This document requires no actions from IANA.</t>
</section>
<section title="Acknowledgements" anchor="sec.acknowledgements">
<t>Significant text incorporated in the draft as well and review was
provided by Harald Alvestrand and Suhas Nandakumar. <!-- ACK 1 --> Dan
Burnett, Neil Stratford, Eric Rescorla, Anant Narayanan, Andrew Hutton,
Richard Ejzak, <!-- ACK 2 --> <!-- ACK 3 --> <!-- ACK 4 --> Adam
Bergkvist and Matthew Kaufman all provided valuable feedback on this proposal.
<!-- ACK 5 -->
<!-- ACK 5a --> <!-- ACK 5b --> <!-- ACK 5c --> <!-- ACK 6 --><!-- ACK 7 --></t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- NORM 1 -->
<reference anchor="RFC5245">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal for Offer/Answer
Protocols</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<date month="April" year="2010" />
</front>
<seriesInfo name="RFC" value="5245" />
<format octets="285120"
target="http://www.rfc-editor.org/rfc/rfc5245.txt" type="TXT" />
</reference>
<reference anchor="RFC5888">
<front>
<title>The Session Description Protocol (SDP) Grouping
Framework</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2010" />
<abstract>
<t>In this specification, we define a framework to group "m" lines
in the Session Description Protocol (SDP) for different purposes.
This framework uses the "group" and "mid" SDP attributes, both of
which are defined in this specification. Additionally, we specify
how to use the framework for two different purposes: for lip
synchronization and for receiving a media flow consisting of
several media streams on different transport addresses. This
document obsoletes RFC 3388. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5888" />
<format octets="43924"
target="http://www.rfc-editor.org/rfc/rfc5888.txt" type="TXT" />
</reference>
<reference anchor="RFC5761">
<front>
<title>Multiplexing RTP Data and Control Packets on a Single
Port</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<author fullname="M. Westerlund" initials="M." surname="Westerlund">
<organization></organization>
</author>
<date month="April" year="2010" />
<abstract>
<t>This memo discusses issues that arise when multiplexing RTP
data packets and RTP Control Protocol (RTCP) packets on a single
UDP port. It updates RFC 3550 and RFC 3551 to describe when such
multiplexing is and is not appropriate, and it explains how the
Session Description Protocol (SDP) can be used to signal
multiplexed sessions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5761" />
<format octets="31778"
target="http://www.rfc-editor.org/rfc/rfc5761.txt" type="TXT" />
</reference>
<reference anchor="RFC4585">
<front>
<title>Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)</title>
<author fullname="J. Ott" initials="J." surname="Ott">
<organization></organization>
</author>
<author fullname="S. Wenger" initials="S." surname="Wenger">
<organization></organization>
</author>
<author fullname="N. Sato" initials="N." surname="Sato">
<organization></organization>
</author>
<author fullname="C. Burmeister" initials="C." surname="Burmeister">
<organization></organization>
</author>
<author fullname="J. Rey" initials="J." surname="Rey">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>Real-time media streams that use RTP are, to some degree,
resilient against packet losses. Receivers may use the base
mechanisms of the Real-time Transport Control Protocol (RTCP) to
report packet reception statistics and thus allow a sender to
adapt its transmission behavior in the mid-term. This is the sole
means for feedback and feedback-based error repair (besides a few
codec-specific mechanisms). This document defines an extension to
the Audio-visual Profile (AVP) that enables receivers to provide,
statistically, more immediate feedback to the senders and thus
allows for short-term adaptation and efficient feedback-based
repair mechanisms to be implemented. This early feedback profile
(AVPF) maintains the AVP bandwidth constraints for RTCP and
preserves scalability to large groups. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4585" />
<format octets="117762"
target="http://www.rfc-editor.org/rfc/rfc4585.txt" type="TXT" />
</reference>
<reference anchor="RFC5124">
<front>
<title>Extended Secure RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/SAVPF)</title>
<author fullname="J. Ott" initials="J." surname="Ott">
<organization></organization>
</author>
<author fullname="E. Carrara" initials="E." surname="Carrara">
<organization></organization>
</author>
<date month="February" year="2008" />
<abstract>
<t>An RTP profile (SAVP) for secure real-time communications and
another profile (AVPF) to provide timely feedback from the
receivers to a sender are defined in RFC 3711 and RFC 4585,
respectively. This memo specifies the combination of both profiles
to enable secure RTP communications with feedback.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5124" />
<format octets="37856"
target="http://www.rfc-editor.org/rfc/rfc5124.txt" type="TXT" />
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization></organization>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization></organization>
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization></organization>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization></organization>
</author>
<date month="June" year="2002" />
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an
application-layer control (signaling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include Internet telephone calls, multimedia
distribution, and multimedia conferences. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261" />
<format octets="647976"
target="http://www.rfc-editor.org/rfc/rfc3261.txt" type="TXT" />
</reference>
<!-- NORM 2 -->
<reference anchor='I-D.ietf-rtcweb-video'>
<front>
<title>WebRTC Video Processing and Codec Requirements</title>
<author initials='A' surname='Roach' fullname='Adam Roach'>
<organization />
</author>
<date month='July' day='1' year='2014' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-video-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-video-00.txt' />
</reference>
<!-- NORM 2a -->
<reference anchor="I-D.ietf-rtcweb-audio">
<front>
<title>WebRTC Audio Codec and Processing Requirements</title>
<author fullname="Jean-Marc Valin" initials="J" surname="Valin">
<organization></organization>
</author>
<author fullname="Cary Bran" initials="C" surname="Bran">
<organization></organization>
</author>
<date day="2" month="August" year="2013" />
<abstract>
<t>This document outlines the audio codec and processing
requirements for WebRTC client application and endpoint
devices.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-audio-02" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-audio-02.txt"
type="TXT" />
</reference>
<!-- NORM 3 -->
<reference anchor="I-D.ietf-mmusic-sctp-sdp">
<front>
<title>Stream Control Transmission Protocol (SCTP)-Based Media
Transport in the Session Description Protocol (SDP)</title>
<author fullname="Salvatore Loreto" initials="S" surname="Loreto">
<organization></organization>
</author>
<author fullname="Gonzalo Camarillo" initials="G"
surname="Camarillo">
<organization></organization>
</author>
<date day="30" month="June" year="2013" />
<abstract>
<t>SCTP (Stream Control Transmission Protocol) is a transport
protocol used to establish associations between two endpoints.
This document describes how to express media transport over SCTP
in SDP (Session Description Protocol). This document defines the
'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for
SDP.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-mmusic-sctp-sdp-04" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-04.txt"
type="TXT" />
</reference>
<!-- NORM 4 -->
<reference anchor="RFC4572">
<front>
<title>Connection-Oriented Media Transport over the Transport Layer
Security (TLS) Protocol in the Session Description Protocol
(SDP)</title>
<author fullname="J. Lennox" initials="J." surname="Lennox">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>This document specifies how to establish secure
connection-oriented media transport sessions over the Transport
Layer Security (TLS) protocol using the Session Description
Protocol (SDP). It defines a new SDP protocol identifier,
'TCP/TLS'. It also defines the syntax and semantics for an SDP
'fingerprint' attribute that identifies the certificate that will
be presented for the TLS session. This mechanism allows media
transport over TLS connections to be established securely, so long
as the integrity of session descriptions is
assured.</t><t> This document extends and updates RFC
4145. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4572" />
<format octets="38658"
target="http://www.rfc-editor.org/rfc/rfc4572.txt" type="TXT" />
</reference>
<!-- NORM 5 -->
<reference anchor="RFC4145">
<front>
<title>TCP-Based Media Transport in the Session Description Protocol
(SDP)</title>
<author fullname="D. Yon" initials="D." surname="Yon">
<organization></organization>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<date month="September" year="2005" />
<abstract>
<t>This document describes how to express media transport over TCP
using the Session Description Protocol (SDP). It defines the SDP
'TCP' protocol identifier, the SDP 'setup' attribute, which
describes the connection setup procedure, and the SDP 'connection'
attribute, which handles connection reestablishment.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4145" />
<format octets="30225"
target="http://www.rfc-editor.org/rfc/rfc4145.txt" type="TXT" />
</reference>
<!-- NORM 6 -->
<reference anchor="I-D.nandakumar-mmusic-proto-iana-registration">
<front>
<title abbrev="SDP Proto Registrations">IANA registration of SDP 'proto' attribute
for transporting RTP Media over TCP under various RTP profiles.</title>
<author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
<organization>Cisco Systems Inc</organization>
<address>
<postal>
<street>707 Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>snandaku@cisco.com</email>
</address>
</author>
<date day="18" month="September" year="2014" />
<area>RAI</area>
<workgroup>MMUSIC</workgroup>
<abstract>
<t>
RTP provides end-to-end network transport functions suitable for
applications transmitting real-time data, such as audio, video or
simulation data, over multicast or unicast network services. The data
transport is augmented by a control protocol (RTCP) to allow monitoring
of the data delivery in a manner scalable to large multicast networks,
and to provide minimal control and identification functionality.
</t>
<t>
This document describes how to express RTP media transport over TCP
in SDP (Session Description Protocol) under various configurations.
This document defines 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF',
'TCP/TLS/RTP/SAVP', 'TCP/TLS/RTP/SAVPF' protocol identifiers for SDP.
</t>
</abstract>
</front>
</reference>
<!-- NORM 7 -->
<reference anchor='I-D.ietf-mmusic-sdp-mux-attributes'>
<front>
<title>A Framework for SDP Attributes when Multiplexing</title>
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
<organization />
</author>
<date month='February' day='14' year='2014' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-sdp-mux-attributes-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-mux-attributes-01.txt' />
</reference>
<!-- NORM 8 -->
<!-- NORM 9 -->
<!-- NORM 10 -->
<reference anchor="RFC5285">
<front>
<title>A General Mechanism for RTP Header Extensions</title>
<author fullname="D. Singer" initials="D." surname="Singer">
<organization></organization>
</author>
<author fullname="H. Desineni" initials="H." surname="Desineni">
<organization></organization>
</author>
<date month="July" year="2008" />
<abstract>
<t>This document provides a general mechanism to use the header
extension feature of RTP (the Real-Time Transport Protocol). It
provides the option to use a small number of small extensions in
each RTP packet, where the universe of possible extensions is
large and registration is de-centralized. The actual extensions in
use in a session are signaled in the setup information for that
session. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5285" />
<format octets="36844"
target="http://www.rfc-editor.org/rfc/rfc5285.txt" type="TXT" />
</reference>
<!-- NORM 11 -->
<reference anchor="RFC6904">
<front>
<title>Encryption of Header Extensions in the Secure Real-time
Transport Protocol (SRTP)</title>
<author fullname="J. Lennox" initials="J." surname="Lennox">
<organization></organization>
</author>
<date month="April" year="2013" />
<abstract>
<t>The Secure Real-time Transport Protocol (SRTP) provides
authentication, but not encryption, of the headers of Real-time
Transport Protocol (RTP) packets. However, RTP header extensions
may carry sensitive information for which participants in
multimedia sessions want confidentiality. This document provides a
mechanism, extending the mechanisms of SRTP, to selectively
encrypt RTP header extensions in SRTP.</t><t> This
document updates RFC 3711, the Secure Real-time Transport Protocol
specification, to require that all future SRTP encryption
transforms specify how RTP header extensions are to be
encrypted.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6904" />
<format octets="33486"
target="http://www.rfc-editor.org/rfc/rfc6904.txt" type="TXT" />
</reference>
<!-- NORM 12 -->
<reference anchor="I-D.ietf-rtcweb-rtp-usage">
<front>
<title>Web Real-Time Communication (WebRTC): Media Transport and Use
of RTP</title>
<author fullname="Colin Perkins" initials="C" surname="Perkins">
<organization></organization>
</author>
<author fullname="Magnus Westerlund" initials="M"
surname="Westerlund">
<organization></organization>
</author>
<author fullname="Joerg Ott" initials="J" surname="Ott">
<organization></organization>
</author>
<date day="5" month="September" year="2013" />
<abstract>
<t>The Web Real-Time Communication (WebRTC) framework provides
support for direct interactive rich communication using audio,
video, text, collaboration, games, etc. between two peers'
web-browsers. This memo describes the media transport aspects of
the WebRTC framework. It specifies how the Real-time Transport
Protocol (RTP) is used in the WebRTC context, and gives
requirements for which RTP features, profiles, and extensions need
to be supported.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-rtcweb-rtp-usage-09" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-09.txt"
type="TXT" />
</reference>
<!-- NORM 13 -->
<reference anchor="I-D.ietf-mmusic-sdp-bundle-negotiation">
<front>
<title>Multiplexing Negotiation Using Session Description Protocol
(SDP) Port Numbers</title>
<author fullname="Christer Holmberg" initials="C" surname="Holmberg">
<organization></organization>
</author>
<author fullname="Harald Alvestrand" initials="H"
surname="Alvestrand">
<organization></organization>
</author>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization></organization>
</author>
<date day="14" month="June" year="2013" />
<abstract>
<t>This specification defines a new SDP Grouping Framework
extension, "BUNDLE", that can be used with the Session Description
Protocol (SDP) Offer/Answer mechanism to negotiate the usage of
bundled media, which refers to the usage of a single 5-tuple for
media associated with multiple SDP media descriptions ("m="
lines).</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-mmusic-sdp-bundle-negotiation-04" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation-04.txt"
type="TXT" />
</reference>
<!-- NORM 14 -->
<reference anchor="I-D.ietf-mmusic-msid">
<front>
<title>Cross Session Stream Identification in the Session
Description Protocol</title>
<author fullname="Harald Alvestrand" initials="H"
surname="Alvestrand">
<organization></organization>
</author>
<date day="13" month="August" year="2013" />
<abstract>
<t>This document specifies a grouping mechanism for RTP media
streams that can be used to specify relations between media
streams. This mechanism is used to signal the association between
the SDP concept of "m-line" and the WebRTC concept of
"MediaStream" / "MediaStreamTrack" using SDP signaling. This
document is a work item of the MMUSIC WG, whose discussion list is
mmusic@ietf.org.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-msid-01" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt"
type="TXT" />
</reference>
<!-- NORM 15 -->
<reference anchor='RFC7022'>
<front>
<title>Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)</title>
<author initials='A.' surname='Begen' fullname='A. Begen'>
<organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'>
<organization /></author>
<author initials='D.' surname='Wing' fullname='D. Wing'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2013' month='September' />
</front>
<seriesInfo name='RFC' value='7022' />
<format type='TXT' octets='21717' target='http://www.rfc-editor.org/rfc/rfc7022.txt' />
</reference>
<!-- NORM 16 -->
<reference anchor='I-D.ietf-rtcweb-security'>
<front>
<title>Security Considerations for WebRTC</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='January' day='21' year='2014' />
<abstract><t>The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC". The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-security-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-06.txt' />
</reference>
<!-- NORM 17 -->
<reference anchor='I-D.ietf-rtcweb-security-arch'>
<front>
<title>WebRTC Security Architecture</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='February' day='14' year='2014' />
<abstract><t>The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC"). This document defines the security architecture for WebRTC.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-security-arch-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-09.txt' />
</reference>
<!-- NORM 18 -->
<reference anchor='RFC3552'>
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<author initials='B.' surname='Korver' fullname='B. Korver'>
<organization /></author>
<date year='2003' month='July' />
<abstract>
<t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='72' />
<seriesInfo name='RFC' value='3552' />
<format type='TXT' octets='110393' target='http://www.rfc-editor.org/rfc/rfc3552.txt' />
</reference>
<!-- NORM 19 -->
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<reference anchor="RFC3264">
<front>
<title>An Offer/Answer Model with Session Description Protocol
(SDP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2002" />
</front>
<seriesInfo name="RFC" value="3264" />
<format octets="60854"
target="http://www.rfc-editor.org/rfc/rfc3264.txt" type="TXT" />
</reference>
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization></organization>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="RFC" value="4566" />
<format octets="108820"
target="http://www.rfc-editor.org/rfc/rfc4566.txt" type="TXT" />
</reference>
<reference anchor="I-D.ietf-rtcweb-data-protocol">
<front>
<title>WebRTC Data Channel Protocol</title>
<author fullname="Randell Jesup" initials="R" surname="Jesup">
<organization></organization>
</author>
<author fullname="Salvatore Loreto" initials="S" surname="Loreto">
<organization></organization>
</author>
<author fullname="Michael Tuexen" initials="M" surname="Tuexen">
<organization></organization>
</author>
<date day="26" month="February" year="2013" />
<abstract>
<t>The Web Real-Time Communication (WebRTC) working group is
charged to provide protocols to support for direct interactive
rich communication using audio, video, and data between two peers'
web- browsers. This document specifies an actual (minor) protocol
for how the JS-layer DataChannel objects provide the data channels
between the peers.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-rtcweb-data-protocol-04" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-data-protocol-04.txt"
type="TXT" />
</reference>
<reference anchor="RFC3605">
<front>
<title>
Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)
</title>
<author initials="C." surname="Huitema" fullname="C. Huitema">
<organization/>
</author>
<date year="2003" month="October"/>
<abstract>
<t>
The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3605"/>
<format type="TXT" octets="17270" target="http://www.rfc-editor.org/rfc/rfc3605.txt"/>
</reference>
<reference anchor="I-D.ietf-mmusic-trickle-ice">
<front>
<title>Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol</title>
<author fullname="Emil Ivov" initials="E" surname="Ivov">
<organization></organization>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization></organization>
</author>
<author fullname="Justin Uberti" initials="J" surname="Uberti">
<organization></organization>
</author>
<date day="11" month="March" year="2013" />
<abstract>
<t>This document describes an extension to the Interactive
Connectivity Establishment (ICE) protocol that allows ICE agents
to send and receive candidates incrementally rather than
exchanging complete lists. With such incremental provisioning, ICE
agents can begin connectivity checks while they are still
gathering candidates and considerably shorten the time necessary
for ICE processing to complete. The above mechanism is also
referred to as "trickle ICE".</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-mmusic-trickle-ice-00" />
<format target="http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt"
type="TXT" />
</reference>
<reference anchor="I-D.ietf-rtcweb-fec">
<front>
<title>WebRTC Forward Error Correction Requirements</title>
<author initials="J" surname="Uberti" fullname="Justin Uberti">
<organization/>
</author>
<date month="February" day="6" year="2015"/>
<abstract>
<t>
This document makes recommendations for how Forward Error
Correction (FEC) should be used by WebRTC applications.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-fec-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-fec-00.txt"/>
</reference>
<reference anchor='RFC6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'>
<organization /></author>
<date year='2012' month='January' />
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6347' />
<format type='TXT' octets='73546' target='http://www.rfc-editor.org/rfc/rfc6347.txt' />
</reference>
</references>
<references title="Informative References">
<!-- INFORM 1 -->
<reference anchor="RFC3556">
<front>
<title>Session Description Protocol (SDP) Bandwidth Modifiers for
RTP Control Protocol (RTCP) Bandwidth</title>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization></organization>
</author>
<date month="July" year="2003" />
<abstract>
<t>This document defines an extension to the Session Description
Protocol (SDP) to specify two additional modifiers for the
bandwidth attribute. These modifiers may be used to specify the
bandwidth allowed for RTP Control Protocol (RTCP) packets in a
Real-time Transport Protocol (RTP) session. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3556" />
<format octets="15310"
target="http://www.rfc-editor.org/rfc/rfc3556.txt" type="TXT" />
</reference>
<reference anchor="RFC5576">
<front>
<title>Source-Specific Media Attributes in the Session Description
Protocol (SDP)</title>
<author fullname="J. Lennox" initials="J." surname="Lennox">
<organization></organization>
</author>
<author fullname="J. Ott" initials="J." surname="Ott">
<organization></organization>
</author>
<author fullname="T. Schierl" initials="T." surname="Schierl">
<organization></organization>
</author>
<date month="June" year="2009" />
<abstract>
<t>The Session Description Protocol (SDP) provides mechanisms to
describe attributes of multimedia sessions and of individual media
streams (e.g., Real-time Transport Protocol (RTP) sessions) within
a multimedia session, but does not provide any mechanism to
describe individual media sources within a media stream. This
document defines a mechanism to describe RTP media sources, which
are identified by their synchronization source (SSRC) identifiers,
in SDP, to associate attributes with these sources, and to express
relationships among sources. It also defines several source-level
attributes that can be used to describe properties of media
sources. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5576" />
<format octets="40454"
target="http://www.rfc-editor.org/rfc/rfc5576.txt" type="TXT" />
</reference>
<reference anchor="RFC5956">
<front>
<title>
Forward Error Correction Grouping Semantics in the Session
Description Protocol
</title>
<author initials="A." surname="Begen" fullname="A. Begen">
<organization/>
</author>
<date year="2010" month="September"/>
<abstract>
<t>
This document defines the semantics for grouping the associated source
and FEC-based (Forward Error Correction) repair flows in the Session
Description Protocol (SDP). The semantics defined in this document
are to be used with the SDP Grouping Framework (RFC 5888). These
semantics allow the description of grouping relationships between the
source and repair flows when one or more source and/or repair flows
are associated in the same group, and they provide support for
additive repair flows. SSRC-level (Synchronization Source) grouping
semantics are also defined in this document for Real-time Transport
Protocol (RTP) streams using SSRC multiplexing. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5956"/>
<format type="TXT" octets="29530" target="http://www.rfc-editor.org/rfc/rfc5956.txt"/>
</reference>
<reference anchor="RFC5506">
<front>
<title>Support for Reduced-Size Real-Time Transport Control Protocol
(RTCP): Opportunities and Consequences</title>
<author fullname="I. Johansson" initials="I." surname="Johansson">
<organization></organization>
</author>
<author fullname="M. Westerlund" initials="M." surname="Westerlund">
<organization></organization>
</author>
<date month="April" year="2009" />
<abstract>
<t>This memo discusses benefits and issues that arise when
allowing Real-time Transport Protocol (RTCP) packets to be
transmitted with reduced size. The size can be reduced if the
rules on how to create compound packets outlined in RFC 3550 are
removed or changed. Based on that analysis, this memo defines
certain changes to the rules to allow feedback messages to be sent
as Reduced-Size RTCP packets under certain conditions when using
the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile
with Feedback) profile (RFC 4585). This document updates RFC 3550,
RFC 3711, and RFC 4585. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5506" />
<format octets="41011"
target="http://www.rfc-editor.org/rfc/rfc5506.txt" type="TXT" />
</reference>
<!-- INFORM 2 -->
<!-- INFORM 3 -->
<!-- INFORM 4 -->
<reference anchor="RFC3960">
<front>
<title>Early Media and Ringing Tone Generation in the Session
Initiation Protocol (SIP)</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="December" year="2004" />
<abstract>
<t>This document describes how to manage early media in the
Session Initiation Protocol (SIP) using two models: the gateway
model and the application server model. It also describes the
inputs one needs to consider in defining local policies for
ringing tone generation. This memo provides information for the
Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3960" />
<format octets="31692"
target="http://www.rfc-editor.org/rfc/rfc3960.txt" type="TXT" />
</reference>
<!-- INFORM 5 -->
<!-- INFORM 6 -->
<reference anchor="RFC4588">
<front>
<title>RTP Retransmission Payload Format</title>
<author fullname="J. Rey" initials="J." surname="Rey">
<organization></organization>
</author>
<author fullname="D. Leon" initials="D." surname="Leon">
<organization></organization>
</author>
<author fullname="A. Miyazaki" initials="A." surname="Miyazaki">
<organization></organization>
</author>
<author fullname="V. Varsa" initials="V." surname="Varsa">
<organization></organization>
</author>
<author fullname="R. Hakenberg" initials="R." surname="Hakenberg">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>RTP retransmission is an effective packet loss recovery
technique for real-time applications with relaxed delay bounds.
This document describes an RTP payload format for performing
retransmissions. Retransmitted RTP packets are sent in a separate
stream from the original RTP stream. It is assumed that feedback
from receivers to senders is available. In particular, it is
assumed that Real-time Transport Control Protocol (RTCP) feedback
as defined in the extended RTP profile for RTCP-based feedback
(denoted RTP/AVPF) is available in this memo.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4588" />
<format octets="76630"
target="http://www.rfc-editor.org/rfc/rfc4588.txt" type="TXT" />
</reference>
<!-- INFORM 7 -->
<reference anchor="RFC3389">
<front>
<title>Real-time Transport Protocol (RTP) Payload for Comfort Noise
(CN)</title>
<author fullname="R. Zopf" initials="R." surname="Zopf">
<organization></organization>
</author>
<date month="September" year="2002" />
</front>
<seriesInfo name="RFC" value="3389" />
<format octets="17018"
target="http://www.rfc-editor.org/rfc/rfc3389.txt" type="TXT" />
</reference>
<!-- INFORM 8 -->
<!-- INFORM 9 -->
<!-- INFORM 10 -->
<!-- INFORM 11 -->
<!-- INFORM 12 -->
<!-- INFORM 13 -->
<!-- INFORM 14 -->
<!-- INFORM 15 -->
<!-- INFORM 16 -->
<reference anchor="I-D.nandakumar-rtcweb-sdp">
<front>
<title>SDP for the WebRTC</title>
<author fullname="Suhas Nandakumar" initials="S"
surname="Nandakumar">
<organization></organization>
</author>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization></organization>
</author>
<date day="13" month="July" year="2013" />
<abstract>
<t>The Web Real-Time Communication (WebRTC) [WEBRTC] working group
is charged to provide protocol support for direct interactive rich
communication using audio,video and data between two peers' web
browsers. With in the WebRTC framework, Session Description
protocol (SDP) [RFC4566] is used for negotiating session
capabilities between the peers. Such a negotiataion happens based
on the SDP Offer/Answer exchange mechanism described in the RFC
3264 [RFC3264]. This document serves a introductory purpose in
describing the role of SDP for the most common WebRTC use-cases.
This SDP examples provided in this document is still a work in
progress, but aims to align closest to the evolving standards.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-nandakumar-rtcweb-sdp-02" />
<format target="http://www.ietf.org/internet-drafts/draft-nandakumar-rtcweb-sdp-02.txt"
type="TXT" />
<format target="http://www.ietf.org/internet-drafts/draft-nandakumar-rtcweb-sdp-02.pdf"
type="PDF" />
</reference>
<!-- INFORM 17 -->
<reference anchor="RFC5763">
<front>
<title>Framework for Establishing a Secure Real-time Transport
Protocol (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)</title>
<author fullname="J. Fischl" initials="J." surname="Fischl">
<organization></organization>
</author>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
<organization></organization>
</author>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization></organization>
</author>
<date month="May" year="2010" />
<abstract>
<t>This document specifies how to use the Session Initiation
Protocol (SIP) to establish a Secure Real-time Transport Protocol
(SRTP) security context using the Datagram Transport Layer
Security (DTLS) protocol. It describes a mechanism of transporting
a fingerprint attribute in the Session Description Protocol (SDP)
that identifies the key that will be presented during the DTLS
handshake. The key exchange travels along the media path as
opposed to the signaling path. The SIP Identity mechanism can be
used to protect the integrity of the fingerprint attribute from
modification by intermediate proxies. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5763" />
<format octets="81546"
target="http://www.rfc-editor.org/rfc/rfc5763.txt" type="TXT" />
</reference>
<reference anchor='RFC5764'>
<front>
<title>Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2010' month='May' />
<abstract>
<t>This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5764' />
<format type='TXT' octets='60590' target='http://www.rfc-editor.org/rfc/rfc5764.txt' />
</reference>
<reference anchor="RFC4568">
<front>
<title>Session Description Protocol (SDP) Security Descriptions for
Media Streams</title>
<author fullname="F. Andreasen" initials="F." surname="Andreasen">
<organization></organization>
</author>
<author fullname="M. Baugher" initials="M." surname="Baugher">
<organization></organization>
</author>
<author fullname="D. Wing" initials="D." surname="Wing">
<organization></organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="RFC" value="4568" />
<format octets="107881"
target="http://www.rfc-editor.org/rfc/rfc4568.txt" type="TXT" />
</reference>
<reference anchor="W3C.WD-webrtc-20140617"
target="http://www.w3.org/TR/2011/WD-webrtc-20140617">
<front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<author fullname="Adam Bergkvist" initials="A." surname="Bergkvist">
<organization></organization>
</author>
<author fullname="Daniel C. Burnett" initials="D." surname="Burnett">
<organization></organization>
</author>
<author fullname="Anant Narayanan" initials="A." surname="Narayanan">
<organization></organization>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization></organization>
</author>
<date day="17" month="June" year="2014" />
</front>
<seriesInfo name="World Wide Web Consortium WD"
value="WD-webrtc-20140617" />
<format target="http://www.w3.org/TR/2011/WD-webrtc-20140617"
type="HTML" />
</reference>
</references>
<section title="Change log" anchor="sec.change-log">
<t> Note: This section will be removed by RFC Editor before publication. </t>
<t>Changes in draft-09:">
<list style="symbols">
<t>
Don't return null for {local,remote}Description after close().
</t>
<t>
Changed TCP/TLS to UDP/DTLS in RTP profile names.
</t>
<t>
Separate out bundle and mux policy.
</t>
<t>
Added specific references to FEC mechanisms.
</t>
<t>
Added canTrickle mechanism.
</t>
<t>
Added section on subsequent answers and, answer options.
</t>
<t>
Added text defining set{Local,Remote}Description behavior.
</t>
</list>
</t>
<t>Changes in draft-08:
<list style="symbols">
<t> Added new example section and removed old examples in appendix. </t>
<t>Fixed <proto> field handling.</t>
<t>Added text describing a=rtcp attribute.</t>
<t>Reworked handling of OfferToReceiveAudio and OfferToReceiveVideo per discussion
at IETF 90.</t>
<t>Reworked trickle ICE handling and its impact on m= and c= lines per
discussion at interim.</t>
<t>Added max-bundle-and-rtcp-mux policy.</t>
<t>Added description of maxptime handling.</t>
<t>Updated ICE candidate pool default to 0.</t>
<t>Resolved open issues around AppID/receiver-ID.</t>
<t>Reworked and expanded how changes to the ICE configuration are handled.</t>
<t>Some reference updates.</t>
<t>Editorial clarification.</t>
</list></t>
<t>Changes in draft-07:
<list style="symbols">
<t>Expanded discussion of VAD and Opus DTX.</t>
<t>Added a security considerations section.</t>
<t>Rewrote the section on modifying SDP to require
implementations to clearly indicate whether any given
modification is allowed.</t>
<t>Clarified impact of IceRestart on CreateOffer in
local-offer state.</t>
<t>Guidance on whether attributes should be defined at the
media level or the session level.</t>
<t>Renamed "default" bundle policy to "balanced".</t>
<t>Removed default ICE candidate pool size and clarify how it works.</t>
<t>Defined a canonical order for assignment of MSTs to m= lines.</t>
<t>Removed discussion of rehydration.</t>
<t>Added Eric Rescorla as a draft editor.</t>
<t>Cleaned up references.</t>
<t>Editorial cleanup</t>
</list></t>
<t>Changes in draft-06: <list style="symbols">
<t>Reworked handling of m= line recycling.</t>
<t>Added handling of BUNDLE and bundle-only.</t>
<t>Clarified handling of rollback.</t>
<t>Added text describing the ICE Candidate Pool and its behavior.</t>
<t>Allowed OfferToReceiveX to create multiple recvonly m= sections.
</t>
</list></t>
<t>Changes in draft-05: <list style="symbols">
<t>Fixed several issues identified in the createOffer/Answer
sections during document review.</t>
<t>Updated references.</t>
</list></t>
<t>Changes in draft-04: <list style="symbols">
<t>Filled in sections on createOffer and createAnswer.</t>
<t>Added SDP examples.</t>
<t>Fixed references.</t>
</list></t>
<t>Changes in draft-03: <list style="symbols">
<t>Added text describing relationship to W3C specification</t>
</list></t>
<t>Changes in draft-02: <list style="symbols">
<!-- A -->
<t>Converted from nroff</t>
<!-- B -->
<t>Removed comparisons to old approaches abandoned by the working
group</t>
<!-- C -->
<t>Removed stuff that has moved to W3C specification</t>
<!-- D -->
<t>Align SDP handling with W3C draft</t>
<!-- E -->
<t>Clarified section on forking.</t>
<!-- F -->
<!-- G -->
<!-- H -->
<!-- I -->
<!-- J -->
<!-- K -->
<!-- L -->
</list></t>
<t>Changes in draft-01: <list style="symbols">
<t>Added diagrams for architecture and state machine.</t>
<t>Added sections on forking and rehydration.</t>
<t>Clarified meaning of "pranswer" and "answer".</t>
<t>Reworked how ICE restarts and media directions are
controlled.</t>
<t>Added list of parameters that can be changed in a
description.</t>
<t>Updated suggested API and examples to match latest thinking.</t>
<t>Suggested API and examples have been moved to an appendix.</t>
</list></t>
<t>Changes in draft -00: <list style="symbols">
<t>Migrated from draft-uberti-rtcweb-jsep-02.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:38:12 |