payload Reisenbauer
Internet-Draft Frequentis
Intended status: Standards Track Brandhuber
Expires: October 24, 2018 eurofunk
April 22, 2018

RTP Payload Format for the TETRA Audio Codec


This document specifies a Real-time Transport Protocol (RTP) payload format for TETRA encoded speech signals. The payload format is designed to be able to interoperate with existing TETRA transport formats on non-IP networks. 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

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 October 24, 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 ( 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

This document specifies the payload format for packetization of TErrestial Trunked Radio (TETRA) encoded speech signals [ETSI-TETRA-Codec] 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:

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. Codec payload serialisation within the traditional circuit mode based TETRA system is specified for TDM lines with 2048 kBit/s. For this purpose two optional formats are defined [ETSI-TETRA-Codec], the first format is called FSTE (First Speech Transport Encoding Format), the other format is called OSTE (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 packet. 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 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          |

4.3. Payload Header

4.3.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.

4.3.2. F bit: Frame Type

Value Frame contains
0 FSTE encoded data
1 OSTE encoded data

4.3.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.3.4. C bit: Failed Crypto operation indication

This bit may be set to "1" if a decryption (encrypted audio along the circuit switched mobile network, decryption at the RTP sender forwarding this audio) operation could not be performed successfully for the specific half-block. Consequently, the encryption status of the half-block audio data is unknown. Implementation of an RTP receiver has to take into account "C bit" when forwarding such TETRA audio data (either to a decoder directly or via TETRA infrastructure to a TETRA mobile unit), the contained audio might be scrambled - depending if the audio originally was generated as a plain-override half-block or as an encrypted half-block.

4.3.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.3.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.3.7. S: Spare (7 bits)

Those bits are reserved for future use and set to "0" currently.

4.4. 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].

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

6. Congestion Control Considerations

Tetra uses a fixed bitrate which cannot be adjusted at all.

Since UDP does not provide congestion control, applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer RFC8085 [RFC8085] and MAY also implement a transport circuit breaker RFC8083 [RFC8083]. Work in the RMCAT working group [RMCAT] describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to congestion control functions.

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 per media type registration template from RFC 6838 [RFC6838].

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:

Media Subtype name:

Required parameters:


Optional parameters:

These parameters apply to RTP transfer only.


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.

see RFC 4566 [RFC4566].
Security considerations:

See Section Section 10 of RFC XXXX. [RFC Editor: Upon publication as an RFC, please replace "XXXX" with the number assigned to this document and remove this note.]

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:


8. Mapping to SDP

The information carried in the 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:

Media Type name:

Media subtype name:

Required parameters:

Optional parameters:

Mapping Parameters into SDP

The information carried in the 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:

Here is an example SDP session of usage of TETRA:

m=audio 49120 RTP/AVP 99
a=rtpmap:99 TETRA/8000

8.1. Offer/Answer Considerations

The following considerations apply when using SDP Offer-Answer procedures to negotiate the use of TETRA payload in RTP:

8.2. Declarative SDP Considerations

For declarative media, the "ptime" and "maxptime" parameter specifies the possible variants used by the sender.

9. IANA Considerations

This memo requests that IANA registers [audio/TETRA] from section Section 7.1. The media type is also requested to be added to the IANA registry for "RTP Payload Format MIME types" (<>).

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 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 [RFC5246] (RTP over TCP), but also other alternatives may exist.

11. References

11.1. Normative References

[BDBOS-BIP20] Bundesanstalt für den Digitalfunk der Behörden und Organisationen mit Sicherheitsaufgaben, "BIP 20 QOS Dienstgüte-Parameter BOS-Interoperabilitätsprofil für Endgeräte 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.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[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.
[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.
[RFC4566] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017.
[RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017.

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.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002.
[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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008.
[RFC6838] Freed, N., Klensin, J. and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013.
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format", RFC 8088, DOI 10.17487/RFC8088, May 2017.
[RMCAT] RTP Media Congestion Avoidance Techniques (rmcat) Working Group, "RTP Media Congestion Avoidance Techniques (rmcat) Working Grooup", 2018.

Authors' Addresses

Andreas Reisenbauer Frequentis AG Innovationsstr. 1 Vienna, 1100 Austria EMail:
Udo Brandhuber eurofunk Kappacher GmbH Germany EMail:
Joachim Hagedorn Hagedorn Informationssysteme GmbH Germany EMail:
Klaus-Peter Höhnsch T-Systems International GmbH Germany EMail:
Stefan Wenk Frequentis AG Innovationsstr. 1 Vienna, 1100 Austria EMail: