文章总结： 本文档RFC8842定义了在SDP提供/应答过程中协商DTLS关联的通用规范，引入新的tls-id属性来唯一标识关联并明确何时需建立新DTLS连接。文档更新了RFC5763和7345，规范涵盖DTLS角色协商、证书指纹匹配及传输参数变更处理，同时扩展支持TLS连接协商。 综合评分： 87 文章分类： 技术标准,网络安全,应用安全
数据报传输层安全（DTLS）和传输层安全（TLS）的会话描述协议（SDP）提供/应答注意事项
衡水石头哥 衡水石头哥
铁军哥
2026年6月18日 07:44 北京
在小说阅读器读本章
去阅读
RFC8842：Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)，January 2021
梗概
本文档定义了用于协商和建立数据报传输层安全（Datagram Transport Layer Security，DTLS）关联的会话描述协议（Session Description Protocol，SDP）提供/应答过程。该文件还定义了何时必须建立新的DTLS关联的标准。该文档通过引用本规范替换常见的SDP提供/应答过程来更新RFC 5763和7345。
本文档定义了新的SDP媒体级属性“tls-id”。
本文档还结合RFC 4145和8122中的过程定义了如何使用“tls-id”属性来协商和建立传输层安全（Transport Layer Security，TLS）连接。
本备忘录的状态
这是一份互联网标准跟踪文档。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息，请参阅RFC 7841第2节。
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8842。
版权声明
版权所有（c）2021 IETF Trust和文档作者。版权所有。
本文件受本文件发布之日生效的BCP 78和IETF信托与IETF文件相关的法律规定（https://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并且在提供时不提供简化BSD许可证中所述的保证。
1、简介
[RFC5763] 定义了使用数据报传输层安全（Secure Real-time Transport Protocol using Datagram Transport Layer Security，DTLS-SRTP）的安全实时传输协议的会话描述协议（Session Description Protocol，SDP）提供/应答过程。 [RFC7345] 定义了基于数据报传输层安全的UDP传输层（UDP Transport Layer over Datagram Transport Layer Security，UDPTL-DTLS）的SDP提供/应答过程。本规范根据 [RFC5763] 中的过程定义了DTLS的一般提供/应答过程。然后，定义特定DTLS用法的其他规范可以引用此规范，以确保DTLS方面在所有用法中是通用的。当多种用途共享相同的DTLS关联时，拥有通用的过程至关重要 [RFC8843]。本文档通过引用本规范替换常见的SDP提供/应答过程来更新 [RFC5763] 和 [RFC7345]。
注意：自 [RFC5763] 发布以来，[RFC4474] 已被 [RFC8224] 取代。更新 [RFC5763] 中的引用（及其相关流程）不在本文档的讨论范围之内。但是，我们鼓励 [RFC5763] 应用的实现者采用 [RFC8224] 而非 [RFC4474]。
正如[RFC5763]中所定义的，当传输参数改变时，必须建立一个新的DTLS关联。使用交互式连接建立（Interactive Connectivity Establishment，ICE） [RFC8445] 时，传输参数更改未明确定义。确定传输更改的一种可能方法是基于ufrag [RFC8445] 更改，但ufrag值在ICE协商时和ICE重新启动 [RFC8445] 发生时都会更改。这些事件并不总是需要建立新的DTLS关联，但以前无法在SDP提议或应答中明确指示是否需要新的DTLS关联。为了解决这个问题，本文档定义了一个新的SDP属性“tls-id”。一对SDP“tls-id”属性值（发起方和应答方的属性值）唯一标识DTLS关联。在SDP提议或应答中提供“tls-id”属性的新值可用于指示是否要建立新的DTLS关联。
在协商传输层安全（Transport Layer Security，TLS）连接时，可以结合使用本文档中的过程以及 [RFC5763] 和 [RFC8122] 中的过程来指定SDP“tls-id”属性。SDP“tls-id”属性值的唯一组合可用于识别协商的TLS连接。例如，可以在TLS协议扩展中使用唯一值来区分多个TLS连接并将这些连接与特定的提议/应答交换相关联。第7节描述了TLS特定的注意事项。
2、惯例
本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们出现在所有内容中时，应按照BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。
3、建立新的DTLS关联
3.1、一般的
在以下情况下，成功进行SDP提供/应答交换后，必须在两个端点之间建立新的DTLS关联：
* 协商的DTLS协商角色发生变化；或者
* 在SDP提议或答复中修改、添加或删除一个或多个证书指纹；或者
* 通过更改本文档中定义的SDP“tls-id”属性的值，使用SDP明确表示建立新的DTLS关联的意图；
注：以上前两项基于 [RFC5763] 中的流程。本规范增加了对使用 SDP“tls-id”属性进行显式信令的支持。
新的DTLS关联只能作为成功的SDP提议/应答交换的结果而建立。每当实体确定需要新的DTLS关联时，该实体必须按照第5节中的过程发起SDP提议/应答交换。
以下部分描述了需要建立新的DTLS关联的典型情况。
在本文档中，两个端点之间的“新DTLS关联”是指初始DTLS关联（当端点之间当前没有建立DTLS关联时）或替换先前建立的DTLS关联。
3.2、当地传输参数的变化
如果端点修改其本地传输参数（地址和/或端口），并且修改需要新的DTLS关联，则端点必须更改其本地SDP“tls-id”属性值（请参阅第4节）。
如果底层传输协议禁止DTLS关联跨越多个五元组（传输/源地址/源端口/目标地址/目标端口），并且如果五元组发生更改，则端点必须更改其本地SDP“tls-id”属性值（请参阅第4节）。这种情况的一个例子是当DTLS通过流控制传输协议（Stream Control Transmission Protocol，SCTP）承载时，如 [RFC6083] 中所述。
3.3、ICE ufrag值的变化
如果端点使用ICE并修改本地ufrag值，并且修改需要新的DTLS关联，则端点必须更改其本地SDP“tls-id”属性值（请参阅第4节）。
4、SDP“tls-id”属性
一对SDP“tls-id”属性值（发起方和应答方的属性值）唯一地标识DTLS关联或TLS连接。
名称：tls-id
值：tls-id-值
使用级别：媒体
字符集相关：否
缺省值：不适用
语法：
tls-id-value = 20*255(tls-id-char) tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_"
示例：a=tls-id:abc3de65cddef001be82
每次端点请求建立新的DTLS关联时，端点必须生成新的本地“tls-id”属性值。未更改的本地“tls-id”属性值与未更改的指纹相结合，表明端点打算重用现有的DTLS关联。
“tls-id”属性值必须使用强随机函数生成，并包含至少120位随机数。
没有为SDP“tls-id”属性定义缺省值。希望使用该属性的实现必须明确地将其包含在SDP提供和应答中。如果提议或应答不包含“tls-id”属性（如果提议者或应答方表示尚未更新以支持“tls-id”属性的现有实现，则可能会发生这种情况），对以下一个或多个特征的修改必须被视为端点想要建立新的DTLS关联的指示，除非有另一种机制明确指示要建立新的DTLS关联：
* DTLS协商角色；或者
* 指纹设置；或者
* 本地传输参数
注意：ufrag 值的修改并不表示端点想要建立新的 DTLS 关联。要表示要建立新的 DTLS 关联，必须修改上述一个或多个特征。
“tls-id”属性的多路复用类别[RFC8859]是“IDENTICAL”，这意味着该属性值适用于正在多路复用的所有媒体描述[RFC8843]。然而，如[RFC8843]中所述，为了避免重复，该属性仅与表示发起方/应答方BUNDLE标记的“m=”行相关联。
对于基于RTP的媒体，“tls-id”属性适用于整个关联的媒体描述。该属性不得针对每个源进行定义（使用SDP“ssrc”属性 [RFC5576]）。
与属性相关的SDP提供/应答过程 [RFC3264] 在第5节中定义。
5、SDP提供/应答程序
5.1、一般的
本节定义了用于协商DTLS关联的通用SDP提供/应答过程。用于各个DTLS使用（例如，DTLS-SRTP）的附加过程（例如，关于特定SDP属性的使用）超出了本规范的范围，需要在特定于使用的文档中指定。
注：本节中的流程是对 DTLS-SRTP 文档 [RFC5763] 中首次规定的流程的概括，并增加了 SDP“tls-id”属性的使用。本文对该文档进行了更新，以使用这些新流程。
本节中的过程适用于与DTLS保护的媒体/数据关联的SDP媒体描述（“m=”行）。
当发起方或应答方指示其想要建立新的DTLS关联时，其需要确保与任何先前建立的DTLS关联和新的DTLS关联关联的媒体分组可以被解复用。在有序传输（例如SCTP）的情况下，这可以简单地通过在与先前建立的DTLS关联相关联的所有数据包已被发送之后发送新的DTLS关联的数据包来完成。在无序传输（例如UDP）的情况下，与先前建立的DTLS关联相关联的数据包可以在应答SDP和与新的DTLS关联相关联的第一数据包已被接收之后到达。解复用与先前建立的DTLS关联和新的DTLS关联关联的数据包的唯一方法是基于五元组。因此，如果无序传输用于DTLS关联，则必须由至少一个端点分配新的三元组（传输/源地址/源端口），以便可以对DTLS数据包进行解复用。
当发起方需要建立新的DTLS关联时，并且如果使用无序传输（例如UDP），则发起方必须为该提供分配一个新的三元组，以便发起方可以区分与新DTLS关联关联的任何数据包和与任何其他DTLS关联关联的任何数据包。这通常意味着使用本地地址和/或端口，或一组ICE候选者（请参阅第6节），这些候选者最近未用于任何其他DTLS关联。
当应答方需要建立新的DTLS关联时，如果使用无序传输，并且发起方没有分配新的三元组，则应答方必须为应答分配一个新的三元组，以便能够区分与新DTLS关联关联的任何数据包和与任何其他DTLS关联关联的任何数据包。这通常意味着使用本地地址和/或端口，或一组ICE候选者（请参阅第6节），这些候选者最近未用于任何其他DTLS关联。
为了协商DTLS关联，使用以下SDP属性：
* SDP“setup”属性，在[RFC4145]中定义，用于协商DTLS角色；
* SDP“指纹”属性，定义于[RFC8122]，用于提供一个或多个证书指纹；和
* 本规范中定义的SDP“tls-id”属性用于标识DTLS关联。
本规范没有定义SDP“连接”属性 [RFC4145] 用于协商DTLS关联的用法。然而，如果DTLS关联与已定义该属性的使用的另一个协议（例如SCTP或TCP）一起使用，则可以使用该属性。
与TCP和TLS连接不同，端点在协商DTLS关联时不得使用SDP“setup”属性“holdconn”值。
端点必须支持 [RFC8122] 中定义的哈希函数。
根据 [RFC8122] 中定义的过程，DTLS握手期间收到的证书 [RFC6347] 必须与SDP“指纹”属性中收到的证书指纹匹配。如果指纹与散列证书不匹配，则端点必须立即终止媒体会话（请参阅[RFC8122]）。
SDP发起方和应答方可以跨多个DTLS关联重复使用证书，并为每个DTLS关联提供相同的证书指纹。SDP发起方和应答方的SDP“tls-id”属性值的组合标识每个单独的DTLS关联。
注意：在某些情况下，由提供方生成的 SDP“tls-id”属性值最终可能用于多个 DTLS 关联。因此，需要结合提供方和应答方的属性值来识别 DTLS 关联。例如，当提供方发送更新后的 offer（参见 5.5 节）但未修改其属性值时，应答方会判断需要创建一个新的 DTLS 关联。此时，应答方会为新的 DTLS 关联生成一个新的本地属性值（参见 5.3 节），而提供方则使用与当前关联相同的属性值。另一个例子是，当使用会话发起协议 (Session Initiation Protocol，SIP) [RFC3261] 进行信令传输，并且 offer 被分叉给多个应答方时，提供方生成的属性值将用于每个应答方建立的 DTLS 关联。
5.2、生成初始SDP报价
当发起方发送初始报价时，发起方必须根据[RFC8122]中的过程插入一个具有“actpass”属性值的SDP“setup”属性[RFC4145]，以及一个或多个SDP“指纹”属性。此外，发起方必须在报价中插入具有唯一属性值的SDP“tls-id”属性。
当发起方插入带有“actpass”属性值的SDP“setup”属性时，发起方必须准备好在收到SDP应答之前从应答方接收DTLS ClientHello消息 [RFC6347]（如果应答方建立了新的DTLS关联）。
如果发起方收到DTLS ClientHello消息，并且在发起方收到携带与DTLS关联关联的指纹的SDP应答之前建立了DTLS关联，则在指纹之前在DTLS关联上接收到的任何数据都必须被视为来自未经验证的源。发起方对此类数据的处理以及向未经验证的来源发送数据不属于本文档的范围。
5.3、生成应答
当应答方发送应答时，应答方必须根据[RFC4145]中的过程在应答中插入一个SDP“设置”属性，并根据[RFC8122]中的过程插入一个或多个SDP“指纹”属性。如果应答方根据第3.1节中指定的标准确定要建立新的DTLS关联，则应答方必须在关联应答中插入具有新的唯一属性值的SDP“tls-id”属性。请注意，发起方和应答方生成自己的本地“tls-id”属性值，并且两个值的组合标识DTLS关联。
如果应答方收到要求建立新的DTLS关联的提议，并且如果应答方不接受建立新的DTLS关联，则应答方必须拒绝与建议的DTLS关联关联的“m=”行 [RFC3264]。
如果应答方收到不需要建立新的DTLS关联的提议，并且如果应答方确定不建立新的DTLS关联，则应答方必须在关联的应答中插入具有先前分配的属性值的SDP“tls-id”属性。此外，应答方必须在相关应答中插入一个SDP“设置”属性，其属性值不会更改先前协商的DTLS角色，以及一个或多个SDP“指纹”属性值，该属性值不会更改先前发送的指纹集。
如果应答方收到不包含SDP“tlsid”属性的报价，则应答方不得在应答中插入“tls-id”属性。
如果要建立新的DTLS关联，并且应答方在应答中插入具有“active”属性值的SDP“setup”属性，则应答方必须通过向发起方发送DTLS ClientHello消息来发起DTLS握手 [RFC6347]。
即使发起方需要在初始报价（第5.2节）和后续报价（第5.5节）中插入带有“actpass”属性值的“SDP”设置属性，应答方也必须能够接收具有其他属性值的初始和后续报价，以便向后兼容可能在初始和后续报价中插入其他属性值的旧实现。
5.4、发起方对SDP应答的处理
当发起方收到基于第3.1节中定义的标准建立新DTLS关联的应答时，如果发起方成为DTLS客户端（基于SDP“setup”属性值 [RFC4145]），则发起方必须建立DTLS关联。如果发起方成为DTLS服务器，它必须等待应答方建立DTLS关联。
如果发起方表示希望重用现有的DTLS关联，并且应答方不请求建立新的DTLS关联，则发起方将继续使用先前建立的DTLS关联。
可以根据SDP提议或应答中的更改来建立新的DTLS关联。与旧端点通信时，发起方可以收到包含相同指纹集和协商角色的应答。如果接收到这样的应答作为对请求建立新的DTLS关联的要约的响应，则仍将建立新的DTLS关联，因为要约中的传输参数可能已被更改。
5.5、修改会话
当提议者发送后续提议时，如果提议者想要建立新的DTLS关联，则提议者必须根据 [RFC8122] 中的过程插入带有“actpass”属性值的SDP“setup”属性 [RFC4145]，以及一个或多个SDP“指纹”属性。此外，发起方必须在报价中插入具有新的唯一属性值的SDP“tls-id”属性。
当提议者发送后续提议并且不想建立新的DTLS关联时，如果先前建立的DTLS关联存在，则提议者必须在提议中插入具有“actpass”属性值的SDP“setup”属性，以及一个或多个具有不更改先前发送的指纹集的属性值的SDP“指纹”属性。此外，发起方必须在报价中插入具有先前分配的属性值的SDP“tls-id”属性。
注意：当建立新的 DTLS 关联时，每个端点都需要准备好接收有关新旧 DTLS 关联的数据，只要这两个关联都处于活动状态。
6、ICE考虑因素
当使用交互式连接建立（Interactive Connectivity Establishment，ICE）机制[RFC8445]时，ICE连接检查在DTLS握手开始之前执行。请注意，如果使用积极的提名模式，则在ICE最终收敛到单个候选对之前，多个候选对可能会被标记为有效。
注意：ICE 已弃用主动提名，但出于向后兼容性的原因仍必须支持 [RFC8445]。
当通过无序传输建立新的DTLS关联时，为了消除与新建立的DTLS关联关联的任何数据包的歧义，至少一个端点必须分配一组全新的ICE候选者，这些候选者最近未用于任何其他DTLS关联。这意味着除非发起方发起ICE重启，否则应答方无法发起新的DTLS关联 [RFC8445]。如果应答方想要启动新的DTLS关联，它需要自行启动ICE重启和新的提供/应答交换。但是，默认情况下，ICE重新启动不需要建立新的DTLS关联。
注意：通过 NAT 简单穿越 UDP 协议 (Simple Traversal of the UDP Protocol through NAT，STUN) 数据包直接通过 UDP 发送，而不是通过 DTLS 发送。[RFC7983] 描述了如何从 DTLS 数据包和 SRTP 数据包中解复用 STUN 数据包。
与组件关联的每个ICE候选者都被视为同一DTLS关联的一部分。因此，从DTLS的角度来看，当端点在这些ICE候选者之间切换时，不被视为本地传输参数的更改。
7、TLS注意事项
本文档中的过程还可用于协商和建立TLS连接，但具有下述限制。
正如[RFC4145]中规定的，SDP“连接”属性用于指示是否建立新的TLS连接。发起方和应答方必须确保“connection”属性值和“tls-id”属性值不会导致关于是否建立新的TLS连接的冲突。
注意：虽然 SDP 的“connection”属性可用于指示是否要建立新的 TLS 连接，但 SDP 的“tls-id”属性值的唯一组合可用于标识 TLS 连接。例如，该唯一值可用于 TLS 协议扩展中，以区分多个 TLS 连接并将这些连接与特定的 offer/answer 交换关联起来。[RFC8844] 中定义了这样一个扩展。
如果发起方或应答方在提供/应答中插入具有“新”值的SDP“连接”属性，并且还插入SDP“tls-id”属性，则“tls-id”属性的值必须是新的且唯一的。
如果提议者或应答方在提议/应答中插入具有“现有”值的SDP“连接”属性，如果先前建立的TLS连接存在，并且如果提议者/应答方先前在提议/应答中插入了与相同TLS连接关联的SDP“tls-id”属性，则提议者/应答方还必须在提议/应答中插入具有先前分配的值的SDP“tls-id”属性。
如果提议者或应答方收到具有冲突属性值的提议/应答，则提议者/应答方必须将提议/应答处理为格式错误。
端点不得做出有关对等方对SDP“tls-id”属性的支持的假设。因此，为了避免歧义，发起方和应答方都必须始终将“connection”属性与“tls-id”属性结合使用。
注意：如 [RFC4145] 中所定义，如果 SDP“connection”属性未显式存在，则隐式缺省值为“new”。
下面的SDP示例基于 [RFC8122] 第3.4节中的示例，并添加了SDP“tls-id”属性。
m=image 54111 TCP/TLS t38 c=IN IP4 192.0.2.2 a=tls-id:abc3de65cddef001be82 a=setup:passive a=connection:new a=fingerprint:SHA-256 \ 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 3E:5D:49:6B:19:E5:7C:AB:4A:AD a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
8、SIP注意事项
当会话发起协议（Session Initiation Protocol，SIP）[RFC3261]用作建立多媒体会话的信号协议时，可以在呼叫者和多个被呼叫者之间建立对话[RFC3261]。这称为分叉。如果发生分叉，将在调用者和每个被调用者之间建立单独的DTLS关联。
当分叉发生时，SDP发起方可以从多个远程位置接收DTLS ClientHello消息和SDP应答。因此，发起方可能必须等待多个SDP应答（来自不同的远程位置），直到收到与特定DTLS握手关联的证书相匹配的证书指纹。发起方不得声明指纹不匹配，直到确定不会从任何其他远程位置收到SDP应答。
可以发送不包含SDP提议的INVITE请求。这样的INVITE请求通常被称为“空INVITE”或“无报价INVITE”。接收端点将在对请求的响应中包含SDP提议。当端点生成这样的SDP提议时，如果先前建立的DTLS关联存在，则提议者必须插入SDP“tls-id”属性和一个或多个SDP“指纹”属性以及先前分配的属性值。如果先前建立的DTLS关联不存在，则报价必须基于与新报价相同的规则生成（参见第5.2节）。无论之前是否存在DTLS关联，都必须根据 [RFC4145] 中定义的规则包含SDP“setup”属性。此外，如果使用ICE，则必须根据 [RFC8839] 中描述的第三方呼叫控制注意事项启动ICE重启。
9、RFC更新
9.1、一般的
本节更新了使用DTLS保护媒体的规范，以反映本规范中定义的过程。
9.2、对RFC 5763的更新
9.2.1、更新第1节
对 [RFC4572] 的引用被对 [RFC8122] 的引用替换。
9.2.2、更新第5节
[RFC5763]第5节（“建立安全通道”）中的文本已修改，通过引用本规范替换DTLS的通用SDP提供/应答过程：
新文本：
交换过程中的两个端点使用证书在 DTLS 握手过程中展示其身份。本文档使用的证书样式与“基于传输层安全协议 (TLS) 的会话描述协议 (SDP) 中的面向连接的媒体传输”[RFC8122] 中描述的相同。如果使用自签名证书，证书中的“subjectAltName”属性的内容可以使用用户的统一资源标识符 (URI)。这仅用于调试目的，并非将证书绑定到任何通信端点的必要条件。证书的完整性通过 SDP 中的“fingerprint”属性来保证。生成公钥/私钥对的成本相对较高。端点无需为每个会话生成证书。会话发起协议 (SIP) [RFC3261] 等协议使用 [RFC3264] 中定义的 offer/answer 模型来建立多媒体会话。当一个端点希望与另一个端点建立安全媒体会话时，它会向对方发送一个 SIP 消息，其中包含一个 Offer。该 Offer 的 SDP 有效负载中包含端点想要使用的证书的指纹。端点应该通过完整性保护通道将包含 Offer 的 SIP 消息发送给 Offer 方的 SIP 代理。代理应该按照 [RFC4474] 中概述的流程添加一个 Identity 标头字段。当远端端点收到 SIP 消息时，它可以使用 Identity 标头字段验证发送方的身份。由于 Identity 标头字段是对多个 SIP 标头字段（包括 SIP 消息正文）进行数字签名，因此接收方还可以确定消息在应用数字签名并添加到 SIP 消息后未被篡改。远端端点（应答方）现在可以与 Offer 方建立 DTLS 关联。或者，它可以在应答中指示由 Offer 方发起 DTLS 关联。无论哪种情况，都将使用基于证书的双向 DTLS 认证。完成 DTLS 握手后，已认证身份的信息（包括证书）将提供给终端应用程序。应答方随后可以验证提供方在 DTLS 握手中用于认证的证书是否与 SDP 中包含的证书指纹相关联。此时，应答方可以向最终用户表明媒体已安全。提供方可能只是暂时接受应答方的证书，因为它可能尚未获得应答方的证书指纹。当应答方接受提供方的证书时，它会向提供方返回一个包含应答方证书指纹的应答。此时，提供方可以接受或拒绝对端的证书，并可以向最终用户表明媒体已安全。请注意，用于保护媒体流量的整个认证和密钥交换过程均通过 DTLS 在媒体面中处理。信令面仅用于验证对端的证书指纹。提供方和应答方必须遵循 RFC 8842 中定义的 SDP 提供/应答程序。
9.2.3、更新第6.6节
[RFC5763]第6.6节（“会话修改”）中的文本已修改，通过引用本规范替换DTLS的通用SDP提供/应答过程：
新文本：
一旦向提供方提供应答，任一端点均可请求会话修改，其中可能包含更新后的提供信息。此会话修改可通过 INVITE 请求或 UPDATE 请求进行。对等方可以重用现有的 DTLS 关联，也可以按照 RFC 8842 中的流程建立新的关联。
9.2.4、更新第6.7.1节
[RFC5763]第6.7.1节（“ICE交互”）中的文本已修改，通过引用本规范替换ICE过程：
新文本：
RFC 8842 中描述了 DTLS 保护媒体的交互式连接建立 (ICE) [RFC8445] 注意事项。
9.3、对RFC 7345的更新
9.3.1、更新第4节
[RFC7345] 第4节（“SDP发起方/应答方程序”）中的小节（4.1 – 4.5）被删除并替换为以下新文本：
新文本：
端点（即提供方和应答方）必须为每个 UDPTL over DTLS 媒体流创建 SDP 媒体描述（“m=” 行”），并且必须为“m=” 行”的“proto”字段分配一个 UDP/TLS/UDPTL 值（参见表 1）。提供方和应答方必须遵循 RFC 8842 中定义的 SDP 提供/应答流程，以协商与 UDPTL over DTLS 媒体流关联的 DTLS 连接。此外，提供方和应答方必须使用 [ITU.T38] 中定义的为 UDPTL over UDP 定义的 SDP 属性。
9.3.2、更新第5.2.1节
[RFC7345]第5.2.1节（“ICE使用”）中的文本已修改，通过引用本规范替换ICE过程：
新文本：
RFC 8842 中描述了 DTLS 保护媒体的交互式连接建立 (ICE) [RFC8445] 注意事项。
9.3.3、更新第9.1节
对 [RFC8122] 的引用添加到 [RFC7345]，第9.1节（“规范性引用”）：
新文本：
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, <https://www.rfc-editor.org/info/rfc8122>.
10、安全考虑
本规范不会修改与DTLS或SDP提供/应答机制相关的安全注意事项。除了介绍SDP“tls-id”属性之外，本文档还简单阐明了协商和建立DTLS关联的过程。
本规范不会修改实际的TLS连接设置过程。SDP“tls-is”属性本身不能用于将SDP Offer/answer交换与TLS连接设置相关联。因此，本文档没有引入与将SDP Offer/answer交换与TLS连接设置关联相关的新安全注意事项。
11、IANA考虑因素
本文档更新了 [RFC4566] 第8.2.2节中指定的“会话描述协议参数”注册表。具体来说，它将SDP“tls-id”属性添加到SDP媒体级属性表中，如下所示。
属性名称：tls-id
属性类型：媒体级
受字符集限制：否
用途：指示是否要建立/重新建立新的DTLS关联或TLS连接。
适当的值：参见第4节
联系人姓名：Christer Holmberg
多路复用器类别：相同
12、参考文献
12.1、规范性参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <https://www.rfc-editor.org/info/rfc4145>.[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.[RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 2014, <https://www.rfc-editor.org/info/rfc7345>.[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, <https://www.rfc-editor.org/info/rfc8122>.[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>.[RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.
12.2、参考资料丰富
[ITU.T38] ITU-T, "Procedures for real-time Group 3 facsimile communication over IP networks", Recommendation T.38, September 2010, <https://www.itu.int/rec/T-REC-T.38/en>.[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <https://www.rfc-editor.org/info/rfc4474>.[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, DOI 10.17487/RFC4572, July 2006, <https://www.rfc-editor.org/info/rfc4572>.[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <https://www.rfc-editor.org/info/rfc5576>.[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, January 2011, <https://www.rfc-editor.org/info/rfc6083>.[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, <https://www.rfc-editor.org/info/rfc7983>.[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/info/rfc8224>.[RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021, <https://www.rfc-editor.org/info/rfc8839>.[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)", RFC 8844, DOI 10.17487/RFC8844, January 2021, <https://www.rfc-editor.org/info/rfc8844>.
致谢
感谢Justin Uberti、Martin Thomson、Paul Kyzivat、Jens Guballa、Charles Eckel、Gonzalo Salgueiro和Paul Jones对本文档提供的意见和建议。Ben Campbell进行了区域总监审查。Paul Kyzivat进行了Gen-ART审查。
***推荐阅读***
我们的WireGuard管理系统支持手机电脑了！全平台终端配置，支持扫码连接，一键搞定
保姆级教程：一条命令部署OpenVPN管理系统V4版，支持Win/Mac/安卓/iOS全平台接入
成本省下99.7%！用40元的腾讯云服务器自建IPsecVPN，成功对接企业级飞塔防火墙
别再乱选VPN了！实测数据告诉你：为什么L2TP是个“坑”
终极进化：当swanctl遇上FRR，让你的Linux加密隧道化身SD-WAN雏形
流量指哪打哪！手把手教你用静态Segment List玩转SRv6流量工程
嫌SRv6报文太胖跑不动？带你在Ubuntu+FRR实战uSID微段压缩
22秒跑出密码！算力碾压再升级，揭秘WiFi6+WPA3的致命短板
嫌一键部署不过瘾？带你手搓Hermes智能体，主打一个通透
十倍性能提升！Ubuntu 26.04深度实测：当VPP遇上OpenVPN，带宽直接冲破 6.5Gbps！
性能暴涨670 %！当WireGuard遇上VPP，带宽直冲7.4 Gbps！
手机也能跑DeepSeek-R1/Qwen3了：零成本搭建AI推理平台
2048卡昇腾910C集群算力集群交付工程手册
2048卡H100算力中心100G无阻塞存储网建设方案
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：铁军哥 衡水石头哥 衡水石头哥《数据报传输层安全（DTLS）和传输层安全（TLS）的会话描述协议（SDP）提供/应答注意事项》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论