Requirements for codecs and media handling in support of the Mission Critical Push To Talk (MCPTT) service are contained in this document.
The MCPTT service supports voice communication between several users (i.e. group call), where each user has the ability to gain access to the permission to talk in an arbitrated manner. The MCPTT service also supports private calls between two users.
Background information in support of this document may be found in TR 26.989.
The present document specifies the codecs and media handling for MCPTT. The corresponding service requirements are defined in TS 22.179. The corresponding functional architecture, procedures and information flows are defined in TS 23.179.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
RFC 4867 (2007): "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", J. Sjoberg, M. Westerlund, A. Lakaniemi and Q. Xie.
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
(void)
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
AMR-WB
MCPTT clients shall support the AMR-WB codec as specified in TS 26.171, TS 26.190, TS 26.173 and TS 26.204, including all 9 modes and source controlled rate operation as specified in TS 26.193, voice activity detection as specified in TS 26.194, comfort noise generation as specified in TS 26.192 and error concealment as specified in TS 26.191. The MCPTT clients shall be capable of operating with any subset of these 9 codec modes.
Based on operator / MCPTT service provider policy, MCPTT clients may additionally support the EVS codec in super-wideband mode.
If an operator / MCPTT service provider chooses to additionally use SWB according to its policy, then an MCPTT client that offers super-wideband speech communication shall support the EVS codec in SWB mode as defined in TS 26.441, TS 26.445, TS 26.442, TS 26.452, TS 26.443, discontinuous transmission TS 26.450, voice activity detection as specified in TS 26.451, comfort noise generation as specified in TS 26.449 and error concealment as specified in TS 26.447.
General MCPTT client procedures for SDP offer-answer are specified in TS 24.379 and TS 24.380.
MCPTT clients shall support both "RTP/AVP" [25] and "RTP/SAVP" [26] profiles in SDP offer/answer. MCPTT clients shall not reject an SDP offer due to offered RTP profile being either "RTP/AVP" or "RTP/SAVP". MCPTT clients may, based on operator / MCPTT service provider policy, offer either "RTP/AVP" or "RTP/SAVP" RTP profiles.
MCPTT clients shall support and offer a payload type with AMR-WB.
If an operator / MCPTT service provider policy enables an MCPTT service using the EVS codec in SWB mode, then MCPTT clients may, based on operator / MCPTT service provider policy, additionally offer a payload type with the EVS codec in SWB mode.
The offer-answer protocol, setting of the codec preference order, and the generation of SDP offer and answer shall be configured according to operator / MCPTT service provider policy.
MCPTT clients shall support both RTP [24] and SRTP [26] media transport.
An MCPTT client shall understand the payload formats and options as defined in RFC 4867 [23]. The MCPTT client does not have to support operating according to all the options defined in RFC 4867 but shall be capable of properly accepting or rejecting all options.
The following payload format options from RFC 4867 are defined as follows to ensure minimum interoperability:
bandwidth-efficient shall be supported
mode-set: shall support all modes and shall offer no particular mode set
mode-change-period: both "1" and "2" shall be supported, "1" shall be offered (or not included)
mode-change-capability: both "1" and "2" shall be supported, "2" shall be offered
mode-change-neighbor: both "0" and "1" shall be supported, "0" shall be offered (or not included)
channels: shall offer "1"
Other parameters:
ptime: shall be supported, "20" shall be offered
maxptime: shall be supported, "240" shall be offered
max-red: shall be supported, "0" shall be offered
If, based on operator / MCPTT service provider policy, the MCPTT service additionally supports the EVS codec in SWB mode, then an MCPTT client that supports the optional EVS codec in SWB mode shall understand the EVS payload format as specified in TS 26.445 in order to support EVS in SWB mode. The MCPTT client does not have to support operating according to all the options defined in TS 26.445 but must be capable of properly accepting or rejecting all options.
When MCPTT voice traffic is received on the MBMS bearer in MBMS/MBSFN, the traffic is scheduled to arrive at intervals of multiples of 40ms. The received traffic could also exhibit time-varying jitter introduced in the backhaul and the uplink transmission by the talker before being scheduled for transmission on the MBMS bearer. The MCPTT UE receiving traffic on an MBMS bearer shall support and use a de-jitter buffer that is able to manage this amount of jitter.
MCPTT Server procedures are specified in TS 24.379 and TS 24.380.
MCPTT call media codec information shall include codecs according to MCPTT Client capabilities as specified in clause 4.1.1.