idnits 2.17.1 draft-ietf-avt-rtp-text-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 291 has weird spacing: '...mestamp of pr...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2279 (ref. '6') (Obsoleted by RFC 3629) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 Internet Draft Gunnar Hellstrom 3 draft-ietf-avt-rtp-text-04.txt LM Ericsson 4 February, 6, 2000 5 Expires: August 6, 2000 7 RTP Payload for Text Conversation 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and it is in full conformance with 12 all provisions of section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/lid-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Distribution of this document is unlimited. 30 ABSTRACT 32 This memo describes how to carry text conversation session contents 33 in RTP packets. Text conversation session contents are specified in 34 ITU-T Recommendation T.140 [1]. 36 Text conversation is used alone or in connection to other 37 conversational facilities such as video and voice, to form multimedia 38 conversation services. 40 This RTP payload description contains an optional possibility to 41 include redundant text from already transmitted packets in order to 42 reduce the risk of text loss caused by packet loss. The redundancy 43 coding follows RFC 2198. 45 Internet Draft 47 1 Introduction 49 This memo defines a payload type for carrying text conversation 50 session contents in RTP packets. Text conversation session contents 51 are specified in ITU-T Recommendation T.140 [1]. Text conversation is 52 used alone or in connection to other conversational facilities such 53 as video and voice, to form multimedia conversation services. Text in 54 text conversation sessions is sent as soon as it is available, or 55 with a small delay for buffering. 56 The text is supposed to be entered by human users from a keyboard, 57 handwriting recognition, voice recognition or any other input method. 58 The rate of character entry is usually at a level of a few characters 59 per second or less. Therefore, the expected number of characters to 60 transmit is low. Only one or a few new characters are expected to be 61 transmitted with each packet. 63 T.140 specifies that text and other T.140 elements MUST be 64 transmitted in ISO 10 646-1 code with UTF-8 transformation. That 65 makes it easy to implement internationally useful applications, and 66 to handle the text in modern information technology environments. 67 The payload of an RTP packet following this specification 68 consists of text encoded according to T.140 without any 69 additional framing. A common case will be a single ISO 10646 70 character, UTF-8 encoded. 72 T.140 requires the transport channel to provide characters without 73 duplication and in original order. 74 Text conversation users expect that text will be delivered with no or 75 a low level of lost information. If lost information can be 76 indicated, the willingness to accept loss is expected to 77 be higher. 79 Therefore a mechanism based on RTP is specified here. It gives text 80 arrival in correct order, without duplications, 81 and with detection and indication of losses. It also includes an 82 optional possibility to repeat data for redundancy to lower the 83 risk of loss. Since packet overhead is 84 usually much larger than the T.140 contents, the increase in channel 85 load by the redundancy scheme is minimal. 87 1.1 Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [4] 93 Internet Draft 95 2. Usage of RTP 97 When transport of T.140 text session data in RTP is desired, the 98 payload as described in this specification SHOULD be used. 100 A text conversation RTP packet as specified by this payload format 101 consists of an RTP header as defined in RFC 1889 [2] followed 102 immediately by a block of T.140 data, defined here to be a 103 "T140block". There is no additional header specific to this 104 payload format. The T140block contains one or more T.140 code 105 elements as specified in [1]. Most T.140 code elements are single 106 ISO 10646 [5] characters, but some are multiple character 107 sequences. Each character is UTF-8 encoded [6] into one or more 108 octets. 110 The T140blocks MAY be transmitted redundantly according to the 111 payload format defined in RFC 2198 [3]. In that case, the RTP 112 header is followed by one or more redundant data block headers, the 113 same number of redundant data fields carrying T140blocks from 114 previous packets, and finally the new (primary) T140block for this 115 packet. 117 2.1 RTP packet header 119 Each RTP packet starts with a fixed RTP header. The following fields 120 of the RTP fixed header are used for T.140 text streams: 122 Payload Type (PT): The assignment of an RTP payload type is specific 123 to the RTP profile under which this payload format is used. For 124 profiles which use dynamic payload type number assignment, this 125 payload format is identified by the name "T140" (see section 6). 126 If redundancy is used per RFC 2198, the Payload Type MUST indicate 127 that payload format ("RED"). 129 Sequence number: The Sequence Number MUST be increased by one for 130 each new transmitted packet. It is used for detection of packet loss 131 and packets out of order, and can be used in the process of retrieval 132 of redundant text, reordering of text and marking missing text. 134 Timestamp: The RTP Timestamp encodes the approximate instance of entry 135 of the primary text in the packet. A clock frequency of 1000 Hz MUST 136 be used. Sequential packets MUST NOT use the same timestamp. Since 137 packets do not represent any constant duration, the timestamp cannot 138 be used to directly infer packet losses. 140 Internet Draft 142 2.2 Additional headers 144 There are no additional headers defined specific to this payload 145 format. 147 When redundant transmission of the data according to RFC 2198 is 148 desired, the RTP header is followed by one or more redundant data 149 block headers, one for each redundant data block to be included. 150 Each of these headers provides the timestamp offset and length of 151 the corresponding data block plus a payload type number indicating 152 this payload format ("T140"). 154 2.3 T.140 Text structure 156 T.140 text is UTF-8 coded as specified in T.140 with no extra 157 framing. When using the format with redundant data, the transmitter 158 MAY select a number of T140block generations to retransmit in each 159 packet. A higher number introduces better protection against loss 160 of text but increases the data rate. 162 Since packets are not generated at regular intervals, the timestamp is not 163 sufficient to identify a packet in the presence of loss unless extra 164 information is provided. Since sequence numbers are not provided in 165 the redundant header, some additional rules must be followed to allow the 166 redundant data corresponding to missing primary data to be merged 167 properly into the stream of primary data T140blocks: 168 - Each redundant data block MUST contain the same data as a 169 T140block previously transmitted as primary data, and be 170 identified with a timestamp offset equating to the original 171 timestamp for that T140block. 172 - The redundant data MUST be placed in age order with most 173 recent redundant T140block last in the redundancy area. 174 - All T140blocks from the oldest desired generation up through 175 the generation immediately preceding the new (primary) 176 T140block MUST be included. 178 These rules allow the sequence numbers for the redundant T140blocks 179 to be inferred by counting backwards from the sequence number in 180 the RTP header. The result will be that all the text in the 181 payload will be contiguous and in order. 183 3. Recommended procedures 185 This section contains RECOMMENDED procedures for usage of the payload 186 format. 187 Based on the information in the received packets, the receiver can: 188 - reorder text received out of order. 189 - mark where text is missing because of packet loss. 190 - compensate for lost packets by using redundant data. 192 Internet Draft 194 3.1 Recommended basic procedure 196 Packets are transmitted only when there is valid T.140 data to 197 transmit. The sequence number is used for sequencing of T.140 data. 199 On reception, the RTP sequence number is compared with the sequence 200 number of the last correctly received packet. If they are 201 consecutive, the (only or primary) T140block is retrieved from the 202 packet. 204 3.2 Recommended procedure for compensation for lost packets. 206 For reduction of data loss in case of packet loss, redundant data MAY 207 be included in the packets following to the procedures in RFC 2198. 208 If network conditions are not known, it is RECOMMENDED to use one 209 redundant T140block in each packet. If there is a gap in 210 the RTP sequence numbers, and redundant T140blocks are 211 available in a subsequent packet, the sequence numbers for the 212 redundant T140blocks should be inferred by counting backwards from 213 the sequence number in the RTP header for that packet. If there are 214 redundant T140blocks with sequence numbers matching those that are 215 missing, the redundant T140blocks may be substituted for the 216 missing T140blocks. 218 Both for the case when redundancy is used and not used, missing data 219 SHOULD be marked. T.140 defines a missing data marker (Unicode 220 character 2607 "Lightning") which SHOULD be used as a marker to 221 indicate each missing T140block. 223 3.3 Recommended procedure for compensation for packets out of order. 225 For protection against packets arriving out of order, the following 226 procedure MAY be implemented in the receiver. 227 If analysis of a received packet reveals a gap in the sequence and 228 no redundant data is available to fill that gap, 229 the received packet can be kept in a buffer to allow time for the 230 missing packet(s) to arrive. It is suggested that the waiting 231 time be limited to 0.5 seconds. For the case when redundancy is used 232 the waiting time SHOULD be extended to the number of redundancy 233 generations times the T.140 buffering timer if this product is known 234 to be greater than 0.5 seconds. 236 If a packet with a T140block belonging to 237 the gap arrives before the waiting time expires, this T140block 238 is inserted into the gap and then consecutive T140blocks from the 239 leading edge of the gap may be consumed. Any T140block which does 240 not arrive before the time limit expires should be treated as lost. 242 Internet Draft 244 3.4 Transmission during "silent periods" when redundancy is used. 246 When using the redundancy transmission scheme, and there is nothing 247 more to transmit from T.140, the latest T140block has a risk of 248 getting old before it is transmitted as redundant data. The result 249 is less useful protection against packet loss at the end of a text 250 input sequence. For cases where this should be avoided, 251 a zero-length primary T140block MAY be transmitted with the redundant 252 data. 254 Any zero-length T140blocks that are sent as primary data 255 MUST be included as redundant T140blocks on subsequent packets 256 just as normal text T140blocks would be so that sequence number 257 inference for the redundant T140blocks will be correct, as 258 explained in section 2.3. 260 Redundancy for the last T140block SHOULD NOT be implemented by 261 repeatedly transmitting the same packet (with the same sequence 262 number) because this will cause the packet loss count, as reported 263 in RTCP, to decrement. 265 Internet Draft 267 4. Examples 269 This is an example of a T140 RTP packet without redundancy. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |V=2|P|X| CC=0 |M| T140 PT | sequence number | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | timestamp (1000Hz) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | synchronization source (SSRC) identifier | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 + T.140 encoded data + 280 | | 281 + +---------------+ 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 This is an example of an RTP packet with one redundant T140block. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |V=2|P|X| CC=0 |M| "RED" PT | sequence number of primary | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | timestamp of primary encoding "P" | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | synchronization source (SSRC) identifier | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |1| T140 PT | timestamp offset of "R" | "R" block length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |0| T140 PT | | 298 +-+-+-+-+-+-+-+-+ + 299 | | 300 + "R" T.140 encoded redundant data + 301 | | 302 + +---------------+ 303 | | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 305 | "P" T.140 encoded primary data | 306 + + 307 + +---------------+ 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure: Examples of RTP text packets. 313 Internet Draft 315 5. Security Considerations. 317 Since the intention of the described payload format is to carry text 318 in a text conversation, security measures in the form of encryption 319 are of importance. The amount of data in a text conversation session 320 is low and therefore any encryption method MAY be selected and 321 applied to T.140 session contents or to the whole RTP packets. 322 When redundant data is included, the same security considerations 323 as for RFC 2198 apply. 325 6. MIME Media Type Registrations 327 This document defines a new RTP payload name and associated MIME 328 type, T140 (text/t140). 330 6.1 Registration of MIME media type text/t140 332 MIME media type name: text 334 MIME subtype name: t140 336 Required parameters: None 338 Optional parameters: None 340 Encoding considerations: T140 text can be transmitted 341 with RTP as specified in "draft-ietf-avt-rtp-text-04". 343 Security considerations: None 345 Interoperability considerations: None 347 Published specification: ITU-T T.140 Recommendation. 348 draft-ietf-avt-rtp-text-04. 350 Applications which use this media type: 351 Text communication terminals and text conferencing tools. 353 Additional information: None 355 Magic number(s): None 356 File extension(s): None 357 Macintosh File Type Code(s): None 359 Person & email address to contact for further information: 360 Gunnar Hellstrom 361 e-mail: gunnar.hellstrom@omnitor.se 363 Intended usage: COMMON 364 Author/Change controller: 365 Gunnar Hellstrom 366 e-mail: gunnar.hellstrom@omnitor.se 368 7. Author's Address 370 Gunnar Hellstrom 371 Ericsson Mobile Communication AB 372 Home Communications 373 SE-164 80 Stockholm 374 Sweden 376 e-mail: gunnar.hellstrom@omnitor.se 377 Tel: +46 708 204 288 378 Fax: +46 8 556 002 06 380 8. Acknowledgements 382 The author wants to thank Stephen Casner and Colin Perkins for 383 valuable support with reviews and advice on creation of this 384 document, and Michele Mizarro for verification of the usability of 385 the payload format for its intended purpose. 387 9. References 389 [1] ITU-T Recommendation T.140 (1998) - Text conversation protocol for 390 multimedia application, with amendment 1999. 392 [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 393 "RTP: A Transport Protocol for Real-Time Applications", RFC 1889. 395 [3] C. Perkins, I. Kouvelas, V. Hardman, M. Handley, and J. Bolot, 396 "RTP payload for redundant audio data," RFC 2198, Internet 397 Engineering Task Force, Sept. 1997. 399 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 400 Levels", RFC 2119, March 1997. 402 [5] ISO/IEC 10646-1: (1993), Universal Multiple Octet Coded Character 403 Set 405 [6] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 406 2279, Internet Engineering Task Force, Jan. 1998. 408 10. Revision history. 410 Oct 6 1999. draft-01. Explanations in recommended procedures 411 improved. 412 Oct 22 1999. draft-02. Nomenclature, ordering of redundant packets, 413 send empty info to expire redundancy. 414 Jan 13 2000. draft-03. Clarification after working group last call, 415 Clarify that timestamp is not used for 416 Sequencing. Improvements in clarity. 417 Feb 6 2000. draft-04. Four "SHALL" changed to "MUST" because they 418 was the intention. Two typos corrected.