RFC 4103
RTP Payload for Text Conversation
RFC 4103 is here and it's giving real-time text realness 💖
- Title: RTP Payload for Text Conversation
- Network Working Group: not listed in the header
- Authors: G. Hellstrom (Omnitor AB) and P. Jones (Cisco Systems, Inc.)
- Category: Standards Track
- Date: June 2005
- Obsoletes: RFC 2793
- Updates: no Updates field in this title block
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 🦋
okay so this memo obsoletes RFC 2793, and it's all about how to carry real-time text conversation session contents inside RTP packets 💬 The text conversation contents themselves are specced in ITU-T Recommendation T.140.
One payload format is described here, for sending text over a separate RTP session that's dedicated to text only. 🎀
This RTP payload description also suggests a method for including redundant text from packets that were already sent, which helps lower the risk of losing text when packets get lost 🫶
Table of Contents 📋
1. Introduction ...................................................3
2. Conventions Used in This Document ..............................4
3. Usage of RTP ...................................................4
3.1. Motivations and Rationale .................................4
3.2. Payload Format for Transmission of text/t140 Data .........4
3.3. The "T140block" ...........................................5
3.4. Synchronization of Text with Other Media ..................5
3.5. RTP Packet Header .........................................5
4. Protection against Loss of Data ................................6
4.1. Payload Format When Using Redundancy ......................6
4.2. Using Redundancy with the text/t140 Format ................7
5. Recommended Procedure ..........................................8
5.1. Recommended Basic Procedure ...............................8
5.2. Transmission before and after "Idle Periods" ..............8
5.3. Detection of Lost Text Packets ............................9
5.4. Compensation for Packets Out of Order ....................10
6. Parameter for Character Transmission Rate .....................10
7. Examples ......................................................11
7.1. RTP Packetization Examples for the text/t140 Format ......11
7.2. SDP Examples .............................................13
8. Security Considerations .......................................14
8.1. Confidentiality ..........................................14
8.2. Integrity ................................................14
8.3. Source Authentication ....................................14
9. Congestion Considerations .....................................14
10. IANA Considerations ...........................................16
10.1. Registration of MIME Media Type text/t140 ...............16
10.2. SDP Mapping of MIME Parameters ..........................17
10.3. Offer/Answer Consideration ..............................17
11. Acknowledgements ..............................................18
12. Normative References ..........................................18
13. Informative References ........................................191. Introduction 🌸
This doc defines a payload type for carrying text conversation session contents inside RTP [2] packets. The text conversation contents are specced in ITU-T Recommendation T.140 [1]. Text chat can be used all by itself or alongside other stuff like video and voice to make full multimedia conversation services. In these sessions, text gets sent character-by-character as soon as it's available, or after a small delay for buffering ⏱️
The text is meant to be typed in by humans from a keyboard, handwriting recognition, voice recognition, or any other input method. The rate of character entry is usually a few characters per second or less, so in general only one or a few new characters get sent with each packet ⌨️ Sometimes a person pastes in a little block of text they prepared, and then a packet can end up carrying more payload, which is a whole vibe 💅
T.140 specifies that text and other T.140 elements must be transmitted in ISO 10646-1 [5] code with UTF-8 [6] transformation. This makes it super easy to build internationally useful apps and handle text in modern IT environments 🌍 The payload of an RTP packet that follows this spec is just text encoded according to T.140, with no extra framing. The most common case is a single ISO 10646 character, UTF-8 encoded 🍓
T.140 requires the transport channel to deliver characters without duplication and in their original order. Text conversation users expect their text to arrive with no lost information, or at least a low level of it 🥺
So a mechanism based on RTP is specified here ✨ It gives text arrival in correct order, without duplication, and with detection and indication of loss. It also includes an optional way to repeat data for redundancy, to lower the risk of loss. Packet overhead is usually way bigger than the T.140 contents, so the bandwidth increase from redundancy is minimal, which is honestly iconic 👑
By using RTP for text transmission in a multimedia conversation app, text and other media can be handled in a uniform way in things like conferencing systems, firewalls, and network translation devices. That eases the design and makes prompt, proper media delivery more likely 🧚
This document obsoletes RFC 2793 [16]. It clarifies ambiguities in RFC 2793, improves on the implementation requirements people learned from building it, and gives explicit usage examples. Main character energy 🎀
2. Conventions Used in This Document 💜
Quick house rule: 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]. 📏
3. Usage of RTP 🦋
The payload format for real-time text transmission with RTP [2] described in this memo is meant for general text conversation use, and it's called text/t140 after its MIME registration 💬
3.1. Motivations and Rationale 🌷
The text/t140 format is meant to be used for text sent on a separate RTP session that's dedicated to text and not shared with other media 📝
The text/t140 format MAY be used for any non-gateway application, as well as in gateways. It MAY be used at the same time as other media streams, sent as a separate RTP session, as required in real-time multimedia apps 🎬
The text/t140 format in this memo is compatible with its earlier definition in RFC 2793. It's been refined, mainly to minimize interoperability problems and encourage good reliability and functionality 🫶
By treating text transmission as its own text medium, a bunch of good effects happen. Routing, device selection, invoking transcoding, picking quality of service parameters, and other high and low level functions all depend on each medium being explicitly specified 🧠
3.2. Payload Format for Transmission of text/t140 Data 📦
A text/t140 conversation RTP payload format consists of one, and only one, block of T.140 data, called a "T140block" (see Section 3.3). There are no additional headers specific to this payload format. The fields in the RTP header are set as defined in Section 3.5 and carried in network byte order (see RFC 791 [12]) 🔢
3.3. The "T140block" 🧱
T.140 text is UTF-8 coded, as specified in T.140, with no extra framing. The T140block contains one or more T.140 code elements as specified in [1]. Most T.140 code elements are single ISO 10646 [5] characters, but some are multiple character sequences. Each character is UTF-8 encoded [6] into one or more octets.
Each block MUST contain an integral number of UTF-8 encoded characters, no matter how many octets each character takes up 🙅♀️ Any composite character sequence (CCS) SHOULD be placed within one block 🎀
3.4. Synchronization of Text with Other Media 🎶
Usually, each medium in a session uses its own RTP stream. So if syncing the text with other media packets is important, the streams MUST be associated when the sessions are set up, and the streams MUST share the same reference clock. (Check out the description of the timestamp field as it relates to synchronization in Section 5.1 of RFC 3550 [2], it's the tea ☕) Association of RTP streams can be done through the CNAME field of the RTCP SDES function. That part depends on the particular application and is outside the scope of this document 💅
3.5. RTP Packet Header 📡
Each RTP packet starts with a fixed RTP header. These are the fields of the RTP fixed header that are specified for T.140 text streams:
Payload Type (PT): The assignment of an RTP payload type is specific to the RTP profile the payload format is used under. For profiles that use dynamic payload type number assignment, this payload format can be identified by the MIME type "text/t140" (see Section 10). If redundancy is used per RFC 2198, another payload type number needs to be provided for the redundancy format. The MIME type for identifying RFC 2198 is available in RFC 4102 [9] 🪪Sequence number: The definition of sequence numbers is available in RFC 3550 [2]. When transmitting text with the payload format fortext/t140, it's used for detecting packet loss and out-of-order packets, and it can help with retrieving redundant text, reordering text, and marking missing text 🔁Timestamp: The RTP Timestamp encodes the approximate moment the primary text in the packet was entered. A clock frequency of 1000 Hz MUST be used. Sequential packets MUST NOT use the same timestamp. Packets don't represent any constant duration, so the timestamp can't be used to directly infer packet loss ⏰M-bit: The M-bit MUST be included. The first packet in a session, and the first packet after an idle period, SHOULD be marked by setting the marker bit in the RTP data header to one. The marker bit in all other packets MUST be set to zero. The reception of the marker bit MAY be used for refined methods of detecting loss 🚩
4. Protection against Loss of Data ✨
okay bestie, keeping text loss from packet loss under control is a whole priority 🫶 Check ITU-T F.703 [17] for the details.
The default method that MUST be used when no other method is explicitly selected is redundancy, following RFC 2198 [3]. 💖 When this method is used, the original text and two redundant generations SHOULD be transmitted, unless the application or end-to-end conditions call for other levels of redundancy.
Forward Error Correction, as described in RFC 2733 [8], or any other mechanism that boosts reliability for text, MAY be used instead of redundancy or alongside it 🦋 Text data MAY also be sent with no extra protection, as long as end-to-end network conditions keep the text quality requirements from ITU-T F.703 [17] met under every load you can anticipate 🌸
4.1. Payload Format When Using Redundancy
When you're using the payload format with redundant data, the transmitter may pick a number of T140block generations to resend in each packet. More generations means better protection against text loss, but the data rate goes up a little bit 🧚
The RTP header comes first, followed by one or more redundant data block headers, one for each redundant data block you're including. Each of these headers gives the timestamp offset and length of its data block, plus a payload type number that says it's text/t140 🎀
After those headers come the redundant data fields, which carry T140blocks from earlier packets. The new (primary) T140block for this packet goes last 💅
Redundant data that would need a timestamp offset higher than 16383 (because it's too old by the time it's sent) MUST NOT be included in transmitted packets. Not me sending ancient text 💀
4.2. Using Redundancy with the text/t140 Format
Text only gets sent when there's text to send, so the timestamp can't be used to spot a lost packet 😭 Instead, the receiver looks at missing sequence numbers to find lost text packets. Sequence numbers don't show up in the redundant header, though, so there are some extra rules so redundant data for missing primary data can merge into the primary T140block stream properly. Here they are:
- Each redundant data block MUST contain the same data as a T140block previously transmitted as primary data.
- 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 immediately preceding 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 stays contiguous and in order, which is so satisfying 🔥
If there's a gap in the received RTP sequence numbers and redundant T140blocks show up 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 any redundant T140blocks have sequence numbers that match the missing ones, those redundant T140blocks may be swapped in for the missing T140blocks 🫶
5. Recommended Procedure
This section has RECOMMENDED procedures for using the payload format 🌈 Based on what's in the packets it receives, the receiver can:
- reorder text that arrived out of order.
- mark where text is missing because of packet loss.
- compensate for lost packets by using redundant data.
5.1. Recommended Basic Procedure
Packets get sent whenever there's valid T.140 data to transmit 🍓
T.140 says T.140 data MAY be buffered for transmission with a maximum buffering time of 500 ms. A buffering time of 300 ms is RECOMMENDED when the application or end-to-end network conditions aren't known to need a different value ✨
If no new data shows up for longer than the buffering time, the transmission process is in an idle period 😴
When new text shows up after an idle period, it is RECOMMENDED to send it as soon as possible. After that, it is RECOMMENDED to buffer T.140 data in buffering time intervals until the next idle period. This keeps the maximum bit rate for text at a reasonable level 💜 The buffering time MUST be selected so that text users will perceive a real-time text flow, because real-time vibes are the whole point 💖
5.2. Transmission before and after "Idle Periods"
When valid T.140 data has been sent and no new T.140 data is available after the selected buffering time, an empty T140block SHOULD be transmitted. This marks the start of an idle period 🦋 The procedure is recommended so potentially missing text can be detected more quickly before an idle period.
An empty T140block contains no data 🫧
When redundancy is used, transmission keeps going with a packet at every transmission timer expiration, with an empty T.140block inserted as primary, until the last non-empty T140block has been sent as both primary and redundant data, with all the intended generations of redundancy. The last packet before an idle period contains only one non-empty T140block as redundant data, and the rest of that redundancy packet holds empty T140blocks 🎀
Any empty T140block sent as primary data MUST be included as redundant T140blocks in subsequent packets, just like normal text T140blocks, unless the empty T140block is too old to be transmitted. This keeps sequence number inference for the redundant T140blocks correct, as explained in Section 4.2 🧚
After an idle period, the transmitter SHOULD set the M-bit to one in the first packet with new text 🌸
5.3. Detection of Lost Text Packets
Packet loss for text/t140 packets MAY be detected by spotting gaps in the sequence numbers of the RTP packets the receiver gets 👀
With text/t140, loss is usually caught by comparing the sequence of RTP packets as they arrive. Any discrepancy MAY be used to indicate loss. The highest RTP sequence number received can also be compared with the one in RTCP reports, as an extra check for loss of the last packet before an idle period 🔥
Missing data SHOULD be marked by inserting a missing text marker in the received stream for each missing T140block, as specified in ITU-T T.140 Addendum 1 [1] ✨
Empty T140blocks get sent at the beginning of an idle period, so there's a slight risk of falsely marking text as lost when only an empty T140block was lost 😭 Procedures based on detecting the packet with the M-bit set to one MAY be used to reduce the risk of false loss markers.
If redundancy is used with the text/t140 format and a packet arrives with fewer redundancy levels than normal for the session, it SHOULD be treated as if one empty T140block was received for each excluded level in that packet. This is because the only time a T140block gets left out of transmission is when it's an empty T140block that has become too old to send 💅
If two successive packets have the same number of redundant generations, that number SHOULD be treated as the general redundancy level for the session. A change to the general redundancy level SHOULD only happen after an idle period 🌈
The text/t140 format relies on the sequence number in the RTP packet header to detect loss, so it isn't suitable for applications that need to alternate it with other payloads in the same RTP stream. Trying to detect data loss at the edges of the shifts between t140 text and other stream contents would be complicated and unreliable 🙈 That's why text/t140 is RECOMMENDED to be the only payload type in the RTP stream.
5.4. Compensation for Packets Out of Order
To protect against packets arriving out of order, the receiver MAY implement the following procedure. If a received packet shows a gap in the sequence and no redundant data is available to fill it, the received packet SHOULD be kept in a buffer to give the missing packet(s) time to arrive. It is RECOMMENDED that the waiting time be limited to 1 second ⏳
If a packet carrying a T140block from the gap arrives before the waiting time runs out, that T140block gets inserted 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 expires should be treated as lost, and a missing text marker should be inserted (see Section 5.3) 🦋
6. Parameter for Character Transmission Rate
Sometimes you need to limit how fast characters get sent 🎀 For example, when a Public Switched Telephone Network (PSTN) gateway is connecting an IP device to a PSTN textphone, the character rate from the IP device may need limiting so the gateway doesn't throw characters away when its buffer overflows 💀
To control the character transmission rate, use the MIME parameter "cps" in the "fmtp" attribute [7] (see Section 10 ). In SDP, it looks like this:
a=fmtp:<format> cps=<integer>The <format> field holds the payload type used for text. The <integer> field is an integer for the maximum number of characters that may be received per second. The value is used as a mean value over any 10-second interval. The default value is 30 🍓
You can find examples of this in SDP in Section 7.2 ✨
When devices receive this parameter, they MUST follow the request by sending characters at a rate at or below the specified <integer> value 🫶 This parameter wasn't defined in RFC 2793 [16], so implementations of the text/t140 format might be out there that don't recognize it or act on it. For that reason, receivers of text/t140 MUST be designed to handle temporary reception of characters at a higher rate than this parameter specifies. That way, malfunction from buffer overflow gets avoided during text conversations with human input 👑
7. Examples 🌸
7.1. RTP Packetization Examples for the text/t140 Format 🎀
okay bestie, let's look at some actual packets 👀✨ first up is a text/t140 RTP packet with no redundancy at all. it's the simplest version, no cap 💅
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 |
+ +---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+next, the same kind of packet but with one redundant T140block 🦋 the "RED" payload type is doing the heavy lifting here, and you can spot the "R" and "P" pieces in the layout.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+now the sneaky one 🙈 this packet has an empty primary block. that's what happens when you send a packet just to force the redundant data out when there's no new text. so cute, so useful 🫶
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 |
+-+-+-+-+-+-+-+-+ +---------------+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+as a follow-on to that last one, here's the next packet in the sequence 🌸 this time it actually carries real text in the primary block. it has two levels of redundancy and one primary data block. the empty block still shows up in the redundant copies, which is totally normal for text/t140. and when the "R2" block is the empty one, its "R2 block length" is set to zero to show that 🍓
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 "R2" | "R2" block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| T140 PT | timestamp offset of "R1" | "R1" block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| T140 PT | "R1" T.140 encoded redundant data |
+-+-+-+-+-+-+-+-+ +---------------+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| "P" T.140 encoded primary data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+7.2. SDP Examples 💜
time for the SDP side of things 🧚 this one describes RTP text transport on port 11000:
m=text 11000 RTP/AVP 98
a=rtpmap:98 t140/1000and this one is basically the same vibe, but it also uses RFC 2198 to give the recommended two levels of redundancy for the text packets 🔥
m=text 11000 RTP/AVP 98 100
a=rtpmap:98 t140/1000
a=rtpmap:100 red/1000
a=fmtp:100 98/98/98Note: even though these examples use the RTP/AVP profile, this memo isn't trying to limit itself to that. Any appropriate profile may be used with this memo 🌈
8. Security Considerations 🔐
okay, security time, and it's serious bestie 😭 All of the security considerations from Section 14 of RFC 3550 [2] apply.
8.1. Confidentiality 🤫
text is meant for text conversations, so encryption matters a lot here. the amount of data in a text conversation session is low, so any encryption method MAY be selected and applied to T.140 session contents or to whole RTP packets. Secure Real-time Transport Protocol (SRTP) [14] provides a suitable method for ensuring confidentiality 💖
8.2. Integrity 🛡️
sometimes you really don't want anyone messing with the text contents of an RTP stream 😤 SRTP [14] provides methods for providing integrity that MAY be applied.
8.3. Source Authentication 🪪
there are several ways to make sure the text is coming from who it says it's coming from 👀
text streams are usually used in a multimedia control environment. Security measures for authentication are available and SHOULD be applied in the registration and session establishment procedures, so that the identity of the sender of the text stream is reliably associated with the person or device setting up the session. Once established, SRTP [14] mechanisms MAY be applied to ascertain that the source is maintained the same during the session ✨
9. Congestion Considerations 🌊
the congestion considerations from Section 10 of RFC 3550 [2], Section 6 of RFC 2198 [3], and any used profile (e.g., the section about congestion in chapter 2 of RFC 3551 [11]) apply here, with the following application-specific considerations 💅
Automated systems MUST NOT use this format to send large amounts of text at rates significantly above those a human user could enter. 🤖🚫
even if network load from text conversation users is usually very low, for best-effort networks an application MUST monitor the packet loss rate and take appropriate actions to reduce its sending rate (if this application sends at a higher rate than what TCP would achieve over the same path). the reason is that this application, thanks to its recommended usage of two or more redundancy levels, is very robust against packet loss 💪 and because text conversations have such a low bit-rate, if you look at the discussion in RFC 3714 [13], this application will experience very high packet loss rates before it needs to reduce its sending rate at all 🧠
if the application needs to reduce its sending rate, it SHOULD NOT reduce the number of redundancy levels below the default amount specified in Section 4. Instead, the following actions are RECOMMENDED, in order of priority 📋
- Increase the shortest time between transmissions (described in Section 5.1) from the recommended 300 ms to 500 ms, which is the highest value allowed according to T.140.
- Limit the maximum rate of characters transmitted.
- Increase the shortest time between transmissions to a higher value, not higher than 5 seconds. This will cause unpleasant delays in transmission, beyond what is allowed according to T.140, but text will still be conveyed in the session with some usability 🥲
- Exclude participants from the session.
please note that if the reduction in bit-rate achieved through the above measures is not sufficient, the only remaining action is to terminate the session 💀
as guidance, here are some load figures as examples, based on use of IPv4, including the load from IP, UDP, and RTP headers without compression 📊
- Experience tells that a common mean character transmission rate, during a complete PSTN text telephony session, is around two characters per second.
- A maximum performance of 20 characters per second is enough even for voice-to-text applications.
- With the (unusually high) load of 20 characters per second, in a language that makes use of three octets per UTF-8 character, two redundant levels, and 300 ms between transmissions, the maximum load of this application is 3300 bits/s.
- When the restrictions mentioned above are applied, limiting transmission to 10 characters per second, using 5 s between transmissions, the maximum load of this application, in a language that uses one octet per UTF-8 character, is 300 bits/s.
Note that this payload can be used in a congested situation as a last resort to maintain some contact when audio and video media need to be stopped. the availability of one low bit-rate stream for text in such adverse situations may be crucial for keeping communication going in a critical moment 🆘🫶
10. IANA Considerations 🗂️
this document updates the RTP payload format named "t140" and the associated MIME type "text/t140", in the IANA RTP and Media Type registries 🌸
10.1. Registration of MIME Media Type text/t140 🎀
okay bestie, this is the part where the text/t140 MIME type gets officially registered 💅 here's the whole form, copied exactly so nothing gets fumbled:
MIME media type name: text
MIME subtype name: t140
Required parameters: rate: The RTP timestamp clock rate, which is
equal to the sampling rate. The only valid value is 1000.
Optional parameters: cps: The maximum number of characters that may
be received per second. The default value is 30.
Encoding considerations: T.140 text can be transmitted with RTP as
specified in RFC 4103.
Security considerations: See Section 8 of RFC 4103.
Interoperability considerations: This format is the same as specified
in RFC2793. For RFC2793 the "cps=" parameter was not defined.
Therefore, there may be implementations that do not consider this
parameter. Receivers need to take that into account.
Published specification: ITU-T T.140 Recommendation. RFC 4103.
Applications which use this media type: Text communication terminals
and text conferencing tools.
Additional information: This type is only defined for transfer via
RTP.
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 |so the big one is rate, which is required and has exactly one valid value, 1000 ⏱️ cps is optional and defaults to 30 if nobody says otherwise 🧚 the interop note is important too: the older RFC2793 version never defined cps=, so some implementations might just ignore it, and receivers have to account for that 🫶
10.2. SDP Mapping of MIME Parameters 🦋
so the stuff in the MIME type spec has a very specific home in SDP [7], which is the thing everyone uses to describe RTP sessions ✨ when SDP is describing a text/t140 session, it goes like this:
- The MIME type (
text) goes in SDPm=as the media name. - The MIME subtype (payload format name) goes in SDP
a=rtpmapas the encoding name. The RTP clock rate ina=rtpmapMUST be 1000 fortext/t140. - The parameter
cpsgoes in SDPa=fmtpattribute. - When the payload type is used with redundancy according to RFC 2198, the level of redundancy is shown by the number of elements in the slash-separated payload type list in the
fmtpparameter of the redundancy declaration as defined in RFC 4102 [9] and RFC 2198 [3].
10.3. Offer/Answer Consideration 🤝
okay so if you want interop to work inside the offer/answer model [10], there's one consideration that should be made:
- The
cpsparameter is declarative. Both sides may provide a value, which is independent of the other side.
11. Acknowledgements 🫶
the authors want to give a big shoutout to Stephen Casner, Magnus Westerlund, and Colin Perkins for the super valuable reviews and advice while this doc was being made 💖 thank you to Mickey Nasiri at Ericsson Mobile Communication for providing the development environment, to Michele Mizarro for checking that the payload format is usable for its intended purpose, and to Andreas Piirimets for the editing support and validation. legends, all of them 👑
12. Normative 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 3550, July 2003.
- [3] 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.
- [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", STD 63, RFC 3629, November 2003.
- [7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [8] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
- [9] Jones, P., "Registration of the text/red MIME Sub-Type", RFC 4102, June 2005.
- [10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
- [11] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conference with Minimal Control", STD 65, RFC 3551, July 2003.
- [12] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
13. Informative References 🌸
- [13] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
- [14] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [15] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
- [16] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793, May 2000.
- [17] ITU-T Recommendation F.703, Multimedia Conversational Services, November 2000.
Authors' Addresses 🧚
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE-121 37 Johanneshov
Sweden
Phone: +46 708 204 288 / +46 8 556 002 03
Fax: +46 8 556 002 06
EMail: gunnar.hellstrom@omnitor.se
Paul E. Jones
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Phone: +1 919 392 6948
EMail: paulej@packetizer.comFull 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 keep 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 on whether any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document are valid or in scope, or whether a license under those rights might be available. it also doesn't claim to have done any independent search for such rights. info on how RFC documents handle rights is in BCP 78 and BCP 79.
copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
the IETF also invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc4103 2005-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms