One document matched: draft-ivov-rtcweb-noplan-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" ipr="trust200902"
docName="draft-ivov-rtcweb-noplan-00">
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<?rfc compact='yes' ?>
<front>
<title abbrev="No Plan: SDP O/A with Multiple SSRCs ">No Plan:
Economical Use of the Offer/Answer Model in WebRTC Sessions with
Multiple Media Sources
</title>
<author initials='E.' surname='Ivov' fullname='Emil Ivov'>
<organization abbrev='Jitsi'>Jitsi</organization>
<address>
<postal>
<street></street>
<city>Strasbourg</city>
<code>67000</code>
<country>France</country>
</postal>
<phone>+33-177-624-330</phone>
<email>emcho@jitsi.org</email>
</address>
</author>
<date/>
<abstract>
<t>
This document describes a model for the lightweight use of SDP
Offer/Answer in WebRTC. The goal is to minimize reliance on
Offer/Answer exchanges in a WebRTC session and provide
applications with the tools necessary to implement the
signalling that they may need in a way that best fits their
custom requirements and topologies. This simplifies signalling
of multiple media sources or providing RTP Synchronisation
source (SSRC) identification in multi-party sessions. Another
important goal of this model is to remove from clients
topological constraints such as the requirement to know in
advance all SSRC identifiers that they could potentially
introduce in a particular session.
</t>
<t>
This document does not question the use of SDP and the
Offer/Answer model or the value they have in terms of
interoperability with legacy or other non-WebRTC devices.
</t>
</abstract>
</front>
<middle>
<section title='Background' anchor="background">
<t>
In its early stages the RTCWEB working group chose to use the
Session Description Protocol (SDP) and the Offer/Answer model
<xref target="RFC3264"/> when establishing and
negotiating sessions. This choice was also accompanied by the
decision not to mandate a specific signalling protocol so that,
once interoperability has been achieved, web applications can
choose the semantics that best fit their requirements. In some
scenarios however, such as those involving the use of multiple
media sources, these choices have left open the issue of exactly
which operations should be handled by SDP Offer/Answer and which
of them should be left to application-specific signalling.
</t>
<t>
At the time of writing of this document, the RTCWEB working
group is considering two approaches to addressing the issue,
that are often referred to as Plan A <xref target="PlanA"/> and
Plan B <xref target="PlanB"/>. Both of them describe semantics
that require Offer/Answer exchanges in a number of situations
where this could be avoided, particularly when adding or
removing media sources to a session. This requirement applies
equally to cases where a client adds the stream of a newly
activated web cam, a simulcast flow or upon the arrival or
departure of a conference participant.
</t>
<t>
Plan A handles such notifications with the addition or removal
of independent m= lines <xref target="PlanA"/>, while Plan B
relies on the use of multiplexed m= lines but still depends
on the Offer/Answer exchanges for the addition or removal of
media stream identifiers <xref target="MSID"/>.
</t>
<t>
By taking the Offer/Answer approach, both Plan A and Plan B
take away from the application the opportunity to handle such
events in a way that is most fitting for the use case, which,
among other things, also goes against the working group's
decision to not to define a specific signalling protocol. (It
could be argued that it is therefore only natural how proponents
of each plan, having different use cases in mind, are remarkably
far from reaching consensus).
</t>
<t>
Another problem, more specific to Plan B, is the reliance on
preliminary announcement of SSRC identifiers for stream
identification. Why this could be perceived as relatively
straightforward in one-to-one sessions or even conference calls
within controlled environments, it can be a problem in the
following cases:
</t>
<t>
<list style="symbols">
<t>
interoperability with legacy/non-WebRTC endpoints
</t>
<t>
use within non-controlled and potentially federated
conference environments where new RTP streams may appear
relatively often. In such cases the signalling required to
describe all of them through Offer/Answer may represent
substantial overhead while none or only a part of it (e.g.
the description of a main, active speaker stream) may be
required by the application.
</t>
</list>
</t>
<t>
By increasing the number of Offer/Answer exchanges Both Plan A
and Plan B also increase the risk of encountering glare
situations (i.e. cases where both parties attempt to modify a
session at the same time). While glare is also possible with
basic Offer/Answer and resolution of such situations must
be implemented anyway, the need to frequently resort to such
code may either negatively impact user experience (e.g. when
"back off" resolution is used) or require substantial
modifications in the Offer/Answer model and/or further venturing
into the land of signalling protocols
<xref target="ROACH-GLARELESS-ADD"/>.
</t>
<t>
Finally, both Plan A and Plan B, also create expectations that
fine grained control of FEC, layering and RTX flows will always
be implemented through Offer/Answer, which would not necessarily
the best way to handle this in congested situations.
</t>
</section>
<section title='Introduction' anchor="intro">
<t>
The goal of this document is to provide directions for use of
the SDP Offer/Answer model in a way that satisfies the following
requirements:
</t>
<t>
<list style="symbols">
<t>
the addition and removal of media sources (e.g. conference
participants, multiple web cams or "slides" ) must be
possible without the need of Offer/Answer exchanges;
</t>
<t>
the addition or removal of simulcast or layered streams must
be possible without the need for Offer/Answer exchanges
beyond the initial declaration of such capabilities for
either direction.
</t>
<t>
call establishment must not require preliminary announcement
or even knowledge of all potentially participating media
sources;
</t>
<t>
application specific signalling should be used to cover most
semantics following call establishment, such as adding,
removing or identifying SSRCs;
</t>
<t>
straightforward interoperability with widely deployed legacy
endpoints with rudimentary support for Offer/Answer. This
includes devices that allow for one audio and potentially
one video m= line and that expect to only ever be required
to render a single RTP stream at a time for any of them.
(Note that this does NOT include devices that expect to see
multiple "m=video" lines for different SSRCs as they can
hardly be viewed as "widely deployed legacy").
</t>
</list>
</t>
<t>
To achieve the above requirements this specification expects
that browsers and WebRTC endpoints in general will only use
SDP Offer/Answer to establish transport channels and initialize
an RTP stack and codec/processing chains. This also includes any
renegotiation that requires the re-initialisation of these
chains. For example, adding VP8 to a session that was setup with
only H.264, would obviously still require an Offer/Answer
exchange.
</t>
<t>
All other session control and signalling are to be left to
applications.
</t>
<t>
The actual Offer/Answer semantics presented here do not differ
fundamentally from those proposed by Plan A and Plan B. The main
differentiation point of this approach is the fact that the
exact protocol mechanism is left to WebRTC applications. Such
applications or lightweight signalling gateways can then
implement either Plan A, or Plan B, or an entirely different
signalling protocol, depending on what best matches their use
cases and topology.
</t>
</section>
<section title="Reliance on Offer/Answer" anchor="offer-answer">
<t>
The model presented in this specification relies on use of
SDP and Offer/Answer in quite the same way as many of the
pre-WebRTC (and most of the legacy) endpoints do: negotiating
formats, establishing transport channels and exchanging, in a
declarative way, media and transport parameters that are then
used for the initialization of the corresponding stacks.
</t>
<t>
The following is an example presenting what this specification
views as a typical offer sent by a WebRTC endpoint:
<figure>
<artwork align="left" xml:space="preserve">
<![CDATA[
v=0
o=- 0 0 IN IP4 198.51.100.33
s=
t=0 0
a=group:BUNDLE audio video // declaring BUNDLE Support
c=IN IP4 198.51.100.33
a=ice-ufrag:Qq8o/jZwknkmXpIh // initializing ICE
a=ice-pwd:gTMACiJcZv1xdPrjfbTHL5qo
a=ice-options:trickle
a=fingerprint:sha-1 // DTLS-SRTP keying
a4:b1:97:ab:c7:12:9b:02:12:b8:47:45:df:d8:3a:97:54:08:3f:16
m=audio 5000 RTP/SAVPF 96 0 8
a=mid:audio
a=rtcp-mux
a=rtpmap:96 opus/48000/2 // PT mappings
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level //5825 header
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level //extensions
[ICE Candidates]
m=video 5002 RTP/SAVPF 97 98
a=mid:video
a=rtcp-mux
a=rtpmap:97 VP8/90000 // PT mappings and resolutions capabilities
a=imageattr:97 \
send [x=[480:16:800],y=[320:16:640],par=[1.2-1.3],q=0.6] \
[x=[176:8:208],y=[144:8:176],par=[1.2-1.3]] \
recv *
a=rtpmap:98 H264/90000
a=imageattr:98 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \
recv [x=330,y=250]
a=extmap:3 urn:ietf:params:rtp-hdrext:fec-source-ssrc //5825 header
a=extmap:4 urn:ietf:params:rtp-hdrext:rtx-source-ssrc //extensions
a=max-send-ssrc:{*:1} // declaring maximum
a=max-recv-ssrc:{*:4} // number of SSRCs
[ICE Candidates]
]]>
</artwork>
</figure>
The answer to the offer above would have roughly the same
structure and content. The most important aspects here are:
</t>
<t>
<list style="symbols">
<t>
Preserves interoperability with most kinds of legacy or
non-WebRTC endpoints.
</t>
<t>
Allows the negotiation of most parameters that concern the
media/RTP stack (typically the browser).
</t>
<t>
Only a single Offer/Answer exchange is required for session
establishment and, in most cases, for the entire duraftion
of a session.
</t>
<t>
Leaves complete freedom to applications as to the way that
they are going to signal any other information such as
SSRC identification information or the addition or removal
of RTP streams.
</t>
</list>
</t>
<t>
</t>
<section title="Interoperability with Legacy" anchor="interop">
<t>
Interoperating with the "widely deployed legacy endpoints" is
one of the main reasons for the RTCWEB working group to choose
the SDP Offer/Answer model as basis for media negotiation. It
is hence important to clarify the compatibility claims that
this specification makes.
</t>
<t>
A "widely deployed legacy endpoint" is considered to have the
following characteristics:
</t>
<t>
<list style="symbols">
<t>
Likely to use the SIP protocol.
</t>
<t>
Capability to gracefully handle one audio and potentially
one video m= line in an SDP Offer.
</t>
<t>
Capability to render one SSRC per m=line at any given
moment but multiple, consecutive SSRCs over a
period of time. This would be the case with transferred
session replacements for example. While the capability to
handle multiple SSRCs simultaneously is not uncommon it
cannot be relied upon and should first be confirmed by
signalling.
</t>
<t>
Possibly have features such as ICE, BUNDLE, RTCP-MUX, etc.
Just as likely not to.
</t>
<t>
Very unlikely to announce in SDP the SSRCs that they
intend to use for a given session.
</t>
<t>
Exact set of features and capabilities: Guaranteed to be
wildly and widely diverse.
</t>
</list>
</t>
<t>
While it is relatively simple for RTCWEB to accommodate some
of the above, it is obviously impossible to design a model
that could simply be labeled as "compatible with legacy". It
is reasonable to assume that use cases involving use of such
endpoints will be designed for a relatively specific set of
devices and applications. The role of the WebRTC framework is
to hence provide a least-common-denominator model that can
then be extended by applications.
</t>
<t>
It is just as important not to make choices or assumptions
that will render interoperability for some applications or
topologies difficult or even impossible.
</t>
<t>
This is exactly what the use of Offer/Answer discussed here
strives to achieve. Audio/Video offers originating from WebRTC
endpoints will always have a maximum of one audio and one
video m= line. It will be up to applications to determine
exactly how many streams they can afford to send once such
a session has been established. The exact mechanism to do this
is outside the scope of this document (or WebRTC in general).
</t>
<t>
Note that it is still possible for WebRTC endpoints to
indicate support for a maximum number of incoming or outgoing
streams for reasons such as processing constraints. Use of the
"max-send-ssrc" and "max-recv-ssrc" attributes
<xref target="MAX-SSRC"/> could be one way of doing this,
although that mechanism would need to be extended to provide
ways of distinguishing between independent flows and
complementary ones such as layered FEC and RTX. Even with this
in mind it is still important, not to rely on the presence of
that indication in incoming descriptions as well as to provide
applications with a way of retrieving such capabilities from
the WebRTC stack (e.g. the browser).
</t>
<t>
Determining whether a peer has the ability to seamlessly
switch from one SSRC to another is also left to application
specific signalling. It is worth noting that protocols such
as SIP for example, often accompany SSRC replacements with
extra signalling (re-INVITEs with a "replaces" header) that
can easily be reused by applications or mapped to something
that they deem more convenient.
</t>
<t>
For the sake of interoperability this specification strongly
advises against the use of multiple m= lines for a single
media type. Not only would such use be meaningless to a large
number of legacy endpoints but it is also likely to be
mishandled by many of them and to cause unexpected behaviour.
</t>
<t>
Finally, it is also worth pointing out that there is a
significant number of feature rich non-WebRTC applications and
devices that have relatively advanced, modern sets of
capabilities. Such endpoints hardly fit the "legacy"
qualification. Yet, as is often the case with novel and/or
proprietary applications, they too have adopted diverse
signalling mechanisms and the requirements described in this
section fully apply when it comes to interoperating with them.
</t>
</section>
</section>
<section title="Additional Session Control and Signalling"
anchor="session-control">
<t>
<list style="symbols">
<t>
Adding and removing RTP streams to an existing session.
</t>
<t>
Accepting and refusing some of them.
</t>
<t>
Identifying SSRCs and obtaining additional metadata for
them (e.g. the user corresponding to a specific SSRC).
</t>
</list>
</t>
<t>
All of the above semantics are best handled and hence should be
left to applications. There are numerous existing or emerging
solutions, some of them developed by the IETF, that already
cover this. This includes CLUE channels <xref target="CLUE"/>,
the SIP Event Package For Conference State
<xref target="RFC4575"/> and its XMPP variant
<xref target="COIN"/>. Additional mechanisms, undoubtedly many
based on JSON, are very likely to emerge in the future as WebRTC
applications address varying use cases, scenarios and
topologies.
</t>
<t>
The most important part of this specification is hence to
prevent certain assumptions or topologies from being imposed on
applications. One example of this is the need to know and
include in the Offer/Answer exchange, all the SSRCs that can
show up in a session. This can be particularly problematic for
scenarios that involve non-WebRTC endpoints.
</t>
<t>
Large scale conference calls, potentially federated through
RTP translator-like bridges, would be another problematic
scenario. Being able to always pre-announce SSRCs in such
situations could of course be made to work but it would come at
a price. It would either require a very high number of
Offer/Answer updates that propagate the information through the
entire topology, or use of tricks such as pre-allocating a range
of "fake" SSRCs, announcing them to participants and then
overwriting the actual SSRCs with them. Depending on the
scenario both options could prove inappropriate or inefficient
while some applications may not even need such information.
Others could be retrieving it through simplistic means such as
access to a centralized resource (e.g. an URL pointing to a JSON
description of the conference).
</t>
</section>
<section title="Demultiplexing and Identifying Streams (Use of Bundle)"
anchor="bundle">
<t>
This document assumes use of BUNDLE in WebRTC endpoints. This
implies that all RTP streams are likely to end up being received
on the same port. A demuxing mechanism is therefore necessary in
order for these packets to then be fed into the appropriate
processing chain (i.e. matched to an m= line).
</t>
<t>
<list>
<t>Note: it is important to distinguish between the
demultiplexing and the identification of incoming flows.
Throughout this specification the former is used to refer to
the process of choosing selecting a
depacketizing/decoding/processing chain to feed incoming
packets to. Such decisions depend solely on the format that
is used to encode the content of incoming packets.
</t>
<t>
The above is not to be confused with the process of making
rendering decision about a processed flow. Such decisions
include showing a "current speaker" flow at a specific
location, window or video tag, while choosing a different
one for a second, "slides" flow. Another example would be
the possibility to attach "Alice", "Bob" and "Carol" labels
on top of the appropriate UI components. This specification
leaves such rendering choices entirely to
application-specific signalling as described in
<xref target="session-control"/>.
</t>
</list>
</t>
<t>
This specification uses demuxing based on RTP payload types.
When creating offers and answers WebRTC applications MUST
therefore allocate RTP payload types only once per bundle group.
In cases where rtcp-mux is in use this would mean a maximum of
96 payload types per bundle <xref target="RFC5761"/>. It has
been pointed out that some legacy devices may have unpredictable
behaviour with payload types that are outside the 96-127 range
reserved by <xref target="RFC3551"/> for dynamic use. Some
applications or implementations may therefore choose not to use
values outside this range. Whatever the reason, offerers that
find they need more than the available payload type numbers,
will simply need to either use a second bundle group or not use
BUNDLE at all (which in the case of a single audio and a single
video m= line amounts to roughly the same thing). This would
also imply building a dynamic table, mapping SSRCs to PTs and
m= lines, in order to then also allow for RTCP demuxing.
</t>
<t>
While not desirable, the implications of such a decision would
be relatively limited. Use of trickle ICE
<xref target="TRICKLE-ICE"/> is going to lessen the impact on
call establishment latency. Also, the fact that this would only
occur in a limited number of cases makes it unlikely to have
a significant effect on port consumption.
</t>
<t>
An additional requirement that has been expressed toward
demuxing is the ability to assign incoming packets with the same
payload type to different processing chains depending on their
SSRCs. A possible example for this is a scenario where two video
streams are being rendered on different video screens that each
have their own decoding hardware.
</t>
<t>
While the above may appear as a demuxing and a decoding related
problem it is really mostly a rendering policy specific to an
application. As such it should be handled by app. specific
signalling that could involve custom-formatted, per-SSRC
information that accompanies SDP offers and answers.
</t>
</section>
<section title="Simulcasting, FEC, Layering and RTX (Open Issue)"
anchor="repair-flows">
<t>
From a WebRTC perspective, repair flows such as layering, FEC,
RTX and to some extent simulcasting, present an interesting
challenge, which is why they are considered an open issue by
this specification.
</t>
<t>
On the one hand they are transport utilities that need to be
understood, supported and used by browsers in a way that is
mostly transparent to applications. On the other, some
applications may need to be made aware of them and given the
option to control their use. This could be necessary in cases
where their use needs to be signalled to non-WebRTC endpoints
in an application specific way. Another example is the
possibility for an application to choose to disable some or all
repair flows because it has been made aware by
application-specific signalling that they are temporarily not
being used/rendered by the remote end (e.g. because it is only
displaying a thumbnail or because a corresponding video tag
is not currently visible).
</t>
<t>
One way of handling such flows would be to advertise them in the
way suggested by <xref target="RFC5956"/> and to then control
them through application specific signalling. This options has
the merit of already existing but it also implies the
pre-announcement and propagation of SSRCs and the bloated
signalling that this incurs. Also, relying solely on
Offer/Answer here would expose an offerer to the typical race
condition of repair SSRCs arriving before the answer and the
processing ambiguity that this would imply.
</t>
<t>
Another approach could be a combination of RTCP and
RTP header extensions <xref target="RFC5285"/> in a way similar
to the one employed by the Rapid Synchronisation of RTP Flows
<xref target="RFC6051"/>. While such a mechanism is not
currently defined by the IETF, specifying it could be relatively
straightforward:
</t>
<t>
Every packet belonging to a repair flow could carry an RTP
header extension <xref target="RFC5285"/> that points to the
source stream (or source layer in case of layered mechanisms).
The following shows one possible way of signalling this:
</t>
<t>
<figure>
<artwork align="left" xml:space="preserve">
<![CDATA[
a=extmap:3 urn:ietf:params:rtp-hdrext:fec-source-ssrc
]]>
</artwork>
</figure>
In this case the actual RTP packet and header extension could
look like this:
<figure>
<artwork align="left" xml:space="preserve">
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| timestamp |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID-3 | L=3 | SSRC of the source RTP flow ... |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| ... SSRC | 0 (pad) | 0 (pad) | 0 (pad) |n
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| payload data |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>
Note that the above is just a stub. It's an example that's meant
to show one possible solution with some mechanisms (e.g. 1-D
Interleaved Parity <xref target="RFC6015"/>). Other mechanisms
may and probably will require different extensions or signalling
(<xref target="SRCNAME"/> will likely be an option for some). In
some cases, where layering information is provided by the codec,
an extensions is not going to be necessary at all.
</t>
<t>
In cases where FEC or simulcast relations are not immediately
needed by the recipient, the above information could also be
delayed until the reception of the first RTCP packet.
</t>
</section>
<section title="WebRTC API Requirements"
anchor="webrtc-reqs">
<t>
One of the main characteristics of this specification is the
use of SDP for transport channel setup and media stack
initialisation only. In order for applications to be able to
cover everything else it is important that WebRTC APIs actually
allow for it. Given the initial directions taken by early
implementations and specification work, this is currently almost
but not entirely possible.
</t>
<t>
The following is a list of requirements that the WebRTC APIs
would need to satisfy in order for this specification to be
usable. (Note: some of the items are already possible and are
only included for the sake of completeness.)
</t>
<t>
<list style="numbers">
<t>
Expose the SSRCs of all local MediaStreamTrack-s that the
application may want to attach to a PeerConnection.
</t>
<t>
Expose the SSRCs of all remote MediaStreamTrack-s that are
received on a PeerConnection
</t>
<t>
Expose to applications all locally generated repair flows
that exist for a source (e.g. FEC and RTX flows that will be
generated for a webcam) their types relations and SSRCs.
</t>
<t>
Expose information about the maximum number of incoming
streams that can be decoded and rendered.
</t>
<t>
Applications should be able to pause and resume (disable and
enable) any MediaStreamTrack. This should also include the
possibility to do so for specific repair flows.
</t>
<t>
Information about how certain MediaStreamTrack-s relate to
each other (e.g. a given audio flow is related to
a specific video flow) may be exchanged by applications
after media has started arriving. At that point the
corresponding MediaStreamTrack-s may have been announced
to the application within independent MediaStream-s. It
should therefore be possible for applications to join such
tracks within a single MediaStream.
</t>
</list>
</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>
None.
</t>
</section>
</middle>
<back>
<references title='Informative References'>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.3551"?>
<?rfc include="reference.RFC.4575"?>
<?rfc include="reference.RFC.5285"?>
<?rfc include="reference.RFC.5761"?>
<?rfc include="reference.RFC.5956"?>
<?rfc include="reference.RFC.6015"?>
<?rfc include="reference.RFC.6051"?>
<!--
<?rfc include="reference.I-D.roach-rtcweb-plan-a"?>
-->
<!-- Plan A -->
<reference anchor="PlanA"
target="reference.I-D.roach-rtcweb-plan-a">
<front>
<title>Using SDP with Large Numbers of Media Flows</title>
<author initials="A. B." surname="Roach"
fullname="Adam Roach">
<organization abbrev='Mozilla'>Mozilla</organization>
</author>
<author initials="M." surname="Thomson"
fullname="Martin Thomson">
<organization abbrev='Microsoft'>Microsoft</organization>
</author>
<date month="May" day="07" year="2013" />
</front>
<seriesInfo name='Internet-Draft'
value='reference.I-D.roach-rtcweb-plan-a' />
</reference>
<!-- Plan B -->
<reference anchor="PlanB"
target="reference.I-D.uberti-rtcweb-plan">
<front>
<title>Plan B: a proposal for signaling multiple media sources
in WebRTC.</title>
<author initials="J." surname="Uberti"
fullname="Justin Uberti">
<organization abbrev='Google'>Google</organization>
</author>
<date month="May" day="03" year="2013" />
</front>
<seriesInfo name='Internet-Draft'
value='reference.I-D.uberti-rtcweb-plan' />
</reference>
<!-- MSID -->
<reference anchor="MSID"
target="reference.I-D.ietf-mmusic-msid">
<front>
<title>Cross Session Stream Identification in the Session
Description Protocol</title>
<author initials="H." surname="Alvestrand"
fullname="Harald Alvestrand">
<organization abbrev='Google'>Google</organization>
</author>
<date month="February" day="10" year="2013" />
</front>
<seriesInfo name='Internet-Draft'
value='reference.I-D.ietf-mmusic-msid' />
</reference>
<!-- ROACH-GLARELESS-ADD -->
<reference anchor="ROACH-GLARELESS-ADD"
target="reference.I-D.roach-rtcweb-glareless-add">
<front>
<title>An Approach for Adding RTCWEB Media Streams without
Glare</title>
<author initials="A. B." surname="Roach"
fullname="Adam Roach">
<organization abbrev='Mozilla'>Mozilla</organization>
</author>
<date month="May" day="07" year="2013" />
</front>
<seriesInfo name='Internet-Draft'
value='reference.I-D.roach-rtcweb-glareless-add' />
</reference>
<!-- MAX-SSRC -->
<reference anchor="MAX-SSRC"
target="reference.I-D.westerlund-avtcore-max-ssrc">
<front>
<title>Multiple Synchronization sources (SSRC) in RTP Session
Signaling
</title>
<author fullname="Magnus Westerlund" initials="M."
surname="Westerlund">
<organization>Ericsson</organization>
</author>
<author fullname="Bo Burman" initials="B." surname="Burman">
<organization>Ericsson</organization>
</author>
<author fullname="Fredrik Jansson" initials="F."
surname="Jansson">
<organization>Ericsson</organization>
</author>
<date day="16" month="July" year="2012"/>
</front>
<seriesInfo name='Internet-Draft'
value='reference.I-D.westerlund-avtcore-max-ssrc' />
</reference>
<!-- CLUE -->
<reference anchor="CLUE"
target="reference.I-D.ietf-clue-framework">
<front>
<title>Framework for Telepresence Multi-Streams</title>
<author fullname="Mark Duckworth" initials="M."
surname="Duckworth">
<organization>Polycom</organization>
</author>
<author fullname="Andrew Pepperell" initials="A."
surname="Pepperell">
<organization>Acano</organization>
</author>
<author fullname="Stephan Wenger" initials="S."
surname="Wenger">
<organization>Vidyo</organization>
</author>
<date day="16" month="May" year="2013"/>
</front>
<seriesInfo name='Internet-Draft'
value='reference.I-D.ietf-clue-framework' />
</reference>
<!-- COIN -->
<reference anchor="COIN"
target="reference.I-D.ietf-coin-framework">
<front>
<title>XEP-0298: Delivering Conference Information to Jingle
Participants (Coin)</title>
<author fullname="Emil Ivov" initials="E."
surname="Ivov">
<organization>Jitsi</organization>
</author>
<author fullname="Enrico Marocco" initials="E."
surname="Marocco">
<organization>Telecom Italia Labs</organization>
</author>
<date day="09" month="June" year="2011"/>
</front>
<seriesInfo name="XSF XEP" value="0298"/>
<format type="HTML"
target="http://xmpp.org/extensions/xep-0298.html"/>
</reference>
<!-- Trickle ICE -->
<reference anchor="TRICKLE-ICE"
target="reference.I-D.ivov-mmusic-trickle-ice">
<front>
<title abbrev='Trickle ICE'>
Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol
</title>
<author initials='E.' surname='Ivov'
fullname='Emil Ivov'>
<organization abbrev='Jitsi'>Jitsi</organization>
</author>
<author fullname="Eric Rescorla" initials="E.K."
surname="Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author fullname="Justin Uberti" initials="J."
surname="Uberti">
<organization>Google</organization>
</author>
<date day="11" month="March" year="2013"/>
</front>
<seriesInfo name='Internet-Draft'
value='reference.I-D.ivov-mmusic-trickle-ice' />
</reference>
<!-- SRCNAME -->
<reference anchor="SRCNAME"
target="reference.I-D.westerlund-avtext-rtcp-sdes-srcname">
<front>
<title>RTCP SDES Item SRCNAME to Label Individual Sources
</title>
<author fullname="Magnus Westerlund" initials="M."
surname="Westerlund">
<organization>Ericsson</organization>
</author>
<author fullname="Bo Burman" initials="B." surname="Burman">
<organization>Ericsson</organization>
</author>
<author fullname="Patrik Sandgren" initials="P."
surname="Sandgren">
<organization>Ericsson</organization>
</author>
<date day="22" month="October" year="2012"/>
</front>
<seriesInfo name='Internet-Draft'
value='reference.I-D.westerlund-avtext-rtcp-sdes-srcname' />
</reference>
</references>
<section title='Acknowledgements'>
<t>
Many thanks to Enrico Marocco, Bernard Aboba and Peter Thatcher
for reviewing this document and providing numerous comments and
substantial input.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:46 |