RFC-8285AGeneralMechanismforRTPHeaderExtensions资源-CSDN文库

需积分: 1 3 浏览量 2023-08-07 10:46:35 上传评论收藏 38KB PDF 举报

资源推荐

资源详情

资源评论

Internet Engineering Task Force (IETF) D. Singer

Request for Comments: 8285 Apple, Inc.

Obsoletes: 5285 H. Desineni

Category: Standards Track Qualcomm

ISSN: 2070-1721 R. Even, Ed.

Huawei Technologies

October 2017

A General Mechanism for RTP Header Extensions

Abstract

This document provides a general mechanism to use the header

extension feature of RTP (the Real-time Transport Protocol). It

provides the option to use a small number of small extensions in each

RTP packet, where the universe of possible extensions is large and

registration is decentralized. The actual extensions in use in a

session are signaled in the setup information for that session. This

document obsoletes RFC 5285.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force

(IETF). It represents the consensus of the IETF community. It has

received public review and has been approved for publication by the

Internet Engineering Steering Group (IESG). Further information on

Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata,

and how to provide feedback on it may be obtained at

https://www.rfc-editor.org/info/rfc8285.

Singer, et al. Standards Track [Page 1]

RFC 8285 RTP Header Extensions October 2017

This document is subject to BCP 78 and the IETF Trust’s Legal

Provisions Relating to IETF Documents

(https://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect

to this document. Code Components extracted from this document must

include Simplified BSD License text as described in Section 4.e of

the Trust Legal Provisions and are provided without warranty as

described in the Simplified BSD License.

Table of Contents

1. Introduction ....................................................3

2. Requirements Notation ...........................................3

3. Design Goals ....................................................3

4. Packet Design ...................................................4

4.1. General ....................................................4

4.1.1. Transmission Considerations .........................5

4.1.2. Header Extension Type Considerations ................6

4.2. One-Byte Header ............................................8

4.3. Two-Byte Header ............................................9

5. SDP Signaling Design ...........................................10

6. SDP Signaling for Support of Mixed One-Byte and Two-Byte

Header Extensions ..........................................12

7. SDP Offer/Answer ...............................................13

8. BNF Syntax .....................................................17

9. Security Considerations ........................................17

10. IANA Considerations ...........................................18

10.1. Identifier Space for IANA to Manage ......................18

10.2. Registration of the SDP "extmap" Attribute ...............20

10.3. Registration of the SDP "extmap-allow-mixed" Attribute ...20

11. Changes from RFC 5285 .........................................21

12. References ....................................................21

12.1. Normative References .....................................21

12.2. Informative References ...................................23

Acknowledgments ...................................................24

Authors’ Addresses ................................................25

Singer, et al. Standards Track [Page 2]

RFC 8285 RTP Header Extensions October 2017

1. Introduction

The RTP specification [RFC3550] provides a capability to extend the

RTP header. Section 5.3.1 of [RFC3550] defines the header extension

format and rules for its use. The existing header extension method

permits at most one extension per RTP packet, identified by a 16-bit

identifier and a 16-bit length field specifying the length of the

header extension in 32-bit words.

This mechanism has two conspicuous drawbacks. First, it permits only

one header extension in a single RTP packet. Second, the

specification gives no guidance as to how the 16-bit header extension

identifiers are allocated to avoid collisions.

This specification removes the first drawback by defining a backward-

compatible and extensible means to carry multiple header extension

elements in a single RTP packet. It removes the second drawback by

defining that these extension elements are named by URIs, defining an

IANA registry for extension elements defined in IETF specifications,

and providing a Session Description Protocol (SDP) method for mapping

between the naming URIs and the identifier values carried in the RTP

packets.

This header extension applies to RTP/AVP (the Audio/Visual Profile)

and its extensions.

This document obsoletes [RFC5285] and removes a limitation from

RFC 5285 that did not allow sending both one-byte and two-byte header

extensions in the same RTP stream.

2. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

"OPTIONAL" in this document are to be interpreted as described in

BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all

capitals, as shown here.

3. Design Goals

The goal of this design is to provide a simple mechanism whereby

multiple identified extensions can be used in RTP packets, without

the need for formal registration of those extensions but nonetheless

avoiding collisions.

This mechanism provides an alternative to the practice of burying

associated metadata into the media format bitstream. This has often

been done in media data sent over fixed-bandwidth channels. Once

Singer, et al. Standards Track [Page 3]

RFC 8285 RTP Header Extensions October 2017

this is done, a decoder for the specific media format needs to

extract the metadata. Also, depending on the media format, the

metadata can be added at the time of encoding the media so that the

bit-rate used for the metadata is taken into account. But the

metadata can be unknown at that time. Inserting metadata at a later

time can cause a decode and re-encode to meet bit-rate requirements.

In some cases, a more appropriate and higher-level mechanism may be

available, and if so, it can be used. For cases where a higher-level

mechanism is not available, it is better to provide a mechanism at

the RTP level than to have the metadata be tied to a specific form of

media data.

4. Packet Design

4.1. General

The following design is fit into the "header extension" of the RTP

extension, as described above.

The presence and format of this header extension and its contents are

negotiated or defined out of band, such as through signaling (see

below for SDP signaling). The 16-bit identifier for the two forms of

the RTP extension defined here is only an architectural constant

(e.g., for use by network analyzers); it is the negotiation/

definition (e.g., in SDP) that is the definitive indication that this

header extension is present.

The RTP specification [RFC3550] states that RTP "is designed so that

the header extension may be ignored by other interoperating

implementations that have not been extended." The intent of this

restriction is that RTP header extensions MUST NOT be used to extend

RTP itself in a manner that is backward incompatible with

non-extended implementations. For example, a header extension is not

allowed to change the meaning or interpretation of the standard RTP

header fields or of the RTP Control Protocol (RTCP). Header

extensions MAY carry metadata in addition to the usual RTP header

information, provided the RTP layer can function if that metadata is

missing. For example, RTP header extensions can be used to carry

data that’s also sent in RTCP, as an optimization to lower latency,

since they’ll fall back to the original non-optimized behavior if the

header extension is not present. The use of header extensions to

convey information that will, if missing, disrupt the behavior of a

higher-layer application that builds on top of RTP is only acceptable

if this doesn’t affect interoperability at the RTP layer. For

example, applications that use the SDP BUNDLE extension with the

Media Identification (MID) RTP header extension [SDP-BUNDLE] to

correlate RTP streams with SDP "m=" lines likely won’t work with full

Singer, et al. Standards Track [Page 4]

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页未读，继续阅读

评论收藏

内容反馈

毕加索解锁

粉丝: 2139
资源: 24

RFC-8285 A General Mechanism for RTP Header Extensions

最新资源

RFC-8285 A General Mechanism for RTP Header Extensions

RFC-3550 A Transport Protocol for Real-Time Applications (RTP)

RFC-4585 Extended RTP Profile for RTCP - Based Feedback (RTCP-FB

RFC-7798 RTP Payload Format for High Efficiency Video Coding

RFC-3640 RTP Payload Format for Transport of MPEG-4 Elementary S

RFC-7587 RTP Payload Format for the Opus Speech and Audio Codec

RFC-7741 RTP Payload Format for VP8 Video (VP8)

RFC-5404 RTP Payload Format for G.719 (G.719)

RFC-2032 RTP Payload Format for H.261 Video Streams (FIR)

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

RFC-7655 RTP Payload Format for G.711.0 (G.711)

RFC-4749 RTP Payload Format for the G.729.1 Audio Codec (G.729)

RFC10xx 内容,分析与详解

RFC-5104 Codec Control Messages in the RTP Audio-Visual Profile

RFC1889-(RTP)-协议中文概要

RFC-3550 RTP中英文版

RFC-3550-RTP协议-中文版.pdf

Python库 | rfc-xmldiff-0.5.2.tar.gz

rfc-index.zip_RFC_index_rfc-all

RFC-33A.rar_rfc-33a

落雪音乐-六音音源 sixyin-music-source-v1.1.0.js

markdown配套文件，使用前先解压

喜马拉雅xm文件解密工具

OCPP协议解析 代码+代码含义详解

mpp_demo.rar

m3u8的下载转换工具

ubuntu下安装ffmpeg必备软件包合集

音频转码，无限制的享受音乐吧！

OPENCV函数手册（中文）.zip

ev4转mp4小工具（无视授权密码）

最新资源

OCPP协议解析代码+代码含义详解