idnits 2.17.1 draft-ietf-payload-tetra-00.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 (April 22, 2018) is 2188 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: October 24, 2018 eurofunk 6 Hagedorn 7 Hagedorn 8 Hoehnsch 9 T-Systems 10 Wenk 11 Frequentis 12 April 22, 2018 14 RTP Payload Format for the TETRA Audio Codec 15 draft-ietf-payload-tetra-00 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 October 24, 2018. 42 Copyright Notice 44 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . 5 68 4.3.3. CTRL: Control bit(5 bits) . . . . . . . . . . . . . . 5 69 4.3.4. C bit: Failed Crypto operation indication . . . . . . 6 70 4.3.5. FRAME_NR: FN (5 bits) . . . . . . . . . . . . . . . . 6 71 4.3.6. R: Audio Signal Relevance (3 bits) . . . . . . . . . 6 72 4.3.7. S: Spare (7 bits) . . . . . . . . . . . . . . . . . . 7 73 4.4. Payload Data . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Payload example . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Congestion Control Considerations . . . . . . . . . . . . . . 8 76 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8 77 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8 78 8. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 10 80 8.2. Declarative SDP Considerations . . . . . . . . . . . . . 10 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 11.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 channels, multiple frames per payload, robustness against packet 95 loss, and interoperation with existing TETRA transport formats on 96 non-IP 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 theses 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 within the 134 traditional circuit mode based TETRA system is specified for TDM 135 lines with 2048 kBit/s. For this purpose two optional formats are 136 defined [ETSI-TETRA-Codec], the first format is called FSTE (First 137 Speech Transport Encoding Format), the other format is called OSTE 138 (Optimized Speech Transport Encoding Format). These two formats 139 defer 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 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |I|F| CTRL |C|FRAME_NR | R |D(1) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | D(137)| S | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 4.3. Payload Header 193 4.3.1. I bit: Frame Indicator 195 1: The following frame contains a first block of two sub-blocks 197 0: The following frame contains a separated sub-block. A sub-block 198 marked as such could either be a second sub-block, or an independent 199 block, which does not have a relation with any first block. To 200 distinguish between the one and the other the information of the 201 Control bits has to be evaluated. 203 4.3.2. F bit: Frame Type 205 +-------+-------------------+ 206 | Value | Frame contains | 207 +-------+-------------------+ 208 | 0 | FSTE encoded data | 209 | 1 | OSTE encoded data | 210 +-------+-------------------+ 212 4.3.3. CTRL: Control bit(5 bits) 214 Ctrl 1..3 according table 2 of [ETSI-TETRA-ISI]. 216 +-------+---------------+-------------+ 217 | Value | Sub block 1 | Sub block 2 | 218 +-------+---------------+-------------+ 219 | 000 | normal | normal | 220 | 001 | C stolen | normal | 221 | 010 | U stolen | normal | 222 | 011 | C stolen | C stolen | 223 | 100 | C stolen | U stolen | 224 | 101 | U stolen | C stolen | 225 | 110 | U stolen | U stolen | 226 | 111 | O&M ISI block | | 227 +-------+---------------+-------------+ 229 Ctrl 4..5 according table 3 of [ETSI-TETRA-ISI]. 231 +-------+-------------------+-------------------+ 232 | Value | Sub block 1 | Sub block 2 | 233 +-------+-------------------+-------------------+ 234 | 00 | BFI no errors | BFI no errors | 235 | 01 | BFI no errors | BFI with error(s) | 236 | 10 | BFI with error(s) | BFI no error(s) | 237 | 11 | BFI with error(s) | BFI with error(s) | 238 +-------+-------------------+-------------------+ 240 NOTE: The meaning of C4 and C5 is outside the scope of the present 242 4.3.4. C bit: Failed Crypto operation indication 244 This bit may be set to "1" if a decryption (encrypted audio along the 245 circuit switched mobile network, decryption at the RTP sender 246 forwarding this audio) operation could not be performed successfully 247 for the specific half-block. Consequently, the encryption status of 248 the half-block audio data is unknown. Implementation of an RTP 249 receiver has to take into account "C bit" when forwarding such TETRA 250 audio data (either to a decoder directly or via TETRA infrastructure 251 to a TETRA mobile unit), the contained audio might be scrambled - 252 depending if the audio originally was generated as a plain-override 253 half-block or as an encrypted half-block. 255 4.3.5. FRAME_NR: FN (5 bits) 257 Those bits contain an uplink frame number as defined in table 8 of 258 [ETSI-TETRA-ISI]. If no frame number is available the FRAME_NR value 259 SHALL be set to 00000. 261 4.3.6. R: Audio Signal Relevance (3 bits) 263 The Audio Signal Relevance bits contain information about the 264 Relevance of the voice packet contained here. 266 R 1 268 0: no audio signal relevance propagated (R2 and R3 do not contain any 269 valid information) 271 1: audio signal relevance propagated in R2 and R3 273 R 2..3 According to table 1 of [BDBOS-BIP20] 275 +-------+-----------------------------------------------------------+ 276 | value | relevance | 277 +-------+-----------------------------------------------------------+ 278 | 00 | no audio signal relevance (level ? -72 dBm0) | 279 | 01 | low audio signal relevance (-52dBm0 ? level > -72dBm0) | 280 | 10 | medium audio signal relevance (-32dBm0 ? level > -52dBm0) | 281 | 11 | high audio signal relevance (0dBm0 ? level > -32dBm0) | 282 +-------+-----------------------------------------------------------+ 284 4.3.7. S: Spare (7 bits) 286 Those bits are reserved for future use and set to "0" currently. 288 4.4. Payload Data 290 Reference [ETSI-TETRA-ISI] contains the definition for the generation 291 of the codec data. Data bits D1..D137 in chapter 8 correspond to the 292 "Bit number in speech frame" row of table 4 of [ETSI-TETRA-ISI]. 294 The payload itself contains TETRA ACELP coded speech information 295 encoded according to table 4 of [ETSI-TETRA-Codec]. 297 5. Payload example 299 The following example shows how a first and a consecutive 30 ms frame 300 is combined into a single 60ms RTP packet. Note: This example shows 301 of usage of OSTE mapping. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |1|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | D(137)| S | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |0|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | D(137)| S | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Both halves of information contain exact the same CTRL bits 329 6. Congestion Control Considerations 331 Tetra uses a fixed bitrate which cannot be adjusted at all. 333 Since UDP does not provide congestion control, applications that use 334 RTP over UDP SHOULD implement their own congestion control above the 335 UDP layer RFC8085 [RFC8085] and MAY also implement a transport 336 circuit breaker RFC8083 [RFC8083]. Work in the RMCAT working group 337 [RMCAT] describes the interactions and conceptual interfaces 338 necessary between the application components that relate to 339 congestion control, including the RTP layer, the higher-level media 340 codec control layer, and the lower-level transport interface, as well 341 as components dedicated to congestion control functions. 343 Congestion control for RTP SHALL be used in accordance with RFC 3550 344 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 345 [RFC3551]. An additional requirement if best-effort service is being 346 used is: users of this payload format MUST monitor packet loss to 347 ensure that the packet loss rate is within acceptable parameters. 349 7. Payload Format Parameters 351 This RTP payload format is identified using one media subtype (audio/ 352 TETRA) which is registered in accordance with RFC 4855 [RFC4855] and 353 per media type registration template from RFC 6838 [RFC6838]. 355 7.1. Media Type Definition 357 The media type for the TETRA codec is expected to be allocated from 358 the IETF tree once this draft turns into an RFC. This media type 359 registration covers both real-time transfer via RTP and non-real-time 360 transfers via stored files. 362 Media Type name: 363 audio 364 Media Subtype name: 365 TETRA 366 Required parameters: 367 none 369 Optional parameters: 371 These parameters apply to RTP transfer only. 373 maxptime: 374 The maximum amount of media which can be encapsulated in a payload 375 packet, expressed as time in milliseconds. The time is calculated 376 as the sum of the time that the media present in the packet 377 represents. The time SHOULD be an integer multiple of the frame 378 size. If this parameter is not present, the sender MAY 379 encapsulate any number of speech frames into one RTP packet. 380 ptime: 381 see RFC 4566 [RFC4566]. 382 Security considerations: 383 See Section Section 10 of RFC XXXX. [RFC Editor: Upon publication 384 as an RFC, please replace "XXXX" with the number assigned to this 385 document and remove this note.] 387 Interoperability considerations: 389 Published specification: 391 Applications that use this media type: 393 This media type is used in applications needing transport or storage 394 of encoded voice. Some examples include; Voice over IP, streaming 395 media, voice messaging, and voice recording on recording systems. 397 Intended usage: 398 COMMON 400 8. Mapping to SDP 402 The information carried in the media type specification has a 403 specific mapping to fields in the Session Description Protocol 404 [RFC4566], which is commonly used to describe RTP sessions. When SDP 405 is used to specify sessions employing the TETRA codec, the mapping is 406 as follows: 408 Media Type name: 409 audio 410 Media subtype name: 411 TETRA 412 Required parameters: 413 none 414 Optional parameters: 415 none 416 Mapping Parameters into SDP 417 The information carried in the media type specification has a 418 specific mapping to fields in the Session Description Protocol 419 [RFC4566], which is commonly used to describe RTP sessions. When 420 SDP is used to specify sessions employing the TETRA codec, the 421 mapping is as follows: 423 * The media type ("audio") goes in SDP "m=" as the media name. 425 * The media subtype (payload format name) goes in SDP "a=rtpmap" 426 as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 427 8000. 428 * The parameters "ptime" and "maxptime" go in the SDP "a=ptime" 429 and "a=maxptime" attributes, respectively. 430 * Any remaining parameters go in the SDP "a=fmtp" attribute by 431 copying them directly from the media type parameter string as a 432 semicolon-separated list of parameter=value pairs. 434 Here is an example SDP session of usage of TETRA: 436 m=audio 49120 RTP/AVP 99 437 a=rtpmap:99 TETRA/8000 438 a=maxptime:60 439 a=ptime:60 441 8.1. Offer/Answer Considerations 443 The following considerations apply when using SDP Offer-Answer 444 procedures to negotiate the use of TETRA payload in RTP: 446 o In most cases, the parameters "maxptime" and "ptime" will not 447 affect interoperability; however, the setting of the parameters 448 can affect the performance of the application. The SDP offer- 449 answer handling of the "ptime" and "maxptime" parameter is 450 described in RFC3264 [RFC3264]. 451 o Integer multiples of 30ms SHALL be used for ptime. It is 452 recommended to use packet size of 60ms. Even if there is no good 453 reason why not doing so, there is no need that ptime and maxptime 454 parameters are negotiated symmetrically. 455 o Any unknown parameter in an offer SHALL be removed in the answer. 457 8.2. Declarative SDP Considerations 459 For declarative media, the "ptime" and "maxptime" parameter specifies 460 the possible variants used by the sender. 462 9. IANA Considerations 464 This memo requests that IANA registers [audio/TETRA] from section 465 Section 7.1. The media type is also requested to be added to the 466 IANA registry for "RTP Payload Format MIME types" 467 (). 469 10. Security Considerations 471 RTP packets using the payload format defined in this specification 472 are subject to the security considerations discussed in the RTP 473 specification [RFC3550] , and in any applicable RTP profile. The 474 main security considerations for the RTP packet carrying the RTP 475 payload format defined within this memo are confidentiality, 476 integrity and source authenticity. Confidentiality is achieved by 477 encryption of the RTP payload. Integrity of the RTP packets through 478 suitable cryptographic integrity protection mechanism. Cryptographic 479 systems may also allow the authentication of the source of the 480 payload. A suitable security mechanism for this RTP payload format 481 should provide confidentiality, integrity protection and at least 482 source authentication capable of determining if an RTP packet is from 483 a member of the RTP session or not. 485 Note that the appropriate mechanism to provide security to RTP and 486 payloads following this memo may vary. It is dependent on the 487 application, the transport, and the signaling protocol employed. 488 Therefore a single mechanism is not sufficient, although if suitable 489 the usage of SRTP [RFC3711] is recommended. Other mechanism that may 490 be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but 491 also other alternatives may exist. 493 11. References 495 11.1. Normative References 497 [BDBOS-BIP20] 498 Bundesanstalt fuer den Digitalfunk der Behoerden und 499 Organisationen mit Sicherheitsaufgaben, "BIP 20 QOS 500 Dienstguete-Parameter BOS-Interoperabilitaetsprofil fuer 501 Endgeraete zur Nutzung im Digitalfunk BOS; Version 2014-04 502 - Revision 2", 2014. 504 [ETSI-TETRA-Codec] 505 European Telecommunications Standards Institute, "EN 300 506 395-2; Terrestrial Trunked Radio (TETRA); Speech codec for 507 full-rate traffic channel; Part 2: TETRA codec V1.3.1", 508 2005, . 512 [ETSI-TETRA-ISI] 513 European Telecommunications Standards Institute, "TS 100 514 392-3-6; Terrestrial Trunked Radio (TETRA); Voice plus 515 Data (V+D); Part 3: Interworking at the Inter-System 516 Interface (ISI); Sub-part 6: Speech format implementation 517 for circuit mode transmission V1.1.1", 2003, 518 . 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, 524 DOI 10.17487/RFC2119, March 1997, 525 . 527 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 528 Jacobson, "RTP: A Transport Protocol for Real-Time 529 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 530 July 2003, . 532 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 533 Video Conferences with Minimal Control", STD 65, RFC 3551, 534 DOI 10.17487/RFC3551, July 2003, 535 . 537 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 538 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 539 July 2006, . 541 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 542 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 543 DOI 10.17487/RFC8083, March 2017, 544 . 546 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 547 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 548 March 2017, . 550 11.2. Informative References 552 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 553 Payload Format Specifications", BCP 36, RFC 2736, 554 DOI 10.17487/RFC2736, December 1999, 555 . 557 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 558 with Session Description Protocol (SDP)", RFC 3264, 559 DOI 10.17487/RFC3264, June 2002, 560 . 562 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 563 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 564 RFC 3711, DOI 10.17487/RFC3711, March 2004, 565 . 567 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 568 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 569 December 2005, . 571 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 572 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 573 . 575 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 576 (TLS) Protocol Version 1.2", RFC 5246, 577 DOI 10.17487/RFC5246, August 2008, 578 . 580 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 581 Specifications and Registration Procedures", BCP 13, 582 RFC 6838, DOI 10.17487/RFC6838, January 2013, 583 . 585 [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", 586 RFC 8088, DOI 10.17487/RFC8088, May 2017, 587 . 589 [RMCAT] RTP Media Congestion Avoidance Techniques (rmcat) Working 590 Group, "RTP Media Congestion Avoidance Techniques (rmcat) 591 Working Grooup", 2018, 592 . 594 Authors' Addresses 596 Andreas Reisenbauer 597 Frequentis AG 598 Innovationsstr. 1 599 Vienna 1100 600 Austria 602 Email: andreas.reisenbauer@frequentis.com 603 Udo Brandhuber 604 eurofunk Kappacher GmbH 605 Germany 607 Email: ubrandhuber@eurofunk.com 609 Joachim Hagedorn 610 Hagedorn Informationssysteme GmbH 611 Germany 613 Email: joachim@hagedorn-infosysteme.de 615 Klaus-Peter Hoehnsch 616 T-Systems International GmbH 617 Germany 619 Email: klaus-peter.hoehnsch@t-systems.com 621 Stefan Wenk 622 Frequentis AG 623 Innovationsstr. 1 624 Vienna 1100 625 Austria 627 Email: stefan.wenk@frequentis.com