Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 26.114  Word version:  18.5.0

Top   Top   Up   Prev   Next
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.6.4…   Y.6.5…   Y.7…

 

10.2.2  Example use casesp. 115

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.
Reproduction of 3GPP TS 26.114, Fig. 10.7: Flow of parameter sets for encoded frames
Up
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.
Reproduction of 3GPP TS 26.114, Fig. 10.8: Default frame aggregation with one frame per packet
Up
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.
Reproduction of 3GPP TS 26.114, Fig. 10.9: Payload packetization with 100% redundancy and an offset of one packet
Up
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.
Reproduction of 3GPP TS 26.114, Fig. 10.10: Payload packetization with 100% redundancy and an extra offset of one packet
Up
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.
Reproduction of 3GPP TS 26.114, Fig. 10.11: Payload packetization with 2 frames aggregated per packet
Up
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.
Reproduction of 3GPP TS 26.114, Fig. 10.12: Payload packetization with 100% redundancy and 2 frames aggregated per packet
Up
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.
Reproduction of 3GPP TS 26.114, Fig. 10.13: Payload packetization with 100% redundancy,  one extra offset and 2 frames aggregated per packet
Up

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

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.
Up

Up   Top   ToC