MMUSIC J. Lennox
Internet-Draft Vidyo
Intended status: Standards Track July 6, 2009
Expires: January 7, 2010
Mechanisms for Media Source Selection in the Session Description
Protocol (SDP)
draft-lennox-mmusic-sdp-source-selection-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lennox Expires January 7, 2010 [Page 1]
Internet-Draft Media Source Selection in SDP July 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Source-Specific Media Attributes in the Session Description Protocol
(SDP) provide a declarative mechanism by which endpoints can describe
Real-Time Transport Protocol (RTP) sources within a media stream.
This document extends that mechanism by defining mechanisms by which
participants in a multimedia session can request specific sources
from a remote party.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivating Architecture . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. The "remote-ssrc" Media Attribute . . . . . . . . . . . . . . 5
6. Remote Source Attributes . . . . . . . . . . . . . . . . . . . 6
6.1. The "recv" and "inactive" Remote Source-Level
Attributes . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. The "framerate" Remote Source Attribute . . . . . . . . . 7
6.3. The "imageattr" Remote Source Attribute . . . . . . . . . 7
6.4. The "priority" Remote Source Attribute . . . . . . . . . . 8
7. Source Attributes . . . . . . . . . . . . . . . . . . . . . . 8
7.1. The "information" Source Attribute . . . . . . . . . . . . 8
7.2. The "send" and "inactive" Source-Level Attributes . . . . 9
8. Usage With the Offer/Answer Model . . . . . . . . . . . . . . 10
9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 12
12.2. New SDP Source-Level Attributes . . . . . . . . . . . . . 12
12.3. Registry for Remote Source-Level Attributes . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Lennox Expires January 7, 2010 [Page 2]
Internet-Draft Media Source Selection in SDP July 2009
1. Introduction
The source-attribute specification [RFC5576] provides declarative
definitions for Real-Time Protocol (RTP) [RFC3550] media sources in
the Session Description Protocol (SDP) [RFC4566].
In some architectures, it is useful to provide the capability for
endpoints to request specific sources of a remote SDP party, to
selectively enable and disable them.
To accomplish this, this document defines a new media attribute,
"remote-ssrc", which allows a receiver to indicate that it wishes to
receive a remote source, and also allows it to specify attributes of
the remote source. This document defines several such remote source
attributes: "recv", "inactive", "imageattr", "framerate", and
"preference".
Additionally, several new (local) source attributes are defined:
"information", providing human-readable information about a local
source, and "send", and "inactive", which are complementary to the
"recv" and "inactive" remote source attributtes.
2. Terminology
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 RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations.
3. Motivating Architecture
The primary use envisioned for this mechanisms is for multimedia
conferences controlled by a central system. This is similar to the
topolgies described by RTP Topologies [RFC5117] as Topo-Mixer, Topo-
Video-switch-MCU, or Topo-RTCP-terminating-MCU (depending on the
treatment of RTCP), with one crucial difference: rather than only
forwarding either a single media source, or a locally-mixed media
source, to receivers, the central mixer can instead simultaneously
forward multiple media sources independently to each receiver, as
constrained by available bandwidth.
In this architecture, the conference server can notify each
participant as sources become available in the conference.
Participants can then either explicitly request sources from the
server, or allow the server to choose which sources to forward based
on its own criteria and policy. A hybrid mode is also possible, in
Lennox Expires January 7, 2010 [Page 3]
Internet-Draft Media Source Selection in SDP July 2009
which participants explicitly request some sources while allowing the
server to choose others.
Receivers can specify parameters for how they will view certain
sources or server-selected sources, e.g. the image size or frame rate
in which they will display video sources. They can also specify
priority among sources in case the server has insufficient bandwidth
to route them all.
When the first receiver starts viewing a source, the server tells the
sender to start sending it; prior to this, the sender does not send
it. Similarly, when the last receiver stops viewing a source, the
server tells the sender to stop sending it.
At scale, sending each conference source over a separate RTP session,
each with its own m= line, would not be practical, due to issues such
as server port consumption, NAT binding exhaustion, and ICE setup
time. Thus, sources (of the same media type) are instead sent over a
single RTP session, distinguished by their SSRC. This document
defines the source negotiation mechanisms needed in SDP to enable the
mechanisms defined in this architecture.
4. Overview
This mechanism builds upon the declarative source definitions defined
in [RFC5576]. That document defines how to describe individual RTP
sources (within an RTP session) in SDP. Each source is identified by
its Synchronization Source (SSRC) identifier, and is associated with
its CNAME (canonical-name) SDP attribute.
To enable the architecture defined in Section 3, this document
defines a complementary SDP media attribute which allows the receiver
of some RTP sources to let the the sources' sender know which sources
the receiver would like to receive. This attribute, "remote-ssrc",
is defined in Section 5.
A simple example SDP exchange using this mechanism is shown in
Figure 1 and Figure 2. For brevity, only the relevant portions of
the media sections of the SDP descriptions are given.
m=video 49168 RTP/AVP 96
a=rtpmap:96 H264/90000
a=ssrc:12345 cname:user1@host1.example.com
a=ssrc:67890 cname:user2@host2.example.com
Figure 1: Notification of media sources
Lennox Expires January 7, 2010 [Page 4]
Internet-Draft Media Source Selection in SDP July 2009
In Figure 1 an SDP description indicates, using the mechanisms of
[RFC5576], two sources that are available in an RTP session.
m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000
a=remote-ssrc:12345 recv
a=remote-ssrc:12345 framerate:15
Figure 2: Request for a media source.
In Figure 2 an SDP description sent in response requests that a
specific source be sent, along with properties with which the
receiver of the source would like to receive it.
5. The "remote-ssrc" Media Attribute
This section defines a new SDP media-level attribute, "remote-ssrc",
which provides the mechanism by which a remote source can be
requested.
a=remote-ssrc:<ssrc-id> <attribute>
a=remote-ssrc:<ssrc-id> <attribute>:<value>
The SDP media attribute "remote-ssrc" indicates a property (known as
a "remote source-level attribute") of a remote media source (RTP
stream) within an RTP session. <ssrc-id> is the synchronization
source ID (SSRC) of the remote source being described, interpreted as
a 32-bit unsigned integer in network byte order and represented in
decimal. <attribute> or <attribute>:<value> represent the source-
level receive attribute specific to the given remote media source.
The source-level receive attribute follows the syntax of the SDP "a="
line. It thus consists either of a single attribute name (a flag),
such as "recv" or "inactive", or an attribute name and value, e.g.
"framerate:30".
These remote source IDs correspond to sources in the RTP session that
may be sent by other session members. The author of the SDP may have
been learned about these sources by observing them in the RTP session
(either by receiving RTP packets or seeing RTCP reports from them),
from earlier SDP messages containing "ssrc" attributes describing the
sources, or from other means such as the SIP conference event package
[RFC4575] or the XCON conference event package
[I-D.ietf-xcon-event-package].
The "remote-ssrc" media attribute MAY be used for any RTP-based media
Lennox Expires January 7, 2010 [Page 5]
Internet-Draft Media Source Selection in SDP July 2009
transport. It is not defined for other transports.
Though the remote source attributes specified by the "remote-ssrc"
property follow the same syntax as (local) source attributes, they
are defined independently. All remote source attributes MUST be
registered with IANA, using the registry defined in Section 12.3.
Figure 3 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the ssrc attribute.
The "remote-ssrc" media attribute is not (itself) dependent on
charset, though specific remote source attributes MAY be.
6. Remote Source Attributes
This section defines several specific remote source-level attributes
that can be applied to RTP sources.
6.1. The "recv" and "inactive" Remote Source-Level Attributes
a=remote-ssrc:<ssrc> recv
a=remote-ssrc:<ssrc> inactive
The "recv" remote source attribute indicates a source that the author
of an SDP message is interested in receiving. Similarly, the
"inactive" remote source attribute indicates a source that the author
of an SDP message is not interested in receiving. There MUST be at
most one of the "recv" and "inactive" remote source-level attributes
per remote media source.
If the media stream containing the source has the media attributes
"sendonly" or "inactive", the stream MUST NOT list any remote sources
with the "recv" attribute.
If "remote-ssrc" attributes are given for a particular remote source,
but neither "recv" nor "inactive" is specified for it, "recv" is the
default if the media stream is "sendrecv" or "recvonly".
If no remote-ssrc attributes at all are listed for a particular
remote source, the choice of whether to send it is left at the
sender's discretion. However, for sources associated in with an
"ssrc-group" [RFC5576], any unlisted sources of a group SHOULD be
treated the same as any listed ones if the requests are consistent.
Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form
Lennox Expires January 7, 2010 [Page 6]
Internet-Draft Media Source Selection in SDP July 2009
(ABNF) [RFC5234] grammar for the "recv" and "inactive" attributes.
Section 8 describes how the "recv" and "inactive" remote source
attributes are used with SDP offer/answer [RFC3264].
The "recv" and "inactive" remote source attributes are not dependent
on charset.
6.2. The "framerate" Remote Source Attribute
a=remote-ssrc:<ssrc> framerate:<frame rate>
The "framerate" remote source-level attribute gives the maximum frame
rate which the receiver of a video source would like receive for the
video. Higher framerates are likely not to be useful. It is
analogous to the SDP "framerate" media attribute [RFC4566]. Decimal
representations of fractional values using the notation
"<integer>.<fraction>" are allowed.
The "framerate" attribute is defined only for video media. There
MUST be at most one "framerate" remote source attribute per remote
media source.
Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the "framerate" attribute.
The "framerate" remote source attribute is not dependent on charset.
6.3. The "imageattr" Remote Source Attribute
a=remote-ssrc:<ssrc> imageattr:<PT> <attr_list>
The "imageattr" remote source-level attribute describes the image
resolution, and other image characteristics, with which a video
source would like receive the video. Larger resolutions are likely
not to be useful. It is analogous to the "recv" portion of the SDP
"imageattr" media attribute [I-D.ietf-mmusic-image-attributes].
Different image attributes MAY be defined per payload type defined in
the media stream. The <PT> parameter MAY either be one of the media
formats (RTP payload types) specified for the media stream, or the
character "*" indicating that the "imageattr" attribute applies to
all payload types of the session.
Lennox Expires January 7, 2010 [Page 7]
Internet-Draft Media Source Selection in SDP July 2009
The <attr_list> parameter gives a list of resolutions and image
aspect ratios with which the receiver wishes to display the source.
It is described in detail in [I-D.ietf-mmusic-image-attributes].
The "imageattr" attribute is defined only for video media. There
MUST be at most one "imageattr" remote source attribute per payload
type per remote media source. If an "imageattr" attribute is present
with a PT value of "*", it MUST be the only "imageattr" attribute
defined for that remote media source.
Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the "imageattr" attribute.
The "imageattr" remote source attribute is not dependent on charset.
6.4. The "priority" Remote Source Attribute
a=remote-ssrc:<ssrc> priority:<priority>
The "priority" remote source-level attribute gives the relative
priority among the remote sources requested by a receiver. The
<priority> parameter is a decimal integer indicating which streams
should be given higher preference if the sender determines that there
is insufficient bandwidth (or other resource) available to transmit
all the requested streams. Larger numbers indicate a greater
priority. Priority values MUST be less than 2**31 - 1, but otherwise
their specific values have no semantic significance.
Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the "priority" attribute.
The "priority" remote source attribute is not dependent on charset.
7. Source Attributes
This section describes specific (sending) source attributes that can
be applied to RTP sources.
7.1. The "information" Source Attribute
a=ssrc:<ssrc> information:<source description>
The "information" source attribute provides textual information about
Lennox Expires January 7, 2010 [Page 8]
Internet-Draft Media Source Selection in SDP July 2009
a source. It is analogous to the SDP "i=" field for session and
media information. There MUST be at most one "information" source
attribute per media source. If the "charset" attribute is present at
the session or media level, it specifies the character set used in
the source description. If the "charset" attribute is not present,
the "information" attribute MUST contain ISO 10646 characters in
UTF-8 encoding.
The "information" attribute is intended to provide a free-form human-
readable description of a media source. It is not suitable for
parsing by automata.
Figure 8 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the "information" attribute.
7.2. The "send" and "inactive" Source-Level Attributes
a=ssrc:<ssrc> send
a=ssrc:<ssrc> inactive
The "send" source attribute indicates a source that the author of an
SDP message is currently actively sending, due to it having been
requested by the other party with a "recv" remote source attribute in
an SDP offer/answer exchange. Similarly, the "inactive" source
attribute indicates a source that has been rejected with the
"inactive" remote source attribute. There MUST be at most one of the
"send" and "inactive" source-level attributes per media source.
Sources which were not listed with "recv-ssrc" in the previous offer
or answer SHOULD NOT have either "send" or "inactive" listed.
The "send" and "inactive" attributes are not defined for declarative
SDP.
If the media stream containing the source has the media attributes
"recvonly" or "inactive", the stream MUST NOT list any sources with
the "send" attribute.
Figure 9 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the "send" and "inactive" attributes.
Further description of how the "send" and "inactive" source
attributes are used with SDP offer/answer [RFC3264] is given in
Section 8.
The "send" and "inactive" source attributes are not dependent on
charset.
Lennox Expires January 7, 2010 [Page 9]
Internet-Draft Media Source Selection in SDP July 2009
8. Usage With the Offer/Answer Model
When used with the SDP Offer/Answer Model [RFC3264], the "remote-
ssrc" attribute MAY be included either in an SDP offer or answer.
Both offers and answers MAY contain both "ssrc" and "remote-ssrc"
media attributes.
If "remote-ssrc" attributes are present in an SDP offer, the answerer
(if it accepts the offer) SHOULD include all the remotely-requested
active sources in "ssrc" attributes in its answer. If "remote-ssrc"
attributes are present in an answer, no immediate update to SDP is
necessary; however, if the endpoint subsequently sends a new SDP
offer, it SHOULD include all the remotely-requested sources from the
previous offer/answer exchange, unless those sources have
subsequently been removed. In both cases, remote sources with the
"recv" remote source attribute included (implicitly or explicitly)
SHOULD be listed in the next response with the "send" local source
attribute, while remote sources with the "inactive" remote source
attribute SHOULD have the "inactive" local source attribute.
However, if the send/recv mode of the media stream has changed to
"recvonly" or "inactive", sources MUST NOT be listed with the "send"
attribute, and thus all remotely-requested sources SHOULD be listed
as "inactive" instead.
In general, all participants in an offer/answer exchange SHOULD list
all currently available sources, unless information about available
sources is being provided through some other mechanism, such as the
SIP conference event package [RFC4575] or the XCON conference event
package [I-D.ietf-xcon-event-package]. (Because these event packages
support partial updates, whereas SDP does not, source notification
through event packages can be more efficient, where applicable, than
SDP can be.) In the latter case, "inactive" sources, and sources
that have never been explicitly requested, MAY be omitted.
9. Backward Compatibility
TODO: It is not clear if the absence of any "recv-ssrc" attributes,
which following this draft would semantically indicate "I don't want
to request any specific sources right now" needs to be distinguished
from the backward-compatibility case "I don't know anything about the
'recv-ssrc' attribute". Similarly, it's not clear whether "I don't
have any sources to list" needs to be distingushed from "I don't know
about the 'ssrc' attribute."
Lennox Expires January 7, 2010 [Page 10]
Internet-Draft Media Source Selection in SDP July 2009
10. Formal Grammar
This section gives a formal Augmented Backus-Naur Form (ABNF)
[RFC5234] grammar for each of the new media and source attributes
defined in this document. Grammars for existing session or media
attributes which have been extended to be source attributes are not
included.
remote-ssrc-attr = "remote-ssrc:" ssrc-id SP attribute
; The base definition of "attribute" is in RFC 4566.
; (It is the content of "a=" lines.)
ssrc-id = integer ; 0 .. 2**32 - 1
attribute =/ remote-ssrc-attr
Figure 3: Syntax of the "remote-ssrc" media attribute
recv-attr = "recv" / "inactive"
attribute =/ recv-attr
Figure 4: Syntax of the "recv" and "inactive" receive source
attributes
framerate-attr = "framerate:" 1*DIGIT [ "." 1*DIGIT ]
attribute =/ framerate-attr
Figure 5: Syntax of the "framerate" receive source attribute
imageattr-attr = "imageattr:" PT 1*WSP attr_list
; The definition of PT and attr_list are in
; [I-D.ietf-mmusic-image-attributes]
attribute =/ imageattr-attr
Figure 6: Syntax of the "imageattr" receive source attribute
priority-attr = "priority:" 1*DIGIT
attribute =/ priority-attr
Figure 7: Syntax of the "priority" receive source attribute
Lennox Expires January 7, 2010 [Page 11]
Internet-Draft Media Source Selection in SDP July 2009
information-attr = "information:" text
; The definition of text is in [RFC4566]
attribute =/ information-attr
Figure 8: Syntax of the "imformation" source attribute
send-attr = "send" / "inactive"
attribute =/ send-attr
Figure 9: Syntax of the "send" and "inactive" source attributes
11. Security Considerations
All the security implications of RTP [RFC3550] and of SDP [RFC4566]
apply. Explicitly requesting sources of an RTP media stream does not
appear to add further security issues.
12. IANA Considerations
12.1. New SDP Media-Level Attributes
This document defines a new SDP media-level attribute, "remote-ssrc".
This attribute should be registered by IANA under "Session
Description Protocol (SDP) Parameters" under "att-field (media level
only)".
The "remote-ssrc" attribute is used to identify characteristics of
remote media sources within a media stream. Its format is defined in
Section 5.
12.2. New SDP Source-Level Attributes
This document defines three new SDP source-level attributes,
"information", "send", and "inactive". These attributes should be
registered by IANA under "Session Description Protocol (SDP)
Parameters" under "att-field (source level)". Their format is
defined in Section 7.
12.3. Registry for Remote Source-Level Attributes
This specification creates a new IANA registry named "att-field
(remote source level)" within the SDP parameters registry. Remote
source attributes MUST be registered with IANA and documented, under
Lennox Expires January 7, 2010 [Page 12]
Internet-Draft Media Source Selection in SDP July 2009
the same rules as for SDP source-level attributes as specified in
[RFC5576]:
New attribute registrations are accepted according to the
"Specification Required" policy of [RFC5226], provided that the
specification includes the following information:
o contact name, email address, and telephone number
o attribute name (as it will appear in SDP)
o long-form attribute name in English
o whether the attribute value is subject to the charset attribute
o a one-paragraph explanation of the purpose of the attribute
o a specification of appropriate attribute values for this attribute
The above is the minimum that IANA will accept. Attributes that are
expected to see widespread use and interoperability SHOULD be
documented with a standards-track RFC that specifies the attribute
more precisely.
Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit
assumptions about operating systems and does not name specific pieces
of software in a manner that might inhibit interoperability.
Remote source-level attributes which are substantially similar in
semantics to existing source-level, session-level or media-level
attributes SHOULD re-use the same attribute name as those attributes.
Remote source-level attributes SHOULD NOT re-use attribute names of
other level attributes that are unrelated or substantially different.
The initial set of remote source attribute names, with definitions in
Section 6 of this document, is in Figure 10.
Type SDP Name Reference
---- ------------------ ---------
att-field (remote source level)
recv [RFCXXXX]
inactive [RFCXXXX]
framerate [RFCXXXX]
imageattr [RFCXXXX]
priority [RFCXXXX]
Figure 10: Initial Contents of IANA Remote Source Attribute Registry
(Note to the RFC-Editor: please replace "XXXX" with the number of
this document prior to publication as an RFC.)
Lennox Expires January 7, 2010 [Page 13]
Internet-Draft Media Source Selection in SDP July 2009
13. References
13.1. Normative References
[I-D.ietf-mmusic-image-attributes]
Johansson, I. and K. Jung, "Negotiation of Generic Image
Attributes in SDP", draft-ietf-mmusic-image-attributes-02
(work in progress), April 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
13.2. Informative References
[I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress),
September 2008.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
Lennox Expires January 7, 2010 [Page 14]
Internet-Draft Media Source Selection in SDP July 2009
January 2008.
Appendix A. Open issues
o The "recv-ssrc" attribute does not currently list a CNAME. This
could be problematic if a SSRC collision occurs. However, several
mechanisms for discovering sources (the conference event packages,
or in-media-path if RTCP is delayed) might mean that you don't
know the CNAME for a requested source, so you can't simply require
that it be listed. Does the SSRC collision case need to be
addressed, and if so, how?
o The backward compatibility issues need to be considered.
Author's Address
Jonathan Lennox
Vidyo, Inc.
433 Hackensack Avenue
Sixth Floor
Hackensack, NJ 07601
US
Email: jonathan@vidyo.com
Lennox Expires January 7, 2010 [Page 15]