6 Application usage of SDP

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Procedures at the UE

6.1.1 General

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 [30] as updated by RFC 4032 [64].

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 [26].

NOTE 1: A codec can have multiple payload type numbers associated with it.

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 [39]. 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 [55A]. 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.

NOTE 2: The above is the minimum requirement for all UEs. Additional requirements can be found in other specifications.

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 3GPP TS 26.114 [9B]) to indicate the additional bandwidth information. The "a=bw-info" SDP attribute line(s) shall be specified in accordance with 3GPP TS 26.114 [9B]. The value of the "a=bw-info" SDP attribute(s) may affect the assigned QoS which is defined in 3GPP TS 29.213 [13C].

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 [152]. The value of the parameter shall be determined as described in RFC 3890 [152]. The value or absence of the "b=" parameter(s) may affect the assigned QoS which is defined in 3GPP TS 29.213 [13C].

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 [56], 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 [56] 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 subclause 6.1 of RFC 3890 [152].

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 3GPP 29.213 [13C].

NOTE 3: In a two-party session where both participants are active, the RTCP receiver reports are not sent, therefore, the RR bandwidth modifier will typically get the value of zero.

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 [23].

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 [54] 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.

NOTE 4: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or receiving of the initial SDP offer.

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 [27B] 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 [26];

3) cancel the session setup or the session modification according to RFC 3261 [26]; or

4) reject the session setup or the session modification according to RFC 3261 [26].

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 [27B] 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 [26];

3) cancel the session setup or the session modification according to RFC 3261 [26]; or

4) reject the session setup or the session modification according to RFC 3261 [26].

NOTE 5: The UE can use one IP address for signalling (and specify it in the Contact header field) and different IP address(es) for media (and specify it in the "c=" parameter of the SDP).

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 [83].

The UE may support being configured with a media type restriction policy using one or more of the following methods:

a) the Media_type_restriction_policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C];

b) the Media_type_restriction_policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.103 [15B]; and

c) the Media_type_restriction_policy node of 3GPP TS 24.167 [8G].

If the UE is configured with both the Media_type_restriction_policy node of 3GPP TS 24.167 [8G] and the Media_type_restriction_policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C] or 3GPP TS 31.103 [15B, then the Media_type_restriction_policy node of the EF_{IMSConfigData} file shall take precedence.

NOTE 6: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].

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.

NOTE 7: 488 (Not Acceptable Here) response is sent when all media types of all media streams of an SDP offer are restricted from inclusion in an SDP message according to the media type restriction policy.

6.1.2 Handling of SDP at the originating UE

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 [30] and RFC 4032 [64], 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 [30] and RFC 4032 [64] 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 [30]) at the terminating UE.

NOTE 1: Previous versions of this document mandated the use of the SDP inactive attribute. This document does not prohibit specific services from using direction attributes to implement their service-specific behaviours.

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 [30] and RFC 4032 [64], 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 [30] and RFC 4032 [64] for the remote segment and shall not request confirmation for the result of the resource reservation (as defined in RFC 3312 [30]) at the terminating UE.

NOTE 2: If the originating UE does not use the precondition mechanism (see subclause 5.1.3.1), it will not include any precondition information in the SDP message body.

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 [169] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP crypto attribute according to RFC 4568 [168] and the profile defined in 3GPP TS 33.328 [19C]; 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 [222] and RFC 5764 [223] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP "a=3ge2ae:requested" attribute; and

– include the SDP tls-id attribute according to RFC 8842 [240].

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 [178], RFC 6714 [214] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C]; and

– include the SDP "a=3ge2ae:requested" attribute.

NOTE 3: TLS client role and TLS server role are determined according to RFC 6135 [215] (referenced by RFC 6714 [214]). If the SDP answer contains the SDP setup attribute with "active" attribute value, the answerer performs the TLS client role. If the SDP answer contains the SDP setup attribute with "passive" attribute value, the offerer performs the TLS client role.

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 [108] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C]; 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.

NOTE 4: RFC 4583 [108] specifies that the SDP answerer will act as the TLS server but leaves the impact of SDP renegotiation on TLS unspecified.

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 [217], RFC 8842 [240] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C];

– 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 [178], RFC 6714 [214] and the profile defined in 3GPP TS 33.328 [19C]; and

– include the SDP key-mgmt attribute according to RFC 4567 [167] and the profile defined in 3GPP TS 33.328 [19C];

NOTE 5: SDP fingerprint attribute is not included.

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 [167] and the profile defined in 3GPP TS 33.328 [19C] in the SDP answer, then the UE indicate the pre-shared key ciphersuites according to RFC 4279 [218] and the profile defined in 3GPP TS 33.328 [19C] 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.

NOTE 6: The UE can attempt a session establishment through multiple networks with different policies and potentially can need to send multiple INVITE requests and receive multiple 488 (Not Acceptable Here) responses from different CSCF nodes. The UE therefore takes into account the SDP message bodies of all the 488 (Not Acceptable Here) responses received related to the same session establishment when building a new INVITE request.

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 [30] and RFC 4032 [64].

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 3GPP TS 26.114 [9B] 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.

6.1.3 Handling of SDP at the terminating UE

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 [39] 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 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.

NOTE 1: If the terminating UE does not use the precondition mechanism (see subclause 5.1.4.1), it will ignore any precondition information received from the originating UE.

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 [228]; or

– otherwise respond with a 488 (Not Acceptable Here) response including a 301 Warning header field indicating "incompatible network address format".

NOTE 2: Upon receiving an initial INVITE request that does not include an SDP offer, the UE can accept the request and include an SDP offer in the first reliable response. The SDP offer will reflect the called user’s terminal capabilities and user preferences for the session.

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.

NOTE 3: Upon receiving an initial INVITE request, that includes an SDP offer containing connection addresses (in the "c=" parameter) equal to zero, the UE will select the media streams that is willing to accept for the session, reserve the QoS resources for accepted media streams, and include its valid connection address 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 [169];

– with an SDP crypto attribute as defined in RFC 4568 [168]; 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 [169] and the profile defined in 3GPP TS 33.328 [19C]; and

– including an SDP crypto attribute according to RFC 4568 [168] and the profile defined in 3GPP TS 33.328 [19C].

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 [222] and RFC 5764 [223];

– with the SDP fingerprint attribute as defined in RFC 8122 [241]; 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 [222] and RFC 5764 [223] and the profile defined in 3GPP TS 33.328 [19C];

– including the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C]; and

– including the SDP tls-id attribute according to RFC 8842 [240].

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 [178] and RFC 6714 [214];

– with the SDP fingerprint attribute as defined in RFC 8122 [241]; 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 [178], RFC 6714 [214] and the profile defined in 3GPP TS 33.328 [19C]; and

– including the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C].

NOTE 4: TLS client role and TLS server role are determined according to RFC 6135 [215] (referenced by RFC 6714 [214]). If the SDP answer contains the SDP setup attribute with "active" attribute value, the answerer performs the TLS client role. If the SDP answer contains the SDP setup attribute with "passive" attribute value, the offerer performs the TLS client role.

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 [108];

– with the SDP fingerprint attribute as defined in RFC 8122 [241]; 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 [108] and the profile defined in 3GPP TS 33.328 [19C]; and

– including the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C].

Unless a new TLS session is negotiated, subsequent SDP offers and answers shall not impact the previously negotiated TLS roles.

NOTE 5: RFC 4583 [108] specifies that the SDP answerer will act as the TLS server but leaves the impact of SDP renegotiation on TLS unspecified.

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 [217] and RFC 8842 [240];

– with the SDP fingerprint attribute as defined in RFC 8122 [241]; 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 [217], RFC 8842 [240] and the profile defined in 3GPP TS 33.328 [19C];

– including the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C]; 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 [178] and RFC 6714 [214]; and

– with the SDP key-mgmt attribute according to RFC 4567 [167] and the profile defined in 3GPP TS 33.328 [19C];

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

1) generate the SDP answer with the related MSRP based media:

a) transported using the MSRP over TLS transport protocol according to RFC 4975 [178], RFC 6714 [214] and the profile defined in 3GPP TS 33.328 [19C]; and

b) include the SDP key-mgmt attribute according to RFC 4567 [167] and the profile defined in 3GPP TS 33.328 [19C]; and

NOTE 6: SDP fingerprint attribute is not included.

2) indicate the pre-shared key ciphersuites according to RFC 4279 [218] and the profile defined in 3GPP TS 33.328 [19C] 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 [30] and RFC 4032 [64], 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 [30] and RFC 4032 [64] for the remote segment.

NOTE 7: It is out of scope of this specification which media streams are to be included in the SDP offer.

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 [30] and RFC 4032 [64], 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 [30] and RFC 4032 [64] 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.

NOTE 8: Upon receiving an initial INVITE request with one or more media streams which the terminating UE supports and one or more media streams which the UE does not support, the UE is not expected to reject the INVITE request just because of the presence of the unsupported media stream.

NOTE 9: Previous versions of this document mandated the use of the SDP inactive attribute in the SDP offer if the desired QoS resources for one or more media streams had not been reserved at the originating UE when constructing the SDP offer unless the originating UE knew that the precondition mechanism was supported by the remote UE. The use can still occur when interoperating with devices based on earlier versions of this document.

6.1.4 Session modification

6.1.4.1 General

This subclause applies after the 2xx response to the initial INVITE request has been sent or received.

6.1.4.2 Generating session modification request

If the precondition mechanism is used for the session modification, the following applies:

a) if the session modification does not increase the QoS requirement of the already established media stream (e.g., all the media streams in a call hold procedure, audio stream in a call upgrade procedure), in the SDP body of the request (re-INVITE, UPDATE, or PRACK), both local and remote QoS of this media shall be indicated as met; and

b) if the session modification increases the QoS requirement of some already established media stream(s) (e.g., request of using a different audio/video codec that requires higher bandwidth), or if the session modification adds a new media stream (e.g., call upgrade), the setting of the current and desired QoS status of the modified or added media stream shall be the same as specified in subclause 6.1.2. If the network fails to modify or reserve the required resources, the UE shall send a CANCEL request to terminate the session modification.

6.1.4.3 Receiving session modification request

If the precondition mechanism is used for the session modification, the settings of the current and desired QoS status shall be the same as specified in subclause 6.1.3. If the network cannot modify or reserve the required resources, the UE shall send a 580 (Precondition-Failure) response towards the UE that initiated the session modification.

6.2 Procedures at the P-CSCF

The P-CSCF shall perform IMS-ALG functionality:

– when the P-CSCF needs to perform procedures for hosted NAT traversal according to Annex F; or

– when the P-CSCF needs to perform procedures for media plane security (see subclause 6.7.2.2);

– when required by the user-related policies provisioned to the P-CSCF (see subclause 5.2.1);

– when the P-CSCF needs to perform ECN procedures (see subclause 6.7.2.3);

– when the P-CSCF needs to perform procedures for OMR (see subclause 6.7.2.4);

– when the P-CSCF needs to perform P-CSCF controlled NA(P)T and NA(P)T-PT (see subclause 6.7.2.5);

– when the P-CSCF needs to perform hosted NAT procedures (see subclause 6.7.2.6);

– when the P-CSCF needs to perform ICE procedures (see subclause 6.7.2.7); or

– when the P-CSCF needs to perform transcoding procedures (see subclause 6.7.2.8).

Upon receiving an initial INVITE request that includes the SDP offer containing only an IPv6 address (in the "c=" parameter) and if the P-CSCF knows that the terminating UE supports only IPv4 addressing and does not perform the IP version interworking as described in subclause 6.7.2.5.1, the P-CSCF may, based on local policy, respond with a 488 (Not Acceptable Here) response including a 301 Warning header field indicating "incompatible network address format".

NOTE 1: How the P-CSCF determines whether the UE supports only IPv4 addressing is implementation specific.

NOTE 2: Upon receiving an initial INVITE request that does not include an SDP offer, the P-CSCF can accept the request and receive an SDP offer in the first reliable response. The SDP offer will reflect the called user’s terminal capabilities and user preferences for the session.

When the P-CSCF receives any SIP request containing an SDP offer, the P-CSCF shall examine the media parameters in the received SDP offer.

If the P-CSCF finds any media parameters which are not allowed on the network by local policy or if available by bandwidth authorisation limitation information coming from the IP-CAN (e.g. via PCRF), the P-CSCF shall return a 488 (Not Acceptable Here) response containing an SDP message body. This SDP message body contains either all the media types, codecs and other SDP parameters which are allowed according to the local policy, or, based on configuration by the operator of the P-CSCF, a subset of these allowed parameters. This subset may depend on the content of the received SIP request. For each media line, the P-CSCF shall build the SDP message body in the 488 (Not Acceptable Here) response in the same manner as a UAS builds the SDP message body in a 488 (Not Acceptable Here) response as specifed in RFC 3261 [26]. The P-CSCF shall order the codecs with the most preferred codec listed first. If the SDP offer is encrypted, the P-CSCF may reject the request.

Subject to local policy, if it is not possible to generate a SDP message body (e.g. the available bandwidth is less than the bandwidth of any codec allowed by the local policy), the P-CSCF shall return a 486 (Busy here) response with a 370 Warning header field indicating "insufficient bandwidth".

When the P-CSCF receives a SIP response different from 200 (OK) response containing SDP offer, the P-CSCF shall not examine the media parameters in the received SDP offer, but the P-CSCF shall rather check the succeeding request containing the SDP answer for this offer, and if necessary (i.e. the SDP answer reduced by the UE still breaches local policy, or if available by bandwidth authorisation limitation information coming from the IP-CAN, e.g. via PCRF), the P-CSCF shall return a 488 (Not Acceptable Here) response containing the local policy allowed SDP message body. If the SDP answer is encrypted, the P-CSCF may reject the succeeding request.

When the P-CSCF receives a 200 (OK) response containing SDP offer, the P-CSCF shall examine the media parameters in the received SDP offer. If the P-CSCF finds any media parameters which are not allowed on the network by local policy or if available by bandwidth authorisation limitation information coming from the IP-CAN (e.g. via PCRF), the P-CSCF shall forward the SDP offer and on the receipt of the ACK request containing the SDP answer, the P-CSCF shall immediately terminate the session as described in subclause 5.2.8.1.2. If the SDP offer is encrypted, the P-CSCF shall forward the SDP offer and on the receipt of the ACK request containing the SDP answer, it may immediately terminate the session as described in subclause 5.2.8.1.2.

In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT controlled by the P-CSCF, or by a hosted NAT, the P-CSCF may need to modify the media connection data in SDP message bodies according to the procedures described in annex F or subclause 6.7.2.5.

The P-CSCF shall apply the same SDP policy to the initial request or response containing an SDP message body, and throughout the complete SIP session.

The P-CSCF may inspect, if present, the "b=RS" and "b=RR" lines in order to find out the bandwidth allocation requirements for RTCP.

Subject to local policy, the P-CSCF shall prohibit the negotiation of ECN during SDP offer/answer exchanges associated with multimedia priority service by removing any ECN attribute "a=ecn-capable-rtp" from the SDP offer and shall not invoke ECN for SIP transactions associated with multimedia priority service.

Additional procedures where the P-CSCF acts as an IMS-ALG are given in subclause 6.7.2. The IMS-ALG only applies where there are specific gateway capabilities to be provided.

6.3 Procedures at the S-CSCF

When the S-CSCF receives any SIP request containing an SDP offer, the S-CSCF shall examine the media parameters in the received SDP offer. If the S-CSCF finds any media parameters which are not allowed based on local policy or subscription (i.e. the information in the instances of the Core Network Service Authorization class in the service profile, described in 3GPP TS 29.228 [14]), the S-CSCF shall return a 488 (Not Acceptable Here) response containing an SDP message body. This SDP message body contains either all the media types, codecs and other SDP parameters which are allowed according to the local policy and users subscription or, based on configuration by the operator of the S-CSCF, a subset of these allowed parameters. This subset may depend on the content of the received SIP request. The S-CSCF shall build the SDP message body in the 488 (Not Acceptable Here) response in the same manner as a UAS builds the SDP message body in a 488 (Not Acceptable Here) response as specified in RFC 3261 [26]. If the SDP offer is encrypted, the S-CSCF may reject the request.

When the S-CSCF receives a SIP response different from 200 (OK) response containing SDP offer, the S-CSCF shall not examine the media parameters in the received SDP offer, but the S-CSCF shall rather check the succeeding request containing the SDP answer for this offer, and if necessary (i.e. the SDP answer reduced by the UE still breaches local policy), the S-CSCF shall return a 488 (Not Acceptable Here) response containing the local policy allowed SDP message body. If the SDP answer is encrypted, the S-CSCF may reject the succeeding request.

When the S-CSCF receives a 200 (OK) response containing an SDP offer, the S-CSCF shall examine the media parameters in the received SDP offer. If the S-CSCF finds any media parameters which are not allowed based on local policy or subscription (i.e. the information in the instances of the Core Network Service Authorization class in the service profile, described in 3GPP TS 29.228 [14]), the S-CSCF shall forward the SDP offer and on the receipt of the ACK request containing the SDP answer, the S-CSCF shall immediately terminate the session as described in subclause 5.4.5.1.2. If the SDP offer is encrypted, the S-CSCF shall forward the SDP offer and on the receipt of the ACK request containing the SDP answer, it may immediately terminate the session as described in subclause 5.4.5.1.2.

6.4 Procedures at the MGCF

6.4.1 Calls originating from circuit-switched networks

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:

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

6.4.2 Calls terminating in circuit-switched networks

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:

a) 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 [30]) 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;

b) end-to-access edge media security is not applicable to the MGCF; and

c) procedures related to the handling of the IP-CAN bearer rejection, modification or release are not applicable to the MGCF.

6.4.3 Optimal Media Routeing (OMR)

If the MGCF supports OMR it shall also perform the UA procedures described in 3GPP TS 29.079 [11D].

6.4.4 Explicit congestion control support in MGCF

An MGW associated with an MGCF can support Explicit Congestion Notification (ECN) according to RFC 3168 [189], 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 [188], 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 [188].

NOTE 1: The "leap" initialisation method is the only initialisation method the MGW supports over the Mn interface in this release.

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 [188].

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.

6.5 Procedures at the MRFC

Void.

6.6 Procedures at the AS

6.6.1 General

Since an AS may provide a wide range of different services, procedures for the SDP usage for an AS acting as originating UA, terminating UA or third-party call control role are dependent on the service provided to the UA and on the capabilities on the remote UA. There is no special requirements regarding the usage of the SDP, except the requirements for the SDP capabilities described in the following paragraphs and clause A.3:

1) Providing that an INVITE request generated by an AS contains an SDP message body, the AS has the capability of reflecting the originating AS’s capabilities, desired QoS and precondition requirements for the session in the SDP message body.

2) When the AS sends a 183 (Session Progress) response with an SDP message body including one or more "m=" media types, it has the capability of requesting confirmation for the result of the resource reservation at the originating endpoint.

When an AS acts as a B2BUA, and it controls media resources using an MRF, it may support OMR. When the AS supports OMR, and it controls media resources using an MRF, it shall also perform the procedures described in 3GPP TS 29.079 [11D].

6.6.2 Transcoding

The AS shall send an SDP offer to the MRFC with the codecs supported by the caller and the codecs to be offered towards the callee, and the IP address and port information received from caller, in seperate media lines. When receiving an SDP answer from the MRFC, the AS shall forward the received selected codecs and IP address and port information in the callee´s media line(s) as an SDP offer towards the callee.

When the callee provides an SDP answer with selected codecs and IP address and port information, the AS shall forward this information within a new SDP offer to the MRFC. When receiving the corresponding SDP answer from the MRFC, the AS shall forward the address and port information within the caller´s media line(s) as an SDP answer towards the caller.

The codecs offered for transcoding are subject to network policy which shall be according to clause T.2.

6.6.3 AS procedures to support WebRTC media optimization procedure

When an AS acts as a B2BUA, and it controls media resources using an MRF, it may support switching to transparent media for WebRTC when those media have been negotiated, as specified in annex U.2.4 of 3GPP TS 23.228 [7]. An AS that supports switching to transparent media for WebRTC shall apply the procedures in the present subclause.

NOTE 1: The AS can in addition apply OMR procedures described in 3GPP TS 29.079 [11D].

If the AS receives an SDP offer that contains any "tra-contact" SDP attribute, and the AS decides to include an MRF in the media path, the AS shall:

1) include the address information as received from the MRF in that contact line and also encapsulate the address information into each received "tra-contact" attribute, replacing previous information; and

2) transparently pass all received "tra-m-line", "tra-att", "tra-SCTP-association", "tra-media-line-number" and "tra-bw" SDP attributes.

NOTE 2: When interacting with the MRF to reserve resources and provide the information needed for media handling the AS will ask for resources suitable for the media described in the SDP offer outside the "tra-m-line", "tra-att" and "tra-bw" SDP attributes.

If an AS receives an SDP answer and the SDP answer includes "tra-m-line" media level SDP attributes, the AS shall:

1) configure the MRF to transparently pass the media described in the received "tra-m-line", "tra-att", "tra-SCTP-association", and "tra-bw" SDP attributes; and

2) transparently pass all received "tra-m-line", "tra-att", "tra-SCTP-association" and "tra-bw" SDP attributes.

NOTE 3: When interacting with MRF the AS will deactivate media plane interworking in the MRF. The AS will use the "tra-SCTP-association" SDP attributes to determine which media streams need to be multiplexed into the same SCTP association.

6.7 Procedures at the IMS-ALG functionality

6.7.1 IMS-ALG in IBCF

6.7.1.1 General

When the IBCF acts as an IMS-ALG, it makes procedures as for an originating UA and terminating UA. The IMS-ALG acts as a B2BUA. The general treatment of the SDP information between originating UA and terminating UA is described in 3GPP TS 29.162 [11A]. For the use of the IMS-ALG for specific capabilities, additional procedures are defined in subsequent subclauses.

Subject to local policy, the IBCF shall prohibit the negotiation of ECN during SDP offer/answer exchanges associated with multimedia priority service by removing any ECN attribute "a=ecn-capable-rtp" from the SDP offer and shall not invoke ECN for SIP transactions associated with multimedia priority service.

NOTE: Disabling ECN in an IBCF does not prevent a P-CSCF (IMS ALG), subject to roaming agreement, from applying ECN over the access network between a UE and the P-CSCF (IMS-ALG).

6.7.1.2 IMS-ALG in IBCF for support of ICE

6.7.1.2.1 General

This subclause describes procedures of an IBCF to support ICE as defined in RFC 8445 [289] and RFC 8839 [290].

If no TrGW is inserted, an IBCF may transparently pass ICE related SDP attibutes to support ICE. The remaining procedures in this subclause are only applicable if the IBCF is inserting a TrGW on the media plane.

When the IBCF with attached TrGW receives SDP candidate information from the SDP offerer the IBCF shall not forward the candidate information towards the SDP answerer. When the IBCF receives SDP candidate information from the SDP answerer the IBCF shall not forward the candidate information towards the SDP offerer. The remaining procedures in this subclause are optional.

NOTE: An IBCF that removes and/or does not provide ICE related SDP attributes (e.g. a=candidate) in the offer/answer exchange will cause the ICE procedures to be aborted and the address and port information in the m and c lines of the SDP offer will be used. If this address and port information contains the relayed candidate address of a STUN Relay server, as recommended by ICE, then an extra media relay server will be used for the session which is not necessary nor desirable.

The IBCF with attached TrGW performs separate ICE procedures towards the SDP offerer and the SDP answerer. The usage of ICE is negotiated separately with the SDP offerer and SDP answerer, and ICE may be applied independently at either side. Furthermore, the IBCF may be configured to apply ICE procedures only towards one network side, e.g. towards the IM CN subsystem it belongs to.

Since the IBCF is not located behind a NAT, it does not request the TrGW to generate keep-alive messages even when acting as a full ICE entity. The IBCF only requests the TrGW to terminate and generate STUN messages used for the candidate selection procedures.

Since the IBCF is not located behind a NAT the IBCF shall only include host candidates in SDP offers and answers generated by the IBCF.

6.7.1.2.2 IBCF full ICE procedures for UDP based streams

6.7.1.2.2.1 General

This subclause describes the IBCF full ICE procedures for UDP based streams.

6.7.1.2.2.2 IBCF receiving SDP offer

When the IBCF receives an SDP offer including ICE candidate information, the IBCF shall send the candidate information for each UDP based stream received in the SDP offer towards the TrGW. The IBCF will request the TrGW to reserve media- and STUN resources towards the SDP offerer, based on the candidate information, in order to allow the TrGW to perform the necessary connectivity checks per the ICE procedures.

If the SDP offerer is acting as an ICE controller entity the IBCF shall act as an ICE controlled entity in the direction towards the SDP offerer. If the SDP offerer is acting as an ICE controlled entity the IBCF shall act as an ICE controller entity in the direction towards the SDP offerer.

6.7.1.2.2.3 IBCF sending SDP offer

Prior to sending an SDP offer, the IBCF may choose to apply related ICE procedues, e.g. if it expects to interact with terminals applying procedures as described in subclause K.5.2, and if both the IBCF and TrGW also support ICE procedures. To invoke these ICE procedures, the IBCF will request the TrGW to reserve media- and STUN resources towards the SDP answerer for each UDP based media stream and include a host candidate attribute for each UDP based stream in the SDP offer, providing the reserved address and port at the TrGW as destination.

The IBCF shall always act as an ICE controller entity towards the SDP answerer.

NOTE: The host candidate address included by the IBCF in the generated SDP offer matches the c- and m line information for the associcated UDP stream in the SDP offer.

6.7.1.2.2.4 IBCF receiving SDP answer

When the IBCF receives an SDP answer including ICE candidate information, the IBCF will send the candidate information for each UDP based stream received in the SDP answer towards the TrGW.

The IBCF will request the TrGW to perform ICE candidate selection procedures towards the SDP answerer. The IBCF will request the TrGW to inform the IBCF, for each UDP stream, which candidate pair has been selected towards the SDP answerer, once the candidate selection procedure towards the SDP answerer has finished.

If the TrGW indicates to the IBCF that, for at least one UDP stream, the selected candidate pair does not match the c- and m- line address information for the associated UDP stream, exchanged between the IBCF and the SDP answerer, and the IBCF acts an ICE controller entity towards the SDP answerer, the IBCF shall send a new offer towards the SDP answerer in order to allign the c- and m- lines address information with the chosen candidate pair for the associated UDP stream.

6.7.1.2.2.5 IBCF sending SDP answer

When the IBCF generates an SDP answer for an offer that included ICE candidate information, the IBCF will request the TrGW to reserve media- and STUN resources towards the SDP offerer for each UDP based media stream and include an SDP host candidate attribute for each UDP based stream in the SDP answer, providing the reserved address and port at the TrGW as destination.

The IBCF shall in the generated SDP answer include host candidate information which matches the c- and m line information for the associated UDP stream in the SDP answer.

The IBCF will request the TrGW to perform ICE candidate selection procedures towards the SDP offerer. The IBCF will request the TrGW to inform the IBCF, for each UDP stream, which candidate pair has been selected towards the SDP offerer, once the candidate selection procedure towards the SDP answerer has finished.

If the TrGW indicates to the IBCF that the selected candidate pair towards the SDP offerer does not match the c- and m- line address information for the associated UDP stream, exchanged between the IBCF and the SDP offerer, and the IBCF acts an ICE controller entity towards the SDP offerer, the IBCF shall send an offer towards the SDP offerer (which will now act as an SDP answerer) in order to allign the c- and m- line address information with the chosen candidate pair for the associated UDP stream.

6.7.1.2.3 IBCF ICE lite procedures for UDP based streams

When the IBCF is using ICE lite procedures for UDP based streams, the IBCF procedures are identical as described in subclause 6.7.1.2.2, with the following exceptions:

– The IBCF always acts as an ICE controlled entity towards the SDP offerer and towards the SDP answerer, and;

– The IBCF requests the TrGW to perform ICE lite candidate selection procedures, as defined in ICE

6.7.1.2.4 ICE procedures for TCP based streams

6.7.1.2.4.1 General

The IBCF shall terminate ICE procedures for TCP based streams. Instead the IBCF will use the mechanism defined in RFC 4145 [83] for establishing TCP based streams, as defined in RFC 6544 [131].

An entity that supports ICE continues the ICE procedures for UDP based streams, even if no candidates are provided for TCP based streams.

NOTE: The IBCF ICE procedures for TCP based streams are identical no matter whether the IBCF uses full ICE- or ICE lite- procedures for UDP based streams.

6.7.1.2.4.2 IBCF receiving SDP offer

When the IBCF receives an SDP offer, the IBCF shall ignore the candidate attributes for TCP based streams. The IBCF shall not send the candidate information for TCP based streams towards the TrGW.

6.7.1.2.4.3 IBCF sending SDP offer

When the IBCF generates an SDP offer the IBCF shall include an "actpass" setup attribute, as defined in RFC 4145 [83], for each TCP based stream, which will cause the SDP answerer to initiate the TCP connections towards the TrGW. The IBCF shall not include any candidate attributes for TCP based streams in the SDP offer.

6.7.1.2.4.4 IBCF receiving SDP answer

Since the IBCF does not include candidates in the SDP offer towards the SDP answerer, there are no ICE specific procedures when the IBCF receives an SDP answer.

NOTE: If the SDP answer contains candidate attributes for TCP based streams, the IBCF simply discards the candidate attributes.

6.7.1.2.4.5 IBCF sending SDP answer

When the IBCF generates an SDP answer the IBCF shall include a "passive" setup attribute, as defined in RFC 4145 [83], for each TCP based stream, which will cause the SDP offerer to initiate the TCP connections towards the TrGW. The IBCF shall not include any candidate attributes for TCP based streams in the SDP answer.

6.7.1.3 IMS-ALG in IBCF for transcoding

Before forwarding the SDP offer to the answerer, the IBCF may add to the selected media one or more codecs to the codec list contained in the SDP offer. The codecs added to the SDP offer are based on local policy and shall be in accordance with the requirements of clause T.2.

NOTE 1: The local policy can be based on supported codecs in the terminating network.

Upon receipt of an SDP answer, the IBCF shall inspect the list of the returned codecs and proceed as follows:

– if the list contains at least one of the codecs belonging to the original SDP offer, the IBCF shall not invoke the transcoding function; and

– if the list contains none of the codecs belonging to the original SDP offer, the IBCF shall select one of the returned codecs introduced in the answer and invoke the transcoding function. In order to perform the transcoding the IBCF shall select one of the codecs originally offered and set to a non-zero port value the related media stream in the answer sent to the offerer.

NOTE 2: The protocol used between IBCF and TrGW to allow the transport plane media trascoding control is out of scope of this specification. The codec selected by the answerer and the one selected by the IBCF and sent to the offerer can be used to instruct the TrGW for the transcoding purposes.

The IBCF shall remove from the SDP the codecs added to the original SDP offer before forwarding the SDP answer to the offerer.

NOTE 3: In accordance with normal SDP procedure the transcoding IBCF informs the answerer of the properties of the chosen codecs (IP-address and ports).

6.7.1.4 IMS-ALG in IBCF for NA(P)T and NA(P)T-PT controlled by the IBCF

6.7.1.4.1 General

This subclause describes the IBCF procedures for supporting the scenario where IP address and/or port conversions occur at the TrGW level in the media path between the UE and the backbone. Two types of address conversions are covered:

– IP version interworking (NA(P)T-PT); and

– IP address/port translation (NA(P)T).

When the IBCF performs procedures for IBCF controlled NA(P)T and NA(P)T-PT, the IBCF shall modify the IP address(es) and port numbers (in case of NA(P)T) in SDP offers and answers, based on the IP address(es) and port number(s) received from the TrGW, as described in subclause 6.7.2.1.

For terminating sessions the IBCF may towards a UE performing the functions of an external attached network indicate in the SDP offer alternate IP address versions (IPv4 and IPv6) by inserting two "altc" attributes as defined in RFC 6947 [228]. The order of setting the two IP addresses in the two "altc" SDP attributes shall be based on local policy. The insertion of the "altc" attributes is independent of their presence in the received SDP offer.

NOTE 1: The insertion of alternate IP versions allows avoiding the rejection of the SDP offer because of incompatible network address formats and when the request terminates in a corporate network enables the corporate network to avoid IP version interworking.

NOTE 2: The handling of alternative IP addresses between the IMS-ALG and the TrGW is defined in 3GPP TS 29.162 [11A].

If the IBCF sends an initial INVITE request that includes only an IPv6 address in the SDP offer, and receives a 488 (Not Acceptable Here) response with 301 Warning header field indicating "incompatible network address format", the IBCF shall send an ACK as per standard SIP procedures. Subsequently, based on operator policy, the IBCF may, by performing the IP version interworking, 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.

6.7.1.5 IMS-ALG procedure in IBCF to support WebRTC media optimization procedure

The IMS-ALG in the IBCF may support switching to transparent media for WebRTC when those media have been negotiated, as specified in annex U.2.4 of 3GPP TS 23.228 [7]. An IMS-ALG that supports switching to transparent media for WebRTC shall apply the procedures in the present subclause.

NOTE 1: The IMS-ALG can in addition apply OMR procedures described in 3GPP TS 29.079 [11D].

If the IMS-ALG receives an SDP offer that contains any "tra-contact" SDP attribute, and the IMS-ALG decides to include a TrGw in the media path, the IMS-ALG shall:

1) include the address information as received from the TrGW in that contact line and also encapsulate the address information into each received "tra-contact" attribute, replacing previous information; and

2) transparently pass all received "tra-m-line", "tra-att", "tra-SCTP-association", "tra-media-line-number" and "tra-bw" SDP attributes.

NOTE 2: When interacting with the TrGW to reserve resources and provide the information needed for media handling the IMS-ALG will ask for resources suitable for the media described in the SDP offer outside the "tra-m-line", "tra-att" and "tra-bw" SDP attributes. The details of the interaction between the IMS-ALG and the TrGW are out of scope of this document.

If an IMS-ALG receives an SDP answer and the SDP answer includes "tra-m-line" media level SDP attributes, the IMS-ALG shall:

1) configure the TrGW to transparently pass the media described in the received "tra-m-line", "tra-att", "tra-SCTP-association", and "tra-bw" SDP attributes; and

2) transparently pass all received "tra-m-line", "tra-att", "tra-SCTP-association" and "tra-bw" SDP attributes.

NOTE 3: When interacting with TrGW the IMS-AGW will deactivate media plane interworking in the TrGW. The details of this interaction are out of scope of this document. The IMS-AGW will use the "tra-SCTP-association" SDP attributes to determine which media streams need to be multiplexed into the same SCTP association.

6.7.2 IMS-ALG in P-CSCF

6.7.2.1 General

This subclause specifies the general procedures for the support of SDP in IMS-ALG within the P-CSCF. For the use of the IMS-ALG for specific capabilities, additional procedures are defined in subsequent subclauses.

When the IMS-ALG receives an SDP offer, it shall create a new SDP offer, based the contents of the received SDP offer, modified according to procedures and policies associated with specific capabilities that the IMS-ALG is used for, according to capabilities supported by the IMS-AGW, and to provide the IP address and port information received by the IMS-AGW.

When the IMS-ALG receives an SDP answer, it shall create a new SDP answer, to respond to the originally received SDP offer, modified according to the same procedures and policies that were used to modify the SDP offer.

The P-CSCF may receive multiple provisional responses with an SDP answer due to forking of a request before the first final answer is received. For each SDP answer received in such subsequent provisional responses, the P-CSCF shall apply the procedure in this subclause.

After the session is established, it is possible for both ends of the session to change the media connection data for the session. When the P-CSCF receives a SDP offer/answer where port number(s) or IP address(es) is/are included, there are three different possibilities:

– IP address(es) or/and port number(s) have been added;

– IP address(es) and port number(s) have been reassigned to the end points; or

NOTE 1: If necessary, the P-CSCF will request the IMS-AGW access gateway to release the resources related to the previously assigned IP address(es) and port number(s).

– no change has been made to the IP address(es) and port number(s).

NOTE 2: In the particular case of RTP flows, port conversions also apply to the associated RTCP flows.

6.7.2.2 IMS-ALG in P-CSCF for media plane security

When the P-CSCF acts as an IMS-ALG, it acts as a B2BUA and modifies the SDP as described as described in 3GPP TS 23.334 [7F].

If the P-CSCF indicated support for end-to-access-edge media security using SDES during registration:

1) upon receiving an SDP offer from the served UE containing an end-to-access-edge protected RTP based media, i.e. a RTP media stream:

– transported using the SRTP transport protocol as defined in RFC 3711 [169];

– with an SDP crypto attribute as defined in RFC 4568 [168]; and

– with the SDP "a=3ge2ae:requested" attribute;

the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and SRTP is concerned, and shall:

– if the SDP offer contains a Transport Protocol Capability SDP attribute (see RFC 5939 [137]) offering:

a) "RTP/SAVPF" transport, e.g. "a=tcap:x RTP/SAVPF", replace this transport with "RTP/AVPF" within that attribute; and

b) "RTP/SAVP" transport, e.g. "a=tcap:x RTP/SAVP", replace this transport with "RTP/AVP" within that attribute; and

– strip the SDP "a=3ge2ae:requested" attribute and the SDP crypto attribute from the end-to-access-edge protected RTP based media of the received SDP offer; and

2) upon sending an SDP answer to the SDP offer from the served UE, for each end-to-access-edge protected RTP based media of the SDP offer from the served UE which is accepted in the SDP answer, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and SRTP is concerned and shall:

– indicate the SRTP transport protocol according to RFC 3711 [169] and the profile defined in 3GPP TS 33.328 [19C]; and

– include a SDP crypto attribute according to RFC 4568 [168] and the profile defined in 3GPP TS 33.328 [19C].

If the served 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 2ae-media security using SDES during registration:

1) upon receiving an SDP offer from remote user with an RTP based media, for each end-to-access-edge protected RTP based media, i.e. a RTP based media except those for which the result of the SDP offer / answer exchange results in the application of an end-to-end media security mechanism, the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and RTP is concerned, and shall:

– remove any SDP crypto attribute and any "a=acap:x crypto" SDP attribute (see RFC 5939 [137]);

– if the SDP offer contains any potential configuration(s) using "RTP/SAVPF" transport or "RTP/SAVP" transport, as offered in corresponding Transport Protocol Capability SDP attribute(s) (see RFC 5939 [137]), (e.g. "a=tcap:x RTP/AVPF a=pcfg:y t=x"), remove those potential configuration(s);

NOTE: Keeping the related "RTP/SAVPF" transport or "RTP/SAVP" transport within a Transport Protocol Capability SDP attribute that also contains other transports avoids a potential need to renumber other transports and adjust other potential configurations in the SDP offer and the actual configuration in the SDP answer accordingly.

– if the SDP offer contains a Transport Protocol Capability SDP attribute (see RFC 5939 [137]) offering:

a) "RTP/AVPF" transport (e.g. "a=tcap:x RTP/AVPF"), replace this transport with "RTP/SAVPF" within that attribute; and

b) "RTP/AVP" transport (e.g. "a=tcap:x RTP/AVP"), replace this transport with "RTP/SAVP" within that attribute;

– if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939 [137]), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);

– offer SRTP transport protocol according to RFC 3711 [169] and the profile defined in 3GPP TS 33.328 [19C];

– include a SDP crypto attribute according to RFC 4568 [168] and the profile defined in 3GPP TS 33.328 [19C]; and

– include a SDP "a=3ge2ae:applied" attribute; and

2) upon receiving an SDP answer to the SDP offer from remote user, for each accepted end-to-access-edge protected RTP based media, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and RTP is concerned, and shall remove the SDP crypto attribute.

If the P-CSCF indicated support for the end-to-access-edge media security for RTP media using DTLS-SRTP and certificate fingerprints during registration:

1) upon receiving an SDP offer from the served UE containing an end-to-access-edge protected RTP based media, i.e. an RTP based media:

– transported using "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as the transport protocol according to RFC 5763 [222] and RFC 5764 [223];

– with the SDP fingerprint attribute as defined in RFC 8122 [241];

– with the SDP "a=3ge2ae:requested" attribute; and

– with the SDP tls-id attribute as defined in RFC 8842 [240];

the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and "RTP/AVP" or "RTP/AVPF" over UDP is concerned, and shall strip the SDP "a=3ge2ae:requested" attribute, the SDP fingerprint attribute and the SDP tls-id attribute from the RTP based media of the received SDP offer; and

2) upon sending an SDP answer to the SDP offer from the served UE, for each end-to-access-edge protected RTP based media of the SDP offer from the served UE that is accepted in the SDP answer, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and "RTP/AVP" or "RTP/AVPF" over UDP is concerned and shall:

– indicate the "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as the transport protocol according to RFC 5763 [222], RFC 5764 [223] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C]; and

– include the SDP tls-id attribute as defined in RFC 8842 [240].

If the served 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:

1) upon receiving an SDP offer from remote UE with an RTP based media, for each end-to-access-edge protected RTP based media, i.e. an RTP based media except those for which the result of the SDP offer / answer exchange results in the application of an end-to-end security mechanism, the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and "RTP/AVP" or "RTP/AVPF" over UDP is concerned, and shall:

– remove any SDP fingerprint attribute;

– remove any SDP tls-id attribute;

– offer "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as the transport protocol according to RFC 5763 [222], RFC 5764 [223] and the profile defined in 3GPP TS 33.328 [19C];

– if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939 [137]), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP "a=3ge2ae:applied" attribute; and

– include the SDP tls-id attribute as defined in RFC 8842 [240]; and

2) upon receiving an SDP answer to the SDP offer from remote user, for each accepted end-to-access-edge protected RTP based media, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and "RTP/AVP" or "RTP/AVPF" over UDP is concerned, and shall remove the SDP fingerprint attribute and SDP tls-id attribute.

If the P-CSCF indicated support for the end-to-access-edge media security for MSRP using TLS and certificate fingerprints during registration:

1) upon receiving an SDP offer from the served UE containing an end-to-access-edge protected MSRP based media, i.e. an MSRP based media:

– transported using the MSRP over TLS transport protocol as defined in RFC 4975 [178] and RFC 6714 [214];

– with the SDP fingerprint attribute as defined in RFC 8122 [241]; and

– with the SDP "a=3ge2ae:requested" attribute;

the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and MSRP is concerned, and shall strip the SDP "a=3ge2ae:requested" attribute and the SDP fingerprint attribute from the end-to-access-edge protected MSRP based media of the received SDP offer; and

2) upon sending an SDP answer to the SDP offer from the served UE, for each end-to-access-edge protected MSRP based media of the SDP offer from the served UE which is accepted in the SDP answer, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and MSRP is concerned and shall:

– indicate the MSRP over TLS transport protocol according to RFC 4975 [178], RFC 6714 [214] and the profile defined in 3GPP TS 33.328 [19C]; and

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C].

If the served 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:

1) upon receiving an SDP offer from remote user with an MSRP based media, for each end-to-access-edge protected MSRP based media, i.e. an MSRP based media except those for which the result of the SDP offer / answer exchange results in the application of an end-to-end security mechanism, the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and MSRP is concerned, and shall:

– remove any SDP fingerprint attribute;

– offer MSRP over TLS transport protocol according to RFC 4975 [178], RFC 6714 [214] and the profile defined in 3GPP TS 33.328 [19C];

– if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939 [137]), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C]; and

– include the SDP "a=3ge2ae:applied" attribute; and

2) upon receiving an SDP answer to the SDP offer from remote user, for each accepted end-to-access-edge protected MSRP based media, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and MSRP is concerned, and shall remove the SDP fingerprint attribute.

If the P-CSCF indicated support for the end-to-access-edge media security for BFCP using TLS and certificate fingerprints during registration:

1) upon receiving an SDP offer from the served UE containing an end-to-access-edge protected BFCP based media, i.e. a BFCP based media:

– transported using the BFCP over TLS transport protocol as defined in RFC 4583 [108];

– with the SDP fingerprint attribute as defined in RFC 8122 [241]; and

– with the SDP "a=3ge2ae:requested" attribute;

the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and BFCP is concerned, and shall strip the SDP "a=3ge2ae:requested" attribute and the SDP fingerprint attribute from the BFCP based media of the received SDP offer; and

2) upon sending an SDP answer to the SDP offer from the served UE, for each end-to-access-edge protected BFCP based media of the SDP offer from the served UE which is accepted in the SDP answer, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and BFCP is concerned and shall:

– indicate the BFCP over TLS transport protocol according to RFC 4583 [108] and the profile defined in 3GPP TS 33.328 [19C]; and

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C].

If the served 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:

1) upon receiving an SDP offer from remote UE with an BFCP based media, for each end-to-access-edge protected BFCP based media, i.e. a BFCP based media except those for which the result of the SDP offer / answer exchange results in the application of an end-to-end security mechanism, the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and BFCP is concerned, and shall:

– remove any SDP fingerprint attribute;

– offer BFCP over TLS transport protocol according to RFC 4583 [108] and the profile defined in 3GPP TS 33.328 [19C];

– if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939 [137]), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C]; and

– include the SDP "a=3ge2ae:applied" attribute; and

2) upon receiving an SDP answer to the SDP offer from remote user, for each accepted end-to-access-edge protected BFCP based media, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and BFCP is concerned, and shall remove the SDP fingerprint attribute.

If the P-CSCF indicated support for the end-to-access-edge media security for UDPTL over DTLS and certificate fingerprints during registration:

1) upon receiving an SDP offer from the served UE containing an end-to-access-edge protected UDPTL based media, i.e. a UDPTL based media:

– transported using the UDPTL over DTLS transport protocol as defined in RFC 7345 [217] and RFC 8842 [240];

– with the SDP fingerprint attribute as defined in RFC 8122 [241];

– with the SDP "a=3ge2ae:requested" attribute; and

– with the SDP tls-id attribute as defined in RFC 8842 [240];

the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and UDPTL is concerned, and shall strip the SDP "a=3ge2ae:requested" attribute and the SDP fingerprint attribute and the SDP tls-id attribute from the UDPTL based media of the received SDP offer; and

2) upon sending an SDP answer to the SDP offer from the served UE, for each end-to-access-edge protected UDPTL based media of the SDP offer from the served UE which is accepted in the SDP answer, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and UDPTL is concerned and shall:

– indicate the UDPTL over DTLS transport protocol according to RFC 7345 [217], RFC 8842 [240] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C]; and

– include the SDP tls-id attribute as defined in RFC 8842 [240].

If the served 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:

1) upon receiving an SDP offer from remote UE with an UDPTL based media, for each end-to-access-edge protected UDPTL based media, i.e. a UDPTL based media except those for which the result of the SDP offer / answer exchange results in the application of an end-to-end security mechanism, the P-CSCF shall invoke IMS-ALG procedures, will act as defined in 3GPP TS 23.334 [7F] as far as SDP and UDPTL is concerned, and shall:

– remove any SDP fingerprint attribute;

– remove any SDP tls-id attribute;

– offer UDPTL over DTLS transport protocol according to RFC 7345 [217], RFC 8842 [240] and the profile defined in 3GPP TS 33.328 [19C];

– if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939 [137]), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);

– include the SDP fingerprint attribute according to RFC 8122 [241] and the profile defined in 3GPP TS 33.328 [19C];

– include the SDP "a=3ge2ae:applied" attribute; and

– include the SDP tls-id attribute as defined in RFC 8842 [240]; and

2) upon receiving an SDP answer to the SDP offer from remote user, for each accepted end-to-access-edge protected UDPTL based media, the P-CSCF will act as defined in 3GPP TS 23.334 [7F] as far as SDP and UDPTL is concerned, and shall remove the SDP fingerprint attribute and SDP tls-id attribute.

6.7.2.3 IMS-ALG in P-CSCF for explicit congestion control support

6.7.2.3.1 General

An IMS-ALG may support ECN according to RFC 6679 [188].

Subject to local policy, an IMS-ALG shall prohibit the negotiation of ECN during SDP offer/answer exchanges associated with multimedia priority service by removing any ECN attribute "a=ecn-capable-rtp" from the SDP offer and shall not invoke ECN for SIP transactions associated with multimedia priority service.

6.7.2.3.2 Incoming SDP offer with ECN

If the IMS-ALG receives an SDP offer containing the "a=ecn-capable-rtp" attribute as specified in RFC 6679 [188] and:

– the IMS-ALG knows via configuration that the IMS-AGW supports transparently forwarding of ECN bits according to RFC 3168 [189];

– the IMS-ALG knows via configuration that the (IMS) network handles ECN-marked packets properly; and

– the IMS-ALG does not configure the IMS-AGW to transcode,

then the IMS-ALG shall:

– if the "ecn-capable-rtp" attribute includes both the "ice" initialisation method and other initialisation methods, remove the "ice" initialisation method from the "ecn-capable-rtp" attribute and add the attribute with this modification in the outgoing the SDP offer;

– if the "ecn-capable-rtp" attribute only includes the "ice" initialisation method, do not include the "ecn-capable-rtp" attribute it outgoing SDP offer; and

– if the "ecn-capable-rtp" attribute did not includes the "ice" initialisation method include the unmodified "ecn-capable-rtp" attribute within the outgoing SDP offer.

If the IMS-ALG receives an SDP offer containing the ECN attribute "a=ecn-capable-rtp" as specified in RFC 6679 [188] and any of the following conditions apply:

– the IMS-ALG knows by configuration that the IMS-AGW does not support transparent transport of ECN-marked packets;

– the IMS-ALG knows by configuration that the (IMS) network does not properly handle ECN-marked packets; or

– the IMS-ALG does not configure the IMS-AGW to transcode,

then the IMS-ALG shall not include ECN attributes in the outgoing SDP offer, and, if the IMS-ALG knows in addition via configuration that the IMS-AGW supports acting as an ECN endpoint and that the IMS-ALG supports at least some of the initialisation methods offered within the "a=ecn-capable-rtp" attribute, the IMS-ALG shall:

– select an initialisation method supported by the IMS-AGW; and

– return a SDP answer according to the capabilities of the IMS-AGW, containing the "a=ecn-capable-rtp" attribute,

and the IMS-ALG will configure the IMS-AGW to act as an end point for ECN.

If the IMS-ALG receives an SDP answer containing the "a=ecn-capable-rtp" attribute it will instruct the IMS-AGW to transparently forward the ECN bits described in RFC 3168 [189].

6.7.2.3.3 Incoming SDP offer without ECN

If the IMS-ALG receives a SDP offer without the "a=ecn-capable-rtp" attribute and all of the following conditions apply:

– the IMS-ALG knows via configuration that the IMS-AGW supports acting as ECN endpoint; and

– the IMS-ALG knows via configuration that the succeeding network supports ECN,

then the IMS-ALG may include the "a=ecn-capable-rtp" attribute in the offer it forwards towards the succeeding node, indicating the related capabilities of the IMS-AGW.

If the IMS-ALG inserted ECN attributes in the SDP offer and receives an SDP answer containing the "a=ecn-capable-rtp" attribute, the IMS-ALG shall return the SDP answer to the preceding node removing the "a=ecn-capable-rtp" attribute, and will configure the IMS-AGW to act as an ECN endpoint.

6.7.2.4 IMS-ALG in P-CSCF for Optimal Media Routeing (OMR)

Based on operator policy, the P-CSCF shall remove OMR related SDP attributes before it sends an SDP offer or answer towards an UE, as specified in subclause 2.1.9 of 3GPP TS 29.079 [11D].

6.7.2.5 IMS-ALG in P-CSCF for NA(P)T and NA(P)T-PT controlled by the P-CSCF

6.7.2.5.1 General

This subclause describes the P-CSCF procedures for supporting the scenario where IP address and/or port conversions occur at the IMS-AGW level in the media path between the UE and the backbone. Two types of address conversions are covered:

– IP version interworking (NA(P)T-PT); and

– IP address/port translation (NA(P)T).

When the P-CSCF performs procedures for P-CSCF controlled NA(P)T and NA(P)T-PT, it shall modify the IP address(es) and port numbers (in case of NA(P)T) in SDP offers and answers, based on the IP address(es) and port number(s) received from the IMS-AGW, as described in subclause 6.7.2.1.

For terminating sessions the P-CSCF may towards a UE performing the functions of an external attached network indicate in the SDP offer alternate IP address versions (IPv4 and IPv6) by inserting two "altc" attributes as defined in RFC 6947 [228]. The order of setting the two IP addresses in the two "altc" SDP attributes shall be based on local policy. The insertion of the "altc" attributes is independent of their presence in the received SDP offer.

NOTE 2: The handling of alternative IP addresses between the IMS-ALG and the TrGW is defined in 3GPP TS 23.334.

6.7.2.6 IMS-ALG in P-CSCF for support of hosted NAT

6.7.2.6.1 General

When the P-CSCF performs procedures for hosted NAT, it shall modify the IP address(es) and port numbers, based on the IP address(es) and number(s) received from the IMS-AGW, as described in subclause 6.7.2.1.

6.7.2.6.2 Hosted NAT traversal for TCP based streams

When the P-CSCF acts as an IMS-ALG, it acts as a B2BUA and modifies the SDP as described as described in 3GPP TS 23.334 [7F].

6.7.2.7 IMS-ALG in P-CSCF for support of ICE

6.7.2.7.1 General

This subclause describes procedures of a P-CSCF to support ICE, as defined in RFC 8445 [289] and RFC 8839 [290].

NOTE 1: If no IMS-AGW is inserted on the media plane, a P-CSCF might transparently pass ICE related SDP attibutes, in order to support ICE between the UE and remote entities. The remaining procedures in this subclause apply to when the P-CSCF inserts an IMS-ALG on the media plane.

When the P-CSCF with attached IMS-AGW receives SDP candidate information from the offerer, it shall not forward the candidate information towards the answerer. When the P-CSCF receives SDP candidate information from the answerer, it shall not forward the candidate information towards the offerer. The remaining procedures in subclause 6.7.2.7.1 are optional.

NOTE 2: An P-CSCF that removes and/or does not provide ICE related SDP attributes (e.g. a=candidate) in the offer/answer exchange will cause the ICE procedures to be aborted and the address and port information in the m and c lines of the SDP offer will be used. If this address and port information contains the relayed candidate address of a STUN Relay server, as recommended by ICE, then an extra media relay server will be used for the session which is not necessary nor desirable.

The P-CSCF with attached IMS-ALG performs separate ICE procedures towards the offerer and the answerer. The usage of ICE is negotiated separately with the offerer and answerer, and ICE may be applied independently at either side. Furthermore, the P-CSCF may be configured to apply ICE procedures only towards one network side, e.g. towards the IM CN subsystem it belongs to.

NOTE 3: Since the P-CSCF is inserting an IMS-ALG, it can choose to provide the NAT traversal mechanism defined in Annex F towards the UE. In such case the P-CSCF will not provide ICE support towards the UE, but the P-CSCF can still provide ICE support towards the core network in scenarios where ICE is used in the core network, e.g. to support NAT traversal for other access networks with no deploied IMS-ALGs.

Since the P-CSCF is not located behind a NAT, it does not request the IMS-ALG to generate keep-alive messages even when acting as a full ICE entity. The P-CSCF only requests the IMS-ALG to terminate and generate STUN messages used for the candidate selection procedures.

Since the P-CSCF is not located behind a NAT the P-CSCF shall only include host candidates in SDP offers and answers generated by the P-CSCF.

6.7.2.7.2 P-CSCF full ICE procedures for UDP based streams

6.7.2.7.2.1 General

This subclause describes the P-CSCF full ICE procedures for UDP based streams.

6.7.2.7.2.2 P-CSCF receiving SDP offer

When the P-CSCF receives an SDP offer including ICE candidate information, the P-CSCF shall send the candidate information for each UDP based stream received in the SDP offer towards the IMS-ALG. If the SDP offer includes TCP candidate information for a UDP based stream, the P-CSCF may send such candidate information to the IMS-AGW, in addition to the UDP candidate information as defined in RFC 6544 [131]. The P-CSCF shall request the IMS-ALG to reserve media- and STUN resources towards the offerer, based on the candidate information, in order to allow the IMS-ALG to perform the necessary connectivity checks per the ICE procedures.

If the offerer is acting as an ICE controller entity the P-CSCF shall act as an ICE controlled entity in the direction towards the offerer. If the offerer is acting as an ICE controlled entity the P-CSCF shall act as an ICE controller entity in the direction towards the offerer.

6.7.2.7.2.3 P-CSCF sending SDP offer

Prior to sending an SDP offer, the P-CSCF may choose to apply related ICE procedues, e.g. if it expects to interact with terminals applying procedures as described in subclause K.5.2, and if both the P-CSCF and IMS-ALG also support ICE procedures. To invoking these ICE procedures, the P-CSCF shall request the IMS-ALG to reserve media- and STUN resources towards the answerer for each UDP based media stream and include a host candidate attribute for each UDP based stream in the SDP offer, providing the reserved address and port at the IMS-ALG as destination. The P-CSCF may also include host TCP candidate information for UDP based streams in the SDP offer as defined in RFC 6544 [131].

The P-CSCF shall always act as an ICE controller entity towards the answerer.

NOTE: The host candidate address included by the P-CSCF in the generated SDP offer matches the c- and m line information for the associcated UDP stream in the SDP offer.

6.7.2.7.2.4 P-CSCF receiving SDP answer

When the P-CSCF receives an SDP answer including ICE candidate information, the P-CSCF shall send the candidate information for each UDP based stream received in the SDP answer towards the IMS-ALG.

The P-CSCF shall request the IMS-ALG to perform ICE candidate selection procedures towards the answerer. The P-CSCF shall request the IMS-ALG to inform the P-CSCF, for each UDP stream, which candidate pair has been selected towards the answerer, once the candidate selection procedure towards the answerer has finished.

If the IMS-ALG indicates to the P-CSCF that, for at least one UDP stream, the selected candidate pair does not match the c- and m- line address information for the associated UDP stream, exchanged between the P-CSCF and the answerer, and the P-CSCF acts an ICE controller entity towards the answerer, the P-CSCF shall send a new offer towards the answerer in order to allign the c- and m- lines address information with the chosen candidate pair for the associated UDP stream.

6.7.2.7.2.5 P-CSCF sending SDP answer

When the P-CSCF generates an SDP answer for an offer that included ICE candidate information, the P-CSCF shall request the IMS-ALG to reserve media- and STUN resources towards the offerer for each UDP based media stream and include an SDP host candidate attribute for each UDP based stream in the SDP answer, providing the reserved address and port at the IMS-ALG as destination.

The P-CSCF shall in the generated SDP answer include host candidate information which matches the c- and m line information for the associated UDP stream in the SDP answer.

The P-CSCF shall request the IMS-ALG to perform ICE candidate selection procedures towards the offerer. The P-CSCF shall request the IMS-ALG to inform the P-CSCF, for each UDP stream, which candidate pair has been selected towards the offerer, once the candidate selection procedure towards the answerer has finished.

If the IMS-ALG indicates to the P-CSCF that the selected candidate pair towards the offerer does not match the c- and m- line address information for the associated UDP stream, exchanged between the P-CSCF and the offerer, and the P-CSCF acts an ICE controller entity towards the offerer, the P-CSCF shall send an offer towards the offerer (which will now act as an answerer) in order to allign the c- and m- line address information with the chosen candidate pair for the associated UDP stream.

6.7.2.7.3 P-CSCF ICE lite procedures for UDP based streams

When the P-CSCF is using ICE lite procedures for UDP based streams, the P-CSCF procedures are identical as described in subclause 6.7.2.7.2, with the following exceptions:

– The P-CSCF always acts as an ICE controlled entity towards the offerer and towards the answerer; and

– The P-CSCF requests the IMS-ALG to perform ICE lite candidate selection procedures, as defined in RFC 8445 [289].

6.7.2.7.4 ICE procedures for TCP based streams

6.7.2.7.4.1 General

The P-CSCF shall disable ICE procedures for TCP based streams, i.e. streams where TCP is indicated as transport protocol in the m-line. Instead the P-CSCF will use the mechanism defined in RFC 4145 [83] for establishing TCP based streams, as defined in RFC 6544 [131].

NOTE 1: Handling of TCP candidates for UDP based streams is described in subclause 6.7.2.7.2.

NOTE 2: An entity that supports ICE continues the ICE procedures for UDP based streams, even if no candidates are provided for TCP based streams.

6.7.2.7.4.2 P-CSCF receiving SDP offer

When the P-CSCF receives an SDP offer, the P-CSCF shall ignore the candidate attributes for TCP based streams. The P-CSCF shall not send the candidate information for TCP based streams towards the IMS-ALG.

6.7.2.7.4.3 P-CSCF sending SDP offer

When the P-CSCF generates an SDP offer the P-CSCF shall include an "actpass" setup attribute, as defined in RFC 4145 [83], for each TCP based stream, which will cause the answerer to initiate the TCP connections towards the IMS-ALG. The P-CSCF shall not include any candidate attributes for TCP based streams in the SDP offer.

6.7.2.7.4.4 P-CSCF receiving SDP answer

Since the P-CSCF does not include candidates in the SDP offer towards the answerer, there are no ICE specific procedures when the P-CSCF receives an SDP answer.

NOTE: If the SDP answer contains candidate attributes for TCP based streams, the P-CSCF simply discards the candidate attributes.

6.7.2.7.4.5 P-CSCF sending SDP answer

When the P-CSCF generates an SDP answer the P-CSCF shall include a "passive" setup attribute, as defined in RFC 4145 [83], for each TCP based stream, which will cause the offerer to initiate the TCP connections towards the IMS-ALG. The P-CSCF shall not include any candidate attributes for TCP based streams in the SDP answer.

6.7.2.8 IMS-ALG in P-CSCF for transcoding

An IMS-ALG may support procedures to modify SDP for transcoding purposes. The IMS-ALG shall only apply those transcoding procedures if an attached IMS-AGW supports transcoding.

Upon receipt of an SDP offer, based on local policy and SDP signalling inspection, the IMS-ALG may decide to offer transcoding.

To offer transcoding at the IMS-AGW, the IMS-ALG shall add codecs selected by local policy and supported by the IMS-AGW to the SDP offer. The local policy shall be in accordance with the requirements of clause T.2.

Upon receipt of the corresponding SDP answer, the IMS-ALG shall inspect the list of the codecs within the SDP answer and proceed as follows:

– If the list contains at least one of the codecs that was already contained in the previously received SDP offer, no transcoding at the IMS-AGW is required and the IMS-ALG will configure the IMS-AGW accordingly. The IMS-ALG shall remove from the SDP the codecs added to the original offer before forwarding the response to the offerer.

– If only the codecs inserted by the IMS-ALG are contained in the answer, the IMS-ALG will configure the IMS-AGW to transcode. The IMS-ALG shall replace the received codecs in the SDP anwer with the codec it configured the IMS-AGW to use towards the SDP offerer´s direction.

For an IMS-ALG acting as ATCF, the following applies in addition:

– During an originating or terminating session establishment, for media using PS transport towards the UE, the IMS-ALG (ATCF) should pass SDP offers without adding codecs to the SDP offer and pass SDP answers without modification to the contained codecs to avoid the potential need for transcoding in the IMS-AGW before the PS to CS access transfer; and

– during the PS to CS access transfer procedure, the IMS-ALG (ATCF) shall preferentially select from the SDP offer it receives from the MSC server the codec already configured on the corresponding remote leg, if available.

6.7.3 IMS-ALG in ISC gateway function

6.7.3.1 General

When the ISC gateway function acts as an IMS-ALG, it makes procedures as for an originating UA and terminating UA. The IMS-ALG acts as a B2BUA. For the use of the IMS-ALG for specific capabilities, additional procedures are defined in subsequent subclauses.

NOTE: The internal function of the IBCF as an IMS-ALG is defined in 3GPP TS 29.162 [11A], and the capabilities are identical for the ISC gateway function.

6.7.3.2 IMS-ALG in application gateway function for support of ICE

The application gateway function shall act according to the procedures defined for the IBCF in subclause 6.7.1.2.