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 a H.332 session as defined in the ITU
H.332 specification [10]. 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 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 such
as ISO-8859-1 for Northern European languages. In particular,
the ISO 8859-1 is specified with the following SDP attribute:
a=charset:ISO-8859-1
This is a session-level attribute; if this attribute is present,
it must be before the first media field. 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 byte 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 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 should be 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 RFC1766 language
tag in US-ASCII. 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 multiple languages
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 RFC1766 language tag
in US-ASCII. 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 attribute, is
only defined for video media, and 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 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 attribute, and 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 doesn't 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.
It is a media attribute, and is not dependent on charset.
6.1. Communicating Conference Control Policy
There is some debate over the way conference control policy should be
communicated. In general, the authors believe that an implicit
declarative style of specifying conference control is desirable where
possible.
A simple declarative style uses a single conference attribute field
before the first media field, possibly supplemented by properties
such as `recvonly' for some of the media tools. This conference
attribute conveys the conference control policy. An example might be:
a=type:moderated
In some cases, however, it is possible that this may be insufficient
to communicate the details of an unusual conference control policy.
If this is the case, then a conference attribute specifying external
control might be set, and then one or more "media" fields might be
used to specify the conference control tools and configuration data
for those tools. An example is an ITU H.332 session:
c=IN IP4 224.5.6.7
a=type:H332
m=audio 49230 RTP/AVP 0
m=video 49232 RTP/AVP 31
m=application 12349 udp wb
m=control 49234 H323 mc
c=IN IP4 134.134.157.81
In this example, a general conference attribute (type:H332) is
specified stating that conference control will be provided by an
external H.332 tool, and a contact addresses for the H.323 session
multipoint controller is given.
In this document, only the declarative style of conference control
declaration is specified. Other forms of conference control should
specify an appropriate type attribute, and should define the
implications this has for control media.
7. Security Considerations
SDP is a session description format that describes multimedia
sessions. A session description should not be trusted unless it has
been obtained by an authenticated transport protocol from a 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.
One transport that will frequently 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 they are 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 description contain
information required to start software on the receivers 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
their consent. Thus a session description arriving by session
announcement, email, session invitation, or WWW page SHOULD not
deliver the user into an {it interactive} multimedia session without
the user being aware that this will happen. As it is not always
simple to tell whether a session is interactive or not, applications
that are unsure should assume sessions are interactive.
In this specification, there are no attributes which 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.
Session descriptions may be parsed at intermediate systems such as
firewalls for the purposes of opening a hole in the firewall to allow
the participation in multimedia sessions. It is considered
INAPPROPRIATE for a firewall to open such holes for unicast data
streams unless the session description comes in a request from inside
the firewall.
For multicast sessions, it is likely that local administrators will
apply their own policies, but the exclusive use of "local" or "site-
local" administrative scope within the firewall and the refusal of
the firewall to open a hole for such scopes will provide separation
of global multicast sessions from local ones.
Appendix A: SDP Grammar
This appendix provides an Augmented BNF grammar for SDP. ABNF is
defined in RFC2234.
announcement = proto-version
origin-field
session-name-field
information-field
uri-field
email-fields
phone-fields
connection-field
bandwidth-fields
time-fields
key-field
attribute-fields
media-descriptions
proto-version = "v=" 1*DIGIT CRLF
;this memo describes version 0
origin-field = "o=" username space
sess-id space sess-version space
nettype space addrtype space
addr CRLF
session-name-field = "s=" text CRLF
information-field = ["i=" text CRLF]
uri-field = ["u=" uri CRLF]
email-fields = *("e=" email-address CRLF)
phone-fields = *("p=" phone-number CRLF)
connection-field = ["c=" nettype space addrtype space
connection-address CRLF]
;a connection field must be present
;in every media description or at the
;session-level
bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF)
time-fields = 1*( "t=" start-time space stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
repeat-fields = "r=" repeat-interval space typed-time
1*(space typed-time)
zone-adjustments = time space ["-"] typed-time
*(space time space ["-"] typed-time)
key-field = ["k=" key-type CRLF]
key-type = "prompt" |
"clear:" key-data |
"base64:" key-data |
"uri:" uri
key-data = email-safe | "~" | "
attribute-fields = *("a=" attribute CRLF)
media-descriptions = *( media-field
information-field
*(connection-field)
bandwidth-fields
key-field
attribute-fields )
media-field = "m=" media space port ["/" integer]
space proto 1*(space fmt) CRLF
media = 1*(alpha-numeric)
;typically "audio", "video", "application"
;or "data"
fmt = 1*(alpha-numeric)
;typically an RTP payload type for audio
;and video media
proto = 1*(alpha-numeric)
;typically "RTP/AVP" or "udp" for IP4
port = 1*(DIGIT)
;should in the range "1024" to "65535" inclusive
;for UDP based media
attribute = (att-field ":" att-value) | att-field
att-field = 1*(alpha-numeric)
att-value = byte-string
sess-id = 1*(DIGIT)
;should be unique for this originating username/host
sess-version = 1*(DIGIT)
;0 is a new session
connection-address = multicast-address
| addr
multicast-address = 3*(decimal-uchar ".") decimal-uchar "/" ttl
[ "/" integer ]
;multicast addresses may be in the range
;224.0.0.0 to 239.255.255.255
ttl = decimal-uchar
start-time = time | "0"
stop-time = time | "0"
time = POS-DIGIT 9*(DIGIT)
;sufficient for 2 more centuries
repeat-interval = typed-time
typed-time = 1*(DIGIT) [fixed-len-time-unit]
fixed-len-time-unit = "d" | "h" | "m" | "s"
bwtype = 1*(alpha-numeric)
bandwidth = 1*(DIGIT)
username = safe
;pretty wide definition, but doesn't include space
email-address = email | email "(" email-safe ")" |
email-safe "<" email ">"
email = ;defined in RFC822
uri= ;defined in RFC1630
phone-number = phone | phone "(" email-safe ")" |
email-safe "<" phone ">"
phone = "+" POS-DIGIT 1*(space | "-" | DIGIT)
;there must be a space or hyphen between the
;international code and the rest of the number.
nettype = "IN"
;list to be extended
addrtype = "IP4" | "IP6"
;list to be extended
addr = FQDN | unicast-address
FQDN = 4*(alpha-numeric|"-"|".")
;fully qualified domain name as specified in RFC1035
unicast-address = IP4-address | IP6-address
IP4-address = b1 "." decimal-uchar "." decimal-uchar "." b4
b1 = decimal-uchar
;less than "224"; not "0" or "127"
b4 = decimal-uchar
;not "0"
IP6-address = ;to be defined
text = byte-string
;default is to interpret this as IS0-10646 UTF8
;ISO 8859-1 requires a "a=charset:ISO-8859-1"
;session-level attribute to be used
byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
;any byte except NUL, CR or LF
decimal-uchar = DIGIT
| POS-DIGIT DIGIT
| ("1" 2*(DIGIT))
| ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
| ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))
integer = POS-DIGIT *(DIGIT)
alpha-numeric = ALPHA | DIGIT
DIGIT = "0" | POS-DIGIT
POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|
"l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"|
"w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"|
"H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"|
"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"
email-safe = safe | space | tab
safe = alpha-numeric |
"'" | "'" | "-" | "." | "/" | ":" | "?" | """ |
"#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |
"]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |
"~" | "
space = %d32
tab = %d9
CRLF = %d13.10
Appendix B: Guidelines for registering SDP names with IANA
There are seven field names that may be registered with IANA. Using
the terminology in the SDP specification BNF, they are "media",
"proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype".
"media" (eg, audio, video, application, data).
Packetized media types, such as those used by RTP, share the
namespace used by media types registry [RFC2048] (i.e. "MIME
types"). The list of valid media names is the set of top-level
MIME content types. The set of media is intended to be small and
not to be extended except under rare circumstances. (The MIME
subtype corresponds to the "fmt" parameter below).
"proto"
In general this should be an IETF standards-track transport
protocol identifier such as RTP/AVP (rfc 1889 under the rfc 1890
profile).
However, people will want to invent their own proprietary
transport protocols. Some of these should be registered as a
"fmt" using "udp" as the protocol and some of which probably
can't be.
Where the protocol and the application are intimately linked,
such as with the LBL whiteboard wb which used a proprietary and
special purpose protocol over UDP, the protocol name should be
"udp" and the format name that should be registered is "wb". The
rules for formats (see below) apply to such registrations.
Where the proprietary transport protocol really carries many
different data formats, it is possible to register a new protocol
name with IANA. In such a case, an RFCMUST be produced
describing the protocol and referenced in the registration. Such
an RFCMAY be informational, although it is preferable if it is
standards-track.
"fmt"
The format namespace is dependent on the context of the "proto"
field, so a format cannot be registered without specifying one or
more transport protocols that it applies to.
Formats cover all the possible encodings that might want to be
transported in a multimedia session.
For RTP formats that have been assigned static payload types, the
payload type number is used. For RTP formats using a dynamic
payload type number, the dynamic payload type number is given as
the format and an additional "rtpmap" attribute specifies the
format and parameters.
For non-RTP formats, any unregistered format name may be
registered through the MIME-type registration process [RFC2048].
The type given here is the MIME subtype only (the top-level MIME
content type is specified by the media parameter). The MIME type
registration SHOULD reference a standards-track RFCwhich
describes the transport protocol for this media type. If there
is an existing MIME type for this format, the MIME registration
should be augmented to reference the transport specification for
this media type. If there is not an existing MIME type for this
format, and there exists no appropriate file format, this should
be noted in the encoding considerations as "no appropriate file
format".
"att-field" (Attribute names)
Attribute field names MAY be registered with IANA, although this
is not compulsory, and unknown attributes are simply ignored.
When an attribute is registered, it must be accompanied by a
brief specification stating the following:
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 type of attribute (session level, media level, or both)
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.
IANA will not sanity check such attribute registrations except to
ensure that they do not clash with existing registrations.
Although the above is the minimum that IANA will accept, if the
attribute is expected to see widespread use and interoperability
is an issue, authors are encouraged to produce a standards-track
RFCthat 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.
"bwtype" (bandwidth specifiers)
A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers may be registered with IANA. The
submission MUST reference a standards-track RFCspecifying the
semantics of the bandwidth specifier precisely, and indicating
when it should be used, and why the existing registered bandwidth
specifiers do not suffice.
"nettype" (Network Type)
New network types may be registered with IANA if SDP needs to be
used in the context of non-internet environments. Whilst these
are not normally the preserve of IANA, there may be circumstances
when an Internet application needs to interoperate with a non-
internet application, such as when gatewaying an internet
telephony call into the PSTN. The number of network types should
be small and should be rarely extended. A new network type
cannot be registered without registering at least one address
type to be used with that network type. A new network type
registration MUST reference an RFCwhich gives details of the
network type and address type and specifies how and when they
would be used. Such an RFCMAY be Informational.
"addrtype" (Address Type)
New address types may be registered with IANA. An address type
is only meaningful in the context of a network type, and any
registration of an address type MUST specify a registered network
type, or be submitted along with a network type registration. A
new address type registration MUST reference an RFCgiving
details of the syntax of the address type. Such an RFCMAY be
Informational. Address types are not expected to be registered
frequently.
Registration Procedure
To register a name the above guidelines should be followed regarding
the required level of documentation that is required. The
registration itself should be sent to IANA. Attribute registrations
should include the information given above. Other registrations
should include the following additional information:
o contact name, email address and telephone number
o name being registered (as it will appear in SDP)
o long-form name in English
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or
"addrtype")
o a one paragraph explanation of the purpose of the registered name.
o a reference to the specification (eg RFCnumber) of the registered
name.
IANA may refer any registration to the IESG or to any appropriate
IETF working group for review, and may request revisions to be made
before a registration will be made.
Appendix C: Authors' Addresses
Mark Handley
Information Sciences Institute
c/o MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139
United States
electronic mail: mjh@isi.edu
Van Jacobson
MS 46a-1121
Lawrence Berkeley Laboratory
Berkeley, CA 94720
United States
electronic mail: van@ee.lbl.gov
Acknowledgments
Many people in the IETF MMUSIC working group have made comments and
suggestions contributing to this document. In particular, we would
like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison
Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Rob
Lanphier and Steve Hanna.
References
[1] Mills, D., "Network Time Protocol (version 3) specification and
implementation", RFC1305, March 1992.
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC1889, January
1996.
[3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC1890, January 1996
[4] Handley, M., "SAP - Session Announcement Protocol", Work in
Progress.
[5] V. Jacobson, S. McCanne, "vat - X11-based audio teleconferencing
tool" vat manual page, Lawrence Berkeley Laboratory, 1994.
[6] The Unicode Consortium, "The Unicode Standard -- Version 2.0",
Addison-Wesley, 1996.
[7] ISO/IEC 10646-1:1993. International Standard -- Information
technol- ogy -- Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane. Five amendments
and a techn- ical corrigendum have been published up to now. UTF-8
is described in Annex R, published as Amendment 2.
[8] Goldsmith, D., and M. Davis, "Using Unicode with MIME", RFC1641,
July 1994.
[9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC2044, October 1996.
[10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for
Receiving Internet-based H.323 Conferences", ITU, Geneva.
[11] Handley, M., Schooler, E., and H. Schulzrinne, "Session
Initiation Protocol (SIP)", Work in Progress.
[12] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC2326, April 1998.
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.