RFC-4749RTPPayloadFormatfortheG.729.1AudioCodec(G.729)资源-CSDN文库

需积分: 1 136 浏览量 2023-08-07 10:41:13 上传评论收藏 20KB PDF 举报

RFC 4749 - RTP Payload Format for the G.729.1 Audio Codec (G.729) RFC 4749是一份由Internet Engineering Task Force (IETF)发布的标准-track文档，旨在定义Real-time Transport Protocol (RTP) payload格式，以便在IP网络中传输G.729.1音频编解码器编码的音频数据。标题“RFC 4749 RTP Payload Format for the G.729.1 Audio Codec (G.729)”表明了该文档的主要内容是定义RTP payload格式，以便在IP网络中传输G.729.1音频编解码器编码的音频数据。G.729.1是一种由International Telecommunication Union (ITU-T)开发的音频编解码器，能够在低比特率下提供高质量的音频。描述“RFC-4749 RTP Payload Format for the G.729.1 Audio Codec (G.729)”同样表明了该文档的主要内容是定义RTP payload格式，以便在IP网络中传输G.729.1音频编解码器编码的音频数据。标签“RFC”表明该文档是 getRequest for Comments（RFC）文档，RFC是IETF发布的一系列标准-track文档，旨在定义Internet协议和技术标准。部分内容中，文档首先介绍了G.729.1音频编解码器的背景，然后讨论了嵌入式比特率的考虑因素，接着介绍了RTP头的使用方法。然后，文档详细地描述了payload格式的结构、payload头的字段、音频数据的格式等内容。文档还讨论了负载格式参数、媒体类型注册、会话描述协议（SDP）参数映射等内容。从文档的内容来看，RFC 4749定义了一个RTP payload格式，以便在IP网络中传输G.729.1音频编解码器编码的音频数据。该文档对RTP payload格式的定义为G.729.1音频编解码器的应用提供了一个标准的解决方案。知识点： 1. RTP payload格式：RFC 4749定义了一个RTP payload格式，以便在IP网络中传输G.729.1音频编解码器编码的音频数据。 2. G.729.1音频编解码器：G.729.1是一种由International Telecommunication Union (ITU-T)开发的音频编解码器，能够在低比特率下提供高质量的音频。 3. 嵌入式比特率：RFC 4749讨论了嵌入式比特率的考虑因素，以确保音频数据的传输质量。 4. RTP头的使用方法：RFC 4749介绍了RTP头的使用方法，以便在IP网络中传输音频数据。 5. payload格式的结构：RFC 4749详细地描述了payload格式的结构，包括payload头的字段、音频数据的格式等内容。 6. 媒体类型注册：RFC 4749讨论了媒体类型注册，以便在IP网络中传输音频数据。 7. 会话描述协议（SDP）参数映射：RFC 4749讨论了SDP参数映射，以便在IP网络中传输音频数据。

资源推荐

资源详情

资源评论

Network Working Group A. Sollaud

Request for Comments: 4749 France Telecom

Category: Standards Track October 2006

RTP Payload Format for the G.729.1 Audio Codec

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Abstract

This document specifies a Real-time Transport Protocol (RTP) payload

format to be used for the International Telecommunication Union

(ITU-T) G.729.1 audio codec. A media type registration is included

for this payload format.

Table of Contents

1. Introduction ....................................................2

2. Background ......................................................2

3. Embedded Bit Rates Considerations ...............................3

4. RTP Header Usage ................................................3

5. Payload Format ..................................................4

5.1. Payload Structure ..........................................4

5.2. Payload Header: MBS Field ..................................4

5.3. Payload Header: FT Field ...................................6

5.4. Audio Data .................................................6

6. Payload Format Parameters .......................................7

6.1. Media Type Registration ....................................7

6.2. Mapping to SDP Parameters ..................................8

6.2.1. Offer-Answer Model Considerations ...................9

6.2.2. Declarative SDP Considerations .....................11

7. Congestion Control .............................................11

8. Security Considerations ........................................11

9. IANA Considerations ............................................12

10. References ....................................................12

10.1. Normative References .....................................12

10.2. Informative References ...................................12

Sollaud Standards Track [Page 1]

RFC 4749 RTP Payload Format for G.729.1 October 2006

1. Introduction

The International Telecommunication Union (ITU-T) recommendation

G.729.1 [1] is a scalable and wideband extension of the

recommendation G.729 [9] audio codec. This document specifies the

payload format for packetization of G.729.1 encoded audio signals

into the Real-time Transport Protocol (RTP).

The payload format itself is described in Section 5. A media type

registration and the details for the use of G.729.1 with SDP are

given in Section 6.

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

"SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC 2119 [2].

2. Background

G.729.1 is an 8-32 kbps scalable wideband (50-7000 Hz) speech and

audio coding algorithm interoperable with G.729, G.729 Annex A, and

G.729 Annex B. It provides a standardized solution for packetized

voice applications that allows a smooth transition from narrowband to

wideband telephony.

The most important services addressed are IP telephony and

videoconferencing, either for enterprise corporate networks or for

mass market (like Public Switched Telephone Network (PSTN) emulation

over DSL or wireless access). Target devices can be IP phones or

other VoIP handsets, home gateways, media gateways, IP Private Branch

Exchange (IPBX), trunking equipment, voice messaging servers, etc.

For all those applications, the scalability feature allows tuning the

bit rate versus quality trade-off, possibly in a dynamic way during a

session, taking into account service requirements and network

transport constraints.

The G.729.1 coder produces an embedded bitstream structured in 12

layers corresponding to 12 available bit rates between 8 and 32 kbps.

The first layer, at 8 kbps, is called the core layer and is bitstream

compatible with the ITU-T G.729/G.729A coder. At 12 kbps, a second

layer improves the narrowband quality. Upper layers provide wideband

audio (50-7000 Hz) between 14 and 32 kbps, with a 2 kbps granularity

allowing graceful quality improvements. Only the core layer is

mandatory to decode understandable speech; upper layers provide

quality enhancement and wideband enlargement.

Sollaud Standards Track [Page 2]

RFC 4749 RTP Payload Format for G.729.1 October 2006

The codec operates on 20-ms frames, and the default sampling rate is

16 kHz. Input and output at 8 kHz are also supported, at all bit

rates.

3. Embedded Bit Rates Considerations

The embedded property of G.729.1 streams provides a mechanism to

adjust the bandwidth demand. At any time, a sender can change its

sending bit rate without external signalling, and the receiver will

be able to properly decode the frames. It may help to control

congestion, since the bandwidth can be adjusted by selecting another

bit rate.

The ability to adjust the bandwidth may also help when having a fixed

bandwidth link dedicated to voice calls, for example in a residential

or trunking gateway. In that case, the system can change the bit

rates depending on the number of simultaneous calls. This will only

impact the sending bandwidth. In order to adjust the receiving

bandwidth as well, we introduce an in-band signalling to request the

other party to change its own sending bit rate. This in-band request

is called MBS, for Maximum Bit rate Supported. It is described in

Section 5.2. Note that it is only useful for two-way unicast G.729.1

traffic, because when A sends an in-band MBS to B in order to request

that B modify its sending bit rate, it concerns the stream from B to

A. If there is no G.729.1 stream in the reverse direction, the MBS

will have no effect.

4. RTP Header Usage

The format of the RTP header is specified in RFC 3550 [3]. This

payload format uses the fields of the header in a manner consistent

with that specification.

The RTP timestamp clock frequency is the same as the default sampling

frequency: 16 kHz.

G.729.1 has also the capability to operate with 8 kHz sampled input/

output signals at all bit rates. It does not affect the bitstream,

and the decoder does not require a priori knowledge about the

sampling rate of the original signal at the input of the encoder.

Therefore, depending on the implementation and the audio acoustic

capabilities of the devices, the input of the encoder and/or the

output of the decoder can be configured at 8 kHz; however, a 16 kHz

RTP clock rate MUST always be used.

The duration of one frame is 20 ms, corresponding to 320 samples at

16 kHz. Thus the timestamp is increased by 320 for each consecutive

frame.

Sollaud Standards Track [Page 3]

剩余13页未读，继续阅读

评论收藏

内容反馈

毕加索解锁

粉丝: 2696
资源: 24

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

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

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

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

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

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

RFC-7798 RTP Payload Format for High Efficiency Video Coding

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

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

RFC 3984 - RTP Payload Format for H_264 Video

RFC3984 RTP Payload Format for H264 Video

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

RTP中文版 by 51TalkAM.pdf

Python库 | sf-rfc-validate-0.0.8.tar.gz

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

RFC-3550 RTP中英文版

配套资料－FTP协议的RFC－rfc0959.txt

Python库 | rfc5424-logging-handler-1.4.0.tar.gz

Python库 | rfc5424-logging-handler-1.4.3.tar.gz

微软HEVC视频扩展插件（免费）

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

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

VP9视频扩展 Microsoft.VP9VideoExtensions-1.0.52781.0-x64

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

喜马拉雅xm文件解密工具

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

机器学习音频训练文件-24年抖音金曲

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

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

最新资源

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