idnits 2.17.1 draft-ietf-payload-tetra-02.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 (January 23, 2019) is 1921 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: July 27, 2019 eurofunk 6 Hagedorn 7 Hagedorn 8 Hoehnsch 9 T-Systems 10 Wenk 11 Frequentis 12 January 23, 2019 14 RTP Payload Format for the TETRA Audio Codec 15 draft-ietf-payload-tetra-02 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 July 27, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 11 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 FSTE and OSTE format 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 according table 2 of [ETSI-TETRA-ISI]. 257 +-------+---------------+-------------+ 258 | Value | Sub block 1 | Sub block 2 | 259 +-------+---------------+-------------+ 260 | 000 | normal | normal | 261 | 001 | C stolen | normal | 262 | 010 | U stolen | normal | 263 | 011 | C stolen | C stolen | 264 | 100 | C stolen | U stolen | 265 | 101 | U stolen | C stolen | 266 | 110 | U stolen | U stolen | 267 | 111 | O&M ISI block | | 268 +-------+---------------+-------------+ 270 Ctrl 4..5 according table 3 of [ETSI-TETRA-ISI]. 272 +-------+-------------------+-------------------+ 273 | Value | Sub block 1 | Sub block 2 | 274 +-------+-------------------+-------------------+ 275 | 00 | BFI no errors | BFI no errors | 276 | 01 | BFI no errors | BFI with error(s) | 277 | 10 | BFI with error(s) | BFI no error(s) | 278 | 11 | BFI with error(s) | BFI with error(s) | 279 +-------+-------------------+-------------------+ 281 NOTE: The meaning of C4 and C5 is outside the scope of the present 282 document 284 4.3.4. C bit: Failed Crypto operation indication 286 This bit may be set to "1" if a decryption (encrypted audio along the 287 circuit switched mobile network, decryption at the RTP sender 288 forwarding this audio) operation could not be performed successfully 289 for the specific half-block. Consequently, the encryption status of 290 the half-block audio data is unknown. Implementation of an RTP 291 receiver has to take into account "C bit" when forwarding such TETRA 292 audio data (either to a decoder directly or via TETRA infrastructure 293 to a TETRA mobile unit), the contained audio might be scrambled - 294 depending if the audio originally was generated as a plain-override 295 half-block or as an encrypted half-block. 297 4.3.5. FRAME_NR: FN (5 bits) 299 The frame number bits contain an uplink frame number as defined in 300 table 8 of [ETSI-TETRA-ISI]. If no frame number is available the 301 FRAME_NR value SHALL be set to 00000. 303 4.3.6. R: Audio Signal Relevance (3 bits) 305 The Audio Signal Relevance bits contain information about the 306 Relevance of the voice packet contained here. 308 R 1 310 0: no audio signal relevance propagated (R2 and R3 do not contain any 311 valid information) 313 1: audio signal relevance propagated in R2 and R3 315 R 2..3 According to table 1 of [BDBOS-BIP20] 317 +-------+-----------------------------------------------------------+ 318 | value | relevance | 319 +-------+-----------------------------------------------------------+ 320 | 00 | no audio signal relevance (level ? -72 dBm0) | 321 | 01 | low audio signal relevance (-52dBm0 ? level > -72dBm0) | 322 | 10 | medium audio signal relevance (-32dBm0 ? level > -52dBm0) | 323 | 11 | high audio signal relevance (0dBm0 ? level > -32dBm0) | 324 +-------+-----------------------------------------------------------+ 326 NOTE: Receiver SHOULD consider stolen or erroneous blocks as not 327 available for audio decoding as indicated by control bits independent 328 of audio signal relevance bits. 330 4.3.7. S: Spare (7 bits) 332 The S bits bits are reserved for future use and set to "0" currently. 334 4.4. Payload Data 336 Reference [ETSI-TETRA-ISI] contains the definition for the generation 337 of the codec data. Data bits D1..D137 in chapter 8 correspond to the 338 "Bit number in speech frame" row of table 4 of [ETSI-TETRA-ISI]. 340 The payload itself contains TETRA ACELP coded speech information 341 encoded according to table 4 of [ETSI-TETRA-Codec]. 343 5. Payload example 345 The following example shows how a first and a second consecutive 30 346 ms frame is combined into a single 60ms RTP packet. Note: This 347 example shows the usage of OSTE mapping. 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |1|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | D(137)| S | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |0|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | D(137)| S | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Both halves of information contain exact the same CTRL bits 375 6. Congestion Control Considerations 377 Tetra uses a fixed bitrate which cannot be adjusted at all. 379 Since UDP does not provide congestion control, applications that use 380 RTP over UDP SHOULD implement their own congestion control above the 381 UDP layer RFC8085 [RFC8085] and MAY also implement a transport 382 circuit breaker RFC8083 [RFC8083]. Work in the RMCAT working group 383 [RMCAT] describes the interactions and conceptual interfaces 384 necessary between the application components that relate to 385 congestion control, including the RTP layer, the higher-level media 386 codec control layer, and the lower-level transport interface, as well 387 as components dedicated to congestion control functions. 389 Congestion control for RTP SHALL be used in accordance with RFC 3550 390 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 391 [RFC3551]. An additional requirement if best-effort service is being 392 used is: users of this payload format MUST monitor packet loss to 393 ensure that the packet loss rate is within acceptable parameters. 395 7. Payload Format Parameters 397 This RTP payload format is identified using one media subtype (audio/ 398 TETRA) which is registered in accordance with RFC 4855 [RFC4855] and 399 per media type registration template from RFC 6838 [RFC6838]. 401 7.1. Media Type Definition 403 The media type for the TETRA codec is expected to be allocated from 404 the IETF tree once this draft turns into an RFC. This media type 405 registration covers both real-time transfer via RTP and non-real-time 406 transfers via stored files. 408 Type name: 409 audio 410 Subtype name: 411 TETRA 412 Required parameters: 413 none 414 Optional parameters: 415 These parameters apply to RTP transfer only. 417 * maxptime: The maximum amount of media which can be encapsulated 418 in a payload packet, expressed as time in milliseconds. The 419 time is calculated as the sum of the time that the media 420 present in the packet represents. The time SHOULD be an 421 integer multiple of the frame size. If this parameter is not 422 present, the sender MAY encapsulate any number of speech frames 423 into one RTP packet. 424 * ptime: see RFC 4566 [RFC4566]. 425 Encoding considerations: 426 This media type is framed and binary according Section 4.8 of RFC 427 6838 [RFC6838]. 428 Security considerations: 429 See Section Section 10 of RFC XXXX. [RFC Editor: Upon publication 430 as an RFC, please replace "XXXX" with the number assigned to this 431 document and remove this note.] 433 Interoperability considerations: N/A 435 Published specification: 437 RFC XXXX [RFC Editor: Upon publication as an RFC, please replace 438 "XXXX" with the number assigned to this document and remove this 439 note.] 440 Applications that use this media type: 441 This media type is used in applications needing transport or 442 storage of encoded voice. Some examples include; Voice over IP, 443 streaming media, voice messaging, and voice recording on recording 444 systems. 446 Additional Information: 448 - Deprecated alias names for this type: N/A 449 - Magic number(s): N/A 450 - File extension(s): N/A 451 - Macintosh file type code(s): N/A 453 Person & email address to contact for further information: 454 Andreas Reisenbauer 455 IETF Payload Working Group 456 Intended usage: 457 COMMON 458 Restrictions on usage: 459 This media subtype depends on RTP framing and hence is only 460 defined for transfer via RTP RFC 3550 [RFC3550]. Transport within 461 other framing protocols is not defined at this time. 462 Author: 463 Andreas Reisenbauer 464 Change controller: 465 The IETF PAYLOAD Working Group, or other party as designated by 466 the IESG. 468 8. Mapping to SDP 470 The information carried in the media type specification has a 471 specific mapping to fields in the Session Description Protocol 472 [RFC4566], which is commonly used to describe RTP sessions. When SDP 473 is used to specify sessions employing the TETRA codec, the mapping is 474 as follows: 476 Media Type name: 477 audio 478 Media subtype name: 479 TETRA 480 Required parameters: 481 none 482 Optional parameters: 483 none 484 Mapping Parameters into SDP 485 The information carried in the media type specification has a 486 specific mapping to fields in the Session Description Protocol 487 [RFC4566], which is commonly used to describe RTP sessions. When 488 SDP is used to specify sessions employing the TETRA codec, the 489 mapping is as follows: 491 * The media type ("audio") goes in SDP "m=" as the media name. 492 * The media subtype (payload format name) goes in SDP "a=rtpmap" 493 as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 494 8000. 495 * The parameters "ptime" and "maxptime" go in the SDP "a=ptime" 496 and "a=maxptime" attributes, respectively. 497 * Any remaining parameters go in the SDP "a=fmtp" attribute by 498 copying them directly from the media type parameter string as a 499 semicolon-separated list of parameter=value pairs. 501 Here is an example SDP session of usage of TETRA: 503 m=audio 49120 RTP/AVP 99 504 a=rtpmap:99 TETRA/8000 505 a=maxptime:60 506 a=ptime:60 508 8.1. Offer/Answer Considerations 510 The following considerations apply when using SDP Offer-Answer 511 procedures to negotiate the use of TETRA payload in RTP: 513 o In most cases, the parameters "maxptime" and "ptime" will not 514 affect interoperability; however, the setting of the parameters 515 can affect the performance of the application. The SDP offer- 516 answer handling of the "ptime" and "maxptime" parameter is 517 described in RFC3264 [RFC3264]. 518 o Integer multiples of 30ms SHALL be used for ptime. It is 519 recommended to use packet size of 60ms. There is no need that 520 ptime and maxptime parameters are negotiated symmetrically. 521 o Any unknown parameter in an offer SHALL be removed in the answer. 523 8.2. Declarative SDP Considerations 525 For declarative media, the "ptime" and "maxptime" parameter specify 526 the possible variants used by the sender. 528 9. IANA Considerations 530 This memo requests that IANA registers [audio/TETRA] from section 531 Section 7.1. The media type is also requested to be added to the 532 IANA registry for "RTP Payload Format MIME types" 533 (). 535 10. Security Considerations 537 RTP packets using the payload format defined in this specification 538 are subject to the security considerations discussed in the RTP 539 specification [RFC3550] , and in any applicable RTP profile. The 540 main security considerations for the RTP packet carrying the RTP 541 payload format defined within this memo are confidentiality, 542 integrity and source authenticity. Confidentiality is achieved by 543 encryption of the RTP payload. Integrity of the RTP packets through 544 suitable cryptographic integrity protection mechanism. Cryptographic 545 systems may also allow the authentication of the source of the 546 payload. A suitable security mechanism for this RTP payload format 547 should provide confidentiality, integrity protection and at least 548 source authentication capable of determining if an RTP packet is from 549 a member of the RTP session or not. 551 Note that the appropriate mechanism to provide security to RTP and 552 payloads following this memo may vary. It is dependent on the 553 application, the transport, and the signaling protocol employed. 554 Therefore a single mechanism is not sufficient, although if suitable 555 the usage of SRTP [RFC3711] is recommended. Other mechanism that may 556 be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but 557 also other alternatives may exist. 559 11. References 561 11.1. Normative References 563 [BDBOS-BIP20] 564 Bundesanstalt fuer den Digitalfunk der Behoerden und 565 Organisationen mit Sicherheitsaufgaben, "BIP 20 QOS 566 Dienstguete-Parameter BOS-Interoperabilitaetsprofil fuer 567 Endgeraete zur Nutzung im Digitalfunk BOS; Version 2014-04 568 - Revision 2", 2014. 570 [ETSI-TETRA-Codec] 571 European Telecommunications Standards Institute, "EN 300 572 395-2; Terrestrial Trunked Radio (TETRA); Speech codec for 573 full-rate traffic channel; Part 2: TETRA codec V1.3.1", 574 2005, . 578 [ETSI-TETRA-ISI] 579 European Telecommunications Standards Institute, "TS 100 580 392-3-6; Terrestrial Trunked Radio (TETRA); Voice plus 581 Data (V+D); Part 3: Interworking at the Inter-System 582 Interface (ISI); Sub-part 6: Speech format implementation 583 for circuit mode transmission V1.1.1", 2003, 584 . 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, 590 DOI 10.17487/RFC2119, March 1997, 591 . 593 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 594 Jacobson, "RTP: A Transport Protocol for Real-Time 595 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 596 July 2003, . 598 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 599 Video Conferences with Minimal Control", STD 65, RFC 3551, 600 DOI 10.17487/RFC3551, July 2003, 601 . 603 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 604 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 605 July 2006, . 607 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 608 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 609 DOI 10.17487/RFC8083, March 2017, 610 . 612 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 613 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 614 March 2017, . 616 11.2. Informative References 618 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 619 Payload Format Specifications", BCP 36, RFC 2736, 620 DOI 10.17487/RFC2736, December 1999, 621 . 623 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 624 with Session Description Protocol (SDP)", RFC 3264, 625 DOI 10.17487/RFC3264, June 2002, 626 . 628 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 629 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 630 RFC 3711, DOI 10.17487/RFC3711, March 2004, 631 . 633 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 634 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 635 December 2005, . 637 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 638 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 639 . 641 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 642 (TLS) Protocol Version 1.2", RFC 5246, 643 DOI 10.17487/RFC5246, August 2008, 644 . 646 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 647 Specifications and Registration Procedures", BCP 13, 648 RFC 6838, DOI 10.17487/RFC6838, January 2013, 649 . 651 [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", 652 RFC 8088, DOI 10.17487/RFC8088, May 2017, 653 . 655 [RMCAT] RTP Media Congestion Avoidance Techniques (rmcat) Working 656 Group, "RTP Media Congestion Avoidance Techniques (rmcat) 657 Working Grooup", 2018, 658 . 660 Authors' Addresses 662 Andreas Reisenbauer 663 Frequentis AG 664 Innovationsstr. 1 665 Vienna 1100 666 Austria 668 Email: andreas.reisenbauer@frequentis.com 669 Udo Brandhuber 670 eurofunk Kappacher GmbH 671 Germany 673 Email: ubrandhuber@eurofunk.com 675 Joachim Hagedorn 676 Hagedorn Informationssysteme GmbH 677 Germany 679 Email: joachim@hagedorn-infosysteme.de 681 Klaus-Peter Hoehnsch 682 T-Systems International GmbH 683 Germany 685 Email: klaus-peter.hoehnsch@t-systems.com 687 Stefan Wenk 688 Frequentis AG 689 Innovationsstr. 1 690 Vienna 1100 691 Austria 693 Email: stefan.wenk@frequentis.com