The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032. In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect SDP message bodies. Hence, the UE shall not encrypt SDP message bodies. During the session establishment procedure, and during session modification procedures, SIP messages shall only contain an SDP message body if that is intended to modify the session description, or when the SDP message body is included in the message because of SIP rules described in RFC 3261. In order to support accurate bandwidth calculations, the UE may include the "a=ptime" attribute for all "audio" media lines as described in RFC 4566. If a UE receives an "audio" media line with "a=ptime" specified, the UE should transmit at the specified packetization rate. If a UE receives an "audio" media line which does not have "a=ptime" specified or the UE does not support the "a=ptime" attribute, the UE should transmit at the default codec packetization rate as defined in RFC 3551. The UE will transmit consistent with the resources available from the network. For "video" and "audio" media types that use the RTP/RTCP and where the port number is not zero, the UE shall specify the proposed bandwidth for each media stream using the "b=" media descriptor and the "AS" bandwidth modifier in the SDP. For "video" and "audio" media types that use the RTP/RTCP and where the port number is not zero, the UE may include for each RTP payload type "a=bw-info" SDP attribute(s) (defined in clause 19 of TS 26.114) to indicate the additional bandwidth information. The "a=bw-info" SDP attribute line(s) shall be specified in accordance with TS 26.114. The value of the "a=bw-info" SDP attribute(s) may affect the assigned QoS which is defined in TS 29.213. For "video" and "audio" media types that utilize the RTP/RTCP, in addition to the "b=AS" parameter, the UE may specify the "b=TIAS", and "a=maxprate" parameters in accordance with RFC 3890. The value of the parameter shall be determined as described in RFC 3890. The value or absence of the "b=" parameter(s) may affect the assigned QoS which is defined in TS 29.213. If a UE receives a media line which contains both a=ptime and a=maxprate, the UE should use the a=maxprate value, if this attribute is supported. If multiple codecs are specified on the media line, "a=maxprate" (or "a=ptime" if "a=maxprate" is not available or not supported) should be used to derive the packetization time used for all codecs specified on the media line. Given that not all codecs support identical ranges of packetization, the UE should ensure that the packetization derived by "a=maxprate" (or "a=ptime" if "a=maxprate" is not available or not supported) is a valid packetization time for each codec specified in the list. If the media line in the SDP message body indicates the usage of RTP/RTCP, and if the UE is configured to request an RTCP bandwidth level for the session is different than the default RTCP bandwidth as specified in RFC 3556, then in addition to the "AS" bandwidth modifier in the media-level "b=" line, the UE shall include two media-level "b=" lines, one with the "RS" bandwidth modifier and the other with the "RR" bandwidth modifier as described in RFC 3556 to specify the required bandwidth allocation for RTCP. The bandwidth-value in the b=RS: and b=RR: lines may include transport overhead as described in Section 6.1 of RFC 3890. For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" parameter will affect the assigned QoS which is defined in or TS 29.213. If an in-band DTMF codec is supported by the application associated with an audio media stream, then the UE shall include, in addition to the payload type numbers associated with the audio codecs for the media stream, for each clock rate associated with the audio codecs for the media stream, a payload type number associated with the MIME subtype "telephone-event", to indicate support of in-band DTMF as described in RFC 4733. The UE shall inspect the SDP message body contained in any SIP request or response, looking for possible indications of grouping of media streams according to RFC 3524 and perform the appropriate actions for IP-CAN bearer establishment for media according to IP-CAN specific procedures (see subclause B.2.2.5 for IP-CAN implemented using GPRS, subclause L.2.2.5 for IP-CAN implemented using EPS, and subclause U.2.2.5 for IP-CAN implemented using 5GS). In case of UE initiated resource reservation and if the UE determines resource reservation is needed, the UE shall start reserving its local resources whenever it has sufficient information about the media streams, media authorization and used codecs available. In order to fulfil the QoS requirements of one or more media streams, the UE may re-use previously reserved resources. In this case the UE shall indicate as met the local preconditions related to the media stream, for which resources are re-used. If the SDP is affected due to a rejected IP-CAN bearer or a released IP-CAN bearer then the UE shall:

1. update the session according to RFC 3264 and set the ports of the media stream(s) for which IP-CAN resource was rejected or released to zero in the new SDP offer;
2. release the session according to RFC 3261;
3. cancel the session setup or the session modification according to RFC 3261; or
4. reject the session setup or the session modification according to RFC 3261.

If the SDP is affected due to a modified IP-CAN bearer, and the desired QoS resources for one or more media streams are no longer available at the UE due to the modification, then the UE shall:

1. update the session according to RFC 3264 and set the ports of the media stream(s) for which IP-CAN resource was modified to zero in the new SDP offer;
2. release the session according to RFC 3261;
3. cancel the session setup or the session modification according to RFC 3261; or
4. reject the session setup or the session modification according to RFC 3261.

If the UE wants to transport media streams with TCP and there are no specific alternative negotiation mechanisms defined for that particular application, then the UE shall support the procedures and the SDP rules specified in RFC 4145. The UE may support being configured with a media type restriction policy using one or more of the following methods:

1. the Media_type_restriction_policy node of the EF IMSConfigData file described in TS 31.102;
2. the Media_type_restriction_policy node of the EF IMSConfigData file described in TS 31.103; and
3. the Media_type_restriction_policy node of TS 24.167.

If the UE is configured with both the Media_type_restriction_policy node of TS 24.167 and the Media_type_restriction_policy node of the EF IMSConfigData file described in TS 31.102 or TS 31.103, then the Media_type_restriction_policy node of the EF IMSConfigData file shall take precedence. If the UE supports being configured with a media type restriction policy, the UE shall not include in a sent SDP message (SDP offer or SDP answer) a media stream with:

• non zero port number; and
• a media type which is restricted from inclusion in an SDP message according to the media type restriction policy.

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 RTP media using DTLS-SRTP and certificate fingerprints during registration, and the P-CSCF indicated support for the end-to-access-edge media security for RTP media using DTLS-SRTP and certificate fingerprints 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 "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as the transport protocol according to RFC 5763 and RFC 5764 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 RFC 8842.

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, RFC 8842 [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 RFC 8842 [240].

If the P-CSCF did not indicate support for end-to-access-edge media security using neither DTLS-SRTP nor 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 RFC 8853 [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 RFC 8853 [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 RTP media using DTLS-SRTP and certificate fingerprints, upon receiving an SDP offer containing an RTP based media:

• transported using the "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as the transport protocol according to RFC 5763 and RFC 5764;
• with the SDP fingerprint attribute as defined in RFC 8122; 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 "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as the transport protocol according to RFC 5763 and RFC 5764 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 RFC 8842.

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 RFC 8842 [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, RFC 8842 [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 RFC 8842 [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 clause A.3.2, with the following exceptions:

• in an initial INVITE request generated by a MGCF, the MGCF shall indicate the current status of the local precondition;
• end-to-access edge media security is not applicable to the MGCF; and
• 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. When the MGCF generates and sends an INVITE request for a call originating in a circuit-switched network, the MGCF shall populate the SDP with the codecs supported by the associated MGW.

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.

If the MGCF supports OMR it shall also perform the UA procedures described in TS 29.079.

An MGW associated with an MGCF can support Explicit Congestion Notification (ECN) according to RFC 3168, and can act as an ECN endpoint to enable ECN with a local ECN-capable terminal within a local network that properly handles ECN-marked packets. If the MGCF receives a SDP offer containing ECN attribute "a=ecn-capable-rtp" as specified in RFC 6679, and if the MGCF knows via configuration that the MGW handles ECN-marked packets properly then the MGCF, taking into account the initialisation method the MGW supports, shall return a SDP answer containing the ECN attribute "a=ecn-capable-rtp" according to RFC 6679. When creating an SDP offer and if the MGCF knows via configuration that the MGW handles ECN-marked packets properly the MGCF may initiate ECN negotiation in accordance with RFC 6679. If the MGCF receives the SDP answer also containing ECN attribute "a=ecn-capable-rtp" then the MGCF will instruct the MGW to apply ECN procedures.