RFC8866: SDP-Session Description Protocol¶
Obsoletes: rfc4566(July 2006) rfc2327(April 1998) rfc3266(June 2002)
Category: Standards Track
January 2021
SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
1. Introduction¶
When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants.
SDP provides a standard representation for such information, irrespective of how that information is transported.
It is intended to use different transport protocols as appropriate, including the Session Announcement Protocol(SAP)[RFC2974], Session Initiation Protocol(SIP)[RFC3261] , Real-Time Streaming Protocol (RTSP) [RFC7826],
electronic mail [RFC5322] using the MIME extensions [RFC2045], and theHypertext Transport Protocol (HTTP) [RFC7230].SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications.
2. Glossary of Terms¶
Session Description: A well-defined format for conveying sufficient information to discover and participate in a multimedia session.
Media Description: A Media Description contains the information needed for one party to establish an application-layer network protocol connection to another party. It starts with an “m=” line and is terminated by either the next “m=” line or by the end of the session description.
Session-Level Section: This refers to the parts that are not media descriptions, => whereas the
session descriptionrefers to the whole body that includes thesession-level sectionand themedia description(s).
3. Examples of SDP Usage¶
3.1. Session Initiation¶
The Session Initiation Protocol (SIP) [RFC3261] is an application-layer control protocol for creating, modifying, and terminating sessions such as Internet multimedia conferences, Internet telephone calls, and multimedia distribution.
The SIP messages used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types [RFC6838].
3.2. Streaming Media¶
The Real-Time Streaming Protocol (RTSP) [RFC7826], is an application-level protocol for control over the delivery of data with real-time properties.
RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video.
An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters.
3.3. Email and the World Wide Web¶
For both email and WWW distribution, the media type “application/sdp” is used.
3.4. Multicast Session Announcement¶
One protocol used to implement such a distributed directory is the SAP [RFC2974].
SDP provides the recommended session description format for such session announcements.
4. Requirements and Recommendations¶
The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session.
An SDP description includes the following:
1. Session name and purpose
2. Time(s) the session is active
3. The media comprising the session
4. Information needed to receive those media (addresses, ports, formats, etc.)
In general, SDP must convey sufficient information to enable applications to join a session (with the possible exception of encryption keys) and to announce the resources to be used to any nonparticipants that may need to know. (This latter feature is primarily useful when SDP is used with a multicast session announcement protocol.)
4.1. Media and Transport Information¶
An SDP description includes the following media information:
1. The type of media (video, audio, etc.)
2. The media transport protocol (RTP/UDP/IP, H.320, etc.)
3. The format of the media (H.261 video, MPEG video, etc.)
4. Typically, the remote address and remote port
4.2. Timing Information¶
Sessions may be either bounded or unbounded in time.
Whether or not they are bounded, they may be only active at specific times.
SDP can convey:
An arbitrary list of start and stop times bounding the session
For each bound, repeat times such as "every Wednesday at 10am for one hour"
5. SDP Specification¶
An SDP description is denoted by the media type “application/sdp” (See Section 8).
An SDP description is entirely textual.
An SDP description consists of a number of lines of text of the form:
<type>=<value>
备注
Some lines in each description are required and some are optional, but when present, they must appear in exactly the order given here. (The fixed order greatly enhances error detection and allows for a simple parser).
An SDP description consists of a session-level section followed by zero or more media descriptions:
注: optional items are marked with a "*"
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in all media descriptions)
b=* (zero or more bandwidth information lines)
One or more time descriptions:
("t=", "r=" and "z=" lines; see below)
k=* (obsolete)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description
t= (time the session is active)
r=* (zero or more repeat times)
z=* (optional time zone offset line)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (obsolete)
a=* (zero or more media attribute lines)
An example SDP description is:
v=0
o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1
s=Call to John Smith
i=SDP Offer #1
u=http://www.jdoe.example.com/home.html
e=Jane Doe <jane@jdoe.example.com>
p=+1 617 555-6011
c=IN IP4 198.51.100.1
t=0 0
m=audio 49170 RTP/AVP 0
m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99
c=IN IP6 2001:db8::2
a=rtpmap:99 h263-1998/90000
5.1. Protocol Version (“v=”)¶
The “v=” line (version-field) gives the version of the Session Description Protocol.
This memo defines version 0 means there is no minor version number.
示例:
v=0
5.2. Origin (“o=”)¶
In general, the “o=” line serves as a globally unique identifier for this version of the session description, and the subfields excepting the version, taken together identify the session irrespective of any modifications.
格式:
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
说明:
<username>
The user's login on the originating host, or it is "-" if the originating host does not support the concept of user IDs.
The <username> MUST NOT contain spaces.
<sess-id>
a numeric string such that the tuple of
<username>, <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a globally unique id for the session.
The method of <sess-id> allocation is up to the creating tool,
but a timestamp, in seconds since January 1, 1900 UTC, is recommended to ensure uniqueness.
<sess-version>
a version number for this session description.
Its usage is up to the creating tool,
so long as <sess-version> is increased when a modification is made to the session description.
Again, as with <sess-id> it is RECOMMENDED that a timestamp be used.
<nettype>
a text string giving the type of network.
Initially, "IN" is defined to have the meaning "Internet",
but other values MAY be registered in the future (see Section 8).
<addrtype>
a text string giving the type of the address that follows.
Initially, "IP4" and "IP6" are defined, but other values MAY be registered in the future (see Section 8).
<unicast-address>
an address of the machine from which the session was created.
For an address type of "IP4", this is
either a fully qualified domain name of the machine
or the dotted-decimal representation of an IP version 4 address of the machine.
For an address type of "IP6", this is
either a fully qualified domain name of the machine
or the address of the machine represented as specified in Section 4 of [RFC5952].
For both "IP4" and "IP6", the fully qualified domain name is the form that SHOULD be given unless this is unavailable,
in which case a globally unique address MAY be substituted.
5.3. Session Name (“s=”)¶
格式:
s=<session name>
The “s=” line (session-name-field) is the textual session name.
There MUST be one and only one “s=” line per session description.
The “s=” line MUST NOT be empty. If a session has no meaningful name, then “s= “ or “s=-” (i.e., a single space or dash as the session name) is RECOMMENDED.
5.4. Session Information (“i=”)¶
格式:
i=<session information>
The “i=” line (information-field) provides textual information about the session.
5.5. URI (“u=”)¶
格式:
u=<uri>
The “u=” line (uri-field) provides a URI (Uniform Resource Identifier) [RFC3986].
5.6. Email Address and Phone Number (“e=” and “p=”)¶
格式:
e=<email-address>
p=<phone-number>
The “e=” line (email-field) and “p=” line (phone-field) specify contact information for the person responsible for the session.
Example:
p=+1 617 555-6011
e=j.doe@example.com (Jane Doe)
e=Jane Doe <j.doe@example.com>
5.7. Connection Information (“c=”)¶
格式:
c=<nettype> <addrtype> <connection-address>
The “c=” line (connection-field) contains information necessary to establish a network connection.
A session description MUST contain either at least one “c=” line in each media description or a single “c=” line at the session level.
示例:
c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.1/127/3
c=IN IP6 ff00::db8:0:101/3
5.8. Bandwidth Information (“b=”)¶
格式:
b=<bwtype>:<bandwidth>
The OPTIONAL “b=” line (bandwidth-field) denotes the proposed bandwidth to be used by the session or media description.
The <bwtype> is an alphanumeric modifier that provides the meaning of the <bandwidth> number.
Two values are defined in this specification, but other values MAY be registered in the future:
CT
AS
5.9. Time Active (“t=”)¶
A “t=” line (time-field) begins a time description that specifies the start and stop times for a session.
格式:
t=<start-time> <stop-time>
The following example specifies two active intervals:
t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC
t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC
These are the decimal representation of time values in seconds since January 1, 1900 UTC.
If the <stop-time> is set to zero, then the session is not bounded, though it will not become active until after the <start-time>. If the <start-time> is also zero, the session is regarded as permanent.
User interfaces SHOULD strongly discourage the creation of unbounded and permanent sessions as they give no information about when the session is actually going to terminate, and so make scheduling difficult.
5.10. Repeat Times (“r=”)¶
格式:
r=<repeat interval> <active duration> <offsets from start-time>
示例:
t=3724394400 3730536000 ; Mon 08-Jan-2018 10:00 UTC
; Tue 20-Mar-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
times may also be given in units of days, hours, or minutes:
r=7d 1h 0 25h
5.11. Time Zone Adjustment (“z=”)¶
格式:
z=<adjustment time> <offset> <adjustment time> <offset> ....
To schedule a repeated session that spans a change from daylight saving time to standard time or vice versa, it is necessary to specify
offsetsfrom the base time.
An example might be the following:
t=3724394400 3754123200 ; Mon 08-Jan-2018 10:00 UTC
; Tue 18-Dec-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC,
; offset 1 hour,
; Sun 28-Oct-2018 2:00 UTC,
; no offset
This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the onset of British Summer Time) the time base by which the session’s repeat times are calculated is shifted back by 1 hour, and that at time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer Time) the session’s original time base is restored.
5.12. Encryption Keys (“k=”)¶
格式:
k=<method>
k=<method>:<encryption key>
The “k=” line (key-field) is obsolete and MUST NOT be used.
5.13. Attributes (“a=”)¶
格式:
a=<attribute-name>
a=<attribute-name>:<attribute-value>
Attributes are the primary means for extending SDP.
Attributes may be defined to be used as session-level attributes, media-level attributes, or both.
Attribute-fields may be of two forms:
A property attribute is simply of the form "a=<attribute-name>".
These are binary attributes, and the presence of the attribute conveys that the attribute is a property of the session.
An example might be "a=recvonly".
A value attribute is of the form "a=<attribute-name>:<attribute-value>".
For example, a whiteboard could have the value attribute "a=orient:landscape".
5.14. Media Descriptions (“m=”)¶
格式:
m=<media> <port> <proto> <fmt> ...
Each media description starts with an “m=” line (media-field) and is terminated by either the next “m=” line or by the end of the session description.
A media-field has several subfields:
<media>: the media type. including:
"audio"
"video"
"text"
"application"
"message"
<port>: the transport port to which the media stream is sent.
<proto>: the transport protocol. including:
"udp"
"RTP/AVP"
"RTP/SAVP"
"RTP/SAVPF"
<fmt>： a media format description.
The interpretation of the media format depends on the value of the <proto> subfield.
If the <proto> subfield is "RTP/AVP" or "RTP/SAVP",
the <fmt> subfields contain RTP payload type numbers.
If the <proto> subfield is "udp",
the <fmt> subfields MUST reference a media type describing the format under the
"audio", "video", "text", "application", or "message" top-level media types.
6. SDP Attributes¶
6.1. cat (Category)¶
Syntax:
cat-value = category
category = non-ws-string
Example:
a=cat:foo.bar
This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received.
6.2. keywds (Keywords)¶
Syntax:
keywds-value = keywords
keywords = text
Example:
a=keywds:SDP session description protocol
This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received.
6.3. tool¶
This gives the name and version number of the tool used to create the session description.
Syntax:
tool-value = tool-name-and-version
tool-name-and-version = text
Example:
a=tool:foobar V3.2
6.4. 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 “a=ptime:” to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetization of audio.
Syntax:
ptime-value = non-zero-int-or-real
Example:
a=ptime:20
6.5. 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.
a=ptime指定了每个packet的标准payload时长,但实际上每个packet的payload长度可能会有些变化。a=maxptime则指定了最大允许的payload时长变化。
通过设置maxptime,接收端可以预留足够的缓存空间,以防实际的packet payload长度超出正常的ptime设置。这也有助于避免数据包溢出和丢包。所以a=ptime和a=maxptime一起使用,可以让发送端和接收端对RTP数据包中的音视频数据具有更精确和更健壮的处理能力。
Syntax:
maxptime-value = non-zero-int-or-real
Example:
a=maxptime:20
6.6. rtpmap¶
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.
Note that the payload type number is indicated in a 7-bit field, limiting the values to inclusively between 0 and 127.
Syntax:
rtpmap-value = payload-type SP encoding-name
"/" clock-rate [ "/" encoding-params ]
payload-type = zero-based-integer
encoding-name = token
clock-rate = integer
encoding-params = channels
channels = integer
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 “a=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
自有摄像头实例:
m=audio 0 RTP/AVP 8
a=rtpmap:8 PCMA/8000/1
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
常见的Payload Type值为:
0: PCMU - G.711 u-law 64kbit/s audio
1: 1016 - G.721 ADPCM 32kbit/s audio
3: GSM - GSM 06.10 13kbit/s audio
4: G723 - G.723.1 dual rate 5.3/6.3kbit/s audio
5: DVI4 - IMA ADPCM 32kbit/s audio
6: DVI4 - IMA ADPCM 64kbit/s audio
7: LPC - LPC-10 2.5kbit/s audio
8: PCMA - G.711 A-law 64kbit/s audio
9: G722 - G.722 64kbit/s audio
10: L16 - Linear PCM 44.1kHz audio
11: L16 - Linear PCM 44.1kHz stereo audio
12: QCELP - QCELP 8kbit/s audio
13: CN - Comfort noise 8kbit/s audio
14: MPA - MPEG-1/MPEG-2 audio
15: G728 - G.728 16kbit/s audio
16-23: - Unassigned
24: unassigned video
25: CelB - Sun CellB video
26: JPEG - JPEG video
28: nv - nv video
31: H261 - H.261 video
32: MPV - MPEG-1/MPEG-2 video
33: MP2T - MPEG-2 transport stream
34: H263 - H.263 video
96-127: - Dynamic range
6.7. Media Direction Attributes¶
At most one occurrence of “a=recvonly”, “a=sendrecv”, “a=sendonly”, or “a=inactive” MAY appear at session level, and at most one MAY appear in each media description.
备注
If none of the media direction attributes is present at either session level or media level, “a=sendrecv” SHOULD be assumed as the default.
Within the following SDP example, the “a=sendrecv” attribute applies to the first audio media and the “a=inactive” attribute applies to the others:
v=0
o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1
s=-
c=IN IP6 2001:db8::1
t=0 0
a=inactive
m=audio 49170 RTP/AVP 0
a=sendrecv
m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
说明:
a=recvonly 表示这个流只能被接收,不能被发送。接收端可以获取媒体数据,但发送端不发送任何数据。
a=sendrecv 表示这个流可以双向传输,既可以发送也可以接收。这是最常见的流方向。
a=sendonly 表示这个流只能被发送,不能被接收。发送端发送媒体数据,但接收端不接收任何数据。
a=inactive 表示这个流暂时不活动,既不发送也不接收任何数据。
通过指定不同的方向,可以实现 more 复杂的交互,比如:
- 发送端发送,多个接收端接收(单播或多播)
- 多个发送端发送,接收端选择性接收
- 先发送后接收,实现“询问”的效果
- 先接收用户输入,后发送响应信息
典型场景如下:
a=recvonly
- 监控摄像头:多个客户端接收同一个摄像头的视频流
- 直播:观众接收流媒体服务器的音视频流
a=sendrecv
- 视频聊天:双方互相发送和接收音视频流
- 在线会议:多方互相发送和接收视频和音频
a=sendonly
- 直播:流媒体服务器向观众发送流,但不接收任何流
- 摄像头:IP摄像头发送视频流,但不接收任何流
a=inactive
- 流暂时不活动,可能由于网络问题或客户端的请求。等情况恢复后可以重新变为 sendrecv 或 recvonly
这4种属性基本上涵盖了流媒体的所有应用场景:
- 点对点:视频聊天(sendrecv)
- 点对多点:监控、在线课堂(recvonly)
- 多点对多点:视频会议(sendrecv)
- 直播:IP摄像头、直播节目(sendonly)
6.7.1. recvonly (Receive-Only)¶
This specifies that the tools should be started in receive-only mode where applicable.
Note that receive-only mode applies to the media only, not to any associated control protocol.
Example:
a=recvonly
6.7.2. sendrecv (Send-Receive)¶
Example:
a=sendrecv
This specifies that the tools should be started in send and receive mode.
This is necessary for interactive multimedia conferences with tools that default to receive-only mode.
6.7.3. sendonly (Send-Only)¶
Example:
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 in send-only mode and one in receive-only mode.
Note that send-only mode applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal.
6.7.4. inactive¶
Example:
a=inactive
This specifies that the tools should be started in inactive mode.
This is necessary for interactive multimedia conferences where users can put other users on hold.
No media is sent over an inactive media stream.
Note that an RTP-based system MUST still send RTCP (if RTCP is used), even if started in inactive mode.
6.8. orient (Orientation)¶
Syntax:
orient-value = portrait / landscape / seascape
portrait = %s"portrait"
landscape = %s"landscape"
seascape = %s"seascape"
; NOTE: These names are case-sensitive.
Example:
a=orient:portrait
Normally this is only used for a whiteboard or presentation tool.
It specifies the orientation of the workspace on the screen.
Permitted values are “portrait”, “landscape”, and “seascape” (upside-down landscape).
6.9. type (Conference Type)¶
Syntax:
type-value = conference-type
conference-type = broadcast / meeting / moderated / test / H332
broadcast = %s"broadcast"
meeting = %s"meeting"
moderated = %s"moderated"
test = %s"test"
H332 = %s"H332"
; NOTE: These names are case-sensitive.
Example:
a=type:moderated
This specifies the type of the multimedia conference.
6.10. charset (Character Set)¶
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.
The charset specified MUST be one of those registered in the IANA Character Sets registry (http://www.iana.org/assignments/character-sets)
Syntax:
charset-value = <defined in [RFC2978]>
For example, the ISO 8859-1 is specified with the following SDP attribute::
a=charset:ISO-8859-1
6.11. sdplang (SDP Language)¶
Syntax:
sdplang-value = Language-Tag
; Language-Tag defined in RFC 5646
Example:
a=sdplang:fr
In general, sending session descriptions consisting of multiple languages is discouraged.
The “a=sdplang:” attribute value must be a single language tag [RFC5646].
6.12. lang (Language)¶
The “a=lang:” attribute is supposed to be used for setting the initial language(s) used in the session.
Syntax:
lang-value = Language-Tag
; Language-Tag defined in RFC 5646
Example:
a=lang:de
6.13. 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 are allowed.
It is defined only for video media.
Syntax:
framerate-value = non-zero-int-or-real
Example:
a=framerate:60
6.14. quality¶
Syntax:
quality-value = zero-based-integer
Example:
a=quality:10
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:
Table 2: Encoding Quality Values 10 the best still-image quality the compression scheme can give. 5 the default behavior given no quality suggestion. 0 the worst still-image quality the codec designer thinks is still usable.
6.15. fmtp (Format Parameters)¶
Syntax:
fmtp-value = fmt SP format-specific-params
format-specific-params = byte-string
; Notes:
; - The format parameters are media type parameters and
; need to reflect their syntax.
Example:
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
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, semicolon separated, 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.
7. Security Considerations¶
SDP MUST NOT be used to convey keying material (e.g., using the “a=crypto:” attribute [RFC4568]) unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated.
8. IANA Considerations¶
One media type registration from [RFC4566] has been updated, as defined below.
Type name: application Subtype name: sdp Required parameters: None. Optional parameters: None.
9. SDP Grammar¶
SDP Syntax:
session-description = version-field
origin-field
session-name-field
[information-field]
[uri-field]
*email-field
*phone-field
[connection-field]
*bandwidth-field
1*time-description
[key-field]
*attribute-field
*media-description
通用:
version-field = %s"v" "=" 1*DIGIT CRLF ;this memo describes version 0
origin-field = %s"o" "=" username SP sess-id SP sess-version SP nettype SP addrtype SP unicast-address CRLF
session-name-field = %s"s" "=" text CRLF
information-field = %s"i" "=" text CRLF
uri-field = %s"u" "=" uri CRLF
email-field = %s"e" "=" email-address CRLF
phone-field = %s"p" "=" phone-number CRLF
connection-field = %s"c" "=" nettype SP addrtype SP connection-address CRLF
; a connection field must be present
; in every media description or at the session level
bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF
time相关:
time-description = time-field [repeat-description]
repeat-description = 1*repeat-field [zone-field]
time-field = %s"t" "=" start-time SP stop-time CRLF
repeat-field = %s"r" "=" repeat-interval SP typed-time
1*(SP typed-time) CRLF
zone-field = %s"z" "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time) CRLF
field:
key-field = %s"k" "=" key-type CRLF
attribute-field = %s"a" "=" attribute CRLF
media-description = media-field
[information-field]
*connection-field
*bandwidth-field
[key-field]
*attribute-field
media-field = %s"m" "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF
sub-rules:
; 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 5322 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 time in
; seconds since January 1, 1900 UTC.
; The representation is an unbounded
; length field containing at least
; 10 digits. Unlike some representations
; 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 = %s"d" / %s"h" / %s"m" / %s"s"
; NOTE: These units are case-sensitive.
; sub-rules of 'k='
key-type = %s"prompt" /
%s"clear:" text /
%s"base64:" base64 /
%s"uri:" uri
; NOTE: These names are case-sensitive.
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
; sub-rules of 'a='
attribute = (attribute-name ":" attribute-value) /
attribute-name
attribute-name = token
attribute-value = byte-string
att-field = attribute-name ; for backward compatibility
; sub-rules of 'm='
media = token
;typically "audio", "video", "text", "image"
;or "application"
fmt = token
;typically an RTP payload type for audio
;and video media
proto = token *("/" token)
;typically "RTP/AVP", "RTP/SAVP", "udp",
;or "RTP/SAVPF"
port = 1*DIGIT
generic sub-rules:
; 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 [ "/" numaddr ]
; IP4 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 = IP6-address [ "/" numaddr ]
; IP6 address starting with FF
numaddr = integer
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"
IP6-address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IP4-address
; 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.
;ISO 8859-1 requires "a=charset:ISO-8859-1"
;session-level attribute to be used
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR, or LF
non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters
token-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&"
/ "'" ; (single quote)
/ "*" / "+" / "-" / "." / "^" / "_"
/ "`" ; (Grave accent)
/ "{" / "|" / "}" / "~"
token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting
;characters ()<>
integer = POS-DIGIT *DIGIT
zero-based-integer = "0" / integer
non-zero-int-or-real = integer / non-zero-real
non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT
; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; external references:
ALPHA = <ALPHA definition from RFC 5234>
DIGIT = <DIGIT definition from RFC 5234>
CRLF = <CRLF definition from RFC 5234>
HEXDIG = <HEXDIG definition from RFC 5234>
SP = <SP definition from RFC 5234>
VCHAR = <VCHAR definition from RFC 5234>
URI-reference = <URI-reference definition from RFC 3986>
addr-spec = <addr-spec definition from RFC 5322>
10. Summary of Changes from RFC 4566¶
Identified now-obsolete items: “a=cat:” (Section 6.1), “a=keywds:” (Section 6.2), and “k=” (Section 5.12).
Expanded and clarified the specification of the “a=lang:” (Section 6.12) and “a=sdplang:” (Section 6.11) attributes.
Removed some references to SAP because it is no longer in widespread use.
Changed some examples to use IPv6 addresses, and added additional examples using IPv6.