idnits 2.17.1 draft-df-stecker-expertenforum-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 (January 9, 2018) is 2299 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) -- Looks like a reference, but probably isn't: '3' on line 137 -- Looks like a reference, but probably isn't: '4' on line 396 -- 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 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 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 13, 2018 eurofunk 6 Hagedorn 7 Hagedorn 8 Hoehnsch 9 T-Systems 10 Wenk 11 Frequentis 12 January 9, 2018 14 RTP Payload Format for the TETRA Audio Codec 15 draft-df-stecker-expertenforum-payload-tetra-00 17 Abstract 19 This document specifies a Real-time Transport Protocol (RTP) payload 20 format to be used for TETRA encoded speech signals. The payload 21 format is designed to be able to interoperate with existing TETRA 22 transport formats on non-IP networks. This version of the document 23 does not specify a file format for transport of TETRA speech data in 24 storage mode applications such as email as would be required by the 25 IETF. A media type registration is included, specifying the use of 26 the RTP payload format and the storage format. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 13, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 64 3. Media Format Background . . . . . . . . . . . . . . . . . . . 3 65 4. Payload format . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 4 67 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . 4 68 4.2.1. I bit: Frame Indicator . . . . . . . . . . . . . . . 4 69 4.2.2. F bit: Frame Type . . . . . . . . . . . . . . . . . . 5 70 4.2.3. CTRL: Control bit(5 bits) . . . . . . . . . . . . . . 5 71 4.2.4. C bit: Failed Crypto operation indication . . . . . . 5 72 4.2.5. FRAME_NR: FN (5 bits) . . . . . . . . . . . . . . . . 6 73 4.2.6. R: Audio Signal Relevance (3 bits) . . . . . . . . . 6 74 4.2.7. S: Spare (7 bits) . . . . . . . . . . . . . . . . . . 6 75 4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . 6 76 4.4. Payload layout . . . . . . . . . . . . . . . . . . . . . 7 77 5. Payload example . . . . . . . . . . . . . . . . . . . . . . . 7 78 6. Congestion Control Considerations . . . . . . . . . . . . . . 8 79 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8 80 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8 81 8. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . 9 82 8.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 10 83 8.2. Declarative SDP Considerations . . . . . . . . . . . . . 10 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 11.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 This document specifies the payload format for packetization of 94 TErrestial Trunked Radio (TETRA) encoded speech signals into the 95 Real-time Transport Protocol (RTP) [RFC3550]. The payload format 96 supports transmission of multiple channels, multiple frames per 97 payload, robustness against packet loss, and interoperation with 98 existing TETRA transport formats on non-IP networks, as described in 99 Section Section 3. 101 The payload format itself is specified in Section Section 4. 103 2. Conventions Used In This Document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119] when they 108 appear in ALL CAPS. These words may also appear in this document in 109 lower case as plain English words, absent their normative meanings. 111 The following acronyms are used in this document: 113 o ETSI: European Telecommunications Standards Institute 114 o TETRA: TErrestial Trunked Radio 116 The byte order used in this document is network byte order, i.e., the 117 most significant byte first. The bit order is also the most 118 significant bit first. This is presented in all figures as having 119 the most significant bit leftmost on a line and with the lowest 120 number. Some bit fields may wrap over multiple lines in which cases 121 the bits on the first line are more significant than the bits on the 122 next line. 124 Best current practices for writing an RTP payload format 125 specification were followed [RFC2736] updated with [RFC8088]. 127 3. Media Format Background 129 The TETRA codec is used as vocoder for TETRA systems. The TETRA 130 codec is designed for compressing 30ms of audio speech data into 137 131 bits. The TETRA codec is designed in such a way that on the air 132 interface two of theses 30ms samples are transported together (sub- 133 block 1 and sub-block 2). The codec allows that data of the first 134 30ms voice frame can be stolen and used for other purposes, e.g. for 135 the exchange of dynamically updated key-material in end-to-end 136 encrypted voice sessions. For E1 lines there are two optional 137 formats defined [3], the first format is called FSTE (First Speech 138 Transport Encoding Format), the other format is called OSTE 139 (Optimized Speech Transport Encoding Format). These two formats 140 defer mainly insofar that the OSTE format transports an additional 5 141 bit frame number, which provides timing information from the air 142 interface to the receiving side in order to save the need for 143 buffering due to different transports speed on air and in 64 kbit/s 144 circuit switched networks. The RTP payload format is defined such 145 that the value of this frame number can be transported. 147 4. Payload format 149 The RTP payload format is designed in such a way that it can carry 150 the information needed to map the FSTE and OSTE format from 151 [ETSI-TETRA-ISI]. The RTP format is defined such that both of the 152 independent sub-blocks can be transferred separately or together 153 within one RTP frame. Both of them contain the same information in 154 terms of control bits - the information is propagated redundantly. 155 This redundancy is driven by on one hand to simplify the encoding 156 process in direction from E1 to RTP on the other to provide the 157 option to go for either 30ms or 60ms packet size. The redundant 158 information SHALL be propagated consistently equal - otherwise the 159 behavior of the receiver is unspecified. The payload format is 160 chosen such that the TETRA data bits are octet aligned. 162 4.1. RTP Header Usage 164 The format of the RTP header is specified in [RFC3550]. The use of 165 the fields of the RTP header by the TETRA payload format is 166 consistent with that specification. 168 The payload length of TETRA is an integer number of octets; 169 therefore, no padding is necessary. 171 The timestamp, sequence number, and marker bit (M) of the RTP header 172 are used in accordance with Section 4.1 of [RFC3551]. 174 The RTP payload type for Tetra is to be assigned dynamically. 176 4.2. Payload Header 178 4.2.1. I bit: Frame Indicator 180 1: The following frame contains a first block of two sub-blocks 182 0: The following frame contains a separated sub-block. A sub-block 183 marked as such could either be a second sub-block, or an independent 184 block, which does not have a relation with any first block. To 185 distinguish between the one and the other the information of the 186 Control bits has to be evaluated. 188 4.2.2. F bit: Frame Type 190 +-------+-------------------+ 191 | Value | Frame contains | 192 +-------+-------------------+ 193 | 0 | FSTE encoded data | 194 | 1 | OSTE encoded data | 195 +-------+-------------------+ 197 4.2.3. CTRL: Control bit(5 bits) 199 Ctrl 1..3 according table 2 of [ETSI-TETRA-ISI]. 201 +-------+---------------+-------------+ 202 | Value | Sub block 1 | Sub block 2 | 203 +-------+---------------+-------------+ 204 | 000 | normal | normal | 205 | 001 | C stolen | normal | 206 | 010 | U stolen | normal | 207 | 011 | C stolen | C stolen | 208 | 100 | C stolen | U stolen | 209 | 101 | U stolen | C stolen | 210 | 110 | U stolen | U stolen | 211 | 111 | O&M ISI block | | 212 +-------+---------------+-------------+ 214 Ctrl 4..5 according table 3 of [ETSI-TETRA-ISI]. 216 +-------+-------------------+-------------------+ 217 | Value | Sub block 1 | Sub block 2 | 218 +-------+-------------------+-------------------+ 219 | 00 | BFI no errors | BFI no errors | 220 | 01 | BFI no errors | BFI with error(s) | 221 | 10 | BFI with error(s) | BFI no error(s) | 222 | 11 | BFI with error(s) | BFI with error(s) | 223 +-------+-------------------+-------------------+ 225 NOTE: The meaning of C4 and C5 is outside the scope of the present 227 4.2.4. C bit: Failed Crypto operation indication 229 This bit may be set to "1" if an encryption or a decryption operation 230 could not be performed successfully for the specific half-block. 231 Consequently, the encryption status of the half-block audio data is 232 unknown. If a receiver decides to forward the TETRA audio data to 233 OSTE or FSTE or to directly hand over the TETRA audio data to a TETRA 234 audio decoder, the contained audio might be scrambled - depending if 235 the audio originally was generated as a plain-override half-block or 236 as an encrypted half-block. 238 4.2.5. FRAME_NR: FN (5 bits) 240 Those bits contain an uplink frame number as defined in table 8 of 241 [ETSI-TETRA-ISI]. If no frame number is available the FRAME_NR value 242 SHALL be set to 00000. 244 4.2.6. R: Audio Signal Relevance (3 bits) 246 The Audio Signal Relevance bits contain information about the 247 Relevance of the voice packet contained here. 249 R 1 251 0: no audio signal relevance propagated (R2 and R3 do not contain any 252 valid information) 254 1: audio signal relevance propagated in R2 and R3 256 R 2..3 According to table 1 of [BDBOS-BIP20] 258 +-------+-----------------------------------------------------------+ 259 | value | relevance | 260 +-------+-----------------------------------------------------------+ 261 | 00 | no audio signal relevance (level ? -72 dBm0) | 262 | 01 | low audio signal relevance (-52dBm0 ? level > -72dBm0) | 263 | 10 | medium audio signal relevance (-32dBm0 ? level > -52dBm0) | 264 | 11 | high audio signal relevance (0dBm0 ? level > -32dBm0) | 265 +-------+-----------------------------------------------------------+ 267 4.2.7. S: Spare (7 bits) 269 Those bits are reserved for future use and set to "0" currently. 271 4.3. Payload Data 273 Reference [ETSI-TETRA-ISI] contains the definition for the generation 274 of the codec data. Data bits D1..D137 in chapter 8 correspond to the 275 "Bit number in speech frame" row of table 4 of [ETSI-TETRA-ISI]. 277 The payload itself contains TETRA ACELP coded speech information 278 encoded according to table 4 of [ETSI-TETRA-Codec]. 280 4.4. Payload layout 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |I|F| CTRL |C|FRAME_NR | R |D(1) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | D(137)| S | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 5. Payload example 298 The following example shows how a first and a consecutive 30 ms frame 299 is combined into a single 60ms RTP packet. Note: This example shows 300 of usage of OSTE mapping. 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |1|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | D(137)| S | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |0|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | D(137)| S | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Both halves of information contain exact the same CTRL bits 328 6. Congestion Control Considerations 330 Tetra uses a fixed bitrate which cannot be adjusted at all. 332 Congestion control for RTP SHALL be used in accordance with RFC 3550 333 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 334 [RFC3551]. An additional requirement if best-effort service is being 335 used is: users of this payload format MUST monitor packet loss to 336 ensure that the packet loss rate is within acceptable parameters. 338 7. Payload Format Parameters 340 This RTP payload format is identified using one media subtype (audio/ 341 TETRA) which is registered in accordance with RFC 4855 [RFC4855] and 342 using the template of RFC 4288 [RFC4288]. 344 7.1. Media Type Definition 346 The media type for the TETRA codec is expected to be allocated from 347 the IETF tree once this draft turns into an RFC. This media type 348 registration covers both real-time transfer via RTP and non-real-time 349 transfers via stored files. 351 Media Type name: 352 audio 353 Media Subtype name: 354 TETRA 355 Required parameters: 356 none 358 Optional parameters: 360 These parameters apply to RTP transfer only. 362 maxptime: 363 The maximum amount of media which can be encapsulated in a payload 364 packet, expressed as time in milliseconds. The time is calculated 365 as the sum of the time that the media present in the packet 366 represents. The time SHOULD be an integer multiple of the frame 367 size. If this parameter is not present, the sender MAY 368 encapsulate any number of speech frames into one RTP packet. 369 ptime: 370 see RFC 4566 [RFC4566]. 371 drgw-fe: 372 As long as there is no official RTP payload definition from IETF 373 this proprietary parameter ("digital radio gateway forum of 374 experts") is marked with the only possible value 1. It marks the 375 session to be established according to this specification. 377 Security considerations: See Section 7 of RFC 4867 [RFC4867]. 379 Interoperability considerations: 381 Published specification: 383 Applications that use this media type: 385 This media type is used in applications needing transport or storage 386 of encoded voice. Some examples include; Voice over IP, streaming 387 media, voice messaging, and voice recording on recording systems. 389 Intended usage: 390 COMMON 392 8. Mapping to SDP 394 The information carried in the media type specification has a 395 specific mapping to fields in the Session Description Protocol 396 (SDP)[4], which is commonly used to describe RTP sessions. When SDP 397 is used to specify sessions employing the TETRA codec, the mapping is 398 as follows: 400 Media Type name: 401 audio 402 Media subtype name: 403 TETRA Required parameters:none Optional parameters:none 404 Mapping MIME Parameters into SDP 405 The information carried in the MIME media type specification has a 406 specific mapping to fields in the Session Description Protocol 407 [RFC4566], which is commonly used to describe RTP sessions. When 408 SDP is used to specify sessions employing the TETRA codec, the 409 mapping is as follows: 411 * The MIME type ("audio") goes in SDP "m=" as the media name. 412 * The MIME subtype (payload format name) goes in SDP "a=rtpmap" 413 as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 414 8000. 415 * The parameters "ptime" and "maxptime" go in the SDP "a=ptime" 416 and "a=maxptime" attributes, respectively. 417 * Any remaining parameters go in the SDP "a=fmtp" attribute by 418 copying them directly from the media type parameter string as a 419 semicolon-separated list of parameter=value pairs. 421 Here is an example SDP session of usage of TETRA: 423 m=audio 49120 RTP/AVP 99 424 a=rtpmap:99 TETRA/8000 425 a=maxptime:60 426 a=ptime:60 427 a=fmtp:99 429 8.1. Offer/Answer Considerations 431 The following considerations apply when using SDP Offer-Answer 432 procedures to negotiate the use of TETRA payload in RTP: 434 o In most cases, the parameters "maxptime" and "ptime" will not 435 affect interoperability; however, the setting of the parameters 436 can affect the performance of the application. The SDP offer- 437 answer handling of the "ptime" parameter is described in RFC3264 438 [RFC3264]. The "maxptime" parameter MUST be handled in the same 439 way. 440 o Any unknown parameter in an offer SHALL be removed in the answer. 442 8.2. Declarative SDP Considerations 444 For declarative media, the "ptime" and "maxptime" parameter specifies 445 the possible variants used by the sender. Multiple TETRA rtpmap 446 values MAY be used to convey TETRA-coded voice at different packet 447 rates. The receiver can then select an appropriate MELPe codec by 448 using one of the rtpmap values. 450 9. IANA Considerations 452 This memo requests that IANA registers [audio/TETRA]. The media type 453 is also requested to be added to the IANA registry for "RTP Payload 454 Format MIME types" (). 457 10. Security Considerations 459 RTP packets using the payload format defined in this specification 460 are subject to the security considerations discussed in the RTP 461 specification [RFC3550] , and in any applicable RTP profile. The 462 main security considerations for the RTP packet carrying the RTP 463 payload format defined within this memo are confidentiality, 464 integrity and source authenticity. Confidentiality is achieved by 465 encryption of the RTP payload. Integrity of the RTP packets through 466 suitable cryptographic integrity protection mechanism. Cryptographic 467 systems may also allow the authentication of the source of the 468 payload. A suitable security mechanism for this RTP payload format 469 should provide confidentiality, integrity protection and at least 470 source authentication capable of determining if an RTP packet is from 471 a member of the RTP session or not. 473 Note that the appropriate mechanism to provide security to RTP and 474 payloads following this memo may vary. It is dependent on the 475 application, the transport, and the signaling protocol employed. 476 Therefore a single mechanism is not sufficient, although if suitable 477 the usage of SRTP [RFC3711] is recommended. Other mechanism that may 478 be used are IPsec [RFC4301] and TLS [RFC4346] (RTP over TCP), but 479 also other alternatives may exist. 481 11. References 483 11.1. Normative References 485 [BDBOS-BIP20] 486 Bundesanstalt fuer den Digitalfunk der Behoerden und 487 Organisationen mit Sicherheitsaufgaben, "BIP 20 QOS 488 Dienstguete-Parameter BOS-Interoperabilitaetsprofil fuer 489 Endgeraete zur Nutzung im Digitalfunk BOS; Version 2014-04 490 - Revision 2", 2014. 492 [ETSI-TETRA-Codec] 493 European Telecommunications Standards Institute, "EN 300 494 395-2; Terrestrial Trunked Radio (TETRA); Speech codec for 495 full-rate traffic channel; Part 2: TETRA codec V1.3.1", 496 2005, . 500 [ETSI-TETRA-ISI] 501 European Telecommunications Standards Institute, "TS 100 502 392-3-6; Terrestrial Trunked Radio (TETRA); Voice plus 503 Data (V+D); Part 3: Interworking at the Inter-System 504 Interface (ISI); Sub-part 6: Speech format implementation 505 for circuit mode transmission V1.1.1", 2003, 506 . 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, 512 DOI 10.17487/RFC2119, March 1997, 513 . 515 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 516 Jacobson, "RTP: A Transport Protocol for Real-Time 517 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 518 July 2003, . 520 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 521 Video Conferences with Minimal Control", STD 65, RFC 3551, 522 DOI 10.17487/RFC3551, July 2003, 523 . 525 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 526 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 527 July 2006, . 529 11.2. Informative References 531 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 532 Payload Format Specifications", BCP 36, RFC 2736, 533 DOI 10.17487/RFC2736, December 1999, 534 . 536 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 537 with Session Description Protocol (SDP)", RFC 3264, 538 DOI 10.17487/RFC3264, June 2002, 539 . 541 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 542 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 543 RFC 3711, DOI 10.17487/RFC3711, March 2004, 544 . 546 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 547 Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, 548 December 2005, . 550 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 551 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 552 December 2005, . 554 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 555 (TLS) Protocol Version 1.1", RFC 4346, 556 DOI 10.17487/RFC4346, April 2006, 557 . 559 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 560 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 561 . 563 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 564 "RTP Payload Format and File Storage Format for the 565 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 566 (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, 567 April 2007, . 569 [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", 570 RFC 8088, DOI 10.17487/RFC8088, May 2017, 571 . 573 Authors' Addresses 575 Andreas Reisenbauer 576 Frequentis AG 577 Innovationsstr. 1 578 Vienna 1100 579 Austria 581 Email: andreas.reisenbauer@frequentis.com 583 Udo Brandhuber 584 eurofunk Kappacher GmbH 585 Germany 587 Email: ubrandhuber@eurofunk.com 589 Joachim Hagedorn 590 Hagedorn Informationssysteme GmbH 591 Germany 593 Email: joachim@hagedorn-infosysteme.de 595 Klaus-Peter Hoehnsch 596 T-Systems International GmbH 597 Germany 599 Email: klaus-peter.hoehnsch@t-systems.com 600 Stefan Wenk 601 Frequentis AG 602 Innovationsstr. 1 603 Vienna 1100 604 Austria 606 Email: stefan.wenk@frequentis.com