分享
 
 
 

RFC4102 - Registration of the text/red MIME Sub-Type

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group P. Jones

Request for Comments: 4102 Cisco Systems, Inc.

Category: Standards Track June 2005

Registration of the text/red MIME Sub-Type

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.

Copyright Notice

Copyright (C) The Internet Society (2005).

Abstract

This document defines the text/red MIME sub-type. "Red" is short for

redundant. The actual RTP packetization for this MIME type is

specified in RFC 2198.

1. IntrodUCtion

Text is an important component of any multimedia communication

system. Like audio, the transport of text can benefit from the use

of redundancy in order to improve reliability and end-user

eXPerience.

RFC 2198 [1] defines an RTP [2] payload format for redundant audio

data. The format defined in that document is quite suitable for

providing redundancy for text, as well as audio.

RFC 4103 [8] specifies one usage of RFC 2198 and the text/red MIME

type for the transport of redundant text data.

This memo provides the MIME sub-type registration information for

text/red. While this document focuses on the use of this MIME sub-

type in SDP [5], the application of this MIME sub-type is not

restricted to SDP.

2. Conventions Used in This Document

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 [3].

3. IANA Considerations

One new MIME sub-type has been registered by the IANA, as described

below:

MIME media type name: text

MIME suBType name: RED

Required parameters:

rate: the RTP clock rate of the payload carried within the RTP

packet. Typically, this rate is 1000, but other rates MAY be

specified. This parameter MUST be set equal to the clock rate of

the text payload format carried as the primary encoding.

pt: a comma-separated ordered list of RTP payload types

enumerating the primary, secondary, etc., in accordance with RFC

2198. Because comma is a special character, the list MUST be a

quoted-string (enclosed in double quotes). For static payload

types, each list element is simply the type number. For dynamic

payload types, each list element is a mapping of the dynamic

payload type number to an embedded MIME content-type specification

for the payload format corresponding to the dynamic payload type.

The format of the mapping is:

dynamic-payload-type "=" content-type

If the content-type string includes a comma, then the content-

type string MUST be a quoted-string. If the content-type string

does not include a comma, it MAY still be quoted. Because it is

part of the list, which must itself be a quoted-string, the

quotation marks MUST be quoted with backslash quoting as specified

in RFC 2045 [4]. If the content-type string itself contains a

quoted-string, then the requirement for backslash quoting is

recursively applied.

Optional parameters: ptime, maxptime (these attributes are originally

defined in RFC 2327 [5] and RFC 3267 [6], respectively)

Restrictions on Usage:

This type is defined only for transfer via RTP.

It shall not be defined for a storage format.

Encoding considerations:

See restrictions on Usage above; this section is included per

the requirements in RFC 3555 [7].

Security considerations: Refer to section 5 of RFC 4102.

Interoperability considerations: none

Published specification: RFC 2198

Applications which use this media type:

Text streaming and conferencing tools.

Additional information: none

Person & email address to contact for further information:

Paul E. Jones

E-mail: paulej@packetizer.com

Intended usage: COMMON

Author:

Paul E. Jones

paulej@packetizer.com

Change Controller:

AVT Working Group delegated from the IESG

4. Mapping to SDP Parameters

The information carried in the MIME media type specification has a

specific mapping to fields in the Session Description Protocol (SDP)

[5], which is commonly used to describe RTP sessions. When SDP is

used to specify sessions employing the RFC 2198 in a text session,

the mapping is as follows:

- The MIME type ("text") goes in SDP "m=" as the media name.

- The value of the parameter "rate" goes in SDP "a=rtpmap".

- The MIME subtype (RED) goes in SDP "a=rtpmap" as the encoding

name.

- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and

"a=maxptime" attributes, respectively.

- The pt parameter is mapped to an a=fmtp attribute by eliminating

the parameter name (pt) and changing the commas to slashes. For

example, 'pt="101,102"' maps to 'a=fmtp:99 101/102', where = '99'

is the payload type of the redundancy frames. Note that the

single quote marks (') used in this example are not present in the

actual message encoding, but are present here only for

readability. The level of redundancy is shown by the number of

elements in the payload type list.

Any dynamic payload type in the list MUST be represented by its

payload type number and not by its content-type. The mapping of

payload types to the content-type is done using the normal SDP

procedures with "a=rtpmap".

An example of SDP is:

m=text 11000 RTP/AVP 98 100

a=rtpmap:98 t140/1000

a=rtpmap:100 red/1000

a=fmtp:100 98/98

For each redundancy payload type defined, the ordering of the primary

and redundancy encoding(s) is fixed. If more than one combination of

primary and redundancy encoding(s) is desired, multiple redundancy

payload types needs to be defined.

5. Security Considerations

The security considerations listed in RFC 2198 apply. Further, it

should be understood that text data, perhaps even more so than audio

data, is susceptible to unwanted modification that may lead to

undesired results. To prevent modification of the primary,

secondary, or header information, payload integrity protection over

at least the complete RTP packet is RECOMMENDED, for example using

SRTP [9].

6. Normative References

[1] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,

Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload

for Redundant Audio Data", RFC 2198, September 1997.

[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,

"RTP: A Transport Protocol for Real-Time Applications", STD 64,

RFC 3550, July 2003.

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", BCP 14, RFC 2119, March 1997.

[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

Extensions (MIME) Part One: Format of Internet Message Bodies",

RFC 2045, November 1996.

[5] Handley, M., Jackson, V., "SDP: Session Description Protocol",

RFC 2327, April 1998.

[6] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-

Time Transport Protocol (RTP) Payload Format and File Storage

Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate

Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.

[7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload

Formats", RFC 3555, July 2003.

7. Informative References

[8] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",

RFC 4103, June 2005.

[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.

Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC

3711, March 2004.

Author's Address

Paul E. Jones

Cisco Systems, Inc.

7025 Kit Creek Rd.

Research Triangle Park, NC 27709, USA

Phone: +1 919 392 6948

EMail: paulej@packetizer.com

Full Copyright Statement

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions

contained in BCP 78, and except as set forth therein, the authors

retain all their rights.

This document and the information contained herein are provided on an

"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET

ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any

Intellectual Property Rights or other rights that might be claimed to

pertain to the implementation or use of the technology described in

this document or the extent to which any license under such rights

might or might not be available; nor does it represent that it has

made any independent effort to identify any such rights. Information

on the procedures with respect to rights in RFC documents can be

found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any

assurances of licenses to be made available, or the result of an

attempt made to obtain a general license or permission for the use of

such proprietary rights by implementers or users of this

specification can be obtained from the IETF on-line IPR repository at

http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any

copyrights, patents or patent applications, or other proprietary

rights that may cover technology that may be required to implement

this standard. Please address the information to the IETF at ietf-

ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有