Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x
Top   in Index   Prev   Next

TS 26.111
Codec for Circuit Switched Multimedia Telephony Service –
Modifications to H.324

3GPP‑Page   ETSI‑search   CONTENT↓
V18.0.0 (PDF)  2024/03  15 p.
V17.0.0  2022/03  15 p.
V16.0.0  2020/06  15 p.
V15.0.0  2018/06  14 p.
V14.0.0  2017/03  15 p.
V13.0.0  2015/12  15 p.
V12.0.0  2014/09  15 p.
V11.0.0  2012/09  15 p.
V10.0.0  2011/04  15 p.
V9.0.0  2009/12  15 p.
V8.0.0  2008/12  15 p.
V7.1.0  2008/06  15 p.
V6.2.0  2008/06  15 p.
V5.1.0  2003/06  11 p.
V4.0.0  2001/04  11 p.
V3.4.0  2000/12  11 p.
Rapporteur:
Dr. Jung, Kyunghun
Samsung Electronics Co., Ltd

Content for  TS 26.111  Word version:  18.0.0

Here   Top
0 Introduction  1 Scope  2 References  3 Definitions and abbreviations  4 General  5 Document structure  6 Functional requirements  7 Terminal procedures  8 Optional enhancements  9 Interoperation with other terminals  10 Multipoint considerations  11 Maintenance  $ Change history 

 

0  Introduction  p. 4

In the present document is described additions, deletions, and changes made to ITU-T Recommendation H.324 [10] with Annex C for the purpose of using that recommendation as a basis for the technical specification for circuit switched multimedia service in 3GPP networks. The present document does not address call setup procedures, but references to the specifications which cover call setup are found in TS 26.110.
Up

1  Scope  p. 5

In ITU-T Recommendation H.324 [10] with Annex C describes a generic multimedia codec for use in error-prone, wireless networks. The scope of the present document are the changes, deletions, and additions to those texts necessary to fully specify a multimedia codec for use in 3GPP networks. Note that this implicitly excludes the network interface and call setup procedures. Also excluded are any general introductions to the system components.
Up

2  References  p. 5

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.
[1]
ITU-T Recommendation H.223: "Multiplexing protocol for low bit rate multimedia communication".
[2]
ITU-T Recommendation H.223 - Annex A: "Multiplexing protocol for low bit rate multimedia mobile communication over low error-prone channels".
[3]
ITU-T Recommendation H.223 - Annex B: "Multiplexing protocol for low bit rate multimedia mobile communication over moderate error-prone channels".
[4]
ITU-T Recommendation H.223 - Annex C: "Multiplexing protocol for low bit rate multimedia mobile communication over highly error-prone channels".
[5]
ITU-T Recommendation H.223 - Annex D: "Optional multiplexing protocol for low bit rate multimedia mobile communication over highly error-prone channels".
[6]
ITU-T Recommendation H.245: "Control protocol for multimedia communication".
[7]
ITU-T Recommendation G.723.1: "Dual rate speech coder for multimedia communication transmitting at 5,3 and 6,3 kbit/s".
[8]
ITU-T Recommendation H.263: "Video coding for low bitrate communication".
[9]
ITU-T Recommendation H.261: "Video CODEC for audiovisual services at px64 kbit/s".
[10]
ITU-T Recommendation H.324: "Terminal for low bitrate multimedia communication".
[11]
TS 26.110: "Codec for Circuit Switched Multimedia Telephony Service; General description".
[12]
TR 26.911: "Codec for circuit switched multimedia telephony service; terminal implementor's Guide (Release 4)".
[13]
ITU-T Recommendation X.691: "Information Technology - ASN.1 Encoding Rules - Specification of Packed Encoding Rules (PER)".
[14]
ISO/IEC 14496-2: "Information technology - Coding of audio-visual objects - Part 2: Visual".
[15]
TS 26.071: "General description".
[16]
TS 26.090: "Transcoding functions".
[17]
TS 26.073: "Adaptive Multi-Rate (AMR); ANSI C source code".
[18]
TS 26.171: "AMR Wideband Speech codec; General Description".
[19]
ITU-T Recommendation H.264 (2003): "Advanced video coding for generic audiovisual services" | ISO/IEC 14496-10:2003: "Information technology - Coding of audio-visual objects - Part 10: Advanced Video Coding".
[20]
ITU-T Recommendation H.241 (2003): "Extended video procedures and control signals for H.300 series terminals".
[21]
ITU-T Recommendation G.722.2 Annex F (2002): "AMR-WB usage in H.245".
[22]
TS 26.201: : "Adaptive Multi-Rate - Wideband (AMR-WB) speech codec ; Frame Structure."
Up

3  Definitions and abbreviations  p. 6

3.1  Definitions  p. 6

For the purposes of the present document, the following terms and definitions apply:
H.324:
ITU-T H.324 [10] with Annex C
3G-324M terminal:
based on ITU-T H.324 [10] recommendation modified by 3GPP for purposes of 3GPP circuit switched network based video telephony

3.2  Abbreviations  p. 6

For the purposes of the present document, the following abbreviations apply:
AMR
Adaptive Multi-Rate
AMR-WB
AMR Wide-Band
AVC
Advanced Video Codec
FLC
Fixed Length Code
RVLC
Reverse Variable Length Code
DP
Data Partitioning
RM
Resynchronization Marker
MCU
Multipoint Control Unit

4  General  p. 6

The present document contains any deviations to ITU-T H.324 [10] required for the specification of 3G-324M Terminals.

5  Document structure  p. 6

The structure of H.324 [10] is followed in the present document. Where there are no differences in a specific section, that section is skipped. Where differences are minor, only the differences are described. Where major differences exist, the section is rewritten in the present document. It is important to note that for wireless terminals, Annex C of H.324 [10] supersedes respective portions of the main body of H.324 [10] For the present document, these modifications are treated as if they are part of the main body of H.324 [10] Therefore, a reader must keep in mind both the main body and Annex C of H.324 [10] when reading the present document.
Up

6  Functional requirements  p. 7

6.1  Required elements  p. 7

3G-324M implementations are not required to have each functional element except a wireless interface, H.223 [1] with Annex A and B multiplex, and H.245 [6] version 3 or later versions for system control protocol.
3G-324M terminals offering audio communication shall support the AMR audio codec. Support for G.723.1 [7] is not mandatory, but recommended.
3G-324M terminals offering video communication shall support the H.263 [8] video codec. Support for MPEG-4 simple profile and H.261 [9] is optional.
3G-324M terminals shall support H.223 [1] with annex A and annex B.
3G-324M terminals shall support at least 32 kbit/s minimum bit rate at the mux to wireless network interface.
Up

6.2  Information streams  p. 7

V.25ter discussion does not apply.

6.3  Modem  p. 7

Does not apply.

6.4  Multiplex  p. 7

3G-324M terminals shall support H.223 [1] with Annex A and Annex B. All other aspects shall follow H.324 [10] with Annex C. H.223 [1] Annex C and D are optional.

6.5  Control channel  p. 7

No differences with H.324 [10].
Should it not be possible to signal an element of the 3G-324M terminal using a published version of H.245 [6], a procedure will be defined here.

6.6  Video channels  p. 7

Support for H.261 [9] is optional.
Support for MPEG-4 Visual is optional. When supported, MPEG-4 Visual codecs shall support Simple Profile @ Level 0. The FLC code 0000 1000 in Table G-1 - "FLC table for profile_and_level_indication" in ISO/IEC 14496-2 [14] is assigned to it. Additional information can be found in [14].
MPEG-4 Visual Simple Profile @ level 0 provides error concealment as part of the simple profile through Data Partitioning (DP), Reversible Variable Length Coding (RVLC), Resynchronization Marker (RM) and header extension code. MPEG-4 Visual is baseline compatible with H.263 [8].
When opening a logical channel for MPEG-4 Visual, configuration information (Visual Object Sequence Header, Visual Object Header, and Video Object Layer Header) shall be sent in the decoderConfigurationInformation parameter. The same information shall also be sent in the MPEG-4 video bitstream. If the operational mode of MPEG 4 Visual encoder needs to be changed, the existing MPEG-4 video logical channel shall be closed and H.245 [6] procedures for opening a new MPEG-4 video logical channel shall be started. The new operational mode shall be indicated in the parameters of the new logical channel.
Support for H.264 (MPEG-4 AVC) [19] is optional. When supported, H.264 codecs shall support Baseline level 1, without requirements on output timing conformance (Annex C of [19]).
Support for H.264 [19] shall be signalled according to H.241 chapter 8 "Capability Exchange signalling" [20].
When opening a logical channel for H.264 [19], initial sequence parameter set(s) and picture parameter set(s) should be sent in a H.264 DecoderConfigurationInformation (DCI) defined in Table 1 below, amending H.241 parameters [20]. Additionally, decoder capabilities may be sent in a H.264 AcceptRedundantSlices and a H.264 ProfileIOP defined in Table 2 and 3 below, amending H.241 parameters [20].
A sequence parameter set or a picture parameter set with a particular value of seq_parameter_set_id or pic_parameter_set_id, respectively, sent in the H.264 [19] DCI shall be identical to the earliest occurrence of the sequence parameter set or picture parameter set with the same value of seq_parameter_set_id or pic_parameter_set_id, respectively, sent in the H.264 bitstream.
If DCI was used when a H.264 [19] logical channel was opened and H.264 sequence parameter sets need to be changed or new sets need to be added during the session, the existing H.264 logical channel shall be closed and H.245 [6] procedures for opening a new H.264 logical channel shall be started, in which sequence parameter set(s) and picture parameter set(s) shall be sent in a DCI. Each sequence parameter set of H.264 [19] shall contain the vui_parameters syntax structure including the num_reorder_frames syntax element set equal to 0.
If H.264 picture parameter sets need to be changed or new sets need to be added during a session, it may be done either by opening a new logical channel using the same procedure as described above or within the current channel, by including picture parameter set NAL units directly in the bitstream.
Parameter nameDecoderConfigurationInformation
Parameter descriptionThis is a nonCollapsing GenericParameter.
DecoderConfigurationInformation indicates how to configure the decoder for a particular H.264 video sequence [19]. It contains sequence parameter set NAL units, picture parameter set NAL units, or both, using the byte stream format specified in Annex B/H.264, separating NAL units with a start code. The use of a start code before the first parameter set NAL unit is optional.
Parameter identifier value43
Parameter statusOptional. Shall not be present for Capability Exchange and Mode Request. May be present exactly once for Logical Channel Signalling.
Parameter typeOctetString
Supersedes-
A decoder may indicate its' capability to make use of H.264 redundant slices by the following parameter.
Parameter nameAcceptRedundantSlices
Parameter descriptionThis is a collapsing GenericParameter.
AcceptRedundantSlices indicates the capability to use H.264 redundant slices and corresponds to the MIME video/H264 parameter "redundant-pic-cap".
When False or when the parameter is not present, it indicates that the receiver makes no attempt to use redundant coded pictures to correct incorrectly decoded primary coded pictures and a sender should not send redundant slices.
When True, it indicates that the receiver is capable of decoding any such redundant slice that covers a corrupted area in a primary decoded picture (at least partly), and a sender may send redundant slices.
When using a H.264 profile (or subset of a profile as indicated by the H.264 ProfileIOP parameter defined in Table 3) and level that disallows the use of redundant slices, this parameter shall be ignored.
Parameter identifier value44
Parameter statusOptional. May be present exactly once for Capability Exchange Signalling.
Parameter typeLogical
Supersedes-
A decoder may indicate additional limitations that only the common subset of the algorithmic features and limitations of the Baseline level 1 are supported by the following parameter.
Parameter nameProfileIOP
Parameter descriptionProfileIOP indicates that the capability to decode H.264 streams is limited to a common subset of the algorithmic features included in the indicated profile and level.
This parameter is a Boolean array.
bit 1 (value 128) is constraint_set0_flag.
bit 2 (value 64) is constraint_set1_flag.
bit 3 (value 32) is constraint_set2_flag.
All other bits are reserved, shall be set to 0, and shall be ignored by receivers.
constraint_set0_flag, constraint_set1_flag and constraint_set2_flag are defined in [18].
As an example, a receiver indicating decoding support of the intersection of the baseline and main profile will signal value 11000000 (constraint_set0_flag = 1, constraint_set1_flag = 1, constraint_set2_flag = 0).
Parameter identifier value46
Parameter statusOptional. May be present exactly once for Capability Exchange Signalling.
Parameter typeBooleanArray
Supersedes-
A terminal supporting H.264 encoding should respond to all videoFastUpdatePicture commands received via the H.245 control channel. If an H.264 encoder responds to videoFastUpdatePicture, it shall use the procedure specified in subclause 6.2.2 of H.241.
A terminal supporting H.264 shall start decoding immediately when it receives data (even if the stream does not start with an IDR access unit) or alternatively no later than it receives the next IDR access unit or the next recovery point SEI message, whichever is earlier in decoding order. The decoding process for a stream not starting with an IDR access unit shall be the same as for a valid H.264 bitstream. However, the client shall be aware that such a stream may contain references to picture not available in the decoded picture buffer. The display behaviour of the client is out of scope of this specification.
Up

6.6.1  MPEG-4 interface to multiplex  p. 10

As H.263 [8] encoders align picture start codes with the start of an AL-SDU, the same concept applies to MPEG-4 encoders. The following are the requirements of the MPEG-4 interface to the H.223 [1] multiplex.
  1. Each 3G-324M MPEG-4 encoder shall align each visual_object_sequence_start_code with the start of an AL-SDU.
  2. Each 3G-324M MPEG-4 encoder shall align each group_of_vop_start_code (the beginning of a GOV field) with the start of an AL-SDU unless the GOV field immediately follows configuration information.
  3. Each 3G-324M MPEG-4 encoder shall align each vop_start_code with the start of an AL-SDU unless the vop_start_code immediately follows configuration information or a GOV field.
In these requirements, GOV stands for Group_of_VideoObjectPlane() and Configuration information consists of Visual Object Sequence Header, Visual Object Header, and Video Object Layer Header.
Up

6.6.2  H.264 (MPEG-4 AVC) interface to multiplex  p. 10

Shall conform to the byte stream format according to H.241 chapter 7.1.5 "Transport of H.264 streams in H.324 systems" [20].
More strict alignment of AL-SDU and NAL units may optionally be used. To signal capability for and use of this mode, the generic parameter described in Table 3 shall be used, amending the H.264 Generic Capability in H.241 [20].
Parameter nameNalAlignedMode
Parameter descriptionThis is a collapsing GenericParameter.
NalAlignedMode indicates that every AL-SDU carrying H.264 shall contain an integer number of NAL units and that the start of the AL-SDU shall be aligned with the start of a NAL. Individual NAL units within the AL-SDU shall be separated by start codes as described in Annex B/H.264. The use of a start code before the first NAL in an AL-SDU is optional.
Parameter identifier value45
Parameter statusOptional. May be present exactly once for Capability Exchange, Logical Channel, or Mode Request Signalling.
Parameter typeLogical
Supersedes-
Up

6.7  Audio channels  p. 11

AMR is the mandatory speech codec. Support for G.723.1 [7] is not mandatory, but recommended. Support for AMR-WB [18] is also recommended.
When AMR-WB is supported, the AMR-WB speech data shall be carried in IF2 frame format as defined in Annex A of TS 26.201, and the signalling for AMR-WB shall be according to G.722.2 Annex F [21] with the following additional restrictions:
  • octetAlign shall be present
  • The following parameters are not compatible with IF2 frame format, and so shall not be used:
    • crc
    • robustSorting
    • interleaving
When both the receiving and transmitting terminals support multiple codecs in common, the use of AMR and AMR-WB is preferred:
  • If both the receiving and transmitting terminals support AMR and other codecs (e.g. G.723.1) but not AMR-WB, then AMR shall be used.
  • If both the receiving and transmitting terminals support AMR and other codecs including AMR-WB, either AMR or AMR-WB shall be used.
Asymmetric configurations with one codec in one direction and another one in the other direction (e.g. AMR in one direction and AMR-WB in the other direction) are allowed, if supported by both terminals.
This applies to connections without an Multipoint Control Unit (MCU).
Up

6.8  Data channels  p. 11

No differences with H.324 [10].

7  Terminal procedures  p. 11

See TS 26.110.

8  Optional enhancements  p. 11

No differences with H.324 [10].

9  Interoperation with other terminals  p. 11

For further study.

10  Multipoint considerations  p. 11

For further study.

11  Maintenance  p. 12

No differences with H.324 [10].

$  Change history  p. 13

Up   Top