idnits 2.17.1 draft-ietf-payload-tetra-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2019) is 1736 days in the past. Is this intentional? 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. 'BDBOS-BIP20' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-TETRA-Codec' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-TETRA-ISI' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 payload Reisenbauer 3 Internet-Draft Frequentis 4 Intended status: Standards Track Brandhuber 5 Expires: January 27, 2020 eurofunk 6 Hagedorn 7 Hagedorn 8 Hoehnsch 9 T-Systems 10 Wenk 11 Frequentis 12 July 26, 2019 14 RTP Payload Format for the TETRA Audio Codec 15 draft-ietf-payload-tetra-03 17 Abstract 19 This document specifies a Real-time Transport Protocol (RTP) payload 20 format for TETRA encoded speech signals. The payload format is 21 designed to be able to interoperate with existing TETRA transport 22 formats on non-IP networks. A media type registration is included, 23 specifying the use of the RTP payload format and the storage format. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 27, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 61 3. Media Format Background . . . . . . . . . . . . . . . . . . . 3 62 4. Payload format . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Payload layout . . . . . . . . . . . . . . . . . . . . . 4 65 4.3. Payload Header . . . . . . . . . . . . . . . . . . . . . 5 66 4.3.1. I bit: Frame Indicator . . . . . . . . . . . . . . . 5 67 4.3.2. F bit: Frame Type . . . . . . . . . . . . . . . . . . 6 68 4.3.3. CTRL: Control bit(5 bits) . . . . . . . . . . . . . . 6 69 4.3.4. C bit: Failed Crypto operation indication . . . . . . 6 70 4.3.5. FRAME_NR: FN (5 bits) . . . . . . . . . . . . . . . . 7 71 4.3.6. R: Audio Signal Relevance (3 bits) . . . . . . . . . 7 72 4.3.7. S: Spare (7 bits) . . . . . . . . . . . . . . . . . . 7 73 4.4. Payload Data . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Payload example . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Congestion Control Considerations . . . . . . . . . . . . . . 8 76 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 9 77 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 9 78 8. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 11 80 8.2. Declarative SDP Considerations . . . . . . . . . . . . . 11 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 11.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 This document specifies the payload format for packetization of 91 TErrestial Trunked RAdio (TETRA) encoded speech signals 92 [ETSI-TETRA-Codec] into the Real-time Transport Protocol (RTP) 93 [RFC3550]. The payload format supports transmission of multiple 94 frames per payload, robustness against packet loss, and 95 interoperation with existing TETRA transport formats on non-IP 96 networks, as described in Section Section 3. 98 The payload format itself is specified in Section Section 4. 100 2. Conventions Used In This Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119] when they 105 appear in ALL CAPS. These words may also appear in this document in 106 lower case as plain English words, absent their normative meanings. 108 The following acronyms are used in this document: 110 o ETSI: European Telecommunications Standards Institute 111 o TETRA: TErrestial Trunked RAdio 113 The byte order used in this document is network byte order, i.e., the 114 most significant byte first. The bit order is also the most 115 significant bit first. This is presented in all figures as having 116 the most significant bit leftmost on a line and with the lowest 117 number. Some bit fields may wrap over multiple lines in which cases 118 the bits on the first line are more significant than the bits on the 119 next line. 121 Best current practices for writing an RTP payload format 122 specification were followed [RFC2736] updated with [RFC8088]. 124 3. Media Format Background 126 The TETRA codec is used as vocoder for TETRA systems. The TETRA 127 codec is designed for compressing 30ms of audio speech data into 137 128 bits. The TETRA codec is designed in such a way that on the air 129 interface two of these 30ms samples are transported together (sub- 130 block 1 and sub-block 2). The codec allows that data of the first 131 30ms voice frame can be stolen and used for other purposes, e.g. for 132 the exchange of dynamically updated key-material in end-to-end 133 encrypted voice sessions. Codec payload serialisation is specified 134 for TDM lines with 2048 kBit/s within traditional circuit mode based 135 TETRA system. For this purpose two optional formats are defined 136 [ETSI-TETRA-Codec], the first format is called FSTE (First Speech 137 Transport Encoding Format), the other format is called OSTE 138 (Optimized Speech Transport Encoding Format). These two formats 139 differ mainly insofar that the OSTE format transports an additional 5 140 bit frame number, which provides timing information from the air 141 interface to the receiving side in order to save the need for 142 buffering due to different transports speed on air and in 64 kbit/s 143 circuit switched networks. The RTP payload format is defined such 144 that the value of this frame number can be transported. 146 4. Payload format 148 The RTP payload format is designed in such a way that it can carry 149 the information needed to map the audio and control payload from 150 [ETSI-TETRA-ISI]. The RTP format is defined such that both of the 151 independent sub-blocks can be transferred separately or together 152 within one RTP packet. Both of them contain the same information in 153 terms of control bits - the information is propagated redundantly. 154 This redundancy is driven by on one hand to simplify the encoding 155 process in direction from E1 to RTP on the other to provide the 156 option to go for either 30ms or 60ms packet size. The redundant 157 information SHALL be propagated consistently equal - otherwise the 158 behavior of the receiver is unspecified. The payload format is 159 chosen such that the TETRA data bits are octet aligned. 161 4.1. RTP Header Usage 163 The format of the RTP header is specified in [RFC3550]. The use of 164 the fields of the RTP header by the TETRA payload format is 165 consistent with that specification. 167 The payload length of TETRA is an integer number of octets; 168 therefore, no padding is necessary. 170 The timestamp, sequence number, and marker bit (M) of the RTP header 171 are used in accordance with Section 4.1 of [RFC3551]. 173 The RTP payload type for Tetra is to be assigned dynamically. 175 4.2. Payload layout 177 RTP payload is composed of multiple blocks with TETRA audio data. 178 TETRA Audio data itself contains: - Audio Payload Header - Audio Data 179 (137 Bit) - 7 Spare Bits 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |I|F| CTRL |C|FRAME_NR | R |D(1) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | D(137)| S | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 RTP payload can be formed by any integer multiple of 30ms audio using 196 following layout (e.g. 90ms audio payload): 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |I|F| CTRL |C|FRAME_NR | R |D(1) | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | D(137)| S | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 |I|F| CTRL |C|FRAME_NR | R |D(1) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | D(137)| S | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 |I|F| CTRL |C|FRAME_NR | R |D(1) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | D(137)| S | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 4.3. Payload Header 234 4.3.1. I bit: Frame Indicator 236 1: The following frame contains a first block of two sub-blocks 238 0: The following frame contains a separated sub-block. A sub-block 239 marked as such could either be a second sub-block, or an independent 240 block, which does not have a relation with any first block. To 241 distinguish between the one and the other the information of the 242 Control bits has to be evaluated. 244 4.3.2. F bit: Frame Type 246 +-------+-------------------+ 247 | Value | Frame contains | 248 +-------+-------------------+ 249 | 0 | FSTE encoded data | 250 | 1 | OSTE encoded data | 251 +-------+-------------------+ 253 4.3.3. CTRL: Control bit(5 bits) 255 Ctrl 1..3 derived from the information propagated according table 5.7 256 of [ETSI-TETRA-ISI]. 258 +-------+---------------+-------------+ 259 | Value | Sub block 1 | Sub block 2 | 260 +-------+---------------+-------------+ 261 | 000 | normal | normal | 262 | 001 | C stolen | normal | 263 | 010 | U stolen | normal | 264 | 011 | C stolen | C stolen | 265 | 100 | C stolen | U stolen | 266 | 101 | U stolen | C stolen | 267 | 110 | U stolen | U stolen | 268 | 111 | O&M ISI block | | 269 +-------+---------------+-------------+ 271 Ctrl 4..5 derived from the information propagated according table 5.7 272 of [ETSI-TETRA-ISI]. 274 +-------+------------------------+------------------------+ 275 | Value | Sub block 1 | Sub block 2 | 276 +-------+------------------------+------------------------+ 277 | 00 | no bad frame indicator | no bad frame indicator | 278 | 01 | no bad frame indicator | bad frame indicator(s) | 279 | 10 | bad frame indicator(s) | no bad frame indicator | 280 | 11 | bad frame indicator(s) | bad frame indicator(s) | 281 +-------+------------------------+------------------------+ 283 NOTE: The interpretation of C4 and C5 is outside the scope of the 284 present document 286 4.3.4. C bit: Failed Crypto operation indication 288 This bit may be set to "1" if a decryption (encrypted audio along the 289 circuit switched mobile network, decryption at the RTP sender 290 forwarding this audio) operation could not be performed successfully 291 for the specific half-block. Consequently, the encryption status of 292 the half-block audio data is unknown. Implementation of an RTP 293 receiver has to take into account "C bit" when forwarding such TETRA 294 audio data (either to a decoder directly or via TETRA infrastructure 295 to a TETRA mobile unit), the contained audio might be scrambled - 296 depending if the audio originally was generated as a plain-override 297 half-block or as an encrypted half-block. 299 4.3.5. FRAME_NR: FN (5 bits) 301 The frame number bits contain an uplink frame number as defined in 302 table 5.3 of [ETSI-TETRA-ISI]. If no frame number is available the 303 FRAME_NR value SHALL be set to 00000. 305 4.3.6. R: Audio Signal Relevance (3 bits) 307 The Audio Signal Relevance bits contain information about the 308 Relevance of the voice packet contained here. 310 R 1 312 0: no audio signal relevance propagated (R2 and R3 do not contain any 313 valid information) 315 1: audio signal relevance propagated in R2 and R3 317 R 2..3 According to table 1 of [BDBOS-BIP20] 319 +-------+-----------------------------------------------------------+ 320 | value | relevance | 321 +-------+-----------------------------------------------------------+ 322 | 00 | no audio signal relevance (level ? -72 dBm0) | 323 | 01 | low audio signal relevance (-52dBm0 ? level > -72dBm0) | 324 | 10 | medium audio signal relevance (-32dBm0 ? level > -52dBm0) | 325 | 11 | high audio signal relevance (0dBm0 ? level > -32dBm0) | 326 +-------+-----------------------------------------------------------+ 328 NOTE: Receiver SHOULD consider stolen or erroneous blocks as not 329 available for audio decoding as indicated by control bits independent 330 of audio signal relevance bits. 332 4.3.7. S: Spare (7 bits) 334 The S bits bits are reserved for future use and set to "0" currently. 336 4.4. Payload Data 338 The payload itself contains TETRA ACELP coded speech information 339 encoded according to table 4 of [ETSI-TETRA-Codec]. 341 5. Payload example 343 The following example shows how a first and a second consecutive 30 344 ms frame is combined into a single 60ms RTP packet. Note: This 345 example shows the usage of OSTE mapping. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 |1|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | D(137)| S | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |0|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | D(137)| S | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Both halves of information contain exact the same CTRL bits 373 6. Congestion Control Considerations 375 Tetra uses a fixed bitrate which cannot be adjusted at all. 377 Since UDP does not provide congestion control, applications that use 378 RTP over UDP SHOULD implement their own congestion control above the 379 UDP layer RFC8085 [RFC8085] and MAY also implement a transport 380 circuit breaker RFC8083 [RFC8083]. Work in the RMCAT working group 381 [RMCAT] describes the interactions and conceptual interfaces 382 necessary between the application components that relate to 383 congestion control, including the RTP layer, the higher-level media 384 codec control layer, and the lower-level transport interface, as well 385 as components dedicated to congestion control functions. 387 Congestion control for RTP SHALL be used in accordance with RFC 3550 388 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 389 [RFC3551]. An additional requirement if best-effort service is being 390 used is: users of this payload format MUST monitor packet loss to 391 ensure that the packet loss rate is within acceptable parameters. 393 7. Payload Format Parameters 395 This RTP payload format is identified using one media subtype (audio/ 396 TETRA) which is registered in accordance with RFC 4855 [RFC4855] and 397 per media type registration template from RFC 6838 [RFC6838]. 399 7.1. Media Type Definition 401 The media type for the TETRA codec is expected to be allocated from 402 the IETF tree once this draft turns into an RFC. This media type 403 registration covers both real-time transfer via RTP and non-real-time 404 transfers via stored files. 406 Type name: 407 audio 408 Subtype name: 409 TETRA 410 Required parameters: 411 none 412 Optional parameters: 413 These parameters apply to RTP transfer only. 415 * maxptime: The maximum amount of media which can be encapsulated 416 in a payload packet, expressed as time in milliseconds. The 417 time is calculated as the sum of the time that the media 418 present in the packet represents. The time SHOULD be an 419 integer multiple of the frame size. If this parameter is not 420 present, the sender MAY encapsulate any number of speech frames 421 into one RTP packet. 422 * ptime: see RFC 4566 [RFC4566]. 423 Encoding considerations: 424 This media type is framed and binary according Section 4.8 of RFC 425 6838 [RFC6838]. 426 Security considerations: 427 See Section Section 10 of RFC XXXX. [RFC Editor: Upon publication 428 as an RFC, please replace "XXXX" with the number assigned to this 429 document and remove this note.] 431 Interoperability considerations: N/A 432 Published specification: 433 RFC XXXX [RFC Editor: Upon publication as an RFC, please replace 434 "XXXX" with the number assigned to this document and remove this 435 note.] 436 Applications that use this media type: 437 This media type is used in applications needing transport or 438 storage of encoded voice. Some examples include; Voice over IP, 439 streaming media, voice messaging, and voice recording on recording 440 systems. 442 Additional Information: 444 - Deprecated alias names for this type: N/A 445 - Magic number(s): N/A 446 - File extension(s): N/A 447 - Macintosh file type code(s): N/A 449 Person & email address to contact for further information: 450 Andreas Reisenbauer 451 IETF Payload Working Group 452 Intended usage: 453 COMMON 454 Restrictions on usage: 455 This media subtype depends on RTP framing and hence is only 456 defined for transfer via RTP RFC 3550 [RFC3550]. Transport within 457 other framing protocols is not defined at this time. 458 Author: 459 Andreas Reisenbauer 460 Change controller: 461 The IETF PAYLOAD Working Group, or other party as designated by 462 the IESG. 464 8. Mapping to SDP 466 The information carried in the media type specification has a 467 specific mapping to fields in the Session Description Protocol 468 [RFC4566], which is commonly used to describe RTP sessions. When SDP 469 is used to specify sessions employing the TETRA codec, the mapping is 470 as follows: 472 Media Type name: 473 audio 474 Media subtype name: 475 TETRA 476 Required parameters: 477 none 478 Optional parameters: 479 none 481 Mapping Parameters into SDP 482 The information carried in the media type specification has a 483 specific mapping to fields in the Session Description Protocol 484 [RFC4566], which is commonly used to describe RTP sessions. When 485 SDP is used to specify sessions employing the TETRA codec, the 486 mapping is as follows: 488 * The media type ("audio") goes in SDP "m=" as the media name. 489 * The media subtype (payload format name) goes in SDP "a=rtpmap" 490 as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 491 8000. 492 * The parameters "ptime" and "maxptime" go in the SDP "a=ptime" 493 and "a=maxptime" attributes, respectively. 494 * Any remaining parameters go in the SDP "a=fmtp" attribute by 495 copying them directly from the media type parameter string as a 496 semicolon-separated list of parameter=value pairs. 498 Here is an example SDP session of usage of TETRA: 500 m=audio 49120 RTP/AVP 99 501 a=rtpmap:99 TETRA/8000 502 a=maxptime:60 503 a=ptime:60 505 8.1. Offer/Answer Considerations 507 The following considerations apply when using SDP Offer-Answer 508 procedures to negotiate the use of TETRA payload in RTP: 510 o In most cases, the parameters "maxptime" and "ptime" will not 511 affect interoperability; however, the setting of the parameters 512 can affect the performance of the application. The SDP offer- 513 answer handling of the "ptime" and "maxptime" parameter is 514 described in RFC3264 [RFC3264]. 515 o Integer multiples of 30ms SHALL be used for ptime. It is 516 recommended to use packet size of 60ms. There is no need that 517 ptime and maxptime parameters are negotiated symmetrically. 518 o Any unknown parameter in an offer SHALL be removed in the answer. 520 8.2. Declarative SDP Considerations 522 For declarative media, the "ptime" and "maxptime" parameter specify 523 the possible variants used by the sender. 525 9. IANA Considerations 527 This memo requests that IANA registers [audio/TETRA] from section 528 Section 7.1. The media type is also requested to be added to the 529 IANA registry for "RTP Payload Format MIME types" 530 (). 532 10. Security Considerations 534 RTP packets using the payload format defined in this specification 535 are subject to the security considerations discussed in the RTP 536 specification [RFC3550] , and in any applicable RTP profile. The 537 main security considerations for the RTP packet carrying the RTP 538 payload format defined within this memo are confidentiality, 539 integrity and source authenticity. Confidentiality is achieved by 540 encryption of the RTP payload. Integrity of the RTP packets through 541 suitable cryptographic integrity protection mechanism. Cryptographic 542 systems may also allow the authentication of the source of the 543 payload. A suitable security mechanism for this RTP payload format 544 should provide confidentiality, integrity protection and at least 545 source authentication capable of determining if an RTP packet is from 546 a member of the RTP session or not. 548 Note that the appropriate mechanism to provide security to RTP and 549 payloads following this memo may vary. It is dependent on the 550 application, the transport, and the signaling protocol employed. 551 Therefore a single mechanism is not sufficient, although if suitable 552 the usage of SRTP [RFC3711] is recommended. Other mechanism that may 553 be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but 554 also other alternatives may exist. 556 11. References 558 11.1. Normative References 560 [BDBOS-BIP20] 561 BDBOS, "BIP 20 QOS Dienstguete-Parameter BOS- 562 Interoperabilitaetsprofil fuer Endgeraete zur Nutzung im 563 Digitalfunk BOS; Version 2014-04 - Revision 2", 2014. 565 [ETSI-TETRA-Codec] 566 ETSI, "EN 300 395-2; Terrestrial Trunked Radio (TETRA); 567 Speech codec for full-rate traffic channel; Part 2: TETRA 568 codec V1.3.1", 2005, . 572 [ETSI-TETRA-ISI] 573 ETSI, "TS 100 392-3-8; Terrestrial Trunked Radio (TETRA); 574 Voice plus Data (V+D); Part 3: Interworking at the Inter- 575 System Interface (ISI); Sub-part 8: Generic Speech Format 576 Implementation V1.3.1", 2018, 577 . 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, 583 DOI 10.17487/RFC2119, March 1997, 584 . 586 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 587 Jacobson, "RTP: A Transport Protocol for Real-Time 588 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 589 July 2003, . 591 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 592 Video Conferences with Minimal Control", STD 65, RFC 3551, 593 DOI 10.17487/RFC3551, July 2003, 594 . 596 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 597 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 598 July 2006, . 600 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 601 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 602 DOI 10.17487/RFC8083, March 2017, 603 . 605 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 606 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 607 March 2017, . 609 11.2. Informative References 611 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 612 Payload Format Specifications", BCP 36, RFC 2736, 613 DOI 10.17487/RFC2736, December 1999, 614 . 616 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 617 with Session Description Protocol (SDP)", RFC 3264, 618 DOI 10.17487/RFC3264, June 2002, 619 . 621 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 622 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 623 RFC 3711, DOI 10.17487/RFC3711, March 2004, 624 . 626 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 627 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 628 December 2005, . 630 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 631 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 632 . 634 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 635 (TLS) Protocol Version 1.2", RFC 5246, 636 DOI 10.17487/RFC5246, August 2008, 637 . 639 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 640 Specifications and Registration Procedures", BCP 13, 641 RFC 6838, DOI 10.17487/RFC6838, January 2013, 642 . 644 [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", 645 RFC 8088, DOI 10.17487/RFC8088, May 2017, 646 . 648 [RMCAT] IETF, "RTP Media Congestion Avoidance Techniques (rmcat) 649 Working Grooup", 2018, 650 . 652 Authors' Addresses 654 Andreas Reisenbauer 655 Frequentis AG 656 Innovationsstr. 1 657 Vienna 1100 658 Austria 660 Email: andreas.reisenbauer@frequentis.com 662 Udo Brandhuber 663 eurofunk Kappacher GmbH 664 Germany 666 Email: ubrandhuber@eurofunk.com 667 Joachim Hagedorn 668 Hagedorn Informationssysteme GmbH 669 Germany 671 Email: joachim@hagedorn-infosysteme.de 673 Klaus-Peter Hoehnsch 674 T-Systems International GmbH 675 Germany 677 Email: klaus-peter.hoehnsch@t-systems.com 679 Stefan Wenk 680 Frequentis AG 681 Innovationsstr. 1 682 Vienna 1100 683 Austria 685 Email: stefan.wenk@frequentis.com