Internet DRAFT - draft-df-stecker-expertenforum-payload-tetra
draft-df-stecker-expertenforum-payload-tetra
payload Reisenbauer
Internet-Draft Frequentis
Intended status: Standards Track Brandhuber
Expires: July 13, 2018 eurofunk
Hagedorn
Hagedorn
Hoehnsch
T-Systems
Wenk
Frequentis
January 9, 2018
RTP Payload Format for the TETRA Audio Codec
draft-df-stecker-expertenforum-payload-tetra-00
Abstract
This document specifies a Real-time Transport Protocol (RTP) payload
format to be used for TETRA encoded speech signals. The payload
format is designed to be able to interoperate with existing TETRA
transport formats on non-IP networks. This version of the document
does not specify a file format for transport of TETRA speech data in
storage mode applications such as email as would be required by the
IETF. A media type registration is included, specifying the use of
the RTP payload format and the storage format.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 13, 2018.
Reisenbauer, et al. Expires July 13, 2018 [Page 1]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. Media Format Background . . . . . . . . . . . . . . . . . . . 3
4. Payload format . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 4
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . 4
4.2.1. I bit: Frame Indicator . . . . . . . . . . . . . . . 4
4.2.2. F bit: Frame Type . . . . . . . . . . . . . . . . . . 5
4.2.3. CTRL: Control bit(5 bits) . . . . . . . . . . . . . . 5
4.2.4. C bit: Failed Crypto operation indication . . . . . . 5
4.2.5. FRAME_NR: FN (5 bits) . . . . . . . . . . . . . . . . 6
4.2.6. R: Audio Signal Relevance (3 bits) . . . . . . . . . 6
4.2.7. S: Spare (7 bits) . . . . . . . . . . . . . . . . . . 6
4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Payload layout . . . . . . . . . . . . . . . . . . . . . 7
5. Payload example . . . . . . . . . . . . . . . . . . . . . . . 7
6. Congestion Control Considerations . . . . . . . . . . . . . . 8
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8
8. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 10
8.2. Declarative SDP Considerations . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Reisenbauer, et al. Expires July 13, 2018 [Page 2]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
1. Introduction
This document specifies the payload format for packetization of
TErrestial Trunked Radio (TETRA) encoded speech signals into the
Real-time Transport Protocol (RTP) [RFC3550]. The payload format
supports transmission of multiple channels, multiple frames per
payload, robustness against packet loss, and interoperation with
existing TETRA transport formats on non-IP networks, as described in
Section Section 3.
The payload format itself is specified in Section Section 4.
2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] when they
appear in ALL CAPS. These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
The following acronyms are used in this document:
o ETSI: European Telecommunications Standards Institute
o TETRA: TErrestial Trunked Radio
The byte order used in this document is network byte order, i.e., the
most significant byte first. The bit order is also the most
significant bit first. This is presented in all figures as having
the most significant bit leftmost on a line and with the lowest
number. Some bit fields may wrap over multiple lines in which cases
the bits on the first line are more significant than the bits on the
next line.
Best current practices for writing an RTP payload format
specification were followed [RFC2736] updated with [RFC8088].
3. Media Format Background
The TETRA codec is used as vocoder for TETRA systems. The TETRA
codec is designed for compressing 30ms of audio speech data into 137
bits. The TETRA codec is designed in such a way that on the air
interface two of theses 30ms samples are transported together (sub-
block 1 and sub-block 2). The codec allows that data of the first
30ms voice frame can be stolen and used for other purposes, e.g. for
the exchange of dynamically updated key-material in end-to-end
encrypted voice sessions. For E1 lines there are two optional
formats defined [3], the first format is called FSTE (First Speech
Transport Encoding Format), the other format is called OSTE
Reisenbauer, et al. Expires July 13, 2018 [Page 3]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
(Optimized Speech Transport Encoding Format). These two formats
defer mainly insofar that the OSTE format transports an additional 5
bit frame number, which provides timing information from the air
interface to the receiving side in order to save the need for
buffering due to different transports speed on air and in 64 kbit/s
circuit switched networks. The RTP payload format is defined such
that the value of this frame number can be transported.
4. Payload format
The RTP payload format is designed in such a way that it can carry
the information needed to map the FSTE and OSTE format from
[ETSI-TETRA-ISI]. The RTP format is defined such that both of the
independent sub-blocks can be transferred separately or together
within one RTP frame. Both of them contain the same information in
terms of control bits - the information is propagated redundantly.
This redundancy is driven by on one hand to simplify the encoding
process in direction from E1 to RTP on the other to provide the
option to go for either 30ms or 60ms packet size. The redundant
information SHALL be propagated consistently equal - otherwise the
behavior of the receiver is unspecified. The payload format is
chosen such that the TETRA data bits are octet aligned.
4.1. RTP Header Usage
The format of the RTP header is specified in [RFC3550]. The use of
the fields of the RTP header by the TETRA payload format is
consistent with that specification.
The payload length of TETRA is an integer number of octets;
therefore, no padding is necessary.
The timestamp, sequence number, and marker bit (M) of the RTP header
are used in accordance with Section 4.1 of [RFC3551].
The RTP payload type for Tetra is to be assigned dynamically.
4.2. Payload Header
4.2.1. I bit: Frame Indicator
1: The following frame contains a first block of two sub-blocks
0: The following frame contains a separated sub-block. A sub-block
marked as such could either be a second sub-block, or an independent
block, which does not have a relation with any first block. To
distinguish between the one and the other the information of the
Control bits has to be evaluated.
Reisenbauer, et al. Expires July 13, 2018 [Page 4]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
4.2.2. F bit: Frame Type
+-------+-------------------+
| Value | Frame contains |
+-------+-------------------+
| 0 | FSTE encoded data |
| 1 | OSTE encoded data |
+-------+-------------------+
4.2.3. CTRL: Control bit(5 bits)
Ctrl 1..3 according table 2 of [ETSI-TETRA-ISI].
+-------+---------------+-------------+
| Value | Sub block 1 | Sub block 2 |
+-------+---------------+-------------+
| 000 | normal | normal |
| 001 | C stolen | normal |
| 010 | U stolen | normal |
| 011 | C stolen | C stolen |
| 100 | C stolen | U stolen |
| 101 | U stolen | C stolen |
| 110 | U stolen | U stolen |
| 111 | O&M ISI block | |
+-------+---------------+-------------+
Ctrl 4..5 according table 3 of [ETSI-TETRA-ISI].
+-------+-------------------+-------------------+
| Value | Sub block 1 | Sub block 2 |
+-------+-------------------+-------------------+
| 00 | BFI no errors | BFI no errors |
| 01 | BFI no errors | BFI with error(s) |
| 10 | BFI with error(s) | BFI no error(s) |
| 11 | BFI with error(s) | BFI with error(s) |
+-------+-------------------+-------------------+
NOTE: The meaning of C4 and C5 is outside the scope of the present
4.2.4. C bit: Failed Crypto operation indication
This bit may be set to "1" if an encryption or a decryption operation
could not be performed successfully for the specific half-block.
Consequently, the encryption status of the half-block audio data is
unknown. If a receiver decides to forward the TETRA audio data to
OSTE or FSTE or to directly hand over the TETRA audio data to a TETRA
audio decoder, the contained audio might be scrambled - depending if
Reisenbauer, et al. Expires July 13, 2018 [Page 5]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
the audio originally was generated as a plain-override half-block or
as an encrypted half-block.
4.2.5. FRAME_NR: FN (5 bits)
Those bits contain an uplink frame number as defined in table 8 of
[ETSI-TETRA-ISI]. If no frame number is available the FRAME_NR value
SHALL be set to 00000.
4.2.6. R: Audio Signal Relevance (3 bits)
The Audio Signal Relevance bits contain information about the
Relevance of the voice packet contained here.
R 1
0: no audio signal relevance propagated (R2 and R3 do not contain any
valid information)
1: audio signal relevance propagated in R2 and R3
R 2..3 According to table 1 of [BDBOS-BIP20]
+-------+-----------------------------------------------------------+
| value | relevance |
+-------+-----------------------------------------------------------+
| 00 | no audio signal relevance (level ? -72 dBm0) |
| 01 | low audio signal relevance (-52dBm0 ? level > -72dBm0) |
| 10 | medium audio signal relevance (-32dBm0 ? level > -52dBm0) |
| 11 | high audio signal relevance (0dBm0 ? level > -32dBm0) |
+-------+-----------------------------------------------------------+
4.2.7. S: Spare (7 bits)
Those bits are reserved for future use and set to "0" currently.
4.3. Payload Data
Reference [ETSI-TETRA-ISI] contains the definition for the generation
of the codec data. Data bits D1..D137 in chapter 8 correspond to the
"Bit number in speech frame" row of table 4 of [ETSI-TETRA-ISI].
The payload itself contains TETRA ACELP coded speech information
encoded according to table 4 of [ETSI-TETRA-Codec].
Reisenbauer, et al. Expires July 13, 2018 [Page 6]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
4.4. Payload layout
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|F| CTRL |C|FRAME_NR | R |D(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D(137)| S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Payload example
The following example shows how a first and a consecutive 30 ms frame
is combined into a single 60ms RTP packet. Note: This example shows
of usage of OSTE mapping.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D(137)| S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| CTRL |C|0|0|0|0|0|0|0|0|D(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D(137)| S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Both halves of information contain exact the same CTRL bits
Reisenbauer, et al. Expires July 13, 2018 [Page 7]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
6. Congestion Control Considerations
Tetra uses a fixed bitrate which cannot be adjusted at all.
Congestion control for RTP SHALL be used in accordance with RFC 3550
[RFC3550], and with any applicable RTP profile; e.g., RFC 3551
[RFC3551]. An additional requirement if best-effort service is being
used is: users of this payload format MUST monitor packet loss to
ensure that the packet loss rate is within acceptable parameters.
7. Payload Format Parameters
This RTP payload format is identified using one media subtype (audio/
TETRA) which is registered in accordance with RFC 4855 [RFC4855] and
using the template of RFC 4288 [RFC4288].
7.1. Media Type Definition
The media type for the TETRA codec is expected to be allocated from
the IETF tree once this draft turns into an RFC. This media type
registration covers both real-time transfer via RTP and non-real-time
transfers via stored files.
Media Type name:
audio
Media Subtype name:
TETRA
Required parameters:
none
Optional parameters:
These parameters apply to RTP transfer only.
maxptime:
The maximum amount of media which can be encapsulated in a payload
packet, expressed as time in milliseconds. The time is calculated
as the sum of the time that the media present in the packet
represents. The time SHOULD be an integer multiple of the frame
size. If this parameter is not present, the sender MAY
encapsulate any number of speech frames into one RTP packet.
ptime:
see RFC 4566 [RFC4566].
drgw-fe:
As long as there is no official RTP payload definition from IETF
this proprietary parameter ("digital radio gateway forum of
experts") is marked with the only possible value 1. It marks the
session to be established according to this specification.
Reisenbauer, et al. Expires July 13, 2018 [Page 8]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
Security considerations: See Section 7 of RFC 4867 [RFC4867].
Interoperability considerations:
Published specification:
Applications that use this media type:
This media type is used in applications needing transport or storage
of encoded voice. Some examples include; Voice over IP, streaming
media, voice messaging, and voice recording on recording systems.
Intended usage:
COMMON
8. Mapping to SDP
The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol
(SDP)[4], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing the TETRA codec, the mapping is
as follows:
Media Type name:
audio
Media subtype name:
TETRA Required parameters:none Optional parameters:none
Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol
[RFC4566], which is commonly used to describe RTP sessions. When
SDP is used to specify sessions employing the TETRA codec, the
mapping is as follows:
* The MIME type ("audio") goes in SDP "m=" as the media name.
* The MIME subtype (payload format name) goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
8000.
* The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
and "a=maxptime" attributes, respectively.
* Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the media type parameter string as a
semicolon-separated list of parameter=value pairs.
Here is an example SDP session of usage of TETRA:
Reisenbauer, et al. Expires July 13, 2018 [Page 9]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
m=audio 49120 RTP/AVP 99
a=rtpmap:99 TETRA/8000
a=maxptime:60
a=ptime:60
a=fmtp:99
8.1. Offer/Answer Considerations
The following considerations apply when using SDP Offer-Answer
procedures to negotiate the use of TETRA payload in RTP:
o In most cases, the parameters "maxptime" and "ptime" will not
affect interoperability; however, the setting of the parameters
can affect the performance of the application. The SDP offer-
answer handling of the "ptime" parameter is described in RFC3264
[RFC3264]. The "maxptime" parameter MUST be handled in the same
way.
o Any unknown parameter in an offer SHALL be removed in the answer.
8.2. Declarative SDP Considerations
For declarative media, the "ptime" and "maxptime" parameter specifies
the possible variants used by the sender. Multiple TETRA rtpmap
values MAY be used to convey TETRA-coded voice at different packet
rates. The receiver can then select an appropriate MELPe codec by
using one of the rtpmap values.
9. IANA Considerations
This memo requests that IANA registers [audio/TETRA]. The media type
is also requested to be added to the IANA registry for "RTP Payload
Format MIME types" (<http://www.iana.org/assignments/rtp-
parameters>).
10. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [RFC3550] , and in any applicable RTP profile. The
main security considerations for the RTP packet carrying the RTP
payload format defined within this memo are confidentiality,
integrity and source authenticity. Confidentiality is achieved by
encryption of the RTP payload. Integrity of the RTP packets through
suitable cryptographic integrity protection mechanism. Cryptographic
systems may also allow the authentication of the source of the
payload. A suitable security mechanism for this RTP payload format
should provide confidentiality, integrity protection and at least
Reisenbauer, et al. Expires July 13, 2018 [Page 10]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
source authentication capable of determining if an RTP packet is from
a member of the RTP session or not.
Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the
application, the transport, and the signaling protocol employed.
Therefore a single mechanism is not sufficient, although if suitable
the usage of SRTP [RFC3711] is recommended. Other mechanism that may
be used are IPsec [RFC4301] and TLS [RFC4346] (RTP over TCP), but
also other alternatives may exist.
11. References
11.1. Normative References
[BDBOS-BIP20]
Bundesanstalt fuer den Digitalfunk der Behoerden und
Organisationen mit Sicherheitsaufgaben, "BIP 20 QOS
Dienstguete-Parameter BOS-Interoperabilitaetsprofil fuer
Endgeraete zur Nutzung im Digitalfunk BOS; Version 2014-04
- Revision 2", 2014.
[ETSI-TETRA-Codec]
European Telecommunications Standards Institute, "EN 300
395-2; Terrestrial Trunked Radio (TETRA); Speech codec for
full-rate traffic channel; Part 2: TETRA codec V1.3.1",
2005, <http://www.etsi.org/deliver/
etsi_en/300300_300399/30039502/01.03.01_60/
en_30039502v010301p.pdf>.
[ETSI-TETRA-ISI]
European Telecommunications Standards Institute, "TS 100
392-3-6; Terrestrial Trunked Radio (TETRA); Voice plus
Data (V+D); Part 3: Interworking at the Inter-System
Interface (ISI); Sub-part 6: Speech format implementation
for circuit mode transmission V1.1.1", 2003,
<http://www.etsi.org/deliver/
etsi_ts/100300_100399/1003920306/01.01.01_60/
ts_1003920306v010101p.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Reisenbauer, et al. Expires July 13, 2018 [Page 11]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
11.2. Informative References
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736,
DOI 10.17487/RFC2736, December 1999,
<https://www.rfc-editor.org/info/rfc2736>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, DOI 10.17487/RFC4288,
December 2005, <https://www.rfc-editor.org/info/rfc4288>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/info/rfc4346>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>.
Reisenbauer, et al. Expires July 13, 2018 [Page 12]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"RTP Payload Format and File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867,
April 2007, <https://www.rfc-editor.org/info/rfc4867>.
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format",
RFC 8088, DOI 10.17487/RFC8088, May 2017,
<https://www.rfc-editor.org/info/rfc8088>.
Authors' Addresses
Andreas Reisenbauer
Frequentis AG
Innovationsstr. 1
Vienna 1100
Austria
Email: andreas.reisenbauer@frequentis.com
Udo Brandhuber
eurofunk Kappacher GmbH
Germany
Email: ubrandhuber@eurofunk.com
Joachim Hagedorn
Hagedorn Informationssysteme GmbH
Germany
Email: joachim@hagedorn-infosysteme.de
Klaus-Peter Hoehnsch
T-Systems International GmbH
Germany
Email: klaus-peter.hoehnsch@t-systems.com
Reisenbauer, et al. Expires July 13, 2018 [Page 13]
Internet-Draft RTP Payload Format for TETRA Audio codec January 2018
Stefan Wenk
Frequentis AG
Innovationsstr. 1
Vienna 1100
Austria
Email: stefan.wenk@frequentis.com
Reisenbauer, et al. Expires July 13, 2018 [Page 14]
