截至2025年4月，定义WebRTC ICE候选数据格式的最新RFC是哪一个？

截至2025年4月，定义WebRTC ICE候选数据格式的最新RFC是哪一个？

RFC 5245曾定义ICE候选数据格式：

candidate:842163049 1 udp 1677729535 192.168.1.2 61734 typ srflx raddr 10.0.0.2 rport 54321

该格式可通过RFC 5245第15.1节“candidate”属性明确识别：

15.1. "candidate" 属性

candidate属性仅属于媒体级属性，包含一个可用于连通性检查的候选传输地址。

该属性的语法采用RFC 5234定义的增强型BNF（Augmented BNF）描述：

candidate-attribute = "candidate" ":" foundation SP component-id SP
transport SP
priority SP
connection-address SP ;引自RFC 4566
port ;引自RFC 4566的端口定义
SP cand-type
[SP rel-addr]
[SP rel-port]
*(SP extension-att-name SP
extension-att-value)

foundation = 132ice-char
component-id = 15DIGIT
transport = "UDP" / transport-extension
transport-extension = token ;引自RFC 3261
priority = 1*10DIGIT
cand-type = "typ" SP candidate-types
candidate-types = "host" / "srflx" / "prflx" / "relay" / token
rel-addr = "raddr" SP connection-address
rel-port = "rport" SP port
extension-att-name = byte-string ;引自RFC 4566
extension-att-value = byte-string
ice-char = ALPHA / DIGIT / "+" / "/"

但RFC 5245已被废弃，现需查找定义该格式的最新RFC。

RFC 8445第5.3节“交换候选信息”包含类似内容，但描述不够明确——比如仅提到“类型：候选者的类型”，却未指明ICE候选数据中必须使用typ标识。

5.3. 交换候选信息

ICE代理（发起方和响应方）需要交换以下候选者相关信息。每种ICE应用场景必须定义如何通过所用协议交换这些信息。本节描述需要交换的具体内容：

候选者：一个或多个候选者，每个候选者包含：

地址：候选者的IP地址和传输协议端口。

传输协议：候选者使用的传输协议。如果所用协议仅基于单一传输协议，该字段可省略。

基础标识：最多32个字符的序列。

组件ID：候选者的组件ID。如果所用协议不涉及组件概念，该字段可省略。

优先级：32位的候选者优先级。

类型：候选者的类型。

关联地址和端口：候选者的关联IP地址和端口。如果代理出于隐私等原因不想暴露这些信息，可省略或设为无效值。

扩展参数：所用协议可定义未来添加新的ICE候选者参数的方式。

内容的提问来源于stack exchange，提问作者mon