If multiple addresses are specified in the "c=" field and multiple
ports are specified in the "m=" field, a one-to-one mapping from
port to the corresponding address is implied. For example:
c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31
would imply that address 224.2.1.1 is used with ports 49170 and
49171, and address 224.2.1.2 is used with ports 49172 and 49173.
The semantics of multiple "m=" lines using the same transport
address are undefined. This implies that, unlike limited past
practice, there is no implicit grouping defined by such means and
an explicit grouping framework (for example, [18]) should instead
be used to express the intended semantics.
<proto> is the transport protocol. The meaning of the transport
protocol is dependent on the address type field in the relevant
"c=" field. Thus a "c=" field of IP4 indicates that the transport
protocol runs over IP4. The following transport protocols are
defined, but may be extended through registration of new protocols
with IANA (see Section 8):
* udp: denotes an unspecified protocol running over UDP.
* RTP/AVP: denotes RTP [19] used under the RTP Profile for Audio
and Video Conferences with Minimal Control [20] running over
UDP.
* RTP/SAVP: denotes the Secure Real-time Transport Protocol [23]
running over UDP.
The main reason to specify the transport protocol in addition to
the media format is that the same standard media formats may be
carried over different transport protocols even when the network
protocol is the same -- a historical example is vat Pulse Code
Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP
PCM audio. In addition, relays and monitoring tools that are
transport-protocol-specific but format-independent are possible.
<fmt> is a media format description. The fourth and any subsequent
sub-fields describe the format of the media. The interpretation
of the media format depends on the value of the <proto> sub-field.
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
sub-fields contain RTP payload type numbers. When a list of
payload type numbers is given, this implies that all of these
payload formats MAY be used in the session, but the first of these
formats SHOULD be used as the default format for the session. For
dynamic payload type assignments the "a=rtpmap:" attribute (see
Section 6) SHOULD be used to map from an RTP payload type number
to a media encoding name that identifies the payload format. The
"a=fmtp:" attribute MAY be used to specify format parameters (see
Section 6).
If the <proto> sub-field is "udp" the <fmt> sub-fields MUST
reference a media type describing the format under the "audio",
"video", "text", "application", or "message" top-level media
types. The media type registration SHOULD define the packet
format for use with UDP transport.
For media using other transport protocols, the <fmt> field is
protocol specific. Rules for interpretation of the <fmt> sub-
field MUST be defined when registering new protocols (see Section
8.2.2).
6. SDP Attributes
The following attributes are defined. Since application writers may
add new attributes as they are required, this list is not exhaustive.
Registration procedures for new attributes are defined in Section
8.2.4.
a=cat:<category>
This attribute gives the dot-separated hierarchical category of
the session. This is to enable a receiver to filter unwanted
sessions by category. There is no central registry of
categories. It is a session-level attribute, and it is not
dependent on charset.
a=keywds:<keywords>
Like the cat attribute, this is to assist identifying wanted
sessions at the receiver. This allows a receiver to select
interesting session based on keywords describing the purpose of
the session; there is no central registry of keywords. It is a
session-level attribute. It is a charset-dependent attribute,
meaning that its value should be interpreted in the charset
specified for the session description if one is specified, or
by default in ISO 10646/UTF-8.
a=tool:<name and version of tool>
This gives the name and version number of the tool used to
create the session description. It is a session-level
attribute, and it is not dependent on charset.
a=ptime:<packet time>
This gives the length of time in milliseconds represented by
the media in a packet. This is probably only meaningful for
audio data, but may be used with other media types if it makes
sense. It should not be necessary to know ptime to decode RTP
or vat audio, and it is intended as a recommendation for the
encoding/packetisation of audio. It is a media-level
attribute, and it is not dependent on charset.
a=maxptime:<maximum packet time>
This gives the maximum amount of media that can be encapsulated
in each packet, expressed as time in milliseconds. The time
SHALL be calculated as the sum of the time the media present in
the packet represents. For frame-based codecs, the time SHOULD
be an integer multiple of the frame size. This attribute is
probably only meaningful for audio data, but may be used with
other media types if it makes sense. It is a media-level
attribute, and it is not dependent on charset. Note that this
attribute was introduced after RFC 2327, and non-updated
implementations will ignore this attribute.
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
This attribute maps from an RTP payload type number (as used in
an "m=" line) to an encoding name denoting the payload format
to be used. It also provides information on the clock rate and
encoding parameters. It is a media-level attribute that is not
dependent on charset.
Although an RTP profile may make static assignments of payload
type numbers to payload formats, it is more common for that
assignment to be done dynamically using "a=rtpmap:" attributes.
As an example of a static payload type, consider u-law PCM
coded single-channel audio sampled at 8 kHz. This is
completely defined in the RTP Audio/Video profile as payload
type 0, so there is no need for an "a=rtpmap:" attribute, and
the media for such a stream sent to UDP port 49232 can be
specified as:
m=audio 49232 RTP/AVP 0
An example of a dynamic payload type is 16-bit linear encoded
stereo audio sampled at 16 kHz. If we wish to use the dynamic
RTP/AVP payload type 98 for this stream, additional information
is required to decode it:
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
Up to one rtpmap attribute can be defined for each media format
specified. Thus, we might have the following:
m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
RTP profiles that specify the use of dynamic payload types MUST
define the set of valid encoding names and/or a means to
register encoding names if that profile is to be used with SDP.
The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for
encoding names, under the top-level media type denoted in the
"m=" line. In the example above, the media types are
"audio/l8" and "audio/l16".
For audio streams, <encoding parameters> indicates the number
of audio channels. This parameter is OPTIONAL and may be
omitted if the number of channels is one, provided that no
additional parameters are needed.
For video streams, no encoding parameters are currently
specified.
Additional encoding parameters MAY be defined in the future,
but codec-specific parameters SHOULD NOT be added. Parameters
added to an "a=rtpmap:" attribute SHOULD only be those required
for a session directory to make the choice of appropriate media
to participate in a session. Codec-specific parameters should
be added in other attributes (for example, "a=fmtp:").
Note: RTP audio formats typically do not include information
about the number of samples per packet. If a non-default (as
defined in the RTP Audio/Video Profile) packetisation is
required, the "ptime" attribute is used as given above.
a=recvonly
This specifies that the tools should be started in receive-only
mode where applicable. It can be either a session- or media-
level attribute, and it is not dependent on charset. Note that
recvonly applies to the media only, not to any associated
control protocol (e.g., an RTP-based system in recvonly mode
SHOULD still send RTCP packets).
a=sendrecv
This specifies that the tools should be started in send and
receive mode. This is necessary for interactive conferences
with tools that default to receive-only mode. It can be either
a session or media-level attribute, and it is not dependent on
charset.
If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
default for sessions that are not of the conference type
"broadcast" or "H332" (see below).
a=sendonly
This specifies that the tools should be started in send-only
mode. An example may be where a different unicast address is
to be used for a traffic destination than for a traffic source.
In such a case, two media descriptions may be used, one
sendonly and one recvonly. It can be either a session- or
media-level attribute, but would normally only be used as a
media attribute. It is not dependent on charset. Note that
sendonly applies only to the media, and any associated control
protocol (e.g., RTCP) SHOULD still be received and processed as
normal.
a=inactive
This specifies that the tools should be started in inactive
mode. This is necessary for interactive conferences where
users can put other users on hold. No media is sent over an
inactive media stream. Note that an RTP-based system SHOULD
still send RTCP, even if started inactive. It can be either a
session or media-level attribute, and it is not dependent on
charset.
a=orient:<orientation>
Normally this is only used for a whiteboard or presentation
tool. It specifies the orientation of a the workspace on the
screen. It is a media-level attribute. Permitted values are
"portrait", "landscape", and "seascape" (upside-down
landscape). It is not dependent on charset.
a=type:<conference type>
This specifies the type of the conference. Suggested values
are "broadcast", "meeting", "moderated", "test", and "H332".
"recvonly" should be the default for "type:broadcast" sessions,
"type:meeting" should imply "sendrecv", and "type:moderated"
should indicate the use of a floor control tool and that the
media tools are started so as to mute new sites joining the
conference.
Specifying the attribute "type:H332" indicates that this
loosely coupled session is part of an H.332 session as defined
in the ITU H.332 specification [26]. Media tools should be
started "recvonly".
Specifying the attribute "type:test" is suggested as a hint
that, unless explicitly requested otherwise, receivers can
safely avoid displaying this session description to users.
The type attribute is a session-level attribute, and it is not
dependent on charset.
a=charset:<character set>
This specifies the character set to be used to display the
session name and information data. By default, the ISO-10646
character set in UTF-8 encoding is used. If a more compact
representation is required, other character sets may be used.
For example, the ISO 8859-1 is specified with the following SDP
attribute:
a=charset:ISO-8859-1
This is a session-level attribute and is not dependent on
charset. The charset specified MUST be one of those registered
with IANA, such as ISO-8859-1. The character set identifier is
a US-ASCII string and MUST be compared against the IANA
identifiers using a case-insensitive comparison. If the
identifier is not recognised or not supported, all strings that
are affected by it SHOULD be regarded as octet strings.
Note that a character set specified MUST still prohibit the use
of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets
requiring the use of these characters MUST define a quoting
mechanism that prevents these bytes from appearing within text
fields.
a=sdplang:<language tag>
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
language for the session description. As a media-level
attribute, it specifies the language for any media-level SDP
information field associated with that media. Multiple sdplang
attributes can be provided either at session or media level if
multiple languages in the session description or media use
multiple languages, in which case the order of the attributes
indicates the order of importance of the various languages in
the session or media from most important to least important.
In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple descriptions
SHOULD be sent describing the session, one in each language.
However, this is not possible with all transport mechanisms,
and so multiple sdplang attributes are allowed although NOT
RECOMMENDED.
The "sdplang" attribute value must be a single RFC 3066
language tag in US-ASCII [9]. It is not dependent on the
charset attribute. An "sdplang" attribute SHOULD be specified
when a session is of sufficient scope to cross geographic
boundaries where the language of recipients cannot be assumed,
or where the session is in a different language from the
locally assumed norm.
a=lang:<language tag>
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
default language for the session being described. As a media-
level attribute, it specifies the language for that media,
overriding any session-level language specified. Multiple lang
attributes can be provided either at session or media level if
the session description or media use multiple languages, in
which case the order of the attributes indicates the order of
importance of the various languages in the session or media
from most important to least important.
The "lang" attribute value must be a single RFC 3066 language
tag in US-ASCII [9]. It is not dependent on the charset
attribute. A "lang" attribute SHOULD be specified when a
session is of sufficient scope to cross geographic boundaries
where the language of recipients cannot be assumed, or where
the session is in a different language from the locally assumed
norm.
a=framerate:<frame rate>
This gives the maximum video frame rate in frames/sec. It is
intended as a recommendation for the encoding of video data.
Decimal representations of fractional values using the notation
"<integer>.<fraction>" are allowed. It is a media-level
attribute, defined only for video media, and it is not
dependent on charset.
a=quality:<quality>
This gives a suggestion for the quality of the encoding as an
integer value. The intention of the quality attribute for
video is to specify a non-default trade-off between frame-rate
and still-image quality. For video, the value is in the range
0 to 10, with the following suggested meaning:
10 - the best still-image quality the compression scheme can
give.
5 - the default behaviour given no quality suggestion.
0 - the worst still-image quality the codec designer thinks
is still usable.
It is a media-level attribute, and it is not dependent on
charset.
a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP does not
have to understand them. The format must be one of the formats
specified for the media. Format-specific parameters may be any
set of parameters required to be conveyed by SDP and given
unchanged to the media tool that will use this format. At most
one instance of this attribute is allowed for each format.
It is a media-level attribute, and it is not dependent on
charset.
7. Security Considerations
SDP is frequently used with the Session Initiation Protocol [15]
using the offer/answer model [17] to agree on parameters for unicast
sessions. When used in this manner, the security considerations of
those protocols apply.
SDP is a session description format that describes multimedia
sessions. Entities receiving and acting upon an SDP message SHOULD
be aware that a session description cannot be trusted unless it has
been obtained by an authenticated transport protocol from a known and
trusted source. Many different transport protocols may be used to
distribute session description, and the nature of the authentication
will differ from transport to transport. For some transports,
security features are often not deployed. In case a session
description has not been obtained in a trusted manner, the endpoint
SHOULD exercise care because, among other attacks, the media sessions
received may not be the intended ones, the destination where media is
sent to may not be the expected one, any of the parameters of the
session may be incorrect, or the media security may be compromised.
It is up to the endpoint to make a sensible decision taking into
account the security risks of the application and the user
preferences and may decide to ask the user whether or not to accept
the session.
One transport that can be used to distribute session descriptions is
the Session Announcement Protocol (SAP). SAP provides both
encryption and authentication mechanisms, but due to the nature of
session announcements it is likely that there are many occasions
where the originator of a session announcement cannot be
authenticated because the originator is previously unknown to the
receiver of the announcement and because no common public key
infrastructure is available.
On receiving a session description over an unauthenticated transport
mechanism or from an untrusted party, software parsing the session
should take a few precautions. Session descriptions contain
information required to start software on the receiver’s system.
Software that parses a session description MUST NOT be able to start
other software except that which is specifically configured as
appropriate software to participate in multimedia sessions. It is
normally considered inappropriate for software parsing a session
description to start, on a user’s system, software that is
appropriate to participate in multimedia sessions, without the user
first being informed that such software will be started and giving
the user’s consent. Thus, a session description arriving by session
announcement, email, session invitation, or WWW page MUST NOT deliver
the user into an interactive multimedia session unless the user has
explicitly pre-authorised such action. As it is not always simple to
tell whether or not a session is interactive, applications that are
unsure should assume sessions are interactive.
In this specification, there are no attributes that would allow the
recipient of a session description to be informed to start multimedia
tools in a mode where they default to transmitting. Under some
circumstances it might be appropriate to define such attributes. If
this is done, an application parsing a session description containing
such attributes SHOULD either ignore them or inform the user that
joining this session will result in the automatic transmission of
multimedia data. The default behaviour for an unknown attribute is
to ignore it.
In certain environments, it has become common for intermediary
systems to intercept and analyse session descriptions contained
within other signalling protocols. This is done for a range of