Content for TS 26.114 Word version: 18.8.0

0… 3… 4… 5… 6… 6.2.3… 6.2.5… 6.2.7… 6.2.10… 7… 7.5… 8… 9… 10… 10.2.1.6… 10.2.2… 10.3… 10.4… 11… 12… 12.3… 12.7… 13a… 16… 16.5… 17… 18… 19… A… A.3… A.4… A.5… A.10… A.14… A.15… B… C… C.1.3… C.1.3.5 C.2… D E… E.18… E.31… G… K… L… M… N… O… P… P.3 Q… R… S… T… U… V… W… X… Y… Y.6… Y.6.4… Y.6.5… Y.7…

18 MTSI client in terminal using fixed access |R12| p. 220

18.1 General p. 220

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 p. 220

18.2.1 General p. 220

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

18.2.2 Speech p. 220

18.2.2.1 Speech codecs p. 220

MTSI clients in terminal using fixed access supporting AMR, AMR-WB, EVS or IVAS 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 p. 221

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

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 p. 221

An MTSI client in terminal using fixed access supporting AMR, AMR-WB, EVS or IVAS 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, EVS or IVAS 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.

18.2.3 Video p. 222

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

18.2.4 Real-time text p. 222

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 p. 222

18.3.1 General p. 222

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.

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 p. 222

18.3.2.1 General p. 222

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, for that media type in order to negotiate the RTP profiles.

18.3.2.2 Speech p. 222

If an MTSI client in terminal using fixed access supports AMR and/or AMR-WB, EVS and/or IVAS, 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, EVS, or IVAS, 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 Sections 14-18 of RFC 5188 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.

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 p. 223

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 p. 223

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

18.3.2.5 Bandwidth negotiation p. 223

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 p. 223

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 p. 224

18.4.1 General p. 224

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) over UDP (RFC 0768). 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 p. 224

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 p. 224

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, and as specified in RFC 5459 when DTX is used.
For EVRC and EVRC-B as specified in RFC 4788.
For EVRC-WB as specified in RFC 5188.
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 of RFC 3551, Table 4.

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 p. 225

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.

18.6 Packet-loss handling p. 225

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.

18.7 Adaptation p. 225

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 p. 225

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 in order to harmonize the acoustic front-end.

18.9 Supplementary services p. 225

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.