Content for  TS 24.229  Word version:  19.0.0

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 TS 29.162. 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.

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

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

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 TS 23.228. An IMS-ALG that supports switching to transparent media for WebRTC shall apply the procedures in the present subclause. 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.

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.

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
• no change has been made to the IP address(es) and port number(s).

When the P-CSCF acts as an IMS-ALG, it acts as a B2BUA and modifies the SDP as described as described in TS 23.334. 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;
   • with an SDP crypto attribute as defined in RFC 4568; and
   • with the SDP "a=3ge2ae:requested" attribute;
   the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 as far as SDP and SRTP is concerned, and shall:
   • if the SDP offer contains a Transport Protocol Capability SDP attribute (see RFC 5939) offering:
     1. "RTP/SAVPF" transport, e.g. "a=tcap:x RTP/SAVPF", replace this transport with "RTP/AVPF" within that attribute; and
     2. "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 TS 23.334 as far as SDP and SRTP is concerned and shall:
   • indicate the SRTP transport protocol according to RFC 3711 and the profile defined in TS 33.328; and
   • include a SDP crypto attribute according to RFC 4568 and the profile defined in TS 33.328.

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 TS 23.334 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);
   • 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), (e.g. "a=tcap:x RTP/AVPF a=pcfg:y t=x"), remove those potential configuration(s);
   • if the SDP offer contains a Transport Protocol Capability SDP attribute (see RFC 5939) offering:
     1. "RTP/AVPF" transport (e.g. "a=tcap:x RTP/AVPF"), replace this transport with "RTP/SAVPF" within that attribute; and
     2. "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), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);
   • offer SRTP transport protocol according to RFC 3711 and the profile defined in TS 33.328;
   • include a SDP crypto attribute according to RFC 4568 and the profile defined in TS 33.328; 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 TS 23.334 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 and RFC 5764;
   • with the SDP fingerprint attribute as defined in RFC 8122;
   • with the SDP "a=3ge2ae:requested" attribute; and
   • with the SDP tls-id attribute as defined in RFC 8842;
   the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 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 TS 23.334 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, RFC 5764 and the profile defined in TS 33.328;
   • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328; and
   • include the SDP tls-id attribute as defined in RFC 8842.

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 TS 23.334 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, RFC 5764 and the profile defined in TS 33.328;
   • if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);
   • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328;
   • include the SDP "a=3ge2ae:applied" attribute; and
   • include the SDP tls-id attribute as defined in RFC 8842; 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 TS 23.334 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 and RFC 6714;
   • with the SDP fingerprint attribute as defined in RFC 8122; and
   • with the SDP "a=3ge2ae:requested" attribute;
   the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 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 TS 23.334 as far as SDP and MSRP is concerned and shall:
   • indicate the MSRP over TLS transport protocol according to RFC 4975, RFC 6714 and the profile defined in TS 33.328; and
   • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328.

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 TS 23.334 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, RFC 6714 and the profile defined in TS 33.328;
   • if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);
   • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328; 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 TS 23.334 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;
   • with the SDP fingerprint attribute as defined in RFC 8122; and
   • with the SDP "a=3ge2ae:requested" attribute;
   the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 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 TS 23.334 as far as SDP and BFCP is concerned and shall:
   • transported using the BFCP over TLS transport protocol as defined in RFC 4583;
   • indicate the BFCP over TLS transport protocol according to RFC 4583 and the profile defined in TS 33.328; and
   • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328.

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 TS 23.334 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 and the profile defined in TS 33.328;
   • if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);
   • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328; 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 TS 23.334 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 and RFC 8842;
   • with the SDP fingerprint attribute as defined in RFC 8122;
   • with the SDP "a=3ge2ae:requested" attribute; and
   • with the SDP tls-id attribute as defined in RFC 8842;
   the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 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 TS 23.334 as far as SDP and UDPTL is concerned and shall:
   • indicate the UDPTL over DTLS transport protocol according to RFC 7345, RFC 8842 and the profile defined in TS 33.328;
   • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328; and
   • include the SDP tls-id attribute as defined in draft-ietf-mmusic-dtls-sdp [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 TS 23.334 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, RFC 8842 and the profile defined in TS 33.328;
   • if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);
   • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328;
   • include the SDP "a=3ge2ae:applied" attribute; and
   • include the SDP tls-id attribute as defined in RFC 8842; 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 TS 23.334 as far as SDP and UDPTL is concerned, and shall remove the SDP fingerprint attribute and SDP tls-id attribute.

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 TS 29.079.

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.

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.

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