用于文本交谈的RTP负载

【用于文本交谈的RTP负载】本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议 , 它需要进一步进行讨论和建
议以得到改进 。请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化
程度和状态 。本备忘录的发布不受任何限制 。
版权声明
Copyright(C)TheInternetSociety(2001).
摘要
本文描述了在RTP包中传输文本交谈内容的方法 , 关于文本交谈会话内容在ITU-T建议
(T.140[1])中有具体说明 。
文本交谈可以用来单独传输或与音视频等交谈工具一起构成多媒体交谈服务 。
本RTP负载包含可选的已传输数据包的冗余文本来降低包丢失的风险 。冗余码参照RFC
2198 。
目录
1.简介 2
1.1术语 3
2.RTP用法 3
2.1RTP包头 3
2.2附加头 4
2.3T.140文本结构 4
3.推荐过程 4
3.1基本推荐过程 5
3.2补偿丢包的推荐过程 5
3.3补偿乱序包的推荐过程 5
3.4使用冗余时的“静音期”传输 5
4.范例 6
5.安全性考虑 7
6.MIMEMEDIATYPEREGISTRATIONS 7
6.1RegistrationofMIMEmediatypetext/t140 7
鸣谢 8
作者地址 8
参考 8
版权说明 9
致谢 9
1.简介
本文定义了一种用于在RTP包中传输文本交谈会话内容的负载格式 , 文本交谈会话内容
在ITU-T建议(T.140[1])中有具体说明 。文本交谈可单独传输或与音视频等交谈工具共同
构成多媒体交谈服务 。文本交谈中的文本应尽快传输 , 或者经过一个小的缓冲延迟 。
文本的输入通常是以键盘、手写识别、语音识别或是其它输入方法 。字符的输入率通常
为每秒几个字符 。这样 , 期望的字符传输率也较低 。通常每个包中只有很少的新字符需要传
输 。
在T.140中指定文本和其它T.140元素必须以经过UTF-8变换的ISO10646-1码来传送 。
这些有助于实现国际化应用 , 并且易于处理现代信息技术环境中的文本 。本文RTP负载中
的文本编码严格遵守T.140 , 没有任何附加帧 。通常是UTF-8编码的ISO10646单字符 。
T.140要求字符按照原始顺序 , 没有重复的传输 。文本交谈的使用者希望文本传输没有
或尽可能少丢失 。当然 , 假如能标识出丢失的信息 , 则丢失的可接受程度会高些 。
因此 , 这里介绍了一个基于RTP的机制 。它将按照原始顺序 , 无重复传输 , 并且提供
丢失检测和指示 。它同时也提供一个可选方案 , 利用重复的冗余数据来降低丢失文本风险 。
考虑到包开销通常远远大于T.140内容 , 传输通道中增加冗余数据造成的负担很小 。
1.1术语
本文中的要害字“必须” , “必须不” , “要求的” , “应该” , “不应该” , “会” , “不会” ,
“建议” , “或许” , “可选的”在RFC2119[4]中解释 。
2.RTP用法
当RTP传输中需要传输T.140文本交谈 , 应该使用本文所述的负载 。
这种负载格式的文本交谈RTP包的格式包括:一个RTP头(在RFC1889[2]中有定义) ,
其后紧接着是一个T.140数据块(这里被定义为“T140block”) 。该负载格式没有附加头 。
T140块包括[1]中定义的一个或多个T.140码元素 。大部分T.140码元素为ISO10645[5]单
字符 , 但是也有一些是多字符序列 。其中每个字符均为UTF-8编码[6]的一个或多个字节 。
这说明不管单个字符中有几个字节 , 每一块必须包含UTF-8码的整数倍 。这也说明任何组
合的字符序列(CCS)应该被放到同一块中 。
T140块可能会根据RFC2198[3]所定义的负载格式传输冗余数据 。这样 , RTP头后将

推荐阅读