An INVITE request generated by a UE shall contain a SDP offer and at least one media description. This SDP offer shall reflect the calling user's terminal capabilities and user preferences for the session. If the desired QoS resources for one or more media streams have not been reserved at the UE when constructing the SDP offer, the UE:

• shall indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 and RFC 4032 for the remote segment, if the UE uses the precondition mechanism (see subclause 5.1.3.1); and
• if the UE uses the precondition mechanism (see subclause 5.1.3.1), shall not request confirmation for the result of the resource reservation (as defined in RFC 3312) at the terminating UE.

If the UE uses the precondition mechanism (see subclause 5.1.3.1), and the desired QoS resources for one or more media streams are available at the UE when the SDP offer is sent, the UE shall indicate the related local preconditions as met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 and RFC 4032 for the remote segment and shall not request confirmation for the result of the resource reservation (as defined in RFC 3312) at the terminating UE. If the UE indicated support for end-to-access-edge media security using SDES during registration, and the P-CSCF indicated support for end-to-access-edge media security using SDES during registration, then upon generating an SDP offer with an RTP based media, for each RTP based media except those for which the UE requests an end-to-end media security mechanism, the UE shall:

• offer SRTP transport protocol according to RFC 3711 and the profile defined in TS 33.328;
• include the SDP crypto attribute according to RFC 4568 and the profile defined in TS 33.328; and
• include an SDP "a=3ge2ae:requested" attribute.

If the UE indicated support for the end-to-access-edge media security for MSRP using TLS and certificate fingerprints during registration, and the P-CSCF indicated support for the end-to-access-edge media security for MSRP using TLS and certificate fingerprints during registration, then upon generating an SDP offer with an MSRP based media, for each MSRP based media except those for which the UE requests an end-to-end security mechanism, the UE shall:

• offer MSRP over TLS transport protocol according to RFC 4975, RFC 6714 and the profile defined in TS 33.328;
• include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328; and
• include the SDP "a=3ge2ae:requested" attribute.

If the UE indicated support for the end-to-access-edge media security for BFCP using TLS and certificate fingerprints during registration, and the P-CSCF indicated support for the end-to-access-edge media security for BFCP using TLS and certificate fingerprints during registration, then upon generating an SDP offer with an BFCP based media, for each BFCP based media except those for which the UE requests an end-to-end security mechanism, the UE shall:

• offer BFCP over TLS transport protocol according to RFC 4583 and the profile defined in TS 33.328;
• include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328; and
• include the SDP "a=3ge2ae:requested" attribute.

Unless a new TLS session is negotiated, subsequent SDP offers and answers shall not impact the previously negotiated TLS roles. If the UE indicated support for the end-to-access-edge media security for UDPTL using DTLS and certificate fingerprints during registration, and the P-CSCF indicated support for the end-to-access-edge media security for UDPTL using DTLS and certificate fingerprints during registration, then upon generating an SDP offer with an UDPTL based media, for each UDPTL based media except those for which the UE requests an end-to-end security mechanism, the UE shall:

• offer UDPTL over DTLS transport protocol according to RFC 7345, draft-ietf-mmusic-dtls-sdp [240] and the profile defined in TS 33.328;
• include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328;
• include the SDP "a=3ge2ae:requested" attribute; and
• include the SDP tls-id attribute according to draft-ietf-mmusic-dtls-sdp [240].

If the P-CSCF did not indicate support for end-to-access-edge media security using SDES during registration, the UE shall not include an SDP "a=3ge2ae:requested" attribute in any RTP based media in any SDP offer. If the P-CSCF did not indicate support for the end-to-access-edge media security for MSRP using TLS and certificate fingerprints during registration, the UE shall not include an SDP "a=3ge2ae:requested" attribute in any MSRP based media in any SDP offer. If the P-CSCF did not indicate support for the end-to-access-edge media security for BFCP using TLS and certificate fingerprints during registration, the UE shall not include an SDP "a=3ge2ae:requested" attribute in any BFCP based media in any SDP offer. If the P-CSCF did not indicate support for the end-to-access-edge media security for UDPTL using DTLS and certificate fingerprints during registration, the UE shall not include an SDP "a=3ge2ae:requested" attribute in any UDPTL based media in any SDP offer. The UE shall not include an SDP "a=3ge2ae:requested" attribute in any media other than RTP based, MSRP based, BFCP based and UDPTL based in any SDP offer. Upon generating an SDP offer with an MSRP based media protected by the end-to-end media security for MSRP using TLS and KMS, the UE shall:

• offer MSRP over TLS transport protocol according to RFC 4975, RFC 6714 and the profile defined in TS 33.328; and
• include the SDP key-mgmt attribute according to RFC 4567 and the profile defined in TS 33.328;

Upon receiving an SDP answer to the SDP offer with the MSRP based media protected by the end-to-end media security for MSRP using TLS and KMS, and if the MSRP based media is accepted and associated with the SDP key-mgmt attribute as described in RFC 4567 and the profile defined in TS 33.328 in the SDP answer, then the UE indicate the pre-shared key ciphersuites according to RFC 4279 and the profile defined in TS 33.328 in TLS handshake of TLS connection transporting the MSRP based media. When the UE detects that an emergency call is being made, the UE shall not include end-to-end media security on any media in the SDP offer. Upon generating the SDP offer for an INVITE request generated after receiving a 488 (Not Acceptable Here) response, as described in subclause 5.1.3.1, the SDP offer shall contain a subset of the allowed media types, codecs and other parameters from the SDP message bodies of all 488 (Not Acceptable Here) responses so far received for the same session establishment attempt (i.e. a set of INVITE requests used for the same session establishment). For each media line, the UE shall order the codecs in the SDP offer according to the order of the codecs in the SDP message bodies of the 488 (Not Acceptable Here) responses. Upon confirming successful local resource reservation, the UE shall create an SDP offer in which the related local preconditions are set to met, using the segmented status type, as defined in RFC 3312 and RFC 4032. Upon receiving an SDP answer, which includes more than one codec per media stream, excluding the in-band DTMF codec, as described in subclause 6.1.1, the UE shall:

• send an SDP offer at the first possible time, selecting only one codec per media stream; or
• if the UE is participant in a multi-stream multiparty multimedia conference session using simulcast (indicated by the presence of "a=simulcast" SDP attribute(s) in the SDP answer, as defined in draft-ietf-mmusic-sdp-simulcast [249]), apply the procedures defined in TS 26.114 Annex S.

If the UE sends an initial INVITE request that includes only an IPv6 address in the SDP offer, and receives an error response (e.g., 488 (Not Acceptable Here) with 301 Warning header field) indicating "incompatible network address format", the UE shall send an ACK as per standard SIP procedures. Subsequently, the UE may acquire an IPv4 address or use an existing IPv4 address, and send a new initial INVITE request to the same destination containing only the IPv4 address in the SDP offer.

Upon receipt of an initial SDP offer in which no precondition information is available, the terminating UE shall in the SDP answer:

• if, prior to sending the SDP answer the desired QoS resources have been reserved at the terminating UE, set the related media streams in the SDP answer to:
  • active mode, if the offered media streams were not listed as inactive; or
  • inactive mode, if the offered media streams were listed as inactive.

If the terminating UE had previously set one or more media streams to inactive mode and the QoS resources for those media streams are now ready, the UE shall set the media streams to active mode by applying the procedures described in RFC 4566 with respect to setting the direction of media streams. Upon sending a SDP answer to an SDP offer (which included one or more media lines which was offered with several codecs) the terminating UE shall:

• select exactly one codec per media line and indicate only the selected codec for the related media stream. In addition, the UE may indicate support of the in-band DTMF codec, as described in subclause 6.1.1; or
• if the UE is participant in a multi-stream multiparty multimedia conference session using simulcast (indicated by the presence of "a=simulcast" SDP attribute(s) in the SDP answer, as defined in draft-ietf-mmusic-sdp-simulcast [249]), apply the procedures defined in TS 26.114 annex S.

If the terminating UE does not support any of the offered codecs, or there are other parameters not acceptable to the UE, the UE shall send a 488 (Not Acceptable Here) response and shall in the response include an SDP in the message body containing the codecs and parameters supported by the UE. Upon sending an SDP answer to an SDP offer, with the SDP answer including one or more media streams for which the originating side did indicate its local preconditions as not met, if the precondition mechanism is used by the terminating UE (see subclause 5.1.4.1), the terminating UE shall indicate its local preconditions and request the confirmation for the result of the resource reservation at the originating end point. Upon receiving an initial INVITE request that includes the SDP offer containing an IP address type (in the "c=" parameter) that is not supported by the UE, the UE shall:

• if the UE is a UE performing the functions of an external attached network and
  1. if the received SDP offer contains an "altc" SDP attribute indicating an alternative and supported IP address; and
  2. the UE supports the "altc" SDP attribute;
  select an IP address type in accordance with RFC 6947; or
• otherwise respond with a 488 (Not Acceptable Here) response including a 301 Warning header field indicating "incompatible network address format".

If the UE receives an SDP offer that specifies different IP address type for media (i.e. specify it in the "c=" parameter of the SDP offer) that the UE is using for signalling, and if the UE supports both IPv4 and IPv6 addresses simultaneously, the UE shall accept the received SDP offer. Subsequently, the UE shall either acquire an IP address type or use an existing IP address type as specified in the SDP offer, and include it in the "c=" parameter in the SDP answer. If the UE supports the end-to-access-edge media security using SDES, upon receiving an SDP offer containing an RTP based media:

• transported using the SRTP transport protocol as defined in RFC 3711;
• with an SDP crypto attribute as defined in RFC 4568; and
• with the SDP "a=3ge2ae:applied" attribute;

and if the UE accepts the RTP based media, then the UE shall generate the SDP answer with the related RTP based media:

• transported using the SRTP transport protocol according to RFC 3711 and the profile defined in TS 33.328; and
• including an SDP crypto attribute according to RFC 4568 and the profile defined in TS 33.328.

If the UE supports the end-to-access-edge media security for MSRP using TLS and certificate fingerprints, upon receiving an SDP offer containing an MSRP based media:

• transported using the MSRP over TLS transport protocol as defined in RFC 4975 and RFC 6714;
• with the SDP fingerprint attribute as defined in RFC 8122; and
• with the SDP "a=3ge2ae:applied" attribute;

and if the UE accepts the MSRP based media, then the UE shall generate the SDP answer with the related MSRP based media:

• transported using the MSRP over TLS transport protocol according to RFC 4975, RFC 6714 and the profile defined in TS 33.328; and
• including the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328.

If the UE supports the end-to-access-edge media security for BFCP using TLS and certificate fingerprints, upon receiving an SDP offer containing an BFCP based media:

• transported using the BFCP over TLS transport protocol as defined in RFC 4583;
• with the SDP fingerprint attribute as defined in RFC 8122; and
• with the SDP "a=3ge2ae:applied" attribute;

and if the UE accepts the BFCP based media, then the UE shall generate the SDP answer with the related BFCP based media:

• transported using the BFCP over TLS transport protocol according to RFC 4583 and the profile defined in TS 33.328; and
• including the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328.

Unless a new TLS session is negotiated, subsequent SDP offers and answers shall not impact the previously negotiated TLS roles. If the UE supports the end-to-access-edge media security for UDPTL using DTLS and certificate fingerprints, upon receiving an SDP offer containing an UDPTL based media:

• transported using the UDPTL over DTLS transport protocol as defined in RFC 7345 and draft-ietf-mmusic-dtls-sdp [240];
• with the SDP fingerprint attribute as defined in RFC 8122; and
• with the SDP "a=3ge2ae:applied" attribute;

and if the UE accepts the UDPTL based media, then the UE shall generate the SDP answer with the related UDPTL based media:

• transported using the UDPTL over DTLS transport protocol according to RFC 7345, draft-ietf-mmusic-dtls-sdp [240] and the profile defined in TS 33.328;
• including the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328; and
• including the SDP tls-id attribute according to draft-ietf-mmusic-dtls-sdp [240].

Upon receiving an SDP offer containing an MSRP based media:

• transported using the MSRP over TLS transport protocol as defined in RFC 4975 and RFC 6714; and
• with the SDP key-mgmt attribute according to RFC 4567 and the profile defined in TS 33.328;

and if the UE accepts the MSRP based media, the UE shall:

1. generate the SDP answer with the related MSRP based media:
   1. transported using the MSRP over TLS transport protocol according to RFC 4975, RFC 6714 and the profile defined in TS 33.328; and
   2. include the SDP key-mgmt attribute according to RFC 4567 and the profile defined in TS 33.328; and
2. indicate the pre-shared key ciphersuites according to RFC 4279 and the profile defined in TS 33.328 in TLS handshake of TLS connection transporting the MSRP based media.

If the terminating UE uses the precondition mechanism (see subclause 5.1.4.1), if the desired QoS resources for one or more media streams have not been reserved at the terminating UE when constructing the SDP offer, the terminating UE shall indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 and RFC 4032 for the remote segment. If the terminating UE uses the precondition mechanism (see subclause 5.1.4.1) and if the desired QoS resources for one or more media streams are available at the terminating UE when the SDP offer is sent, the UE shall indicate the related local preconditions as met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 and RFC 4032 for the remote segment. If the terminating UE sends an UPDATE request to remove one or more media streams negotiated in the session for which a final response to the INVITE request has not been sent yet, the terminating UE sets the ports of the media streams to be removed from the session to zero in the new SDP offer.

The usage of SDP by the MGCF is the same as its usage by the UE, as defined in the subclause 6.1 and A.3.2, with the following exceptions:

1. when the MGCF sends a 183 (Session Progress) response with an SDP message body, the MGCF shall only request confirmation for the result of the resource reservation (as defined in RFC 3312) at the originating end point if all of the following conditions are true:
   • there are any remaining unfulfilled preconditions at the originating end point;
   • the received initial INVITE request indicates support of SIP preconditions; and
   • local configuration indicates support of SIP preconditions;
2. end-to-access edge media security is not applicable to the MGCF; and
3. procedures related to the handling of the IP-CAN bearer rejection, modification or release are not applicable to the MGCF.

When sending an SDP message body, the MGCF shall not include the "i=", "u=", "e=", "p=", "r=", and "z=" descriptors in the SDP message body, and the MGCF shall ignore them if received in an SDP message body.