RFC 4351
Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream
RFC 4351: Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream 🎀
Bestie, this one is a Historic doc from January 2006 💅. It was written by G. Hellstrom from Omnitor AB and P. Jones from Cisco Systems, Inc., and it's published under the Network Working Group. The header has no Obsoletes or Updates entries, so this RFC doesn't replace or update anything else 🧚.
Status of This Memo ✨
This memo is a Historic Document for the Internet community 📚. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 💜.
Copyright Notice 🌸
Copyright (C) The Internet Society (2006).
Abstract 🦋
Okay so this memo explains how to carry real-time text conversation session contents inside RTP packets 💖. The text conversation contents themselves are specified in ITU-T Recommendation T.140.
It describes one payload format for sending audio and text data together within a single RTP session 🎶.
It also recommends a way to include redundant text from packets that were already sent, so there's less chance 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 audio/t140c Data ........4
3.3. The "T140block" ............................................5
3.4. Synchronization of Text with Other Media ...................5
3.5. Synchronization Considerations for the audio/t140c Format ..5
3.6. RTP Packet Header ..........................................6
4. Protection against Loss of Data .................................7
4.1. Payload Format When Using Redundancy .......................7
4.2. Using Redundancy with the audio/t140c Format ...............8
5. Recommended Procedure ...........................................8
5.1. Recommended Basic Procedure ................................8
5.2. Transmission before and after "Idle Periods" ...............9
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 audio/t140c Format .....11
7.2. SDP Examples ..............................................12
8. Security Considerations ........................................13
8.1. Confidentiality ...........................................13
8.2. Integrity .................................................13
8.3. Source Authentication .....................................13
9. Congestion Considerations ......................................14
10. IANA Considerations ...........................................15
10.1. Registration of MIME Media Type audio/t140c ..............15
10.2. SDP Mapping of MIME Parameters ...........................16
10.3. Offer/Answer Consideration ...............................17
11. Acknowledgements ..............................................17
12. Normative References ..........................................17
13. Informative References ........................................181. Introduction ✨
This document defines a payload type for carrying text conversation session contents in RTP [2] packets 💖. Those session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation can be used on its own, or alongside other conversational stuff like video and voice, to build multimedia conversation services 🎀. In multimedia conversation sessions, text is 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, but it can also come from handwriting recognition, voice recognition, or any other input method 🦋. Usually that's only a few characters per second or less 💅. In general, only one or a few new characters get sent in each packet. Sometimes a user pastes in a little block of text they prepared, and that can make a packet carry a bigger payload 🌈.
T.140 says that text and other T.140 elements must be transmitted in ISO 10646-1[5] code with UTF-8 [6] transformation 🌸. That makes it way easier to build apps that work internationally and to handle text in modern information technology environments 🌍. The payload of an RTP packet that follows this spec is 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 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 most a little.
So this doc specifies a mechanism based on RTP 🎀. It gets text to arrive in the correct order, without duplication, and it detects and indicates loss too 👀. It also has an optional possibility to repeat data for redundancy, which lowers the risk of loss 💜. Packet overhead is usually much bigger than the T.140 contents, so the bandwidth increase from using redundancy is minimal 🫶.
Using RTP for text in a multimedia conversation app means text and other media can be handled in a uniform way. Examples include conferencing systems, firewalls, and network translation devices 🧚. That makes the design easier and boosts the chances of prompt and proper media delivery 🔥.
This document introduces a method for transporting text interleaved with voice within the same RTP session 💖.
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 [4] 🙈. So whenever you see those words in caps, that's the vibe the spec is going for 💅.
3. Usage of RTP 🌷
The payload format for real-time text transmission with RTP [2] that's described in this memo is meant for use between Public Switched Telephone Network (PSTN) gateways. It's called audio/t140c 📞.
3.1. Motivations and Rationale 💭
The audio/t140c payload spec is meant to let gateways that connect two PSTN networks interleave audio and text data, received on the PSTN circuit, through a single RTP session 🎧. It's kind of like the way dual-tone multifrequency (DTMF) gets pulled out and sent inside an RTP session [14] 🎹.
The audio/t140c format SHALL NOT be used for applications other than PSTN gateway applications. For those gateway apps, a specific profiling document MAY make it REQUIRED for a specific application 📑. You'd pick audio/t140c for gateway apps where ports are limited and scarce, which is the main reason to prefer it 🚪. Applications SHOULD use RFC 4103 [15] for real-time text communication that falls outside the limited scope of this specification 💅.
3.2. Payload Format for Transmission of audio/t140c Data 🧩
An audio/t140c conversation RTP payload is made of a 16-bit "T140block counter", carried in network byte order (see RFC 791 [11] Annex B). After that comes one and only one "T140block" (see section 3.3) 🍰. The fields in the RTP header are set as defined in section 3.6 📦.
The T140block counter MUST be initialized to zero the first time a packet containing a T140block is transmitted. It MUST be incremented by 1 each time a new block is transmitted. Once the counter hits the value 0xFFFF, it gets reset to 0 the next time it's incremented 🔢. This counter is how lost blocks get detected and how duplicate blocks get avoided 🕵️♀️.
To keep things readable, the rest of this document talks only about the T140block and doesn't explicitly mention the T140block counter 📖. Just know that when you're using the audio/t140c format, the T140block counter MUST always come before the actual T140block, including redundant data transmissions 💜.
3.3. The "T140block" 🎀
T.140 text is UTF-8 coded, as specified in T.140, with no extra framing 🌸. A T140block holds 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 gets 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 🫶. 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 separate RTP stream 🎬. So if it matters that text and other media packets stay synchronized, the streams MUST be associated when the sessions are established, 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 🕰️.) Association of RTP streams can be done through the CNAME field of the RTP Control Protocol (RTCP) SDES function 🔗. How you do it depends on the particular application, and that's outside the scope of this document 🙌.
3.5. Synchronization Considerations for the audio/t140c Format 💅
Okay so audio/t140c packets usually get sent in between voice packets or other kinds of audio packets 🎀. The whole point is to build one shared audio signal on the receiving end so the call can hop back and forth between text and voice. The audio/t140c payload then plays out audio signals using a PSTN textphone coding method (usually a modem) 📞.
You have to watch the RTP timestamps of the voice, text, or other audio packets ⏱️ if you want the stream to play back correctly. Also, ngl, incoming text from a PSTN circuit can come in at a higher bit-rate than an egress PSTN circuit can play out 😭. So on the egress side, a gateway might not finish playing out the text packets before it's time to play the next voice packet.
This app is mainly for PSTN textphone users, so it is strongly RECOMMENDED that all received text packets get properly reproduced on the egress gateway before any other subsequent audio packets are considered 🫶.
If it's necessary, voice and other audio packets should be discarded so the text signals can be properly reproduced on the PSTN circuit 🗑️, even if the text packets arrive late.
PSTN textphone users commonly use turn-taking indicators in the text stream 🔁. So you can expect that as long as text is being transmitted, it's valid text and should get priority over voice 👑.
Usual RTP semantics apply when switching payload formats within an RTP session. A sender MAY switch between "audio/t140c" and some other format within an RTP session, but MUST NOT send overlapping data using two different audio formats within an RTP session. 🚫
Here's the bit people miss: this doesn't stop an implementation from splitting itself into two logical parts to send overlapping data 🧚. Each part uses its own synchronization source (SSRC) and sends its own RTP and RTCP. Others in the session will see that endpoint as two participants with different SSRCs, but the same RTCP SDES CNAME 🌸. For more on using multiple payloads in an RTP session, check RFC 3550 [2].
3.6. RTP Packet Header 🦋
Every RTP packet starts with a fixed RTP header. These are the fixed header fields that get specified 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 use dynamic payload type number assignment, this payload format can be identified by the MIME type audio/t140c (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 in RFC 3555 [17].
Sequence number: Sequence numbers are defined in RFC 3550 [2] 🔢. With the audio/t140c payload format, character loss gets detected through the T140block counter instead.
Timestamp: The RTP Timestamp encodes the approximate moment the primary text in the packet entered the stream ⏰. For audio/t140c, the clock frequency MAY be set to any value, and it SHOULD be set to the same value as any audio packets in the same RTP stream, so you avoid RTP timestamp rate switching 🙈. The value SHOULD be set by out of band mechanisms. Sequential packets MUST NOT use the same timestamp. Since packets don't represent any constant duration, 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 distinguished 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 for detecting loss.
4. Protection against Loss of Data 🧷
Keeping text loss caused by packet loss within acceptable limits really deserves attention 🎯. (See ITU-T F.703 [16].)
The default method that MUST be used when no other method is explicitly selected is redundancy in accordance with 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.
Other protection methods MAY be used 🌈. Forward Error Correction mechanisms as per RFC 2733 [8], or any other mechanism meant to increase the reliability of text transmission, MAY be used as an alternative or as a complement to redundancy. Text data MAY be sent without additional protection if end-to-end network conditions let the text quality requirements in ITU-T F.703 [16] be met under every anticipated load condition 🫧.
4.1. Payload Format When Using Redundancy 🍓
When you use the format with redundant data, the transmitter may select a number of T140block generations to retransmit in each packet. A higher number gives better protection against text loss, but it marginally increases the data rate ⬆️.
The RTP header is followed by one or more redundant data block headers, one for each redundant data block to be included. Each of these headers gives the timestamp offset and length of its data block, plus a payload type number indicating the audio/t140c payload format 🧾.
After the redundant data block headers come the redundant data fields carrying T140blocks from previous packets. Last but not least comes the new (primary) T140block for this packet 🎁.
Redundant data that would need a timestamp offset higher than 16383 because of its age at transmission MUST NOT be included in transmitted packets ❌.
4.2. Using Redundancy with the audio/t140c Format 🧠
Sequence numbers aren't provided in the redundant header, and the sequence number space is shared by all audio payload types within an RTP session 🙃. So a sequence number in the form of a T140block counter gets added to the T140block for transmission. This lets the redundant T140block data for missing primary data be retrieved and slotted properly into the stream of received T140block data when using the audio/t140c payload format 🧩.
All non-empty redundant data blocks MUST contain the same data as a T140block previously transmitted as primary data, and they MUST be identified with a T140block counter that equals the original T140block counter for that T140block. 🔒
The T140block counters that come before the text in the T140block let the receiver put things in order 📚. If there's a gap in the T140block counter value of received audio/t140c packets, and there are redundant T140blocks whose counters match the missing ones, the redundant T140blocks may be substituted for the missing T140blocks 🦸.
The value of the length field in the redundant header indicates the length of the concatenated T140block counter and the T140block 📏.
5. Recommended Procedure 🌟
This section has RECOMMENDED procedures for using the payload format 💫. Based on the information in the received packets, the receiver can:
- reorder text received 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 are transmitted when there's valid T.140 data to send 📤.
T.140 specifies that 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 require another value.
If no new data is available for longer than the buffering time, the transmission process is in an idle period 😴.
When new text becomes available for transmission after an idle period, it is RECOMMENDED to send it as soon as possible ⚡. After that transmission, it is RECOMMENDED to buffer T.140 data in buffering time intervals until the next idle period. This keeps the maximum bit-rate usage for text at a reasonable level 🌿. The buffering time MUST be selected so that text users will perceive a real-time text flow 💖.
5.2. Transmission before and after "Idle Periods" 🌙
When valid T.140 data has been sent and no new T.140 data is available for transmission after the selected buffering time, an empty T140block SHOULD be transmitted. This situation counts as the beginning of an idle period. The procedure is recommended so potentially missing text can be detected more quickly before an idle period, or when the audio stream switches from transmitting audio/t140c to some other form of audio 🔍.
An empty T140block contains no data: neither T.140 data nor a T140block counter 🫥.
When redundancy is used, transmission continues with a packet at every transmission timer expiration, with an empty T.140block inserted as primary. This goes on until the last non-empty T140block has been transmitted as primary and as redundant data with all intended generations of redundancy 🔁. The last packet before an idle period will contain only one non-empty T140block as redundant data, plus the empty primary T140block 🫙.
When using the audio/t140c payload format, empty T140blocks sent as primary data SHOULD NOT be included as redundant T140blocks. Sending them would just waste bandwidth, and it would introduce a risk of falsely detecting loss 🚫.
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 🕵️
Receivers detect the loss of an audio/t140c packet by observing the value of the T140block counter in a subsequent audio/t140c packet 👀.
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] ❓.
Procedures based on detecting the packet with the M-bit set to one MAY be used to reduce the risk of introducing false markers of loss 🎯.
False detection is also avoided when using audio/t140c by observing the value of the T140block counter 💅.
If two successive packets have the same number of redundant generations, it SHOULD be treated as the general redundancy level for the session 🧃. Changing the general redundancy level SHOULD only be done after an idle period 🌜.
5.4. Compensation for Packets Out of Order 🌀
To protect against packets arriving out of order, the following procedure MAY be implemented in the receiver 🛡️. If analysis of a received packet reveals a gap in the sequence and no redundant data is available to fill that gap, the received packet SHOULD be kept in a buffer, so there's time for the missing packet(s) to arrive. It is RECOMMENDED that the waiting time be limited to 1 second ⏱️.
If a packet with a T140block belonging to the gap arrives before the waiting time expires, that T140block gets inserted into the gap. 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 inserted (see section 5.3) 🥺.
6. Parameter for Character Transmission Rate ✨
okay so sometimes you NEED to slow the characters down 🐢💖 like, if a PSTN gateway is connecting an IP device to an old-school PSTN textphone, the IP side might have to chill on the character rate, or the gateway's buffer overflows and characters just get thrown away 😭 no thanks.
To control the rate, there's a MIME parameter called "cps" that goes in the "fmtp" attribute [7] (check out section 10 for the registration details 🎀). In SDP it looks like this:
a=fmtp:<format> cps=<integer>The <format> bit is the payload type used for text 🦋. The <integer> is the max number of characters that may be received per second. The value shall be used as a mean value over any 10-second interval ✨. If nothing's specified, the default is 30 💅.
When a device gets this parameter, it MUST adhere to it, so it has to keep its transmission at or below the <integer> value. Bestie, that's non-negotiable 🫶. Examples of this in SDP are in section 7.2 🌸.
7. Examples
7.1. RTP Packetization Examples for the audio/t140c Format
Here's an audio/t140c RTP packet with no redundancy 🍓 Look at how clean it is.
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| T140c PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (8000Hz) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T140block counter | T.140 encoded data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---------------+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next up is an RTP packet with one redundant T140block using the audio/t140c payload format 🔥. The primary block is empty, which happens when you send a packet just to force the redundant data out when there's no new data. And since this is audio/t140c, the redundant block of T.140 data is immediately preceded by a T140block counter 🙈.
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| T140c PT | timestamp offset of "R" | "R" block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| T140c PT | "R" T140block counter | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| "R" T.140 encoded redundant data |
+ +---------------+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Following on from that, the next packet in the sequence has a new real T140block 💜 This one has 2 levels of redundancy and one primary data block. The previous primary block was empty, so no redundant data is included for it. Why? Because with audio/t140c, any earlier "empty" T140blocks are NOT included as redundant data in later packets. Lowkey genius, right? 🧚
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| T140c PT | timestamp offset of "R1" | "R1" block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| T140c PT | "R1" T140block counter | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| "R1" T.140 encoded redundant data |
+ +---------------+
| | "P" T140block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| counter | "P" T.140 encoded primary data |
+-+-+-+-+-+-+-+-+ +
| |
+ +---------------+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+7.2. SDP Examples
Here's some SDP describing RTP text interleaved with G.711 audio packets in the same RTP session 📞. It comes from port 7200 and caps the text at a max of 6 characters per second 💅:
m=audio 7200 RTP/AVP 0 98
a=rtpmap:98 t140c/8000
a=fmtp:98 cps=6And this one uses RFC 2198 to give text packets the recommended two levels of redundancy 🌈. It's still interleaving text and G.711 in one session, with text no faster than 20 characters per second ⭐:
m=audio 7200 RTP/AVP 0 98 100
a=rtpmap:98 t140c/8000
a=fmtp:98 cps=20
a=rtpmap:100 red/8000
a=fmtp:100 98/98/98Note: these examples use the RTP/AVP profile, but that's not meant to limit this memo to just that profile 🦋. Any appropriate profile can be used with this memo ✨.
8. Security Considerations
Everything in section 14 of RFC 3550 [2] applies here, no exceptions 🚨.
8.1. Confidentiality
Okay, this is serious bestie 😭. The whole point of this payload format is carrying text in a text conversation, so encryption really matters. The amount of data in a text session is low, so any encryption method MAY be selected and applied to the T.140 session contents or to the whole RTP packets 🔐. Secure Realtime Transport Protocol (SRTP) [13] is a solid option for keeping things confidential.
8.2. Integrity
Sometimes you need to protect the text in an RTP stream from being messed with 🙅♀️. SRTP [13] has integrity methods that MAY be applied.
8.3. Source Authentication
Making sure the text comes from who it's supposed to come from can be done with a mix of methods 💖.
Text streams usually live in a multimedia control environment 🎀. Authentication security measures are available and SHOULD be applied during registration and session establishment, so the identity of the text sender is reliably tied to the person or device setting up the session. Once that's done, SRTP [13] mechanisms MAY be applied to make sure the source stays the same for the whole session 🔒.
9. Congestion Considerations
Congestion stuff from section 10 of RFC 3550 [2], section 6 of RFC 2198 [3], and whichever profile you're using (like the congestion part in section 2 of RFC 3551 [10]) all apply here, plus some extra app-specific notes 🌸.
Automated systems MUST NOT use this format to send large amounts of text at a rate way above what a human could type 🤖🚫.
Even though text conversation load is usually super low, on best-effort networks an application MUST monitor its packet loss rate 📉. If it sends faster than TCP would manage over the same path, it MUST take action to reduce its sending rate. Here's why this is chill: with two or more redundancy levels, the app is really robust against packet loss 🛡️. And since text is low bit-rate, if you read RFC 3714 [12], the app will see really high packet loss before it has to cut its rate at all 💪.
If the app does need to slow down, it SHOULD NOT drop the number of redundancy levels below the default in section 4 🙅♀️. Instead, these 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 that is the highest value allowable 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.
Heads up 🚨: if cutting the bit-rate with the steps above still isn't enough, the only option left is to terminate the session 💀.
Here are some load figures as examples, based on IPv4, including IP, UDP, and RTP headers without compression 📊:
- Experience tells that a common mean character transmission rate during a complete PSTN text telephony session in reality is around 2 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 make use of three-octet UTF-8 characters, two redundant levels, and 300 ms between transmissions, the maximum load of this application is 3500 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.
Also, this payload can be used in a congested situation as a last resort to keep some contact going when audio and video need to be stopped 🆘. Having one low bit-rate text stream in those rough moments can be crucial for staying in touch when it matters most 🫶.
10. IANA Considerations
This document defines one RTP payload format named t140 and an associated MIME type audio/t140c 🎉. IANA has registered both 👑.
10.1. Registration of MIME Media Type audio/t140c 💖
okay so this is where the MIME type gets officially registered, and yes it's paperwork, but make it iconic ✨ here's the whole registration template:
MIME media type name: audio
MIME subtype name: t140c
Required parameters:
rate: The RTP timestamp clock rate, which is equal to the
sampling rate. This parameter SHOULD have the same value as
for any audio codec packets interleaved in the same RTP
stream.
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 4351.
Security considerations: See section 8 of RFC 4351.
Interoperability considerations: None
Published specification: ITU-T T.140 Recommendation.
RFC 4351.
Applications which use this media type:
Text communication systems and text conferencing tools that
transmit text associated with audio and within the same RTP
session as the audio, such as PSTN gateways that transmit
audio and text signals between two PSTN textphone users
over an IP network.
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:
Paul E. Jones
E-mail: paulej@packetizer.com
Intended usage: COMMON
Author / Change controller:
Paul E. Jones | IETF avt WG delegated from the IESG
paulej@packetizer.com |10.2. SDP Mapping of MIME Parameters 🎀
the MIME type spec has a very specific mapping onto fields in the Session Description Protocol (SDP) [7], which is what people use to describe RTP sessions. so when you're setting up sessions with the audio/t140c format in SDP, it goes like this:
- The MIME type ("audio") goes in SDP
m=as the media name. - The MIME subtype (payload format name) goes in SDP
a=rtpmapas the encoding name. For audio/t140c, the clock rate MAY be set to any value, and SHOULD be set to the same value as for any audio packets in the same RTP stream. 🍓 - The parameter "cps" goes in SDP
a=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 "fmtp" parameter of the redundancy declaration as defined in RFC 2198 [3]. the number of slash-separated elements is literally how you tell the redundancy level, so count carefully bestie 🧮
10.3. Offer/Answer Consideration ☎️
so if you want interoperability inside the offer/answer model [9], here's the one thing you should keep in mind 👀
- The "cps" parameter is declarative. Both sides may provide a value, which is independent of the other side. no negotiating the number, each side just says its own piece 💅
11. Acknowledgements 🫶
the authors want to give a huge thank you to Stephen Casner, Magnus Westerlund, and Colin Perkins for the valuable support, reviews, and advice on making this document. big thanks also to Mickey Nasiri at Ericsson Mobile Communication for providing the development environment, Michele Mizarro for checking that the payload format actually works for what it was built for, and Andreas Piirimets for the editing help. the real MVPs 👑
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", STD 64,
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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[10] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[11] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.13. Informative References 🧠
[12] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
Control for Voice Traffic in the Internet", RFC 3714, March
2004.
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[14] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[15] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
RFC 4103, June 2005.
[16] ITU-T Recommendation F.703, Multimedia Conversational Services,
Nov 2000.
[17] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.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 ⚖️
okay the legal bit, but it's important so read it 🙈 the copyright here belongs to The Internet Society (2006).
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 in it 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 doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope. it also doesn't say whether a license for those rights is available, and it hasn't independently gone looking for any of them. if you want the procedures for rights in RFC documents, check BCP 78 and BCP 79.
copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.
the IETF invites anyone interested to bring to its attention any copyrights, patents or 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 provided by the IETF Administrative Support Activity (IASA). the end, periodt 🦋
📦 where this page comes from
- ietf: rfc4351 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms