draft-ietf-mmusic-sdp-source-attributes-00.txt   draft-ietf-mmusic-sdp-source-attributes-01.txt 
MMUSIC J. Lennox MMUSIC J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Intended status: Standards Track J. Ott Intended status: Standards Track J. Ott
Expires: May 19, 2008 Helsinki University of Technology Expires: August 28, 2008 Helsinki University of Technology
T. Schierl T. Schierl
Fraunhofer HHI Fraunhofer HHI
November 16, 2007 February 25, 2008
Source-Specific Media Attributes in the Session Description Protocol Source-Specific Media Attributes in the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-source-attributes-00 draft-ietf-mmusic-sdp-source-attributes-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Session Description Protocol provides mechanisms to describe The Session Description Protocol provides mechanisms to describe
attributes of multimedia sessions and of individual media streams attributes of multimedia sessions and of individual media streams
(e.g., Real-time Transport Protocol (RTP) sessions) within a (e.g., Real-time Transport Protocol (RTP) sessions) within a
multimedia session, but does not provide any mechanism to describe multimedia session, but does not provide any mechanism to describe
individual media sources within a media stream. This document individual media sources within a media stream. This document
defines a mechanism to describe RTP media sources, identified by defines a mechanism to describe RTP media sources, identified by
their Synchronization Source Identifiers (SSRCs), in SDP, associate their Synchronization Source Identifiers (SSRCs), in SDP, associate
attributes with these sources, and express relationships among attributes with these sources, and express relationships among
sources. It also defines several source-level attributes which can sources. It also defines several source-level attributes which can
be used to describe properties of media sources. be used to describe properties of media sources.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Media Attributes . . . . . . . . . . . . . . . . . . . . . . . 5 4. Media Attributes . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. The "ssrc" Media Attribute . . . . . . . . . . . . . . . . 5 4.1. The "ssrc" Media Attribute . . . . . . . . . . . . . . . . 5
4.2. The "ssrc-group" Media Attribute . . . . . . . . . . . . . 6 4.2. The "ssrc-group" Media Attribute . . . . . . . . . . . . . 6
5. Usage of Identified Source Identifiers in RTP . . . . . . . . 7 5. Usage of Identified Source Identifiers in RTP . . . . . . . . 7
6. Source Attributes . . . . . . . . . . . . . . . . . . . . . . 9 6. Source Attributes . . . . . . . . . . . . . . . . . . . . . . 8
6.1. The "cname" Source Attribute . . . . . . . . . . . . . . . 9 6.1. The "cname" Source Attribute . . . . . . . . . . . . . . . 9
6.2. The "previous-ssrc" Source Attribute . . . . . . . . . . . 9 6.2. The "previous-ssrc" Source Attribute . . . . . . . . . . . 9
6.3. The "fmtp" Source Attribute . . . . . . . . . . . . . . . 10 6.3. The "fmtp" Source Attribute . . . . . . . . . . . . . . . 10
6.4. Other Source Attributes . . . . . . . . . . . . . . . . . 10 6.4. Other Source Attributes . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Usage With the Offer/Answer Model . . . . . . . . . . . . . . 12 8. Usage With the Offer/Answer Model . . . . . . . . . . . . . . 11
9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 14 12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 13
12.2. Registry for Source-Level Attributes . . . . . . . . . . . 14 12.2. Registry for Source-Level Attributes . . . . . . . . . . . 14
12.3. Registry for Source Grouping Semantics . . . . . . . . . . 15 12.3. Registry for Source Grouping Semantics . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Changes From Earlier Versions . . . . . . . . . . . . 18 Appendix A. Changes From Earlier Versions . . . . . . . . . . . . 17
A.1. Changes From Individual Submission Draft -01 . . . . . . . 18 A.1. Changes From Working Group Draft -00 . . . . . . . . . . . 17
A.2. Changes From Draft -00 . . . . . . . . . . . . . . . . . . 18 A.2. Changes From Individual Submission Draft -01 . . . . . . . 17
A.3. Changes From Individual Submission Draft -00 . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] provides mechanisms The Session Description Protocol (SDP) [RFC4566] provides mechanisms
to describe attributes of multimedia sessions and of media streams to describe attributes of multimedia sessions and of media streams
(e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within (e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within
a multimedia session, but does not provide any mechanism to describe a multimedia session, but does not provide any mechanism to describe
individual media sources within a media stream. individual media sources within a media stream.
Several recently-proposed protocols, notably RTP Single-Source Several recently-proposed protocols, notably RTP Single-Source
Multicast [I-D.ietf-avt-rtcpssm] have found it useful to describe Multicast [I-D.ietf-avt-rtcpssm] have found it useful to describe
specific media sources in SDP messages. Single-source multicast, in specific media sources in SDP messages. Single-source multicast, in
particular, needs to ensure that receivers' RTP Syncronization Source particular, needs to ensure that receivers' RTP Synchronization
Identifiers (SSRCs) do not collide with those of media senders, as Source Identifiers (SSRCs) do not collide with those of media
the RTP specification [RFC3550] requires that colliding sources senders, as the RTP specification [RFC3550] requires that colliding
change their SSRC values after a collision has been detected. sources change their SSRC values after a collision has been detected.
Earlier work has used mechanisms specific to each protocol to Earlier work has used mechanisms specific to each protocol to
describe the individual sources of an RTP session. describe the individual sources of an RTP session.
Moreover, whereas the Real-Time Transport Protocol (RTP) [RFC3550] is Moreover, whereas the Real-Time Transport Protocol (RTP) [RFC3550] is
defined as allowing multiple sources in an RTP session (for example, defined as allowing multiple sources in an RTP session (for example,
if a user has more than one camera), SDP has no existing mechanism if a user has more than one camera), SDP has no existing mechanism
for an endpoint to indicate that it will be using multiple sources, for an endpoint to indicate that it will be using multiple sources,
or to describe their characteristics individually. or to describe their characteristics individually.
To address all these problems, this document defines a mechanism to To address all these problems, this document defines a mechanism to
describe RTP sources, identified by their Synchronization Sources describe RTP sources, identified by their Synchronization Sources
Identifiers (SSRCs), in SDP, associate attributes with these sources, Identifiers (SSRCs), in SDP, associate attributes with these sources,
and express relationships among individual sources. It also defines and express relationships among individual sources. It also defines
a number of new SDP attributes that apply to individual sources a number of new SDP attributes that apply to individual sources
("source-level" attributes); describes how a number of existing media ("source-level" attributes); describes how a number of existing media
stream ("media-level") attributes can also be applied at the source stream ("media-level") attributes can also be applied at the source
level; and establishes IANA registries for source-level attributes. level; and establishes IANA registries for source-level attributes
and source grouping semantics.
During the discussion in the AVT and MMUSIC working groups on the
transport [I-D.ietf-avt-rtp-svc] and signaling
[I-D.schierl-mmusic-layered-codec] of the Scalable Video Coding (SVC)
Extensions of H.264, SSRC multiplexing of layered video was
considered as an appropriate multiplexing technique, if the use case
strongly requires this. It was considered that a compelling use case
exists for identifying RTP packet streams carrying different layers
of a single SVC media stream. One use case was pointed out, which is
the adaptation of an SRTP encrypted SVC stream by a middle-box not
being in the security context. Since the authentication and
integrity mechanism of SRTP still requires the middle-box being in
the security context, the authors of [I-D.ietf-avt-rtp-svc] and
[I-D.schierl-mmusic-layered-codec] currently do not consider SSRC
multiplexing. Since the process for both memos is still going on,
however, a requirement for SSRC multiplexing for SVC may come up
again. SSRC multiplexing would anyway make an easy identification of
layers of a scalable media stream in a middle-box possible, without
the need of parsing into RTP payload headers. A potential use case
is shown in Section 7, the examples section.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Overview 3. Overview
In the Real-Time Transport Protocol (RTP) [RFC3550], an association In the Real-Time Transport Protocol (RTP) [RFC3550], an association
among a group of communicating participants is known as an RTP among a group of communicating participants is known as an RTP
Session. An RTP session is typically associated with a single Session. An RTP session is typically associated with a single
transport address (in the case of multicast) or communication flow transport address (in the case of multicast) or communication flow
(in the case of unicast), though RTP translators and single-source (in the case of unicast), though RTP translators and single-source
multicast [I-D.ietf-avt-rtcpssm] can make the situation more complex. multicast [I-D.ietf-avt-rtcpssm] can make the situation more complex.
RTP topologies are discussed in more detail in RTP topologies are discussed in more detail in [RFC5117].
[I-D.ietf-avt-topologies].
Within an RTP session, the source of a single stream of RTP packets Within an RTP session, the source of a single stream of RTP packets
is known as a synchronization source (SSRC). Every synchronization is known as a synchronization source (SSRC). Every synchronization
source is identified by a 32-bit numeric identifier. In addition, source is identified by a 32-bit numeric identifier. In addition,
receivers (who may never send RTP packets) also have source receivers (who may never send RTP packets) also have source
identifiers, which are used to identify their RTP Control Protocol identifiers, which are used to identify their RTP Control Protocol
(RTCP) receiver reports and other feedback messages. (RTCP) receiver reports and other feedback messages.
Messages of the Session Description Protocol (SDP) [RFC4566], known Messages of the Session Description Protocol (SDP) [RFC4566], known
as Session Descriptions, describe Multimedia Sessions. A multimedia as Session Descriptions, describe Multimedia Sessions. A multimedia
skipping to change at page 6, line 16 skipping to change at page 5, line 41
attribute name (a flag), or an attribute name and value, e.g. attribute name (a flag), or an attribute name and value, e.g.
"cname:user@example.com". No attributes of the former type are "cname:user@example.com". No attributes of the former type are
defined by this document. defined by this document.
Within a media stream, ssrc attributes with the same value of Within a media stream, ssrc attributes with the same value of
<ssrc-id> describe different attributes of the same media sources. <ssrc-id> describe different attributes of the same media sources.
Across media streams, <ssrc-id> values are not correlated (unless Across media streams, <ssrc-id> values are not correlated (unless
correlation is indicated by media-stream grouping or some other correlation is indicated by media-stream grouping or some other
mechanism) and MAY be repeated. mechanism) and MAY be repeated.
For each source mentioned in SDP, the source-level attribute "cname", Each "ssrc" media attribute specifies a single source-level attribute
defined in Section 6.1, MUST be provided. Any number of other for the given <ssrc-id>. For each source mentioned in SDP, the
source-level attributes for the source MAY also be provided. source-level attribute "cname", defined in Section 6.1, MUST be
provided. Any number of other source-level attributes for the source
MAY also be provided.
The "ssrc" media attribute MAY be used for any RTP-based media The "ssrc" media attribute MAY be used for any RTP-based media
transport. It is not defined for other transports. transport. It is not defined for other transports.
If any other SDP attributes also mention RTP SSRC values (for If any other SDP attributes also mention RTP SSRC values (for
example, MIKEY [RFC3830][RFC4567]), the values used MUST be example, MIKEY [RFC3830][RFC4567]), the values used MUST be
consistent. (These attributes MAY provide additional information consistent. (These attributes MAY provide additional information
about a source described by an "ssrc" attribute, or MAY describe about a source described by an "ssrc" attribute, or MAY describe
additional sources.) additional sources.)
Though the source-level attributes specified by the ssrc property Though the source-level attributes specified by the ssrc property
follow the same syntax as session-level and media-level attributes, follow the same syntax as session-level and media-level attributes,
they are defined independently. All source-level attributes MUST be they are defined independently. All source-level attributes MUST be
registered with IANA, using the registry defined in Section 12.2. registered with IANA, using the registry defined in Section 12.2.
Figure 10 in Section 10 gives a formal Augmented Backus-Naur Form Figure 9 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC4234] grammar for the ssrc attribute. (ABNF) [RFC5234] grammar for the ssrc attribute.
The "ssrc" media attribute is not dependent on charset. The "ssrc" media attribute is not dependent on charset.
4.2. The "ssrc-group" Media Attribute 4.2. The "ssrc-group" Media Attribute
a=ssrc-group:<semantics> <ssrc-id> ... a=ssrc-group:<semantics> <ssrc-id> ...
The SDP media attribute "ssrc-group" expresses a relationship among The SDP media attribute "ssrc-group" expresses a relationship among
several sources of an RTP session. It is analogous to the "group" several sources of an RTP session. It is analogous to the "group"
session-level attribute [RFC3388], which expresses a relationship session-level attribute [RFC3388], which expresses a relationship
skipping to change at page 7, line 12 skipping to change at page 6, line 40
sources are already identified by their SSRC IDs, no analogous sources are already identified by their SSRC IDs, no analogous
property to the "mid" attribute is necessary; groups of sources are property to the "mid" attribute is necessary; groups of sources are
identified by their SSRC IDs directly. identified by their SSRC IDs directly.
The <semantics> parameter is taken from the specification of the The <semantics> parameter is taken from the specification of the
"group" attribute [RFC3388]. The initial semantics values defined "group" attribute [RFC3388]. The initial semantics values defined
for the ssrc-group attribute are FID (Flow Identification) [RFC3388] for the ssrc-group attribute are FID (Flow Identification) [RFC3388]
and FEC (Forward Error Correction) [RFC4756]. In each case, the and FEC (Forward Error Correction) [RFC4756]. In each case, the
relationship among the grouped sources is the same as the relationship among the grouped sources is the same as the
relationship among corresponding sources in media streams grouped relationship among corresponding sources in media streams grouped
using the SDP "group" attribute. Additional ssrc-group semantics using the SDP "group" attribute.
values MUST be registered with IANA, as specified in Section 12.3.
Though the "ssrc-group" semantics values follow the same syntax as
"group" semantics values, they are defined independently. All "ssrc-
group" semantics values MUST be registered with IANA, using the
registry defined in Section 12.3.
(The other "group" semantics registered with IANA as of this writing (The other "group" semantics registered with IANA as of this writing
are not useful for source grouping. LS (Lip Synchronization) are not useful for source grouping. LS (Lip Synchronization)
[RFC3388] is redundant for sources within a media stream, as RTP [RFC3388] is redundant for sources within a media stream, as RTP
sources with the same CNAME are implicitly synchronized in RTP. SRF sources with the same CNAME are implicitly synchronized in RTP. SRF
(Single Reservation Flow) [RFC3524] and ANAT (Alternative Network (Single Reservation Flow) [RFC3524] and ANAT (Alternative Network
Address Types) [RFC4091] refer specifically to the media stream's Address Types) [RFC4091] refer specifically to the media stream's
transport characteristics. CS (Composite Session) transport characteristics. CS (Composite Session)
[I-D.mehta-rmt-flute-sdp] is used to group FLUTE sessions, and so is [I-D.mehta-rmt-flute-sdp] is used to group FLUTE sessions, and so is
not applicable to RTP.) not applicable to RTP.)
The ssrc-group attribute indicates the sources in a group by listing The ssrc-group attribute indicates the sources in a group by listing
the <ssrc-id>s of the sources in the group. It MUST list at least the <ssrc-id>s of the sources in the group. It MUST list at least
one <ssrc-id> for a group, and MAY list any number of additional one <ssrc-id> for a group, and MAY list any number of additional
ones. Every <ssrc-id> listed in an ssrc-group attribute MUST be ones. Every <ssrc-id> listed in an ssrc-group attribute MUST be
defined by a corresponding "ssrc:" line in the same media defined by a corresponding "ssrc:" line in the same media
description. description.
The "ssrc-group" media attribute is not dependent on charset. The "ssrc-group" media attribute is not dependent on charset.
Figure 11 in Section 10 gives a formal Augmented Backus-Naur Form Figure 10 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC4234] grammar for the ssrc-group attribute. (ABNF) [RFC5234] grammar for the ssrc-group attribute.
5. Usage of Identified Source Identifiers in RTP 5. Usage of Identified Source Identifiers in RTP
The synchronization source identifiers used in an RTP session are The synchronization source identifiers used in an RTP session are
chosen randomly and independently by endpoints. As such, it is chosen randomly and independently by endpoints. As such, it is
possible for two RTP endpoints to choose the same SSRC identifier. possible for two RTP endpoints to choose the same SSRC identifier.
Though the probability of this is low, the RTP specification Though the probability of this is low, the RTP specification
[RFC3550] requires that all RTP endpoints MUST be prepared to detect [RFC3550] requires that all RTP endpoints MUST be prepared to detect
and resolve collisions. and resolve collisions.
skipping to change at page 8, line 28 skipping to change at page 8, line 13
be present in an RTP session; additional sources, with previously be present in an RTP session; additional sources, with previously
unmentioned SSRC IDs, can be added at any time, and endpoints MUST be unmentioned SSRC IDs, can be added at any time, and endpoints MUST be
prepared to receive packets from these sources. (How endpoints prepared to receive packets from these sources. (How endpoints
handle such packets is not specified here; they SHOULD be handled in handle such packets is not specified here; they SHOULD be handled in
the same manner as packets from additional sources would be handled the same manner as packets from additional sources would be handled
had the endpoint not received any a=ssrc: attributes at all.) had the endpoint not received any a=ssrc: attributes at all.)
An endpoint that observes an SSRC collision between its explicitly- An endpoint that observes an SSRC collision between its explicitly-
signaled source and another entity that has not explicitly signaled signaled source and another entity that has not explicitly signaled
an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by
5*1.5*Td, with Td being the deterministic calculated reporting 5*1.5*Td, where Td is the deterministic calculated reporting interval
interval for receivers, to see whether the conflict still exists. for receivers defined in Section 6.3.1 of the RTP specification
(This gives precedence to explicitly-signaled sources, and places the [RFC3550], to see whether the conflict still exists. (This gives
burden of collision resolution on non-signaled sources.) SSRC precedence to explicitly-signaled sources, and places the burden of
collisions between multiple explicitly-signaled sources, however, collision resolution on non-signaled sources.) SSRC collisions
MUST be acted upon immediately. between multiple explicitly-signaled sources, however, MUST be acted
upon immediately.
If, following RTP's collision-resolution procedures [RFC3550], a If, following RTP's collision-resolution procedures [RFC3550], a
source identified by source-level attributes has been forced to source identified by source-level attributes has been forced to
change its SSRC identifier, the author of the SDP containing the change its SSRC identifier, the author of the SDP containing the
source-level attributes for these sources SHOULD send out an updated source-level attributes for these sources SHOULD send out an updated
SDP session description with the new SSRC, if the mechanism by which SDP session description with the new SSRC, if the mechanism by which
SDP is being distributed for the multimedia session has a mechanism SDP is being distributed for the multimedia session has a mechanism
to distribute updated SDP. This updated SDP MUST include a previous- to distribute updated SDP. This updated SDP MUST include a previous-
ssrc source-level attribute, described in Section 6.2, listing the ssrc source-level attribute, described in Section 6.2, listing the
source's previous SSRC ID. (If only a single source with a given source's previous SSRC ID. (If only a single source with a given
skipping to change at page 9, line 38 skipping to change at page 9, line 26
SSRC with a different CNAME, it SHOULD assume there has been an SSRC SSRC with a different CNAME, it SHOULD assume there has been an SSRC
collision, and that the description of the source that was carried in collision, and that the description of the source that was carried in
the SDP description is not applicable to the actual source being the SDP description is not applicable to the actual source being
received. This source attribute is REQUIRED to be present if any received. This source attribute is REQUIRED to be present if any
source attributes are present for a source. The cname attribute MUST source attributes are present for a source. The cname attribute MUST
NOT occur more than once for the same ssrc-id within a given media NOT occur more than once for the same ssrc-id within a given media
stream. stream.
The "cname" source attribute is not dependent on charset. The "cname" source attribute is not dependent on charset.
Figure 12 in Section 10 gives a formal Augmented Backus-Naur Form Figure 11 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC4234] grammar for the cname attribute. (ABNF) [RFC5234] grammar for the cname attribute.
6.2. The "previous-ssrc" Source Attribute 6.2. The "previous-ssrc" Source Attribute
a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ... a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ...
The "previous-ssrc" source attribute associates a media source with The "previous-ssrc" source attribute associates a media source with
previous source identifiers used for the same media source. previous source identifiers used for the same media source.
Following an SSRC change due to an SSRC collision involving a media Following an SSRC change due to an SSRC collision involving a media
source described in SDP, the updated session description describing source described in SDP, the updated session description describing
the source's new SSRC (described in Section 5) MUST include the the source's new SSRC (described in Section 5) MUST include the
previous-ssrc attribute associating the new SSRC with the old one. previous-ssrc attribute associating the new SSRC with the old one.
If further updated SDP descriptions are published describing the If further updated SDP descriptions are published describing the
media source, the previous-ssrc attribute SHOULD be included if the media source, the previous-ssrc attribute SHOULD be included if the
session description was generated before the participant timeout of session description was generated before the participant timeout of
the old SSRC, and MAY be included after that point. This attribute, the old SSRC, and MAY be included after that point. This attribute,
if present, MUST list at least one previous SSRC, and MAY list any if present, MUST list at least one previous SSRC, and MAY list any
number of additional SSRCs for the source, if the source has collided number of additional SSRCs for the source, if the source has collided
skipping to change at page 10, line 20 skipping to change at page 10, line 7
media source, the previous-ssrc attribute SHOULD be included if the media source, the previous-ssrc attribute SHOULD be included if the
session description was generated before the participant timeout of session description was generated before the participant timeout of
the old SSRC, and MAY be included after that point. This attribute, the old SSRC, and MAY be included after that point. This attribute,
if present, MUST list at least one previous SSRC, and MAY list any if present, MUST list at least one previous SSRC, and MAY list any
number of additional SSRCs for the source, if the source has collided number of additional SSRCs for the source, if the source has collided
more than once. This attribute MUST be present only once for each more than once. This attribute MUST be present only once for each
source. source.
The "previous-ssrc" source attribute is not dependent on charset. The "previous-ssrc" source attribute is not dependent on charset.
Figure 13 in Section 10 gives a formal Augmented Backus-Naur Form Figure 12 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC4234] grammar for the previous-ssrc attribute. (ABNF) [RFC5234] grammar for the previous-ssrc attribute.
6.3. The "fmtp" Source Attribute 6.3. The "fmtp" Source Attribute
a=ssrc:<ssrc> fmtp:<format> <format specific parameters> a=ssrc:<ssrc> fmtp:<format> <format specific parameters>
The "fmtp" source attribute allows format-specific parameters to be The "fmtp" source attribute allows format-specific parameters to be
conveyed about a given source. The <format> parameter MUST be one of conveyed about a given source. The <format> parameter MUST be one of
the media formats (i.e., RTP payload types) specified for the media the media formats (i.e., RTP payload types) specified for the media
stream. The meaning of the <format specific parameters> is unique stream. The meaning of the <format specific parameters> is unique
for each media type. This parameter MUST only be used for media for each media type. This parameter MUST only be used for media
skipping to change at page 11, line 27 skipping to change at page 11, line 18
a=ssrc:67890 cname:another-user@example.com a=ssrc:67890 cname:another-user@example.com
Figure 7: Example: a media stream containing several independent Figure 7: Example: a media stream containing several independent
sources from a single session member. sources from a single session member.
The example in Figure 7 shows a video stream where one participant The example in Figure 7 shows a video stream where one participant
(identified by a single CNAME) has several cameras. The sources (identified by a single CNAME) has several cameras. The sources
could be further distinguished by RTCP Source Description (SDES) could be further distinguished by RTCP Source Description (SDES)
information. information.
m=video 49172 RTP/AVP 97
a=rtpmap:97 SVC/90000
a=ssrc-group:DDP 271828 14142135
a=ssrc:271828 cname:layered-codec@example.com
a=ssrc:14142135 cname:layered-codec@example.com
a=ssrc:14142135 depend:lay 271828
Figure 8: (Hypothetical) example: relationship among several sources:
layered coding
The example in Figure 8 shows a relationship among several sources,
grouped by the "DDP" grouping semantics defined in Signaling of
Layered and Multi-Description Media
[I-D.schierl-mmusic-layered-codec]. (Note that this is only an
example; multiplexing of layered codecs among several sources in an
RTP session is currently not specified or encouraged.)
m=video 49174 RTP/AVPF 96 98 m=video 49174 RTP/AVPF 96 98
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=rtpmap:98 rtx/90000 a=rtpmap:98 rtx/90000
a=fmtp:98 apt=96;rtx-time=3000 a=fmtp:98 apt=96;rtx-time=3000
a=ssrc-group:FID 11111 22222 a=ssrc-group:FID 11111 22222
a=ssrc:11111 cname:user3@example.com a=ssrc:11111 cname:user3@example.com
a=ssrc:22222 cname:user3@example.com a=ssrc:22222 cname:user3@example.com
a=ssrc-group:FID 33333 44444 a=ssrc-group:FID 33333 44444
a=ssrc:33333 cname:user3@example.com a=ssrc:33333 cname:user3@example.com
a=ssrc:44444 cname:user3@example.com a=ssrc:44444 cname:user3@example.com
Figure 9: Example: relationship among several sources: retransmission Figure 8: Example: relationship among several sources: retransmission
sources sources
The example in Figure 9 shows how the relationships among sources The example in Figure 8 shows how the relationships among sources
used for RTP Retransmission [RFC4588] can be explicitly signaled. used for RTP Retransmission [RFC4588] can be explicitly signaled.
This prevents the complexity of associating original sources with This prevents the complexity of associating original sources with
retransmission sources when SSRC multiplexing is used for RTP retransmission sources when SSRC multiplexing is used for RTP
retransmission, as is described in Section 5.3 of [RFC4588]. retransmission, as is described in Section 5.3 of [RFC4588].
8. Usage With the Offer/Answer Model 8. Usage With the Offer/Answer Model
When used with the SDP Offer/Answer Model [RFC3264], SDP source- When used with the SDP Offer/Answer Model [RFC3264], SDP source-
specific attributes describe only the sources with which each party specific attributes describe only the sources with which each party
is willing to send (whether it is sending RTP data or RTCP report is willing to send (whether it is sending RTP data or RTCP report
skipping to change at page 13, line 18 skipping to change at page 12, line 30
will be able to decode the media streams they describe whether or not will be able to decode the media streams they describe whether or not
they support explicit source descriptions. However, some deployed they support explicit source descriptions. However, some deployed
RTP implementations may not actually support multiple media sources RTP implementations may not actually support multiple media sources
in a media stream. Media senders MAY wish to restrict themselves to in a media stream. Media senders MAY wish to restrict themselves to
a single source at a time unless they have some means of concluding a single source at a time unless they have some means of concluding
that the receivers of the media stream support source multiplexing. that the receivers of the media stream support source multiplexing.
10. Formal Grammar 10. Formal Grammar
This section gives a formal Augmented Backus-Naur Form (ABNF) This section gives a formal Augmented Backus-Naur Form (ABNF)
[RFC4234] grammar for each of the new media and source attributes [RFC5234] grammar for each of the new media and source attributes
defined in this document. Grammars for existing session or media defined in this document. Grammars for existing session or media
attributes which have been extended to be source attributes are not attributes which have been extended to be source attributes are not
included. included.
ssrc-attr = "ssrc:" ssrc-id SP attribute ssrc-attr = "ssrc:" ssrc-id SP attribute
; The base definition of "attribute" is in RFC 4566. ; The base definition of "attribute" is in RFC 4566.
; (It is the content of "a=" lines.) ; (It is the content of "a=" lines.)
ssrc-id = integer ; 0 - 2**32 - 1 ssrc-id = integer ; 0 - 2**32 - 1
attribute /= ssrc-attr attribute =/ ssrc-attr
Figure 10: Syntax of the ssrc media attribute
Figure 9: Syntax of the ssrc media attribute
ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id) ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
; The definition of "semantics" is in RFC 3388. ; The definition of "semantics" is in RFC 3388.
; (It is the type of grouping being done.) ; (It is the type of grouping being done.)
attribute /= ssrc-group-attr attribute =/ ssrc-group-attr
Figure 11: Syntax of the ssrc-group media attribute Figure 10: Syntax of the ssrc-group media attribute
cname-attr = "cname:" cname cname-attr = "cname:" cname
cname = byte-string cname = byte-string
; Following the syntax conventions for CNAME as defined in RFC 3550. ; Following the syntax conventions for CNAME as defined in RFC 3550.
; The definition of "byte-string" is in RFC 4566. ; The definition of "byte-string" is in RFC 4566.
attribute /= cname-attr attribute =/ cname-attr
Figure 11: Syntax of the cname source attribute
Figure 12: Syntax of the cname source attribute
previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id) previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)
attribute /= previous-ssrc-attr attribute =/ previous-ssrc-attr
Figure 13: Syntax of the previous-ssrc source attribute Figure 12: Syntax of the previous-ssrc source attribute
11. Security Considerations 11. Security Considerations
All the security implications of RTP [RFC3550] and of SDP [RFC4566] All the security implications of RTP [RFC3550] and of SDP [RFC4566]
apply. Explicitly describing the multiplexed sources of an RTP media apply. Explicitly describing the multiplexed sources of an RTP media
stream does not appear to add any further security issues. stream does not appear to add any further security issues.
12. IANA Considerations 12. IANA Considerations
12.1. New SDP Media-Level Attributes 12.1. New SDP Media-Level Attributes
This document defines two SDP media-level attributes: "ssrc" and This document defines two SDP media-level attributes: "ssrc" and
"ssrc-group". These attributes should be reistered by IANA under "ssrc-group". These attributes should be registered by IANA under
"Session Description Protocol (SDP) Parameters" under "att-field "Session Description Protocol (SDP) Parameters" under "att-field
(media level only)". (media level only)".
The "ssrc" attribute is used to identify characteristics of media The "ssrc" attribute is used to identify characteristics of media
sources within a media stream. Its format is defined in Section 4.1. sources within a media stream. Its format is defined in Section 4.1.
The "ssrc-group" attribute is used to identify relationships among The "ssrc-group" attribute is used to identify relationships among
media sources within a media stream. Its format is defined in media sources within a media stream. Its format is defined in
Section 4.2. Section 4.2.
skipping to change at page 15, line 26 skipping to change at page 14, line 43
of software in a manner that might inhibit interoperability. of software in a manner that might inhibit interoperability.
Source-level attributes which are substantially similar in semantics Source-level attributes which are substantially similar in semantics
to existing session-level or media-level attributes SHOULD re-use the to existing session-level or media-level attributes SHOULD re-use the
same attribute name as those session-level or media-level attributes. same attribute name as those session-level or media-level attributes.
Source-level attributes SHOULD NOT re-use attribute names of session- Source-level attributes SHOULD NOT re-use attribute names of session-
level or media-level attributes that are unrelated or substantially level or media-level attributes that are unrelated or substantially
different. different.
The initial set of source attribute names, with definitions in The initial set of source attribute names, with definitions in
Section 6 of this document, is in Figure 14. Section 6 of this document, is in Figure 13.
Type SDP Name Reference Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
att-field (source level) att-field (source level)
cname [RFCXXXX] cname [RFCXXXX]
previous-ssrc [RFCXXXX] previous-ssrc [RFCXXXX]
fmtp [RFCXXXX] fmtp [RFCXXXX]
Figure 14: Initial Contents of IANA Source Attribute Registry Figure 13: Initial Contents of IANA Source Attribute Registry
(Note to the RFC-Editor: please replace "XXXX" with the number of (Note to the RFC-Editor: please replace "XXXX" with the number of
this document prior to publication as an RFC.) this document prior to publication as an RFC.)
12.3. Registry for Source Grouping Semantics 12.3. Registry for Source Grouping Semantics
This specification creates a new IANA registry named "Semantics for This specification creates a new IANA registry named "Semantics for
the "ssrc-group" SDP Attribute" within the SDP parameters registry. the "ssrc-group" SDP Attribute" within the SDP parameters registry.
Source group semantics MUST be defined in standards-track RFCs, under Source group semantics MUST be defined in standards-track RFCs, under
the same rules as [RFC3388]: the same rules as [RFC3388]:
skipping to change at page 16, line 17 skipping to change at page 15, line 30
any length, but SHOULD be no more than four characters long. any length, but SHOULD be no more than four characters long.
o Reference to an standards track RFC. o Reference to an standards track RFC.
Source grouping semantics values which are substantially similar to Source grouping semantics values which are substantially similar to
existing media grouping semantics values SHOULD re-use the same existing media grouping semantics values SHOULD re-use the same
semantics name as that media gropuing semantics. Source grouping semantics name as that media gropuing semantics. Source grouping
semantics SHOULD NOT re-use source grouping semantics names that are semantics SHOULD NOT re-use source grouping semantics names that are
unrelated or substantially different. unrelated or substantially different.
The initial set of source grouping semantics values, for the The initial set of source grouping semantics values, for the
semantics specified in Section 4.2 of this document, is in Figure 15. semantics specified in Section 4.2 of this document, is in Figure 14.
Semantics Token Reference Semantics Token Reference
------------------- ----- --------- ------------------- ----- ---------
Flow Identification FID [RFCXXXX] Flow Identification FID [RFCXXXX]
Forward Error Correction FEC [RFCXXXX] Forward Error Correction FEC [RFCXXXX]
Figure 15: Initial Contents of IANA Source Group Semantics Registry Figure 14: Initial Contents of IANA Source Group Semantics Registry
(Note to the RFC-Editor: please replace "XXXX" with the number of (Note to the RFC-Editor: please replace "XXXX" with the number of
this document prior to publication as an RFC.) this document prior to publication as an RFC.)
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 17, line 5 skipping to change at page 16, line 18
June 2002. June 2002.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006. Session Description Protocol", RFC 4756, November 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative References 13.2. Informative References
[I-D.ietf-avt-rtcpssm] [I-D.ietf-avt-rtcpssm]
Chesterfield, J., "RTCP Extensions for Single-Source Ott, J., "RTCP Extensions for Single-Source Multicast
Multicast Sessions with Unicast Feedback", Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17
draft-ietf-avt-rtcpssm-13 (work in progress), March 2007. (work in progress), January 2008.
[I-D.ietf-avt-rtp-svc]
Wenger, S., "RTP Payload Format for SVC Video",
draft-ietf-avt-rtp-svc-02 (work in progress), July 2007.
[I-D.ietf-avt-topologies]
Westerlund, M. and S. Wenger, "RTP Topologies",
draft-ietf-avt-topologies-07 (work in progress),
October 2007.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.mehta-rmt-flute-sdp] [I-D.mehta-rmt-flute-sdp]
Mehta, H., "SDP Descriptors for FLUTE", Mehta, H., "SDP Descriptors for FLUTE",
draft-mehta-rmt-flute-sdp-05 (work in progress), draft-mehta-rmt-flute-sdp-05 (work in progress),
January 2006. January 2006.
[I-D.schierl-mmusic-layered-codec]
Wenger, S. and T. Schierl, "Signaling media decoding
dependency in Session Description Protocol (SDP)",
draft-schierl-mmusic-layered-codec-04 (work in progress),
June 2007.
[RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to [RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to
Resource Reservation Flows", RFC 3524, April 2003. Resource Reservation Flows", RFC 3524, April 2003.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005. Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
A.1. Changes From Individual Submission Draft -01 A.1. Changes From Working Group Draft -00
o Removed discussion of ssrc-multiplexing for layered codecs.
o Clarified that each "ssrc" attribute specifies only a single
source-level attribute.
o Clarified that "ssrc-group" semantics are defined separately from
"group" semantics.
o Clarified reference for the Td parameter.
o Updated references.
o Corrected typographical errors.
A.2. Changes From Individual Submission Draft -01
o Added definitions of the new IANA registries and registrations o Added definitions of the new IANA registries and registrations
needed. needed.
o Clarified that none of the attributes defined in the document are o Clarified that none of the attributes defined in the document are
dependent on the charset attribute. dependent on the charset attribute.
o Clarified that ssrc attributes must be consistent with other SDP o Clarified that ssrc attributes must be consistent with other SDP
mechanisms (such as MIKEY) that also specify SSRCs. mechanisms (such as MIKEY) that also specify SSRCs.
o Removed open issues section. o Removed open issues section.
A.2. Changes From Draft -00 A.3. Changes From Individual Submission Draft -00
o Clarified that this document is expressly defining declarative o Clarified that this document is expressly defining declarative
source descriptions, not source offer/answer or other information. source descriptions, not source offer/answer or other information.
o Removed the definitions of the "information", "bandwidth", o Removed the definitions of the "information", "bandwidth",
"sendrecv", "sendonly", "recvonly", "inactive", "charset", "sendrecv", "sendonly", "recvonly", "inactive", "charset",
"sdplang", "lang", "framerate", and "quality" source attributes. "sdplang", "lang", "framerate", and "quality" source attributes.
They are all unnecessary for source decodability, and to the They are all unnecessary for source decodability, and to the
extent they are otherwise useful they are probably better handled extent they are otherwise useful they are probably better handled
by RTCP Source Description (SDES) packets or feedback (AVPF) by RTCP Source Description (SDES) packets or feedback (AVPF)
messages. messages.
o Added text to the Backward Compatibility and Security o Added text to the Backward Compatibility and Security
Considerations sections. Considerations sections.
skipping to change at page 20, line 7 skipping to change at page 19, line 7
Fraunhofer HHI Fraunhofer HHI
Einsteinufer 37 Einsteinufer 37
D-10587 Berlin D-10587 Berlin
Germany Germany
Phone: +49-30-31002-227 Phone: +49-30-31002-227
Email: schierl@hhi.fhg.de Email: schierl@hhi.fhg.de
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 48 change blocks. 
125 lines changed or deleted 95 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/