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.

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

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.

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.

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. When IVAS is offered, the RTP payload type shall include parameters for immersive audio, EVS Primary mode and EVS AMR-WB IO mode as defined in Table 6.2b. 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.

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. SDP examples for IVAS are shown in Annex A.19. 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.

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.

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.

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.

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.

An MTSI client accepting an offer for IVAS immersive audio shall in the SDP answer include parameters for immersive audio, EVS Primary mode and EVS AMR-WB IO mode.