Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

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

 

6  Media configurationp. 38

6.1  Generalp. 38

MTSI uses SIP, SDP and SDPCapNeg for media negotiation and configuration. General SIP signalling and session setup for IMS are defined in TS 24.229, whereas this clause specifies SDP and SDPCapNeg usage and media handling specifically for MTSI, including offer/answer considerations in the capability negotiation. The MTSI client in the terminal may use the OMA-DM solution specified in clause 15 for enhancing SDP negotiation and resource reservation process.
The support for ECN (RFC 3168) in E-UTRAN is specified in TS 36.300. The support for ECN in UTRA/HSPA is specified in TS 25.401. The support of ECN in NR is specified in TS 38.300. MTSI may use Explicit Congestion Notification (ECN) to perform rate adaptation for speech and video. When the MTSI client in terminal supports, and the session allows, adapting the media encoding at multiple bit rates and the radio access bearer technology is known to the MTSI client to be E-UTRAN or UTRA/HSPA, the MTSI client may negotiate the use of ECN (RFC 3168) to perform ECN triggered media bit-rate adaptation. An MTSI MGW supporting ECN supports ECN in the same way as the MTSI client in terminal as described in clauses 12.3.3 and 12.7.3.
The support of ECN is optional for both MTSI client in terminal and MTSI MGW.
It is assumed that the network properly handles ECN-marked packets as described in RFC 6679 end-to-end between the MTSI clients in terminals.
An MTSI MGW can be used for inter-working with:
  • a client that does not use ECN;
  • a client that supports ECN in different way than what is specified for MTSI clients;
  • a CS network;
  • a network which does not handle ECN-marked packets properly.
In such cases, the ECN protocol, as specified for MTSI clients, is terminated in the MTSI MGW.
Up

6.2  Session setup proceduresp. 38

6.2.1  Generalp. 38

The session setup for RTP transported media shall determine for each media: IP address(es), RTP profile, UDP port number(s); codec(s); RTP Payload Type number(s), RTP Payload Format(s). The session setup may also determine: ECN usage and any additional session parameters.
The session setup for UDP transported media without RTP shall determine: IP address(es), UDP port number(s) and additional session parameters.
The session setup for data channel (SCTP over DTLS over UDP transported) media shall determine for each media: IP address(es), UDP port number(s), SCTP port number(s), DTLS server/client role(s), DTLS ID(s), DTLS certificate fingerprint(s), and ICE-related information for data channel media as described in clause 6.2.10. The session setup may also determine use of ICE Lite for data channel media and may determine additional session parameters.
The session setup for RTP and data channel transported media shall, when the port number is not set to zero, determine the maximum bandwidth that is allowed in the session, see also clause 6.2.5. The maximum bandwidth for the receiving direction is specified with the "b=AS" bandwidth modifier. Additional requirements and/or recommendations on the bandwidth negotiation are found in clause 6.2.2.1 for speech, in clause 6.2.3.2 for video, and in clause 6.2.10 for data channel.
An MTSI client shall offer at least one RTP profile for each RTP media stream. Multiple RTP profiles may be offered using SDPCapNeg as described in clause 6.2.1a. For voice and real-time text, the first SDP offer shall include at least the AVP profile. For video, the first SDP offer for a media type shall include at least the AVPF profile. Subsequent SDP offers may include only other RTP profiles if it is known from a preceding offer that this RTP profile is supported by the answerer. The MTSI client shall be capable of receiving an SDP offer containing both AVP and AVPF offers in order to support interworking.
The configuration of ECN for media transported with RTP is described in clause 6.2.2 for speech and in clause 6.2.3.2 for video. The negotiation of ECN at session setup is described in RFC 6679. The adaptation response to congestion events is described in clause 10.
Up

6.2.1a  RTP profile negotiationp. 39

6.2.1a.1  Generalp. 39

MTSI clients should support SDPCapNeg to be able to negotiate RTP profiles for all media types where AVPF is supported. MTSI clients supporting SDPCapNeg shall support the complete SDPCapNeg framework.
SDPCapNeg is described in RFC 5939. This clause only describes the SDPCapNeg attributes that are directly applicable for the RTP profile negotiation, i.e. the tcap, pcfg and acfg attributes. TS 24.229 may outline further requirements needed for supporting SDPCapNeg in SDP messages.
Up

6.2.1a.2  Using SDPCapNeg in SDP offerp. 39

For voice and real-time text, SDPCapNeg shall be used when offering AVPF the first time for a new media type in the session since the support for AVPF in the answering client is not known at this stage. For video, an MTSI client shall either offer AVPF and AVP together using SDPCapNeg, or the MTSI client shall offer only AVPF without using SDPCapNeg. If an MTSI client has offered only AVPF for video, and then receives as response either an SDP answer where the video media component has been rejected, or an SIP 488 or 606 failure response with an SDP body indicating that only AVP is supported for video media, the MTSI client should send a new SDP offer with AVP as transport for video. Subsequent SDP offers, in a re-INVITE or UPDATE, may offer AVPF without SDPCapNeg if it is known from an earlier re-INVITE or UPDATE that the answering client supports this RTP profile. If the offer includes only AVP then SDPCapNeg does not need to be used, which can occur for: text; speech if RTCP is not used; and in re-INVITEs or UPDATEs where the RTP profile has already been negotiated for the session in a preceding INVITE or UPDATE.
When offering AVP and AVPF using SDPCapNeg, the MTSI client shall offer AVP on the media (m=) line and shall offer AVPF using SDPCapNeg mechanisms. The SDPCapNeg mechanisms are used as follows:
  • The support for AVPF is indicated in an attribute (a=) line using the transport capability attribute 'tcap'. AVPF shall be preferred over AVP.
  • At least one configuration using AVPF shall be listed using the attribute for potential configurations 'pcfg'.
Up

6.2.1a.3  Answering to an SDP offer using SDPCapNegp. 39

An invited MTSI client should accept using AVPF whenever supported. If AVPF is to be used in the session then the MTSI client:
  • Shall select one configuration out of the potential configurations defined in the SDP offer for using AVPF.
  • Indicate in the media (m=) line of the SDP answer that the profile to use is AVPF.
  • Indicate the selected configuration for using AVPF in the attribute for actual configurations 'acfg'.
If AVP is to be used then the MTSI shall not indicate any SDPCapNeg attributes for using AVPF in the SDP answer.
Up

6.2.2  Speechp. 40

6.2.2.1  Generalp. 40

For AMR or AMR-WB encoded media, the session setup shall determine the applicable bandwidth(s) as defined in clause 6.2.5, what RTP profile to use; if all codec modes can be used or if the operation needs to be restricted to a subset; if the bandwidth-efficient payload format can be used or if the octet-aligned payload format must be used; if codec mode changes shall be restricted to be aligned to only every other frame border or if codec mode changes can occur at any frame border; if codec mode changes must be restricted to only neighbouring modes within the negotiated codec mode set or if codec mode changes can be performed to any mode within the codec mode set; the number of speech frames that should be encapsulated in each RTP packet and the maximum number of speech frames that may be encapsulated in each RTP packet. For EVS encoded media, the session setup shall determine the RTP profile to use in the session.
If the session setup negotiation concludes that multiple configuration variants are possible in the session then the default operation should be used as far as the agreed parameters allow, see clause 7.5.2.1. It should be noted that the default configurations are slightly different for different access types.
An MTSI client offering a speech media session for narrow-band speech and/or wide-band speech should generate an SDP offer according to the examples in Annex A.1 to Annex A.3. An MTSI client offering EVS should generate an SDP offer according to the examples in Annex A.14.
An MTSI client in terminal supporting EVS should support the RTCP-APP signalling for speech adaptation defined clause 10.2.1, and shall support the RTCP-APP signalling when the MTSI client in terminal supports adaptation for call cases where the RTP-based CMR cannot be used.
Some of the request messages are generic for all speech codecs while other request messages are codec-specific. Request messages that can be used in a session are negotiated in SDP, see clause 10.2.3.
An MTSI client shall at least offer AVP for speech media streams. An MTSI client should also offer AVPF for speech media streams. An MTSI client shall offer AVPF for speech media streams when offering to use RTCP-APP signalling. RTP profile negotiation shall be done as described in clause 6.2.1a. When AVPF is offered then the RTCP bandwidth shall be greater than zero.
If an MTSI client in terminal offers to use ECN for speech in RTP streams then the MTSI client in terminal shall offer ECN Capable Transport as defined below. If an MTSI client in terminal accepts an offer for ECN for speech then the MTSI client in terminal shall declare ECN Capable Transport in the SDP answer as defined below. The SDP negotiation of ECN Capable Transport is described in RFC 6679.
ECN shall not be used when the codec negotiation concludes that only fixed-rate operation is used.
An MTSI client may support multiple codecs where ECN-triggered adaptation is supported only for some of the codecs. An SDP offer for ECN may therefore include multiple codecs where ECN-triggered adaptation is supported only for some of the codecs. An MTSI client receiving an SDP offer including multiple codecs and an offer for ECN should first select which codec to accept and then accept or reject the offer for ECN depending on whether ECN-triggered adaptation is supported for that codec or not. An MTSI client receiving an SDP answer accepting ECN for a codec where ECN-triggered adaptation is not supported should re-negotiate the session to disable ECN.
The use of ECN for a speech stream in RTP is negotiated with the 'ecn-capable-rtp' SDP attribute, (RFC 6679). ECN is enabled when both clients agree to use ECN as configured below. An MTSI client in terminal using ECN shall therefore also include the following parameters and parameter values for the ECN attribute:
  • 'leap', to indicate that the leap-of-faith initiation method shall be used;
  • 'ect=0', to indicate that ECT(0) shall be set for every packet.
An MTSI client offering ECN for speech may indicate support of the RTCP AVPF ECN feedback messages (RFC 6679) using "rtcp-fb" attributes with the "nack" feedback parameter and the "ecn" feedback parameter value. An MTSI client offering ECN for speech may indicate support for RTCP XR ECN summary reports (RFC 6679) using the "rtcp-xr" SDP attribute (RFC 3611) and the "ecn-sum" parameter.
An MTSI client receiving an offer for ECN for speech without an indication of support of RTCP AVPF ECN feedback messages (RFC 6679) within an "rtcp-fb" attribute should accept the offer if it supports ECN.
An MTSI client receiving an offer for ECN for speech with an indication of support of the RTCP AVPF ECN feedback message (RFC 6679) should also accept the offer and may indicate support of the RTCP AVPF ECN feedback messages (RFC 6679) in the answer.
An MTSI client accepting ECN for speech in an answer may indicate support for RTCP XR ECN summary reports in the answer using the "rtcp-xr" SDP attribute (RFC 3611) and the "ecn-sum" parameter.
The use of ECN is disabled when a client sends an SDP without the 'ecn-capable-rtp' SDP attribute.
An MTSI client may initiate a session re-negotiation to disable ECN to resolve ECN-related error cases. An ECN-related error case may, for example, be detecting non-ECT in the received packets when ECT(0) was expected or detecting a very high packet loss rate when ECN is used.
SDP examples for offering and accepting ECT are shown in Annex A.12.
Session setup for sessions including speech and DTMF events is described in Annex G.
Up

6.2.2.2  Generating SDP offersp. 41

When speech is offered, an MTSI client in terminal sending a first SDP offer in the initial offer-answer negotiation shall include at least one RTP payload type for AMR-NB according to RFC 4867 and the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings as defined in Table 6.1. When EVS-NB is also offered, the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings for EVS (both EVS Primary and AMR-WB IO modes) as defined in Table 6.2a.
If wideband speech is also offered, then the SDP offer shall also include at least one RTP payload type for AMR-WB according to RFC 4867 and the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings as defined in Table 6.1. When EVS-WB is also offered, the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings for EVS (both Primary and AMR-WB IO modes) as defined in Table 6.2a. AMR-WB and EVS (including the EVS AMR-WB IO mode) are thus offered using different RTP payload types.
If super-wideband speech is also offered, the SDP offer shall include at least one RTP payload type for EVS and the MTSI client in terminal shall support a configuration where the MTSI client in terminal includes the parameter settings as defined in Table 6.2a.
If fullband speech is also offered, the SDP offer shall include at least one RTP payload type for EVS and the MTSI client in terminal shall support a configuration where the MTSI client in terminal includes the parameter settings as defined in Table 6.2a.
When EVS is offered, the RTP payload type for EVS shall also use parameters for EVS AMR-WB IO mode as defined in Table 6.2a, except for the 'ecn-capable-rtp' and 'leap ect' parameters. AMR-WB and EVS (including the EVS AMR-WB IO mode) are thus offered using different RTP payload types.
Clause 5.2.1.6 describes the preference order for how different configurations should be ordered in the list of payload type numbers that is given on the m= line.
Parameter Usage
octet-alignShall not be included
mode-setShall not be included
mode-change-periodShall not be included
mode-change-capabilityShall be set to 2
mode-change-neighborShall not be included
maxptime Shall be set to 240, see also Table 7.1
crcShall not be included
robust-sortingShall not be included
interleavingShall not be included
ptime Shall be set according to Table 7.1
channelsShall either be set to 1 or be omitted
max-redShall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0Shall be included if offering to use ECN and if the session setup allows for bit-rate adaptation
Parameter Usage
octet-alignShall be set to 1
mode-setShall not be included
mode-change-periodShall not be included
mode-change-capabilityShall be set to 2
mode-change-neighborShall not be included
maxptime Shall be set to 240, see also Table 7.1
crcShall not be included
robust-sortingShall not be included
interleavingShall not be included
ptime Shall be set according to Table 7.1
channelsShall either be set to 1 or be omitted
max-redShall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0Shall be included if offering to use ECN and if the session setup allows for bit-rate adaptation
Parameter Usage
ptime Shall be set according to Table 7.1
maxptime Shall be set to 240, see also Table 7.1
hf-onlyThe SDP offer-answer considerations in TS 26.445 apply.
evs-mode-switchMTSI client in terminal shall not include evs-mode-switch in the initial SDP offer.
dtxMTSI client in terminal shall not include dtx in the initial SDP offer.
dtx-recvMTSI client in terminal shall not include dtx-recv.
max-redShall be included and shall be set to 220 or less.
channelsThe SDP offer-answer considerations in TS 26.445 apply.
cmrThe SDP offer-answer considerations in TS 26.445 apply.
brAn MTSI client in terminal supporting the EVS codec is required to support the entire bit-rate range but may offer a smaller bit-rate range or even a single bit-rate.
br-sendThe SDP offer-answer considerations in TS 26.445 apply.
br-recvThe SDP offer-answer considerations in TS 26.445 apply.
bwThe SDP offer-answer considerations in TS 26.445 apply.
bw-sendThe SDP offer-answer considerations in TS 26.445 apply.
bw-recvThe SDP offer-answer considerations in TS 26.445 apply.
ch-sendThe SDP offer-answer considerations in TS 26.445 apply.
ch-recvThe SDP offer-answer considerations in TS 26.445 apply.
ch-aw-recvThe SDP offer-answer considerations in TS 26.445 apply.
mode-setShall not be included
mode-change-periodShall not be included
mode-change-capabilityThe SDP offer-answer considerations in TS 26.445 apply.
mode-change-neighborShall not be included
When the channels parameter is omitted then this means that one channel is being offered.
The mode-set parameter is omitted, allowing maximum freedom for the visited network.
The mode-change-capability parameter is included and set to 2 for AMR-NB and AMR-WB, to support potential interworking with 2G radio access (GERAN). For EVS AMR-WB IO it is not required to include the mode-change-capability parameter.
An example of an SDP offer for AMR-NB is shown in Table A.1.1. An example of an SDP offer for both AMR-NB and AMR-WB is shown in Table A.1.2. An example of SDP offer for AMR-NB, AMR-WB, and EVS is shown in Table A.14.1.
An SDP example for offering and accepting a dual-mono session for EVS is shown in Annex A.14.1 and A.14.3.
An MTSI client in terminal may divide the offer-answer negotiation into several phases and offer different configurations in different SDP offers. If this is done then the first SDP offer in the initial offer-answer negotiation shall include the most preferable configurations. For AMR-NB, this means that the first SDP offer in the initial offer-answer negotiation shall include at least one RTP payload type for AMR-NB with the parameters as defined in Table 6.1. If wideband speech is offered then the first SDP offer in the initial offer-answer negotiation shall include also at least one RTP payload type for AMR-WB with the parameters as defined in Table 6.1. This also means that offers for octet-aligned payload format do not need to be included in the first SDP offer. If super-wideband or fullband speech is offered, the first SDP offer in the initial offer-answer negotiation shall include at least one RTP payload type for EVS with the parameters as defined in TS 26.445. One example of dividing the offer-answer negotiation into two phases, and the corresponding SDP offers, is shown in clause A.1.1.2.2.
If the speech media is re-negotiated during the session then the knowledge from earlier offer-answer negotiations should be used in order to shorten the session re-negotiation time. I.e., failed offer-answer transactions shall not be repeated.
Up

6.2.2.3  Generating SDP answerp. 44

An MTSI client in terminal must understand all the payload format options that are defined in RFC 4867, and in TS 26.445. It does not have to support operating according to all these options but must be capable to properly accepting or rejecting all options.
The SDP answer depends on many factors, for example:
  • what is included in the SDP offer and in what preference order that is defined. The SDP offer will probably be different if it is generated by another MTSI client in terminal, by an MTSI MGW, a TISPAN client or some other VoIP client that does not follow this specification;
  • if terminal and/or network resources are available; and:
  • if there are other configurations, for example defined with OMA-DM, that mandate, recommend or prevent some configurations.
Table 6.3 describes requirements and recommendations for handling of the AMR payload format parameters and for how to generate the SDP answer.
Parameter in the received SDP offer Comments Handling
CodecWide-band speech is preferable over narrow-band speechIf both AMR-WB and AMR-NB are offered and if AMR-WB is supported by the answering MTSI client in terminal then it shall select to use the AMR-WB codec and include this codec in the SDP answer, unless another preference order is indicated in the SDP offer. If the MTSI client in terminal only supports AMR-NB then this codec shall be selected to be used and shall be included in the SDP answer.
The SDP answer shall only include one RTP Payload Type for speech, see NOTE 1.
octet-alignBoth the bandwidth-efficient and the octet-aligned payload formats are supported by the MTSI client in terminal.
MTSI MGWs for GERAN or UTRAN are likely to either not include the octet-align parameter or to offer octet-align=0.
The bandwidth-efficient payload format is preferable over the octet-aligned payload format.
The offer shall not be rejected purely based on the offered payload format variant.
If both bandwidth-efficient and octet-aligned are included in the received SDP offer then the MTSI client in terminal shall select the bandwidth-efficient payload format and include it in the configuration in the SDP answer.
mode-setThe MTSI client in terminal can interoperate properly with whatever mode-set the other end-point offers or if no mode-set is offered.
The possibilities to use the higher bit rate codec modes also depend on the offered bandwidth.
MTSI MGWs for GERAN or UTRAN inter-working are likely to include the mode-set in the offer if in case the intention is to use TFO or TrFO.
Mode sets that give more adaptation possibilities are preferable over mode-sets with fewer or no adaptation possibilities.
An MTSI client in terminal may be configured with a preferred mode set. Otherwise, the preferred mode-set for AMR-NB is {12.2, 7.4, 5.9, 4.75} and for AMR-WB it is {12.65, 8.85 and 6.60}.
The offer shall not be rejected purely based on the offered mode-set.
If only one mode-set is offered then the MTSI client in terminal shall select to use this and include the same mode-set in the SDP answer.
If several different payload types for the same codec with different mode-sets (possibly including one or more payload type without mode set) are included in the received SDP offer, then the MTSI client in terminal should select in the first hand the mode-set that provides the largest degrees of freedom for codec mode adaptation and in the second hand the mode-set that is closest to the preferred mode sets.
If only a payload type without mode-set has been offered, or if an MTSI client in terminal selects a payload type without mode-set from among the offered ones, and the MTSI client in terminal intends to use only some modes (e.g. one of the preferred mode sets defined at left), then the MTSI client in terminal should include these modes as the mode-set. There are also dependencies between the mode-set and the SDP b=AS bandwidth parameter; see clause 6.2.5.2.
mode-change-periodThe MTSI client in terminal can interoperate properly with whatever mode-change-period the other end-point offers.
MTSI MGWs for GERAN or UTRAN inter-working are likely to include mode-change-period=2 in the offer if in case the intention is to use TFO or TrFO.
The offer shall not be rejected purely based on the offered mode-change-period.
If the received SDP offer defines mode-change-period=2 then this information shall be used to determine the mode changes for AMR-NB or AMR-WB encoded media that the MTSI client in terminal sends.
The MTSI client in terminal should not include the mode-change-period parameter in the SDP answer since it has no corresponding limitations.
mode-change-capabilityThe MTSI client in terminal can interoperate with whatever capabilities the other end-point declares.The offer shall not be rejected purely based on the offered mode-change-capability.
The mode-change-capability information should be used to determine a proper value, or prevent using an improper value, for mode-change-period in the SDP answer, see above. If the offer includes mode-change-capability=1, then the MTSI client in terminal shall not offer mode-change-period=2 in the answer.
The MTSI client in terminal shall include mode-change-capability=2 in the SDP answer since it is required to support restricting mode changes to every other frame.
mode-change-neighborThe MTSI client in terminal can interoperate with whatever limitations the other end-point offers.The offer shall not be rejected purely based on the offered mode-change-neighbor.
The MTSI client in terminal shall use this information to determine how mode changes can be performed for AMR-NB or AMR-WB encoded media that the MTSI client in terminal sends.
The MTSI client in terminal shall not include the mode-change-neighbor parameter in the SDP answer since it has no corresponding limitations.
maxptimeThe MTSI client in terminal can interoperate with whatever value that is offered.
The MTSI client in terminal may also use this information to determine a suitable value for max-red in the SDP answer.
The offer shall not be rejected purely based on the offered maxptime.
The MTSI client in terminal shall use this information to control the packetization when sending RTP packets to the other end-point, see also clause 7.4.2.
The maxptime parameter shall be included in the SDP answer and shall be an integer multiple of 20.
If the received SDP offer includes both the max-red and ptime parameter then the MTSI client in terminal may choose to use this information to define a suitable value for maxptime in the SDP answer, see NOTE 2. The MTSI client in terminal may also choose to set the maxptime value to 240, regardless of the ptime and/or max-red parameters in the SDP offer.
The maxptime value in the SDP answer shall not be smaller than ptime value in the SDP answer. The maxptime value should be selected to give at least some room for adaptation.
crcThe MTSI client in terminal is not required to support this option.The MTSI client in terminal may have to reject offered RTP payload types including this option.
robust-sortingThe MTSI client in terminal is not required to support this option.The MTSI client in terminal may have to reject offered RTP payload types including this option.
interleavingThe MTSI client in terminal is not required to support this option.The MTSI client in terminal may have to reject offered RTP payload types including this option.
ptimeThe MTSI client in terminal can interoperate with whatever value that is offered.The offer shall not be rejected purely based on the offered ptime. The MTSI client in terminal should use this information and should use the requested packetization when sending RTP packets to the other end-point. The MTSI client should use the ptime value to determine how many non-redundant speech frames that can be packed into the RTP packets. The requirements in clause 7.4.2 shall be followed even if ptime in the SDP offer is larger than 80.
The ptime parameter shall be included in the SDP answer and shall be an integer multiple of 20.
If the received SDP offer includes the ptime parameters then the MTSI client in terminal may choose to use this information to define a suitable value for ptime in the SDP answer, see NOTE 3. The MTSI client in terminal may also choose to set the ptime value in the SDP answer according to Table 7.1, regardless of the ptime parameter in the SDP offer.
The ptime value in the SDP answer shall not be larger than the maxptime value in the SDP answer.
channels The number of channels may either be explicitly indicated in the SDP by including '/1', '/2', etc. on the a=rtpmap line, but the number of channels may also be omitted. When the number of channels is omitted then the default rule is that one channel is being offered.
The MTSI client in terminal is only required to support audio media using one channel. Offered RTP payload types with more than one channel may therefore have to be rejected.
When the MTSI client in terminal accepts an offer for single-channel audio then the SDP answer shall either explicitly indicate '/1' or omit the channels parameter.
When the MTSI client in terminal accepts an offer for multi-channel audio then the number of channels shall be included in the SDP answer.
max-redThe MTSI client in terminal may use this information to bound the delay for receiving redundant frames.
The MTSI client in terminal may also use this information to determine a suitable value for maxptime in the SDP answer.
The max-red parameter shall be included in the SDP answer and shall be an integer multiple of 20.
If the received SDP offer includes both the ptime and maxptime parameters then the MTSI client in terminal may choose to use this information to define a suitable value for max-red in the SDP answer, see NOTE 2. The MTSI client in terminal may also choose to set the max-red value to 220.
The max-red value in the SDP answer should be selected to give at least some room for adaptation.
ecn-capable-rtp: leap ect=0An MTSI client in terminal uses this SDP attribute to offer ECN for RTP-transported mediaShall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation
NOTE 1:
An MTSI client may include both a speech coded, e.g. AMR-NB or AMR-WB, and 'telephone-events' for DTMF in the SDP answer, see clause 6.1 of TS 24.229.
NOTE 2:
It is possible to use the following relationship between maxptime, ptime and max-red: maxptime = ptime + max-red. There is however no mandatory requirement that these parameters must be aligned in this way.
NOTE 3:
It may be wise to use the same ptime value in the SDP answer as was given in the SDP offer, especially if the ptime in the SDP offer is larger than 20, since a value larger than the frame length indicates that the other end-point is somehow packet rate limited.
If an SDP offer is received from another MTSI client in terminal using the AMR-NB or AMR-WB codec, then the SDP offer will include configurations as described in Table 6.1 and Table 6.2. If the MTSI client in terminal chooses to accept the offer for using the AMR-NB or AMR-WB codec, as configured in Table 6.1 or Table 6.2 then the MTSI client in terminal shall support a configuration where the MTSI client in terminal creates an SDP answer containing an RTP payload type for the AMR-NB and AMR-WB codec as shown in Table 6.4.
Parameter Comments Handling
ptime
maxptime
evs-mode-switchThis parameter indicates the initial operational mode. This parameter is used by MTSI MGW either when starting in EVS AMR-WB IO mode instead of EVS Primary mode or when switching between EVS Primary mode and EVS AMR-WB IO mode, e.g., for SRVCC.MTSI client in terminal shall not include evs-mode-switch in the initial SDP offer. When including evs-mode-switch in the SDP offer during a session, the offerer shall use the requested mode when sending EVS packets at the start of the session. However, if a media stream is already being received, the offerer needs to be prepared to receive packets in both EVS primary and EVS AMR-WB IO modes until receiving the answer. When including evs-mode-switch in the SDP answer during a session, the answerer shall use the requested mode when sending EVS packets at the start of the session. When receiving SDP answer including evs-mode-switch during a session, the offerer shall use the requested mode when sending EVS packets.
hf-only-
dtxMTSI client in terminal shall not include dtx in the initial SDP offer. MTSI MGW may modify SDP offer to include dtx in order to disable DTX in the session.
dtx-recvMTSI client in terminal shall not include dtx-recv. MTSI MGW may modify SDP offer or answer in order to disable DTX for the send direction of the receiver of dtx-recv.
cmrIn EVS AMR-WB IO mode, CMR to the bit-rates of EVS AMR-WB IO mode and NO_REQ is always enabled.If cmr=-1 and the session is in the EVS Primary mode, MTSI client in terminal shall not transmit CMR. If cmr=-1 and the session is in the EVS AMR-WB IO, MTSI client in terminal shall restrict CMR to values of EVS AMR-WB-IO bit-rates and NO_REQ in the session.
MTSI client in terminal is required to accept CMR even when cmr=-1. MTSI client in terminal is required to accept RTP payload without CMR even when cmr=1.
max-red See Table 6.3
channels See Table 6.3
Parameter Comments Handling
brAn MTSI client in terminal supporting the EVS codec is required to support the entire bit-rate range but may offer a smaller bit-rate range or even a single bit-rate.
br-send
br-recv
bwThe session should start with the maximum bandwidth supported by the initial bit-rate up to the maximum negotiated bandwidth. If a range of bandwidth is negotiated, the codec can operate in any bandwidth in the session but the maximum bandwidth in the range should be used after the start of or update of the session. If a single audio bandwidth higher than narrowband is negotiated, the codec operates in the negotiated bandwidth but can use lower bandwidth(s) in the session, depending on the input signal.Both the offerer and the answerer shall send according to the bandwidth parameter in the answer.
bw-send
bw-recv
ch-send
ch-recv
ch-aw-recv If a positive (2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the receiver of the parameter shall send partial redundancy (channel-aware mode) at the start of the session using the value as the offset. If ch-aw-recv=0 is declared or not present for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) at the start of the session. If ch-aw-recv=-1 is declared for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) in the session. If not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, partial redundancy (channel-aware mode) can be activated or deactivated during the session based on the expected or estimated channel condition through adaptation signaling, such as CMR (see Annex A.2 of TS 26.445) or RTCP based signalling (see clause 10.2). If not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the partial redundancy offset value can also be adjusted during the session based on the expected or estimated channel condition through adaptation signaling.
Parameter Comments Handling
mode-set See Table 6.3
mode-change-period
mode-change-neighbor
mode-change-capability The default value is re-defined in comparison to that in RFC 4867.As the default and the only allowed value of mode-change-capability is 2 in EVS AMR-WB IO, it is not required to include this parameter in the SDP offer or answer.
Parameter Usage
octet-alignShall not be included
mode-set See Table 6.3
mode-change-periodShall not be included
mode-change-capabilityMay be included. If it is included then it shall be set to 2
mode-change-neighborShall not be included
maxptime Shall be set to 240, see also Table 7.1
crcShall not be included
robust-sortingShall not be included
interleavingShall not be included
ptime Shall be set according to Table 7.1
channelsShall either be set to 1 or be omitted
max-redShall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0Shall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation
If an SDP offer is received from a MTSI MGW inter-working with CS GERAN/UTRAN, and when the MTSI MGW supports ECN (see also clause 12.3.3), then it is likely to be configured as shown in Table 6.5 if the MTSI MGW does not support redundancy.
Parameter Usage
octet-alignEither not included or set to 0
mode-setIncluded and indicates the codec modes that are allowed in the CS network
mode-change-periodSet to 2
mode-change-capabilitySet to 2
mode-change-neighborSet to 1 if the CS network is GERAN
maxptime Set to 80, see also Table 12.1
crcNot included
robust-sortingNot included
interleavingNot included
ptime Set according to Table 12.1
channelsSet to 1 or parameter is omitted
max-redSet to 0
ecn-capable-rtp: leap ect=0Shall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation
If the MTSI client in terminal accepts the offer included in Table 6.5 then the MTSI client in terminal shall support a configuration where the MTSI client in terminal creates an SDP answer containing an RTP payload type for the AMR-NB and AMR-WB codecs as shown in Table 6.6.
Parameter Usage
octet-alignShall be set according to the offer
mode-set See Table 6.3
mode-change-periodShall not be included
mode-change-capabilityMay be included. If it is included then it shall be set to 2
mode-change-neighborShall not be included
maxptime Shall be set to 240, see also Table 7.1
crcShall not be included
robust-sortingShall not be included
interleavingShall not be included
ptime Shall be set according to Table 7.1
channelsShall be set according to the offer
max-redShall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0Shall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation
Up

Up   Top   ToC