One document matched: draft-ietf-rtcweb-jsep-07.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-07" 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="4" month="July" year="2014" />
<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>When the call is accepted, the callee uses the createAnswer() API
to generate an appropriate answer, applies it using
setLocalDescription(), and sends the answer back to the initiator over
the signaling channel. When the offerer gets that answer, it installs
it using setRemoteDescription(), 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 SRTP
parameters <xref target="RFC4568"></xref> sent to a remote party
indicate what the local side will use to encrypt, and thereby what the
remote party should expect to receive; the remote party will have to
accept these parameters, with no option to choose a different
value. [[OPEN ISSUE: This is not correct because we removed SDES
(https://github.com/rtcweb-wg/jsep/issues/10)]]
</t>
<t>In addition, various RFCs put different conditions on the format of
offers versus answers. For example, a offer may propose multiple SRTP
configurations, but an answer may only contain a single SRTP
configuration. [[OPEN ISSUE: See issue 10 above.]]</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">
<t>When a new ICE candidate is available, the ICE Agent will notify
the application via a callback; these candidates will automatically be
added to the local session description. When all candidates have been
gathered, the callback will also be invoked to signal that the
gathering process is complete.</t>
<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 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", as defined in <xref
target="RFC5888"></xref>, to identify the m-line. WebRTC
implementations creating an ICE Candidate object MUST populate both of
these fields. Implementations receiving an ICE Candidate object SHOULD
use the MID if they implement that functionality, or the m-line index,
if not.</t>
</section>
</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 for which to gather
candidates. However, to accelerate cases where the application knows
the number of media streams to use ahead of time, it MAY
ask the browser to gather a pool of potential ICE candidates to help
ensure rapid media setup. 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 callback. If the pool becomes
depleted, either because a larger-than-expected number of media
streams is used, or because the pool has not had enough time to gather
candidates, the remaining candidates are gathered as usual.
</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 to 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. The size of the
ICE candidate pool can also be set, if desired; this indicates the
number of ICE components to pre-gather candidates for. If the application
does not indicate a candidate pool size, the browser may
select any default candidate pool size.
</t>
<t>In addition, 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-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>
<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>
</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", and "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 setRemoteDescription was previously 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="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, or if the PeerConnection has been closed.</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, or if the PeerConnection has been closed.</t>
</section>
<section title="updateIce" anchor="sec.updateice">
<t>The updateIce method allows the configuration of the ICE Agent to
be changed during the session, primarily for changing which types of
local candidates are provided to the application and used for
connectivity checks. A callee may initially configure the ICE Agent
to use only relay candidates, to avoid leaking location information,
but update this configuration to use all candidates once the call is
accepted.</t>
<t>Regardless of the configuration, the gathering process collects
all available candidates, but excluded candidates will not be
surfaced in onicecandidate callback or used for connectivity
checks.</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 RTP profile.</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.</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="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>
</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>Either the UDP/TLS/RTP/SAVP or the UDP/TLS/RTP/SAVPF RTP
profile, as specified in <xref target="RFC5764"></xref>,
MUST be used.</t>
<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-SRTP, as specified in <xref target="RFC5763"></xref>,
MUST be used.</t>
</list></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; if this m= section is not being bundled into
another m= section, the port value MUST be unique. If no candidates
have yet been gathered, and a 'null' port value is being used, as
indicated in <xref target="I-D.ietf-mmusic-trickle-ice"></xref>,
Section 5.1., this port MUST still be unique.</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.</t>
</list>
</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.</t>
<t>An "a=msid" line, as specified in <xref
target="I-D.ietf-mmusic-msid"></xref>, Section 2.</t>
<t>[OPEN ISSUE: Use of AppID]</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. For
audio, the codecs specified in <xref
target="I-D.ietf-rtcweb-audio"></xref>, Section 3, MUST be be
supported.</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 corresponding "a=rtpmap"
line indicating the desired FEC codec.</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>For each candidate that has been gathered during the most
recent gathering phase, an "a=candidate" line, as specified in
<xref target="RFC5245"></xref>, Section 4.3., paragraph 3.</t>
<t>For the current default candidate, a "c=" line, as specified
in <xref target="RFC5245"></xref>, Section 4.3., paragraph 6.
If no candidates have been gathered yet, the default candidate
should be set to the 'null' value defined in <xref
target="I-D.ietf-mmusic-trickle-ice"></xref>, Section 5.1.</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, as specified
in <xref target="RFC5576"></xref>, section 4.2, with semantics
set to "FEC" and including the primary and FEC SSRCs.</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 "default", 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
"DTLS/SCTP", as specified in <xref
target="I-D.ietf-mmusic-sctp-sdp"></xref>, Section 3; the "fmt" value
MUST be set to the SCTP port number, as specified in Section 4.1.</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 "a=mid" line MUST stay the same.</t>
<t>Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the
same unless the "IceRestart" option (<xref target="sec.options-handling"/>
was specified. Note that it's not clear why you would actually
want to do this, since at this point ICE has not yet started
and is thus unlikely to need a restart.
</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-handling">
<t>The createOffer method takes as a parameter an RTCOfferOptions
object. Special processing is performed when generating a SDP
description if the following constraints are present.</t>
<section title="OfferToReceiveAudio" anchor="sec.offertoreceiveaudio">
<t>If the "OfferToReceiveAudio" option is specified, with an integer
value of N, the offer MUST include N non-rejected m= sections
with media type "audio", even if fewer than N audio
MediaStreamTracks have been added to the PeerConnection. This allows
the offerer to receive audio, including multiple independent
streams, even when not sending it; accordingly, the directional
attribute on the audio m= sections without associated
MediaStreamTracks MUST be set to recvonly. If this option is
specified in the case where at least N audio MediaStreamTracks have
already been added to the PeerConnection, or N non-rejected
m= sections with media type "audio" would otherwise be generated,
it has no effect. For backwards compatibility, a value of "true"
is interpreted as equivalent to N=1.</t>
</section>
<section title="OfferToReceiveVideo" anchor="sec.offertoreceivevideo">
<t>If the "OfferToReceiveVideo" option is specified, with an integer
value of N, the offer MUST include N non-rejected m= sections
with media type "video", even if fewer than N video
MediaStreamTracks have been added to the PeerConnection. This allows
the offerer to receive video, including multiple independent
streams, even when not sending it; accordingly, the directional
attribute on the video m= sections without associated
MediaStreamTracks MUST be set to recvonly. If this option is
specified in the case where at least N video MediaStreamTracks have
already been added to the PeerConnection, or N non-rejected
m= sections with media type "video" would otherwise be generated,
it has no effect. For backwards compatibility, a value of "true"
is interpreted as equivalent to N=1.</t>
</section>
<section title="VoiceActivityDetection" anchor="sec.voiceactivitydetection">
<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 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 RFC5245, 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). This option is useful for reestablishing connectivity
in cases where failures are detected.
</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. Because use of DTLS is
mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF".
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>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>[OPEN ISSUE: Use of AppID]</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. For audio, the codecs
specified in <xref target="I-D.ietf-rtcweb-audio"></xref>,
Section 3, MUST be supported. 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 "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 that is present in the
offer, a corresponding "a=rtpmap" line indicating the desired
FEC codec.</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>For each candidate that has been gathered during the most
recent gathering phase, an "a=candidate" line, as specified in
<xref target="RFC5245"></xref>, Section 4.3., paragraph 3.</t>
<t>For the current default candidate, a "c=" line, as specified
in <xref target="RFC5245"></xref>, Section 4.3., paragraph 6.
If no candidates have been gathered yet, the default candidate
should be set to the 'null' value defined in <xref
target="I-D.ietf-mmusic-trickle-ice"></xref>, Section 5.1.</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.</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, as specified in <xref
target="RFC5576"></xref>, section 4.2, with semantics set to
"FEC" and including the primary and FEC SSRCs.</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
"DTLS/SCTP", as specified in <xref
target="I-D.ietf-mmusic-sctp-sdp"></xref>, Section 3; the "fmt" value
MUST be set to the SCTP port number, as specified in Section 4.1.</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"></section>
<section title="Options Handling" anchor="sec.options-handling2"></section>
</section>
<section title="Parsing an Offer" anchor="sec.parsing-an-offer"></section>
<section title="Parsing an Answer" anchor="sec.parsing-an-answer"></section>
<section title="Applying a Local Description" anchor="sec.applying-a-local-descript"></section>
<section title="Applying a Remote Description" anchor="sec.applying-a-remote-descrip"></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, 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>
</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 constraints 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="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-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 -->
<!-- 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>
</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="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 -->
<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>
<!-- 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="JSEP Implementation Examples" anchor="sec.jsep-implementation-examp">
<section title="Example API Flows" anchor="sec.example-api-flows">
<t>Below are several sample flows for the new PeerConnection and
library APIs, demonstrating when the various APIs are called in
different situations and with various transport protocols. For clarity
and simplicity, the createOffer/createAnswer calls are assumed to be
synchronous in these examples, whereas the actual APIs are async.</t>
<section title="Call using ROAP" anchor="sec.call-using-roap">
<t>This example demonstrates a ROAP call, without the use of trickle
candidates. <figure>
<artwork><![CDATA[
// Call is initiated toward Answerer
OffererJS->OffererUA: pc = new PeerConnection();
OffererJS->OffererUA: pc.addStream(localStream, null);
OffererUA->OffererJS: iceCallback(candidate);
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS->AnswererJS: {"type":"OFFER", "sdp":offer }
// OFFER arrives at Answerer
AnswererJS->AnswererUA: pc = new PeerConnection();
AnswererJS->AnswererUA: pc.setRemoteDescription("offer", msg.sdp);
AnswererUA->AnswererJS: onaddstream(remoteStream);
AnswererUA->OffererUA: iceCallback(candidate);
// Answerer accepts call
AnswererJS->AnswererUA: pc.addStream(localStream, null);
AnswererJS->AnswererUA: answer = pc.createAnswer(msg.sdp, null);
AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer);
AnswererJS->OffererJS: {"type":"ANSWER","sdp":answer }
// ANSWER arrives at Offerer
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
OffererUA->OffererJS: onaddstream(remoteStream);
// ICE Completes (at Answerer)
AnswererUA->OffererUA: Media
// ICE Completes (at Offerer)
OffererJS->AnswererJS: {"type":"OK" }
OffererUA->AnswererUA: Media
]]></artwork>
</figure></t>
</section>
<section title="Call using XMPP" anchor="sec.call-using-xmpp">
<t>This example demonstrates an XMPP call, making use of trickle
candidates. <figure>
<artwork><![CDATA[
// Call is initiated toward Answerer
OffererJS->OffererUA: pc = new PeerConnection();
OffererJS->OffererUA: pc.addStream(localStream, null);
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS: xmpp = createSessionInitiate(offer);
OffererJS->AnswererJS: <jingle action="session-initiate"/>
OffererJS->OffererUA: pc.startIce();
OffererUA->OffererJS: onicecandidate(cand);
OffererJS: createTransportInfo(cand);
OffererJS->AnswererJS: <jingle action="transport-info"/>
// session-initiate arrives at Answerer
AnswererJS->AnswererUA: pc = new PeerConnection();
AnswererJS: offer = parseSessionInitiate(xmpp);
AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer);
AnswererUA->AnswererJS: onaddstream(remoteStream);
// transport-infos arrive at Answerer
AnswererJS->AnswererUA: candidate = parseTransportInfo(xmpp);
AnswererJS->AnswererUA: pc.addIceCandidate(candidate);
AnswererUA->AnswererJS: onicecandidate(cand)
AnswererJS: createTransportInfo(cand);
AnswererJS->OffererJS: <jingle action="transport-info"/>
// transport-infos arrive at Offerer
OffererJS->OffererUA: candidates = parseTransportInfo(xmpp);
OffererJS->OffererUA: pc.addIceCandidate(candidates);
// Answerer accepts call
AnswererJS->AnswererUA: pc.addStream(localStream, null);
AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null);
AnswererJS: xmpp = createSessionAccept(answer);
AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer);
AnswererJS->OffererJS: <jingle action="session-accept"/>
// session-accept arrives at Offerer
OffererJS: answer = parseSessionAccept(xmpp);
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
OffererUA->OffererJS: onaddstream(remoteStream);
// ICE Completes (at Answerer)
AnswererUA->OffererUA: Media
// ICE Completes (at Offerer)
OffererUA->AnswererUA: Media
]]></artwork>
</figure></t>
</section>
<section title="Adding video to a call, using XMPP" anchor="sec.adding-video-to-a-call-us">
<t>This example demonstrates an XMPP call, where the XMPP
content-add mechanism is used to add video media to an existing
session. For simplicity, candidate exchange is not shown.</t>
<t>Note that the offerer for the change to the session may be
different than the original call offerer. <figure>
<artwork><![CDATA[
// Offerer adds video stream
OffererJS->OffererUA: pc.addStream(videoStream)
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS: xmpp = createContentAdd(offer);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS->AnswererJS: <jingle action="content-add"/>
// content-add arrives at Answerer
AnswererJS: offer = parseContentAdd(xmpp);
AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer);
AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null);
AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer);
AnswererJS: xmpp = createContentAccept(answer);
AnswererJS->OffererJS: <jingle action="content-accept"/>
// content-accept arrives at Offerer
OffererJS: answer = parseContentAccept(xmpp);
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
]]></artwork>
</figure></t>
</section>
<section title="Simultaneous add of video streams, using XMPP" anchor="sec.simultaneous-add-of-video">
<t>This example demonstrates an XMPP call, where new video sources
are added at the same time to a call that already has video; since
adding these sources only affects one side of the call, there is no
conflict. The XMPP description-info mechanism is used to indicate
the new sources to the remote side. <figure>
<artwork><![CDATA[
// Offerer and "Answerer" add video streams at the same time
OffererJS->OffererUA: pc.addStream(offererVideoStream2)
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS: xmpp = createDescriptionInfo(offer);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS->AnswererJS: <jingle action="description-info"/>
AnswererJS->AnswererUA: pc.addStream(answererVideoStream2)
AnswererJS->AnswererUA: offer = pc.createOffer(null);
AnswererJS: xmpp = createDescriptionInfo(offer);
AnswererJS->AnswererUA: pc.setLocalDescription("offer", offer);
AnswererJS->OffererJS: <jingle action="description-info"/>
// description-info arrives at "Answerer", and is acked
AnswererJS: offer = parseDescriptionInfo(xmpp);
AnswererJS->OffererJS: <iq type="result"/> // ack
// description-info arrives at Offerer, and is acked
OffererJS: offer = parseDescriptionInfo(xmpp);
OffererJS->AnswererJS: <iq type="result"/> // ack
// ack arrives at Offerer; remote offer is used as an answer
OffererJS->OffererUA: pc.setRemoteDescription("answer", offer);
// ack arrives at "Answerer"; remote offer is used as an answer
AnswererJS->AnswererUA: pc.setRemoteDescription("answer", offer);
]]></artwork>
</figure></t>
</section>
<section title="Call using SIP" anchor="sec.call-using-sip">
<t>This example demonstrates a simple SIP call (e.g. where the
client talks to a SIP proxy over WebSockets). <figure>
<artwork><![CDATA[
// Call is initiated toward Answerer
OffererJS->OffererUA: pc = new PeerConnection();
OffererJS->OffererUA: pc.addStream(localStream, null);
OffererUA->OffererJS: onicecandidate(candidate);
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS: sip = createInvite(offer);
OffererJS->AnswererJS: SIP INVITE w/ SDP
// INVITE arrives at Answerer
AnswererJS->AnswererUA: pc = new PeerConnection();
AnswererJS: offer = parseInvite(sip);
AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer);
AnswererUA->AnswererJS: onaddstream(remoteStream);
AnswererUA->OffererUA: onicecandidate(candidate);
// Answerer accepts call
AnswererJS->AnswererUA: pc.addStream(localStream, null);
AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null);
AnswererJS: sip = createResponse(200, answer);
AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer);
AnswererJS->OffererJS: 200 OK w/ SDP
// 200 OK arrives at Offerer
OffererJS: answer = parseResponse(sip);
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
OffererUA->OffererJS: onaddstream(remoteStream);
OffererJS->AnswererJS: ACK
// ICE Completes (at Answerer)
AnswererUA->OffererUA: Media
// ICE Completes (at Offerer)
OffererUA->AnswererUA: Media
]]></artwork>
</figure></t>
</section>
<section title="Handling early media (e.g. 1-800-GO FEDEX), using SIP" anchor="sec.handling-early-media-eg-1">
<t>This example demonstrates how early media could be handled; for
simplicity, only the offerer side of the call is shown. <figure>
<artwork><![CDATA[
// Call is initiated toward Answerer
OffererJS->OffererUA: pc = new PeerConnection();
OffererJS->OffererUA: pc.addStream(localStream, null);
OffererUA->OffererJS: onicecandidate(candidate);
OffererJS->OffererUA: offer = pc.createOffer(null);
OffererJS->OffererUA: pc.setLocalDescription("offer", offer);
OffererJS: sip = createInvite(offer);
OffererJS->AnswererJS: SIP INVITE w/ SDP
// 180 Ringing is received by offerer, w/ SDP
OffererJS: answer = parseResponse(sip);
OffererJS->OffererUA: pc.setRemoteDescription("pranswer", answer);
OffererUA->OffererJS: onaddstream(remoteStream);
// ICE Completes (at Offerer)
OffererUA->AnswererUA: Media
// 200 OK arrives at Offerer
OffererJS: answer = parseResponse(sip);
OffererJS->OffererUA: pc.setRemoteDescription("answer", answer);
OffererJS->AnswererJS: ACK
]]></artwork>
</figure></t>
</section>
</section>
<section title="Example Session Descriptions" anchor="sec.example-session-descripti">
<section title="createOffer" anchor="sec.createoffer2">
<t>This SDP shows a typical initial offer, created by createOffer
for a PeerConnection with a single audio MediaStreamTrack, a single
video MediaStreamTrack, and a single data channel. Host candidates
have also already been gathered. Note some lines have been broken
into two lines for formatting reasons.</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 audio video data
m=audio 56500 UDP/TLS/RTP/SAVPF 111 0 8 126
c=IN IP4 192.0.2.1
a=rtcp:56501 IN IP4 192.0.2.1
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500
typ host generation 0
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501
typ host generation 0
a=ice-ufrag:ETEn1v9DoTMB9J4r
a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl
a=ice-options:trickle
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
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=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7
a=msid:47017fee-b6c1-4162-929c-a25110252400
f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
m=video 56502 UDP/TLS/RTP/SAVPF 100 115 116 117
c=IN IP4 192.0.2.1
a=rtcp:56503 IN IP4 192.0.2.1
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502
typ host generation 0
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503
typ host generation 0
a=ice-ufrag:BGKkWnG5GmiUpdIV
a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf
a=ice-options:trickle
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
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=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=100
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7
a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7
a=ssrc:1366781085 cname:EocUG1f0fcg/yvY7
a=ssrc-group:FID 1366781083 1366781084
a=ssrc-group:FEC 1366781083 1366781085
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
m=application 56504 DTLS/SCTP 5000
c=IN IP4 192.0.2.1
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56504
typ host generation 0
a=ice-ufrag:VD5v2BnbZm3mgP3d
a=ice-pwd:+Jlkuox+VVIUDqxcfIDuTZMH
a=ice-options:trickle
a=mid:data
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=sctpmap:5000 webrtc-datachannel 16
]]></artwork>
</figure>
</section>
<section title="createAnswer" anchor="sec.createanswer2">
<t>This SDP shows a typical initial answer to the above offer,
created by createAnswer for a PeerConnection with a single audio
MediaStreamTrack, a single video MediaStreamTrack, and a single data
channel. Host candidates have also already been gathered. Note some
lines have been broken into two lines for formatting reasons.</t>
<figure>
<artwork><![CDATA[
v=0
o=- 6729291447651054566 1 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS
a=group:BUNDLE audio video data
m=audio 20000 UDP/TLS/RTP/SAVPF 111 0 8 126
c=IN IP4 192.0.2.2
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host generation 0
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=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
m=video 20000 UDP/TLS/RTP/SAVPF 100 115 116 117
c=IN IP4 192.0.2.2
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host generation 0
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=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=100
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:3229706347 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 3229706345 3229706346
a=ssrc-group:FEC 3229706345 3229706347
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0
m=application 20000 DTLS/SCTP 5000
c=IN IP4 192.0.2.2
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host generation 0
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=mid:data
a=sctpmap:5000 webrtc-datachannel 16
]]></artwork>
</figure>
</section>
<section title="Call Flows" anchor="sec.call-flows">
<t>Example SDP for WebRTC call flows can be found in <xref
target="I-D.nandakumar-rtcweb-sdp"></xref>. [TODO: should these
call flows be merged into this section?]</t>
</section>
</section>
</section>
<section title="Change log" anchor="sec.change-log">
<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:35:28 |