RFC-8285：RTP头部扩展通用机制

需积分: 1 55 浏览量更新于2024-06-22 收藏 38KB PDF 举报

RFC-8285《RTP头部扩展通用机制》是由Internet Engineering Task Force (IETF) 的 D. Singer 和 Apple, Inc. 联合制定的一份标准草案，它在2017年10月发布。这份文档的主要目的是为了提供一种普遍的解决方案，使得在实时传输协议(RTP)的头部结构中能够支持大量的小型扩展，同时保持注册过程的去中心化。在RTP的每个数据包中，尽管可能的扩展种类繁多，但只有实际使用的那些会在会话的设置信息中明确标识。该标准旨在替代之前的RFC 5285，反映出技术进步和需求的变化。RFC-8285被定义为互联网标准化跟踪文档，这意味着它代表了IETF社区的共识，并经过了公共审查，由Internet Engineering Steering Group (IESG) 批准发布。关于互联网标准的更多信息，可以通过RFC 7841的第2节获取。 RFC-8285的核心内容包括： 1. **RTP头部扩展机制**：文档提出了一个通用的框架，允许在每个RTP数据包中添加少量的自定义扩展字段，这些扩展可以用于增加额外的功能，如媒体编码的元数据、服务质量(QoS)信息或安全特性等。 2. **去中心化注册**：与过去的集中注册模型不同，新的机制鼓励开发者和用户自行创建和使用扩展，而无需通过繁琐的注册过程。这种设计提高了灵活性和适应性，促进了创新。 3. **信号扩展使用**：在会话建立阶段，通过设置信息明确指明实际使用的扩展，确保接收端可以正确解析和处理这些额外信息。 4. **标准化流程**：作为IETF的产品，文档遵循严格的标准化流程，包括公开讨论、专家评审和批准发布，以保证技术的可靠性和一致性。 5. **错误和更新**：任何关于此文档的当前状态、已发现的错误或后续版本的信息，都可通过文档本身提供的链接或者IETF的网站进行查询，确保及时更新和维护。 RFC-8285的重要性在于它为RTP头部扩展提供了一个灵活且可扩展的架构，使得网络通信协议能够更好地满足现代应用的需求，同时保持了良好的标准化和互操作性。随着技术的发展，这一规范对于视频会议、实时通信和多媒体传输等领域具有深远影响。

RFC 8285 RTP Header Extensions October 2017

functionality if the MID is missing, but the operation of the RTP

layer of those applications will be unaffected. Support for RTP

header extensions based on this memo is negotiated using, for

example, SDP Offer/Answer [RFC3264]; intermediaries aware of the RTP

header extensions are advised to be cautious when removing or

generating RTP header extensions. See Section 4.7 of [RFC7667].

The RTP header extension is formed as a sequence of extension

elements, with possible padding. Each extension element has a local

identifier and a length. The local identifiers MAY be mapped to a

larger namespace in the negotiation (e.g., session signaling).

4.1.1. Transmission Considerations

As is good network practice, data should only be transmitted when

needed. The RTP header extension SHOULD only be present in a packet

if that packet also contains one or more extension elements, as

defined here. An extension element SHOULD only be present in a

packet when needed; the signaling setup of extension elements

indicates only that those elements can be present in some packets,

not that they are in fact present in all (or indeed, any) packets.

Some general considerations for getting the header extensions

delivered to the receiver are as follows:

1. The probability for packet loss and burst loss determines how

many repetitions of the header extensions will be required to

reach a targeted delivery probability, and if burst loss is

likely, what distribution would be needed to avoid losing all

repetitions of the header extensions in a single burst.

2. If a set of packets are all needed to enable decoding, there is

commonly no reason for including the header extension in all of

these packets, as they share fate. Instead, at most one instance

of the header extension per independently decodable set of media

data would be a more efficient use of the bandwidth.

3. How early the header extension item information is needed, from

the first received RTP data or only after some set of packets are

received, can guide whether the header extension(s) should be

(1) in all of the first N packets or (2) included only once per

set of packets -- for example, once per video frame.

Singer, et al. Standards Track [Page 5]

剩余24页未读，继续阅读

毕加索解锁

粉丝: 2503
资源: 24

RFC-8285：RTP头部扩展通用机制

RFC-6184 RTP Payload Format for H.264 Video (H.264)

keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem

rfc viewer

rfc1305-1992

rfc全部文档离线下载rfc1-rfc8505

rfc4588 RTP重传有效载荷格式

rfc 3550 中文版

上述中，info与rfc2833的包差异在哪儿

The valid characters are defined in RFC 7230 and RFC 3986什么意思

netty websocket

最新资源