Content for TS 26.114 Word version: 18.1.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.7…

10.2.2 Example use cases 10.2.3 SDP negotiation for RTCP-APP
...

10.2.2 Example use cases p. 114

The following examples demonstrate how requests for redundancy and frame aggregation are realised in the RTP stream.

All examples assume that the speech codec generates frames numbered N-10…N in a continuous flow.

Copy of original 3GPP image for 3GPP TS 26.114, Fig. 10.7: Flow of parameter sets for encoded frames

Figure 10.7: Flow of parameter sets for encoded frames
(⇒ copy of original 3GPP image)

Each increment corresponds to a time difference of 20 ms

In the examples below, P-1…P denote the sequence numbers of the packets.

EXAMPLE 1:

An RTCP_APP_REQ_RED request with bit field 000000000000 (no redundancy) and RTCP_APP_REQ_AGG request with value = 0 (no frame aggregation) will yield packets as shown in Figure 10.8.

Copy of original 3GPP image for 3GPP TS 26.114, Fig. 10.8: Default frame aggregation with one frame per packet

Figure 10.8: Default frame aggregation with one frame per packet
(⇒ copy of original 3GPP image)

EXAMPLE 2:

An RTCP_APP_REQ_RED request with bit field 000000000001 (100% redundancy and no offset) and an RTCP_APP_REQ_AGG request with value = 0 (no frame aggregation) will yield packets as shown in Figure 10.9.

Copy of original 3GPP image for 3GPP TS 26.114, Fig. 10.9: Payload packetization with 100% redundancy and an offset of one packet

Figure 10.9: Payload packetization with 100% redundancy and an offset of one packet
(⇒ copy of original 3GPP image)

EXAMPLE 3:

An RTCP_APP_REQ_RED request with bit field 000000000010 (100% redundancy with offset 1 extra packet) and an RTCP_APP_REQ_AGG request with value = 0 (no frame aggregation) will yield packets as shown in Figure 10.10.

Copy of original 3GPP image for 3GPP TS 26.114, Fig. 10.10: Payload packetization with 100% redundancy and an extra offset of one packet

Figure 10.10: Payload packetization with 100% redundancy and an extra offset of one packet
(⇒ copy of original 3GPP image)

NO_DATA frames must be inserted to fill the gaps between two non-consecutive frames, e.g. between N-2 and N.

EXAMPLE 4:

An RTCP_APP_REQ_RED request with bit field 000000000000 (no redundancy) and RTCP_APP_REQ_AGG request with value = 1 (frame aggregation 2 frames/packet) will yield packets as shown in Figure 10.11.

Copy of original 3GPP image for 3GPP TS 26.114, Fig. 10.11: Payload packetization with 2 frames aggregated per packet

Figure 10.11: Payload packetization with 2 frames aggregated per packet
(⇒ copy of original 3GPP image)

EXAMPLE 5:

An RTCP_APP_REQ_RED request with bit field 000000000001 (100% redundancy) and an RTCP_APP_REQ_AGG request with value = 1 (frame aggregation 2 frames/packet) will yield packets as shown in Figure 10.12.

Copy of original 3GPP image for 3GPP TS 26.114, Fig. 10.12: Payload packetization with 100% redundancy and 2 frames aggregated per packet

Figure 10.12: Payload packetization with 100% redundancy and 2 frames aggregated per packet
(⇒ copy of original 3GPP image)

EXAMPLE 6:

An RTCP_APP_REQ_RED request with bit field 000000000010 (100% redundancy with offset 1 extra packet) and an RTCP_APP_REQ_AGG request with value = 1 (frame aggregation 2 frames/packet) will yield packets as shown in Figure 10.13.

Copy of original 3GPP image for 3GPP TS 26.114, Fig. 10.13: Payload packetization with 100% redundancy, one extra offset and 2 frames aggregated per packet

Figure 10.13: Payload packetization with 100% redundancy, one extra offset and 2 frames aggregated per packet
(⇒ copy of original 3GPP image)

10.2.3 SDP negotiation for RTCP-APP |R12| p. 116

RTCP-APP request messages that can be used are negotiated with SDP using the '3gpp_mtsi_app_adapt' attribute. The syntax for the 3GPP MTSI RTCP-APP adaptation attribute is:

a=3gpp_mtsi_app_adapt:<reqNames>

where:

<reqNames> is a comma-separated list identifying the different request messages (see below).

The ABNF for the RTCP-APP adaptation messages negotiation attribute is the following:

adaptation attribute = "a" "=" "3gpp_mtsi_app_adapt" ":" reqName *("," reqName)
reqName = "RedReq" /
          "FrameAggReq" /
          "AmrCmr" /
          "EvsRateReq" /
          "EvsBandwidthReq" /
          "EvsParRedReq" /
          "EvsIoModeReq" /
          "EvsPrimaryModeReq"

The name denotes the RTCP APP packet types the SDP sender supportes to receive. The meaning of the values is as follows:

RedReq:

Redundancy Request, clause 10.2.1.3

FrameAggReq:

Frame Aggregation Request, clause 10.2.1.4

AmrCmr:

Codec Mode Request for AMR and AMR-WB, clause 10.2.1.5

EvsRateReq:

EVS Primary Rate Request, clause 10.2.1.7

EvsBandwidthReq:

EVS Bandwidth Request, clause 10.2.1.8

EvsParRedReq:

EVS Partial Redundancy Request, clause 10.2.1.9

EvsIoModeReq:

EVS Primary mode to EVS AMR-WB IO mode Switching Request, clause 10.2.1.10

EvsPrimaryModeReq:

EVS AMR-WB IO mode to EVS Primary mode Switching Request, clause 10.2.1.11

An MTSI client supporting the reception of any RTCP APP packets defined in the present specification shall indicate the supported RTCP APP packet types in an initial SDP offer or answer it sends using the SDP "a=3gpp_mtsi_app_adapt" attribute. If the answerer receives an "a=3gpp_mtsi_app_adapt" attribute in the SDP offer, it may send the indicated RTCP APP packet types towards the offerer. The answerer shall indicate its capabilties with the "a=3gpp_mtsi_app_adapt" attribute irrespective if an "a=3gpp_mtsi_app_adapt" attribute was received and the capabilities within. If the offerer receives an "a=3gpp_mtsi_app_adapt" attribute in the SDP answer, it may send the indicated RTCP APP packet types towards the answerer.

An MTSI client supporting only AMR and AMR-WB therefore may for instance include the following in the SDP offer:

a=3gpp_mtsi_app_adapt: RedReq,FrameAggReq,AmrCmr

An MTSI client supporting only AMR, AMR-WB and EVS may for instance include the following in the SDP offer:

a=3gpp_mtsi_app_adapt: RedReq,FrameAggReq,AmrCmr,EvsRateReq,EvsBandwidthReq,EvsParRedReq,EvsIoModeReq,EvsPrimaryModeReq

The attribute shall only be used on media level.

When interworking with pre-Rel-12 clients or non-MTSI clients, it may happen that they support the RTCP-APP signalling but not the SDP negotiation for AMR and AMR-WB. An MTSI client failing to negotiate RTCP-APP as described may still try to use the RTCP-APP signalling when requesting adaptation, but the MTSI client shall then also monitor the received media in order to determine if some or all of the adaptation requests included in the RTCP-APP were partially or fully followed or not followed at all. If none of the adaptation requests is followed, not even partially, then this is an indication that the remote client does not support the RTCP-APP signalling. The MTSI client should then try to use other means for triggering the adaptation, for example CMR in the AMR/AMR-WB payload or RTCP Sender Reports/Receiver Reports.