For the purposes of the present document, the following terms and definitions apply: 3G-324M terminal: 3G-324M codec: 3G-324M encoder: 3G-324M decoder:

(void)

For the purposes of the present document, the following abbreviations apply: AL1,2,3: AL-SDU: AMR: CIF: CRC: DCE: DTE: GOB: GSM: GSTN: ISDN: ITU-T: MONA: MUX-PDU: NSRP: PSC: QCIF: RVLC: SQCIF: SRP: T401: VOP: WNSRP:

H.223 multiplex transmission bit order is defined in H.223 [1] Sec 3.2.2 as LSB first. This first bit is transparently mapped to the first bit of "higher layer PDU" depicted in clause 5.3.5 of TS 25.301, and vice versa. An example is given by the following Figure:

3G-324M decoders should ignore any drawing order information as signalled by ITU-T Recommendation H.245 [5] drawingOrder Capability, see Table E.5 in ITU-T Recommendation H.245 [5], if the MPEG-4 simple profile level 1 is used.

Regardless of which specific video codec standard is used, all video decoder implementations should include basic error concealment techniques. These techniques may include replacing erroneous parts of the decoded video frame with interpolated picture material from previous decoded frames or from spatially different locations of the erroneous frame. The decoder should aim to prevent the display of substantially corrupted parts of the picture. In any case, it is recommended that the terminal should tolerate every possible bitstream without catastrophic behaviour (such as the need for a user-initiated reset of the terminal). 3G-324M encoders and decoders are recommended to support the 1:1 pixel format (square format) . Encoders should signal this capability using ITU-T Recommendation H.245 [5] capability exchange and the appropriate header fields in video codecs so that unnecessary pixel shape conversions can be avoided.

Several of the optional annexes of ITU-T Recommendation H.263 [9] are useful for improving the compression efficiency and error resilience of the codec. The annexes below form a balanced set of tools with respect to error robustness, compression efficiency, quality, and complexity. It is recommended that an ITU-T Recommendation H.263 [9] video decoder should support the following annexes. The main feature of each annex is also mentioned:

• Annex I (Advanced Intra Coding), improves error resilience and compression efficiency.
• Annex J (Deblocking Filter), improves compression efficiency.
• Annex K (Slice Structure Mode, without RS submode), improves error resilience.
• Annex T (Modified Quantizer), improves compression efficiency.

Non-empty GOB headers should be used frequently to improve error resilience (see [6], Clause 5.2). ITU-T Recommendation H.263 [9] encoders in 3G-324M terminals should respond to all videoFastUpdate commands received via the ITU-T Recommendation H.245 [5] control channel (i.e., videoFastUpdatePicture, videoFastUpdateGOB, and videoFastUpdateMB presented in clause 7.11.5 of [2] Version 3). Using this feedback information to make a focused picture update can significantly improve the error performance of the codec. 3G-324M decoders are correspondingly recommended to transmit videoFastUpdate commands when the received picture is detected to be significantly corrupted due to transmission errors. It is recommended that ITU-T Recommendation H.263 [9] decoders take advantage of the GOB and slice header GOB Frame ID (GFID) field in recovering corrupted picture header data (see Clauses 5.2.5 and K.2 of ITU-T Recommendation H.263 [9] recommendation version 2). For this purpose it is recommended that ITU-T Recommendation H.263 [9] encoders should not use the Rounding Type (RTYPE) bit of the extended picture header as described in Clause 5.1.4.3 of [1]. The RTYPE bit should always be set to 0 since it otherwise effectively prevents the use of the GFID field for picture header recovery.

It is recommended that all 3G-324M terminals additionally support the ISO/IEC 14496-2 [14] (MPEG-4 Visual) video codec [11]. The explanatory text below gives justification and further detail for this recommendation. One of the main target environments for MPEG-4 Visual is mobile use. For this purpose the following error resilient techniques have been adopted in MPEG-4 Visual: Resynch Marker, Header Extension Code, Data Partitioning, and Reversible Variable Length Code. With these techniques MPEG 4 Visual codec can be used over errorprone channels enabling highly efficient low delay multimedia communication services for 3G networks. Support for MPEG-4 Visual potentially provides capabilities for communicating with heterogeneous networks without transcoding, or reusing pictures/video from 3G multimedia telephony service by different applications and vice versa. MPEG-4 Visual and ITU-T Recommendation H.263 [9] have substantial technical similarities. MPEG-4 Visual also includes support for the ITU-T Recommendation H.263 [9] baseline codec. Because of multi-functionality of MPEG-4 Visual, subsets of different tools have been defined in order to allow effective implementations of the standard. These subsets, called "Profiles", limit the tool set which shall be implemented. For each of these Profiles one or more Levels have been set to restrict the computational complexity of implementations. It is here recommended that the Simple Visual Profile @ Level 0 is supported to achieve adequate error resilience for transmission error and low complexity simultaneously. No other Profiles are recommended to be supported. Higher Levels for the Simple Visual Profile may be supported depending on the terminal capabilities. MPEG-4 Visual accepts various sizes of input picture within the capability specified from the Profile and Level. Picture size of QCIF for Level 1 should be used for the sake of interoperability. All of the error resilience tools in Simple Visual Profile are recommended to be activated. Resync Marker is a tool which increases the opportunities for the decoder to resynchronize with the bitstream and after loss of synchronization due to errors in the bitstream, thus enabling normal decoder operation to continue. The encoder should insert Resync Marker in the bitstream, in order to enable the decoder to search for the Resync Marker in addition to the Start Code. Header Extension Code (HEC) enables independent decoding of each video packet. One or more than one video packet in a VOP should have HEC in order for. the decoder to utilize information derived from HEC, to avoid discarding a whole VOP when the VOP header could not be received. Data Partitioning is a tool that separates the information within a video packet to improve the degree of error localization and concealment. When the decoder detect errors in a video packet, the decoder may not discard whole the packet if themotion information or the I-VOP DC coefficients are decoded correctly. The decoder may reconstruct the corresponding part of the picture utilizing the above motion information or DC coefficients. The encoder should use Data Partitioning syntax in order to enable the decoder the above operation. Reversible Variable Length Code (RVLC) is a tool which reduce the number of discarded bits.. RVLC decoding operation as described in clause E.1.4 of Annex E in [11] may be performed. The encoder should utilize RVLC to enable the decoder to perform such operation. In addition to these tools, Intra Refresh should be inserted in order to prevent inter-frame propagation of errors. Adaptive Intra Refresh (AIR) described in clause E.1.5 in Annex E of [11] should be used in conjunction with cyclic Intra Refresh. One Video Packet of MPEG-4 Visual should be mapped to one AL-SDU of ITU-T Recommendation H.223 [1] Adaptive Layer. When an incoming bi-directional openLogicalChannel request has unsuitable reverse parameters for the local encoder, e.g., unsuitable MPEG-4 decoderConfigurationInformation, the terminal should reject the request. The cause field of openLogicalChannelReject should be set to value unsuitableReverseChannelParameters. A new openLogicalChannel request should be sent to the other end, now using the forward channel parameters of the rejected request as reverse channel parameters, and specifying new preferred forward channel parameters. All MPEG-4 encoders should accept and respond to ITU-T Recommendation H.245 [5] videoTemporalSpatialTradeOff commands. Support for temporal-spatial trade-off cannot be signaled for MPEG-4 encoders, but the encoders should provide that support by default. MPEG-4 decoders are encouraged to utilize the videoTemporalSpatialTradeOff command. The specific response to the TemporalSpatialTradeOff command by MPEG-4 encoders is not defined and it is up to the implementation to decide how to respond to the command.

FFS. This clause will include guidance on how to utilize the different modes of the AMR codec.

FFS.

It is recommended that terminals additionally support the ITU-T Recommendation G.723.1 [8] audio codec [5] when it is expected that interoperability with GSTN is needed, because it cannot be guaranteed that ITU-T Recommendation H.324 [7] terminals developed for GSTN use will support the AMR codec.