14 Supplementary services

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

14.1 General

In this section media layer behaviour is specified for relevant supplementary services. The supplementary services included in MTSI are described in TS 24.173 [57]. The requirements on the codec support and the data transport are identical to those listed in clauses 5.2 and 7. These requirements are listed here due to the fact that there might be other media‑influencing nodes in MTSI whose behaviour is not explicitly covered by other parts of the present document.

The recommended behaviour described in the following sections is valid for MTSI clients, i.e. all session IP end-points; terminals, MTSI media gateways and other 3GPP network nodes acting as IP endpoints in MTSI sessions.

14.2 Media formats and transport

Any implementation of a supplementary service which affects media or media handling, e.g. such as media creation, media rendering and media manipulation, shall meet the same requirements as a MTSI client in terminal regarding codec support and codec usage. Where applicable,, speech codecs shall be supported according to clause 5.2.1, video according to clause 5.2.2 and text according to clause 5.2.3.

Similarly, the configuration and the transport of the media in any implementation of a supplementary service which affects media or media handling shall be done according to clause 7.

14.3 Media handling in hold procedures

Whenever a supplementary service includes a hold procedure according to RFC 3264 [58], e.g. when using the HOLD supplementary service, the media flow is changed in terms of the session flow attribute (e.g. changing the session attribute "sendrecv" into "sendonly" or "recvonly" or "inactive" and then back again). When this occurs, any involved media-originating or media-terminating node should take measures to ensure that the transitions between the different media flow states in the session occur with minimal impact on the media quality.

When a full-duplex session has put the media flow on hold (see section 8.4 in RFC 3264 [58]), the media flow has been changed into a unidirectional flow through changing the session attribute into either "sendonly" or "recvonly". When resuming the session, it is restored to full duplex by changing the flow attributes back into "sendrecv" from "sendonly" and "recvonly". In this case, the encoder and decoder states in the MTSI clients may not be aligned and a state mismatch could occur. This would result in media quality degradation. Therefore, the following actions are recommended whenever the media session is not being put on hold anymore and the session is restored to full duplex:

– for speech media, the speech decoders should be reset;

– for video media, the video encoders should start the updated session with a full infra refresh even if the previously allocated encoders are still active and no infra refresh is scheduled to be sent.