SDP：会话描述协议
摘要：
此文档规定了会话描述协议（SDP），SDP用于描述多媒体会话，用于会话通知、会话邀请和其他形式的多媒体会话建立。该文档废止了rfc4566
文档状态：
这是一个标准互联网跟踪文档。
此文档是互联网工程任务组（IETF）的一个产品。它代表了IETF组织的共识，它已接受公众评审，并已获互联网工程指导小组（IESG）批准出版。有关互联网标准的进一步信息，请参阅RFC 7841第2节。关于此文档的当前状态、任何勘误表以及如何提供反馈的信息可以在Information on RFC 8866 » RFC Editor上获得。
版权说明：
版权所有(c) 2021 IETF信托基金和被认定为文档的作者。保留所有权利。
本文件受BCP 78和IETF信托关于IETF文件的法律规定约束。
Trust Legal Provisions (TLP) – IETF Trust自本文件发布之日起生效。请仔细审阅这些文件，因为它们描述了您在此文件方面的权利和限制。从本文档中提取的代码组件必须包含第4节中描述的简化BSD许可证文本。并且不提供简化BSD许可证中所述的担保。
本文档可能包含在2008年11月10日前发布或公开的来自IETF文档或IETF贡献的材料。控制这些材料的某些版权的人可能没有授予IETF Trust允许在IETF标准过程之外修改这些材料的权利。没有从控制这些材料的版权的人那里获得足够的许可，本文档不得在IETF标准过程之外被修改，也不得在IETF标准过程之外被创作出其衍生作品。除非将其格式化为RFC或将其翻译成英语以外的语言。
目录
6.5maxptime（Maximum Packet Time最大数据包时长）
6.10charset (Character Set 字符集)
6.11sdplang (SDP Language SDP语言)
6.15fmtp (Format Parameters格式参数)
1.介绍
当发起多媒体电话会议、ip语音呼叫、流媒体视频或其他会话时，需要向参与者传递媒体细节、传输地址和其他会话描述元数据。
SDP为这些信息提供了一种标准的表示方式，而不管这些信息是如何传输的。SDP是一种纯粹的会话描述格式——它没有包含一个传输协议，它的目的是使用不同的传输协议，包括会话公告协议(SAP) [rfc2974]，会话发起协议(SIP) [rfc3261]，实时流协议(RTSP) [rfc7826]，电子邮件[rfc5322]使用MIME扩展[rfc2045]和超文本传输协议(HTTP) [rfc7230]。
SDP的目标是通用的，因此它可以在广泛的网络环境和应用中使用。然而，它并不打算支持会话内容或媒体编码的协商:这被视为会话描述的范围之外。
此文档废止了[rfc4566]。关于[rfc4566]的变更在本备忘录的第十节中概述。
2.术语表
以下术语在本文档中使用，在本文档的上下文中具有特定含义。
会话描述：一种定义良好的格式，用于传递足够的信息来发现和参与多媒体会话。
媒体描述：媒体描述包含了一方与另一方建立应用层网络协议连接所需的信息。它以“m=”行开始，并以下一个“m=”行或会话描述的结尾结束。
会话级部分：指的不是媒体描述的部分，而会话描述指的是包括会话级部分和媒体描述的整个主体。
“多媒体会议”和“多媒体会话”在本文档中使用，定义见[rfc7656]。术语“会话”和“多媒体会话”在本文档中互换使用。本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL”应按照BCP 14 [rfc2119] [rfc8174]的解释，当且仅当它们以大写字母出现时，如此处所示。
3.SDP使用实例
3.1会话初始化
SIP （会话初始化协议） [rfc3261]是一种应用层控制协议，用于创建、修改和终止诸如互联网多媒体会议、网络电话和多媒体分发等会话。用于创建会话的SIP消息携带会话描述，会话描述允许参与者同意一组一致的媒体类型[rfc6838]。这些会话描述通常使用SDP进行格式化。当与SIP一起使用时，提供/应答模型[rfc3264]为使用SDP进行协商提供了一个有限的框架。
3.2流媒体
实时流协议(RTSP) [rfc7826]，是一个应用级的协议，用于控制具有实时属性的数据的交付。RTSP提供了一个可扩展的框架，以支持控制、按需交付实时数据，如音频和视频。RTSP客户端和服务器为媒体传输协商一组适当的参数，部分使用SDP语法来描述这些参数。
3.3电子邮件和万维网
传递会议描述的另一种方式包括电子邮件和万维网（WWW）。对于电子邮件和WWW分发，媒体类型为“application/sdp”。这允许以标准方式从WWW客户机或邮件阅读器自动启动参与会话的应用程序。
注意多播会话的描述发送只通过电子邮件或没有特性的接收机会话描述的万维网一定可以接收会话，因为多播会话可能会限制范围，和访问WWW服务器或接收电子邮件可能是这个范围之外。
3.4多播会话公告
为了辅助多播多媒体会议和其他多播会话的发布，并将相关的会话设置信息传递给潜在的参与者，可以使用分布式会话目录。一个这样的例子一个会话目录的实例定期向众所周知的多播组发送包含会话描述的报文。这些通告由其他会话目录接收，以便潜在的远程参与者可以使用会话描述启动参与会话所需的工具。
用于实现这样一个分布式目录的协议是SAP [rfc2974]。SDP为此类会话公告提供了推荐的会话描述格式。
4.要求和建议
SDP的目的是在多媒体会话中传递关于媒体流的信息，以允许会话描述的接收者参与会话。SDP主要用于Internet协议，尽管它足够通用，可以描述其他网络环境中的多媒体会议。媒体流可以是多对多。会话不需要一直处于活动状态。
到目前为止，Internet上基于组播的会话与许多其他形式的会议的不同之处在于，任何接收到网址流量的人都可以加入会话(除非会话流量是加密的)。在这样的环境中，SDP主要用于两个目的。它是一种传递会话存在的方法，也是一种传递足够信息以支持加入和参与会话的方法。在单播环境中，只有后一种目的可能是相关的。
SDP描述包括以下内容:
*会话名称和意图
*会话处于活动状态的时间
*包含会话的媒体
*接收这些媒体所需的信息(地址、端口、格式等)
由于参与会话所需的资源可能有限，一些额外的信息也可能是需要的:
*会话使用的带宽信息
*负责会话的人的联系信息
通常，SDP必须传递足够的信息，以使应用能够加入会话(可能除了加密密钥)，并向任何可能需要知道的非参与者宣布要使用的资源。(当SDP与多播会话通知协议一起使用时，后一个特性非常有用。)
4.1媒体和传输信息
一个SDP描述包括以下媒体信息:
*媒体类型(视频，音频等)
*媒体传输协议(RTP/UDP/IP，H.320等)
*媒体格式(H.261视频，MPEG视频等)
除了媒体格式和传输协议，SDP还传递地址和端口的详细信息。对于IP组播会话，这些包括：
*用于媒体的组播组地址
*用于媒体的传输端口。
该地址和端口是组播流的目的地址和目的端口，无论发送、接收或两者兼有。对于单播IP会话，需要传递以下信息：
*媒体的目的地址
*媒体的目的传输端口
地址和端口的语义取决于上下文。通常，这应该是要发送或接收媒体的目的地址和目的端口。具体细节可能会因网络类型、地址类型、协议和指定的媒体而有所不同，以及SDP是作为一个广告发布还是在一个offer/answer[rfc3264]交换中协商。(例如，一些地址类型或协议可能没有端口的概念。)应该谨慎地偏离典型的行为，因为这使实现复杂化(包括必须解析地址以打开网络地址转换(NAT)或防火墙针孔的中间件)。
4.2时间信息
会话在时间上可以是有界的，也可以是无界的。无论它们是否有边界，它们可能只在特定时间处于活动状态。SDP可以传递：
*一个任意列表的开始和停止时间包围会话
*对于每个绑定，重复次数，如“every Wednesday at 10am for one hour”
这个计时信息是全球一致的，无论当地时区或夏令时(见章节5.9)。
4.3获取会话的进一步信息
会话描述可以传递足够的信息来决定是否参与会话。SDP可能会以统一资源标识符(Uniform Resource identifier, uri)的形式包含额外的指针[rfc3986]，以获取更多关于会话的信息。(请注意，使用uri来指示远程资源取决于[rfc3986]的安全考虑。)
4.4国际化
SDP规范建议使用UTF-8编码中的ISO10646字符集[rfc3629]来表示多种不同的语言。然而，为了帮助简化表示，SDP还允许在需要时使用其他字符集，如[ISO.8859-1.1998]。国际化只适用于自由文本的子字段(会话名称和背景信息)，而不适用于整个SDP。
5.SDP规范
一个SDP描述用媒体类型“application/ sdp”来表示(见第8节)。
SDP描述完全是文本的。SDP字段名和属性名只使用UTF-8的US-ASCII子集[rfc3629]，但是文本字段和属性值可以使用UTF-8编码的完整的ISO10646字符集，或者由"a=charset:"属性定义的其他字符集(章节6.10)。使用完整UTF-8字符集的字段和属性值永远不会直接比较，因此不需要UTF-8规范化。选择文本形式，而不是像ASN.1或XDR这样的二进制编码，是为了增强可移植性，允许使用多种传输方式，并允许使用灵活的、基于文本的工具包来生成和处理会话描述。但是，由于SDP可能用于限制会话描述的最大允许大小的环境中，因此编码是精心设计的紧凑。此外，由于描述可能通过非常不可靠的方式传输或被中间缓存服务器损坏，编码被设计成严格的顺序和格式规则，因此大多数错误将导致畸形的会话描述，可以很容易地检测到并丢弃。
一个SDP描述由许多行表单文本组成：
<type>=<value>
其中<type>是一个大小写有效的字符和<value>是结构化文本，其格式取决于<type>。一般来说<value>是由单个空格字符或自由格式字符串分隔的多个子字段，除非特定字段另有定义，否则大小写重要。空格分隔符不会在"="符号的两边使用，但是，值可以包含前导空格作为其语法的一部分，即，空格是值的一部分。
一个SDP描述必须符合第9节中定义的语法。下面是语法的概述。
一个SDP描述由一个会话级的部分和零个或多个媒体描述组成。会话级部分以“v=”行开始，并继续到第一个媒体描述(或整个描述的结尾，以先到的为准)。每个媒体描述以“m=”行开始，然后继续到下一个媒体描述或整个会话描述的结尾，以先到的为准。通常，会话级值是所有媒体的默认值，除非被一个等价的媒体级值覆盖。
每个描述中有些行是必需的，有些行是可选的，但是在出现时，它们必须完全按照这里给出的顺序出现。(固定的顺序大大增强了错误检测，并允许使用简单的解析器)。在下面的概述中，可选项被标记为“*”。
Session description 会话描述
v= (protocol version 协议版本)
o= (originator and session identifier 发起者和会话标识符)
s= (session name 会话名称)
i=* (session information 会话信息)
u=* (URI of description 有描述信息的uri)
e=* (email address 电子邮件地址)
p=* (phone number 电话号码)
c=* (connection information -- not required if included in
all media descriptions 连接信息--如果包含在所有媒体描述中，则不需要)
b=* (zero or more bandwidth information lines 0或多个带宽信息行)
One or more time descriptions 一个或多个时间描述：
("t=", "r=" and "z=" lines; see below)
k=* (obsolete 废弃的)
a=* (zero or more session attribute lines 0或多个会话属性行)
Zero or more media descriptions 0或者多个媒体描述行
Time description 时间描述
t= (time the session is active 会话活跃时间)
r=* (zero or more repeat times 0或多次重复)
z=* (optional time zone offset line 可选时区偏移行)
Media description, if present 媒体描述，如果存在的话
m= (media name and transport address 媒体名称和传输地址)
i=* (media title 媒体标题)
c=* (connection information -- optional if included at
session level 连接信息--如果包含在会话级别这里是可选的)
b=* (zero or more bandwidth information lines 0或者多个带宽信息行)
k=* (obsolete 废弃的)
a=* (zero or more media attribute lines 0或者多个媒体属性行)
类型字母的集合故意很小，不打算扩展——SDP解析器必须完全忽略或拒绝任何包含它不理解的类型字母的会话描述。属性机制(“a=”，在5.13节中描述)是扩展SDP并将其调整到特定应用程序或媒体的主要方法。有些属性(第6节中列出的属性)具有定义的含义，但其他属性可以在特定于媒体或会话的基础上添加。(除了特定于媒体和特定于会话的作用域之外，属性作用域也可以在本文档的扩展中定义，例如，[rfc5576]和[rfc8864])SDP解析器必须忽略它不能理解的任何属性。
一个SDP描述可能包含在“u=”，“k=”和“a=”行中引用外部内容的uri。在某些情况下，这些uri可能被解除引用，使会话描述非自包含的。
会话级部分中的连接("c=")信息适用于该会话的所有媒体描述，除非被媒体描述中的连接信息覆盖。例如，在下面的例子中，每个音频媒体描述的行为就好像给出了一个"c=IN IP4 198.51.100.1"。
一个SDP描述的例子：
v=0
o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1
s=Call to John Smith
i=SDP Offer #1
u=http://www.jdoe.example.com/home.html
e=Jane Doe <jane@jdoe.example.com>
p=+1 617 555-6011
c=IN IP4 198.51.100.1
t=0 0
m=audio 49170 RTP/AVP 0
m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99
c=IN IP6 2001:db8::2
a=rtpmap:99 h263-1998/90000
包含文本的字段，如session-name-field和information-field，是八位字节字符串，可以包含除0x00 (Nul)、0x0a (ASCII换行符)和0x0d (ASCII回车符)以外的任何八位元。序列CRLF (0x0d0a)用于结束一行，尽管解析器应该是宽容的，也接受以一个换行符结束的行。如果"a=charset:"属性不存在，这些字节串必须解释为包含UTF-8编码的ISO-10646字符。当"a=charset:"属性出现时，session-name-field、information-field和一些属性字段将根据所选的字符集进行解释。
会话描述可以在“o=”，“u=”，“e=”，“c=”和“a=”行中包含域名。任何在SDP中使用的域名必须符合[rfc1034]和[rfc1035]。国际化域名(IDNS)必须使用在[rfc5890]中定义的ASCII兼容编码(ACE)形式表示，绝不能直接用UTF-8或任何其他编码形式表示(此要求是为了兼容[rfc2327]和其他sdp相关的早期标准，这早于国际化域名的发展)。
5.1协议版本（“v=”）
v=0
“v=”行(version-field)给出了会话描述协议的版本。此文档定义了版本0。没有次要版本号。
5.2起源（“o=”）
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
“o=”行(origin-field)给出了会话的发起者(她的用户名和用户主机的地址)加上会话标识符和版本号
<username> 是用户在原始主机上的登录，如果原始主机不支持用户id的概念，则为“-”。 <username>不能包含空格。
<sess-id> 是一个数字字符串，其元组为<username> <sess-id> <nettype> <addrtype>和 <unicast-address>形成会话的全局唯一标识符。<sess-id>分配由创建工具决定，但建议使用自1900 UTC 1月1日起以秒为单位的时间戳，以确保唯一性。
<sess-version> 是此会话描述的版本号。它的使用取决于创建工具，<sess-version>需要在对会话描述进行修改时增加。还有与<sess-id>一样建议使用时间戳。
<nettype> 是一个给出网络类型的文本字符串。最初，“IN”被定义为具有“Internet”的含义，但将来可能会注册其他值(见第8节)。
<addrtype> 是一个给出后面地址类型的文本字符串。最初，定义了“IP4”和“IP6”，但将来可能会注册其他值(见第8节)。
<unicast-address> 创建会话的机器的地址。对于地址类型“IP4”，这是该计算机的完全限定域名，或者是该计算机的IPv4地址的点分十进制表示。对于地址类型为“IP6”的机器，它要么是机器的完全限定域名，要么是[rfc5952]章节4中指定的机器地址。对于“IP4”和“IP6”，完全限定域名是应该给出的形式，除非这是不可用的，在这种情况下，可以替换一个全局唯一地址。
通常，“o=”行作为会话描述的这个版本的全局唯一标识符，而除了版本之外的子字段放在一起标识会话，而不受任何修改的影响。
出于隐私原因，有时需要混淆会话发起者的用户名和IP地址。如果这是一个担忧的话，只要选择的方式不影响字段的全局唯一性，可以选择一个任意的<username>和私有的<unicast-address>填充“o=”行。
5.3会话名称（“s=”）
s=<session name>
“s=”行(session-name-field)是文本形式的会话名称。每个会话描述必须有且只有一个“s=”行。"s="行不能为空。如果会话没有有意义的名称，则建议使用“s= ”或“s=-”(即使用空格或破折号作为会话名称)。如果存在会话级的"a=charset:"属性，它指定在"s="字段中使用的字符集。如果会话级的"a=charset:"属性不存在，"s="字段必须包含UTF-8编码的ISO10646字符。
5.4会话信息（“i=”）
i=<session information>
“i=”行(information-field)提供了文本形式的会话信息。每个会话描述最多只能有一行会话级的“i=”，每个媒体描述最多只能有一行“i=”。除非提供了媒体级的"i="行，否则会话级的"i="行适用于该媒体描述。如果"a=charset:"属性存在，它指定在"i="行中使用的字符集。如果"a=charset:"属性不存在，"i="行必须包含UTF-8编码的ISO10646字符。
每个媒体描述最多只能使用一行“i=”。在媒体定义中，“i=”行主要用于标记媒体流。因此，当一个会话有多个相同媒体类型的不同媒体流时，它们最有可能是有用的。举个例子，有两块不同的白板，一块用于幻灯片，一块用于反馈和提问。
“i=”行旨在提供一种自由的、人类可读的会话描述或媒体流的目的。它不适合用自动机进行解析。
5.5URI（“u=”）
u=<uri>
"u="行(uri-field)提供了一个URI(统一资源标识符)[rfc3986]。URI应该是一个指向有关会话的其他人类可读信息的指针。这一行是可选的。每个会话描述不允许超过一个"u="行。
5.6电子邮件地址和电话号码（“e=”和“p=”）
e=<email-address>
p=<phone-number>
“e=”行(email-field)和“p=”行(phone-field)指定负责会话的人的联系信息。这不一定和创建会话描述的是同一个人。
电子邮件地址或电话号码是可选的。
如果有电子邮件地址或电话号码，必须在第一个媒体描述之前指定。一个会话描述可以提供多个电子邮件或电话线路。
电话号码应以“+”开头的国际公共电信号码(见ITU-T建议E.164 [E164])的形式提供。如果需要的话，空格和连字符可以用来分隔电话字段，以提高可读性。例如
p=+1 617 555-6011
电子邮件地址和电话号码都可以有一个可选的自由文本字符串与它们相关联，通常给出可能联系的人的名字。如果它存在，必须用括号括起来。例如
e=j.doe@example.com (Jane Doe)
电子邮件地址和电话号码也允许使用[rfc5322]名称引用约定。例如
e=Jane Doe <j.doe@example.com>
自由文本字符串应该使用UTF-8编码的ISO-10646字符集，或者如果设置了适当的会话级"a=charset:"属性，则使用ISO-8859-1或其他编码。
5.7连接信息（“c=”）
c=<nettype> <addrtype> <connection-address>
“c=”行(connection-field)包含了建立网络连接所必需的信息。
一个会话描述必须在每个媒体描述中至少包含一个"c="行，或者在会话级别上包含一个"c="行。它可以包含一个单独的会话级"c="行和额外的媒体级"c="行(每一个媒体描述)，在这种情况下，媒体级值覆盖相应媒体的会话级设置。
第一个子字段(<nettype>)是网络类型，这是一个给出网络类型的文本字符串。最初，“IN”被定义为具有“Internet”的含义，但其他值可能在将来注册(见第8节)。
第二个子字段(<addrtype>)是地址类型。这允许SDP用于非基于IP的会话。此文档只定义了“IP4”和“IP6”，但是其他的值可以在将来注册(见第8节)。
第三个子字段(<connection-address>)是连接地址。根据<addrtype>的值，可以在连接地址后面添加额外的子字段。
当<addrtype>为“IP4”或“IP6”时，连接地址定义如下：
*如果会话是组播，连接地址将是一个IP组播组地址。如果会话不是组播，则连接地址包含预期数据源、数据中继或数据接收器的单播IP地址，由附加属性字段(章节5.13)确定。我们不希望单播地址在一个通过一个多播通告进行通信的会话描述中被给出，尽管这是不被禁止的。
*使用“IP4”组播连接地址的会话也必须有一个生存时间(TTL)值，除了组播地址。TTL和地址一起定义了在这个会话中发送的多播数据包将被发送的范围。TTL值必须在0 ~ 255之间。虽然TTL必须指定，但不赞成使用它来限定多播流量的范围；应用程序应该使用管理范围的地址。
会话的TTL使用一个斜杠作为分隔符附加到地址上。一个例子是：
c=IN IP4 233.252.0.1/127
“IP6”组播不使用TTL作用域，因此TTL值不能出现在“IP6”组播中。预计IPv6范围的地址将被用来限制多媒体会议的范围。
分层或分层编码方案是指将来自单一媒体源的编码分成若干层的数据流。接收者可以通过订阅这些层的一个子集来选择所需的质量(以及带宽)。这种分层编码通常在多个组播组中传输，以实现组播修剪。这种技术可以防止只需要特定层次结构的站点产生不必要的流量。对于需要多个多播组的应用程序，我们允许使用以下符号来表示连接地址
<base multicast address>[/<ttl>]/<number of addresses>
如果没有给出地址的数量，则假设为1。这样分配的多播地址在基址上面连续地分配，因此，例如：
c=IN IP4 233.252.0.1/127/3
会声明地址233.252.0.1，233.252.0.2和233.252.0.3将与TTL为127一起使用。这在语义上与在媒体描述中包含多个"c="行是相同的：
c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127
类似地，IPv6的例子也是如此：
c=IN IP6 ff00::db8:0:101/3
这在语义上相当于：
c=IN IP6 ff00::db8:0:101
c=IN IP6 ff00::db8:0:102
c=IN IP6 ff00::db8:0:103
（记住TTL子字段在“IP6”组播中是不存在的）
多个地址或"c="行可以在每个媒体描述的基础上指定，只有当它们在分层或分层编码方案中为不同层提供多播地址时。不能在会话级别指定多个地址或"c="行。
上面描述的多个地址的斜杠符号不能用于IP单播地址。
5.8带宽信息（“b=”）
b=<bwtype>:<bandwidth>
可选的"b=" 行(bandwidth-field)表示会话或媒体描述使用的建议带宽。<bwtype>是一个字母数字修饰符，它提供<bandwidth>的含义。本规范中定义了两个值，但将来可能会注册其他值(见章节8和[rfc3556]， [rfc3890])
CT 如果会话的带宽不同于范围内隐含的带宽，则应为会话提供“b=CT:”一行，给出所使用带宽的建议上限(“会议总带宽”)。类似地，如果在“m=”行中捆绑的媒体流[rfc8843]的带宽不同于范围内的隐式值，“b=CT:”行应该在媒体层中提供。这样做的主要目的是给出一个关于两个或多个会话(或捆绑的媒体流)是否可以同时共存的大致概念。请注意，“b=CT:”行给出了所有端点上所有介质的总带宽。
“b=CT:”的Mux类别是NORMAL。这在[rfc8859]中进行了讨论。
AS 带宽被解释为特定于应用程序(它将是应用程序的最大带宽概念)。通常，如果适用，这将与应用程序的“最大带宽”控制中设置的值一致。对于基于RTP的应用程序，“b=AS:”行给出了RTP的“会话带宽”，如RFC3550章节6.2所定义的。请注意，“b=AS:”行给出了单个端点上单个媒体的带宽数值，尽管可能有许多端点同时发送。
“b=AS:”的Mux类别是SUM。这在[RFC8859]中进行了讨论。
[RFC4566]为<bwtype>定义了一个“X-”前缀的名字。这只是为了实验目的。例如：
b=X-YZ:128
不建议使用“X-”前缀。代替新的(非“X-”前缀)<bwtype>名称应该被定义，然后必须在标准命名空间中向IANA注册。SDP解析器必须忽略未知<bwtype>的带宽域的名字。<bwtype>名称必须是字母和数字，尽管没有长度限制，但建议它们是short。
<bandwidth>默认情况下被解释为每秒千比特(包括传输层和网络层开销，但不包括链路层开销)。一个新的<bwtype>的定义修饰符可以指定将被解释为一些替代单位带宽(本备忘录中定义的“CT”和“AS”修饰符使用默认单位)。
5.9有效时间（“t=”）
t=<start-time> <stop-time>
一个“t=”行(time-field)开始一个时间描述，该描述指定会话的开始和停止时间。如果一个会话在多个不规则间隔的时间内处于活动状态，可以使用多个时间描述；每个额外的时间描述指定会话将处于活动状态的额外时间段。如果会话在固定的重复时间是活动的，一个重复描述，由“r=”行开始(见章节5.10)可以包括在时间字段之后——在这种情况下，时间字段指定整个重复序列的开始和停止时间。
下面的示例指定了两个活动间隔：
t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC
t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC
时间字段的第一个和第二个子字段分别给出会话的开始时间和停止时间。这些是自1900年1月1日起以秒为单位的时间值的十进制表示。要将这些值转换为Unix时间(UTC)，需要减去十进制的2208988800。
一些时间代表将在2036年结束。因为SDP使用任意长度的十进制表示，所以没有这个问题。SDP的实现需要准备好处理这些较大的值。
如果<stop-time>被设置为0，则会话没有限制，尽管它直到<start-time>之后才会成为活动的。如果<start-time>亦为零，则视为永久性的。
用户接口应该强烈反对创建无边界的和永久的会话，因为它们没有提供关于会话实际何时结束的信息，从而使调度变得困难。
一般的假设是，在向用户显示未超时的无界会话时，一个无界会话将只在当前时间或会话开始时间(以较晚的时间为准)的半小时内处于活动状态。如果需要其他行为，则需要停止时间。当关于会话何时真正结束的新信息可用时，应该适当地给出和修改。
永久会话可能会显示给用户从未处于活动状态，除非有关联的重复次数，该重复次数正好是会话处于活动状态的时间。
5.10重复次数（“r=”）
r=<repeat interval> <active duration> <offsets from start-time>
“r=”行(repeat-field)指定会话的重复次数。如果需要表达复杂的时间表，可以包含多个重复字段。例如，如果一个会议是在周一上午10点和周二上午11点，持续三个月，每周一个小时，那么<start-time>在相应的“t=”行中表示第一个星期一上午10点，<repeat interval>将是1周，<active duration>是1小时，偏移量是0和25小时。相应的“t=”行停止时间表示三个月后最后一个会话的结束时间。默认情况下，所有子字段都以秒为单位，因此“r=”和“t=”行可能如下所示：
t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC
; Tues 20-Mar-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
为了使描述更紧凑，时间也可以以天、小时或分钟为单位给出。它们的语法是数字后面紧跟一个区分大小写的字符。分数单位是不允许的，应该使用更小的单位。允许使用以下单元规范字符：
+---+------------------------------------------------+
| d | days (86400 seconds) |
+---+------------------------------------------------+
| h | hours (3600 seconds) |
+---+------------------------------------------------+
| m | minutes (60 seconds) |
+---+------------------------------------------------+
| s | seconds (allowed for completeness) |
+---+------------------------------------------------+
表1:时间单位规格字符
因此，也可以编写上述repeat-field：
r=7d 1h 0 25h
月重复和年重复不能直接指定一个SDP重复时间；相反，应该使用单独的时间描述来显式列出会话时间。
5.11时区调整（“z=”）
z=<adjustment time> <offset> <adjustment time> <offset> ....
“z=”行(zone-field)是它紧跟其后的repeat-fields的可选修饰符。它不适用于任何其他字段。
要计划一个跨越从夏令时到标准时间或反之亦然的变化的重复会话，有必要指定从基本时间的偏移量。这是因为不同的时区在一天的不同时间改变时间，不同的国家在不同的日期采用或取消夏时制并且一些国家根本没有夏时制。
因此，为了安排一个同时处于冬季和夏季的会话，必须能够明确地指定安排会话的时区。为了简化接收方的这个任务，我们允许发送方指定时区调整发生的时间(表示为1900 UTC 1月1日以来的秒数)，以及会话第一次被调度时的偏移量。“z=”行允许发送者指定这些调整时间和从基准时间的偏移量的列表。
下面是一个例子：
t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC
; Tues 18-Dec-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC,
; offset 1 hour,
; Sun 28-Oct-2018 2:00 UTC,
; no offset
这指定在3730928400时间(Sun 25-Mar-2018 1:00 UTC，英国夏令时开始)，用来计算会话重复次数的时间基准向后移动了1小时，并且在3749680800时间(Sun 28-Oct-2018 2:00 UTC, 英国夏令时结束)恢复原有的时间基准。调整总是相对于指定的开始时间——它们不是累积的。
如果一个会话可能持续数年，则预期会话描述将定期修改，而不是在一个会话描述中传输数年的调整。
5.12加密密钥（“k=”）
k=<method>
k=<method>:<encryption key>
“k=”行(key-field)是过时的，绝对不能使用。由于遗留问题，本文档包含了它。绝不能在SDP中包含"k="行，并且如果在SDP中收到它必须丢弃它。
5.13属性（“a=”）
a=<attribute-name>
a=<attribute-name>:<attribute-value>
属性是扩展SDP的主要方法。可以将属性定义为会话级属性、媒体级属性或两者同时使用。(除了媒体级和会话级作用域之外，属性作用域也可以在本文档的扩展中定义，例如[rfc5576]和[rfc8864])。
一个媒体描述可以包含任意数量的“a=”行(attribute-fields)，这些特定于媒体描述的属性行被称为媒体级属性，用于添加关于媒体描述的信息。属性字段也可以添加到第一个媒体描述之前；这些会话级属性传递附加信息，这些信息作为一个整体应用于会话，而不是应用于单个媒体描述。
属性字段可以有两种形式：
*特性属性是简单的形式“a=<attribute-name>”。这些是二进制属性，属性的存在表示该属性是会话的属性。例如“a=recvonly”。
* 值属性的形式是“a=<attribute-name>:<attribute-value>”。例如，白板可以具有值属性“a=orient:landscape”。
属性解释取决于被调用的媒体工具。因此，会话描述的接收者应该在他们对一般会话描述的解释，特别是对属性的解释中进行配置。
属性名称必须使用ISO-10646/UTF-8的US-ASCII子集。
属性值是八位字节字符串，可以使用除0x00 (Nul)、0x0A (LF)和0x0D (CR)以外的任何八位值。默认情况下，属性值将被解释为使用UTF-8编码的ISO-10646字符集。与其他文本字段不同，属性值通常不受"a=charset:"属性的影响，因为这会导致与已知值的比较出现问题。然而，当一个属性被定义时，它可以被定义为依赖于字符集，在这种情况下，它的值应该在会话字符集中解释，而不是在ISO-10646中。
属性必须注册到IANA(见第8节)。如果接收到一个不能理解的属性，它必须被接收方忽略。
5.14媒体描述（“m=”）
m=<media> <port> <proto> <fmt> ...
一个会话描述可以包含多个媒体描述。每个媒体描述以“m=”行(media-field)开始，并以下一个“m=”行或会话描述的结尾结束。一个媒体字段有几个子字段：
<media> 是媒体类型。本文档定义了“audio”、“video”、“text”、“application”和“message”的值。这个列表会被其他备忘录扩展，将来可能会被其他注册媒体类型的备忘录进一步扩展(参见章节8)。例如，[rfc6466]定义了“image”媒体类型。
<port> 是媒体流发送到的传输端口。传输端口的含义取决于在相关的“c=”行中指定的正在使用的网络，以及在media-field的子字段<proto>。媒体应用程序使用的其他端口(如RTP控制协议(RTCP)端口[rfc3550])可以从基本媒体端口算法上派生出来，也可以在一个单独的属性中指定(例如，在[rfc3605]中定义的"a= RTCP:"属性)。
如果使用了不连续的端口，或者它们不遵循偶数RTP端口和奇数RTCP端口的奇偶规则，则必须使用"a= RTCP:"属性。被请求将媒体发送到端口的应用程序。绝不能从RTP端口中减去1：也就是说，他们必须将RTP发送到<port>中指定的端口。并将RTCP发送到“a= RTCP:”属性中指定的端口。
对于将分级编码的流发送到单播地址的应用程序，可能需要指定多个传输端口。这是使用类似于在“c=”行中用于IP多播地址的符号来完成的
m=<media> <port>/<number of ports> <proto> <fmt> ...
在这种情况下，所使用的端口取决于传输协议。对于RTP，默认情况下，只有偶数端口被用于数据，对应的一个更高的奇数端口被用于属于RTP会话的RTCP，并且<number of ports>表示RTP会话数。例如：
m=video 49170/2 RTP/AVP 31
将指定端口49170和49171组成RTP/RTCP对，49172和49173组成RTP/RTCP对。RTP/AVP是传输协议，31是格式(见下文关于<fmt>的描述)。
本文档不包括使用不连续端口声明分层编码流的机制。(目前还没有定义可以实现此功能的属性。在[rfc3605]中定义的"a=rtcp:"属性不处理分层编码。)如果需要声明不连续端口，则需要定义一个新属性来这样做。
如果在"c="行中指定了多个地址，在"m="行中指定了多个端口，则隐含了从端口到对应地址的一对一映射。例如：
m=video 49170/2 RTP/AVP 31
c=IN IP4 233.252.0.1/127/2
这意味着地址233.252.0.1用于端口49170和49171，地址233.252.0.2用于端口49172和49173。
如果使用多个"c="行指定多个地址，则映射类似。例如
m=video 49170/2 RTP/AVP 31
c=IN IP6 ff00::db8:0:101
c=IN IP6 ff00::db8:0:102
这意味着地址ff00::db8:0:101用于端口49170和49171，地址ff00::db8:0:102用于端口49172和49173。
本文档没有说明如何将相同的媒体地址分配给多个媒体描述。这样做并不意味着以任何方式对这些媒体描述进行分组。应该使用显式分组框架(例如，[rfc5888])来表达预期的语义。如[rfc8843]。
<proto> 是传输协议。传输协议的含义依赖于相关的“c=”行中的地址类型子字段。因此，地址类型为“IP4”的“c=”行表示传输协议在IPv4上运行。以下传输协议被定义，但可以通过注册新的协议与IANA进行扩展(见章节8)：
* udp：表示数据直接在udp中传输，没有额外的帧。
* RTP/AVP：表示RTP [rfc3550]在RTP配置文件下使用，用于在UDP上运行的音频和视频会议的最小控制[rfc3551]。
* RTP/SAVP：表示UDP上运行的安全实时传输协议[rfc3711]。
* RTP/SAVPF：表示在UDP上运行可以通过RTCP-Based Feedback [rfc5124]来扩展SRTP配置文件的SRTP。
在媒体格式之外指定传输协议的主要原因是，即使在网络协议相同的情况下，也可以在不同的传输协议上携带相同的标准媒体格式--—个历史上的例子是vat (MBone的流行多媒体音频工具)脉冲编码调制(PCM)音频和RTP PCM音频；另一个可能是TCP/RTP PCM音频。此外，特定于传输协议但与格式无关的中继和监控工具也是可能的。
<fmt> 是媒体格式说明。第四个和随后的任何子字段描述媒体的格式。媒体格式的解释取决于<proto>子域的值。
如果<proto>子字段为“RTP/AVP”或“RTP/SAVP”，其中<fmt>子字段包含RTP有效负载类型号。当给出负载类型编号的列表时，这意味着所有这些负载格式都可以在会话中使用，并且这些负载格式是按照优先顺序列出的，列出的第一种格式是首选格式。当列出多个有效载荷格式时，会话应该使用列表开头的第一个可接受的有效载荷格式。对于动态负载类型分配，“a=rtpmap:”属性(见章节6.6)应该用于从RTP负载类型编号映射到标识负载格式的媒体编码名称。"a=fmtp:"属性可以用来指定格式参数(参见章节6.15)。
如果 <proto>子字段是“udp”， <fmt>子字段必须引用"audio"， "video"， "text"，"application", 或者 "message" 顶级媒体类型下描述格式的媒体类型。媒体类型注册应该定义UDP传输使用的包格式。
对于使用其他传输协议的媒体，<fmt>子字段与协议相关。<fmt>子字段的值必须在注册新协议时定义(参见8.2.2节)。
[rfc4855]第3节指出RTP概要文件中定义的有效载荷格式(编码)名称通常以大写显示，而媒体子类型名称通常以小写显示。它还声明，这两个名称在两个地方都是不区分大小写的，类似于在媒体类型字符串和默认映射到SDP“a=fmtp:”属性中都是不区分大小写的参数名称。
6.SDP属性
6.1cat（Category种类）
名称：cat
值：cat-value
使用级别：session
字符集依赖：no
语法：
cat-value = category
category = non-ws-string
示例：
a=cat:foo.bar
这个属性给出了会话的点分隔的层次类别。这是为了使接收方能够按类别过滤不需要的会话。没有分类的中心登记处。此属性已过时，不应使用。如果收到，应该忽略它。
6.2keywds （Keywords关键字）
名称：keywds
值：keywds-value
使用级别：session
字符集依赖：yes
语法：
keywds-value = keywords
keywords = text
示例：
a=keywds:SDP session description protocol
和"a=cat:"属性一样，这是为了帮助接收者识别需要的会话，并允许接收者根据描述会话目的的关键字选择感兴趣的会话；但是，没有关键字的中心注册表。如果指定了，它的值应该用为会话描述指定的字符集来解释，或者默认用ISO10646 /UTF-8中。此属性已过时，不应使用。如果收到，应该忽略它。
6.3tool
名称：tool
值：tool-value
使用级别：session
字符集依赖：no
语法：
tool-value = tool-name-and-version
tool-name-and-version = text
示例：
a=tool:foobar V3.2
这提供了用于创建会话描述（创建SDP）的工具的名称和版本号。
6.4ptime （Packet Time包时间）
名称：ptime
值：ptime-value
使用级别：media
字符集依赖：no
语法：
ptime-value = non-zero-int-or-real
示例：
a=ptime:20
这给出了以毫秒为单位的时间长度，该长度由包中的媒体表示。这可能只对音频数据有意义，如果这个参数有意义也可以用于其他的媒体类型。不需要必须知道“a=ptime:”来解码RTP或增值音频，它是作为音频编码/分包的建议。
6.5maxptime（Maximum Packet Time最大数据包时长）
名称：maxptime
值：maxptime-value
使用级别：media
字符集依赖：no
语法：
maxptime-value = non-zero-int-or-real
示例：
a=maxptime:20
这给出了每个包中可以封装的最大媒体量，以毫秒为单位表示时间。时间应计算为媒体在包中所代表的时间的总和。对于基于帧的编解码器，时间应该是帧大小的整数倍。此属性可能只对音频数据有意义，但如果有意义，可以与其他媒体类型一起使用。注意，这个属性是在[rfc2327]之后引入的，没有更新的实现将忽略这个属性。
6.6rtpmap
名称：rtpmap
值：rtpmap-value
使用级别：media
字符集依赖：no
语法：
rtpmap-value = payload-type SP encoding-name
"/" clock-rate [ "/" encoding-params ]
payload-type = zero-based-integer
encoding-name = token
clock-rate = integer
encoding-params = channels
channels = integer
这个属性从RTP有效负载类型号(在“m=”行中使用)映射到表示要使用的有效负载格式的编码名称。它还提供了时钟速率和编码参数的信息。请注意，有效负载类型编号是在一个7bit字段中表示的，将值限制在0到127之间。
尽管RTP配置中可以对负载格式进行静态的负载类型编号分配，但更常见的情况是使用“a=rtpmap:”属性动态地进行分配。作为一个静态有效载荷类型的例子，考虑在8 kHz采样的u-law PCM编码的单声道音频。这在RTP audio/video配置文件中完全定义为有效负载类型0，所以不需要“a=rtpmap:”属性，这样的流发送到UDP端口49232的媒体可以指定为
m=audio 49232 RTP/AVP 0
一个动态有效载荷类型的例子是16khz采样的16位线性编码立体声音频。如果我们希望对该流使用动态RTP/AVP负载类型98，则需要额外的信息来解码它
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
每个指定的媒体格式最多可以定义一个"a=rtpmap:"属性。因此，我们可能会得到以下结果
m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
指定使用动态有效负载类型的RTP配置，如果该配置要与SDP一起使用的话，必须定义一组有效的编码名称和/或注册编码名称的方法。“RTP/AVP”和“RTP/SAVP”配置使用媒体子类型作为编码名称，在“m=”行中表示的顶级媒体类型下面。在上面的例子中，媒体类型是“audio/L8”和“audio/L16”。
对于音频流，encoding-params表示音频通道数。该参数是可选的，如果通道数量为1，则可以省略，前提是不需要其他参数。
对于视频流，当前没有指定编码参数。
将来可能会定义其他编码参数，但不应该添加特定于编解码器的参数。添加到"a=rtpmap:"属性的参数应该只用于会话目录，以便选择适当的媒体参与会话。特定于编解码的参数应该添加到其他属性中（例如，“a=fmtp:”）。
注意：RTP音频格式通常不包含关于每个包的采样数量的信息。如果一个非默认的(定义在RTP音频/视频配置文件[rfc3551])数据包是必需的，“a=ptime:”属性被使用，如章节6.4所示。
6.7媒体方向属性
最多出现一次"a=recvonly"， "a=sendrecv"， "a=sendonly"，或"a=inactive"可能出现在会话级别，并且在每个媒体描述中最多出现一次。
如果其中任何一个出现在媒体描述中，那么它就适用于该媒体描述。如果媒体描述中没有出现，那么来自会话级别的描述（如果有的话）将应用于该媒体描述。
如果在会话级别或媒体级别上没有任何媒体方向属性，"a=sendrecv"应该被认为是默认值。
在下面的SDP示例中，“a=sendrecv”属性应用于第一个音频媒体，而“a=inactive”属性应用于其他音频
v=0
o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1
s=-
c=IN IP6 2001:db8::1
t=0 0
a=inactive
m=audio 49170 RTP/AVP 0
a=sendrecv
m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
6.7.1recvonly (Receive-Only)
名称：recvonly
值：
使用级别：session，media
字符集依赖：no
示例：
a=recvonly
这指定工具应该在适用的情况下以仅接收模式启动。请注意，仅接收模式只适用于媒体，而不适用于任何相关的控制协议。在仅接收模式下，基于rtp的系统仍然必须发送RTCP报文，如[RFC3550]章节6所述。
6.7.2sendrecv (Send-Receive)
名称：sendrecv
值：
使用级别：session， media
字符集依赖：no
示例：
a=sendrecv
这指定工具应该以发送和接收模式启动。这对于使用默认为仅接收模式的工具的交互式多媒体会议是必要的。
6.7.3sendonly (Send-Only)
名称：sendonly
值：
使用级别：session， media
字符集依赖：no
示例：
a=sendonly
这指定工具应该以只发送模式启动。例如，流量目的地使用的单播地址可能与流量源使用的单播地址不同。在这种情况下，可以使用两个媒体描述，一个在send-only模式，一个在receive-only模式。请注意，只发送模式只适用于媒体，任何相关的控制协议(例如，RTCP)应该仍然被接收和正常处理。
6.7.4inactive
名称：inactive
值：
使用级别：session， media
字符集依赖：no
示例：
a=inactive
这指定工具应该在非活动模式下启动。这对于交互式多媒体会议是必要的，用户可以让其他用户保持等待。没有媒体通过非活动媒体流发送。注意，基于rtp的系统必须仍然发送RTCP(如果使用了RTCP)，即使在非活动模式下启动。
6.8orient (Orientation方向)
名称：orient
值：orient-value
使用级别：media
字符集依赖：no
语法：
orient-value = portrait / landscape / seascape
portrait = %s"portrait"
landscape = %s"landscape"
seascape = %s"seascape"
; 注意: 这些名称区分大小写。
示例：
a=orient:portrait
通常这只用于白板或演示工具。它指定屏幕上工作空间的方向。允许的值是"portrait", "landscape", and "seascape"(倒置landscape)。
6.9type (Conference Type会议类型)
名称：type
值：type-value
使用级别：session
字符集依赖：no
语法：
type-value = conference-type
conference-type = broadcast / meeting / moderated / test /
H332
broadcast = %s"broadcast"
meeting = %s"meeting"
moderated = %s"moderated"
test = %s"test"
H332 = %s"H332"
; 注意: 这些名称区分大小写
示例：
a=type:moderated
多媒体会议的类型。允许的值为“broadcast”、“meeting”、“moderated”、“test”和“H332”。这些值对其他可能合适的选项有影响
*如果指定了"a=type:broadcast"，则"a=recvonly"可能适用于那些正在连接的选项。
*当"a=type:meeting"被指定时，"a=sendrecv"可能是合适的。
* "a=type:moderated"表示使用楼层控制工具，并启动媒体工具，以静音加入多媒体会议的新站点。
*指定"a=type:H332"表示此松散耦合会话是ITU H.332规范[ITU.H332.1998]中定义的H.332会话的一部分。媒体工具应该使用"a=recvonly"启动。
*建议指定"a=type:test"作为提示，除非明确请求，否则接收者可以安全地避免向用户显示这个会话描述。
6.10charset (Character Set 字符集)
名称：charset
值：charset-value
使用级别：session
字符集依赖：no
语法：
charset-value = <defined in [RFC2978]>
这指定用于显示会话名称和信息数据的字符集。默认情况下，使用UTF-8编码的ISO-10646字符集。如果需要更紧凑的表示，则可以使用其他字符集。例如，ISO 8859-1是通过以下SDP属性来指定的:
a=charset:ISO-8859-1
指定的字符集必须是在IANA字符集注册表(Character Sets)中注册的字符集之一，例如ISO-8859-1。字符集标识符是一个字符串，必须与注册表的“名称”或“首选MIME名称”字段中的标识符进行不区分大小写的比较。如果标识符不被识别或不被支持，那么所有受其影响的字符串都应该被视为八位字节字符串。
与字符集相关的字段必须只包含根据所选字符集定义有效的字节序列。此外，与字符集相关的字段不能包含字节0x00 (Nul)、0x0A (LF)和0x0d (CR)。
6.11sdplang (SDP Language SDP语言)
名称：sdplang
值：sdplang-value
使用级别：session，media
字符集依赖：no
语法：
sdplang-value = Language-Tag
; Language-Tag 被定义在 rfc5646
示例：
a=sdplang:fr
如果会话描述或媒体使用多种语言，那么可以在会话级或媒体级提供多个"a=sdplang:"属性。
作为会话级属性，它指定会话描述的语言(而不是媒体的语言)。作为一个媒体级属性，它指定了与该媒体相关的任何媒体级SDP信息字段的语言(同样不是该媒体的语言)，覆盖了在会话级指定的任何“a=sdplang:”属性。
通常，不鼓励发送包含多种语言的会话描述。相反，应该发送多个会话描述来描述会话，每种语言一个。但是，这并不适用于所有的传输机制，因此允许多个“a=sdplang:”属性，但是不推荐。
“a=sdplang:”属性值必须是单个语言标签[rfc5646]。“a=sdplang:”属性应该在以下情况下被指定:会话的分布具有足够的范围，可以跨越地理边界，接收方的语言不能被假定，或者会话使用的语言与本地假定规范不同。
6.12lang (Language 语言)
名称：lang
值：lang-value
使用级别：session，media
字符集依赖：no
语法：
lang-value = Language-Tag
; Language-Tag 被定义在 rfc5646
示例：
a=lang:de
如果会话或媒体具有一种以上语言的能力，那么可以在会话或媒体级别提供多个"a=lang:"属性，在这种情况下，属性的顺序表示会话或媒体中各种语言的优先顺序，从最受欢迎到最不受欢迎。
作为会话级属性，"a=lang:"指定所描述会话的语言功能。作为一个媒体级属性，它指定了该媒体的语言功能，覆盖了指定的任何会话级语言。
"a=lang:"属性值必须是一个单一的[rfc5646]语言标签。“a=lang:”属性应该在以下情况下被指定：会话具有足够的范围，可以跨越地理边界，其中参与者的语言不能被假定，或者会话具有不同于本地假定规范的语言能力。
"a=lang:"属性应该用于设置会话中使用的初始语言。会话期间的事件可能会影响所使用的语言，并且参与者并没有被严格限制为只使用声明的语言。
大多数实时用例开始时只使用一种语言，而其他用例则涉及一系列语言，比如，一个解释的或带字幕的会话。当指定了多个"a=lang:"属性时，"a=lang:"属性本身不会提供任何关于在会话期间打算使用的多种语言的信息，或者如果目的是只选择其中一种语言。如果需要，可以定义一个新属性，并使用它来表示这样的意图。如果没有这样的语义，就假定对于协商的会话，将选择并使用声明的语言之一。
6.13framerate (Frame Rate帧率)
名称：framerate
值：framerate-value
使用级别：media
字符集依赖：no
语法：
framerate-value = non-zero-int-or-real
示例：
a=framerate:60
这给出了以帧/秒为单位的最大视频帧速率。它的目的是作为视频数据编码的建议。允许用小数表示分数值。它仅为视频媒体定义。
6.14quality质量
名称：quality
值：quality-value
使用级别：media
字符集依赖：no
语法：
quality-value = zero-based-integer
示例：
a=quality:10
这为整数值的编码质量提供了建议。视频质量属性的目的是指定帧率和静止图像质量之间的非默认权衡。对于视频，取值范围为0 ~ 10，建议取值如下
+----+----------------------------------------+
| 10 | 压缩方案所能提供的 |
| | 最佳静止图像质量。 |
+----+----------------------------------------+
| 5 | 默认行为没有给出 |
| | 任何质量建议。 |
+----+----------------------------------------+
| 0 | 编解码器设计者认为最糟糕 |
| | 的静态图像质量仍然可用。 |
+----+----------------------------------------+
表2: 编码质量值
6.15fmtp (Format Parameters格式参数)
名称：fmtp
值：fmtp-value
使用级别：media
字符集依赖：no
语法：
fmtp-value = fmt SP format-specific-params
format-specific-params = byte-string
; 注意:
; - 格式参数是媒体类型参数，需要反映它们的语法。
示例：
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
这个属性允许特定于特定格式的参数以一种SDP不需要理解的方式传递。格式必须是为媒体指定的格式之一。特定于格式的参数，分号分隔，可以是SDP需要传递的任何一组参数，并且不会改变将使用这种格式的媒体工具。每个格式最多允许有一个此属性的实例。
"a=fmtp:"属性可以用来指定任何协议的参数和定义使用这些参数的格式。
7.安全性考虑
SDP经常与会话初始化协议（SIP） [rfc3261]一起使用提供/应答模型[rfc3264]来协商单播会话的参数。当以这种方式使用时，需要考虑这些协议的安全性。
SDP是一种描述多媒体会话的会话描述格式。接收和处理SDP消息的实体应该意识到会话描述是不可信的，除非它是从已知和可信的来源，通过身份验证和完整性保护的传输协议获得的。可以使用许多不同的传输协议来分发会话描述，不同传输的身份验证和完整性保护的性质也不同。对于某些传输，通常不部署安全特性。如果会话描述没有以可信的方式获得，终端应该小心，因为在其他攻击中，收到的媒体会话可能不是预期的，媒体发送的目的地可能不是预期的目的地，会话的任何参数可能不正确，或者媒体安全可能受到损害。终端可以根据应用程序的安全风险和用户偏好做出明智的决定——终端可以通过询问用户是否接受会话来决定。
在通过未经身份验证的传输机制或从不受信任方接收会话描述时，解析会话描述的软件应该采取一些预防措施。如果完整性保护不到位，也会出现类似的问题。会话描述包含在接收方系统上启动软件所需的信息。解析会话描述的软件必须不能启动其他软件，除非它被专门配置为参与多媒体会话的适当软件。通常认为，在用户的系统上，软件解析会话描述以启动适合参与多媒体会话的软件，而不首先通知用户将启动该软件并给予用户同意是不合适的。因此，通过会话通知、电子邮件、会话邀请或WWW页面到达的会话描述绝不能将用户传递到交互式多媒体会话中，除非用户明确地预先授权了这样的操作。由于判断会话是否交互式并不总是简单的，因此不确定的应用程序应该假设会话是交互式的。软件处理包含在会话描述中的url也应该注意在[rfc3986]中确定的安全考虑。
在这个规范中，没有属性允许会话描述的接收者被告知以默认的传输模式启动多媒体工具。在某些情况下，定义这样的属性可能是合适的。如果这样做，应用程序解析包含这些属性的会话描述时，要么忽略它们，要么通知用户加入该会话将导致多媒体数据的自动传输。未知属性的默认行为是忽略它。
在某些环境中，中间系统拦截和分析包含在其他信令协议中的会话描述已经变得很常见。这样做的目的有很多，包括但不限于在防火墙上打开一个洞，允许媒体流通过，或标记、优先级或有选择地阻塞流量。在某些情况下，这样的中介系统可能会修改会话描述，例如，让会话描述的内容匹配动态创建的NAT绑定。这些行为是不推荐的，除非会话描述的传递方式允许中间系统进行适当的检查，以建立会话描述的真实性，以及它的源建立这种通信会话的权限。SDP本身没有包含足够的信息来启用这些检查：它们依赖于封装协议(例如，SIP或RTSP)。使用一些过程和SDP扩展(例如，交互连接建立(ICE) [rfc8445]和ICE- SIP - SDP [rfc8839])可以避免中间系统修改SDP。
SDP绝对不能用来传递密钥材料(例如，使用"a=crypto:"属性[rfc4568])，除非它可以保证SDP传送的通道是私有的和经过认证的。
8.IANA的一些考虑
8.1"application/sdp"媒体类型
一个来自[rfc4566]的媒体类型注册已经更新，定义如下：
类型名称：application
子类型名称：sdp
必要参数：无
可选参数：无
编码注意事项：8位文本。SDP文件主要是UTF-8格式的文本。"a=charset:"属性可以用来表示在SDP文件的某些部分中存在其他字符集(参见RFC 8866第6节)。任何二进制内容不能直接在SDP中表示。
安全注意事项：参见RFC 8866第7节
互操作性注意事项：参见rfc8866
出版规范：rfc8866
使用这种媒体类型的应用程序：
IP语音、视频电话会议、流媒体、即时消息等等。参见RFC 8866第3节。
片段标识符注意事项：无
附加信息：
已弃用此类型的别名：N/A
重要的数字：无
文件扩展名：扩展“.sdp”是常用的。苹果电脑文件类型代码：“sdp”
人&电子邮件进一步联系信息：
IETF MMUSIC工作组 <mmusic@ietf.org>
限制使用：无
作者/变更控制者：
由IESG委派的rfc8866 IETF MMUSIC工作组的作者
8.2向IANA注册SDP参数
本文档为六个命名的SDP子字段指定了IANA参数注册表。使用SDP规范Augmented Backus-Naur Form (ABNF)中的术语，它们是 <media>，<proto>，<attribute-name>，<bwtype>，<nettype>和 <addrtype>。
本文档还替换和更新了之前[rfc4566]定义的所有参数的定义。IANA更改了这些注册表中对rfc4566的所有引用，改为引用本文档。
本文档中注册的所有参数的联系名称和电子邮件地址是:IETF MMUSIC工作组<mmusic@ietf.org>或由IESG指定的继任者。
所有这些注册中心都有一个通用的格式：
+====+=========+=========+=========+
| Type | SDP Name | [other fields] | Reference |
+====+=========+=========+=========+
表3：SDP注册表的通用格式
8.2.1注册步骤
一个定义SDP <media>，<proto>，<attribute-name>，<bwtype>，<nettype>和<addrtype>参数必须包含以下信息：
*联系人姓名
*联系人电子邮件地址
*正在定义的名称(它将在SDP中出现)
*类型的名字(<media>, <proto>, <attribute-name>, <bwtype>,
<nettype>, 或者<addrtype>)
*定义名称的用途的描述
*对包含此信息和值定义的文档的稳定引用。(这通常是一个RFC号码。)
下面的小节指定了必须为特定参数指定哪些其他信息(如果有的话)，以及注册表中包含哪些其他字段。
8.2.2媒体类型 (<media>)
媒体类型的集合应该很小，除非在极少数情况下，否则不应该扩展。同样的规则应该适用于媒体名称以及顶级媒体类型，在可能的情况下，应该为SDP注册与MIME相同的名称。对于现有顶级媒体类型以外的媒体，必须生成一个标准跟踪RFC来注册一个新的顶级媒体类型，并且注册必须提供一个很好的理由来说明为什么没有现有的合适的媒体名称(rfc8126的“标准行动”政策)。
该备忘录注册了媒体类型"audio"，"video"，"text"，"application"和"message"。
注意：媒体类型“control”和“data”在本规范的早期版本中被列为有效的；然而，它们的语义从来没有被完全指定，它们也没有被广泛使用。这些媒体类型在本规范中已经被删除，尽管它们仍然是[rfc3840]中定义的SIP用户代理的有效媒体类型功能。如果这些媒体类型在将来被认为是有用的，那么必须制作一个标准跟踪RFC来记录它们的使用。在此之前，应用程序不应该使用这些类型，也不应该在SIP功能声明中声明对它们的支持(即使它们存在于由[rfc3840]创建的注册表中)。还要注意[rfc6466]定义了“image”媒体类型。
8.2.3传输协议 (<proto>)
<proto>子字段描述所使用的传输协议。此注册表的注册程序为“RFC Required”。
这个文档注册了两个值
*“RTP/AVP”是一个参考[rfc3550]在RTP概要文件下使用的运行在UDP/IP上的最小控制的音频和视频会议[rfc3551]。
*“udp”表示直接使用udp协议。
新的传输协议可以被定义，并且必须向IANA注册。注册必须引用描述协议的RFC。这样的RFC可以是实验性的或信息性的，尽管它最好是标准跟踪。定义新协议的RFC必须定义管理<fmt>(见下面)命名空间的规则。
以“RTP/”开头的<proto>名称只能用于定义RTP的概要文件的传输协议。例如，一个短名为“XYZ”的配置文件将由“RTP/XYZ”的<proto>子字段表示。
由<proto>子字段定义的每个传输协议都有一个相关的<fmt>名称空间，该名称空间描述了该协议可能传递的媒体格式。格式涵盖了多媒体会话中可以传输的所有可能的编码。
在“RTP/AVP”和其他“RTP/*”配置文件下的RTP有效载荷格式必须使用有效载荷类型号作为它们的<fmt>值。如果有效负载类型编号是由这个会话描述动态分配的，那么必须包含一个额外的“a=rtpmap:”属性来指定格式名称和参数，这些参数是由有效负载格式的媒体类型注册定义的。建议作为SDP传输协议注册的其他RTP配置文件(与RTP结合使用)为<fmt>命名空间指定相同的规则。
对于“udp”协议，允许<fmt>值是来自IANA媒体类型注册表的媒体子类型。媒体类型和子类型组合<media>/<fmt>指定UDP报文正文的格式。鼓励对格式使用现有的媒体子类型。如果没有合适的媒体子类型存在，建议通过IETF进程[rfc6838]注册一个新的或者参考通过Standards Track RFC定义的格式。
对于其他协议，格式可以根据相关<proto>规则进行注册。
新格式的注册必须指定它们应用于哪个传输协议。
8.2.4属性名称 (<attribute-name>)
Attribute-field名称(<attribute-name>)必须向IANA注册并记录，以避免在同一个名称下由于属性定义冲突而产生的任何问题。(虽然在SDP中未知的属性被简单地忽略，冲突的协议碎片是一个严重的问题。)
<attribute-name>注册表的格式为:
+====+=========+==========+===========+========+
| Type | SDP Name | Usage Level | Mux Category | Reference |
+====+=========+==========+===========+========+
表4：<attribute-name>注册表的格式
例如，为会话级和媒体级定义的属性"a=lang:"将在新注册表中列出如下
+======+=========+===========+===========+=========+
| Type | SDP Name | Usage Level | Mux Category | Reference |
+======+=========+===========+===========+=========+
| attribute | lang | session, media | TRANSPORT | [rfc8866] |
| | | | | [rfc8859] |
+-----------+----------+---------------------+---------------------+------------------+
表5:<attribute-name>注册表示例
这一个<attribute-name>注册表合并了以前所有特定于使用级别的“att -field”注册表，包括由[rfc8859]所做的更新，并将“att -field”注册表重命名为“attribute-name(以前的“att -field”)”注册表。IANA已经完成了必要的重新格式化。
本文档的第6节替换了[rfc4566]的初始属性定义集。IANA相应地更新了注册表。
文档可以定义新的属性，也可以扩展以前定义的属性的定义。
8.2.4.1新属性
根据[rfc8126]的“规范要求”策略，新属性注册被接受，条件是规范包含以下信息
*联系人姓名
*联系人电子邮件地址
*属性名：在SDP中将出现的属性名。这必须符合<attribute-name>的定义。
*属性语法：对于一个value属性(参见5.13节)，一个ABNF定义的<attribute-name>必须提供语法(见第9节)。语法必须遵循[rfc5234]章节2.2和[rfc7405]中的规则形式。这将定义属性可能接受的允许值。它还可以定义一个扩展方法来添加未来值。对于属性属性，ABNF定义被省略，因为属性属性不接受任何值。
*属性语义：对于value属性，必须提供属性可能接受的值的语义描述。下面的目的一节描述了属性属性的用法。
*属性值：定义值的语法的ABNF语法规则的名称。规则名称的缺失表示该属性不接受任何值。将规则名括在“[”和“]”中表示值是可选的。
*使用级别：属性的使用级别。必须是以下一个或多个:session、media、source、dcsa和dcsa(子协议)。关于源级属性的定义，请参见[rfc5576]。有关dcsa属性的定义，请参见[rfc8864]。
*依赖字符集：这必须是“Yes”或“No”，取决于属性值是否服从“a=字符集:”属性。
*用途：解释属性的用途和用法。
* O/A程序：提供/应答程序，见[rfc3264]。
* Mux类别：必须指出以下类别之一：NORMAL，NOT RECOMMENDED，IDENTICAL，SUM， TRANSPORT，INHERIT，IDENTICAL-PER-PT，SPECIAL，或TBD定义由[rfc8859]。
*引用：对定义属性的规范的引用。
以上是IANA所能接受的最低要求。期望看到广泛使用和互操作性的属性应该用标准跟踪RFC来记录，以更精确地指定属性。
注册提交者应确保规范是SDP的精神属性,最要注意的就是这些属性是平台独立的,它没有对操作系统和隐式假设不具体的软件名称的方式可能会导致互操作性。
注册的提交者还应该谨慎地选择属性使用级别。当媒体被分解时，属性可以有不同的值时，他们不应该只选择“session”，例如，当每个“m=”部分在不同的端点上有自己的IP地址时。在这种情况下，选择的属性类型应该是“session, media”或“media”(取决于所需的语义)。默认的规则是，对于所有新的SDP属性，可以出现在会话级别和媒体级别，媒体级别覆盖会话级别。当新的SDP属性不是这种情况时，它必须显式声明。
IANA已经注册了初始属性名集这些定义替换了[RFC4566]中的定义。
IANA已经注册了初始属性名集(<attribute- name> 值)的定义，如本文档第6节所述(这些定义替换了[rfc4566]中的定义)。
8.2.4.2更新现有属性
根据[rfc8126]的“规范要求”策略，接受更新的属性注册。
请审查更新的指定专家评估更新是否符合先前的意图和属性的使用，以及新文档相对于以前的文档是否具有足够的成熟度和权威性。
更新属性(例如，通过添加一个新值)的规范必须根据以下约束更新8.2.4.1节中的注册信息项
*联系人姓名：必须提供负责更新的实体名称。
*联系电子邮件地址：必须提供负责更新的实体的电子邮件地址。
*属性名称：必须提供且不能更改。否则，它就是一个新属性。
*属性语法：如果语法发生变化，必须提供带有语法扩展的现有规则语法。对现有属性用法的修订可以扩展属性的语法，但必须向后兼容。
*属性语义：对新的附加属性值的语义描述或对现有值的语义扩展。必须以向后兼容的方式扩展现有的属性值语义。
*使用级别：更新只能添加额外的级别。
*依赖字符集：不能更改。
*用途：可根据更新的用途进行扩展。
* O/A过程：可以以向后兼容的方式更新和/或只适用于新的使用级别。
* Mux类别：没有变化，除非从“TBD”到另一个值(见rfc8859)。如果媒体级别被添加到先前没有包含它的属性定义中，它也可能改变。
*参考资料：必须提供新的(额外的或替代的)参考资料。
如果属性更新对项目没有影响，则应该忽略这些项目。
8.2.5带宽说明符 (<bwtype>)
带宽说明符的激增是强烈不鼓励的。
新的带宽规格(<bwtype>子字段值)必须注册到IANA。提交必须引用一个标准跟踪RFC，精确地指定带宽说明符的语义，并指出何时应该使用它，以及为什么现有注册的带宽说明符不能满足要求。
RFC必须为这个值指定Mux类别，如rfc8859所定义的。
<bwtype>格式注册表：
+====+========+============+========+
| Type | SDP Name | Mux Category | Reference |
+====+========+============+========+
表6：<bwtype>注册表的格式
IANA已更新<bwtype>对于“CT”和“AS”的注册表项，请使用本备忘录第5.8节中的定义(这些定义取代了[rfc4566]中的定义)。
8.2.6 网络类型 (<nettype>)
网络类型“IN”，代表Internet，在本备忘录的章节5.2和章节5.7中定义(该定义取代了[rfc4566]中的定义)。
为了使SDP能够引用一个新的非internet环境，一个新的网络类型(<nettype>子字段值)必须注册IANA。注册受[rfc8126]的“RFC Required”政策的约束。虽然非Internet环境通常不是IANA的专利，但在某些情况下，Internet应用程序可能需要与非Internet应用程序进行互操作，例如将Internet电话转接到公共交换电话网(PSTN)时。网络类型的数量应该较小，并且应该很少扩展。一个新的网络类型注册必须引用一个RFC，该RFC给出了网络类型和可以使用的地址类型的详细信息。
<nettype>格式注册表：
+====+==========+=================+========+
| Type | SDP Name | Usable addrtype Values | Reference |
+====+==========+=================+========+
表7:<nettype>注册表的格式
IANA已经更新了<nettype>注册到了新格式。
以下是更新后的注册表内容：
+======+========+===================+========+
| Type | SDP Name | Usable addrtype Values | Reference |
+======+========+==================+=========+
| nettype | IN | IP4, IP6 | [rfc8866] |
+----------+---------------+-------------------------------+----------------+
| nettype | TN | RFC2543 | [rfc2848] |
+----------+---------------+-------------------------------+----------------+
| nettype | ATM | NSAP, GWID, E164 | [rfc3108] |
+----------+---------------+-------------------------------+----------------+
| nettype | PSTN | E164 | [rfc7195] |
+----------+---------------+-------------------------------+----------------+
表8:<nettype>注册表的内容
请注意，[rfc7195]和[rfc3108]都将“E164”注册为地址类型，尽管[rfc7195]提到“E164”地址类型对于ATM和PSTN网络有不同的上下文。
8.2.7地址类型 (<addrtype>)
新的地址类型(<addrtype>)必须在IANA注册。注册受[rfc8126]的“RFC Required”政策的约束。新的地址类型注册必须引用RFC，给出地址类型语法的详细信息。地址类型不需要经常注册。
本文档5.7节给出了地址类型“IP4”和“IP6”的新定义。
8.3加密匙存取方法(过时)
IANA以前维护了一个SDP加密密钥访问方法(“enckey”)名称的表。这个表已经过时了，因为“k=”行是不可扩展的。不接受新注册。
9.SDP语法
本节为SDP提供了一个增强的BNF语法。ABNF的定义在[rfc5234]和[rfc7405]中。
; SDP 语法
session-description = version-field
origin-field
session-name-field
[information-field]
[uri-field]
*email-field
*phone-field
[connection-field]
*bandwidth-field
1*time-description
[key-field]
*attribute-field
*media-description
version-field = %s"v" "=" 1*DIGIT CRLF
;此文档描述了版本0
origin-field = %s"o" "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
session-name-field = %s"s" "=" text CRLF
information-field = %s"i" "=" text CRLF
uri-field = %s"u" "=" uri CRLF
email-field = %s"e" "=" email-address CRLF
phone-field = %s"p" "=" phone-number CRLF
connection-field = %s"c" "=" nettype SP addrtype SP connection-address CRLF
;连接字段必须出现在每个媒体描述中或会话级别上
bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF
time-description = time-field
[repeat-description]
repeat-description = 1*repeat-field
[zone-field]
time-field = %s"t" "=" start-time SP stop-time CRLF
repeat-field = %s"r" "=" repeat-interval SP typed-time 1*(SP typed-time) CRLF
zone-field = %s"z" "=" time SP ["-"] typed-time*(SP time SP ["-"] typed-time) CRLF
key-field = %s"k" "=" key-type CRLF
attribute-field = %s"a" "=" attribute CRLF
media-description = media-field
[information-field]
*connection-field
*bandwidth-field
[key-field]
*attribute-field
media-field = %s"m" "=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF
; sub-rules of 'o='
username = non-ws-string
;很宽泛的定义，但不能包括空格
sess-id = 1*DIGIT
;这个用户名/主机应该是唯一的
sess-version = 1*DIGIT
nettype = token
;通常为"IN"
addrtype = token
;通常为"IP4" or "IP6"
; sub-rules of 'u='
uri = URI-reference
; 查看 rfc3986
; sub-rules of 'e='，查看 rfc5322中的定义
email-address = address-and-comment / dispname-and-address / addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"
; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" /1*email-safe "<" phone ">" /phone
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
; sub-rules of 'c='
connection-address = multicast-address / unicast-address
; sub-rules of 'b='
bwtype = token
bandwidth = 1*DIGIT
; sub-rules of 't='
start-time = time / "0"
stop-time = time / "0"
time = POS-DIGIT 9*DIGIT
; 自1900 UTC 1月1日起以秒为单位的十进制时间表示。表示为至少包含10位数字的无界长度字段。与其他地方使用的一些表述不同，SDP中的时间并不包含在2036年。
; sub-rules of 'r=' and 'z='
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s"
; 注意：这些单位是区分大小写的。
; sub-rules of 'k='
key-type = %s"prompt" /
%s"clear:" text /
%s"base64:" base64 /
%s"uri:" uri
; 注意：这些名称是区分大小写的。
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
; sub-rules of 'a='
attribute = (attribute-name ":" attribute-value) /attribute-name
attribute-name = token
attribute-value = byte-string
att-field = attribute-name ; for backward compatibility
; sub-rules of 'm='
media = token
;通常为"audio", "video", "text", "image"或"application"
fmt = token
;通常是用于音频和视频媒体的RTP有效负载类型
proto = token *("/" token)
;通常为"RTP/AVP", "RTP/SAVP", "udp"或 "RTP/SAVPF"
port = 1*DIGIT
; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / FQDN/ extn-addr
IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" numaddr ]
; IP4 组播地址范围在 224.0.0.0 到 239.255.255.255之间
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /("23" DIGIT )
IP6-multicast = IP6-address [ "/" numaddr ]
; 以 FF开头的IP6 地址
numaddr = integer
ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".")
; rfc1035(及更新)rfc1035中指定的完全限定域名
IP4-address = b1 3("." decimal-uchar)
b1 = decimal-uchar
; 小于 "224"
IP6-address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IP4-address
; 其他地址族通用
extn-addr = non-ws-string
; generic sub-rules: datatypes
text = byte-string
;默认是将其解释为UTF8文本。ISO 8859-1要求使用“a=charset:ISO-8859-1”会话级属性
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;任何除了 NUL, CR, 或 LF
non-ws-string = 1*(VCHAR/%x80-FF)
;可见字符字符串
token-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&"
/ "'" ; (single quote)
/ "*" / "+" / "-" / "." / "^" / "_"
/ "`" ; (Grave accent)
/ "{" / "|" / "}" / "~"
token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting
;characters ()<>
integer = POS-DIGIT *DIGIT
zero-based-integer = "0" / integer
non-zero-int-or-real = integer / non-zero-real
non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT
; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; 外部引用:
ALPHA = <ALPHA 定义在 rfc5234>
DIGIT = <DIGIT 定义在 rfc5234>
CRLF = <CRLF 定义在 rfc5234>
HEXDIG = <HEXDIG 定义在 rfc5234>
SP = <SP 定义在 rfc5234>
VCHAR = <VCHAR 定义在 rfc5234>
URI-reference = <URI-定义在 rfc3986>
addr-spec = <addr-定义在 rfc5322>
10.rfc4566变更摘要
*一般澄清和精炼的术语。将文本中使用的术语与ABNF对齐。术语 <attribute>， <att-field>和“att-field”现在是<attribute-name>。条款<value>和<att-value>现在<attribute-value>。“media”这个词现在是<media>。
*确定现在已经过时的项目:“a=cat:”(章节6.1)，“a=keywds:”(章节6.2)，和“k=”(章节5.12)。
*更新了规范性和信息性的参考文献，并增加了其他相关rfc的参考文献。
*重新格式化SDP属性部分(章节6)的可读性。属性值的语法现在在ABNF中给出。
*强制RTCP发送非活动的媒体流(章节6.7.4)。
*删除“私人会话”部分。该部分可以追溯到SDP的主要用途是SAP(会话公告协议)的时候，SAP已经不再使用了。现在，SDP的绝大多数用途是用于建立私人会话。这方面的考虑将在第7节中讨论。
*扩展并澄清了“a=lang:”(章节6.12)和“a=sdplang:”(章节6.11)属性的规范。
*删除了一些对SAP的引用，因为SAP不再被广泛使用。
*修改了UDP传输的<fmt>值注册方式(章节8.2.3)。
*修改注册新属性所需的机制和文档(章节8.2.4.1)。
*加强IANA延期注册的程序。删除电话号码和长格式姓名(章节8.2)。
*扩展IANA <nettype>注册表识别有效的<addrtype>子字段(8.2.6节)。
*重新组织几个IANA的“att-field”注册表到一个单一的<attribute-name>注册表(8.2.4节)。
*修改ABNF语法(第9节)的清晰度和对齐文本。除了少数例外，还保持了向后兼容性。特别注意：
-修改了时间描述的语法(“t=”，“r=”，“z=”)以消除歧义。澄清了"z="只修改紧前的"r="行。使“z=”在没有前面的“r=”的情况下出现语法错误(章节5.11)。
-更新了“IP6-address”和“IP6-multicast”规则，与[rfc3986]中的语法一致，镜像修复了[rfc5954]对[rfc3261]的bug。删除由于此更改而未使用的规则。
-“att-field”规则被重命名为“attribute-name”，因为其他地方的“*-field”总是指一个完整的行。但是，规则名“att-field”仍然被定义为与来自其他rfc的引用的向后兼容的同义词。—将“att-value”规则重命名为“attribute-value”。
*修订了ABNF语法中多余的规范性语句，使得文本是非规范性的。
*根据[rfc5735]和[rfc5771]修改了IPv4单播和组播地址的示例SDP描述。
*改变了一些示例使用IPv6地址，并添加了额外的示例使用IPv6。
*从[rfc4855]合并不区分大小写的规则。
*修改了错误引用NTP的章节(章节5.2，章节5.9，章节5.10和章节5.11)。
*阐明了“a=charset:”属性的影响和使用的解释(章节6.10)。
*修改了"a=type:"属性的描述，以消除它有时会将默认媒体方向更改为"a=sendrecv"以外的内容的暗示(章节6.9)。
786
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
