18 MTSI client in terminal using fixed access

26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

18.1 General

This clause 18 applies to an MTSI client in terminal using fixed access.

The functional components of an MTSI client in terminal using fixed access are the same as described in clause 4.2 except that another Layer 2 technology may be used instead of the 3GPP L2 data link.

18.2 Media codecs

18.2.1 General

Media codecs for speech and video are specified in TS 181 005 [98]. Additional requirements and recommendations are included below.

18.2.2 Speech

18.2.2.1 Speech codecs

MTSI clients in terminal using fixed access supporting AMR, AMR-WB or EVS shall follow clause 5.2.1.

An MTSI client in terminal using fixed access supporting G.711 [77] shall support either A-law PCM or -law PCM and should support both.

MTSI client in terminal using fixed access supporting G.722 shall use the mode operation 1 at 64 kbps as specified in ITU-T Recommendation G.722 [78] when G.722 is used. The bitstream ordering shall be in chronological order with Most Significant Bit (MSB) first.

MTSI client in terminal using fixed access supporting EVRC, EVRC-B, and /or EVRC-WB shall follow 3GPP2 C.S0014-E v1.0 [99] when any of these codecs are used.

Encoding of DTMF is described in Annex G.

18.2.2.2 Error concealment procedures

Error concealment procedures shall be used to reduce the quality degradation of the reconstructed speech when one or more erroneous/lost speech or lost Silence Descriptor (SID) frames are received.

For G.722, it is recommended to use Appendix III or Appendix IV of ITU-T Recommendation G.722 [78].

NOTE: Appendices III and IV meet the same quality requirements but with two different quality/complexity trade-offs:

– Appendix III of ITU-T Recommendation G.722 [78] aims at maximizing the robustness at a price of additional complexity.

– Appendix IV of ITU-T Recommendation G.722 [78] offers an optimized complexity/quality trade off with almost no additional complexity compared with G.722 normal decoding (+0.07 WMOPS).

If another error concealment procedure is used it shall have equivalent or better performance than Appendix III or Appendix IV.

For G.711, it is recommended to use Appendix I of ITU-T Recommendation G.711 [77]. If another error concealment procedure is used, it shall have equivalent or better performance than Appendix I of ITU-T Recommendation G.711.

For G.729, the error concealment procedure shall be used as specified in the Main Body of ITU-T Recommendation G.729 [100].

For G.729.1, the error concealment procedure shall be used as specified in the ITU-T Recommendation G.729.1 [101].

18.2.2.3 Source controlled rate operation

An MTSI client in terminal using fixed access supporting AMR, AMR-WB or EVS shall support source controlled rate operation in accordance with clause 5.2.1.

For an MTSI client in terminal using fixed access supporting other codecs than AMR, AMR-WB or EVS the following recommendations apply:

– Source controlled rate operation for G.729 should be supported according to Annex B of ITU-T G.729 [100].

– Source controlled rate operation for G.729.1 should be supported according to Annex C and Annex F of ITU-T G.729.1 [101]. Annex C specifies a discontinuous transmission (DTX) and comfort noise generation for G.729.1. Annex F specified the voice activity detector (VAD) to be used together with the DTX/CNG scheme of Annex C to provide the complete functionality of the discontinuous transmission system.

– Source controlled rate operation for G.711 should be supported according to Appendix 2 of ITU-T G.711 [77].

– No source controlled rate operation has been standardized for G.722.

NOTE 1: Use of source controlled rate operation is optional. Source controlled rate operation is known to degrade the speech quality, especially in noisy environments or with background music, and is not needed when both MTSI client in terminals are using fixed access and when the bandwidth is sufficient to ensure best possible voice quality.

NOTE 2: Apart from source controlled rate operation (VAD/DTX) specified in clause 4.19 of 3GPP2 C.S0014-E [99] and in 3GPP2 C.S0076 v1.0 [102], EVRC, EVRC-B, and EVRC-WB can dynamically vary the source coding bit-rate for active speech to achieve a targeted active speech average data rate as specified in 3GPP2 C.S0014-E.

18.2.3 Video

MTSI clients in terminals using fixed access offering video communication shall support the video codecs as defined in clause 5.2.2.

NOTE: The video codecs recommended in TS 181 005 [98] are H.263 profile 0 and H.264 Baseline Profile without any constraint on the levels. For 3GPP MTSI clients in terminal using 3GPP access, only H.264 is specified in the present document but with a different profile: the Constrained Baseline Profile (CBP) for which the Level 1.2 is mandatory and Level 3.1 is recommended.

The Baseline Profile and the Constrained Baseline Profile are very close but not compatible. The Baseline Profile includes all features that are supported in the Constrained Baseline Profile but some limited features of the Baseline Profile are not supported in the Constrained Baseline Profile.

18.2.4 Real-time text

An MTSI client in terminal using fixed access and offering real-time text shall support real-time text as defined in clause 5.2.3.

18.3 Media configuration

18.3.1 General

The general clause on media configuration (clause 6.1) applies to an MTSI client in terminal using fixed access.

An MTSI client in terminal using fixed access and supporting RTP/AVPF shall do RTP profile negotiation as defined in clause 6.2.1a.

The support for Explicit Congestion Notification (ECN) is optional for an MTSI client in terminal using fixed access. ECN may be used to perform rate adaptation for speech and video when at least one multi-rate or rate-adaptive codec is supported. If ECN is supported then this shall be done in accordance with the requirements and recommendations specified in clause 6 and in clause 7.3 for RTCP based adaptation.

NOTE: It is beneficial if the MTSI client in terminal using fixed access supports ECN, even if the fixed network is not expected to support or use ECN for RTP. This enables using ECN between fixed and mobile clients when the same codecs are supported end-to-end.

An MTSI client in terminal using fixed access and supporting ECN should negotiate ECN usage when the SDP offer includes at least one multi-rate or rate-adaptive codec, see clause 6.2.2 for speech and clause 6.2.3.2 for video. If only fixed-rate codecs are included in the SDP offer for a media type then ECN shall not be negotiated for that media type.

An MTSI client in terminal using fixed access and supporting ECN may accept using ECN when a multi-rate or rate-adaptive codec is accepted, see clause 6.2.2 for speech and clause 6.2.3.2 for video.

18.3.2 Session setup procedures

18.3.2.1 General

The general clause on session set up procedures (clause 6.2.1) applies to the MTSI client in terminal using fixed access.

If an MTSI client in terminal using fixed access supports AVPF for a media type then it shall also support the complete SDPCapNeg framework, RFC 5939 [69], for that media type in order to negotiate the RTP profiles.

18.3.2.2 Speech

If an MTSI client in terminal using fixed access supports AMR and/or AMR-WB and/or EVS, then clause 6.2.2 applies for session set up.

An MTSI client in terminal using fixed access shall support RTP/AVP. When at least one multi-rate codec is supported (AMR, AMR-WB, EVS or G.729.1) then RTP/AVPF should be supported to allow for end-to-end rate adaptation.

If an MTSI client in terminal using fixed access supports AMR and/or AMR-WB, or EVS, then clause 6.2.2.2 applies for generating SDP offers for AMR-NB, AMR-WB and EVS.

An MTSI client in terminal using fixed access supporting both A-law PCM and -law PCM shall offer both variants when sending an SDP offer for G.711.

When an MTSI client in terminal using fixed access supports EVRC-B or EVRC-WB, then clauses 14-18 of RFC 5188 [103] apply when generating SDP offers and answers for EVRC-B and EVRC-WB.

If an MTSI client in terminal using fixed access supports G.729.1 then it also supports G.729 and should offer both G.729.1 and G.729 when sending an SDP offer.

An MTSI client in terminal offering G.729 with source controlled rate operation shall use the parameter "annexb" according to RFC 4855 [107].

The following codec preference order applies for the SDP offer in the session negotiation:

– If AMR-WB is offered it shall be listed first in the codec list (in order of preference, the first codec being preferred).

– If both narrowband codecs and wideband codecs are offered, wideband codecs shall be listed first in the codec list.

When sending the SDP answer, if a wide-band speech session is possible, then selection of narrow-band speech should be avoided whenever possible, unless another preference order is indicated in the SDP offer.

Session setup for sessions including speech and DTMF events is described in Annex G.

18.3.2.3 Video

An MTSI client in terminal using fixed access and supporting video shall support RTP/AVP and shall support RTP/AVPF.

If an MTSI client in terminal using fixed access supports video, then clause 6.2.3 applies for the video session set up.

18.3.2.4 Text

An MTSI client in terminal using fixed access and offering text shall follow clause 6.2.4.

18.3.2.5 Bandwidth negotiation

The general clause 6.2.5.1 related to the use of Application Specific (AS) bandwidth modifier applies also to the MTSI client in terminal using fixed access.

If an MTSI client in terminal using fixed access supports AMR and/or AMR-WB and/or EVS, then clause 6.2.5.2 applies for the bandwidth negotiation for these codecs.

If an MTSI client in terminal using fixed access supports video, then clause 6.2.5.3 applies for the bandwidth negotiation.

When the SDP offer includes multiple codecs then the bandwidth indicated with b=AS shall be set based on the codec that requires the highest bandwidth.

An MTSI client in terminal using fixed access should include the ‘a=bw-info’ attribute (see clause 19) in the SDP offer for speech and video media types and should include the attribute for other media types, as described in clause 6.2.5.1. For AMR, AMR-WB or EVS, the setting of the bandwidth properties are defined in clause 6.2.5.2 and Annex K.

18.3.3 Session control procedures

The clause 6.3 on session set up procedures applies also to an MTSI client in terminal that uses fixed access.

18.4 Data transport

18.4.1 General

The clauses data transport general (7.1) and RTCP usage (7.3.1) apply also to the MTSI client in terminal using fixed access.

An MTSI client in terminal using fixed access shall transport real-time media using RTP (RFC 3550 [9]) over UDP (RFC 0768 [39]). See clause 18.3.2.2, 18.3.2.3 and 18.3.2.4 for requirements on RTP/AVP and RTP/AVPF for speech, video and text, respectively.

The support of AVPF requires an MTSI client in terminal to implement the RTCP transmission rules, the signalling mechanism for SDP and the feedback messages explicitly mentioned in the present document.

For a given RTP based media stream, the MTSI client in terminal shall use the same port number for sending and receiving RTP packets. This facilitates interworking with fixed/broadband access. However, the MTSI client shall accept RTP packets that are not received from the same remote port where RTP packets are sent by the MTSI client.

18.4.2 Packetization

For G.711 both 10 ms and 20 ms frame length shall be supported, and 20 ms frame length shall be used unless another packetization is negotiated. The terminal shall offer to receive 20 ms frame length packetization.

For G.722, 20 ms frame length shall be supported.

The default packetization time for the codecs used in the MTSI client in terminal using fixed access shall be 20 ms (1 non-redundant speech frame per RTP packet). The packetization could change as a result of adaptation by using frame aggregation when adapting to packet rate limited operating conditions, see also clause 18.7.

Packetization time shall be indicated using the a=ptime SDP attribute.

An MTSI clients in terminal using fixed access shall support encapsulating up to 4 non-redundant speech frames into the RTP packets and 12 speech frames in total if redundancy is used (maxptime = 240).

18.4.3 RTP payload format

For each of the following codecs the payload formats are defined in:

– For AMR and/or AMR-WB, or EVS as specified in clause 7.4.2.

– For G.729.1 as specified in RFC 4749 [104], and as specified in RFC 5459 [105] when DTX is used.

– For EVRC and EVRC-B as specified in RFC 4788 [106].

– For EVRC-WB as specified in RFC 5188 [103].

– For DTMF events is described in Annex G.

The RTP payload types for G.711, G.729, G.722 shall be supported as specified in Section 6, Table 4 of RFC 3551 [10].

The following payload types should be used for G.711, G.729 and G.722:

Table 18.4.3-1: Recommended payload type numbers

Codec	Payload Type
G.711 A-law	PT= 8
G.711 μ-law	PT= 0
G.729	PT= 18
G.722	PT=9

For other codecs, dynamic payload types shall be used.

18.5 Jitter buffer management

An MTSI client in terminal using fixed access shall be able to handle delay jitter in order to minimize the speech quality degradation due to jitter (jitter induced frame losses) while limiting the additional end to end delay due to jitter buffering time.

The jitter buffer management (JBM) shall comply with the functional requirements defined in clause 8.2.2 and with the minimum performance requirements defined in clause 8.2.3.

NOTE: The delay and error profiles defined in clause 8.2.3.2.3 were derived for mobile access but they were selected to span the different jitter and packet loss conditions that may occur in different types of networks and in different combination of networks. For fixed-mobile interworking the jitter may be small and packet loss rate may be low in the fixed part of the path, but the jitter may be large and the packet loss rate may be fairly high in the mobile part of the path. This can give end-to-end jitter and packet loss characteristics that are similar to the characteristics found in these profiles. The JBM therefore needs to handle these profiles to support end-to-end fixed-mobile interworking.

18.6 Packet-loss handling

An MTSI client in terminal using fixed access may use redundancy to handle operating conditions with high packet loss rates. When redundancy is supported then this shall be done in accordance with the requirements and recommendations defined in clause 9.

When redundancy is used then the multi-rate or rate-adaptive capabilities of the codec should be used to avoid increasing the load in the network. Redundancy shall be used for fixed-rate codecs only when permitted by the allocated bandwidth.

NOTE: It is beneficial if the MTSI client in terminal using fixed access supports redundancy since this enables using such solutions end-to-end between fixed and mobile clients, at least when the same codecs are supported end-to-end.

18.7 Adaptation

An MTSI client in terminal using fixed access supporting AMR and/or AMR-WB for speech or supporting video should support adaptation as described in clause 10 for speech and video, respectively.

Frame aggregation and redundancy should be supported also for fixed-rate codecs.

The media bit rate adaptation for G.729.1 should use the same principles as described for AMR and AMR-WB in clause 10.2. For example, if G.729.1 is used at a bit rates up to 32 kbps, the adaptation may be configured to reduce the media bit-rate to 8 kbps when ECN-CE is detected.

18.8 Front-end handling

For terminals only supporting fixed access, performance requirements for terminal acoustics and test methods are specified in ETSI TS 103 737 [109], ETSI TS 103 738 [110], ETSI TS 103 739 [111], ETSI TS 103 740 [112], ETSI ES 202 737 [113], ETSI ES 202 738 [114], ETSI ES 202 739 [115], ETSI ES 202 740 [116] and for DECT terminals in ETSI specifications EN 300 175-8 [117] and EN 300 176-2 [118].

Other terminals supporting fixed and 3GPP access shall meet or exceed the minimum performance requirements on the acoustic characteristics of 3G terminals specified in TS 26.131 [35] in order to harmonize the acoustic front-end.

18.9 Supplementary services

An MTSI client in terminal using fixed access shall support media handling for supplementary services as defined in clause 14, except that the codecs are defined in clause 18.2 and the data transport is defined in clause 18.4.