rfc8866xml2.original.xml   rfc8866.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY __reference.RFC.2848 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
ibxml/reference.RFC.2848.xml">
<!ENTITY __reference.RFC.3108 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3108.xml">
<!ENTITY __reference.RFC.7195 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.7195.xml">
<!ENTITY __reference.RFC.4145 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.4145.xml">
<!ENTITY __reference.RFC.6135 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.6135.xml">
<!ENTITY __reference.RFC.1034 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ibxml/reference.RFC.1034.xml"> category="std"
<!ENTITY __reference.RFC.1035 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b number="8866"
ibxml/reference.RFC.1035.xml"> docName="draft-ietf-mmusic-rfc4566bis-37"
<!ENTITY __reference.RFC.2045 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b ipr="pre5378Trust200902"
ibxml/reference.RFC.2045.xml"> obsoletes="4566"
<!ENTITY __reference.RFC.2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b updates=""
ibxml/reference.RFC.2119.xml"> submissionType="IETF"
<!ENTITY __reference.RFC.2327 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b consensus="true"
ibxml/reference.RFC.2327.xml"> xml:lang="en"
<!ENTITY __reference.RFC.2365 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b tocInclude="true"
ibxml/reference.RFC.2365.xml"> symRefs="true"
<!ENTITY __reference.RFC.2974 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b sortRefs="true"
ibxml/reference.RFC.2974.xml"> version="3">
<!ENTITY __reference.RFC.2978 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.2978.xml"> <!-- xml2rfc v2v3 conversion 2.27.1 -->
<!ENTITY __reference.RFC.3261 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3261.xml">
<!ENTITY __reference.RFC.3264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3264.xml">
<!ENTITY __reference.RFC.3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3550.xml">
<!ENTITY __reference.RFC.3551 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3551.xml">
<!ENTITY __reference.RFC.3556 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3556.xml">
<!ENTITY __reference.RFC.3605 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3605.xml">
<!ENTITY __reference.RFC.3629 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3629.xml">
<!ENTITY __reference.RFC.3711 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3711.xml">
<!ENTITY __reference.RFC.3840 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3840.xml">
<!ENTITY __reference.RFC.3890 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3890.xml">
<!ENTITY __reference.RFC.3986 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.3986.xml">
<!ENTITY __reference.RFC.4566 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.4566.xml">
<!ENTITY __reference.RFC.4568 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.4568.xml">
<!ENTITY __reference.RFC.4855 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.4855.xml">
<!ENTITY __reference.RFC.5234 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.5234.xml">
<!ENTITY __reference.RFC.5322 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.5322.xml">
<!ENTITY __reference.RFC.5576 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.5576.xml">
<!ENTITY __reference.RFC.5646 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.5646.xml">
<!ENTITY __reference.RFC.5888 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.5888.xml">
<!ENTITY __reference.RFC.5890 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.5890.xml">
<!ENTITY __reference.RFC.5952 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.5952.xml">
<!ENTITY __reference.RFC.6466 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.6466.xml">
<!ENTITY __reference.RFC.6838 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.6838.xml">
<!ENTITY __reference.RFC.7230 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.7230.xml">
<!ENTITY __reference.RFC.7405 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.7405.xml">
<!ENTITY __reference.RFC.7656 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.7656.xml">
<!ENTITY __reference.RFC.7826 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.7826.xml">
<!ENTITY __reference.RFC.8126 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.8126.xml">
<!ENTITY __reference.RFC.8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.8174.xml">
<!ENTITY __reference.RFC.8445 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/b
ibxml/reference.RFC.8445.xml">
<!ENTITY __reference.I-D.ietf-mmusic-data-channel-sdpneg SYSTEM "http://xml.reso
urce.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-data-channel-sdpneg.xml">
<!ENTITY __reference.I-D.ietf-mmusic-sdp-mux-attributes SYSTEM "http://xml.resou
rce.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-mux-attributes.xml">
<!ENTITY __reference.I-D.ietf-mmusic-sdp-bundle-negotiation SYSTEM "http://xml.r
esource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-bundle-negotiation.
xml">
<!ENTITY __reference.I-D.ietf-mmusic-ice-sip-sdp SYSTEM "https://xml2rfc.tools.i
etf.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice-sip-sdp.xml">
<!ENTITY __reference.ISO.8859-1 SYSTEM "https://xml2rfc.tools.ietf.org/public/rf
c/bibxml2/reference.ISO.8859-1.1998.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc symrefs="yes"?>
<rfc category="std" docName="draft-ietf-mmusic-rfc4566bis-37"
ipr="pre5378Trust200902" obsoletes="4566">
<front> <front>
<title abbrev="SDP">SDP: Session Description Protocol</title> <title abbrev="SDP">SDP: Session Description Protocol</title>
<seriesInfo name="RFC" value="8866"/>
<author fullname="Ali Begen" initials="A." surname="Begen"> <author fullname="Ali Begen" initials="A." surname="Begen">
<organization>Networked Media</organization> <organization>Networked Media</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Konya</city>
<region/>
<code/>
<country>Turkey</country> <country>Turkey</country>
</postal> </postal>
<email>ali.begen@networked.media</email> <email>ali.begen@networked.media</email>
</address> </address>
</author> </author>
<author fullname="Paul Kyzivat" initials="P." surname="Kyzivat"> <author fullname="Paul Kyzivat" initials="P." surname="Kyzivat">
<organization></organization> <organization/>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<city></city>
<region/>
<code/>
<country>USA</country>
</postal> </postal>
<email>pkyzivat@alum.mit.edu</email> <email>pkyzivat@alum.mit.edu</email>
</address> </address>
</author> </author>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<author fullname="Colin Perkins" initials="C.S." surname="Perkins">
<organization abbrev="University of Glasgow">University of <organization abbrev="University of Glasgow">University of
Glasgow</organization> Glasgow</organization>
<address> <address>
<postal> <postal>
<street>School of Computing Science</street> <extaddr>School of Computing Science</extaddr>
<street>University of Glasgow</street>
<city>Glasgow</city> <city>Glasgow</city>
<code>G12 8QQ</code> <code>G12 8QQ</code>
<country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>csp@csperkins.org</email> <email>csp@csperkins.org</email>
</address> </address>
</author> </author>
<author fullname="Mark Handley" initials="M." surname="Handley">
<author fullname="Mark Handley" initials="M." surname="Handley">
<organization abbrev="UCL">University College London</organization> <organization abbrev="UCL">University College London</organization>
<address> <address>
<postal> <postal>
<street>Department of Computer Science</street> <street>Department of Computer Science</street>
<city>London</city> <city>London</city>
<code>WC1E 6BT</code> <code>WC1E 6BT</code>
<country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>M.Handley@cs.ucl.ac.uk</email> <email>M.Handley@cs.ucl.ac.uk</email>
</address> </address>
</author> </author>
<date month="January" year="2021"/>
<date day="9" month="August" year="2019"/> <keyword>Multimedia</keyword>
<keyword>conferencing</keyword>
<keyword>session setup</keyword>
<keyword>signaling</keyword>
<keyword>media</keyword>
<keyword>SIP</keyword>
<keyword>RTSP</keyword>
<keyword>voip</keyword>
<keyword>audio</keyword>
<keyword>video</keyword>
<keyword>streaming</keyword>
<abstract> <abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP is <t>This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of session intended for describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia session announcement, session invitation, and other forms of multimedia session
initiation. This document obsoletes RFC 4566.</t> initiation. This document obsoletes RFC 4566.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>When initiating multimedia teleconferences, voice-over-IP calls, <t>When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants.</t> metadata to the participants.</t>
<t>SDP provides a standard representation for such information, <t>SDP provides a standard representation for such information,
irrespective of how that information is transported. SDP is purely a irrespective of how that information is transported. SDP is purely a
format for session description -- it does not incorporate a transport format for session description -- it does not incorporate a transport
protocol, and it is intended to use different transport protocols as protocol, and it is intended to use different transport protocols as
appropriate, including the Session Announcement Protocol (SAP) <xref appropriate, including the Session Announcement Protocol (SAP) <xref targe
target="RFC2974"/>, Session Initiation Protocol (SIP) <xref t="RFC2974" format="default"/>, Session Initiation Protocol (SIP) <xref target="
target="RFC3261"/>, Real Time Streaming Protocol (RTSP) <xref RFC3261" format="default"/>, Real-Time Streaming Protocol (RTSP) <xref target="R
target="RFC7826"/>, electronic mail <xref target="RFC5322"/> using the MIM FC7826" format="default"/>, electronic mail <xref target="RFC5322" format="defau
E extensions <xref target="RFC2045"/>, lt"/> using the MIME extensions <xref target="RFC2045" format="default"/>,
and the Hypertext Transport Protocol (HTTP) <xref target="RFC7230"/>.</t> and the Hypertext Transport Protocol (HTTP) <xref target="RFC7230" format=
"default"/>.</t>
<t>SDP is intended to be general purpose so that it can be used in a <t>SDP is intended to be general purpose so that it can be used in a
wide range of network environments and applications. However, it is not wide range of network environments and applications. However, it is not
intended to support negotiation of session content or media encodings: intended to support negotiation of session content or media encodings:
this is viewed as outside the scope of session description.</t> this is viewed as outside the scope of session description.</t>
<t>This memo obsoletes <xref target="RFC4566" format="default"/>. The chan
<t>This memo obsoletes <xref target="RFC4566"/>. The changes relative to ges relative to
<xref target="RFC4566"/> are outlined in <xref target="changes"/> of this <xref target="RFC4566" format="default"/> are outlined in <xref target="ch
memo.</t> anges" format="default"/> of this memo.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Glossary of Terms"> <name>Glossary of Terms</name>
<t>The following terms are used in this document and have specific meaning <t>The following terms are used in this document and have specific meaning
within the context of this document.</t> within the context of this document.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Session Description:</dt>
<t hangText="Session Description:">A well-defined format for <dd>A well-defined format for
conveying sufficient information to discover and participate in a conveying sufficient information to discover and participate in a
multimedia session.</t> multimedia session.</dd>
</list> <dt>Media Description:</dt>
</t> <dd>A Media Description contains the information
needed for one party to establish an application-layer network protoco
<t><list style="hanging"> l
<t hangText="Media Description:">A Media Description contains the info
rmation
needed for one party to establish an application layer network protoco
l
connection to another party. It starts with an "m=" line and is termin ated connection to another party. It starts with an "m=" line and is termin ated
by either the next "m=" line or by the end of the session description. by either the next "m=" line or by the end of the session description.
</t> </dd>
</list> <dt>Session-Level Section:</dt>
</t> <dd>This refers to the parts that are not media descriptions, whereas th
e session description refers to the whole body that includes the session-level s
<t><list style="hanging"> ection and the media description(s).</dd>
<t hangText="Session-level Section:">This refers to the parts that are </dl>
not media descriptions, whereas the session description refers to the whole bod
y that includes the session-level section and the media description(s).</t>
</list>
</t>
<t>The terms "multimedia conference" and "multimedia session" are used <t>The terms "multimedia conference" and "multimedia session" are used
in this document as defined in <xref target="RFC7656"/>. The terms in this document as defined in <xref target="RFC7656" format="default"/>. The terms
"session" and "multimedia session" are used interchangeably in this "session" and "multimedia session" are used interchangeably in this
document.</t> document.</t>
<t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP 14 <xref RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
target="RFC2119"/> <xref "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
target="RFC8174"/> when, and only when, they be interpreted as
appear in all capitals, as shown here.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default" anchor="usage_examples">
<section title="Examples of SDP Usage"> <name>Examples of SDP Usage</name>
<section title="Session Initiation"> <section numbered="true" toc="default">
<t>The <xref target="RFC3261">Session Initiation Protocol (SIP)</xref> <name>Session Initiation</name>
<t>The <xref target="RFC3261" format="default">Session Initiation Protoc
ol (SIP)</xref>
is an application-layer control protocol for creating, modifying, and is an application-layer control protocol for creating, modifying, and
terminating sessions such as Internet multimedia conferences, Internet terminating sessions such as Internet multimedia conferences, Internet
telephone calls, and multimedia distribution. The SIP messages used to telephone calls, and multimedia distribution. The SIP messages used to
create sessions carry session descriptions that allow participants to create sessions carry session descriptions that allow participants to
agree on a set of compatible media types <xref target="RFC6838"/>. agree on a set of compatible media types <xref target="RFC6838" format=" default"/>.
These session descriptions These session descriptions
are commonly formatted using SDP. When used with SIP, the <xref are commonly formatted using SDP. When used with SIP, the <xref target="
target="RFC3264"> offer/answer model</xref> provides a limited RFC3264" format="default"> offer/answer model</xref> provides a limited
framework for negotiation using SDP.</t> framework for negotiation using SDP.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Streaming Media"> <name>Streaming Media</name>
<t>The <xref target="RFC7826">Real Time Streaming Protocol <t>The <xref target="RFC7826" format="default">Real-Time Streaming Proto
col
(RTSP)</xref>, is an application-level protocol for control over the (RTSP)</xref>, is an application-level protocol for control over the
delivery of data with real-time properties. RTSP provides an delivery of data with real-time properties. RTSP provides an
extensible framework to enable controlled, on-demand delivery of extensible framework to enable controlled, on-demand delivery of
real-time data, such as audio and video. An RTSP client and server real-time data, such as audio and video. An RTSP client and server
negotiate an appropriate set of parameters for media delivery, negotiate an appropriate set of parameters for media delivery,
partially using SDP syntax to describe those parameters.</t> partially using SDP syntax to describe those parameters.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Email and the World Wide Web"> <name>Email and the World Wide Web</name>
<t>Alternative means of conveying session descriptions include <t>Alternative means of conveying session descriptions include
electronic mail and the World Wide Web (WWW). For both email and WWW electronic mail and the World Wide Web (WWW). For both email and WWW
distribution, the media type "application/sdp" is used. This enables distribution, the media type "application/sdp" is used. This enables
the automatic launching of applications for participation in the the automatic launching of applications for participation in the
session from the WWW client or mail reader in a standard manner.</t> session from the WWW client or mail reader in a standard manner.</t>
<t>Note that descriptions of multicast sessions sent only via email <t>Note that descriptions of multicast sessions sent only via email
or the WWW do not have the property that the receiver of a session or the WWW do not have the property that the receiver of a session
description can necessarily receive the session because the multicast description can necessarily receive the session because the multicast
sessions may be restricted in scope, and access to the WWW server or sessions may be restricted in scope, and access to the WWW server or
reception of email is possible outside this scope.</t> reception of email is possibly outside this scope.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Multicast Session Announcement"> <name>Multicast Session Announcement</name>
<t>In order to assist the advertisement of multicast multimedia <t>In order to assist the advertisement of multicast multimedia
conferences and other multicast sessions, and to communicate the conferences and other multicast sessions, and to communicate the
relevant session setup information to prospective participants, a relevant session setup information to prospective participants, a
distributed session directory may be used. An instance of such a distributed session directory may be used. An instance of such a
session directory periodically sends packets containing a description session directory periodically sends packets containing a description
of the session to a well-known multicast group. These advertisements of the session to a well-known multicast group. These advertisements
are received by other session directories such that potential remote are received by other session directories such that potential remote
participants can use the session description to start the tools participants can use the session description to start the tools
required to participate in the session.</t> required to participate in the session.</t>
<t>One protocol used to implement such a distributed directory is the <t>One protocol used to implement such a distributed directory is the
<xref target="RFC2974">SAP</xref>. SDP provides the recommended <xref target="RFC2974" format="default">SAP</xref>. SDP provides the rec ommended
session description format for such session announcements.</t> session description format for such session announcements.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Requirements and Recommendations"> <name>Requirements and Recommendations</name>
<t>The purpose of SDP is to convey information about media streams in <t>The purpose of SDP is to convey information about media streams in
multimedia sessions to allow the recipients of a session description to multimedia sessions to allow the recipients of a session description to
participate in the session. SDP is primarily intended for use with participate in the session. SDP is primarily intended for use with
Internet protocols, although it is sufficiently general that it can descri be Internet protocols, although it is sufficiently general that it can descri be
multimedia conferences in other network environments. Media streams can multimedia conferences in other network environments. Media streams can
be many-to-many. Sessions need not be continually active.</t> be many-to-many. Sessions need not be continually active.</t>
<t>Thus far, multicast-based sessions on the Internet have differed from <t>Thus far, multicast-based sessions on the Internet have differed from
many other forms of conferencing in that anyone receiving the traffic many other forms of conferencing in that anyone receiving the traffic
can join the session (unless the session traffic is encrypted). In such can join the session (unless the session traffic is encrypted). In such
an environment, SDP serves two primary purposes. It is a means to an environment, SDP serves two primary purposes. It is a means to
communicate the existence of a session, and it is a means to convey communicate the existence of a session, and it is a means to convey
sufficient information to enable joining and participating in the sufficient information to enable joining and participating in the
session. In a unicast environment, only the latter purpose is likely to session. In a unicast environment, only the latter purpose is likely to
be relevant.</t> be relevant.</t>
<t>An SDP description includes the following:</t> <t>An SDP description includes the following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Session name and purpose</li>
<t>Session name and purpose</t> <li>Time(s) the session is active</li>
<li>The media comprising the session</li>
<t>Time(s) the session is active</t> <li>Information needed to receive those media (addresses, ports,
formats, etc.)</li>
<t>The media comprising the session</t> </ul>
<t>Information needed to receive those media (addresses, ports,
formats, etc.)</t>
</list></t>
<t>As resources necessary to participate in a session may be limited, <t>As resources necessary to participate in a session may be limited,
some additional information may also be desirable:</t> some additional information may also be desirable:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Information about the bandwidth to be used by the session</li>
<t>Information about the bandwidth to be used by the session</t> <li>Contact information for the person responsible for the
session</li>
<t>Contact information for the person responsible for the </ul>
session</t>
</list></t>
<t>In general, SDP must convey sufficient information to enable <t>In general, SDP must convey sufficient information to enable
applications to join a session (with the possible exception of applications to join a session (with the possible exception of
encryption keys) and to announce the resources to be used to any encryption keys) and to announce the resources to be used to any
non-participants that may need to know. (This latter feature is nonparticipants that may need to know. (This latter feature is
primarily useful when SDP is used with a multicast session announcement primarily useful when SDP is used with a multicast session announcement
protocol.)</t> protocol.)</t>
<section numbered="true" toc="default">
<section title="Media and Transport Information"> <name>Media and Transport Information</name>
<t>An SDP description includes the following media information:</t> <t>An SDP description includes the following media information:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The type of media (video, audio, etc.)</li>
<t>The type of media (video, audio, etc.)</t> <li>The media transport protocol (RTP/UDP/IP, H.320, etc.)</li>
<li>The format of the media (H.261 video, MPEG video, etc.)</li>
<t>The media transport protocol (RTP/UDP/IP, H.320, etc.)</t> </ul>
<t>The format of the media (H.261 video, MPEG video, etc.)</t>
</list></t>
<t>In addition to media format and transport protocol, SDP conveys <t>In addition to media format and transport protocol, SDP conveys
address and port details. For an IP multicast session, these address and port details. For an IP multicast session, these
comprise:</t> comprise:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The multicast group address for media</li>
<t>The multicast group address for media</t> <li>The transport port for media</li>
</ul>
<t>The transport port for media</t>
</list></t>
<t>This address and port are the destination address and destination <t>This address and port are the destination address and destination
port of the multicast stream, whether being sent, received, or port of the multicast stream, whether being sent, received, or
both.</t> both.</t>
<t>For unicast IP sessions, the following are conveyed:</t> <t>For unicast IP sessions, the following are conveyed:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The remote address for media</li>
<t>The remote address for media</t> <li>The remote transport port for media</li>
</ul>
<t>The remote transport port for media</t>
</list></t>
<t>The semantics of the address and port depend on context. <t>The semantics of the address and port depend on context.
Typically, this SHOULD be the remote address and remote port Typically, this <bcp14>SHOULD</bcp14> be the remote address and remote p ort
to which media is to be sent or received. to which media is to be sent or received.
Details may differ based on the network type, address type, Details may differ based on the network type, address type,
protocol and media specified, and whether the SDP is being distributed protocol, and media specified, and whether the SDP is being distributed
as an advertisement or negotiated in an offer/answer <xref target="RFC32 as an advertisement or negotiated in an offer/answer <xref target="RFC32
64"/> exchange. 64" format="default"/> exchange.
(E.g., Some address types or protocols may not have a notion of port.) (E.g., Some address types or protocols may not have a notion of port.)
Deviating from typical behavior should be done cautiously Deviating from typical behavior should be done cautiously
since this complicates implementations (including middleboxes that must since this complicates implementations (including middleboxes that must
parse the addresses to open Network Address Translation (NAT) or parse the addresses to open Network Address Translation (NAT) or
firewall pinholes).</t> firewall pinholes).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Timing Information"> <name>Timing Information</name>
<t>Sessions may be either bounded or unbounded in time. Whether or not <t>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 they are bounded, they may be only active at specific times. SDP can
convey:</t> convey:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>An arbitrary list of start and stop times bounding the
<t>An arbitrary list of start and stop times bounding the session</li>
session</t> <li>For each bound, repeat times such as "every Wednesday at 10am
for one hour"</li>
<t>For each bound, repeat times such as "every Wednesday at 10am </ul>
for one hour"</t>
</list></t>
<t>This timing information is globally consistent, irrespective of <t>This timing information is globally consistent, irrespective of
local time zone or daylight saving time (see <xref local time zone or daylight saving time (see <xref target="timing" forma
target="timing"/>).</t> t="default"/>).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Obtaining Further Information about a Session"> <name>Obtaining Further Information about a Session</name>
<t>A session description could convey enough information to decide <t>A session description could convey enough information to decide
whether or not to participate in a session. SDP may include additional whether or not to participate in a session. SDP may include additional
pointers in the form of Uniform Resource Identifiers (URIs) <xref target ="RFC3986"/> pointers in the form of Uniform Resource Identifiers (URIs) <xref target ="RFC3986" format="default"/>
for more information about the session. for more information about the session.
(Note that use of URIs to indicate remote resources is subject to (Note that use of URIs to indicate remote resources is subject to
the security considerations from <xref target="RFC3986"/>.) the security considerations from <xref target="RFC3986" format="default" />.)
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Internationalization"> <name>Internationalization</name>
<t>The SDP specification recommends the use of the ISO 10646 character <t>The SDP specification recommends the use of the ISO 10646 character
set in the UTF-8 encoding <xref target="RFC3629"/> to allow many set in the UTF-8 encoding <xref target="RFC3629" format="default"/> to a llow many
different languages to be represented. However, to assist in compact different languages to be represented. However, to assist in compact
representations, SDP also allows other character sets such as representations, SDP also allows other character sets such as
<xref target="ISO.8859-1.1998"/> to be used when desired. <xref target="ISO.8859-1.1998" format="default"/> to be used when desire d.
Internationalization only applies to Internationalization only applies to
free-text sub-fields (session name and background information), and not to free-text subfields (session name and background information), and not t o
SDP as a whole.</t> SDP as a whole.</t>
</section> </section>
</section> </section>
<section anchor="SDP-specification" title="SDP Specification"> <section anchor="SDP-specification" numbered="true" toc="default">
<name>SDP Specification</name>
<t>An SDP description is denoted by the media type "application/sdp" <t>An SDP description is denoted by the media type "application/sdp"
(See <xref target="iana"/>).</t> (See <xref target="iana" format="default"/>).</t>
<t>An SDP description is entirely textual. SDP field names and attribute <t>An SDP description is entirely textual. SDP field names and attribute
names use only the US-ASCII subset of UTF-8 <xref target="RFC3629"/>, names use only the US-ASCII subset of UTF-8 <xref target="RFC3629" format= "default"/>,
but textual fields and but textual fields and
attribute values MAY use the full ISO 10646 character set in UTF-8 attribute values <bcp14>MAY</bcp14> use the full ISO 10646 character set i n UTF-8
encoding, or some other character set defined by the "a=charset:" encoding, or some other character set defined by the "a=charset:"
attribute. Field and attribute values that use the full UTF-8 character attribute (<xref target="charset" format="default"/>).
Field and attribute values that use the full UTF-8 character
set are never directly compared, hence there is no requirement for UTF-8 set are never directly compared, hence there is no requirement for UTF-8
normalization. The textual form, as opposed to a binary encoding such as normalization. The textual form, as opposed to a binary encoding such as
ASN.1 or XDR, was chosen to enhance portability, to enable a variety of ASN.1 or XDR, was chosen to enhance portability, to enable a variety of
transports to be used, and to allow flexible, text-based toolkits to be transports to be used, and to allow flexible, text-based toolkits to be
used to generate and process session descriptions. However, since SDP used to generate and process session descriptions. However, since SDP
may be used in environments where the maximum permissible size of a may be used in environments where the maximum permissible size of a
session description is limited, the encoding is deliberately compact. session description is limited, the encoding is deliberately compact.
Also, since descriptions may be transported via very unreliable means Also, since descriptions may be transported via very unreliable means
or damaged by an intermediate caching server, the encoding was designed or damaged by an intermediate caching server, the encoding was designed
with strict order and formatting rules so that most errors would result with strict order and formatting rules so that most errors would result
skipping to change at line 430 skipping to change at line 321
ASN.1 or XDR, was chosen to enhance portability, to enable a variety of ASN.1 or XDR, was chosen to enhance portability, to enable a variety of
transports to be used, and to allow flexible, text-based toolkits to be transports to be used, and to allow flexible, text-based toolkits to be
used to generate and process session descriptions. However, since SDP used to generate and process session descriptions. However, since SDP
may be used in environments where the maximum permissible size of a may be used in environments where the maximum permissible size of a
session description is limited, the encoding is deliberately compact. session description is limited, the encoding is deliberately compact.
Also, since descriptions may be transported via very unreliable means Also, since descriptions may be transported via very unreliable means
or damaged by an intermediate caching server, the encoding was designed or damaged by an intermediate caching server, the encoding was designed
with strict order and formatting rules so that most errors would result with strict order and formatting rules so that most errors would result
in malformed session descriptions that could be detected easily and in malformed session descriptions that could be detected easily and
discarded.</t> discarded.</t>
<t>An SDP description consists of a number of lines of text of the <t>An SDP description consists of a number of lines of text of the
form:</t> form:</t>
<sourcecode name="" type=""><![CDATA[
<figure> <type>=<value>
<artwork> ]]></sourcecode>
&lt;type&gt;=&lt;value&gt;
</artwork>
</figure>
<t>where &lt;type&gt; is exactly one case-significant character and <t>where &lt;type&gt; is exactly one case-significant character and
&lt;value&gt; is structured text whose format depends on &lt;type&gt;. &lt;value&gt; is structured text whose format depends on &lt;type&gt;.
In general, &lt;value&gt; is either a number of sub-fields delimited by a In general, &lt;value&gt; is either a number of subfields delimited by a
single space character or a free format string, and is case-significant single space character or a free format string, and is case-significant
unless a specific field defines otherwise. Whitespace separators are not u sed unless a specific field defines otherwise. Whitespace separators are not u sed
on either side of the "=" sign, however, the value can contain a leading on either side of the "=" sign, however, the value can contain a leading
whitespace as part of its syntax, i.e., that whitespace is part of the val ue.</t> whitespace as part of its syntax, i.e., that whitespace is part of the val ue.</t>
<t>An SDP description <bcp14>MUST</bcp14> conform to the syntax defined in
<t>An SDP description MUST conform to the syntax defined in <xref target=" <xref target="abnf" format="default"/>.
abnf"/>. The following is an overview of the syntax.</t>
The following is an overview of the syntax:</t>
<t>An SDP description consists of a session-level section followed by <t>An SDP description consists of a session-level section followed by
zero or more media descriptions. The session-level section starts with a zero or more media descriptions. The session-level section starts with a
"v=" line and continues to the first media description (or the end of "v=" line and continues to the first media description (or the end of
the whole description, whichever comes first). Each media description the whole description, whichever comes first). Each media description
starts with an "m=" line and continues to the next media description starts with an "m=" line and continues to the next media description
or the end of the whole session description, whichever comes first. In or the end of the whole session description, whichever comes first. In
general, session-level values are the default for all media unless general, session-level values are the default for all media unless
overridden by an equivalent media-level value.</t> overridden by an equivalent media-level value.</t>
<t>Some lines in each description are required and some are optional, <t>Some lines in each description are required and some are optional,
but when present must appear in exactly the order given here. (The fixed o rder but when present, they must appear in exactly the order given here. (The f ixed order
greatly enhances error detection and allows for a simple parser). greatly enhances error detection and allows for a simple parser).
In the following overview optional items are marked with a "*".</t> In the following overview, optional items are marked with a "*".</t>
<sourcecode type=""><![CDATA[
<figure>
<artwork>
Session description Session description
v= (protocol version) v= (protocol version)
o= (originator and session identifier) o= (originator and session identifier)
s= (session name) s= (session name)
i=* (session information) i=* (session information)
u=* (URI of description) u=* (URI of description)
e=* (email address) e=* (email address)
p=* (phone number) p=* (phone number)
c=* (connection information -- not required if included in c=* (connection information -- not required if included in
all media descriptions) all media descriptions)
skipping to change at line 497 skipping to change at line 378
z=* (optional time zone offset line) z=* (optional time zone offset line)
Media description, if present Media description, if present
m= (media name and transport address) m= (media name and transport address)
i=* (media title) i=* (media title)
c=* (connection information -- optional if included at c=* (connection information -- optional if included at
session level) session level)
b=* (zero or more bandwidth information lines) b=* (zero or more bandwidth information lines)
k=* (obsolete) k=* (obsolete)
a=* (zero or more media attribute lines) a=* (zero or more media attribute lines)
</artwork> ]]></sourcecode>
</figure>
<t>The set of type letters is deliberately small and not intended to be <t>The set of type letters is deliberately small and not intended to be
extensible -- an SDP parser MUST completely ignore or reject any session extensible -- an SDP parser <bcp14>MUST</bcp14> completely ignore or rejec t any session
description that contains a type letter that it does not understand. The description that contains a type letter that it does not understand. The
attribute mechanism ("a=" described below) is the primary means for attribute mechanism ("a=", described in <xref target="attribspec" format=" default"/>) is the primary means for
extending SDP and tailoring it to particular applications or media. Some extending SDP and tailoring it to particular applications or media. Some
attributes (the ones listed in <xref target="attrs"/> of this memo) have attributes (the ones listed in <xref target="attrs" format="default"/>) ha ve
a defined meaning, but others may be added on a media- a defined meaning, but others may be added on a media-
or session-specific basis. (Attribute scopes in addition to media-specific or session-specific basis. (Attribute scopes in addition to media-specific
and session-specific may also be defined in extensions to this document. and session-specific scopes may also be defined in extensions to this docu
E.g., <xref target="RFC5576"/>, ment,
<xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.) e.g., <xref target="RFC5576" format="default"/> and <xref target="RFC8864"
An SDP parser MUST ignore any attribute it doesn't understand.</t> format="default"/>.)
An SDP parser <bcp14>MUST</bcp14> ignore any attribute it doesn't understa
nd.</t>
<t>An SDP description may contain URIs that reference external content <t>An SDP description may contain URIs that reference external content
in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in
some cases, making the session description non-self-contained.</t> some cases, making the session description non-self-contained.</t>
<t>The connection ("c=") information in the session-level section <t>The connection ("c=") information in the session-level section
applies to all the media descriptions of that session unless overridden by connection applies to all the media descriptions of that session unless overridden by connection
information in the media description. information in the media description.
For instance, in the example below, each audio media description behaves a s if For instance, in the example below, each audio media description behaves a s if
it were given a "c=IN IP4 198.51.100.1". it were given a "c=IN IP4 198.51.100.1".
</t> </t>
<t>An example SDP description is:</t> <t>An example SDP description is:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork><![CDATA[
v=0 v=0
o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1 o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1
s=Call to John Smith s=Call to John Smith
i=SDP Offer #1 i=SDP Offer #1
u=http://www.jdoe.example.com/home.html u=http://www.jdoe.example.com/home.html
e=Jane Doe <jane@jdoe.example.com> e=Jane Doe <jane@jdoe.example.com>
p=+1 617 555-6011 p=+1 617 555-6011
c=IN IP4 198.51.100.1 c=IN IP4 198.51.100.1
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=audio 49180 RTP/AVP 0 m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
c=IN IP6 2001:db8::2 c=IN IP6 2001:db8::2
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
]]></artwork> ]]></sourcecode>
</figure>
<t/>
<t>Text-containing fields such as the session-name-field and information-f ield are octet <t>Text-containing fields such as the session-name-field and information-f ield are octet
strings that may contain any octet with the exceptions of 0x00 (Nul), strings that may contain any octet with the exceptions of 0x00 (Nul),
0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence
CRLF (0x0d0a) is used to end a line, although parsers SHOULD be CRLF (0x0d0a) is used to end a line, although parsers <bcp14>SHOULD</bcp14 > be
tolerant and also accept lines terminated with a single newline tolerant and also accept lines terminated with a single newline
character. If the "a=charset" attribute is not present, these octet character. If the "a=charset:" attribute is not present, these octet
strings MUST be interpreted as containing ISO-10646 characters in UTF-8 strings <bcp14>MUST</bcp14> be interpreted as containing ISO-10646 charact
encoding. When the "a=charset" attribute is present the session-name-field ers in UTF-8
, encoding. When the "a=charset:" attribute is present the session-name-fiel
d,
information-field, and some attribute fields are interpreted according information-field, and some attribute fields are interpreted according
to the selected character set.</t> to the selected character set.</t>
<t>A session description can contain domain names in the "o=", "u=", <t>A session description can contain domain names in the "o=", "u=",
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply with "e=", "c=", and "a=" lines. Any domain name used in SDP <bcp14>MUST</bcp14
<xref target="RFC1034"/> and <xref target="RFC1035"/>. Internationalized > comply with
domain names (IDNs) MUST be represented using the ASCII Compatible <xref target="RFC1034" format="default"/> and <xref target="RFC1035" forma
Encoding (ACE) form defined in <xref target="RFC5890"/> and MUST NOT be t="default"/>. Internationalized
domain names (IDNs) <bcp14>MUST</bcp14> be represented using the ASCII Com
patible
Encoding (ACE) form defined in <xref target="RFC5890" format="default"/> a
nd <bcp14>MUST NOT</bcp14> be
directly represented in UTF-8 or any other encoding (this requirement is directly represented in UTF-8 or any other encoding (this requirement is
for compatibility with <xref target="RFC2327"/> and other early for compatibility with <xref target="RFC2327" format="default"/> and other early
SDP-related standards, which predate the development of SDP-related standards, which predate the development of
internationalized domain names).</t> internationalized domain names).</t>
<section numbered="true" toc="default">
<section title="Protocol Version (&quot;v=&quot;)"> <name>Protocol Version ("v=")</name>
<figure> <sourcecode name="" type="sdp"><![CDATA[
<artwork> v=0
v=0 ]]></sourcecode>
</artwork>
</figure>
<t>The "v=" line (version-field) gives the version of the Session Descri ption <t>The "v=" line (version-field) gives the version of the Session Descri ption
Protocol. This memo defines version 0. There is no minor version Protocol. This memo defines version 0. There is no minor version
number.</t> number.</t>
</section> </section>
<section anchor="origin-line" title="Origin (&quot;o=&quot;)"> <section anchor="origin" numbered="true" toc="default">
<figure> <name>Origin ("o=")</name>
<artwork> <sourcecode name="" type=""><![CDATA[
o=&lt;username&gt; &lt;sess-id&gt; &lt;sess-version&gt; &lt;nettype&gt; &lt;a o=<username> <sess-id> <sess-version> <nettype> <addrtype>
ddrtype&gt; <unicast-address>
&lt;unicast-address&gt; ]]></sourcecode>
</artwork>
</figure>
<t>The "o=" line (origin-field) gives the originator of the session (her username and <t>The "o=" line (origin-field) gives the originator of the session (her username and
the address of the user's host) plus a session identifier and version the address of the user's host) plus a session identifier and version
number:</t> number:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>&lt;username&gt;</dt>
<t hangText="&lt;username&gt;">is the user's login on the <dd>is the user's login on the
originating host, or it is "-" if the originating host does not originating host, or it is "-" if the originating host does not
support the concept of user IDs. The &lt;username&gt; MUST NOT support the concept of user IDs. The &lt;username&gt; <bcp14>MUST NO
contain spaces.</t> T</bcp14>
contain spaces.</dd>
<t hangText="&lt;sess-id&gt;">is a numeric string such that the <dt>&lt;sess-id&gt;</dt>
<dd>is a numeric string such that the
tuple of &lt;username&gt;, &lt;sess-id&gt;, &lt;nettype&gt;, tuple of &lt;username&gt;, &lt;sess-id&gt;, &lt;nettype&gt;,
&lt;addrtype&gt;, and &lt;unicast-address&gt; forms a globally &lt;addrtype&gt;, and &lt;unicast-address&gt; forms a globally
unique identifier for the session. The method of &lt;sess-id&gt; unique identifier for the session. The method of &lt;sess-id&gt;
allocation is up to the creating tool, but a timestamp, allocation is up to the creating tool, but a timestamp,
in seconds since January 1, 1900 UTC, is recommended in seconds since January 1, 1900 UTC, is recommended
to ensure uniqueness.</t> to ensure uniqueness.</dd>
<dt>&lt;sess-version&gt;</dt>
<t hangText="&lt;sess-version&gt;">is a version number for this <dd>is a version number for this
session description. Its usage is up to the creating tool, so long session description. Its usage is up to the creating tool, so long
as &lt;sess-version&gt; is increased when a modification is made as &lt;sess-version&gt; is increased when a modification is made
to the session description. Again, as with &lt;sess-id&gt; to the session description. Again, as with &lt;sess-id&gt;
it is RECOMMENDED that a timestamp be used.</t> it is <bcp14>RECOMMENDED</bcp14> that a timestamp be used.</dd>
<dt>&lt;nettype&gt;</dt>
<t hangText="&lt;nettype&gt;">is a text string giving the type of <dd>is a text string giving the type of
network. Initially "IN" is defined to have the meaning "Internet", network. Initially, "IN" is defined to have the meaning "Internet",
but other values MAY be registered in the future (see <xref but other values <bcp14>MAY</bcp14> be registered in the future (see
target="iana"/>).</t> <xref target="iana" format="default"/>).</dd>
<dt>&lt;addrtype&gt;</dt>
<t hangText="&lt;addrtype&gt;">is a text string giving the type of <dd>is a text string giving the type of
the address that follows. Initially "IP4" and "IP6" are defined, the address that follows. Initially, "IP4" and "IP6" are defined,
but other values MAY be registered in the future (see <xref but other values <bcp14>MAY</bcp14> be registered in the future (see
target="iana"/>).</t> <xref target="iana" format="default"/>).</dd>
<dt>&lt;unicast-address&gt;</dt>
<t hangText="&lt;unicast-address&gt;">is an address of the machine <dd>is an address of the machine
from which the session was created. For an address type of IP4, 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 this is either a fully qualified domain name of the machine or the
dotted-decimal representation of an IP version 4 address of the dotted-decimal representation of an IP version 4 address of the
machine. For an address type of IP6, this is either a fully machine. For an address type of "IP6", this is either a fully
qualified domain name of the machine or the address of the machine qualified domain name of the machine or the address of the machine
represented as specified in Section 4 of <xref target="RFC5952"/>. represented as specified in <xref target="RFC5952" section="4" secti
For both IP4 and IP6, the fully qualified domain name is the form th onFormat="of" format="default"/>.
at For both "IP4" and "IP6", the fully qualified domain name is the for
SHOULD be given unless this is unavailable, in which case a m that
globally unique address MAY be substituted.</t> <bcp14>SHOULD</bcp14> be given unless this is unavailable, in which
</list></t> case a
globally unique address <bcp14>MAY</bcp14> be substituted.</dd>
</dl>
<t>In general, the "o=" line serves as a globally unique identifier <t>In general, the "o=" line serves as a globally unique identifier
for this version of the session description, and the sub-fields for this version of the session description, and the subfields
excepting the version, taken together identify the session irrespective excepting the version, taken together identify the session irrespective
of any modifications.</t> of any modifications.</t>
<t>For privacy reasons, it is sometimes desirable to obfuscate the <t>For privacy reasons, it is sometimes desirable to obfuscate the
username and IP address of the session originator. If this is a username and IP address of the session originator. If this is a
concern, an arbitrary &lt;username&gt; and private concern, an arbitrary &lt;username&gt; and private
&lt;unicast-address&gt; MAY be chosen to populate the "o=" line, &lt;unicast-address&gt; <bcp14>MAY</bcp14> be chosen to populate the "o= " line,
provided that these are selected in a manner that does not affect the provided that these are selected in a manner that does not affect the
global uniqueness of the field.</t> global uniqueness of the field.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Session Name (&quot;s=&quot;)"> <name>Session Name ("s=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> s=<session name>
s=&lt;session name&gt; ]]></sourcecode>
</artwork>
</figure>
<t>The "s=" line (session-name-field) is the textual session name. <t>The "s=" line (session-name-field) is the textual session name.
There MUST be one and only one "s=" line per session description. There <bcp14>MUST</bcp14> be one and only one "s=" line per session desc
The "s=" line MUST NOT be empty. If a session has no meaningful name, ription.
then "s= " or "s=-" (i.e., a single space or dash as the session name) i The "s=" line <bcp14>MUST NOT</bcp14> be empty. If a session has no mean
s RECOMMENDED. ingful name,
If a session-level "a=charset" attribute is present, it specifies the ch then "s= " or "s=-" (i.e., a single space or dash as the session name) i
aracter set used s <bcp14>RECOMMENDED</bcp14>.
in the "s=" field. If a session-level "a=charset" attribute is not prese If a session-level "a=charset:" attribute is present, it specifies the c
nt, haracter set used
the "s=" field MUST contain ISO 10646 characters in UTF-8 encoding.</t> in the "s=" field. If a session-level "a=charset:" attribute is not pres
ent,
the "s=" field <bcp14>MUST</bcp14> contain ISO 10646 characters in UTF-8
encoding.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Session Information (&quot;i=&quot;)"> <name>Session Information ("i=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> i=<session information>
i=&lt;session information&gt; ]]></sourcecode>
</artwork>
</figure>
<t>The "i=" line (information-field) provides textual information about the session. There <t>The "i=" line (information-field) provides textual information about the session. There
can be at most one session-level "i=" line per session description, can be at most one session-level "i=" line per session description,
and at most one "i=" line in each media description. Unless a and at most one "i=" line in each media description. Unless a
media-level "i=" line is provided, the session-level "i=" line applies media-level "i=" line is provided, the session-level "i=" line applies
to that media description. If the "a=charset" attribute is present, it to that media description. If the "a=charset:" attribute is present, it
specifies the character set used in the "i=" line. If the "a=charset" specifies the character set used in the "i=" line. If the "a=charset:"
attribute is not present, the "i=" line MUST contain ISO 10646 attribute is not present, the "i=" line <bcp14>MUST</bcp14> contain ISO
10646
characters in UTF-8 encoding.</t> characters in UTF-8 encoding.</t>
<t>At most one "i=" line can be used for each media description. In medi a <t>At most one "i=" line can be used for each media description. In medi a
definitions, "i=" lines are primarily intended for labelling media definitions, "i=" lines are primarily intended for labeling media
streams. As such, they are most likely to be useful when a single streams. As such, they are most likely to be useful when a single
session has more than one distinct media stream of the same media session has more than one distinct media stream of the same media
type. An example would be two different whiteboards, one for slides type. An example would be two different whiteboards, one for slides
and one for feedback and questions.</t> and one for feedback and questions.</t>
<t>The "i=" line is intended to provide a free-form human-readable <t>The "i=" line is intended to provide a free-form human-readable
description of the session or the purpose of a media stream. It is not description of the session or the purpose of a media stream. It is not
suitable for parsing by automata.</t> suitable for parsing by automata.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="URI (&quot;u=&quot;)"> <name>URI ("u=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> u=<uri>
u=&lt;uri&gt; ]]></sourcecode>
</artwork>
</figure>
<t>The "u=" line (uri-field) provides a URI (Uniform Resource Identifier ) <t>The "u=" line (uri-field) provides a URI (Uniform Resource Identifier )
<xref target="RFC3986"/>. The URI should be a pointer to additional <xref target="RFC3986" format="default"/>. The URI should be a pointer t o additional
human readable information about the session. human readable information about the session.
This line is OPTIONAL. No more than one This line is <bcp14>OPTIONAL</bcp14>. No more than one
"u=" line is allowed per session description.</t> "u=" line is allowed per session description.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Email Address and Phone Number (&quot;e=&quot; and &quot;p <name>Email Address and Phone Number ("e=" and "p=")</name>
=&quot;)"> <sourcecode name="" type=""><![CDATA[
<figure> e=<email-address>
<artwork> p=<phone-number>
e=&lt;email-address&gt; ]]></sourcecode>
p=&lt;phone-number&gt;
</artwork>
</figure>
<t>The "e=" line (email-field) and "p=" line (phone-field) specify conta ct information for the person <t>The "e=" line (email-field) and "p=" line (phone-field) specify conta ct information for the person
responsible for the session. This is not necessarily the same person responsible for the session. This is not necessarily the same person
that created the session description.</t> that created the session description.</t>
<t>Inclusion of an email address or phone number is <bcp14>OPTIONAL</bcp
<t>Inclusion of an email address or phone number is OPTIONAL.</t> 14>.</t>
<t>If an email address or phone number is present, it <bcp14>MUST</bcp14
<t>If an email address or phone number is present, it MUST be > be
specified before the first media description. More than one email or pho ne specified before the first media description. More than one email or pho ne
line can be given for a session description.</t> line can be given for a session description.</t>
<t>Phone numbers <bcp14>SHOULD</bcp14> be given in the form of an intern
<t>Phone numbers SHOULD be given in the form of an international ational
public telecommunication number (see ITU-T Recommendation E.164 <xref ta public telecommunication number (see ITU-T Recommendation E.164 <xref ta
rget="E164"/>) rget="E164" format="default"/>)
preceded by a "+". Spaces and hyphens may be used to split up a phone-fi eld preceded by a "+". Spaces and hyphens may be used to split up a phone-fi eld
to aid readability if desired. For example:</t> to aid readability if desired. For example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
p=+1 617 555-6011 p=+1 617 555-6011
</artwork> ]]></sourcecode>
</figure> <t>Both email addresses and phone numbers can have an <bcp14>OPTIONAL</b
cp14> free
<t>Both email addresses and phone numbers can have an OPTIONAL free
text string associated with them, normally giving the name of the text string associated with them, normally giving the name of the
person who may be contacted. This MUST be enclosed in parentheses if person who may be contacted. This <bcp14>MUST</bcp14> be enclosed in par entheses if
it is present. For example:</t> it is present. For example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
</artwork> ]]></sourcecode>
</figure> <t>The alternative <xref target="RFC5322" format="default"/> name quotin
g convention is
<t>The alternative <xref target="RFC5322"/> name quoting convention is
also allowed for both email addresses and phone numbers. For also allowed for both email addresses and phone numbers. For
example:</t> example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure> e=Jane Doe <j.doe@example.com>
<artwork> ]]></sourcecode>
e=Jane Doe &lt;j.doe@example.com&gt; <t>The free text string <bcp14>SHOULD</bcp14> be in the ISO-10646 charac
</artwork> ter set with
</figure>
<t>The free text string SHOULD be in the ISO-10646 character set with
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if
the appropriate session-level "a=charset" attribute is set.</t> the appropriate session-level "a=charset:" attribute is set.</t>
</section> </section>
<section anchor="connection-information" title="Connection Information (&q <section anchor="connection-information" numbered="true" toc="default">
uot;c=&quot;)"> <name>Connection Information ("c=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> c=<nettype> <addrtype> <connection-address>
c=&lt;nettype&gt; &lt;addrtype&gt; &lt;connection-address&gt; ]]></sourcecode>
</artwork>
</figure>
<t>The "c=" line (connection-field) contains information necessary <t>The "c=" line (connection-field) contains information necessary
to establish a network connection.</t> to establish a network connection.</t>
<t>A session description <bcp14>MUST</bcp14> contain either at least one
<t>A session description MUST contain either at least one "c=" line in "c=" line in
each media description or a single "c=" line at the session level. It each media description or a single "c=" line at the session level. It
MAY contain a single session-level "c=" line and additional media-level "c=" <bcp14>MAY</bcp14> contain a single session-level "c=" line and addition al media-level "c="
line(s) per-media-description, in which case the media-level values line(s) per-media-description, in which case the media-level values
override the session-level settings for the respective media.</t> override the session-level settings for the respective media.</t>
<t>The first subfield (&lt;nettype&gt;) is the network type, which
<t>The first sub-field ("&lt;nettype&gt;") is the network type, which
is a text string giving the type of network. Initially, "IN" is is a text string giving the type of network. Initially, "IN" is
defined to have the meaning "Internet", but other values MAY be defined to have the meaning "Internet", but other values <bcp14>MAY</bcp
registered in the future (see <xref target="iana"/>).</t> 14> be
registered in the future (see <xref target="iana" format="default"/>).</
<t>The second sub-field ("&lt;addrtype&gt;") is the address type. This t>
<t>The second subfield (&lt;addrtype&gt;) is the address type. This
allows SDP to be used for sessions that are not IP based. This memo allows SDP to be used for sessions that are not IP based. This memo
only defines IP4 and IP6, but other values MAY be registered in the only defines "IP4" and "IP6", but other values <bcp14>MAY</bcp14> be reg
future (see <xref target="iana"/>).</t> istered in the
future (see <xref target="iana" format="default"/>).</t>
<t>The third sub-field ("&lt;connection-address&gt;") is the <t>The third subfield (&lt;connection-address&gt;) is the
connection address. Additional sub-fields MAY be added after the connection address. Additional subfields <bcp14>MAY</bcp14> be added aft
er the
connection address depending on the value of the &lt;addrtype&gt; connection address depending on the value of the &lt;addrtype&gt;
sub-field.</t> subfield.</t>
<t>When the &lt;addrtype&gt; is "IP4" or "IP6", the connection address i
<t>When the &lt;addrtype&gt; is IP4 or IP6, the connection address is s
defined as follows:</t> defined as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>If the session is multicast, the connection address will be an
<t>If the session is multicast, the connection address will be an
IP multicast group address. If the session is not multicast, then IP multicast group address. If the session is not multicast, then
the connection address contains the unicast IP address of the the connection address contains the unicast IP address of the
expected data source, data relay or data sink as determined by expected data source, data relay, or data sink as determined by
additional attribute-fields. It is not expected that unicast additional attribute-fields (<xref target="attribspec" format="defau
lt"/>).
It is not expected that unicast
addresses will be given in a session description that is addresses will be given in a session description that is
communicated by a multicast announcement, though this is not communicated by a multicast announcement, though this is not
prohibited.</t> prohibited.</li>
<li>Sessions using an "IP4" multicast connection address <bcp14>MUST</
<t>Sessions using an IP4 multicast connection address MUST also bcp14> also
have a time to live (TTL) value present in addition to the have a time to live (TTL) value present in addition to the
multicast address. The TTL and the address together define the multicast address. The TTL and the address together define the
scope with which multicast packets sent in this session will be scope with which multicast packets sent in this session will be
sent. TTL values MUST be in the range 0-255. Although the TTL MUST sent. TTL values <bcp14>MUST</bcp14> be in the range 0-255. Although the TTL <bcp14>MUST</bcp14>
be specified, its use to scope multicast traffic is deprecated; be specified, its use to scope multicast traffic is deprecated;
applications SHOULD use an administratively scoped address applications <bcp14>SHOULD</bcp14> use an administratively scoped ad
instead.</t> dress
</list></t> instead.</li>
</ul>
<t>The TTL for the session is appended to the address using a slash as <t>The TTL for the session is appended to the address using a slash as
a separator. An example is:</t> a separator. An example is:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
</artwork> ]]></sourcecode>
</figure> <t>"IP6" multicast does not use TTL scoping, and hence the TTL value
<bcp14>MUST NOT</bcp14> be present for "IP6" multicast. It is expected t
<t>IP6 multicast does not use TTL scoping, and hence the TTL value hat IPv6 scoped
MUST NOT be present for IP6 multicast. It is expected that IPv6 scoped
addresses will be used to limit the scope of multimedia addresses will be used to limit the scope of multimedia
conferences.</t> conferences.</t>
<t>Hierarchical or layered encoding schemes are data streams where the <t>Hierarchical or layered encoding schemes are data streams where the
encoding from a single media source is split into a number of layers. encoding from a single media source is split into a number of layers.
The receiver can choose the desired quality (and hence bandwidth) by The receiver can choose the desired quality (and hence bandwidth) by
only subscribing to a subset of these layers. Such layered encodings only subscribing to a subset of these layers. Such layered encodings
are normally transmitted in multiple multicast groups to allow are normally transmitted in multiple multicast groups to allow
multicast pruning. This technique keeps unwanted traffic from sites multicast pruning. This technique keeps unwanted traffic from sites
only requiring certain levels of the hierarchy. For applications only requiring certain levels of the hierarchy. For applications
requiring multiple multicast groups, we allow the following notation requiring multiple multicast groups, we allow the following notation
to be used for the connection address:</t> to be used for the connection address:</t>
<sourcecode name="" type=""><![CDATA[
<figure> <base multicast address>[/<ttl>]/<number of addresses>
<artwork> ]]></sourcecode>
&lt;base multicast address&gt;[/&lt;ttl&gt;]/&lt;number of addresses&gt;
</artwork>
</figure>
<t>If the number of addresses is not given, it is assumed to be one. <t>If the number of addresses is not given, it is assumed to be one.
Multicast addresses so assigned are contiguously allocated above the Multicast addresses so assigned are contiguously allocated above the
base address, so that, for example:</t> base address, so that, for example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
c=IN IP4 233.252.0.1/127/3 c=IN IP4 233.252.0.1/127/3
</artwork> ]]></sourcecode>
</figure>
<t>would state that addresses 233.252.0.1, 233.252.0.2, and <t>would state that addresses 233.252.0.1, 233.252.0.2, and
233.252.0.3 are to be used with a TTL of 127. This is semantically 233.252.0.3 are to be used with a TTL of 127. This is semantically
identical to including multiple "c=" lines in a media description:</t> identical to including multiple "c=" lines in a media description:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127 c=IN IP4 233.252.0.3/127
</artwork> ]]></sourcecode>
</figure>
<t>Similarly, an IPv6 example would be:</t> <t>Similarly, an IPv6 example would be:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
c=IN IP6 ff00::db8:0:101/3 c=IN IP6 ff00::db8:0:101/3
</artwork> ]]></sourcecode>
</figure>
<t>which is semantically equivalent to:</t> <t>which is semantically equivalent to:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
c=IN IP6 ff00::db8:0:101 c=IN IP6 ff00::db8:0:101
c=IN IP6 ff00::db8:0:102 c=IN IP6 ff00::db8:0:102
c=IN IP6 ff00::db8:0:103 c=IN IP6 ff00::db8:0:103
</artwork> ]]></sourcecode>
</figure> <t>(remember that the TTL subfield is not present in "IP6"
<t>(remembering that the TTL sub-field is not present in IP6
multicast).</t> multicast).</t>
<t>Multiple addresses or "c=" lines <bcp14>MAY</bcp14> be specified on a
<t>Multiple addresses or "c=" lines MAY be specified on a per media desc per media description
ription
basis only if they provide multicast addresses for different layers in basis only if they provide multicast addresses for different layers in
a hierarchical or layered encoding scheme. Multiple addresses or "c=" li nes a hierarchical or layered encoding scheme. Multiple addresses or "c=" li nes
MUST NOT be specified at session level.</t> <bcp14>MUST NOT</bcp14> be specified at session level.</t>
<t>The slash notation for multiple addresses described above <bcp14>MUST
<t>The slash notation for multiple addresses described above MUST NOT NOT</bcp14>
be used for IP unicast addresses.</t> be used for IP unicast addresses.</t>
</section> </section>
<section title="Bandwidth Information (&quot;b=&quot;)"> <section anchor="bandwidthInfo" numbered="true" toc="default">
<figure> <name>Bandwidth Information ("b=")</name>
<artwork> <sourcecode name="" type=""><![CDATA[
b=&lt;bwtype&gt;:&lt;bandwidth&gt; b=<bwtype>:<bandwidth>
</artwork> ]]></sourcecode>
</figure> <t>The <bcp14>OPTIONAL</bcp14> "b=" line (bandwidth-field) denotes the p
roposed bandwidth to be used by the
<t>The OPTIONAL "b=" line (bandwidth-field) denotes the proposed bandwid
th to be used by the
session or media description. The &lt;bwtype&gt; is an alphanumeric modi fier session or media description. The &lt;bwtype&gt; is an alphanumeric modi fier
giving the meaning of the &lt;bandwidth&gt; figure. Two values are that provides the meaning of the &lt;bandwidth&gt; number. Two values ar
defined in this specification, but other values MAY be registered in e
the future (see <xref target="iana"/> and <xref target="RFC3556"/>, defined in this specification, but other values <bcp14>MAY</bcp14> be re
<xref target="RFC3890"/>):</t> gistered in
the future (see <xref target="iana" format="default"/> and <xref target=
<t><list style="hanging"> "RFC3556" format="default"/>,
<t hangText="CT">If the bandwidth of a session is different from <xref target="RFC3890" format="default"/>):</t>
the bandwidth implicit from the scope, a "b=CT:..." line SHOULD be <dl newline="false" spacing="normal">
<dt>CT</dt>
<dd><t>If the bandwidth of a session is different from
the bandwidth implicit from the scope, a "b=CT:" line <bcp14>SHOULD<
/bcp14> be
supplied for the session giving the proposed upper limit to the supplied for the session giving the proposed upper limit to the
bandwidth used (the "conference total" bandwidth). Similarly, if bandwidth used (the "conference total" bandwidth). Similarly, if
the bandwidth of bundled media streams the bandwidth of bundled media streams
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> <xref target="RFC8843" format="default"/>
in an "m=" line is different in an "m=" line is different
from the implicit value from the scope, a "b=CT:..." line SHOULD from the implicit value from the scope, a "b=CT:" line <bcp14>SHOULD </bcp14>
be supplied in the media level. The primary purpose of this is to be supplied in the media level. The primary purpose of this is to
give an approximate idea as to whether two or more sessions (or give an approximate idea as to whether two or more sessions (or
bundled media streams) can coexist simultaneously. Note that CT bundled media streams) can coexist simultaneously. Note that a "b=CT :" line
gives a total bandwidth figure for all the media at all gives a total bandwidth figure for all the media at all
endpoints.</t> endpoints.</t>
<t>The Mux Category for "b=CT:" is NORMAL. This is discussed
<t hangText="">The Mux Category for CT is NORMAL. This is discussed in <xref target="RFC8859" format="default"/>.</t>
in <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>.</t> </dd>
<dt>AS</dt>
<t hangText="AS">The bandwidth is interpreted to be application <dd><t>The bandwidth is interpreted to be application
specific (it will be the application's concept of maximum specific (it will be the application's concept of maximum
bandwidth). Normally, this will coincide with what is set on the bandwidth). Normally, this will coincide with what is set on the
application's "maximum bandwidth" control if applicable. For application's "maximum bandwidth" control if applicable. For
RTP-based applications, AS gives the RTP "session bandwidth" as RTP-based applications, the "b=AS:" line gives the RTP "session band
defined in Section 6.2 of <xref target="RFC3550"/>. Note that AS width" as
defined in <xref target="RFC3550" section="6.2" sectionFormat="of" f
ormat="default"/>. Note that a "b=AS:" line
gives a bandwidth figure for a single media at a single endpoint, gives a bandwidth figure for a single media at a single endpoint,
although there may be many endpoints sending simultaneously.</t> although there may be many endpoints sending simultaneously.</t>
<t>The Mux Category for "b=AS:" is SUM. This is discussed
<t hangText="">The Mux Category for AS is SUM. This is discussed in <xref target="RFC8859" format="default"/>.</t>
in <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>.</t> </dd>
</list></t> </dl>
<t><xref target="RFC4566" format="default"/> defined an "X-" prefix for
<t><xref target="RFC4566"/> defined an "X-" prefix for &lt;bwtype&gt; na &lt;bwtype&gt; names.
mes.
This was intended for experimental purposes only. For example:</t> This was intended for experimental purposes only. For example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
b=X-YZ:128 b=X-YZ:128
</artwork> ]]></sourcecode>
</figure> <t>Use of the "X-" prefix is <bcp14>NOT RECOMMENDED</bcp14>. Instead new
(non "X-" prefix) &lt;bwtype&gt; names
<t>Use of the "X-" prefix is NOT RECOMMENDED. Instead new (non "X-" pref <bcp14>SHOULD</bcp14> be defined, and then <bcp14>MUST</bcp14> be regist
ix) &lt;bwtype&gt; names ered with IANA in the standard namespace. SDP parsers
SHOULD be defined, and then MUST be registered with IANA in the standard <bcp14>MUST</bcp14> ignore bandwidth-fields with unknown &lt;bwtype&gt;
namespace. SDP parsers names. The &lt;bwtype&gt; names <bcp14>MUST</bcp14> be
MUST ignore bandwidth-fields with unknown &lt;bwtype&gt; names. The &lt;
bwtype&gt; names MUST be
alphanumeric and, although no length limit is given, it is recommended alphanumeric and, although no length limit is given, it is recommended
that they be short.</t> that they be short.</t>
<t>The &lt;bandwidth&gt; is interpreted as kilobits per second by <t>The &lt;bandwidth&gt; is interpreted as kilobits per second by
default (including the transport and network-layer but not the link-laye r overhead). The definition of a new &lt;bwtype&gt; modifier MAY specify default (including the transport and network-layer, but not the link-lay er, overhead). The definition of a new &lt;bwtype&gt; modifier <bcp14>MAY</bcp14 > specify
that the bandwidth is to be interpreted in some alternative unit (the that the bandwidth is to be interpreted in some alternative unit (the
"CT" and "AS" modifiers defined in this memo use the default "CT" and "AS" modifiers defined in this memo use the default
units).</t> units).</t>
</section> </section>
<section anchor="timing" numbered="true" toc="default">
<section anchor="timing" title="Time Active (&quot;t=&quot;)"> <name>Time Active ("t=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> t=<start-time> <stop-time>
t=&lt;start-time&gt; &lt;stop-time&gt; ]]></sourcecode>
</artwork>
</figure>
<t>A "t=" line (time-field) begins a time description that specifies the start and stop times for a session. <t>A "t=" line (time-field) begins a time description that specifies the start and stop times for a session.
Multiple time descriptions MAY be used if a session is active at multipl e Multiple time descriptions <bcp14>MAY</bcp14> be used if a session is ac tive at multiple
irregularly spaced times; each additional time description specifies irregularly spaced times; each additional time description specifies
additional periods of time for which the session will be active. If the additional periods of time for which the session will be active. If the
session is active at regular repeat times, a repeat description, begun b session is active at regular repeat times, a repeat description,
y an "r=" line (see below) can be begun by an "r=" line (see <xref target="repeattime" format="default"/>)
can be
included following the time-field -- in which case the included following the time-field -- in which case the
time-field specifies the start and stop times of the entire repeat time-field specifies the start and stop times of the entire repeat
sequence.</t> sequence.</t>
<t>The following example specifies two active intervals:</t> <t>The following example specifies two active intervals:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC
t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC
</artwork> ]]></sourcecode>
</figure> <t>The first and second subfields of the time-field give the start and s
top times,
<t>The first and second sub-fields of the time-field give the start and
stop times,
respectively, for the session. These are the decimal respectively, for the session. These are the decimal
representation of time values in seconds representation of time values in seconds
since January 1, 1900 UTC. To convert these values to UNIX since January 1, 1900 UTC. To convert these values to Unix
time (UTC), subtract decimal 2208988800.</t> time (UTC), subtract decimal 2208988800.</t>
<t>Some time representations will <t>Some time representations will
wrap in the year 2036. Because SDP uses an arbitrary length wrap in the year 2036. Because SDP uses an arbitrary length
decimal representation, it does not have this issue. Implementations decimal representation, it does not have this issue. Implementations
of SDP need to be prepared to handle these larger values.</t> of SDP need to be prepared to handle these larger values.</t>
<t>If the &lt;stop-time&gt; is set to zero, then the session is not <t>If the &lt;stop-time&gt; is set to zero, then the session is not
bounded, though it will not become active until after the bounded, though it will not become active until after the
&lt;start-time&gt;. If the &lt;start-time&gt; is also zero, the &lt;start-time&gt;. If the &lt;start-time&gt; is also zero, the
session is regarded as permanent.</t> session is regarded as permanent.</t>
<t>User interfaces <bcp14>SHOULD</bcp14> strongly discourage the creatio
<t>User interfaces SHOULD strongly discourage the creation of n of
unbounded and permanent sessions as they give no information about unbounded and permanent sessions as they give no information about
when the session is actually going to terminate, and so make when the session is actually going to terminate, and so make
scheduling difficult.</t> scheduling difficult.</t>
<t>The general assumption may be made, when displaying unbounded <t>The general assumption may be made, when displaying unbounded
sessions that have not timed out to the user, that an unbounded sessions that have not timed out to the user, that an unbounded
session will only be active until half an hour from the current time session will only be active until half an hour from the current time
or the session start time, whichever is the later. If behavior other or the session start time, whichever is the later. If behavior other
than this is required, an end-time SHOULD be given and modified as than this is required, a &lt;stop-time&gt; <bcp14>SHOULD</bcp14> be give n and modified as
appropriate when new information becomes available about when the appropriate when new information becomes available about when the
session should really end.</t> session should really end.</t>
<t>Permanent sessions may be shown to the user as never being active <t>Permanent sessions may be shown to the user as never being active
unless there are associated repeat times that state precisely when the unless there are associated repeat times that state precisely when the
session will be active.</t> session will be active.</t>
</section> </section>
<section anchor="repeattime" numbered="true" toc="default">
<section title="Repeat Times (&quot;r=&quot;)"> <name>Repeat Times ("r=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> r=<repeat interval> <active duration> <offsets from start-time>
r=&lt;repeat interval&gt; &lt;active duration&gt; &lt;offsets from start-time ]]></sourcecode>
&gt;
</artwork>
</figure>
<t>An"r=" line (repeat-field) specifies repeat times for a session. <t>An"r=" line (repeat-field) specifies repeat times for a session.
If needed to express complex schedules, multiple repeat-fields may If needed to express complex schedules, multiple repeat-fields may
be included. For example, if a be included. For example, if a
session is active at 10am on Monday and 11am on Tuesday for one hour session is active at 10am on Monday and 11am on Tuesday for one hour
each week for three months, then the &lt;start-time&gt; in the each week for three months, then the &lt;start-time&gt; in the
corresponding "t=" line would be the representation of 10am on the corresponding "t=" line would be the representation of 10am on the
first Monday, the &lt;repeat interval&gt; would be 1 week, the first Monday, the &lt;repeat interval&gt; would be 1 week, the
&lt;active duration&gt; would be 1 hour, and the offsets would be zero &lt;active duration&gt; would be 1 hour, and the offsets would be zero
and 25 hours. The corresponding "t=" line stop time would be the and 25 hours. The corresponding "t=" line stop time would be the
representation of the end of the last session three months later. By representation of the end of the last session three months later. By
default, all sub-fields are in seconds, so the "r=" and "t=" lines might default, all subfields are in seconds, so the "r=" and "t=" lines might
be the following:</t> be the following:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC
; Tues 20-Mar-2018 12:00 UTC ; Tues 20-Mar-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
</artwork> ]]></sourcecode>
</figure>
<t>To make the description more compact, times may also be given in <t>To make the description more compact, times may also be given in
units of days, hours, or minutes. The syntax for these is a number units of days, hours, or minutes. The syntax for these is a number
immediately followed by a single case-sensitive character. Fractional immediately followed by a single case-sensitive character. Fractional
units are not allowed -- a smaller unit should be used instead. The units are not allowed -- a smaller unit should be used instead. The
following unit specification characters are allowed:</t> following unit specification characters are allowed:</t>
<table>
<figure> <name>Time Unit Specification Characters</name>
<artwork> <tbody>
d - days (86400 seconds) <tr>
h - hours (3600 seconds) <td>d</td>
m - minutes (60 seconds) <td>days (86400 seconds)</td>
s - seconds (allowed for completeness) </tr>
</artwork> <tr>
</figure> <td>h</td>
<td>hours (3600 seconds)</td>
</tr>
<tr>
<td>m</td>
<td>minutes (60 seconds)</td>
</tr>
<tr>
<td>s</td>
<td>seconds (allowed for completeness)</td>
</tr>
</tbody>
</table>
<t>Thus, the above repeat-field could also have been <t>Thus, the above repeat-field could also have been
written:</t> written:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
r=7d 1h 0 25h r=7d 1h 0 25h
</artwork> ]]></sourcecode>
</figure>
<t>Monthly and yearly repeats cannot be directly specified with a <t>Monthly and yearly repeats cannot be directly specified with a
single SDP repeat time; instead, separate time-descriptions should be us ed to single SDP repeat time; instead, separate time-descriptions should be us ed to
explicitly list the session times.</t> explicitly list the session times.</t>
</section> </section>
<section anchor="tzadj" numbered="true" toc="default">
<section title="Time Zone Adjustment (&quot;z=&quot;)"> <name>Time Zone Adjustment ("z=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> z=<adjustment time> <offset> <adjustment time> <offset> ....
z=&lt;adjustment time&gt; &lt;offset&gt; &lt;adjustment time&gt; &lt;offset&g ]]></sourcecode>
t; ....
</artwork>
</figure>
<t>A "z=" line (zone-field) is an optional modifier to the repeat-fields it immediately follows. <t>A "z=" line (zone-field) is an optional modifier to the repeat-fields it immediately follows.
It does not apply to any other fields.</t> It does not apply to any other fields.</t>
<t>To schedule a repeated session that spans a change from daylight <t>To schedule a repeated session that spans a change from daylight
saving time to standard time or vice versa, it is necessary to specify saving time to standard time or vice versa, it is necessary to specify
offsets from the base time. This is required because different time offsets from the base time. This is required because different time
zones change time at different times of day, different countries zones change time at different times of day, different countries
change to or from daylight saving time on different dates, and some change to or from daylight saving time on different dates, and some
countries do not have daylight saving time at all.</t> countries do not have daylight saving time at all.</t>
<t>Thus, in order to schedule a session that is at the same time <t>Thus, in order to schedule a session that is at the same time
winter and summer, it must be possible to specify unambiguously by winter and summer, it must be possible to specify unambiguously by
whose time zone a session is scheduled. To simplify this task for whose time zone a session is scheduled. To simplify this task for
receivers, we allow the sender to specify the time (represented as secon ds receivers, we allow the sender to specify the time (represented as secon ds
since January 1, 1900 UTC) that a time zone adjustment happens since January 1, 1900 UTC) that a time zone adjustment happens
and the offset from the time when the session and the offset from the time when the session
was first scheduled. The "z=" line allows the sender to specify a list was first scheduled. The "z=" line allows the sender to specify a list
of these adjustment times and offsets from the base time.</t> of these adjustment times and offsets from the base time.</t>
<t>An example might be the following:</t> <t>An example might be the following:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<artwork>
t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC
; Tues 18-Dec-2018 12:00 UTC ; Tues 18-Dec-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC,
; offset 1 hour, ; offset 1 hour,
; Sun 28-Oct-2018 2:00 UTC, ; Sun 28-Oct-2018 2:00 UTC,
; no offset ; no offset
</artwork> ]]></sourcecode>
</figure>
<t>This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, <t>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 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 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 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. Summer Time) the session's original time base is restored.
Adjustments are always relative to the specified start time -- they Adjustments are always relative to the specified start time -- they
are not cumulative.</t> are not cumulative.</t>
<t>If a session is likely to last several years, it is expected that <t>If a session is likely to last several years, it is expected that
the session description will be modified periodically rather than the session description will be modified periodically rather than
transmit several years' worth of adjustments in one session transmit several years' worth of adjustments in one session
description.</t> description.</t>
</section> </section>
<section anchor="key-field" numbered="true" toc="default">
<section title="Encryption Keys (&quot;k=&quot;)"> <name>Encryption Keys ("k=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> k=<method>
k=&lt;method&gt; k=<method>:<encryption key>
k=&lt;method&gt;:&lt;encryption key&gt; ]]></sourcecode>
</artwork> <t>The "k=" line (key-field) is obsolete and <bcp14>MUST NOT</bcp14> be
</figure> used. It is included in
<t>The "k=" line (key-field) is obsolete and MUST NOT be used. It is inc this document for legacy reasons. One <bcp14>MUST NOT</bcp14> includ
luded in e a "k=" line
this document for legacy reasons. One MUST NOT include a "k=" line in an SDP, and <bcp14>MUST</bcp14> discard it if it is received in a
in an SDP, and MUST discard it if it is received in an SDP. </t> n SDP. </t>
</section> </section>
<section anchor="attribspec" numbered="true" toc="default">
<section title="Attributes (&quot;a=&quot;)"> <name>Attributes ("a=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> a=<attribute-name>
a=&lt;attribute&gt; a=<attribute-name>:<attribute-value>
a=&lt;attribute&gt;:&lt;value&gt; ]]></sourcecode>
</artwork>
</figure>
<t>Attributes are the primary means for extending SDP. Attributes may <t>Attributes are the primary means for extending SDP. Attributes may
be defined to be used as "session-level" attributes, "media-level" be defined to be used as session-level attributes, media-level
attributes, or both. (Attribute scopes in addition to media- and attributes, or both. (Attribute scopes in addition to media-level and
session- level may also be defined in extensions to this document. session-level scopes may also be defined in extensions to this document,
E.g., <xref target="RFC5576"/>, e.g., <xref target="RFC5576" format="default"/> and
<xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.)</t> <xref target="RFC8864" format="default"/>.)</t>
<t>A media description may contain any number of "a=" lines (attribute-f ields) <t>A media description may contain any number of "a=" lines (attribute-f ields)
that are media description specific. These are referred to as "media-lev el" that are media description specific. These are referred to as media-leve l
attributes and add information about the media description. Attribute-fi elds attributes and add information about the media description. Attribute-fi elds
can also be added before the first media description; these "session-lev el" can also be added before the first media description; these session-leve l
attributes convey additional information that applies to the session attributes convey additional information that applies to the session
as a whole rather than to individual media descriptions.</t> as a whole rather than to individual media descriptions.</t>
<t>Attribute-fields may be of two forms:</t> <t>Attribute-fields may be of two forms:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>A property attribute is simply of the form "a=&lt;attribute-name&g
<t>A property attribute is simply of the form "a=&lt;attribute&gt;". t;".
These are binary attributes, and the presence of the attribute These are binary attributes, and the presence of the attribute
conveys that the attribute is a property of the session. An conveys that the attribute is a property of the session. An
example might be "a=recvonly".</t> example might be "a=recvonly".</li>
<li>A value attribute is of the form
<t>A value attribute is of the form "a=&lt;attribute-name&gt;:&lt;attribute-value&gt;". For example, a w
"a=&lt;attribute&gt;:&lt;value&gt;". For example, a whiteboard hiteboard
could have the value attribute "a=orient:landscape"</t> could have the value attribute "a=orient:landscape".</li>
</list></t> </ul>
<t>Attribute interpretation depends on the media tool being invoked. <t>Attribute interpretation depends on the media tool being invoked.
Thus receivers of session descriptions should be configurable in their Thus receivers of session descriptions should be configurable in their
interpretation of session descriptions in general and of attributes in interpretation of session descriptions in general and of attributes in
particular.</t> particular.</t>
<t>Attribute names <bcp14>MUST</bcp14> use the US-ASCII subset of
<t>Attribute names MUST use the US-ASCII subset of
ISO-10646/UTF-8.</t> ISO-10646/UTF-8.</t>
<t>Attribute values are octet strings, and <bcp14>MAY</bcp14> use any oc
<t>Attribute values are octet strings, and MAY use any octet value tet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
values are to be interpreted as in ISO-10646 character set with UTF-8 values are to be interpreted as in ISO-10646 character set with UTF-8
encoding. Unlike other text fields, attribute values are NOT normally encoding. Unlike other text fields, attribute values are NOT normally
affected by the "charset" attribute as this would make comparisons affected by the "a=charset:" attribute as this would make comparisons
against known values problematic. However, when an attribute is against known values problematic. However, when an attribute is
defined, it can be defined to be charset dependent, in which case its defined, it can be defined to be charset dependent, in which case its
value should be interpreted in the session charset rather than in value should be interpreted in the session charset rather than in
ISO-10646.</t> ISO-10646.</t>
<t>Attributes <bcp14>MUST</bcp14> be registered with IANA (see <xref tar
<t>Attributes MUST be registered with IANA (see <xref get="iana" format="default"/>).
target="iana"/>). If an attribute is received that is not understood, If an attribute is received that is not understood,
it MUST be ignored by the receiver.</t> it <bcp14>MUST</bcp14> be ignored by the receiver.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Media Descriptions (&quot;m=&quot;)"> <name>Media Descriptions ("m=")</name>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork> m=<media> <port> <proto> <fmt> ...
m=&lt;media&gt; &lt;port&gt; &lt;proto&gt; &lt;fmt&gt; ... ]]></sourcecode>
</artwork>
</figure>
<t>A session description may contain a number of media descriptions. <t>A session description may contain a number of media descriptions.
Each media description starts with an "m=" line (media-field) and is ter minated by Each media description starts with an "m=" line (media-field) and is ter minated by
either the next "m=" line or by the end of the session description. A either the next "m=" line or by the end of the session description. A
media-field has several sub-fields:</t> media-field has several subfields:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>&lt;media&gt;</dt>
<t hangText="&lt;media&gt;">is the media type. This document defines <dd>is the media type. This document defines the values "audio", "vide
the values "audio", "video", "text", "application", and "message". This list is o", "text", "application", and "message". This list is extended by other memos a
extended by other memos and may be further extended by additional memos registe nd may be further extended by additional memos registering media types in the fu
ring media types in the future (see <xref target="iana"/>). For example, <xref t ture (see <xref target="iana" format="default"/>). For example, <xref target="RF
arget="RFC6466"/> defined the "image" media type.</t> C6466" format="default"/> defined the "image" media type.</dd>
<dt>&lt;port&gt;</dt>
<t hangText="&lt;port&gt;">is the transport port to which the <dd><t>is the transport port to which the
media stream is sent. The meaning of the transport port depends on media stream is sent. The meaning of the transport port depends on
the network being used as specified in the relevant "c=" line, and the network being used as specified in the relevant "c=" line, and
on the transport protocol defined in the &lt;proto&gt; sub-field on the transport protocol defined in the &lt;proto&gt; subfield
of the media-field. Other ports used by the media application of the media-field. Other ports used by the media application
(such as the RTP Control Protocol (RTCP) port <xref (such as the RTP Control Protocol (RTCP) port <xref target="RFC3550"
target="RFC3550"/>) MAY be derived algorithmically from the base format="default"/>) <bcp14>MAY</bcp14> be derived algorithmically from the base
media port or MAY be specified in a separate attribute (for media port or <bcp14>MAY</bcp14> be specified in a separate attribut
example, "a=rtcp:" as defined in <xref target="RFC3605"/>).</t> e (for
example, the "a=rtcp:" attribute as defined in <xref target="RFC3605
" format="default"/>).</t>
<t>If non-contiguous ports are used or if they don't follow the <t>If noncontiguous ports are used or if they don't follow the
parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:"
attribute MUST be used. Applications that are requested to send attribute <bcp14>MUST</bcp14> be used. Applications that are request
media to a &lt;port&gt; that is odd and where the "a=rtcp:" is ed to send
present MUST NOT subtract 1 from the RTP port: that is, they MUST media to a &lt;port&gt; that is odd and where the "a=rtcp:" attribut
e is
present <bcp14>MUST NOT</bcp14> subtract 1 from the RTP port: that i
s, they <bcp14>MUST</bcp14>
send the RTP to the port indicated in &lt;port&gt; and send the send the RTP to the port indicated in &lt;port&gt; and send the
RTCP to the port indicated in the "a=rtcp" attribute.</t> RTCP to the port indicated in the "a=rtcp:" attribute.</t>
<t>For applications where hierarchically encoded streams are being <t>For applications where hierarchically encoded streams are being
sent to a unicast address, it may be necessary to specify multiple sent to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that transport ports. This is done using a similar notation to that
used for IP multicast addresses in the "c=" line: <figure> used for IP multicast addresses in the "c=" line: </t>
<artwork> <sourcecode name="" type=""><![CDATA[
m=&lt;media&gt; &lt;port&gt;/&lt;number of ports&gt; &lt;proto&gt; &lt;fm m=<media> <port>/<number of ports> <proto> <fmt> ...
t&gt; ... ]]></sourcecode>
</artwork>
</figure></t>
<t>In such a case, the ports used depend on the transport <t>In such a case, the ports used depend on the transport
protocol. For RTP, the default is that only the even-numbered protocol. For RTP, the default is that only the even-numbered
ports are used for data with the corresponding one-higher odd ports are used for data with the corresponding one-higher odd
ports used for the RTCP belonging to the RTP session, and the ports used for the RTCP belonging to the RTP session, and the
&lt;number of ports&gt; denoting the number of RTP sessions. For &lt;number of ports&gt; denoting the number of RTP sessions. For
example: <figure> example: </t>
<artwork> <sourcecode name="" type="sdp"><![CDATA[
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
</artwork> ]]></sourcecode>
</figure></t> <t>would specify that ports 49170 and 49171 form one RTP/RTCP pair,
<t>would specify that ports 49170 and 49171 form one RTP/RTCP pair
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below).</t> transport protocol, and 31 is the format (see the description of &lt
;fmt&gt; below).</t>
<t>This document does not include a mechanism for declaring hierarchi <t>This document does not include a mechanism for declaring hierarchic
cally ally
encoded streams using non-contiguous ports. encoded streams using noncontiguous ports.
(There is currently no attribute defined that can accomplish this. (There is currently no attribute defined that can accomplish this.
The "a=rtcp:" defined in <xref target="RFC3605"/> does not handle hie The "a=rtcp:" attribute defined in <xref target="RFC3605" format="def
rarchical encoding.) ault"/> does not handle hierarchical encoding.)
If a need arises to declare non-contiguous ports then it will be nece If a need arises to declare noncontiguous ports then it will be neces
ssary to define a new attribute to do so.</t> sary to define a new attribute to do so.</t>
<t>If multiple addresses are specified in the "c=" line and <t>If multiple addresses are specified in the "c=" line and
multiple ports are specified in the "m=" line, a one-to-one multiple ports are specified in the "m=" line, a one-to-one
mapping from port to the corresponding address is implied. For mapping from port to the corresponding address is implied. For
example: example: </t>
<figure> <sourcecode name="" type="sdp"><![CDATA[
<artwork>
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
c=IN IP4 233.252.0.1/127/2 c=IN IP4 233.252.0.1/127/2
</artwork> ]]></sourcecode>
</figure></t> <t>would imply that address 233.252.0.1 is used with ports 49170
<t>would imply that address 233.252.0.1 is used with ports 49170
and 49171, and address 233.252.0.2 is used with ports 49172 and and 49171, and address 233.252.0.2 is used with ports 49172 and
49173.</t> 49173.</t>
<t>The mapping is similar if multiple addresses are specified using multiple "c=" lines. <t>The mapping is similar if multiple addresses are specified using multiple "c=" lines.
For example: For example: </t>
<figure> <sourcecode name="" type="sdp"><![CDATA[
<artwork>
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
c=IN IP6 ff00::db8:0:101 c=IN IP6 ff00::db8:0:101
c=IN IP6 ff00::db8:0:102 c=IN IP6 ff00::db8:0:102
</artwork> ]]></sourcecode>
</figure></t> <t>would imply that address ff00::db8:0:101 is used with ports 49170
<t>would imply that address ff00::db8:0:101 is used with ports 49170
and 49171, and address ff00::db8:0:102 is used with ports 49172 and and 49171, and address ff00::db8:0:102 is used with ports 49172 and
49173.</t> 49173.</t>
<t>This document gives no meaning to assigning the same media address
<t>This document gives no meaning to assigning the same media addres to
s to multiple media descriptions.
multiple media-descriptions. Doing so does not implicitly group those media descriptions in any wa
Doing so does not implicitly group those media-descriptions in any wa y.
y. An explicit grouping framework (for example, <xref target="RFC5888" f
An explicit grouping framework (for example, <xref target="RFC5888"/> ormat="default"/>)
)
should instead be used to express the intended semantics. should instead be used to express the intended semantics.
For instance, see <xref target="I-D.ietf-mmusic-sdp-bundle-negotiatio For instance, see <xref target="RFC8843" format="default"/>.</t>
n"/>.</t> </dd>
<dt>&lt;proto&gt;</dt>
<t hangText="&lt;proto&gt;">is the transport protocol. The meaning <dd>
of the transport protocol is dependent on the address type sub-field <t>is the transport protocol. The meaning
in the relevant "c=" line. Thus a "c=" line with an address type of of the transport protocol is dependent on the address type subfield
IP4 indicates that in the relevant "c=" line. Thus a "c=" line with an address type of
"IP4" indicates that
the transport protocol runs over IPv4. The following transport the transport protocol runs over IPv4. The following transport
protocols are defined, but may be extended through registration of protocols are defined, but may be extended through registration of
new protocols with IANA (see <xref target="iana"/>): <list new protocols with IANA (see <xref target="iana" format="default"/>)
style="symbols"> : </t>
<t>udp: denotes that the data is transported directly in UDP <ul spacing="normal">
with no additional framing.</t> <li>udp: denotes that the data is transported directly in UDP
with no additional framing.</li>
<t>RTP/AVP: denotes <xref target="RFC3550">RTP</xref> used <li>RTP/AVP: denotes <xref target="RFC3550" format="default">RTP</
under the <xref target="RFC3551">RTP Profile for Audio and xref> used
under the <xref target="RFC3551" format="default">RTP Profile fo
r Audio and
Video Conferences with Minimal Control</xref> running over Video Conferences with Minimal Control</xref> running over
UDP.</t> UDP.</li>
<li>RTP/SAVP: denotes the <xref target="RFC3711" format="default">
<t>RTP/SAVP: denotes the <xref target="RFC3711">Secure Secure
Real-time Transport Protocol</xref> running over UDP.</t> Real-time Transport Protocol</xref> running over UDP.</li>
</list></t> <li>RTP/SAVPF: denotes SRTP with the <xref target="RFC5124" format
="default">
<t>The main reason to specify the transport protocol in addition Extended SRTP Profile for RTCP-Based Feedback</xref> running ove
r UDP.</li>
</ul>
<t>The main reason to specify the transport protocol in addition
to the media format is that the same standard media formats may be to the media format is that the same standard media formats may be
carried over different transport protocols even when the network carried over different transport protocols even when the network
protocol is the same -- a historical example is VAT (MBone's popular multimedia audio tool) Pulse Code protocol is the same -- a historical example is vat (MBone's popular multimedia audio tool) Pulse Code
Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP
PCM audio. In addition, relays and monitoring tools that are PCM audio. In addition, relays and monitoring tools that are
transport-protocol-specific but format-independent are transport-protocol-specific but format-independent are
possible.</t> possible.</t>
</dd>
<t hangText="&lt;fmt&gt;">is a media format description. The <dt>&lt;fmt&gt;</dt>
fourth and any subsequent sub-fields describe the format of the <dd><t>is a media format description. The
fourth and any subsequent subfields describe the format of the
media. The interpretation of the media format depends on the value media. The interpretation of the media format depends on the value
of the &lt;proto&gt; sub-field.</t> of the &lt;proto&gt; subfield.</t>
<t>If the &lt;proto&gt; sub-field is "RTP/AVP" or "RTP/SAVP" the <t>If the &lt;proto&gt; subfield is "RTP/AVP" or "RTP/SAVP", the
&lt;fmt&gt; sub-fields contain RTP payload type numbers. When a &lt;fmt&gt; subfields contain RTP payload type numbers. When a list
list of payload type numbers is given, this implies that all of of
these payload formats MAY be used in the session, but the first of payload type numbers is given, this implies that all of these
these formats SHOULD be used as the default format for the payload formats MAY be used in the session, and these payload
session. For dynamic payload type assignments the "a=rtpmap:" formats are listed in order of preference, with the first format listed
attribute (see <xref target="attrs"/>) SHOULD be used to map from being preferred. When multiple payload formats are listed,
an RTP payload type number to a media encoding name that the first acceptable payload format
identifies the payload format. The "a=fmtp:" attribute MAY be used from the beginning of the list <bcp14>SHOULD</bcp14> be used for the session.
to specify format parameters (see <xref target="attrs"/>).</t>
<t>If the &lt;proto&gt; sub-field is "udp" the &lt;fmt&gt; For dynamic payload type assignments, the "a=rtpmap:"
sub-fields MUST reference a media type describing the format under attribute (see <xref target="rtpmap" format="default"/>) <bcp14>SHOU
LD</bcp14> be used to map from
an RTP payload type number to a media encoding name that
identifies the payload format. The "a=fmtp:" attribute <bcp14>MAY</b
cp14> be used
to specify format parameters (see <xref target="fmtp" format="defaul
t"/>).</t>
<t>If the &lt;proto&gt; subfield is "udp", the &lt;fmt&gt;
subfields <bcp14>MUST</bcp14> reference a media type describing the
format under
the "audio", "video", "text", "application", or "message" the "audio", "video", "text", "application", or "message"
top-level media types. The media type registration SHOULD define top-level media types. The media type registration <bcp14>SHOULD</bc p14> define
the packet format for use with UDP transport.</t> the packet format for use with UDP transport.</t>
<t>For media using other transport protocols, the &lt;fmt&gt;
<t>For media using other transport protocols, the &lt;fmt&gt; subfield is protocol specific. Rules for interpretation of the
sub-field is protocol specific. Rules for interpretation of the &lt;fmt&gt; subfield <bcp14>MUST</bcp14> be defined when registering
&lt;fmt&gt; sub-field MUST be defined when registering new new
protocols (see Section 8.2.2).</t> protocols (see <xref target="MediaTypes"/>).</t>
<t><xref target="RFC4855" section="3" sectionFormat="of" format="defau
<t>Section 3 of <xref target="RFC4855"/> states that the payload lt"/> states that the payload
format (encoding) names defined in the RTP Profile are commonly format (encoding) names defined in the RTP profile are commonly
shown in upper case, while media subtype names are commonly shown shown in upper case, while media subtype names are commonly shown
in lower case. It also states that both of these names are in lower case. It also states that both of these names are
case-insensitive in both places, similar to parameter names which case-insensitive in both places, similar to parameter names which
are case-insensitive both in media type strings and in the default are case-insensitive both in media type strings and in the default
mapping to the SDP a=fmtp attribute.</t> mapping to the SDP "a=fmtp:" attribute.</t>
</list></t> </dd>
</dl>
</section> </section>
</section> </section>
<section anchor="attrs" numbered="true" toc="default">
<section anchor="attrs" title="SDP Attributes"> <name>SDP Attributes</name>
<t>The following attributes are defined. Since application writers may <t>The following attributes are defined. Since application writers may
add new attributes as they are required, this list is not exhaustive. add new attributes as they are required, this list is not exhaustive.
Registration procedures for new attributes are defined in Section Registration procedures for new attributes are defined in <xref target="At
8.2.4. Syntax is provided using ABNF <xref target="RFC7405"/> with some of tributeNames" format="default"/>.
the rules defined further in Section 9.</t> Syntax is provided using ABNF <xref target="RFC7405" format="default"/>
with some of the rules defined further in <xref target="abnf" format="defa
<section title="cat (category)"> ult"/>.</t>
<t>Name: cat</t> <section anchor="cat" numbered="true" toc="default">
<name>cat (Category)</name>
<t>Value: cat-value</t> <dl>
<dt>Name:</dt><dd>cat</dd>
<t>Usage Level: session</t> <dt>Value:</dt><dd>cat-value</dd>
<dt>Usage Level:</dt><dd>session</dd>
<t>Charset Dependent: no</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<figure> <t>Syntax:</t>
<preamble>Syntax:</preamble> <sourcecode type="abnf"><![CDATA[
<artwork>
cat-value = category cat-value = category
category = non-ws-string category = non-ws-string
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=cat:foo.bar a=cat:foo.bar
</artwork> ]]></sourcecode>
</figure>
<t>This attribute gives the dot-separated hierarchical category of the <t>This attribute gives the dot-separated hierarchical category of the
session. This is to enable a receiver to filter unwanted sessions by session. This is to enable a receiver to filter unwanted sessions by
category. There is no central registry of categories. This attribute category. There is no central registry of categories. This attribute
is obsolete and SHOULD NOT be used. It SHOULD be ignored if received.</t > is obsolete and <bcp14>SHOULD NOT</bcp14> be used. It <bcp14>SHOULD</bcp 14> be ignored if received.</t>
</section> </section>
<section anchor="keywds" numbered="true" toc="default">
<section title="keywds (keywords)"> <name>keywds (Keywords)</name>
<t>Name: keywds</t> <dl>
<dt>Name:</dt><dd>keywds</dd>
<t>Value: keywds-value</t> <dt>Value:</dt><dd>keywds-value</dd>
<dt>Usage Level:</dt><dd>session</dd>
<t>Usage Level: session</t> <dt>Charset Dependent:</dt><dd>yes</dd>
</dl>
<t>Charset Dependent: yes</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
keywds-value = keywords keywds-value = keywords
keywords = text keywords = text
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=keywds:SDP session description protocol a=keywds:SDP session description protocol
</artwork> ]]></sourcecode>
</figure> <t>Like the "a=cat:" attribute, this was intended to assist identifying
wanted
<t>Like the cat attribute, this was intended to assist identifying wante sessions at the receiver, and to allow a receiver to select interesting
d sessions based on keywords describing the purpose of the session; howeve
sessions at the receiver. This allows a receiver to select interesting r, there
sessions based on keywords describing the purpose of the session; there
is no central registry of keywords. Its value should be interpreted in is no central registry of keywords. Its value should be interpreted in
the charset specified for the session description if one is specified, the charset specified for the session description if one is specified,
or by default in ISO 10646/UTF-8. This attribute is obsolete and or by default in ISO 10646/UTF-8. This attribute is obsolete and
SHOULD NOT be used. It SHOULD be ignored if received.</t> <bcp14>SHOULD NOT</bcp14> be used. It <bcp14>SHOULD</bcp14> be ignored if received.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="tool"> <name>tool</name>
<t>Name: tool</t> <dl>
<dt>Name:</dt><dd>tool</dd>
<t>Value: tool-value</t> <dt>Value:</dt><dd>tool-value</dd>
<dt>Usage Level:</dt><dd>session</dd>
<t>Usage Level: session</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
tool-value = tool-name-and-version tool-value = tool-name-and-version
tool-name-and-version = text tool-name-and-version = text
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=tool:foobar V3.2 a=tool:foobar V3.2
</artwork> ]]></sourcecode>
</figure>
<t>This gives the name and version number of the tool used to create <t>This gives the name and version number of the tool used to create
the session description.</t> the session description.</t>
</section> </section>
<section anchor="ptime" numbered="true" toc="default">
<section title="ptime (packet time)"> <name>ptime (Packet Time)</name>
<t>Name: ptime</t> <dl>
<dt>Name:</dt><dd>ptime</dd>
<t>Value: ptime-value</t> <dt>Value:</dt><dd>ptime-value</dd>
<dt>Usage Level:</dt><dd>media</dd>
<t>Usage Level: media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
ptime-value = non-zero-int-or-real ptime-value = non-zero-int-or-real
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=ptime:20 a=ptime:20
</artwork> ]]></sourcecode>
</figure>
<t>This gives the length of time in milliseconds represented by the <t>This gives the length of time in milliseconds represented by the
media in a packet. This is probably only meaningful for audio data, 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 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 not be necessary to know "a=ptime:" to decode RTP or vat audio, and it i s
intended as a recommendation for the encoding/packetization of intended as a recommendation for the encoding/packetization of
audio.</t> audio.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="maxptime (maximum packet time)"> <name>maxptime (Maximum Packet Time)</name>
<t>Name: maxptime</t> <dl>
<dt>Name:</dt><dd>maxptime</dd>
<t>Value: maxptime-value</t> <dt>Value:</dt><dd>maxptime-value</dd>
<dt>Usage Level:</dt><dd>media</dd>
<t>Usage Level: media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
maxptime-value = non-zero-int-or-real maxptime-value = non-zero-int-or-real
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=maxptime:20 a=maxptime:20
</artwork> ]]></sourcecode>
</figure>
<t>This gives the maximum amount of media that can be encapsulated in <t>This gives the maximum amount of media that can be encapsulated in
each packet, expressed as time in milliseconds. The time SHALL be each packet, expressed as time in milliseconds. The time <bcp14>SHALL</b cp14> be
calculated as the sum of the time the media present in the packet calculated as the sum of the time the media present in the packet
represents. For frame-based codecs, the time SHOULD be an integer represents. For frame-based codecs, the time <bcp14>SHOULD</bcp14> be an integer
multiple of the frame size. This attribute is probably only meaningful 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 for audio data, but may be used with other media types if it makes
sense. Note that this attribute was introduced after <xref sense. Note that this attribute was introduced after <xref target="RFC23
target="RFC2327"/>, and non-updated implementations will ignore this 27" format="default"/>,
and implementations that have not been updated will ignore this
attribute.</t> attribute.</t>
</section> </section>
<section anchor="rtpmap" numbered="true" toc="default">
<section title="rtpmap"> <name>rtpmap</name>
<t>Name: rtpmap</t> <dl>
<dt>Name:</dt><dd>rtpmap</dd>
<t>Value: rtpmap-value</t> <dt>Value:</dt><dd>rtpmap-value</dd>
<dt>Usage Level:</dt><dd>media</dd>
<t>Usage Level: media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
rtpmap-value = payload-type SP encoding-name rtpmap-value = payload-type SP encoding-name
"/" clock-rate [ "/" encoding-params ] "/" clock-rate [ "/" encoding-params ]
payload-type = zero-based-integer payload-type = zero-based-integer
encoding-name = token encoding-name = token
clock-rate = integer clock-rate = integer
encoding-params = channels encoding-params = channels
channels = integer channels = integer
</artwork> ]]></sourcecode>
</figure>
<t>This attribute maps from an RTP payload type number (as used in an <t>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. "m=" line) to an encoding name denoting the payload format to be used.
It also provides information on the clock rate and encoding It also provides information on the clock rate and encoding
parameters. Note that the payload type number is indicated in a 7-bit parameters. Note that the payload type number is indicated in a 7-bit
field, limiting the values to inclusively between 0 and 127.</t> field, limiting the values to inclusively between 0 and 127.</t>
<t>Although an RTP profile can make static assignments of payload type <t>Although an RTP profile can make static assignments of payload type
numbers to payload formats, it is more common for that assignment to numbers to payload formats, it is more common for that assignment to
be done dynamically using "a=rtpmap:" attributes. As an example of a be done dynamically using "a=rtpmap:" attributes. As an example of a
static payload type, consider u-law PCM coded single-channel audio static payload type, consider u-law PCM encoded single-channel audio
sampled at 8 kHz. This is completely defined in the RTP Audio/Video 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:" 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 attribute, and the media for such a stream sent to UDP port 49232 can
be specified as: <figure> be specified as: </t>
<artwork> <sourcecode name="" type="sdp"><![CDATA[
m=audio 49232 RTP/AVP 0 m=audio 49232 RTP/AVP 0
</artwork> ]]></sourcecode>
</figure></t>
<t>An example of a dynamic payload type is 16-bit linear encoded <t>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 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 payload type 98 for this stream, additional information is required to
decode it: <figure> decode it: </t>
<artwork> <sourcecode name="" type="sdp"><![CDATA[
m=audio 49232 RTP/AVP 98 m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2 a=rtpmap:98 L16/16000/2
</artwork> ]]></sourcecode>
</figure></t> <t>Up to one "a=rtpmap:" attribute can be defined for each media format
specified. Thus, we might have the following: </t>
<t>Up to one rtpmap attribute can be defined for each media format <sourcecode name="" type="sdp"><![CDATA[
specified. Thus, we might have the following: <figure>
<artwork>
m=audio 49230 RTP/AVP 96 97 98 m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000 a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2 a=rtpmap:98 L16/11025/2
</artwork> ]]></sourcecode>
</figure></t> <t>RTP profiles that specify the use of dynamic payload types <bcp14>MUS
T</bcp14>
<t>RTP profiles that specify the use of dynamic payload types MUST
define the set of valid encoding names and/or a means to register 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" 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 and "RTP/SAVP" profiles use media subtypes for encoding names, under
the top-level media type denoted in the "m=" line. In the example the top-level media type denoted in the "m=" line. In the example
above, the media types are "audio/L8" and "audio/L16".</t> above, the media types are "audio/L8" and "audio/L16".</t>
<t>For audio streams, encoding-params indicates the number <t>For audio streams, encoding-params indicates the number
of audio channels. This parameter is OPTIONAL and may be omitted if of audio channels. This parameter is <bcp14>OPTIONAL</bcp14> and may be omitted if
the number of channels is one, provided that no additional parameters the number of channels is one, provided that no additional parameters
are needed.</t> are needed.</t>
<t>For video streams, no encoding parameters are currently <t>For video streams, no encoding parameters are currently
specified.</t> specified.</t>
<t>Additional encoding parameters <bcp14>MAY</bcp14> be defined in the f
<t>Additional encoding parameters MAY be defined in the future, but uture, but
codec-specific parameters SHOULD NOT be added. Parameters added to an codec-specific parameters <bcp14>SHOULD NOT</bcp14> be added. Parameters
"a=rtpmap:" attribute SHOULD only be those required for a session added to an
"a=rtpmap:" attribute <bcp14>SHOULD</bcp14> only be those required for a
session
directory to make the choice of appropriate media to participate in a directory to make the choice of appropriate media to participate in a
session. Codec-specific parameters should be added in other attributes session. Codec-specific parameters should be added in other attributes
(for example, "a=fmtp:").</t> (for example, "a=fmtp:").</t>
<t>Note: RTP audio formats typically do not include information about <t>Note: RTP audio formats typically do not include information about
the number of samples per packet. If a non-default (as defined in the the number of samples per packet. If a non-default (as defined in the
RTP Audio/Video Profile <xref RTP Audio/Video Profile <xref target="RFC3551" format="default"/>) packe
target="RFC3551"/>) packetization is required, the "ptime" tization is required, the "a=ptime:"
attribute is used as given above.</t> attribute is used as given in <xref target="ptime" format="default"/>.</
t>
</section> </section>
<section numbered="true" toc="default">
<section title="Media Direction Attributes"> <name>Media Direction Attributes</name>
<t>At most one occurrence of recvonly, sendrecv, sendonly, or inactive M <t>At most one occurrence of "a=recvonly", "a=sendrecv", "a=sendonly",
AY appear at or "a=inactive" <bcp14>MAY</bcp14> appear at
session level, and at most one MAY appear in each media description.</t> session level, and at most one <bcp14>MAY</bcp14> appear in each media d
escription.</t>
<t>If any one of these appears in a media description then it applies fo <t>If any one of these appears in a media description, then it applies f
r or
that media description. If none appear in a media description then the o that media description. If none appears in a media description, then the
ne one
from session level, if any, applies to that media description.</t> from session level, if any, applies to that media description.</t>
<t>If none of the media direction attributes is present at either <t>If none of the media direction attributes is present at either
session level or media level, "sendrecv" SHOULD be assumed as the session level or media level, "a=sendrecv" <bcp14>SHOULD</bcp14> be assu med as the
default.</t> default.</t>
<t>Within the following SDP example, the "a=sendrecv" attribute applies
<t>Within the following SDP example, the "sendrecv" attribute applies to the first audio media and the "a=inactive" attribute applies to the o
to the first audio media and the "inactive" attribute applies to the oth thers.</t>
ers.</t> <sourcecode name="" type="sdp"><![CDATA[
<t><figure>
<artwork>
v=0 v=0
o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1 o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1
s=- s=-
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=inactive a=inactive
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=sendrecv a=sendrecv
m=audio 49180 RTP/AVP 0 m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
</artwork> ]]></sourcecode>
</figure></t> <section numbered="true" toc="default">
<name>recvonly (Receive-Only)</name>
<section title="recvonly (receive-only)"> <dl>
<t>Name: recvonly</t> <dt>Name:</dt><dd>recvonly</dd>
<dt>Value:</dt><dd></dd>
<t>Value:</t> <dt>Usage Level:</dt><dd>session, media</dd>
<dt>Charset Dependent:</dt><dd>no</dd>
<t>Usage Level: session, media</t> </dl>
<t>Example:</t>
<t>Charset Dependent: no</t> <sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=recvonly a=recvonly
</artwork> ]]></sourcecode>
</figure>
<t>This specifies that the tools should be started in receive-only <t>This specifies that the tools should be started in receive-only
mode where applicable. Note that recvonly applies to the media only, mode where applicable. Note that receive-only mode applies to the medi a only,
not to any associated control protocol. not to any associated control protocol.
An RTP-based system in recvonly mode MUST still send RTCP packets An RTP-based system in receive-only mode <bcp14>MUST</bcp14> still sen
as described in <xref target="RFC3550"/> Section 6.</t> d RTCP packets
as described in <xref target="RFC3550" section="6" sectionFormat="comm
a" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="sendrecv (send-receive)"> <name>sendrecv (Send-Receive)</name>
<t>Name: sendrecv</t> <dl>
<dt>Name:</dt><dd>sendrecv</dd>
<t>Value:</t> <dt>Value:</dt><dd></dd>
<dt>Usage Level:</dt><dd>session, media</dd>
<t>Usage Level: session, media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=sendrecv a=sendrecv
</artwork> ]]></sourcecode>
</figure>
<t>This specifies that the tools should be started in send and <t>This specifies that the tools should be started in send and
receive mode. This is necessary for interactive multimedia receive mode. This is necessary for interactive multimedia
conferences with tools that default to receive-only mode.</t> conferences with tools that default to receive-only mode.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="sendonly (send-only)"> <name>sendonly (Send-Only)</name>
<t>Name: sendonly</t> <dl>
<dt>Name:</dt><dd>sendonly</dd>
<t>Value:</t> <dt>Value:</dt><dd></dd>
<dt>Usage Level:</dt><dd>session, media</dd>
<t>Usage Level: session, media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=sendonly a=sendonly
</artwork> ]]></sourcecode>
</figure>
<t>This specifies that the tools should be started in send-only <t>This specifies that the tools should be started in send-only
mode. An example may be where a different unicast address is to be 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 used for a traffic destination than for a traffic source. In such a
case, two media descriptions may be used, one sendonly and one case, two media descriptions may be used, one in send-only mode and on
recvonly. Note that sendonly applies only to the media, and any e
associated control protocol (e.g., RTCP) SHOULD still be received in receive-vonly mode. Note that send-only mode applies only to the me
dia, and any
associated control protocol (e.g., RTCP) <bcp14>SHOULD</bcp14> still b
e received
and processed as normal.</t> and processed as normal.</t>
</section> </section>
<section anchor="inactive" numbered="true" toc="default">
<section title="inactive"> <name>inactive</name>
<t>Name: inactive</t> <dl>
<dt>Name:</dt><dd>inactive</dd>
<t>Value:</t> <dt>Value:</dt><dd></dd>
<dt>Usage Level:</dt><dd>session, media</dd>
<t>Usage Level: session, media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=inactive a=inactive
</artwork> ]]></sourcecode>
</figure>
<t>This specifies that the tools should be started in inactive mode. <t>This specifies that the tools should be started in inactive mode.
This is necessary for interactive multimedia conferences where users This is necessary for interactive multimedia conferences where users
can put other users on hold. No media is sent over an inactive media 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 stream. Note that an RTP-based system <bcp14>MUST</bcp14> still send R
is used), even if started inactive.</t> TCP (if RTCP
is used), even if started in inactive mode.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="orient (orientation)"> <name>orient (Orientation)</name>
<t>Name: orient</t> <dl>
<dt>Name:</dt><dd>orient</dd>
<t>Value: orient-value</t> <dt>Value:</dt><dd>orient-value</dd>
<dt>Usage Level:</dt><dd>media</dd>
<t>Usage Level: media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
orient-value = portrait / landscape / seascape orient-value = portrait / landscape / seascape
portrait = %s"portrait" portrait = %s"portrait"
landscape = %s"landscape" landscape = %s"landscape"
seascape = %s"seascape" seascape = %s"seascape"
; NOTE: These names are case-sensitive. ; NOTE: These names are case-sensitive.
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=orient:portrait a=orient:portrait
</artwork> ]]></sourcecode>
</figure>
<t>Normally this is only used for a whiteboard or presentation tool. <t>Normally this is only used for a whiteboard or presentation tool.
It specifies the orientation of the workspace on the screen. It specifies the orientation of the workspace on the screen.
Permitted values are "portrait", "landscape", and "seascape" Permitted values are "portrait", "landscape", and "seascape"
(upside-down landscape).</t> (upside-down landscape).</t>
</section> </section>
<section anchor="type" numbered="true" toc="default">
<section title="type (conference type)"> <name>type (Conference Type)</name>
<t>Name: type</t> <dl>
<dt>Name:</dt><dd>type</dd>
<t>Value: type-value</t> <dt>Value:</dt><dd>type-value</dd>
<dt>Usage Level:</dt><dd>session</dd>
<t>Usage Level: session</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure> type-value = conference-type
<preamble>Syntax:</preamble> conference-type = broadcast / meeting / moderated / test /
H332
<artwork> broadcast = %s"broadcast"
type-value = conference-type meeting = %s"meeting"
conference-type = broadcast / meeting / moderated / test / moderated = %s"moderated"
H332 test = %s"test"
broadcast = %s"broadcast" H332 = %s"H332"
meeting = %s"meeting" ; NOTE: These names are case-sensitive.
moderated = %s"moderated" ]]></sourcecode>
test = %s"test" <t>Example:</t>
H332 = %s"H332" <sourcecode name="" type="sdp"><![CDATA[
; NOTE: These names are case-sensitive.
</artwork>
</figure>
<figure>
<preamble>Example:</preamble>
<artwork>
a=type:moderated a=type:moderated
</artwork> ]]></sourcecode>
</figure>
<t>This specifies the type of the multimedia conference. <t>This specifies the type of the multimedia conference.
Allowed values are "broadcast", "meeting", "moderated", "test", and "H33 2". Allowed values are "broadcast", "meeting", "moderated", "test", and "H33 2".
These values have implications for other options that are likely to be a ppropriate: These values have implications for other options that are likely to be a ppropriate:
<list style="symbols"> </t>
<t>When "a=type:broadcast" is specified, "a=recvonly" is probably <ul spacing="normal">
appropriate for those connecting.</t> <li>When "a=type:broadcast" is specified, "a=recvonly" is probably
<t>When "a=type:meeting" is specified, "a=sendrecv" is likely to b appropriate for those connecting.</li>
e appropriate.</t> <li>When "a=type:meeting" is specified, "a=sendrecv" is likely to be a
<t>"a=type:moderated" suggests the use of a floor control tool and ppropriate.</li>
<li>"a=type:moderated" suggests the use of a floor control tool and
that the media tools be started so as to mute new sites joining the that the media tools be started so as to mute new sites joining the
multimedia conference.</t> multimedia conference.</li>
<t>Specifying "a=type:H332" indicates that this loosely <li>Specifying "a=type:H332" indicates that this loosely
coupled session is part of an H.332 session as defined in the I TU coupled session is part of an H.332 session as defined in the I TU
H.332 specification <xref target="ITU.H332.1998"/>. Media tools H.332 specification <xref target="ITU.H332.1998" format="defaul
should t"/>. Media tools should
be started using "a=recvonly".</t> be started using "a=recvonly".</li>
<t>Specifying "a=type:test" is suggested as a hint that, <li>Specifying "a=type:test" is suggested as a hint that,
unless explicitly requested otherwise, receivers can safely avo id unless explicitly requested otherwise, receivers can safely avo id
displaying this session description to users.</t> displaying this session description to users.</li>
</list> </ul>
</t>
</section> </section>
<section anchor="charset" numbered="true" toc="default">
<section title="charset (character set)"> <name>charset (Character Set)</name>
<t>Name: charset</t> <dl>
<dt>Name:</dt><dd>charset</dd>
<t>Value: charset-value</t> <dt>Value:</dt><dd>charset-value</dd>
<dt>Usage Level:</dt><dd>session</dd>
<t>Usage Level: session</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure> charset-value = <defined in [RFC2978]>
<preamble>Syntax:</preamble> ]]></sourcecode>
<artwork>
charset-value = &lt;defined in [RFC2978]&gt;
</artwork>
</figure>
<t>This specifies the character set to be used to display the session <t>This specifies the character set to be used to display the session
name and information data. By default, the ISO-10646 character set in name and information data. By default, the ISO-10646 character set in
UTF-8 encoding is used. If a more compact representation is required, 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 other character sets may be used. For example, the ISO 8859-1 is
specified with the following SDP attribute:</t> specified with the following SDP attribute:</t>
<sourcecode name="" type="sdp"><![CDATA[
<t><figure>
<artwork>
a=charset:ISO-8859-1 a=charset:ISO-8859-1
</artwork> ]]></sourcecode>
</figure></t> <t>The charset specified <bcp14>MUST</bcp14> be one of those registered
in the IANA
<t>The charset specified MUST be one of those registered in the IANA
Character Sets registry Character Sets registry
(http://www.iana.org/assignments/character-sets), such as ISO-8859-1. (<eref target="http://www.iana.org/assignments/character-sets"/>), such
The character set identifier is a string that MUST be compared as ISO-8859-1.
The character set identifier is a string that <bcp14>MUST</bcp14> be com
pared
against identifiers from the "Name" or "Preferred MIME Name" field of against identifiers from the "Name" or "Preferred MIME Name" field of
the registry using a case-insensitive comparison. If the identifier is the registry using a case-insensitive comparison. If the identifier is
not recognized or not supported, all strings that are affected by it not recognized or not supported, all strings that are affected by it
SHOULD be regarded as octet strings.</t> <bcp14>SHOULD</bcp14> be regarded as octet strings.</t>
<t>Charset-dependent fields <bcp14>MUST</bcp14> contain only sequences o
<t>Charset-dependent fields MUST contain only sequences of bytes that ar f bytes that are
e
valid according to the definition of the selected character set. valid according to the definition of the selected character set.
Furthermore, charset-dependent fields MUST NOT contain the bytes 0x00 (N ul), Furthermore, charset-dependent fields <bcp14>MUST NOT</bcp14> contain th e bytes 0x00 (Nul),
0x0A (LF), and 0x0d (CR).</t> 0x0A (LF), and 0x0d (CR).</t>
</section> </section>
<section anchor="sdplang" numbered="true" toc="default">
<section title="sdplang (SDP language)"> <name>sdplang (SDP Language)</name>
<t>Name: sdplang</t> <dl>
<dt>Name:</dt><dd>sdplang</dd>
<t>Value: sdplang-value</t> <dt>Value:</dt><dd>sdplang-value</dd>
<dt>Usage Level:</dt><dd>session, media</dd>
<t>Usage Level: session, media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure> sdplang-value = Language-Tag
<preamble>Syntax:</preamble> ; Language-Tag defined in RFC 5646
]]></sourcecode>
<artwork> <t>Example:</t>
sdplang-value = Language-Tag <sourcecode name="" type="sdp"><![CDATA[
; Language-Tag defined in RFC5646
</artwork>
</figure>
<figure>
<preamble>Example:</preamble>
<artwork>
a=sdplang:fr a=sdplang:fr
</artwork> ]]></sourcecode>
</figure> <t>Multiple "a=sdplang:" attributes can be provided either at session or
<t>Multiple sdplang attributes can be provided either at session or
media level if the session description or media use multiple media level if the session description or media use multiple
languages.</t> languages.</t>
<t>As a session-level attribute, it specifies the language for the <t>As a session-level attribute, it specifies the language for the
session description (not the language of the media). As a media-level session description (not the language of the media). As a media-level
attribute, it specifies the language for any media-level SDP attribute, it specifies the language for any media-level SDP
information-field associated with that media (again not the language information-field associated with that media (again not the language
of the media), overriding any sdplang attributes specified at of the media), overriding any "a=sdplang:" attributes specified at
session level.</t> session level.</t>
<t>In general, sending session descriptions consisting of multiple <t>In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple sesssion descriptions SHOULD be languages is discouraged. Instead, multiple session descriptions <bcp14> SHOULD</bcp14> be
sent describing the session, one in each language. However, this is sent describing the session, one in each language. However, this is
not possible with all transport mechanisms, and so multiple sdplang not possible with all transport mechanisms, and so multiple "a=sdplang:"
attributes are allowed although NOT RECOMMENDED.</t> attributes are allowed although <bcp14>NOT RECOMMENDED</bcp14>.</t>
<t>The "a=sdplang:" attribute value must be a single language tag
<t>The "sdplang" attribute value must be a single <xref <xref target="RFC5646" format="default"/>. An "a=sdplang:" attribute
target="RFC5646"/> language tag. An "sdplang" attribute <bcp14>SHOULD</bcp14> be specified when a session is distributed with su
SHOULD be specified when a session is distributed with sufficient fficient
scope to cross geographic boundaries, where the language of recipients scope to cross geographic boundaries, where the language of recipients
cannot be assumed, or where the session is in a different language cannot be assumed, or where the session is in a different language
from the locally assumed norm.</t> from the locally assumed norm.</t>
</section> </section>
<section anchor="lang" numbered="true" toc="default">
<section title="lang (language)"> <name>lang (Language)</name>
<t>Name: lang</t> <dl>
<dt>Name:</dt><dd>lang</dd>
<t>Value: lang-value</t> <dt>Value:</dt><dd>lang-value</dd>
<dt>Usage Level:</dt><dd>session, media</dd>
<t>Usage Level: session, media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
lang-value = Language-Tag lang-value = Language-Tag
; Language-Tag defined in RFC5646 ; Language-Tag defined in RFC 5646
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=lang:de a=lang:de
</artwork> ]]></sourcecode>
</figure> <t>Multiple "a=lang:" attributes can be provided either at session or me
dia
<t>Multiple lang attributes can be provided either at session or media
level if the session or media has capabilities in more than one level if the session or media has capabilities in more than one
language, in which case the order of the attributes indicates the language, in which case the order of the attributes indicates the
order of preference of the various languages in the session or media, order of preference of the various languages in the session or media,
from most preferred to least preferred.</t> from most preferred to least preferred.</t>
<t>As a session-level attribute, "a=lang:" specifies a language capabili
<t>As a session-level attribute, lang specifies a language capability ty
for the session being described. As a media-level attribute, it for the session being described. As a media-level attribute, it
specifies a language capability for that media, overriding any specifies a language capability for that media, overriding any
session-level language(s) specified.</t> session-level language(s) specified.</t>
<t>The "a=lang:" attribute value must be a single <xref target="RFC5646"
<t>The "lang" attribute value must be a single <xref format="default"/>
target="RFC5646"/> language tag. A "lang" attribute SHOULD language tag. An "a=lang:" attribute <bcp14>SHOULD</bcp14>
be specified when a session is of sufficient scope to cross geographic be specified when a session is of sufficient scope to cross geographic
boundaries where the language of participants cannot be assumed, or boundaries where the language of participants cannot be assumed, or
where the session has capabilities in languages different from the where the session has capabilities in languages different from the
locally assumed norm.</t> locally assumed norm.</t>
<t>The "a=lang:" attribute is supposed to be used for setting the initia
<t>The "lang" attribute is supposed to be used for setting the initial l
language(s) used in the session. Events during the session may influence which language(s) are used, and the participants are not strictly bound to only use th e declared languages.</t> language(s) used in the session. Events during the session may influence which language(s) are used, and the participants are not strictly bound to only use th e declared languages.</t>
<t>Most real-time use cases start with just one language used, while oth
<t>Most real-time use cases start with just one language used, while other case er cases involve a range of languages, e.g., an interpreted or subtitled session
s involve a range of languages, e.g. an interpreted or subtitled session. When m . When more than one "a=lang:" attribute is specified,
ore than one 'lang' attribute is specified, the "lang" attribute itself does not the "a=lang:" attribute itself does not provide any information about multiple l
provide any information about multiple languages being intended to be used duri anguages being intended to be used during the session, or if the intention is to
ng the session, or if the intention is to only select one of the languages. If n only select one of the languages. If needed, a new attribute can be defined and
eeded, a new attribute can be defined and used to indicate such intentions. With used to indicate such intentions. Without such semantics, it is assumed that fo
out such semantics, it is assumed that for a negotiated session one of the decla r a negotiated session one of the declared languages will be selected and used.<
red languages will be selected and used.</t> /t>
</section> </section>
<section numbered="true" toc="default">
<section title="framerate (frame rate)"> <name>framerate (Frame Rate)</name>
<t>Name: framerate</t> <dl>
<dt>Name:</dt><dd>framerate</dd>
<t>Value: framerate-value</t> <dt>Value:</dt><dd>framerate-value</dd>
<dt>Usage Level:</dt><dd>media</dd>
<t>Usage Level: media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
framerate-value = non-zero-int-or-real framerate-value = non-zero-int-or-real
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=framerate:60 a=framerate:60
</artwork> ]]></sourcecode>
</figure>
<t>This gives the maximum video frame rate in frames/sec. It is <t>This gives the maximum video frame rate in frames/sec. It is
intended as a recommendation for the encoding of video data. Decimal intended as a recommendation for the encoding of video data. Decimal
representations of fractional values are allowed. It is defined only representations of fractional values are allowed. It is defined only
for video media.</t> for video media.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="quality"> <name>quality</name>
<t>Name: quality</t> <dl>
<dt>Name:</dt><dd>quality</dd>
<t>Value: quality-value</t> <dt>Value:</dt><dd>quality-value</dd>
<dt>Usage Level:</dt><dd>media</dd>
<t>Usage Level: media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
quality-value = zero-based-integer quality-value = zero-based-integer
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=quality:10 a=quality:10
</artwork> ]]></sourcecode>
</figure>
<t>This gives a suggestion for the quality of the encoding as an <t>This gives a suggestion for the quality of the encoding as an
integer value. The intention of the quality attribute for video is to integer value. The intention of the quality attribute for video is to
specify a non-default trade-off between frame-rate and still-image 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 quality. For video, the value is in the range 0 to 10, with the
following suggested meaning: <figure> following suggested meaning: </t>
<artwork> <table>
10 - the best still-image quality the compression scheme <name>Encoding Quality Values</name>
can give. <tbody>
5 - the default behavior given no quality suggestion. <tr>
0 - the worst still-image quality the codec designer <td>10</td>
thinks is still usable. <td>the best still-image quality the compression scheme can give.
</artwork> </td>
</figure></t> </tr>
<tr>
<td>5</td>
<td>the default behavior given no quality suggestion.</td>
</tr>
<tr>
<td>0</td>
<td>the worst still-image quality the codec designer thinks is st
ill usable.</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="fmtp" numbered="true" toc="default">
<section title="fmtp (format parameters)"> <name>fmtp (Format Parameters)</name>
<t>Name: fmtp</t> <dl>
<dt>Name:</dt><dd>fmtp</dd>
<t>Value: fmtp-value</t> <dt>Value:</dt><dd>fmtp-value</dd>
<dt>Usage Level:</dt><dd>media</dd>
<t>Usage Level: media</t> <dt>Charset Dependent:</dt><dd>no</dd>
</dl>
<t>Charset Dependent: no</t> <t>Syntax:</t>
<sourcecode type="abnf"><![CDATA[
<figure>
<preamble>Syntax:</preamble>
<artwork>
fmtp-value = fmt SP format-specific-params fmtp-value = fmt SP format-specific-params
format-specific-params = byte-string format-specific-params = byte-string
; Notes: ; Notes:
; - The format parameters are media type parameters and ; - The format parameters are media type parameters and
; need to reflect their syntax. ; need to reflect their syntax.
</artwork> ]]></sourcecode>
</figure> <t>Example:</t>
<sourcecode name="" type="sdp"><![CDATA[
<figure>
<preamble>Example:</preamble>
<artwork>
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
</artwork> ]]></sourcecode>
</figure>
<t>This attribute allows parameters that are specific to a particular <t>This attribute allows parameters that are specific to a particular
format to be conveyed in a way that SDP does not have to understand 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. them. The format must be one of the formats specified for the media.
Format-specific parameters, semicolon separated, may be any set of param eters required to be Format-specific parameters, semicolon separated, may be any set of param eters required to be
conveyed by SDP and given unchanged to the media tool that will use 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 this format. At most one instance of this attribute is allowed for
each format.</t> each format.</t>
<t>The "a=fmtp:" attribute may be used to specify parameters for any
<t>The fmtp attribute may be used to specify parameters for any
protocol and format that defines use of such parameters. protocol and format that defines use of such parameters.
</t> </t>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>SDP is frequently used with the <xref target="RFC3261">Session <t>SDP is frequently used with the <xref target="RFC3261" format="default"
Initiation Protocol</xref> using the <xref target="RFC3264">offer/answer >Session
Initiation Protocol</xref> using the <xref target="RFC3264" format="defaul
t">offer/answer
model</xref> to agree on parameters for unicast sessions. When used in model</xref> to agree on parameters for unicast sessions. When used in
this manner, the security considerations of those protocols apply.</t> this manner, the security considerations of those protocols apply.</t>
<t>SDP is a session description format that describes multimedia <t>SDP is a session description format that describes multimedia
sessions. Entities receiving and acting upon an SDP message SHOULD be sessions. Entities receiving and acting upon an SDP message <bcp14>SHOULD< /bcp14> be
aware that a session description cannot be trusted unless it has been aware that a session description cannot be trusted unless it has been
obtained by an authenticated and integrity-protected transport protocol fr om a known and trusted obtained by an authenticated and integrity-protected transport protocol fr om a known and trusted
source. Many different transport protocols may be used to distribute source. Many different transport protocols may be used to distribute
session descriptions, and the nature of the authentication and integrity-p rotection will differ session descriptions, and the nature of the authentication and integrity p rotection will differ
from transport to transport. For some transports, security features are from transport to transport. For some transports, security features are
often not deployed. In case a session description has not been obtained often not deployed. In case a session description has not been obtained
in a trusted manner, the endpoint SHOULD exercise care because, among in a trusted manner, the endpoint <bcp14>SHOULD</bcp14> exercise care beca use, among
other attacks, the media sessions received may not be the intended ones, 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 the destination to where the media is sent may not be the expected one, a ny
of the parameters of the session may be incorrect, or the media security 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 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 taking into account the security risks of the application and the user
preferences - the endpoint may decide to ask the user whether or not to ac cept the preferences - the endpoint may decide to ask the user whether or not to ac cept the
session.</t> session.</t>
<t>On receiving a session description over an unauthenticated transport <t>On receiving a session description over an unauthenticated transport
mechanism or from an untrusted party, software parsing the session descrip tion mechanism or from an untrusted party, software parsing the session descrip tion
should take a few precautions. Similar concerns apply if integrity protect ion is not in place. should take a few precautions. Similar concerns apply if integrity protect ion is not in place.
Session descriptions contain information Session descriptions contain information
required to start software on the receiver's system. Software that required to start software on the receiver's system. Software that
parses a session description MUST NOT be able to start other software parses a session description <bcp14>MUST NOT</bcp14> be able to start othe r software
except that which is specifically configured as appropriate software to except that which is specifically configured as appropriate software to
participate in multimedia sessions. It is normally considered participate in multimedia sessions. It is normally considered
inappropriate for software parsing a session description to start, on a inappropriate for software parsing a session description to start, on a
user's system, software that is appropriate to participate in multimedia user's system, software that is appropriate to participate in multimedia
sessions, without the user first being informed that such software will sessions, without the user first being informed that such software will
be started and giving the user's consent. Thus, a session description be started and giving the user's consent. Thus, a session description
arriving by session announcement, email, session invitation, or WWW page arriving by session announcement, email, session invitation, or WWW page
MUST NOT deliver the user into an interactive multimedia session unless <bcp14>MUST NOT</bcp14> deliver the user into an interactive multimedia se ssion unless
the user has explicitly pre-authorized such action. As it is not always the user has explicitly pre-authorized such action. As it is not always
simple to tell whether or not a session is interactive, applications simple to tell whether or not a session is interactive, applications
that are unsure should assume sessions are interactive. that are unsure should assume sessions are interactive.
Software processing URLs contained in session descriptions should also Software processing URLs contained in session descriptions should also
heed the security considerations identified in <xref target="RFC3986"/>.</ heed the security considerations identified in <xref target="RFC3986" form
t> at="default"/>.</t>
<t>In this specification, there are no attributes that would allow the <t>In this specification, there are no attributes that would allow the
recipient of a session description to be informed to start multimedia recipient of a session description to be informed to start multimedia
tools in a mode where they default to transmitting. Under some tools in a mode where they default to transmitting. Under some
circumstances it might be appropriate to define such attributes. If this circumstances it might be appropriate to define such attributes. If this
is done, an application parsing a session description containing such is done, an application parsing a session description containing such
attributes SHOULD either ignore them or inform the user that joining attributes <bcp14>SHOULD</bcp14> either ignore them or inform the user tha t joining
this session will result in the automatic transmission of multimedia this session will result in the automatic transmission of multimedia
data. The default behavior for an unknown attribute is to ignore data. The default behavior for an unknown attribute is to ignore
it.</t> it.</t>
<t>In certain environments, it has become common for intermediary <t>In certain environments, it has become common for intermediary
systems to intercept and analyze session descriptions contained within systems to intercept and analyze session descriptions contained within
other signaling protocols. This is done for a range of purposes, other signaling protocols. This is done for a range of purposes,
including but not limited to opening holes in firewalls to allow media including but not limited to opening holes in firewalls to allow media
streams to pass, or to mark, prioritize, or block traffic selectively. streams to pass, or to mark, prioritize, or block traffic selectively.
In some cases, such intermediary systems may modify the session In some cases, such intermediary systems may modify the session
description, for example, to have the contents of the session description, for example, to have the contents of the session
description match NAT bindings dynamically created. These behaviors are description match NAT bindings dynamically created. These behaviors are
NOT RECOMMENDED unless the session description is conveyed in such a <bcp14>NOT RECOMMENDED</bcp14> unless the session description is conveyed in such a
manner that allows the intermediary system to conduct proper checks to manner that allows the intermediary system to conduct proper checks to
establish the authenticity of the session description, and the authority establish the authenticity of the session description, and the authority
of its source to establish such communication sessions. SDP by itself of its source to establish such communication sessions. SDP by itself
does not include sufficient information to enable these checks: they does not include sufficient information to enable these checks: they
depend on the encapsulating protocol (e.g., SIP or RTSP). depend on the encapsulating protocol (e.g., SIP or RTSP).
Use of some procedures and SDP extensions The use of some procedures and SDP extensions
(e.g., ICE <xref target="RFC8445"/> and ICE-SIP-SDP <xref target="I-D.ietf (e.g., Interactive Connectivity Establishment (ICE) <xref target="RFC8445"
-mmusic-ice-sip-sdp"/>) format="default"/>
and ICE-SIP-SDP <xref target="RFC8839" format="default"/>)
may avoid the need for intermediaries to modify SDP.</t> may avoid the need for intermediaries to modify SDP.</t>
<t>SDP <bcp14>MUST NOT</bcp14> be used to convey keying material (e.g., us
<t>SDP MUST NOT be used to convey keying material (e.g., using ing
"a=crypto" <xref target="RFC4568"/>) unless it can be guaranteed that the the "a=crypto:" attribute <xref target="RFC4568" format="default"/>) unles
channel over s it can be guaranteed that the channel over
which the SDP is delivered is both private and authenticated.</t> which the SDP is delivered is both private and authenticated.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section anchor="iana" title="IANA Considerations"> <name>IANA Considerations</name>
<section title="The &quot;application/sdp&quot; Media Type"> <section numbered="true" toc="default">
<t>One media type registration from <xref target="RFC4566"/> is to be <name>The "application/sdp" Media Type</name>
<t>One media type registration from <xref target="RFC4566" format="defau
lt"/> has been
updated, as defined below.</t> updated, as defined below.</t>
<figure> <dl>
<artwork> <dt>Type name:</dt><dd>application</dd>
To: ietf-types@iana.org
Subject: Registration of media type "application/sdp"
Type name: application
Subtype name: sdp <dt>Subtype name:</dt><dd>sdp</dd>
Required parameters: None. <dt>Required parameters:</dt><dd>None.</dd>
Optional parameters: None. <dt>Optional parameters:</dt><dd>None.</dd>
Encoding considerations: 8-bit text. <dt>Encoding considerations:</dt><dd>8-bit text.
SDP files are primarily UTF-8 format text. The "a=charset:" SDP files are primarily UTF-8 format text. The "a=charset:"
attribute may be used to signal the presence of other character attribute may be used to signal the presence of other character
sets in certain parts of an SDP file (see Section 6 of RFC sets in certain parts of an SDP file (see <xref target="attrs"/> of RFC
XXXX). Arbitrary binary content cannot be directly 8866). Arbitrary binary content cannot be directly
represented in SDP. represented in SDP.</dd>
Security considerations: <dt>Security considerations:</dt><dd>
See Section 7 of RFC XXXX. See <xref target="security"/> of RFC 8866.</dd>
Interoperability considerations: <dt>Interoperability considerations:</dt><dd>
See RFC XXXX. See RFC 8866.</dd>
Published specification: <dt>Published specification:</dt><dd>
See RFC XXXX. See RFC 8866.</dd>
Applications which use this media type: <dt>Applications which use this media type:</dt><dd><t><br/>
Voice over IP, video teleconferencing, streaming media, instant Voice over IP, video teleconferencing, streaming media, instant
messaging, among others. See also Section 3 of RFC XXXX. messaging, among others. See also <xref target="usage_examples"/> of RFC
8866.</t></dd>
Fragment identifier considerations: None
Additional information: <dt>Fragment identifier considerations:</dt><dd>None</dd>
Deprecated alias names for this type: N/A <dt>Additional information:</dt><dd><t><br/></t>
Magic number(s): None. <dl spacing="compact">
File extension(s): The extension ".sdp" is commonly used. <dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
Macintosh File Type Code(s): "sdp " <dt>Magic number(s):</dt><dd>None.</dd>
<dt>File extension(s):</dt><dd>The extension ".sdp" is commonly used.</dd>
<dt>Macintosh File Type Code(s):</dt><dd>"sdp"</dd>
</dl>
</dd>
Person &amp; email address to contact for further information: <dt>Person &amp; email address to contact for further information:</dt><dd>
IETF MMUSIC working group &lt;mmusic@ietf.org&gt; IETF MMUSIC working group &lt;mmusic@ietf.org&gt;</dd>
Intended usage: COMMON <dt>Intended usage:</dt><dd>COMMON</dd>
Restrictions on usage: None <dt>Restrictions on usage:</dt><dd>None</dd>
Author/Change controller: <dt>Author/Change controller:</dt><dd><t><br/></t>
Authors of RFC XXXX <ul spacing="compact" empty="true">
IETF MMUSIC working group delegated from the IESG <li>Authors of RFC 8866</li>
<li>IETF MMUSIC working group delegated from the IESG</li>
</ul>
</dd>
</artwork> </dl>
</figure>
</section> </section>
<section anchor="SDP_Parameters" numbered="true" toc="default">
<section anchor="SDP_Parameters" title="Registration of SDP Parameters wit <name>Registration of SDP Parameters with IANA</name>
h IANA">
<t>This document specifies IANA parameter registries <t>This document specifies IANA parameter registries
for six named SDP sub-fields. Using for six named SDP subfields. Using
the terminology in the SDP specification Augmented Backus-Naur Form (ABN F), they the terminology in the SDP specification Augmented Backus-Naur Form (ABN F), they
are "media", "proto", "att-field", "bwtype", "nettype", and are &lt;media&gt;, &lt;proto&gt;, &lt;attribute-name&gt;, &lt;bwtype&gt;
"addrtype".</t> , &lt;nettype&gt;, and
&lt;addrtype&gt;.</t>
<t>This document also replaces and updates the definitions of all those parameters previously <t>This document also replaces and updates the definitions of all those parameters previously
defined by <xref target="RFC4566"/>.</t> defined by <xref target="RFC4566" format="default"/>.</t>
<t>IANA has changed all references to RFC 4566 in these registries to in
<t>IANA: Please change all references to RFC4566 in these registries to i stead refer to this document.</t>
nstead refer to this document.</t> <t>The contact name and email address for all parameters registered in t
his document is: </t>
<t>The contact name and email address for all parameters registered in t <t indent="3">The IETF MMUSIC working group &lt;mmusic@ietf.org&gt; or
his document is: <list its successor as designated by the IESG.</t>
style="empty">
<t>The IETF MMUSIC working group &lt;mmusic@ietf.org&gt; or its succ
essor as designated by the IESG.</t>
</list></t>
<t>All of these registries have a common format:</t> <t>All of these registries have a common format:</t>
<table>
<t><figure> <name>Common Format for SDP Registries</name>
<artwork> <tbody>
| Type | SDP Name | [other fields] | Reference | <tr>
</artwork> <th>Type</th>
</figure></t> <th>SDP Name</th>
<th>[other fields]</th>
<section anchor="Registration_Procedure" title="Registration Procedure"> <th>Reference</th>
<t>A specification document that defines values for SDP "media", "prot </tr>
o", </tbody>
"att-field", "bwtype", "nettype", and "addrtype" parameters MUST </table>
<section anchor="Registration_Procedure" numbered="true" toc="default">
<name>Registration Procedure</name>
<t>A specification document that defines values for SDP &lt;media&gt;,
&lt;proto&gt;,
&lt;attribute-name&gt;, &lt;bwtype&gt;, &lt;nettype&gt;, and &lt;addrt
ype&gt; parameters <bcp14>MUST</bcp14>
include the following information: include the following information:
<list style="symbols"> </t>
<t>contact name;</t> <ul spacing="normal">
<li>Contact name</li>
<t>contact email address;</t> <li>Contact email address</li>
<li>Name being defined (as it will appear in SDP)</li>
<t>name being defined (as it will appear in SDP);</t> <li>Type of name (&lt;media&gt;, &lt;proto&gt;, &lt;attribute-name&g
t;, &lt;bwtype&gt;, &lt;nettype&gt;,
<t>type of name ("media", "proto", "bwtype", "nettype", or &lt;addrtype&gt;)</li>
or "addrtype");</t> <li>A description of the purpose of the defined name</li>
<li>A stable reference to the document containing this
<t>a description of the purpose of the defined name;</t>
<t>a stable reference to the document containing this
information and the definition of the value. information and the definition of the value.
(This will typically be an RFC number.)</t> (This will typically be an RFC number.)</li>
</list></t> </ul>
<t>The subsections below specify what other information (if any) must be specified <t>The subsections below specify what other information (if any) must be specified
for particular parameters, and what other fields are to be included for particular parameters, and what other fields are to be included
in the registry.</t> in the registry.</t>
</section> </section>
<section anchor="MediaTypes" numbered="true" toc="default">
<section title="Media Types (&quot;media&quot;)"> <name>Media Types (&lt;media&gt;)</name>
<t>The set of media types is intended to be small and SHOULD NOT be <t>The set of media types is intended to be small and <bcp14>SHOULD NO
T</bcp14> be
extended except under rare circumstances. The same rules should extended except under rare circumstances. The same rules should
apply for media names as for top-level media types, and where apply for media names as well as for top-level media types, and where
possible the same name should be registered for SDP as for MIME. For possible the same name should be registered for SDP as for MIME. For
media other than existing top-level media types, a Standards Track media other than existing top-level media types, a Standards Track
RFC MUST be produced for a new top-level media type to be RFC <bcp14>MUST</bcp14> be produced for a new top-level media type to
registered, and the registration MUST provide good justification why be
registered, and the registration <bcp14>MUST</bcp14> provide good just
ification why
no existing media name is appropriate (the "Standards Action" policy no existing media name is appropriate (the "Standards Action" policy
of <xref target="RFC8126"/>).</t> of <xref target="RFC8126" format="default"/>).</t>
<t>This memo registers the media types "audio", "video", "text", <t>This memo registers the media types "audio", "video", "text",
"application", and "message".</t> "application", and "message".</t>
<t>Note: The media types "control" and "data" were listed as valid <t>Note: The media types "control" and "data" were listed as valid
in an early version of this specification (RFC 2327); however, their in an early version of this specification <xref target="RFC2327" forma
semantics were never fully specified and they are not widely used. t="default"/>; however, their
semantics were never fully specified, and they are not widely used.
These media types have been removed in this specification, although These media types have been removed in this specification, although
they still remain valid media type capabilities for a SIP user agent they still remain valid media type capabilities for a SIP user agent
as defined in <xref target="RFC3840"/>. If these media types are as defined in <xref target="RFC3840" format="default"/>. If these medi
considered useful in the future, a Standards Track RFC MUST be a types are
considered useful in the future, a Standards Track RFC <bcp14>MUST</bc
p14> be
produced to document their use. Until that is done, applications produced to document their use. Until that is done, applications
SHOULD NOT use these types and SHOULD NOT declare support for them <bcp14>SHOULD NOT</bcp14> use these types and <bcp14>SHOULD NOT</bcp14 > declare support for them
in SIP capabilities declarations (even though they exist in the in SIP capabilities declarations (even though they exist in the
registry created by <xref target="RFC3840"/>). Also note that <xref ta rget="RFC6466"/> defined the "image" media type.</t> registry created by <xref target="RFC3840" format="default"/>). Also n ote that <xref target="RFC6466" format="default"/> defined the "image" media typ e.</t>
</section> </section>
<section anchor="protoreg" numbered="true" toc="default">
<section title="Transport Protocols (&quot;proto&quot;)"> <name>Transport Protocols (&lt;proto&gt;)</name>
<t>The "proto" sub-field describes the transport protocol used. <t>The &lt;proto&gt; subfield describes the transport protocol used.
The registration procedure for this registry is "RFC Required".</t> The registration procedure for this registry is "RFC Required".</t>
<t>This document registers two values: <t>This document registers two values:
<list style="symbols">
<t>"RTP/AVP" is a reference to <xref target="RFC3550"/>
used under the <xref target="RFC3551">RTP Profile for Audio a
nd
Video Conferences with Minimal Control</xref> running over UD
P/IP,</t>
<t>"UDP" indicates direct use of the UDP protocol.</t>
</list>
</t> </t>
<ul spacing="normal">
<t>New transport protocols MAY be defined, and MUST be registered with <li>"RTP/AVP" is a reference to <xref target="RFC3550" format="defau
IANA. lt"/>
Registrations MUST reference an RFC describing the protocol. Such an used under the <xref target="RFC3551" format="default">RTP Pr
RFC MAY be Experimental or Informational, although it is preferable ofile for Audio and
that it be Standards Track. The RFC defining a new protocol MUST defin Video Conferences with Minimal Control</xref> running over UD
e the rules P/IP.</li>
by which the "fmt" (see below) namespace is managed.</t> <li>"udp" indicates direct use of UDP.</li>
</ul>
<t>"proto" names starting with "RTP/" MUST only be used for <t>New transport protocols <bcp14>MAY</bcp14> be defined, and <bcp14>M
defining transport protocols that are profiles of the RTP protocol. UST</bcp14> be registered with IANA.
Registrations <bcp14>MUST</bcp14> reference an RFC describing the prot
ocol. Such an
RFC <bcp14>MAY</bcp14> be Experimental or Informational, although it i
s preferable
that it be Standards Track. The RFC defining a new protocol <bcp14>MUS
T</bcp14> define the rules
by which the &lt;fmt&gt; (see below) namespace is managed.</t>
<t>&lt;proto&gt; names starting with "RTP/" <bcp14>MUST</bcp14> only b
e used for
defining transport protocols that are profiles of RTP.
For example, a profile whose short name is "XYZ" would be denoted by For example, a profile whose short name is "XYZ" would be denoted by
a "proto" sub-field of "RTP/XYZ".</t> a &lt;proto&gt; subfield of "RTP/XYZ".</t>
<t>Each transport protocol, defined by the &lt;proto&gt; subfield, has
<t>Each transport protocol, defined by the "proto" sub-field, has an an
associated "fmt" namespace that describes the media formats that may associated &lt;fmt&gt; namespace that describes the media formats that
may
be conveyed by that protocol. Formats cover all the possible be conveyed by that protocol. Formats cover all the possible
encodings that could be transported in a multimedia session.</t> encodings that could be transported in a multimedia session.</t>
<t>RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles <t>RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles
MUST use the payload type number as their "fmt" value. If the <bcp14>MUST</bcp14> use the payload type number as their &lt;fmt&gt; v alue. If the
payload type number is dynamically assigned by this session payload type number is dynamically assigned by this session
description, an additional "rtpmap" attribute MUST be included to description, an additional "a=rtpmap:" attribute <bcp14>MUST</bcp14> b e included to
specify the format name and parameters as defined by the media type specify the format name and parameters as defined by the media type
registration for the payload format. It is RECOMMENDED that other registration for the payload format. It is <bcp14>RECOMMENDED</bcp14> that other
RTP profiles that are registered (in combination with RTP) as SDP RTP profiles that are registered (in combination with RTP) as SDP
transport protocols specify the same rules for the "fmt" transport protocols specify the same rules for the &lt;fmt&gt;
namespace.</t> namespace.</t>
<t>For the "udp" protocol, the allowed &lt;fmt&gt; values are media su
<t>For the "UDP" protocol, allowed "fmt" values are media subtypes btypes
from the IANA Media Types registry. The media type and subtype combina tion from the IANA Media Types registry. The media type and subtype combina tion
&lt;media&gt;/&lt;fmt&gt; specifies the format of the body of UDP pack ets. &lt;media&gt;/&lt;fmt&gt; specifies the format of the body of UDP pack ets.
Use of an existing media subtype for the format is encouraged. If no s uitable media Use of an existing media subtype for the format is encouraged. If no s uitable media
subtype exists, it is RECOMMENDED that a new one be registered subtype exists, it is <bcp14>RECOMMENDED</bcp14> that a new one be reg
through the IETF process <xref target="RFC6838"/> by production of, istered
or reference to, a standards-track RFC that defines the format.</t> through the IETF process <xref target="RFC6838" format="default"/> by
production of,
<t>For other protocols, formats MAY be registered according to the or reference to, a Standards Track RFC that defines the format.</t>
rules of the associated "proto" specification.</t> <t>For other protocols, formats <bcp14>MAY</bcp14> be registered accor
ding to the
<t>Registrations of new formats MUST specify which transport rules of the associated &lt;proto&gt; specification.</t>
<t>Registrations of new formats <bcp14>MUST</bcp14> specify which tran
sport
protocols they apply to.</t> protocols they apply to.</t>
</section> </section>
<section anchor="AttributeNames" numbered="true" toc="default">
<section title="Attribute Names (&quot;att-field&quot;)"> <name>Attribute Names (&lt;attribute-name&gt;)</name>
<t>Attribute-field names (&lt;attribute-name&gt;) <bcp14>MUST</bcp14>
<t>Attribute-field names ("att-field") MUST be registered with be registered with
IANA and documented, to avoid any issues due to IANA and documented to avoid any issues due to
conflicting attribute definitions under the same name. conflicting attribute definitions under the same name.
(While unknown attributes in (While unknown attributes in
SDP are simply ignored, conflicting ones that fragment the SDP are simply ignored, conflicting ones that fragment the
protocol are a serious problem.)</t> protocol are a serious problem.)</t>
<t>The format of the &lt;attribute-name&gt; registry is:</t>
<table anchor="attRegformat">
<name>Format of the &lt;attribute-name&gt; Registry</name>
<tbody>
<tr>
<th>Type</th>
<th>SDP Name</th>
<th>Usage Level</th>
<th>Mux Category</th>
<th>Reference</th>
</tr>
</tbody>
</table>
<t>The format of the attribute registry is:</t> <t>For example, the attribute "a=lang:", which is defined for both
<t><figure>
<artwork>
| | | | Mux | |
| Type | SDP Name | Usage Level | Category | Reference |
</artwork>
</figure></t>
<t>For example, the attribute "setup" which is defined for both
session and media level, will be listed in the new registry as session and media level, will be listed in the new registry as
follows:</t> follows:</t>
<table anchor="attReg">
<t><figure> <name>&lt;attribute-name&gt; Registry Example</name>
<artwork> <thead>
| | | | Mux | | <tr>
| Type | SDP Name | Usage Level | Category | Reference | <th>Type</th>
|----------|------------|----------------|----------|----------------| <th>SDP Name</th>
|attribute |setup | session,media, |IDENTICAL | [RFC4145] | <th>Usage Level</th>
| | | dcsa,dcsa(msrp)| | [RFC6135] | <th>Mux Category</th>
| | | | | [I-D.mmusic- | <th>Reference</th>
| | | | | msrp-usage- | </tr>
| | | | | data-channel] | </thead>
</artwork> <tbody>
</figure></t> <tr>
<td>attribute</td>
<t>This one registry combines all of the previous usage-level-specific <td>lang</td>
"att-field" <td>session, media</td>
registries, including updates made by <xref target="I-D.ietf-mmusic-sd <td>TRANSPORT</td>
p-mux-attributes"/>. <td>[RFC8866]
IANA is requested to do the necessary reformatting.</t> <xref target="RFC8859" format="default"/>
</td>
<t><xref target="attrs"/> of this document replaces the initial set of </tr>
attribute definitions made by <xref target="RFC4566"/>. </tbody>
IANA is requested to update the registry accordingly.</t> </table>
<t>This one &lt;attribute-name&gt; registry combines all of the previo
us usage-level-specific "att-field"
registries, including updates made by <xref target="RFC8859" format="d
efault"/>,
and renames the "att-field" registry to the
"attribute-name (formerly "att-field")" registry.
IANA has completed the necessary reformatting.</t>
<t><xref target="attrs" format="default"/> of this document replaces t
he initial set of
attribute definitions made by <xref target="RFC4566" format="default"/
>.
IANA has updated the registry accordingly.</t>
<t>Documents can define new attributes and can also extend the <t>Documents can define new attributes and can also extend the
definitions of previously defined attributes:</t> definitions of previously defined attributes.</t>
<section anchor="newatt" numbered="true" toc="default">
<section anchor="newatt" title="New Attributes"> <name>New Attributes</name>
<t>New attribute registrations are accepted according to the <t>New attribute registrations are accepted according to the
"Specification Required" policy of <xref target="RFC8126"/>, "Specification Required" policy of <xref target="RFC8126" format="de fault"/>,
provided that the specification includes the following provided that the specification includes the following
information:</t> information:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Contact name</li>
<t>Contact Name.</t> <li>Contact email address</li>
<li>Attribute name: the name of the attribute that will appear
<t>Contact Email Address.</t> in SDP. This <bcp14>MUST</bcp14> conform to the definition of
&lt;attribute-name&gt;.</li>
<t>Attribute Name: The name of the attribute that will appear <li>Attribute syntax: for a value attribute (see <xref target="att
in SDP). This MUST conform to the definition of ribspec" format="default"/>),
&lt;att-field&gt;.</t> an ABNF definition of the attribute value &lt;attribute-value&gt
;
<t>Attribute Syntax: For a value attribute (see clause 5.13), syntax (see <xref target="abnf" format="default"/>) <bcp14>MUST<
an ABNF definition of the attribute value &lt;att-value&gt; /bcp14> be provided.
syntax (see <xref target="abnf"/>) MUST be provided. The syntax <bcp14>MUST</bcp14> follow the rule form per
The syntax MUST follow the rule form as per Section 2.2 of <xref target="RFC5234" section="2.2" sectionFormat="of" format="
<xref target="RFC5234"/> and <xref target="RFC7405"/>. This SHAL default"/>
L define the allowable and <xref target="RFC7405" format="default"/>. This <bcp14>SHALL
values that the attribute might take. It MAY also define an </bcp14> define the allowable
values that the attribute might take. It <bcp14>MAY</bcp14> also
define an
extension method for the addition of future values. For a extension method for the addition of future values. For a
property attribute, the ABNF definition is omitted as the property attribute, the ABNF definition is omitted as the
property attribute takes no values.</t> property attribute takes no values.</li>
<li>Attribute semantics: for a value attribute, a semantic
<t>Attribute Semantics: For a value attribute, a semantic description of the values that the attribute might take <bcp14>M
description of the values that the attribute might take MUST UST</bcp14>
be provided. The usage of a property attribute is described be provided. The usage of a property attribute is described
under purpose below.</t> under Purpose below.</li>
<li>Attribute value: the name of an ABNF syntax rule defining
<t>Attribute Value: The name of an ABNF syntax rule defining
the syntax of the value. Absence of a rule name indicates that the syntax of the value. Absence of a rule name indicates that
the attribute takes no values. Enclosing the rule name in "[" the attribute takes no values. Enclosing the rule name in "["
and "]" indicates that a value is optional.</t> and "]" indicates that a value is optional.</li>
<li>Usage level: the usage level(s) of the attribute.
<t>Usage Level: Usage level(s) of the attribute. This <bcp14>MUST</bcp14> be one or more of the following:
This MUST be one or more of the following: session, media, source, dcsa, and dcsa(subprotocol).
session, media, source, dcsa and dcsa(subprotocol). For a definition of source-level attributes, see <xref target="R
For a definition of source level attributes, see <xref FC5576" format="default"/>.
target="RFC5576"/>. For a definition of dcsa attributes see: For a definition of dcsa attributes see
<xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.</t> <xref target="RFC8864" format="default"/>.</li>
<li>Charset dependent: this <bcp14>MUST</bcp14> be "Yes" or "No" d
<t>Charset Dependent: This MUST be "Yes" or "No" depending epending
on whether the attribute value is subject to the charset attribu on whether the attribute value is subject to the "a=charset:" at
te.</t> tribute.</li>
<li>Purpose: an explanation of the purpose and usage of the
<t>Purpose: An explanation of the purpose and usage of the attribute.</li>
attribute.</t> <li>O/A procedures: offer/answer procedures as explained in
<xref target="RFC3264" format="default"/>.</li>
<t>O/A Procedures: Offer/Answer procedures as explained in <li>Mux Category: this <bcp14>MUST</bcp14> indicate one of the fol
<xref target="RFC3264"/>.</t> lowing
<t>Mux Category: This MUST indicate one of the following
categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT,
INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by INHERIT, IDENTICAL-PER-PT, SPECIAL, or TBD as defined by
[I-D.ietf-mmusic-sdp-mux-attributes].</t> <xref target="RFC8859" format="default"/>.</li>
<li>Reference: a reference to the specification defining the
<t>Reference: A reference to the specification defining the attribute.</li>
attribute.</t> </ul>
</list></t>
<t>The above is the minimum that IANA will accept. Attributes that <t>The above is the minimum that IANA will accept. Attributes that
are expected to see widespread use and interoperability SHOULD be are expected to see widespread use and interoperability <bcp14>SHOUL
documented with a standards-track RFC that specifies the attribute D</bcp14> be
documented with a Standards Track RFC that specifies the attribute
more precisely.</t> more precisely.</t>
<t>Submitters of registrations should ensure that the <t>Submitters of registrations should ensure that the
specification is in the spirit of SDP attributes, most notably specification is in the spirit of SDP attributes, most notably
that the attribute is platform independent in the sense that it that the attribute is platform independent in the sense that it
makes no implicit assumptions about operating systems and does not makes no implicit assumptions about operating systems and does not
name specific pieces of software in a manner that might inhibit name specific pieces of software in a manner that might inhibit
interoperability.</t> interoperability.</t>
<t>Submitters of registrations should also carefully choose the <t>Submitters of registrations should also carefully choose the
attribute usage level. They should not choose only "session" when attribute usage level. They should not choose only "session" when
the attribute can have different values when media is the attribute can have different values when media is
disaggregated, i.e., when each m= section has its own IP address disaggregated, i.e., when each "m=" section has its own IP address
on a different endpoint. In that case the attribute type chosen on a different endpoint. In that case, the attribute type chosen
should be "session, media" or "media" (depending on desired semantic s). should be "session, media" or "media" (depending on desired semantic s).
The default rule is that for all new The default rule is that for all new
SDP attributes that can occur both in session and media level, the SDP attributes that can occur both in session and media level, the
media level overrides the session level. When this is not the case media level overrides the session level. When this is not the case
for a new SDP attribute, it MUST be explicitly stated.</t> for a new SDP attribute, it <bcp14>MUST</bcp14> be explicitly stated
.</t>
<t>IANA has registered the initial set of attribute names <t>IANA has registered the initial set of attribute names
("att-field" values) with definitions as in <xref (&lt;attribute-name&gt; values) with definitions as in <xref target=
target="attrs"/> of this memo (these definitions replace those in "attrs" format="default"/>
<xref target="RFC4566"/>).</t> of this memo (these definitions replace those in
<xref target="RFC4566" format="default"/>).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Updates to Existing Attributes"> <name>Updates to Existing Attributes</name>
<t>Updated attribute registrations are accepted according to the <t>Updated attribute registrations are accepted according to the
"Specification Required" policy of <xref target="RFC8126"/>.</t> "Specification Required" policy of <xref target="RFC8126" format="de
fault"/>.</t>
<t>The Designated Expert reviewing the update is requested to evalua te <t>The Designated Expert reviewing the update is requested to evalua te
whether the update is compatible with the prior intent and use of th e attribute, whether the update is compatible with the prior intent and use of th e attribute,
and whether the new document is of sufficient maturity and authority in and whether the new document is of sufficient maturity and authority in
relation to the prior document. relation to the prior document.
</t> </t>
<t>The specification updating the attribute (for <t>The specification updating the attribute (for
example, by adding a new value) MUST update registration example, by adding a new value) <bcp14>MUST</bcp14> update registrat
information items from <xref target="newatt"/> according ion
information items from <xref target="newatt" format="default"/> acc
ording
to the following constraints:</t> to the following constraints:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Contact name: a name for an entity
<t>Contact Name: A name for an entity responsible for the update <bcp14>MUST</bcp14> be provided.</li>
responsible for the update MUST be provided.</t> <li>Contact email address: an email address for an entity
responsible for the update <bcp14>MUST</bcp14> be provided.</li>
<t>Contact Email Address: An email address for an entity <li>Attribute name: <bcp14>MUST</bcp14> be provided and <bcp14>MUS
responsible for the update MUST be provided.</t> T NOT</bcp14> be changed.
Otherwise it is a new attribute.</li>
<t>Attribute Name: MUST be provided and MUST NOT be changed. <li>Attribute syntax: the existing rule syntax with the syntax
Otherwise it is a new attribute.</t> extensions <bcp14>MUST</bcp14> be provided if there is a change
to the
<t>Attribute Syntax: The existing rule syntax with the syntax syntax. A revision to an existing attribute usage <bcp14>MAY</bc
extensions MUST be provided if there is a change to the p14> extend
syntax. A revision to an existing attribute usage MAY extend the syntax of an attribute, but <bcp14>MUST</bcp14> be backward
the syntax of an attribute, but MUST be backward compatible.</li>
compatible.</t> <li>Attribute semantics: a semantic description of new
<t>Attribute Semantics: A semantic description of new
additional attribute values or a semantic extension of additional attribute values or a semantic extension of
existing values. Existing attribute values semantics MUST only existing values. Existing attribute values semantics <bcp14>MUST
be extended in a backward compatible manner.</t> </bcp14> only
be extended in a backward compatible manner.</li>
<t>Usage Level: Updates MAY only add additional levels.</t> <li>Usage level: updates <bcp14>MAY</bcp14> only add additional le
vels.</li>
<t>Charset Dependent: MUST NOT be changed.</t> <li>Charset dependent: <bcp14>MUST NOT</bcp14> be changed.</li>
<li>Purpose: <bcp14>MAY</bcp14> be extended according to the updat
<t>Purpose: MAY be extended according to the updated ed
usage.</t> usage.</li>
<li>O/A procedures: <bcp14>MAY</bcp14> be updated in a backward co
<t>O/A Procedures: MAY be updated in a backward compatible mpatible
manner and/or it applies to a new usage level only.</t> manner and/or it applies to a new usage level only.</li>
<li>Mux Category: no change unless from "TBD" to another value
<t>Mux Category: No change unless from "TBD" to another value (see <xref target="RFC8859" format="default"/>.
(see <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>. It <bcp14>MAY</bcp14> also change if media level is being added
It MAY also change if 'media' level is being added to the to the
definition of an attribute that previously did not include definition of an attribute that previously did not include
it.</t> it.</li>
<li>Reference: a new (additional or replacement) reference <bcp14>
<t>Reference: A new (additional or replacement) reference MUST b MUST</bcp14> be provided.</li>
e provided.</t> </ul>
</list></t> <t>Items <bcp14>SHOULD</bcp14> be omitted if there is no impact to t
hem as a
<t>Items SHOULD be omitted if there is no impact to them as a
result of the attribute update.</t> result of the attribute update.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Bandwidth Specifiers (&quot;bwtype&quot;)"> <name>Bandwidth Specifiers (&lt;bwtype&gt;)</name>
<t>A proliferation of bandwidth specifiers is strongly <t>A proliferation of bandwidth specifiers is strongly
discouraged.</t> discouraged.</t>
<t>New bandwidth specifiers (&lt;bwtype&gt; subfield values) <bcp14>MU
<t>New bandwidth specifiers (&lt;bwtype&gt; sub-field values) MUST be ST</bcp14> be registered
registered with IANA. The submission <bcp14>MUST</bcp14> reference a Standards Tr
with IANA. The submission MUST reference a standards-track RFC ack RFC
specifying the semantics of the bandwidth specifier precisely, and specifying the semantics of the bandwidth specifier precisely, and
indicating when it should be used, and why the existing registered indicating when it should be used, and why the existing registered
bandwidth specifiers do not suffice.</t> bandwidth specifiers do not suffice.</t>
<t>The RFC <bcp14>MUST</bcp14> specify the Mux Category for this value
<t>The RFC MUST specify the Mux Category for this value as defined by as defined by
[I-D.ietf-mmusic-sdp-mux-attributes].</t> <xref target="RFC8859" format="default"/>.</t>
<t>The format of the &lt;bwtype&gt; registry is:</t>
<t>The format of the "bwtype" registry is:</t> <table anchor="bwtypeRegformat">
<name>Format of the &lt;bwtype&gt; Registry</name>
<t><figure> <tbody>
<artwork> <tr>
| Type | SDP Name | Mux Category | Reference | <th>Type</th>
</artwork> <th>SDP Name</th>
</figure></t> <th>Mux Category</th>
<th>Reference</th>
<t>IANA is requested to update the "bwtype" registry entries for the </tr>
</tbody>
</table>
<t>IANA has updated the &lt;bwtype&gt; registry entries for the
bandwidth specifiers "CT" and "AS" with the bandwidth specifiers "CT" and "AS" with the
definitions in Section 5.8 of this memo (these definitions replace definitions in <xref target="bandwidthInfo" format="default"/> of this
those in <xref target="RFC4566"/>).</t> memo (these definitions replace
those in <xref target="RFC4566" format="default"/>).</t>
</section> </section>
<section anchor="nettypereg" numbered="true" toc="default">
<section title="Network Types (&quot;nettype&quot;)"> <name>Network Types (&lt;nettype&gt;)</name>
<t>Network type "IN", representing the Internet, <t>Network type "IN", representing the Internet,
is defined in <xref target="origin-line"/> and is defined in <xref target="origin" format="default"/> and
<xref target="connection-information"/> of this memo. <xref target="connection-information" format="default"/> of this memo
(This definition replaces that in <xref target="RFC4566"/>.)</t> (this definition replaces that in <xref target="RFC4566" format="defau
lt"/>).</t>
<t>To enable SDP to reference a new non-Internet environment <t>To enable SDP to reference a new non-Internet environment,
a new network type (&lt;nettype&gt; sub-field value) MUST be registere a new network type (&lt;nettype&gt; subfield value) <bcp14>MUST</bcp14
d > be registered
with IANA. The registration is subject to the "RFC Required" policy with IANA. The registration is subject to the "RFC Required" policy
of <xref target="RFC8126"/>. Although non-Internet environments are of <xref target="RFC8126" format="default"/>. Although non-Internet en vironments are
not normally the preserve of IANA, there may be circumstances when not normally the preserve of IANA, there may be circumstances when
an Internet application needs to interoperate with a non-Internet an Internet application needs to interoperate with a non-Internet
application, such as when gatewaying an Internet telephone call into application, such as when gatewaying an Internet telephone call into
the Public Switched Telephone Network (PSTN). The number of network the Public Switched Telephone Network (PSTN). The number of network
types should be small and should be rarely extended. A new network typ e types should be small and should be rarely extended. A new network typ e
registration MUST reference an RFC that gives details of the network registration <bcp14>MUST</bcp14> reference an RFC that gives details o f the network
type and the address type(s) that may be used with it.</t> type and the address type(s) that may be used with it.</t>
<t>The format of the &lt;nettype&gt; registry is:</t>
<t>The format of the "nettype" registry is:</t> <table anchor="nettypeRegformat">
<name>Format of the &lt;nettype&gt; Registry</name>
<t><figure> <tbody>
<artwork> <tr>
|Type | SDP Name | Usable addrtype Values | Reference | <th>Type</th>
</artwork> <th>SDP Name</th>
</figure></t> <th>Usable addrtype Values</th>
<th>Reference</th>
<t>IANA is requested to update the "nettype" registry to this </tr>
new format. The following is the updated content of th registry: </t> </tbody>
</table>
<t><figure> <t>IANA has updated the &lt;nettype&gt; registry to this
<artwork> new format. The following is the updated content of the registry: </t>
|Type | SDP Name | Usable addrtype Values | Reference | <table anchor="nettypeReg">
|nettype | IN | IP4, IP6 | [RFCXXXX] | <name>Content of the &lt;nettype&gt; registry</name>
|nettype | TN | RFC2543 | [RFC2848] | <thead>
|nettype | ATM | NSAP, GWID, E164 | [RFC3108] | <tr>
|nettype | PSTN | E164 | [RFC7195] | <th>Type</th>
</artwork> <th>SDP Name</th>
</figure></t> <th>Usable addrtype Values</th>
<th>Reference</th>
<t>Note that both [RFC7195] and [RFC3108] registered "E164" as an </tr>
address type, although [RFC7195] mentions that the "E164" address type </thead>
<tbody>
<tr>
<td>nettype</td>
<td>IN</td>
<td>IP4, IP6</td>
<td>[RFC8866]</td>
</tr>
<tr>
<td>nettype</td>
<td>TN</td>
<td>RFC2543</td>
<td><xref target="RFC2848" format="default"/></td>
</tr>
<tr>
<td>nettype</td>
<td>ATM</td>
<td>NSAP, GWID, E164</td>
<td><xref target="RFC3108" format="default"/></td>
</tr>
<tr>
<td>nettype</td>
<td>PSTN</td>
<td>E164</td>
<td><xref target="RFC7195" format="default"/></td>
</tr>
</tbody>
</table>
<t>Note that both <xref target="RFC7195" format="default"/>
and <xref target="RFC3108" format="default"/> registered "E164" as an
address type, although <xref target="RFC7195" format="default"/> menti
ons that the "E164" address type
has a different context for ATM and PSTN networks.</t> has a different context for ATM and PSTN networks.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Address Types (&quot;addrtype&quot;)"> <name>Address Types (&lt;addrtype&gt;)</name>
<t>New address types ("addrtype") MUST be registered with IANA. The <t>New address types (&lt;addrtype&gt;) <bcp14>MUST</bcp14> be registe
red with IANA. The
registration is subject to the "RFC Required" policy registration is subject to the "RFC Required" policy
of <xref target="RFC8126"/>. A new address type registration of <xref target="RFC8126" format="default"/>. A new address type regis
MUST reference an RFC giving details of the syntax of the address tration
<bcp14>MUST</bcp14> reference an RFC, giving details of the syntax of
the address
type. Address types are not expected to be registered type. Address types are not expected to be registered
frequently.</t> frequently.</t>
<t><xref target="connection-information" format="default"/> of this do
<t><xref target="connection-information"/> of this document gives cument gives
new definitions of address types "IP4" and "IP6".</t> new definitions of address types "IP4" and "IP6".</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Encryption Key Access Methods (OBSOLETE)"> <name>Encryption Key Access Methods (OBSOLETE)</name>
<t>The IANA previously maintained a table of SDP encryption key access <t>The IANA previously maintained a table of SDP encryption key access
method ("enckey") names. This table is obsolete, since the "k=" line method ("enckey") names. This table is obsolete, since the "k=" line
is not extensible. New registrations MUST NOT be accepted.</t> is not extensible. New registrations <bcp14>MUST NOT</bcp14> be accepted .</t>
</section> </section>
</section> </section>
<section anchor="abnf" numbered="true" toc="default">
<section anchor="abnf" title="SDP Grammar"> <name>SDP Grammar</name>
<t>This section provides an Augmented BNF grammar for SDP. ABNF is <t>This section provides an Augmented BNF grammar for SDP. ABNF is
defined in <xref target="RFC5234"/> and <xref target="RFC7405"/>.</t> defined in <xref target="RFC5234" format="default"/> and <xref target="RFC 7405" format="default"/>.</t>
<figure> <sourcecode type="abnf" name="sdp-syntax.abnf"><![CDATA[
<artwork><![CDATA[
; SDP Syntax ; SDP Syntax
session-description = version-field session-description = version-field
origin-field origin-field
session-name-field session-name-field
[information-field] [information-field]
[uri-field] [uri-field]
*email-field *email-field
*phone-field *phone-field
[connection-field] [connection-field]
*bandwidth-field *bandwidth-field
skipping to change at line 2836 skipping to change at line 2368
%s"base64:" base64 / %s"base64:" base64 /
%s"uri:" uri %s"uri:" uri
; NOTE: These names are case-sensitive. ; NOTE: These names are case-sensitive.
base64 = *base64-unit [base64-pad] base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "=" base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/" base64-char = ALPHA / DIGIT / "+" / "/"
; sub-rules of 'a=' ; sub-rules of 'a='
attribute = (att-field ":" att-value) / att-field attribute = (attribute-name ":" attribute-value) /
attribute-name
att-field = token attribute-name = token
att-value = byte-string attribute-value = byte-string
att-field = attribute-name ; for backward compatibility
; sub-rules of 'm=' ; sub-rules of 'm='
media = token media = token
;typically "audio", "video", "text", "image" ;typically "audio", "video", "text", "image"
;or "application" ;or "application"
fmt = token fmt = token
;typically an RTP payload type for audio ;typically an RTP payload type for audio
;and video media ;and video media
proto = token *("/" token) proto = token *("/" token)
;typically "RTP/AVP" or "udp" ;typically "RTP/AVP", "RTP/SAVP", "udp",
;or "RTP/SAVPF"
port = 1*DIGIT port = 1*DIGIT
; generic sub-rules: addressing ; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / FQDN multicast-address = IP4-multicast / IP6-multicast / FQDN
/ extn-addr / extn-addr
IP4-multicast = m1 3( "." decimal-uchar ) IP4-multicast = m1 3( "." decimal-uchar )
skipping to change at line 2948 skipping to change at line 2484
POS-DIGIT = %x31-39 ; 1 - 9 POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT decimal-uchar = DIGIT
/ POS-DIGIT DIGIT / POS-DIGIT DIGIT
/ ("1" 2(DIGIT)) / ("1" 2(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; external references: ; external references:
ALPHA = <ALPHA definition from RFC5234> ALPHA = <ALPHA definition from RFC 5234>
DIGIT = <DIGIT definition from RFC5234> DIGIT = <DIGIT definition from RFC 5234>
CRLF = <CRLF definition from RFC5234> CRLF = <CRLF definition from RFC 5234>
HEXDIG = <HEXDIG definition from RFC5234> HEXDIG = <HEXDIG definition from RFC 5234>
SP = <SP definition from RFC5234> SP = <SP definition from RFC 5234>
VCHAR = <VCHAR definition from RFC5234> VCHAR = <VCHAR definition from RFC 5234>
URI-reference = <URI-reference definition from RFC3986> URI-reference = <URI-reference definition from RFC 3986>
addr-spec = <addr-spec definition from RFC5322> addr-spec = <addr-spec definition from RFC 5322>
]]> </artwork> ]]></sourcecode>
</figure>
</section> </section>
<section anchor="changes" numbered="true" toc="default">
<section anchor="changes" title="Summary of Changes from RFC 4566"> <name>Summary of Changes from RFC 4566</name>
<t><list style="symbols"> <ul spacing="normal">
<t>Generally clarified and refined terminology.</t> <li>Generally clarified and refined terminology. Aligned terms used in
text with the ABNF. The terms &lt;attribute&gt;, &lt;att-field&gt;, and
<t>Identified now-obsolete items: "a=cat", "a=keywds", "k=".</t> "att-field" are now &lt;attribute-name&gt;. The terms &lt;value&gt; and
&lt;att-value&gt; are now &lt;attribute-value&gt;. The term "media" is now
<t>Updated normative and informative references, and added references &lt;media&gt;. </li>
to additional relevant related RFCs.</t> <li>Identified now-obsolete items: "a=cat:" (<xref target="cat" format="
default"/>),
<t>Reformatted the SDP Attributes section for readability. "a=keywds:" (<xref target="keywds" format="default"/>), and "k="
The syntax of attribute values is now given in ABNF.</t> (<xref target="key-field" format="default"/>).</li>
<li>Updated normative and informative references, and added references
<t>Made mandatory the sending of RTCP with inactive media streams.</t to additional relevant related RFCs.</li>
> <li>Reformatted the SDP Attributes section (<xref target="attrs" format=
"default"/>) for readability.
<t>Removed the section "Private Sessions". That section dates back to The syntax of attribute values is now given in ABNF.</li>
a time <li>Made mandatory the sending of RTCP with inactive media streams (<xre
when the primary use of SDP was with SAP (Session Announcement Protoc f target="inactive" format="default"/>).</li>
ol). <li>Removed the section "Private Sessions". That section dated back to a
That has fallen out of use. Now the vast majority of uses of SDP is time
when the primary use of SDP was with SAP (Session Announcement Protoc
ol),
which has fallen out of use. Now the vast majority of uses of SDP is
for establishment of private sessions. The considerations for that ar e for establishment of private sessions. The considerations for that ar e
covered in <xref target="security"/>.</t> covered in <xref target="security" format="default"/>.</li>
<li>Expanded and clarified the specification of the "a=lang:" (<xref tar
<t>Expanded and clarified the specification of the "lang" get="lang" format="default"/>)
and "sdplang" attributes.</t> and "a=sdplang:" (<xref target="sdplang" format="default"/>) attri
butes.</li>
<t>Removed some references to SAP because it is no longer in widespre <li>Removed some references to SAP because it is no longer in widespread
ad use.</t> use.</li>
<li>Changed the way &lt;fmt&gt; values for UDP transport are registered
<t>Changed the way &lt;fmt&gt; values for UDP transport are registere (<xref target="protoreg" format="default"/>).</li>
d.</t> <li>Changed the mechanism and documentation required for
registering new attributes (<xref target="newatt" format="default"
<t>Changed the mechanism and documentation required for />).</li>
registering new attributes.</t> <li>Tightened up IANA registration procedures for extensions.
Removed phone number and long-form name (<xref target="SDP_Paramet
<t>Tightened up IANA registration procedures for extensions. ers" format="default"/>).</li>
Removed phone number and long-form name.</t> <li>Expanded the IANA &lt;nettype&gt; registry to identify valid &lt;add
rtype&gt; subfields (<xref target="nettypereg" format="default"/>).</li>
<t>Expanded the IANA nettype registry to identify valid addrtypes.</t <li>Reorganized the several IANA "att-field" registries
> into a single &lt;attribute-name&gt; registry (<xref target="Attri
buteNames" format="default"/>).</li>
<t>Reorganized the several IANA att-type registries <li>
into a single registry</t> <t>Revised ABNF syntax (<xref target="abnf" format="default"/>) f
or clarity
<t>Revised ABNF syntax for clarity. and for alignment with text. Backward compatibility is
Backward compatibility is maintained with a few exceptions: maintained with a few exceptions. Of particular note: </t>
<list style="symbols"> <ul spacing="normal">
<t>Revised the syntax of time descriptions ("t=", "r=", "z=") <li>Revised the syntax of time descriptions ("t=", "r=", "z=") to
to remove ambiguities. Clarified that "z=" only modifies remove ambiguities. Clarified that "z=" only modifies the
the immediately preceding "r=" lines. Made "z=" without a immediately preceding "r=" lines. Made "z=" without a
preceding "r=" a syntax error. preceding "r=" a syntax error (<xref target="tzadj" format="defaul
(This is incompatible with certain aberrant usage.)</t> t"/>).
<t>Updated the "IP6-address" and "IP6-multicast" rules, (This is incompatible with certain aberrant usage.)</li>
consistent with the syntax in RFC3986. <li>Updated the "IP6-address" and "IP6-multicast" rules, consistent
(This mirrors a bug fix made to RFC3261 by RFC5964.) with the syntax in <xref target="RFC3986" format="default"/>, mir
Removed rules that were unused as a result of this change. roring a bug fix made to
</t> </list> <xref target="RFC3261" format="default"/> by <xref target="RFC595
</t> 4" format="default"/>.
Removed rules that were unused as a result of this change.</li>
<t>Revised normative statements that were redundant with ABNF syntax <li>The "att-field" rule has been renamed "attribute-name" because
, elsewhere "*-field" always refers to a complete line. However,
making the text non-normative.</t> the rulename "att-field" remains defined as a synonym for
backward compatibility with references from other RFCs.</li>
<t>Revised IPv4 unicast and multicast addresses in the <li>The "att-value" rule has been renamed "attribute-value".</li>
example SDP descriptions per RFCs 5735 and 5771.</t> </ul>
</li>
<t>Changed some examples to use IPv6 addresses, and added additional <li>Revised normative statements that were redundant with ABNF syntax,
examples using IPv6.</t> making the text non-normative.</li>
<t>Incorporated case-insensitivity rules from RFC 4855.</t>
<t>Revised sections that incorrectly referenced NTP.</t>
<t>Clarified the explanation of the impact and use of a=charset.</t>
<t>Revised the description of a=type to remove implication that it
sometimes changes the default media direction to something other tha
n sendrecv.</t> </list></t>
</section>
<section title="Acknowledgements">
<t>Many people in the IETF Multiparty Multimedia Session Control
(MMUSIC) working group have made comments and suggestions contributing
to this document.</t>
<t>In particular, we would like to thank the following people who contribu <li>Revised IPv4 unicast and multicast addresses in the
ted example SDP descriptions per <xref target="RFC5735"/> and <xref
to the creation of this document or one of its predecessor documents: target="RFC5771"/>.</li>
Adam Roach, Allison Mankin, Bernie Hoeneisen, Bill Fenner, Carsten Bormann, <li>Changed some examples to use IPv6 addresses, and added additional
Eve Schooler, Flemming Andreasen, Gonzalo Camarillo, Joerg Ott, John Elwel examples using IPv6.</li>
l, <li>Incorporated case-insensitivity rules from <xref target="RFC4855" fo
Jon Peterson, Jonathan Lennox, Jonathan Rosenberg, Keith Drage, Peter Parn rmat="default"/>.</li>
es, <li>Revised sections that incorrectly referenced NTP (<xref target="orig
Rob Lanphier, Ross Finlayson, Sean Olson, Spencer Dawkins, Steve Casner, in" format="default"/>,
Steve Hanna, Van Jacobson.</t> <xref target="timing" format="default"/>, <xref target="repeattime"
format="default"/>, and
<xref target="tzadj" format="default"/>).</li>
<li>Clarified the explanation of the impact and use of the "a=charset:"
attribute
(<xref target="charset" format="default"/>).</li>
<li>Revised the description of the "a=type:" attribute to remove implica
tion that it
sometimes changes the default media direction to something other tha
n "a=sendrecv"
(<xref target="type" format="default"/>).</li>
</ul>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
&__reference.RFC.1034;
&__reference.RFC.1035; <references>
<name>References</name>
&__reference.RFC.2119; <references>
<name>Normative References</name>
&__reference.RFC.2848;
&__reference.RFC.2978;
&__reference.RFC.3108;
&__reference.RFC.3629;
&__reference.RFC.3986;
&__reference.RFC.4145;
&__reference.RFC.4566;
&__reference.RFC.5234;
&__reference.RFC.5576;
&__reference.RFC.5646;
&__reference.RFC.5890;
&__reference.RFC.5952;
&__reference.RFC.6135;
&__reference.RFC.7195;
&__reference.RFC.8126;
&__reference.RFC.8174;
&__reference.I-D.ietf-mmusic-data-channel-sdpneg;
&__reference.I-D.ietf-mmusic-sdp-mux-attributes;
&__reference.ISO.8859-1;
<reference anchor="E164">
<front>
<title>E.164 : The international public telecommunication numbering pl
an</title>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="November" year="2010"/>
</front>
<seriesInfo name="ITU" value="Recommendation E.164"/>
</reference>
</references>
<references title="Informative References">
&__reference.RFC.2045;
&__reference.RFC.2327;
&__reference.RFC.2974;
&__reference.RFC.3261;
&__reference.RFC.3264;
&__reference.RFC.3550;
&__reference.RFC.3551;
&__reference.RFC.3556; <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1034.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1035.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2848.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2978.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3108.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3629.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3986.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4566.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5234.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5576.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5646.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5890.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5952.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7195.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8126.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"
/>
&__reference.RFC.3605; <reference anchor="RFC8864" target="https://www.rfc-editor.org/info/rfc8864">
<front>
<title>Negotiation Data Channels Using the Session Description
Protocol (SDP)</title>
<author fullname="Keith Drage" initials="K." surname="Drage">
<organization>Unaffiliated</organization>
</author>
<author fullname="Raju Makaraju" initials="M." surname="Makaraju">
<organization>Nokia</organization>
</author>
<author fullname="Richard Ejzak" initials="R." surname="Ejzak">
<organization>Unaffiliated</organization>
</author>
<author fullname="Jerome Marcon" initials="J." surname="Marcon">
<organization>Unaffiliated</organization>
</author>
<author fullname="Roni Even" initials="R." surname="Even" role="editor">
<organization>Huawei</organization>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8864"/>
<seriesInfo name="DOI" value="10.17487/RFC8864"/>
</reference>
&__reference.RFC.3711; <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8
859">
<front>
<title>A Framework for Session Description Protocol (SDP)
Attributes When Multiplexing</title>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8859"/>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>
&__reference.RFC.3840; </reference>;
&__reference.RFC.3890; <reference anchor="ISO.8859-1.1998">
<front>
<title>Information technology - 8-bit single byte coded graphic - ch
aracter sets - Part 1: Latin alphabet No. 1, JTC1/SC2</title>
<author>
<organization>International Organization for Standardization</orga
nization>
</author>
<date month="" year="1998"/>
</front>
<seriesInfo name="ISO/IEC Standard" value="8859-1"/>
</reference>
&__reference.RFC.4568; <reference anchor="E164" target="https://www.itu.int/rec/T-REC-E.164-201
011-I/en">
<front>
<title>E.164 : The international public telecommunication numbering
plan</title>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="November" year="2010"/>
</front>
<seriesInfo name="ITU Recommendation" value="E.164"/>
</reference>
</references>
<references>
&__reference.RFC.4855; <name>Informative References</name>;
&__reference.RFC.5322; <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2045.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2327.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2974.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3261.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3264.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3550.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3551.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3556.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3605.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3711.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3840.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3890.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4568.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4855.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5124.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5322.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5735.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5771.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5888.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6466.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6838.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7230.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7405.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7656.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7826.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8445.xml"
/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5954.xml"
/>
&__reference.RFC.5888; <reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843"
>
<front>
<title>Negotiating Media Multiplexing Using the Session Description Prot
ocol (SDP)</title>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg">
<organization/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
<organization/>
</author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8843"/>
<seriesInfo name="DOI" value="10.17487/RFC8843"/>
</reference>
&__reference.RFC.6466; <reference anchor='RFC8839' target="https://www.rfc-editor.org/info/rfc8839">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactiv
e Connectivity Establishment (ICE)</title>
&__reference.RFC.6838; <author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
<organization />
</author>
&__reference.RFC.7230; <author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
<organization />
</author>
&__reference.RFC.7405; <author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
&__reference.RFC.7656; <author initials='A' surname='Keränen' fullname='Ari Keränen'>
<organization />
</author>
&__reference.RFC.7826; <author initials='R' surname='Shpount' fullname='Roman Shpount'>
<organization />
</author>
&__reference.RFC.8445; <date month="January" year="2021"/>;
&__reference.I-D.ietf-mmusic-sdp-bundle-negotiation; </front>
<seriesInfo name="RFC" value="8839"/>
<seriesInfo name="DOI" value="10.17487/RFC8839"/>
&__reference.I-D.ietf-mmusic-ice-sip-sdp; </reference>;
<reference anchor="ITU.H332.1998"> <reference anchor="ITU.H332.1998" target="https://www.itu.int/rec/T-REC-
<front> H.332-199809-I/en">
<title>H.323 extended for loosely coupled conferences</title> <front>
<author> <title>H.332 : H.323 extended for loosely coupled conferences</title
<organization>International Telecommunication Union</organization> >
</author> <author>
<date month="September" year="1998"/> <organization>International Telecommunication Union</organization>
</front> </author>
<seriesInfo name="ITU" value="Recommendation H.332"/> <date month="September" year="1998"/>
</reference> </front>
<seriesInfo name="ITU Recommendation" value="H.332"/>
</reference>
</references>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Many people in the IETF Multiparty Multimedia Session Control
(MMUSIC) working group have made comments and suggestions contributing
to this document.</t>
<t>In particular, we would like to thank the following people who contribu
ted
to the creation of this document or one of its predecessor documents:
<contact fullname="Adam Roach"/>, <contact fullname="Allison Mankin"/>,
<contact fullname="Bernie Hoeneisen"/>, <contact fullname="Bill Fenner"/>,
<contact fullname="Carsten Bormann"/>, <contact fullname="Eve Schooler"/>,
<contact fullname="Flemming Andreasen"/>, <contact fullname="Gonzalo Camar
illo"/>,
<contact fullname="Jörg Ott"/>, <contact fullname="John Elwell"/>,
<contact fullname="Jon Peterson"/>, <contact fullname="Jonathan Lennox"/>,
<contact fullname="Jonathan Rosenberg"/>, <contact fullname="Keith Drage"/
>,
<contact fullname="Peter Parnes"/>, <contact fullname="Rob Lanphier"/>,
<contact fullname="Ross Finlayson"/>, <contact fullname="Sean Olson"/>,
<contact fullname="Spencer Dawkins"/>, <contact fullname="Steve Casner"/>,
<contact fullname="Steve Hanna"/>, <contact fullname="Van Jacobson"/>.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 467 change blocks. 
2037 lines changed or deleted 1822 lines changed or added

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