RFC 2793

RTP Payload for Text Conversation

📅 published May 2000, from ietf

RFC 2793: RTP Payload for Text Conversation 🎀

Part 1 of 2 💖 Okay bestie, the title block first. This is RFC 2793, RTP Payload for Text Conversation, written by G. Hellstrom from Omnitor AB. It's a Standards Track doc, dated May 2000. The header doesn't list anything it obsoletes or updates, so there's nothing to chase there 💅.

Status of this Memo ✨

Okay so this document specifies an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions 🗣️. If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📋. Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

Abstract 🦋

This memo explains how to carry text conversation session contents inside RTP packets 📦. The session contents themselves are specified in ITU-T Recommendation T.140 [1] 🎀.

Text conversation can run by itself, or alongside other conversational stuff like video and voice, which is how you get full multimedia conversation services 🎥🎙️. It's giving teamwork ✨.

This RTP payload description has an optional extra: you can include redundant text from packets that were already sent 🔁. The goal is to lower the risk of losing text when packets get lost 🫶. The redundancy coding follows RFC 2198 🧚.

1. Introduction ✨

This memo defines a payload type for carrying text conversation session contents in RTP packets 💌. Those session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation can be used alone or with other conversational facilities such as video and voice, so you get multimedia conversation services 🌸. Text in a session gets sent as soon as it's available, or after a small delay for buffering ⏱️.

The text is supposed to come from human users typing on a keyboard, handwriting recognition, voice recognition, or any other input method ⌨️. People usually enter characters at a rate of a few per second or slower 🐢. So the number of characters to send is pretty low, and only one or a few new characters are expected in each packet 🍓.

T.140 says that text and other T.140 elements MUST be transmitted in ISO 10 646-1 code with UTF-8 transformation 🌍. That's what makes it easy to build apps that work internationally and to handle text in modern information technology environments 💅. The payload of an RTP packet following this spec is just text encoded according to T.140, with no extra framing at all ✨. The most common case is a single ISO 10646 character, UTF-8 encoded 🔥.

T.140 needs the transport channel to deliver characters without duplicates and in their original order 🧠. Text conversation users expect text to arrive with no lost information, or at least a low level of it 😭. If lost information can be indicated, people are usually more willing to accept some loss 🙈.

So this memo specifies a mechanism based on RTP 🚀. It makes sure text arrives in the correct order, with no duplicates, and it detects and indicates losses 👑. It also has an optional way to repeat data for redundancy, to lower the risk of loss 🛡️. Packet overhead is usually way bigger than the T.140 content, so the extra channel load from the redundancy scheme is minimal 💜.

1.1 Terminology

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 [4] 📖.

2. Usage of RTP 🎀

When you want to transport T.140 text session data in RTP, the payload as described in this specification SHOULD be used 🌷.

A text conversation RTP packet under this payload format is an RTP header (defined in RFC 1889 [2]), immediately followed by a block of T.140 data. That block is called a "T140block" 🧁. There's no extra header specific to this payload format 🙅‍♀️. The T140block holds one or more T.140 code elements (see [1]) 💎. Most of those are single ISO 10646 [5] characters, but some are multiple character sequences 🧩. Each character is UTF-8 encoded [6] into one or more octets 🔢. This means each block MUST contain a whole number of UTF-8 encoded characters, no matter how many octets each character takes 🙌. It also means any composite character sequence (CCS) SHOULD be kept inside one block 🫧.

The T140blocks MAY be sent redundantly, following the payload format in RFC 2198 [3] 🔁. When they are, the RTP header is followed by one or more redundant data block headers, then the same number of redundant data fields carrying T140blocks from earlier packets, and finally the new (primary) T140block for this packet 🎁.

2.1 RTP packet header

Every RTP packet starts with a fixed RTP header 🧾. These are the fixed header fields used for T.140 text streams:

  • Payload Type (PT): The RTP payload type assignment depends on the RTP profile this payload format is used under 🎟️. For profiles that assign payload type numbers dynamically, this format is identified by the name T140 (see section 6) 🏷️. If redundancy is used per RFC 2198, the Payload Type MUST indicate that payload format (RED) 🔴.
  • Sequence number: The Sequence Number MUST go up by one for each new packet that gets sent 🔢. It's used to detect lost and out-of-order packets, and it can help with fetching redundant text, reordering text, and marking missing text 🧭.
  • Timestamp: The RTP Timestamp gives the approximate moment the primary text in the packet was entered ⏰. A clock frequency of 1000 Hz MUST be used 🕐. Packets that come one after another MUST NOT share the same timestamp 🙅‍♀️. Packets don't represent any constant duration, so you can't directly infer packet losses from the timestamp 🤷‍♀️.

2.2 Additional headers

There are no extra headers defined specifically for this payload format 🌙.

When you want redundant transmission of data under RFC 2198, the RTP header is followed by one or more redundant data block headers, one for each redundant data block you want to include 🧃. Each of those headers gives the timestamp offset and length of its data block, plus a payload type number that says this payload format is in use (T140) 🎀.

2.3 T.140 Text structure

T.140 text is UTF-8 coded as specified in T.140, with no extra framing 📝. When you use the format with redundant data, the transmitter MAY pick a number of T140block generations to resend in each packet 🔁. A higher number gives better protection against loss of text, but it also raises the data rate 📈.

Packets aren't generated at regular intervals, so the timestamp alone isn't enough to identify a packet when there's loss, unless extra info is provided 😵‍💫. Since sequence numbers aren't provided in the redundant header, some extra rules have to be followed so the redundant data for missing primary data merges properly into the stream of primary data T140blocks 🧩:

  • Each redundant data block MUST contain the same data as a T140block that was previously sent as primary data, and it MUST be identified with a timestamp offset equal to the original timestamp for that T140block 🪞.
  • The redundant data MUST be placed in age order, with the most recent redundant T140block last in the redundancy area 📚.
  • All T140blocks from the oldest desired generation up through the generation right before the new (primary) T140block MUST be included 🧱.

These rules let you work out the sequence numbers for the redundant T140blocks by counting backwards from the sequence number in the RTP header 🔙. The result is that all the text in the payload is contiguous and in order 💯.

This section has RECOMMENDED procedures for using the payload format 💫. Based on the info in the received packets, the receiver can:

  • reorder text that came in out of order 🔀.
  • mark where text is missing because of packet loss 🕳️.
  • make up for lost packets by using redundant data 🦸‍♀️.

Packets are only sent when there's valid T.140 data to send 🚦. The sequence number is what sequences the T.140 data 🔢.

When a packet comes in, the RTP sequence number gets compared with the sequence number of the last correctly received packet 👀. If they're consecutive, the (only or primary) T140block is pulled out of that packet 🎁.

To cut down on data loss when packets are lost, redundant data MAY be included in the packets that follow, using the procedures in RFC 2198 🛟. If network conditions aren't known, it is RECOMMENDED to use one redundant T140block in each packet 🌤️. If there's a gap in the RTP sequence numbers, and redundant T140blocks are available in a later packet, the sequence numbers for those redundant T140blocks should be inferred by counting backwards from the sequence number in that packet's RTP header 🔍. If the redundant T140blocks have sequence numbers that match the missing ones, the redundant T140blocks may be swapped in for the missing T140blocks 🔄.

Whether or not redundancy is used, missing data SHOULD be marked by inserting a missing text marker into the received stream for each missing T140block, as specified in ITU-T T.140. Addendum 1 [1] 🚩.

To protect against packets arriving out of order, the following procedure MAY be implemented in the receiver 🧳. If a received packet reveals a gap in the sequence and there's no redundant data to fill it, the received packet can be held in a buffer, giving the missing packet(s) time to show up 🪣. It is suggested that the waiting time be limited to 0.5 seconds ⏳. When redundancy is used, the waiting time SHOULD be extended to the number of redundancy generations times the T.140 buffering timer, if that product is known to be greater than 0.5 seconds 🕰️.

If a packet with a T140block belonging to the gap arrives before the waiting time runs out, that T140block is put into the gap, and then consecutive T140blocks from the leading edge of the gap may be consumed 🧩. Any T140block that doesn't arrive before the time limit runs out should be treated as lost 💀.

3.4 Transmission during "silent periods" when redundancy is used.

When you're using the redundancy transmission scheme and there's nothing more to send from T.140, the latest T140block can get old before it's sent as redundant data 😬. The result is less useful protection against packet loss at the end of a text input sequence 🥀. For cases where that should be avoided, a zero-length primary T140block MAY be sent along with the redundant data 🫧.

Any zero-length T140blocks sent as primary data MUST be included as redundant T140blocks in later packets, just like normal text T140blocks, so that the sequence number inference for the redundant T140blocks stays correct, as explained in section 2.3 🧮.

Redundancy for the last T140block SHOULD NOT be done by repeatedly sending the same packet (with the same sequence number). Doing that causes the packet loss count, as reported in RTCP, to decrement 🚫.

4. Examples ✨

Okay bestie, time for the fun part 🎀 Here's a T140 RTP packet with no redundancy, so it's just one copy of the text:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |V=2|P|X| CC=0  |M|   T140 PT   |       sequence number         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      timestamp (1000Hz)                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           synchronization source (SSRC) identifier            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  +                      T.140 encoded data                       +
  |                                                               |
  +                                               +---------------+
  |                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And now the one with redundancy 🦋 This packet carries one redundant T140block alongside the primary one:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |V=2|P|X| CC=0  |M|  "RED" PT   |   sequence number of primary  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              timestamp  of primary encoding "P"               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           synchronization source (SSRC) identifier            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1|   T140 PT   |  timestamp offset of "R"  | "R" block length  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|   T140 PT   |                                               |
  +-+-+-+-+-+-+-+-+                                               +
  |                                                               |
  +               "R" T.140 encoded redundant data                +
  |                                                               |
  +                                               +---------------+
  |                                               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
  |                "P" T.140 encoded primary data                 |
  +                                                               +
  +                                               +---------------+
  |                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure: Examples of RTP text packets.

5. Security Considerations 🔐

Okay, this one is serious, so I'm keeping it real 💀 Text conversations carry what people actually type to each other, so security matters here. The amount of data in a text conversation session is low, so any encryption method MAY be selected and applied to the T.140 session contents or to the whole RTP packets. When redundant data is included, the same security considerations as for RFC 2198 apply. Protect your chats, bestie 🫶

6. MIME Media Type Registrations 🎀

This document defines a new RTP payload name and associated MIME type, T140 (text/t140). Cute, right? 💜

6.1. Registration of MIME media type text/t140

Here's the official registration template, copied exactly because the details matter:

   MIME media type name: text

   MIME subtype name: t140

   Required parameters: None

   Optional parameters: None

   Encoding considerations: T140 text can be transmitted with RTP as
   specified in RFC 2793.

   Security considerations: None

   Interoperability considerations: None

   Published specification: ITU-T T.140 Recommendation.
                            RFC 2793.

   Applications which use this media type:
     Text communication terminals and text conferencing tools.

   Additional information: None

     Magic number(s): None
     File extension(s): None
     Macintosh File Type Code(s): None

   Person & email address to contact for further information:
     Gunnar Hellstrom
     e-mail: gunnar.hellstrom@omnitor.se

   Intended usage: COMMON
     Author                      / Change controller:
     Gunnar Hellstrom            | IETF avt WG
     gunnar.hellstrom@omnitor.se | c/o Steve Casner casner@cisco.com

7. Author's Address 💌

Meet the author, Gunnar Hellstrom ✨ Here's how to reach him:

   Gunnar Hellstrom
   Omnitor AB
   Alsnogatan 7, 4 tr
   SE-116 41 Stockholm
   Sweden

   Phone: +46 708 204 288 / +46 8 556 002 03
   Fax:   +46 8 556 002 06
   EMail: gunnar.hellstrom@omnitor.se

8. Acknowledgements 🫶

The author gave a big shoutout to Stephen Casner and Colin Perkins for valuable support, with reviews and advice on creating this document. Thanks also to Mickey Nasiri at Ericsson Mobile Communication for providing the development environment, and to Michele Mizarro for verifying that the payload format is usable for its intended purpose. The squad goals 👑

9. References 📚

  • [1] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application, with amendment 1, (2000).
  • [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
  • [3] Perkins, C., Kouvelas, I., Hardman, V., Handley, M. and J. Bolot, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
  • [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [5] ISO/IEC 10646-1: (1993), Universal Multiple Octet Coded Character Set.
  • [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Here's the legal vibe, and I'm keeping every bit of it 💅 This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are: needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 💖

📦 where this page comes from