S.6 Media transport

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

S.6.1 RTP

An MSMTSI client shall be capable of receiving multiple, separate RTP streams [9] related to a single SIP dialog and route them to the correct decoder based on RTP SSRC, RTP Payload Type, and any "a=content" information in the SDP. The number of RTP streams used in each direction and for each media type is limited to what is negotiated by SDP offer/answer for that SIP dialog, allowing the involved MSMTSI clients to express a limit to the number of streams they can handle simultaneously.

An MSMTSI client in terminal shall be capable of relating received RTP SSRC and CSRC with information from the conference event information (clause S.4), to enable indicating the identity of the RTP stream source. If a received RTP SSRC has no match in the conference event information, and if RTP CSRC is present, CSRC shall also be matched against conference event information. It is left up to MSMTSI client implementation what RTP stream source identification to use if neither SSRC nor CSRC can be matched against conference event information.

S.6.2 RTCP

An MSMTSI client in the terminal shall, as an MTSI client in the terminal, be capable to receive RTCP feedback (FIR, PLI, TMMBR, etc) [40][43] and respond accordingly, but shall also be capable to identify which sent RTP stream (SSRC) the RTCP feedback targets and direct it to the appropriate encoder.

An MSMTSI client shall support RTP-level pause and resume functionality according to [156] for all of its RTP streams, with the exception of the main audio stream from an MSMTSI client in terminal towards an MSMTSI MRF, which is not required to (but may) support RTP-level pause and resume functionality. An MSMTSI client shall be capable of restricting its use of RTP-level pause and resume functionality according to received pause/resume config parameter information in SDP, including not using it at all if that is the negotiation outcome.

An MSMTSI client in terminal shall support RTP-level pause and resume functionality at least corresponding to config=3, and should support full RTP-level pause and resume functionality corresponding to config=1.

An MSMTSI MRF shall support RTP-level pause and resume functionality at least corresponding to config=2, and should support full RTP-level pause and resume functionality corresponding to config=1.

S.6.3 RTP Stream Selective Forwarding

When a conference includes a large number of terminals or participants, the size of the SDP Offer listing the concurrent codec capabilities (CCC) using multiple m= lines can increase considerably. To reduce the size of the SDP offer when a conference includes a large number of participants, RTP-level selective forwarding by the MSMTSI MRF shall support RTP pause/suspend, reuse, replace, and resume actions. This RTP-level "suspend, resuse, replace, and resume" action is described using an example in Clause 6.13.4.2, TR 26.980 [152].

In the SDP Offer the MSMTSI MRF may use fewer downlink m= lines, corresponding to dynamically selected streams even though there are large number of participants or terminals in the MSMTSI session.

To support RTP stream selective forwarding when some participants in a conference supports both the "common" and one or more "preferred" codecs while other participants support only the "common" codec, certain conditions need to be fulfilled for MSMTSI clients both in the terminal and in MSMTSI MRF. This is described below.

The MSMTSI MRF should construct the SDP Offer such that the downlink RTP stream from one participant fits sufficiently well with the capabilities of another participant such that the same downlink m= line can be used for RTP stream selective forwarding. For this, the MSMTSI MRF should pre-anlayze the CCCEx (e.g., based on SIP OPTIONS) and construct sub-groups of participants that can share a given m= line with a given set of "preferred" and "common" codecs in the simulcast.

An MSMTSI client in terminal that supports both "common" and "preferred" codecs for a media type shall support concurrent encoding, sending simulcast [155], and concurrent decoding, with more than a single one codec for every sending media source ("m=" line) of that media type. An MSMTSI MRF that supports both "common" and "preferred" codecs for a media type shall support receving simulcast with more than a single codec for every received media source ("m=" line) of that media type.

An MSMTSI client in terminal that supports both "common" and "preferred" codecs for a media type shall be capable to receive media using any one of those codecs, even if the used codec (RTP payload type) is changing from one RTP packet to the next, for all received media sources ("m=" lines) of that media type. This capability to receive RTP payload type changing from one RTP packet to the next is indicated by accepting payload types with both "common" and "preferred" codecs from the SDP offer in the SDP answer. This way, no SDP re-negotiation is needed to change codec between the ones included in the answer. This ability to support RTP payload type changes every RTP packet is an essential part of the receiving end of a codec simulcast scenario, and shall be explicitly indicated in SDP by including "a=simulcast" with the supported codecs as simulcast format alternatives, even if it means that only a single simulcast stream with alternatives is listed in simulcast receive direction.

An MSMTSI client in the terminal that negotiated receiving simulcast with different codecs and that receives a set of such simulcast streams, can dynamically choose which simulcast stream to decode and should use the best quality simulcast stream that is available.

An MSMTSI MRF that negotiated sending simulcast with a set of different codecs and that needs to forward streams using those codecs, may change RTP payload type within that set in its sent stream at any point in time, as needed to support the communication scenario and forwarding strategy used by the MSMTSI MRF.

The MSMTSI MRF should take action to allow decoder memories to clear when replacing one RTP stream with another RTP stream during switching, to avoid media distortion in the receiving MSMTSI client in the terminal. To enable this, it is currently necessary for the MSMTSI MRF to know the RTP payload format of the used codecs, even if no transcoding is needed. The MSMTSI MRF should therefore, before suspending forwarding of RTP stream A and replacing it by instead forwarding RTP stream B:

– For speech

– Replace the content of a few RTP packet payloads from RTP stream A with a few silence indication (SID) or discontinuous transmission (DTX) frames for the used codec

– For video

– Take assistance from the sender of RTP stream B, asking for a decoder refresh point by sending RTCP FIR to that RTP stream B sender

– Continue forwarding RTP stream A while monitoring RTP stream B for decoder refresh points

– From the point where a decoder refresh point is received in RTP stream A, suspend forwarding of RTP stream A and replace it by forwarding RTP stream B