purposes, including but not limited to opening holes in firewalls to
allow media streams to pass, or to mark, prioritize, or block traffic
selectively. In some cases, such intermediary systems may modify the
session description, for example, to have the contents of the session
description match NAT bindings dynamically created. These behaviours
are NOT RECOMMENDED unless the session description is conveyed in
such a manner that allows the intermediary system to conduct proper
checks to establish the authenticity of the session description, and
the authority of its source to establish such communication sessions.
SDP by itself does not include sufficient information to enable these
checks: they depend on the encapsulating protocol (e.g., SIP or
RTSP).
Use of the "k=" field poses a significant security risk, since it
conveys session encryption keys in the clear. SDP MUST NOT be used
to convey key material, unless it can be guaranteed that the channel
over which the SDP is delivered is both private and authenticated.
Moreover, the "k=" line provides no way to indicate or negotiate
cryptographic key algorithms. As it provides for only a single
symmetric key, rather than separate keys for confidentiality and
integrity, its utility is severely limited. The use of the "k=" line
is NOT RECOMMENDED, as discussed in Section 5.12.
8. IANA Considerations
8.1. The "application/sdp" Media Type
One media type registration from RFC 2327 is to be updated, as
defined below.
To: ietf-types@iana.org
Subject: Registration of media type "application/sdp"
Type name: application
Subtype name: sdp
Required parameters: None.
Optional parameters: None.
Encoding considerations:
SDP files are primarily UTF-8 format text. The "a=charset:"
attribute may be used to signal the presence of other
character sets in certain parts of an SDP file (see
Section 6 of RFC 4566). Arbitrary binary content cannot
be directly represented in SDP.
Security considerations:
See Section 7 of RFC 4566
Interoperability considerations:
See RFC 4566
Published specification:
See RFC 4566
Applications which use this media type:
Voice over IP, video teleconferencing, streaming media, instant
messaging, among others. See also Section 3 of RFC 4566.
Additional information:
Magic number(s): None.
File extension(s): The extension ".sdp" is commonly used.
Macintosh File Type Code(s): "sdp "
Person & email address to contact for further information:
Mark Handley <M.Handley@cs.ucl.ac.uk>
Colin Perkins <csp@csperkins.org>
IETF MMUSIC working group <mmusic@ietf.org>
Intended usage: COMMON
Author/Change controller:
Authors of RFC 4566
IETF MMUSIC working group delegated from the IESG
8.2. Registration of Parameters
There are seven field names that may be registered with IANA. Using
the terminology in the SDP specification Backus-Naur Form (BNF), they
are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and
"addrtype".
8.2.1. Media Types ("media")
The set of media types is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should
apply for media names as for top-level media content types, and where
possible the same name should be registered for SDP as for MIME. For
media other than existing top-level media content types, a Standards
Track RFC MUST be produced for a new top-level content type to be
registered, and the registration MUST provide good justification why
no existing media name is appropriate (the "Standards Action" policy
of RFC 2434 [8].
This memo registers the media types "audio", "video", "text",
"application", and "message".
Note: The media types "control" and "data" were listed as valid in
the previous version of this specification [6]; however, their
semantics were never fully specified and they are not widely used.
These media types have been removed in this specification, although
they still remain valid media type capabilities for a SIP user agent
as defined in RFC 3840 [24]. If these media types are considered
useful in the future, a Standards Track RFC MUST be produced to
document their use. Until that is done, applications SHOULD NOT use
these types and SHOULD NOT declare support for them in SIP
capabilities declarations (even though they exist in the registry
created by RFC 3840).
8.2.2. Transport Protocols ("proto")
The "proto" field describes the transport protocol used. This SHOULD
reference a standards-track protocol RFC. This memo registers three
values: "RTP/AVP" is a reference to RTP [19] used under the RTP
Profile for Audio and Video Conferences with Minimal Control [20]
running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real-
time Transport Protocol [23], and "udp" indicates an unspecified
protocol over UDP.
If other RTP profiles are defined in the future, their "proto" name
SHOULD be specified in the same manner. For example, an RTP profile
whose short name is "XYZ" would be denoted by a "proto" field of
"RTP/XYZ".
New transport protocols SHOULD be registered with IANA.
Registrations MUST reference an RFC describing the protocol. Such an
RFC MAY be Experimental or Informational, although it is preferable
that it be Standards Track. Registrations MUST also define the rules
by which their "fmt" namespace is managed (see below).
8.2.3. Media Formats ("fmt")
Each transport protocol, defined by the "proto" field, has an
associated "fmt" namespace that describes the media formats that may
be conveyed by that protocol. Formats cover all the possible
encodings that might want to be transported in a multimedia session.
RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST
use the payload type number as their "fmt" value. If the payload
type number is dynamically assigned by this session description, an
additional "rtpmap" attribute MUST be included to specify the format
name and parameters as defined by the media type registration for the
payload format. It is RECOMMENDED that other RTP profiles that are
registered (in combination with RTP) as SDP transport protocols
specify the same rules for the "fmt" namespace.
For the "udp" protocol, new formats SHOULD be registered. Use of an
existing media subtype for the format is encouraged. If no media
subtype exists, it is RECOMMENDED that a suitable one be registered
through the IETF process [31] by production of, or reference to, a
standards-track RFC that defines the transport protocol for the
format.
For other protocols, formats MAY be registered according to the rules
of the associated "proto" specification.
Registrations of new formats MUST specify which transport protocols
they apply to.
8.2.4. Attribute Names ("att-field")
Attribute field names ("att-field") MUST be registered with IANA and
documented, because of noticeable issues due to conflicting
attributes under the same name. Unknown attributes in SDP are simply
ignored, but conflicting ones that fragment the protocol are a
serious problem.
New attribute registrations are accepted according to the
"Specification Required" policy of RFC 2434, provided that the
specification includes the following information:
o contact name, email address, and telephone number
o attribute name (as it will appear in SDP)
o long-form attribute name in English
o 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
The above is the minimum that IANA will accept. Attributes that are
expected to see widespread use and interoperability SHOULD be
documented with a standards-track RFC that specifies the attribute
more precisely.
Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit
assumptions about operating systems and does not name specific pieces
of software in a manner that might inhibit interoperability.
IANA has registered the following initial set of attribute names
("att-field" values), with definitions as in Section 6 of this memo
(these definitions update those in RFC 2327):
Name | Session or Media level? | Dependent on charset?
----------+-------------------------+----------------------
cat | Session | No
keywds | Session | Yes
tool | Session | No
ptime | Media | No
maxptime | Media | No
rtpmap | Media | No
recvonly | Either | No
sendrecv | Either | No
sendonly | Either | No
inactive | Either | No
orient | Media | No
type | Session | No
charset | Session | No
sdplang | Either | No
lang | Either | No
framerate | Media | No
quality | Media | No
fmtp | Media | No
8.2.5. Bandwidth Specifiers ("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers ("bwtype" fields) MUST be registered with
IANA. The submission MUST reference a standards-track RFC specifying
the semantics of the bandwidth specifier precisely, and indicating
when it should be used, and why the existing registered bandwidth
specifiers do not suffice.
IANA has registered the bandwidth specifiers "CT" and "AS" with
definitions as in Section 5.8 of this memo (these definitions update
those in RFC 2327).
8.2.6. Network Types ("nettype")
New network types (the "nettype" field) may be registered with IANA
if SDP needs to be used in the context of non-Internet environments.
Although 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
telephone call into the Public Switched Telephone Network (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 RFC that
gives details of the network type and address type and specifies how
and when they would be used.
IANA has registered the network type "IN" to represent the Internet,
with definition as in Sections 5.2 and 5.7 of this memo (these
definitions update those in RFC 2327).
8.2.7. Address Types ("addrtype")
New address types ("addrtype") 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 RFC giving details of the
syntax of the address type. Address types are not expected to be
registered frequently.
IANA has registered the address types "IP4" and "IP6" with
definitions as in Sections 5.2 and 5.7 of this memo (these
definitions update those in RFC 2327).
8.2.8. Registration Procedure
In the RFC documentation that registers SDP "media", "proto", "fmt",
"bwtype", "nettype", and "addrtype" fields, the authors MUST include
the following information for IANA to place in the appropriate
registry:
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 for the registered name (this
will typically be an RFC number)
IANA may refer any registration to the IESG for review, and may
request revisions to be made before a registration will be made.
8.3. Encryption Key Access Methods
The IANA previously maintained a table of SDP encryption key access
method ("enckey") names. This table is obsolete, since the "k=" line
is not extensible. New registrations MUST NOT be accepted.
9. SDP Grammar
This section provides an Augmented BNF grammar for SDP. ABNF is
defined in [4].
; SDP Syntax
session-description = 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 = %x76 "=" 1*DIGIT CRLF
;this memo describes version 0
origin-field = %x6f "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
session-name-field = %x73 "=" text CRLF
information-field = [%x69 "=" text CRLF]
uri-field = [%x75 "=" uri CRLF]
email-fields = *(%x65 "=" email-address CRLF)
phone-fields = *(%x70 "=" phone-number CRLF)
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
;a connection field must be present
;in every media description or at the
;session-level
bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF)
time-fields = 1*( %x74 "=" start-time SP stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
repeat-fields = %x72 "=" repeat-interval SP typed-time
1*(SP typed-time)
zone-adjustments = %x7a "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time)
key-field = [%x6b "=" key-type CRLF]
attribute-fields = *(%x61 "=" attribute CRLF)
media-descriptions = *( media-field
information-field
*connection-field
bandwidth-fields
key-field
attribute-fields )
media-field = %x6d "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF
; sub-rules of ’o=’
username = non-ws-string
;pretty wide definition, but doesn’t
;include space
sess-id = 1*DIGIT
;should be unique for this username/host
sess-version = 1*DIGIT
nettype = token
;typically "IN"
addrtype = token
;typically "IP4" or "IP6"
; sub-rules of ’u=’
uri = URI-reference
; see RFC 3986
; sub-rules of ’e=’, see RFC 2822 for definitions
email-address = address-and-comment / dispname-and-address
/ addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"
; sub-rules of ’p=’
phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" /
phone
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
; sub-rules of ’c=’
connection-address = multicast-address / unicast-address
; sub-rules of ’b=’
bwtype = token
bandwidth = 1*DIGIT
; sub-rules of ’t=’
start-time = time / "0"
stop-time = time / "0"
time = POS-DIGIT 9*DIGIT
; Decimal representation of NTP time in
; seconds since 1900. The representation
; of NTP time is an unbounded length field
; containing at least 10 digits. Unlike the
; 64-bit representation used elsewhere, time
; in SDP does not wrap in the year 2036.
; sub-rules of ’r=’ and ’z=’
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = %x64 / %x68 / %x6d / %x73
; sub-rules of ’k=’
key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt"
%x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:"
%x62 %x61 %x73 %x65 "64:" base64 / ; "base64:"
%x75 %x72 %x69 ":" uri ; "uri:"
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
; sub-rules of ’a=’
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
; sub-rules of ’m=’
media = token
;typically "audio", "video", "text", or
;"application"
fmt = token
;typically an RTP payload type for audio
;and video media
proto = token *("/" token)
;typically "RTP/AVP" or "udp"
port = 1*DIGIT
; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / FQDN
/ extn-addr
IP4-multicast = m1 3( "." decimal-uchar )
"/" ttl [ "/" integer ]
; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )
IP6-multicast = hexpart [ "/" integer ]
; IPv6 address starting with FF
ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
IP4-address = b1 3("." decimal-uchar)
b1 = decimal-uchar
; less than "224"
; The following is consistent with RFC 2373 [30], Appendix B.
IP6-address = hexpart [ ":" IP4-address ]
hexpart = hexseq / hexseq "::" [ hexseq ] /
"::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
; Generic for other address families
extn-addr = non-ws-string
; generic sub-rules: datatypes
text = byte-string
;default is to interpret this as UTF8 text.