5 Functional Requirements

23.3343GPPIP Multimedia Subsystem (IMS) Application Level Gateway (IMS-ALG) - IMS Access Gateway (IMS-AGW) interface: Procedures descriptionsRelease 17TS

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

5.1 General

A single IMS-ALG may control one or multiple IMS-AGW(s).

5.2 Gate Control & Local NAT

The IMS-ALG shall provide the NAPT control function, i.e. obtain the address binding information (according to IETF RFC 2663 [4]) and perform the NAPT policy control along with gate control (i.e. instruct the opening/closing of a gate).

The IMS-ALG shall request the IMS-AGW to allocate transport addresses/resources to enable media to traverse the IMS-AGW. The IMS-ALG may indicate the corresponding IP realm to the IMS-AGW – see clause 5.3. The IMS-AGW shall provide the corresponding external transport addresses to the IMS-ALG.

Terminations for the Iq interface may be pre-defined with different levels of granularity for specific IP ports, interfaces, or groups of interfaces. These may then be defined as an IP realm (see clause 5.3) known by both the IMS-ALG and the IMS-AGW, however IP Realms may also be defined for multiple physical interfaces. In order to efficiently report a failure affecting a large number of terminations associated to specific physical interfaces, the IMS-AGW shall, when allocating a new termination, return to the IMS-ALG an associated Interface ID.

An IMS-AGW not supporting this procedure may allocate the same Interface ID for all IP terminations.

An IMS-AGW supporting the Termination Out-of-Service procedure (see clause 6.1.15) shall maintain a local mapping of Interface ID to its internal resources.

The IMS-AGW shall provide the NAPT enforcement function, i.e. change the address and port number of the media packets as they traverse the IMS-AGW, along with gate control (i.e. open/close a gate under the control of the IMS-ALG).

The IMS-AGW may provide IP version interworking. If the IP version interworking is performed and the IMS-ALG passes an SDP offer or answer, the IMS-ALG may adjust any SDP bandwidth information contained in the SDP offer or answer in accordance with 3GPP TS 29.162 [20] clause 9.1.5.

The IMS-ALG shall request the IMS-AGW to release its transport resources at the end of a session.

5.3 IP realm indication and availability

The IMS-ALG and the IMS-AGW shall support IP realm indication.

The IMS-ALG, when requesting the allocation of transport resources at the IMS-AGW, may indicate the correspondent IP realm to the IMS-AGW. The IMS-AGW shall assign the IP termination in the IP realm indicated. The same IP realm shall be applied to all media streams associated with the termination. The IP realm identifier cannot be changed after the initial assignment.

A default IP realm may be configured such that if the IMS-AGW has not received the IP realm identifier and the IMS-AGW supports multiple IP realms then the default IP realm shall be used.

In order to prevent the IMS-ALG requesting an unavailable IP Realm, the IMS-ALG may audit the list of currently available realms on the IMS-AGW and may request the IMS-AGW to report any changes to that list as they occur over time.

The monitoring of IP realm availability is optional and if supported by IMS-AGW may be requested by the IMS-ALG.

5.4 Remote NAT traversal support

The IMS-ALG and the IMS-AGW shall support remote NA(P)T traversal support using procedures according to the present clause. In addition they may support remote NA(P)T traversal support using Interactive Connectivity Establishment (ICE) according to clause 5.17.

The IMS-ALG is responsible for determining whether there is a remote NAT device (the mechanism by which this achieved is out of scope of the current document).

If a remote NAT device is present, the IMS-ALG shall request the IMS-AGW to perform latching or re-latching when requesting the IMS-AGW to reserve transport addresses/resources.

If remote NAT is applicable, the IMS-AGW shall not use the remote media address/port information (supplied by the IMS-ALG) as the destination address for outgoing media. Instead, the IMS-AGW shall dynamically learn the required destination address via the source address/port of incoming media. This mechanism is known as "latching".

When remote NAT Traversal is applied to a stream associated with multiple flows (e.g. RTP and RTCP), the IMS-AGW shall perform individual latching and/or re-latching on the various flows. This means that an RTP and an RTCP flow of a single stream can be latched to different remote addresses and/or ports.

5.5 Remote Source Address/Port Filtering

The IMS-ALG may support and the IMS-AGW shall support policing of the remote source address/port of incoming media flow(s).

The IMS-ALG may determine that the source address/port of received media packets should be policed.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources, the IMS-ALG may indicate to the IMS-AGW that policing of source address and/or port of received media packets is required.

If such policing is applicable, the IMS-AGW shall check the source address and/or port of all received media packets and silently discard any packets that do not conform to the expected source address and/or port.

5.6 Traffic Policing

The IMS-ALG may support traffic policing of incoming media flows.

The IMS-AGW shall support traffic policing of the maximum average bitrate, defined as sustainable data rate (see IETF RFC 2216 [10]) of incoming media flows and may support traffic policing of the peak data rate of incoming media flows.

The IMS-ALG may require the IMS-AGW to police the media flows to ensure that they conform to the expected data rates.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources, the IMS-ALG may indicate to the IMS-AGW that policing of the related media streams is required and provide traffic policing related parameters as detailed in clause 6.2.5.

If such policing is requested, the IMS-AGW shall police the corresponding media streams as detailed in clause 6.2.5 by measuring the data rate for the received packets within that media stream. If the permissible data rate provided by the IMS-ALG is exceeded, the IMS-AGW shall discard packets to reduce their data rate to the permissible data rate.

For RTP flows where RTCP resources are reserved together with the RTP resources (see clause 5.9), the permissible data rate shall include the bandwidth used by RTP and RTCP together.

5.7 Hanging Termination Detection

The IMS-ALG and the IMS-AGW shall support detection of hanging termination.

The IMS-ALG, when requesting the IMS-AGW to reserve an AGW connection point, shall indicate to the IMS-AGW to perform detection of hanging terminations.

The IMS-AGW shall determine a termination to be hanging if there is no signalling sent/received within a specified period.

On being informed of the hanging termination, the IMS-ALG shall check/determine whether the cited termination is valid and initiate any appropriate corrective action, e.g. release an invalid termination.

5.8 QoS Packet Marking

The IMS-ALG may support and the IMS-AGW shall support control via the Iq interface of the setting of the DiffServ Code Point (DSCP) for media packets sent on a termination.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources, the IMS-ALG may indicate to the IMS-AGW that the DSCP of outgoing media packets shall be explicitly set or copied from the DSCP of the corresponding received packet.

If such modification of the DSCP is required by the IMS-ALG, the IMS-AGW shall set the DSCP for outgoing packets on a termination.

5.9 Handling of RTCP streams

5.9.1 General

The IMS-ALG and the IMS-AGW shall support control via the Iq interface of the specific RTCP behaviour associated to an RTP flow.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources for an RTP flow, the IMS-ALG should also request the IMS-AGW to reserve resources for the corresponding RTCP flow, but may alternatively request the IMS-AGW not to reserve resources for the corresponding RTCP flow. When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources for a non-RTP flow, the IMS-ALG shall not request the IMS-AGW to reserve resources for an RTCP flow.

To request the IMS-AGW to reserve resources for an RTCP flow, the IMS ALG shall provide the RTCP handling information element with a value indicating that resources for RTCP shall be reserved.

To request the IMS-AGW not to reserve resources for an RTCP flow, the IMS ALG shall either provide the RTCP handling information element with a value indicating that resources for RTCP shall not be reserved or omit the RTCP handling information element.

If the IMS-AGW receives the indication to reserve RTCP resources, the IMS-AGW shall allocate a local port with even number for an RTP flow and shall allocate the consecutive local port with odd number for the associated RTCP flow, and it shall send and be prepared to receive RTCP packets.

If the IMS-AGW receives the indication to not reserve RTCP resources, or if it does not receive any indication at all, it shall not allocate an RTCP port when allocating a port for an RTP flow. The IMS-AGW shall not send any RTCP packets and shall silently discard any received RTCP packets.

When RTCP resources are requested, the IMS-ALG may also specify:

– the explicit RTCP transport address information element containing the remote RTCP port, and optionally the remote address, where to send RTCP packets; if not specified, the IMS-AGW shall send RCTP packets to the port contiguous to the remote RTP port; and

– bandwidth allocation requirements for RTCP, if the RTCP bandwidth level for the session is different than the default RTCP bandwidth as specified in RFC 3556 [6].

The explicit RTCP transport address information element contains the "a=rtcp" SDP attribute (as specified in IETF RFC 3605 [7]) received within the SDP body. The explicit RTCP transport address information element is only allowed for remote endpoints and shall not be used for the local endpoint. When the IMS-ALG requests the IMS-AGW to reserve resources for an RTCP flow and provides in addition the explicit RTCP port information element, then the IMS-AGW shall use this network address and transport port as destination when sending RTCP packets towards the remote endpoint.

The IMS-AGW shall return an error if it can not allocate the requested RTCP resources.

5.9.2 RTP/RTCP transport multiplexing

The procedure in clause 5.9.1 describing the default case of RTP/RTCP transport non-multiplexed scenarios may be extended for the transport multiplexed mode by addition of the RTP/RTCP transport multiplexing information element to indicate to the IMS-AGW that RTP and RTCP traffic shall be multiplexed on a single port (as described in IETF RFC 5761 [60]). The RTP/RTCP transport multiplexing information element may only be sent to the IMS-AGW in combination with the RTCP handling information element with the value indicating that resources for RTCP shall be reserved. The support of these procedures is optional for the IMS ALG and the IMS-AGW. The IMS-ALG shall only use these procedures when knowing support at IMS-AGW side (e.g., via configuration management).

The usage is conditional, given by following restrictions:

1) The transport multiplexed mode may be only supported for terminations at the access network side of the IMS-AGW.

2) The transport multiplexed mode shall be only enabled for the local connection endpoint if agreed via SIP SDP offer/answer negotiation with the served UE using:

– the "a=rtcp-mux" SDP attribute, see IETF RFC 5761 [60], as updated by IETF RFC 8035 [72]; and/or

– the "a=rtcp-mux-only" SDP attribute, see IETF RFC 8858 [71].

NOTE 1: Usage of an "rtcp-mux-only" attribute in an SDP answer is forbidden, see IETF RFC 8858 [71]. If the associated SDP answer does not contain an SDP "rtcp-mux" attribute, the offerer (the IMS ALG or the UE) needs to disable the associated RTP based media by sending a new SDP offer:
– with a zero port value associated with the SDP media description ("m=" line); or
– without associating an SDP "rtcp-mux-only" attribute with the SDP media description ("m=" line).

3) When transport multiplexed mode is agreed with the served UE, then it may be applied in both traffic directions.

NOTE 2: The last two conditions enforce a symmetrical usage of RTP/RTCP transport multiplexing in the related network domain (here the access network).

5.10 Media Inactivity Detection

The IMS-ALG and the IMS-AGW may support the detection of inactive media flows.

The IMS-ALG may require an IMS-AGW that supports media inactivity detection to detect if a media flow is inactive.

NOTE: The decision to apply or not media inactivity is general for all sessions with the same media characteristics (i.e. not user specific). It is for further study under which conditions inactivity media detection may be requested.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources, the IMS-ALG may indicate to the IMS-AGW that detection of an inactive media flow is required and may additional specify inactivity detection time and inactivity detection direction.

The IMS-AGW shall determine a media flow on termination to be inactive if there is no media sent and/or received within the inactivity detection time period.

On being informed of the inactive media, the IMS-ALG shall initiate any appropriate corrective action.

5.11 IMS Media Plane Security

5.11.1 General

The IMS-ALG and the IMS-AGW may support IMS media plane security as specified in 3GPP TS 33.328 [12]. They may support end-to-access edge security, or end-to-end security, or both, for

– RTP based media (such as e.g. audio, video information) using SRTP security, and/or

– TCP based media (such as MSRP and BFCP) using TLS security; and/or

– UDP based media (such as T.38 fax over UDPTL/UDP) using DTLS security.

If supported the IMS-ALG and the IMS-AGW shall use the procedures in the following clauses.

NOTE: For the support of end-to-end security, the presence of an IMS-ALG is not required.

Procedures for the IMS-ALG to determine if end-to-access edge security or end-to-end security is applicable to a session are specified in 3GPP TS 33.328 [12] and 3GPP TS 24.229[11].

5.11.2 End-to-access-edge Security

5.11.2.1 End-to-access-edge security for RTP based media using SDES

Procedures for the IMS-ALG to determine if end-to-access edge security is applicable to RTP based media and to exchange cryptography related SDP parameters with the served UE during the SIP session setup are specified in 3GPP TS 33.328 [12] and 3GPP TS 24.229[11].

For media lines that can be subject to e2ae security, the IMS-ALG will receive "RTP/AVP" or "RTP/AVPF" as transport protocol in SDP from the core network. When the IMS-ALG determines that e2ae security is applicable, it will indicate "RTP/SAVP" (see IETF RFC 3711 [14]) or "RTP/SAVPF" (see IETF RFC 5124 [15]), respectively, as transport protocol in the corresponding SDP media lines send towards the served UE. When e2ae security is applied, the IMS-ALG will also receive "RTP/SAVP" or "RTP/SAVPF" in SDP from the served UE. The IMS-ALG will then indicate "RTP/AVP" or "RTP/AVPF" respectively, as transport protocol in the corresponding SDP media lines send towards the core network. When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources for media to which e2ae security is applicable, the IMS ALG shall configure "RTP/SAVP" or "RTP/SAVPF" as transport protocol at the access side termination. The IMS ALG shall configure "RTP/AVP" or "RTP/AVPF" as transport protocol at the core network side termination for media where e2ae security is applicable.

When the IMS-ALG determines that e2ae security is applicable, it will generate appropriate cryptographic context parameters, in particular key(s), and will transfer them to the served UE within SDES SDP "crypto" attribute(s) according to IETF RFC 4568 [13]. The IMS-ALG will also receive cryptographic context parameters, in particular key(s), from the served UE within SDES SDP "crypto" attribute(s). When the IMS-ALG requests the IMS-AGW to reserve or configure transport addresses/resources for media to which e2ae security is applicable, the IMS-ALG shall provide cryptography related parameters as SDES SDP "crypto" attributes applicable at the access side termination.

On the originating side of the SIP session setup, the IMS-ALG shall provide as "Remote cryptographic SDES attribute" the SDES crypto attribute it selected from the ones received from the IMS UE in the SDP Offer . The IMS-ALG shall provide as "Local cryptographic SDES attribute" the SDES crypto attribute the IMS-ALG generated and inserted in the SDP Answer sent to IMS UE.

On the terminating side of the SIP session setup, the IMS-ALG shall provide as "Remote cryptographic SDES attribute" the SDES crypto attribute received from the IMS UE in the SDP Answer. The IMS-ALG shall provide as "Local cryptographic SDES attribute" the SDES crypto attribute selected by the UE from the ones the IMS-ALG generated and inserted in the SDP Offer sent to UE. If the IMS-ALG offers only one SDES crypto attribute to the UE, the IMS-ALG may provide this attribute as "Local cryptographic SDES attribute" within the Reserve AGW Connection Point Procedure before receiving the SDP answer from the UE.In the present release, a modification of an established e2ae crypto session is not supported. Thus, the IMS-ALG shall not modify any previously provided "Local cryptographic SDES attribute" or "Remote cryptographic SDES attribute".

If the IMS-ALG applies e2ae media security for a media stream and receives an SDP bandwidth modifier related to that media stream in SIP/SDP signalling, it should modify this bandwith modifier to adjust the bandwidth overhead due to e2ae security before forwarding the SDP. The IMS-ALG should add the bandwidth overhead caused by e2ae media security to the bandwidth information received from the remote peer. The IMS-ALG should substract the bandwidth overhead caused by e2ae media security from the bandwidth information received from the served UE.

The IMS Access GW shall, upon reception of an SDES crypto attribute, establish an SRTP security context (as described in RFC 4568 [13] and RFC 3711 [14]) and be prepared to convert RTP packets to SRTP packets and vice versa, using the corresponding SRTP security contexts.

5.11.2.2 End-to-access-edge security for TCP based media using TLS

5.11.2.2.1 General

E2ae security for TCP based media using TLS is applicable for MSRP (see IETF RFC 4975 [25]; used in IMS session-based messaging) and BFCP (see IETF RFC 4582 [31]; used in IMS conferencing). The IMS-ALG and IMS-AGW may support e2ae security for MSRP, BFCP, or both protocols.

E2ae protection of MSRP and BFCP media is based on TLS, according to the TLS profile specified in Annex E of 3GPP TS 33.310 [48] and Annex M of 3GPP TS 33.328 [12]. TLS shall be supported over the TCP transport (see IETF RFC 793 [29]).

Key management for e2ae protection of MSRP and BFCP is based on the ciphersuites and session keys negotiated via the TLS handshake protocol between the UE and the IMS-AGW (see 3GPP TS 33.328 [12]).

Procedures for the IMS-ALG to determine if e2ae security for MSRP and/or BFCP is applicable to a session and to exchange the cryptographic information (i.e. certificate fingerprints, see IETF RFC 8122 [80]) over SDP with the served UE during the SIP session setup are specified in 3GPP TS 33.328 [12] and 3GPP TS 24.229 [11]. If e2ae security is not required, the e2e security procedures may apply, see clause 5.11.3.

According to the TLS profile specified in Annex E of 3GPP TS 33.310 [48], the IMS-AGW shall accept TLS renegotiation only if it is secured according to IETF RFC 5746 [47].

NOTE 1: IETF RFC 5746 [47] defines a "TLS secure renegotiation" procedure, which leaves the definition of a basic TLS renegotiation still open. H.248 based support to enable the IMS-ALG to allow or not allow the IMS-AGW to perform client initiated or server initiated TLS renegotiation is not addressed in the present release. The behaviour of the IMS-AGW for "TLS session renegotiation" procedure is hence not further defined in the present release.

For each MSRP or BFCP media stream to be set-up with e2ae security, the P-CSCF (IMS-ALG) shall:

– include the IMS-AGW in the media path and allocate the required resources for the media stream in the IMS-AGW;

– request a certificate fingerprint from the IMS-AGW;

– include the certificate fingerprint received from the IMS-AGW in the SDP it sends to the IMS UE;

– send the certificate fingerprint(s) received in the SDP from the IMS UE to the IMS-AGW;

– instruct the IMS-AGW to perform state-aware TCP handling by including information about the TCP setup direction;

– for each termination determine via SDP negotiation as specified in IETF RFC 4145 [30] if the IMS-AGW needs to act as TCP client or server for the terminations towards the core network and towards the access network;

– indicate to the IMS-AGW how to perform the TCP connection establishment by:

a) either instructing the IMS‑AGW to start a TCP connection establishment on any terminations where it needs to act as TCP client; or

b) indicating to the IMS‑AGW to use an incoming TCP connection establishment request at one termination as a trigger to send a TCP connection establishment request at the interconnected termination in the same context (support of this alternative is optional for the IMS-AGW and IMS‑ALG);

– determine via SDP negotiation if the IMS-AGW needs to act as TLS client or server as specified in the clauses below;

NOTE 2: The determination of the TLS client/server role relies on different rules for MSRP and BFCP.

– if the IMS-AGW needs to act as TLS client, request the IMS-AGW to start the TLS session setup once the TCP connection is established towards the UE; and

– apply additional specific procedures for MSRP in clause 5.11.2.2.2 or for BFCP in clause 5.11.2.2.3.

For each MSRP or BFCP media stream to be set-up with e2ae security the IMS-AGW shall:

– upon request from the IMS-ALG, select an own certificate for the media stream, uniquely associate own certificate with the media stream, and send the fingerprint of the own certificate to the IMS-ALG;

– uniquely associate the certificate fingerprint(s) received from the IMS-ALG with the corresponding MSRP or BFCP media stream, and subsequently use the certificate fingerprint(s) (as described in IETF RFC 4975 [25]) to verify the establishment of the TLS session of the corresponding media stream to belong to the served user;

– if the verification of the remote certificate fingerprint(s) during the TLS session establishment fails, regard the remote TLS endpoint as not authenticated, terminate the TLS session and report the unsuccessful TLS session setup to the IMS-ALG;

– negotiate the TLS protocol configurations with the TLS peer based on locally provisioned TLS profile parameters;

– when the TLS session has been established, convert unprotected media received from the network to protected media to send to the served UE and vice versa;

– be capable to support both the TLS server and TLS client roles;

– when being instructed to start the TLS session setup, act as a TLS client and establish the TLS session as soon as the underlying TCP bearer connection is established;

– upon instruction of the IMS-ALG to perform state-aware TCP handling, not forward any TCP connection establishment request received on one termination towards the interconnected termination;

– upon corresponding instructions from the IMS‑ALG, start a TCP connection establishment on the indicated termination by sending a TCP SYN, or use an incoming TCP connection establishment request received at one termination as a trigger to send a TCP connection establishment request at the interconnected termination in the same context;

– release the underlying TCP bearer connection as soon as the TLS session is released; and

– apply additional specific procedures for MSRP in clause 5.11.2.2.2 or for BFCP in clause 5.11.2.2.3.

5.11.2.2.2 e2ae security for session based messaging (MSRP)

For each MSRP media stream outside WebRTC data channels requiring e2ae security, the IMS-ALG shall indicate to the IMS-AGW as transport protocol:

a) for application-agnostic e2ae security support:

– "TCP" at the termination towards the core network; and

– "TCP/TLS" at the termination towards the access network; or

b) for application-aware e2ae security support:

– "TCP/MSRP" at the termination towards the core network; and

– "TCP/TLS/MSRP" at the termination towards the access network.

The IMS-ALG shall determine via SDP negotiation if the IMS‑AGW needs to act as TLS client or TLS server using the IETF RFC 4145 [30] "a=setup" SDP attribute as follows:

– if the IMS‑ALG send an "a=setup:active" SDP attribute in an SDP answer towards the UE, the IMS‑AGW shall act as TLS client;

– if the IMS‑ALG send an "a=setup:passive" SDP attribute in an SDP answer towards the UE, the IMS‑AGW shall act as TLS server;

– if the IMS‑ALG receives an "a=setup:active" SDP attribute in an SDP answer from the UE, the IMS‑AGW shall act as TLS server; and

– if the IMS‑ALG receives an "a=setup:passive" SDP attribute in an SDP answer from the UE, the IMS‑AGW shall act as TLS client.

5.11.2.2.3 e2ae security for conferencing (BFCP)

For each BFCP media stream requiring e2ae security, the IMS-ALG shall indicate to the IMS-AGW as transport protocol:

– "TCP" at the termination towards the core network; and

– "TCP/TLS" at the termination towards the access network.

The IMS-ALG shall determine via SDP negotiation (see IETF RFC 4583 [27]) if the IMS‑AGW needs to act as TLS client or TLS server as follows:

– if the IMS‑ALG receives an initial SDP offer from the UE, the IMS‑AGW shall act as TLS server; and

– if the IMS‑ALG sends an initial SDP offer towards the UE, the IMS‑AGW shall act as TLS client.

5.11.2.3 End-to-access-edge security for UDP based media using DTLS

5.11.2.3.1 General

The IMS-ALG and the IMS-AGW may support end-to-access-edge (e2ae) security for an UDP based media. The e2ae protection of the UDP based media relies on the usage of DTLS, according to the DTLS profiles specified in Annex E of 3GPP TS 33.310 [48] and exchange of self-signed certificates as defined in 3GPP TS 33.328 [12].

Key management solution for the e2ae media security of UDP is based on the cipher suites and session keys negotiated via the DTLS handshake protocol between the served UE and the IMS-AGW as specified in 3GPP TS 33.328 [12]. Procedures for the IMS-ALG to determine if e2ae security is applicable to UDP based media and to exchange the cryptographic information (i.e. certificate fingerprints, see IETF RFC 8122 [80]) via SDP negotiation with the served UE during the SIP session establishment are specified in 3GPP TS 33.328 [12] and 3GPP TS 24.229 [11].

Clause 5.11.2.3.2 defines specific requirements for e2ae protection of T.38 fax media stream over UDPTL/UDP transport. The usage of UDPTL over DTLS is defined in IETF RFC 7345 [33] and IETF RFC 8842 [81].

5.11.2.3.2 e2ae security for T.38 fax over UDP/UDPTL transport

If the IMS-ALG and the IMS-AGW support e2ae security for the UDP based media using DTLS and certificate fingerprints, then for each T.38 fax media stream over UDPTL/UDP transport to be setup with e2ae security, the IMS-ALG shall:

– include the IMS-AGW in the media path and allocate the required resources for the media stream in the IMS-AGW;

– determine via SDP negotiation with the served UE if the IMS-AGW needs to act as DTLS client or DTLS server as specified in IETF RFC 7345 [33] and IETF RFC 8842 [81];

– when requesting resources towards the access network:

a) indicate to the IMS-AGW "UDP/DTLS" as transport protocol;

NOTE 1: For IANA registry of "UDP/DTLS" see IETF draft-schwarz-mmusic-sdp-for-gw [34].

b) send the certificate fingerprint(s) received from the served UE to the IMS-AGW; and

c) request from the IMS-AGW the certificate fingerprint;

– include the certificate fingerprint received from the IMS-AGW in the SDP body it sends to the served UE;

– if the IMS-ALG received from the served UE an SDP offer with "a=tls-id" media-level SDP attribute (as specified in IETF RFC 8842 [81]), create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP answer which the IMS-ALG sends to the served UE;

– if the IMS-ALG sends to the served UE an SDP offer, create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP offer;

NOTE 2: Already used certificate fingerprints can be assigned to a new DTLS association. If the IMS-AGW uses the same set of fingerprints for a new DTLS association then the IMS-ALG creates a new local "tls-id" attribute value so that the combination of the "tls-id" attribute values of the IMS-ALG and the served UE is unique across all DTLS associations that might be handled by the IMS-ALG and the served UE, as specified in IETF RFC 8842 [81].

– request the IMS-AGW to start the DTLS session setup if the IMS-AGW needs to act as DTLS client; and

– when requesting resources towards the core network:

a) indicate to the IMS-AGW "UDP" as transport protocol.

For each T.38 fax media stream over UDPTL/UDP transport to be setup with e2ae security, the IMS-AGW shall:

– be capable to support both the DTLS server and DTLS client roles;

– upon request from the IMS-ALG, act as DTLS client and start DTLS session establishment;

– upon request from the IMS-ALG, select an own certificate for the T.38 fax media stream, uniquely associate its own certificate with the media stream, and send the fingerprint of the own certificate to the IMS-ALG;

– uniquely associate the certificate fingerprint(s) received from the IMS-ALG with the corresponding T.38 fax media stream; and

– verify during the subsequent DTLS handshake with the served UE (as described in IETF RFC 7345 [33] and IETF RFC 8842 [81]) that the fingerprint of the certificate passed by the served UE during DTLS handshake matches the certificate fingerprint received from the IMS-ALG:

a) if the verification fails, the IMS-AGW shall regard the remote DTLS endpoint as not authenticated, terminate the DTLS session and report the unsuccessful DTLS session setup to the IMS-ALG;

b) otherwise, the IMS-AGW shall continue with DTLS session setup and when the DTLS session is established, the IMS-AGW shall be prepared to receive and convert unprotected media from the core network to the protected media to be sent to the served UE and vice versa.

5.11.2.4 End-to-access-edge security for RTP based media using DTLS-SRTP

Support of end-to-access edge security for RTP based media using DTLS-SRTP is mandatory for WebRTC sessions and optional for other SIP sessions.

The P-CSCF (IMS-ALG) and IMS-AGW provide end-to-access edge security by using DTLS-SRTP, where DTLS is used to establish keys for SRTP according to IETF RFC 5763 [42], IETF RFC 8842 [81] and IETF RFC 5764 [43].

During the establishment of a WebRTC or SIP session, the IMS-ALG receives "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as the transport protocol in SDP from the served UE (IMS UE or WebRTC IMS Client (WIC)). The IMS-ALG then shall indicate "RTP/AVP" or "RTP/AVPF" over UDP, respectively, as the transport protocol in the corresponding SDP media lines send towards the core network. When an IMS-ALG receives "RTP/AVP" or "RTP/AVPF" in SDP from the core network, the IMS-ALG shall indicate "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as transport protocol in SDP send towards the served UE (IMS UE or WIC). When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources for e2ae media security, the IMS ALG shall configure "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as transport protocol at the access side termination, and "RTP/AVP" or "RTP/AVPF" over UDP as transport protocol at the core network side termination.

The IMS-ALG shall send the received UE (IMS UE or WIC) certificate fingerprint(s) to the IMS-AGW that is then able to correlate the fingerprint within the media stream uniquely. For each SRTP/SRTCP media stream to be established with e2ae media security, the IMS-AGW shall send the fingerprint of its certificate via Iq interface to the IMS-ALG.

If the IMS-ALG received from the UE (IMS UE or WIC) an SDP offer with "a=tls-id" media-level SDP attribute (as specified in IETF RFC 8842 [81]), create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP answer which the IMS-ALG sends to the UE (IMS UE or WIC).

If the IMS-ALG sends to the UE (IMS UE or WIC) an SDP offer, create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP offer.

NOTE: Already used certificate fingerprints can be assigned to a new DTLS association. If the IMS-AGW uses the same set of fingerprints for a new DTLS association then the IMS-ALG creates a new local "tls-id" attribute value so that the combination of the "tls-id" attribute values of the IMS-ALG and the UE (IMS UE or WIC) is unique across all DTLS associations that might be handled by the IMS-ALG and the UE (IMS UE or WIC), as specified in IETF RFC 8842 [81].

According to procedures defined in 3GPP TS 24.229[11] and 3GPP TS 24.371 [44], the IMS-AGW shall act as either a DTLS server or client in the DTLS session.

In DTLS-SRTP case, RTP and RTCP data are encrypted using SRTP and SRTCP as defined in IETF RFC 3711 [14].

When the DTLS session is established between the UE (IMS UE or WIC) and the IMS-AGW, the IMS-AGW shall be prepared to send and receive SRTP/SRTCP packets of the incoming network side from the UE (IMS UE or WIC), and convert SRTP/SRTCP packets to RTP/RTCP packets to the outgoing network side and vice versa, if the media stream toward the IMS core network is using RTP/RTCP.

5.11.2.5 End-to-access-edge security for RTP based voice and video media using DTLS-SRTP over TCP

The eP-CSCF (IMS-ALG) and eIMS-AGW for WebRTC may support end-to-access-edge security for RTP based voice and video media using DTLS-SRTP over TCP. If they do so, they shall apply the procedures in the present clause.

NOTE 1: RTP over TCP may be used to traverse NAT/Firewalls that perform UDP blocking.

TCP transport may be offered as an alternative to UDP transport using the ICE procedures in clause 5.18. The eP-CSCF (IMS-ALG) and eIMS-AGW for WebRTC shall then provide end-to-access edge security for voice and video by using DTLS-SRTP over TCP, where DTLS is used to establish keys for SRTP according to IETF RFC 5763 [42], IETF RFC 8842 [81] and IETF RFC 5764 [43]. Framing according to RFC 4571 [58] shall be used for RTP streams transferred over TCP.

The IMS-ALG shall send the received WIC certificate fingerprint(s) to the eIMS-AGW that is then able to correlate the fingerprint within the media stream uniquely. For each SRTP/SRTCP media stream to be established with e2ae media security, the eIMS-AGW shall send the fingerprint of its certificate via Iq interface to the IMS-ALG.

NOTE 2: The same fingerprint also applies for End-to-access-edge security for RTP based media using DTLS-SRTP, as described in clause 5.11.2.4.

If the IMS-ALG received from the WIC an SDP offer with "a=tls-id" media-level SDP attribute (as specified in IETF RFC 8842 [81]) create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP answer which the IMS-ALG sends to the WIC.

If the IMS-ALG sends to the WIC an SDP offer, create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP offer.

NOTE 3: Already used certificate fingerprints can be assigned to a new DTLS association. If the IMS-AGW uses the same set of fingerprints for a new DTLS association then the IMS-ALG creates a new local "tls-id" attribute value so that the combination of the "tls-id" attribute values of the IMS-ALG and the WIC is unique across all DTLS associations that might be handled by the IMS-ALG and the WIC, as specified in IETF RFC 8842 [81].

According to procedures defined in 3GPP TS 24.371 [44], the eIMS-AGW shall act as either a DTLS server or client in the DTLS session.

In DTLS-SRTP over TCP case, RTP and RTCP data are encrypted using SRTP and SRTCP as defined in IETF RFC 3711 [14].

When the DTLS session is established between the WIC and the eIMS-AGW, the eIMS-AGW shall be prepared to send and receive SRTP/SRTCP packets over TCP of the incoming network side from the WIC, and convert SRTP/SRTCP packets to RTP/RTCP packets over UDP to the outgoing network side and vice versa, if the media stream towards the IMS core network is using RTP/RTCP over UDP.

5.11.2.6 End-to-access-edge security for WebRTC data channels using UDP/DTLS/SCTP transport

The procedures in clause 5.20.2 are applicable.

5.11.3 End-to-end Security

5.11.3.1 End-to-end security for RTP based media

For the support of e2e-security, the IMS-ALG and the IMS-AGW shall support "RTP/SAVP" (see IETF RFC 3711 [14]) and/or "RTP/SAVPF" (see IETF RFC 5124 [15]) as transport protocol.

If the IMS-ALG receives SDP containing media lines with "RTP/SAVP" (see IETF RFC 3711 [14]) or "RTP/SAVPF" (see IETF RFC 5124 [15]) as transport protocol, but did not receive any request for end-to-access-edge security, the IMS-ALG shall:

– forward the SDP with unmodified transport protocol for those media lines;

– provide "RTP/SAVP" or "RTP/SAVPF", as received in the SDP, to the IMS-AGW as transport protocol for all related terminations, and provide no media related information to these terminations, to configure the IMS-AGW to pass media transparently.

If the IMS-ALG receives SDP containing SDES SDP attribute(s) according to IETF RFC 4568 [13], and did not receive any request for end-to-access-edge security, it shall forward the SDP with unmodified SDES SDP attribute(s), but shall not provide the SDES SDP attribute(s) to the IMS-AGW.

5.11.3.2 End-to-end security for TCP-based media using TLS

End-to-end protection of MSRP (used in IMS session-based messaging) and BFCP (used in IMS conferencing) media is based on TLS, according to the TLS profile specified in Annex E of 3GPP TS 33.310 [48] and Annex M of 3GPP TS 33.328 [12].

If the IMS-ALG receives SDP containing media lines with "TCP/TLS/MSRP" (see IETF RFC 4975 [25] and IETF RFC 6714 [26]) and/or "TCP/TLS/BFCP" (see IETF RFC 4583 [27]) as transport protocol but did not receive any request for end-to-access-edge security, the IMS-ALG shall:

– forward the SDP with unmodified transport protocol for those media lines and unmodified TLS related SDP attribute(s);

– indicate "TCP" to the IMS-AGW as transport protocol for all related terminations, and provide no media related information to these terminations, to configure the IMS-AGW to pass media transparently.

NOTE: End-to-end security for TCP-based media using TLS is not supported between two terminals being located behind firewalls/NATs.

5.12 Explicit Congestion Notification support

5.12.1 General

An IMS-ALG and IMS-AGW may support Explicit Congestion Notification (see IETF RFC 3168 [16], IETF RFC 6679 [17] and 3GPP TS 26.114 [21]).

An IMS-ALG and IMS-AGW which supports ECN shall support the ECN transparent procedure i.e. the transparent forwarding of ECN bits in the IP header (see IETF RFC 3168 [16]). If the IMS-AGW does not support the transparent forwarding of ECN bits then the IMS-ALG shall not permit ECN in the SDP Offer/Answer negotiation.

The IMS-AGW shall treat RTCP for ECN as a RTP translator with no media translation.

An IMS-ALG and IMS-AGW which supports ECN may then act as an ECN endpoint to enable ECN towards the IMS access network or/and towards the IMS Core Network. The subsequent clauses describe the general support for ECN, further details on the support of ECN during PS to CS access transfer is described in clause 6.2.14.3.

NOTE: It is out of the scope of this profile to support interworking with a non-3GPP ECN IP terminal.

An IMS-ALG and IMS-AGW that support ECN Transparent as well as transcoding shall also support the ECN endpoint procedure.

An IMS-ALG/IMS-AGW supporting the ATCF/ATGW function and ECN shall support ECN Endpoint (see clause 6.2.14).

When acting as an ECN endpoint, the IMS-AGW shall be capable of enabling end-to-end rate adaptation between the local terminal and the remote entity by performing the following towards the ECN-capable peer:

– trigger rate adaptation request towards the ECN-capable peer when receiving in the incoming IMS media flow IP packets marked with ECN-CE, regardless of whether the IMS-AGW applies or does not apply transcoding;

– forward adaptation requests between the local and the remote peer when the IMS-AGW bridges compatible codec configurations between the interfaces without applying a transcoding function;

– perform media adaptation (e.g. reduce media bit-rate) towards the ECN-capable peer when receiving from the latter an adaptation request. and the IMS-AGW applies transcoding.

5.12.2 Incoming SDP offer with ECN

The IMS-ALG and IMS-AGW shall apply the requirements specified in clause 10.2.13.2 of 3GPP TS 29.162 [20] replacing the IBCF and TrGW with IMS-ALG and IMS-AGW respectively.

5.12.3 Incoming SDP offer without ECN

The IMS-ALG and IMS-AGW shall apply the requirements specified in clause 10.2.13.3 of 3GPP TS 29.162 [20] replacing the IBCF and TrGW with IMS-ALG and IMS-AGW respectively with the following additions:

– if the IMS-ALG or IMS-AGW does not support the procedure to act as an ECN endpoint, the IMS-ALG shall not include the "a=ecn-capable-rtp" attribute in the SDP offer it forwards to the succeeding node.

5.12.4 Detection of ECN failures by IMS-AGW

An IMS-ALG and IMS-AGW that support the procedure to act as an ECN endpoint shall support the requirements specified in clause 10.2.13.3a of 3GPP TS 29.162 [20] replacing the IBCF and TrGW with IMS-ALG and IMS-AGW respectively.

5.13 Transcoding

5.13.1 General

The transcoding functionality, where the IMS-AGW processes and possibly converts media data (like e.g. RTP payload) is optional for the P-CSCF and IMS-AGW to support. Transcoding should be supported if the IMS-ALG and IMS-AGW support the ATCF and ATGW functions for use after an SRVCC handover if the media that was used prior to the access transfer is not supported by the MSC Server.

An IMS-ALG and IMS-AGW that support transcoding shall support the requirements specified for Media Control in clause 10.2.5 of 3GPP TS 29.162 [20] respectively for the IBCF and TrGW, with the following additions:

– During an originating or terminating PS session establishment, the IMS-ALG (ATCF) may remove codecs when passing SDP offers (e.g. codecs known not to be supported by either the IMS-AGW (ATGW) or the MSC Server), but 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 (ATGW) before the PS to CS access transfer;

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

The procedures for the IMS-ALG (ATCF) and IMS-AGW (ATGW) are further detailed in clause 6.2.14.

5.13.2 Handling of common codec parameters

When receiving an SDP offer, the IMS-ALG may add a payload type to offer transcoding before forwarding the SDP offer (denoted as "codec 3" in figures 10.2.5.1 and 10.2.5.2 of 3GPP TS 29.162 [20]). If that payload type is selected in the SDP answer, the IMS-ALG needs to transcode. Table 5.13.2.1 describes the IMS-ALG handling of codec related parameters applicable to multiple codecs when the IMS-ALG adds the payload type to the SDP offer, and that payload type is selected in the SDP answer.

Table 5.13.2.1: IMS-ALG handling of common codec parameters for transcoding.

Parameter	Handling of common codec parameter in the sent SDP offer	Handling of common codec parameter in the received SDP answer
ptime (NOTE)	If the ptime parameter is included in the received SDP offer, the IMS-ALG shall supply the parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor. If the value is supported by the IMS-AGW for receiving media, the IMS-ALG should keep the value from the received SDP offer unchanged in the SDP offer it sends. If the IMS-AGW only supports a lower ptime value, the IMS-ALG shall supply the ptime value according to configured preferences in the SDP offer it forwards. If no ptime value was contained in the received SDP offer, the IMS-ALG may add the parameter with a value according to configured preferences to the SDP offer.	If the ptime parameter is included in the received SDP answer, the IMS-ALG shall supply the parameter to the IMS-AGW for the termination towards the SDP answerer in the remote descriptor. If the value is supported by the IMS-AGW for receiving media, the IMS-ALG should keep the value from the received SDP answer unchanged in the SDP answer it sends. If the IMS-AGW only supports a lower ptime value, the IMS-ALG shall supply the ptime value according to configured preferences in the SDP answer it forwards. If no ptime value was contained in the received SDP answer, the IMS-ALG may add the parameter with a value according to configured preferences to the SDP answer.
maxptime (NOTE)	If the maxptime parameter is included in the received SDP offer, the IMS-ALG shall supply the parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor. If the value is supported by the IMS-AGW for receiving media, the IMS-ALG should keep the value from the received SDP offer unchanged in the SDP offer it sends. If the IMS-AGW only supports a lower maxptime value, the IMS-ALG shall supply the maxptime value according to the IMS-AGW capabilities in the SDP offer it forwards. If no maxptime value was contained in the received SDP offer, the IMS-ALG may add the parameter with a value according to the IMS-AGW capabilities to the SDP offer.	If the maxptime parameter is included in the received SDP answer, the IMS-ALG shall supply the parameter to the IMS-AGW for the termination towards the SDP answerer in the remote descriptor. If the value is supported by the IMS-AGW for receiving media, the IMS-ALG should keep the value from the received SDP answer unchanged in the SDP answer it sends. If the IMS-AGW only supports a lower maxptime value, the IMS-ALG shall supply the maxptime value according to the IMS-AGW capabilities in the SDP answer it forwards. If no maxptime value was contained in the received SDP answer, the IMS-ALG may add the parameter with a value according to the IMS-AGW capabilities to the SDP answer.
NOTE: This SDP attribute is defined in IETF RFC 4566 [53]. It applies to all codecs offered in an SDP media line.

Table 5.13.2.2 describes the IMS-AGW handling of codec related parameters applicable to multiple codecs.

Table 5.13.2.2: IMS-AGW handling of common codec parameters

Parameter	Handling in local descriptor	Handling in remote descriptor
ptime (NOTE)	The IMS-AGW should expect to receive packets with this ptime value and may use this information when deciding upon the required resources.	The IMS-AGW should use this ptime value when sending packets.
maxptime (NOTE)	The IMS-AGW should expect to receive packets with this maxptime value and may use this information when deciding upon the required resources.	The IMS-AGW shall use this maxptime value when sending packets.
NOTE: This SDP attribute is defined in IETF RFC 4566 [53]. It applies to all codecs offered in an SDP media line.

5.13.3 Handling of the EVS speech codec

The Enhanced Voice Services (EVS) speech codec is defined in 3GPP TS 26.441 [51]. Its RTP payload type is defined in 3GPP TS 26.445 [52], and procedures for its usage as IMS Multimedia Telephony speech codec are defined in 3GPP TS 26.114 [21].

The IMS-ALG and the IMS-AGW may support transcoding to and from the EVS speech codec. If they do so, the procedures in the present clause apply.

When receiving an SDP offer, the IMS-ALG may add an EVS codec payload type before forwarding the SDP offer (denoted as "codec 3" in figures 10.2.5.1 and 10.2.5.2 of 3GPP TS 29.162 [20]). If that EVS payload type is selected in the SDP answer, the IMS-ALG needs to transcode the EVS codec. Table 5.13.3.1 describes the IMS-ALG handling of EVS codec parameters when the IMS-ALG adds the EVS payload type to the SDP offer, and that EVS payload type is selected in the SDP answer. In addition, rules for the parameter handling in 3GPP TS 26.445 [52] shall apply.

Table 5.13.3.1: IMS-ALG handling of EVS related SDP parameters when the IMS-ALG adds the EVS payload type to the SDP offer.

Parameter	Handling for EVS payload type added to the SDP offer to offer transcoding	Handling if offered EVS payload type is accepted in the SDP answer
evs-mode-switch (NOTE 1)	If the IMS-ALG expects that interworking between AMR-WB and EVS is required (e.g. because AMR-WB was the first payload type in the received SDP offer), it shall include the evs-mode-switch with value 1. Otherwise the IMS-ALG shall not include the evs-mode-switch.	If the evs-mode-switch parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the answerer in the remote descriptor.
hf-only (NOTE 1)	If the IMS-ALG is configured to negotiate using only the header-full EVS RTP payload format, the IMS-ALG shall include the hf-only parameter with a value 1.	If the hf-only parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
dtx (NOTE 1)	If the usage of DTX is not desired in the sending and receiving direction (e.g. due to DTX capabilities of expected codecs to transcode with, e.g. other codecs in the received SDP offer), the IMS-ALG shall include the dtx parameter with a value 0.	If the dtx parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
dtx-recv (NOTE 1)	If receiving DTX is not desired and the dtx parameter is not included, the IMS-ALG shall include the dtx-recv parameter with a value 0. If both the dtx and dtx-recv parameters are included, those parameters shall have the same value; however, inclusion of the dtx-recv parameter is not required if the dtx parameter is included.	If the dtx-recv parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
br (NOTE 1)	If the IMS-ALG desires the same bit rate range for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range to match IMS-AGW capabilities and possible configured policies, it shall supply the br parameter in the SDP offer it sends. Otherwise the IMS-ALG shall not include this parameter in the SDP offer. If the IMS-ALG also supplies the bw, bw-send or bw-recv parameter, the value of the br parameter shall be compatible with the values of those parameters.	If the br parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
br-send (NOTE 1)	If the IMS-ALG desires a different bit rate (range) for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range for the send direction to match IMS-AGW capabilities and possible configured policies, it shall supply the br-send parameter in the SDP offer it sends. Otherwise the IMS-ALG shall not include this parameter in the SDP offer. If the IMS-ALG also supplies the bw or bw-send parameter, the value of the br-send parameter shall be compatible with the values of those parameters.	If the br-send parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
br-recv (NOTE 1)	If the IMS-ALG desires a different bit rate (range) for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range for the receive direction to match IMS-AGW capabilities and possible configured policies, it shall supply the br-recv parameter in the SDP offer it sends. Otherwise the IMS-ALG shall not include this parameter in the SDP offer. If the IMS-ALG also supplies the bw or bw-recv parameter, the value of the br-recv parameter shall be compatible with the values of those parameters.	If the br-recv parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
bw (NOTE 1)	If the IMS-ALG desires the same sampling bandwidth(s) for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths to match IMS-AGW capabilities, sampling bandwidths of expected codecs EVS will be transcoded to (e.g. the first payload type in the received SDP offer), and possible configured policies, it shall supply the bw parameter in the SDP offer it sends. Otherwise the IMS-ALG shall not include this parameter in the SDP offer.	If the bw parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
bw-send (NOTE 1)	If the IMS-ALG desires different sampling bandwidths for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths in the send direction to match IMS-AGW capabilities, sampling bandwidths of expected codecs EVS will be transcoded to (e.g. the first payload type in the received SDP offer) and possible configured policies, it shall supply the bw-send parameter in the SDP offer it sends. Otherwise the IMS-ALG shall not include this parameter in the SDP offer.	If the bw-send parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
bw-recv (NOTE 1)	If the IMS-ALG desires different sampling bandwidths for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths in the receive direction to match IMS-AGW capabilities, sampling bandwidths of expected codecs EVS will be transcoded to (e.g. the first payload type in the received SDP offer), and possible configured policies, it shall supply the bw-recv parameter in the SDP offer it sends. Otherwise the IMS-ALG shall not include this parameter in the SDP offer.	If the bw-recv parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
cmr (NOTE 1)	If the IMS-ALG desires to disable codec mode requests within the RTP payload of the EVS primary mode (due to the IMS-AGW capabilities or policies), it shall include the cmr parameter with value -1 in the SDP offer it sends.	If the cmr parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
ch-aw-recv (NOTE 1)	The IMS-ALG shall include the ch-aw-recv parameter in the SDP offer if it desires to control the channel-aware mode of EVS in the receive direction, e.g. to disable it with value -1. The IMS-ALG shall consider the capabilities of the IMS-AGW when it chooses an appropriate value.	If the ch-aw-recv parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
number of channels (NOTE 2)	The IMS-ALG shall only include the "number of channels" parameter in the SDP offer if it desires to send or receive multiple channels. If the desired number of channels in the send and receive direction differs, the IMS-ALG shall include the higher value. The IMS-ALG should consider the number of channels of expected codecs EVS will be transcoded to (e.g. the first payload type in the received SDP offer).	If the "number of channels" parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
ch-send (NOTE 1)	The IMS-ALG shall only include the ch-send parameter in the SDP offer if it desires to send multiple channels, with different numbers of channels in the send and receive direction. The IMS-ALG should consider the number of channels of expected codecs EVS will be transcoded to (e.g. the first payload type in the received SDP offer).	If the ch-send parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
ch-recv (NOTE 1)	The IMS-ALG shall only include the ch-recv parameter in the SDP offer if it desires to receive multiple channels, with different numbers of channels in the send and receive direction. The IMS-ALG should consider the number of channels of expected codecs EVS will be transcoded to (e.g. the first payload type in the received SDP offer).	If the ch-recv parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
mode-set (NOTE 3)	The IMS-ALG shall only include the mode-set parameter in the SDP offer if it desires to restrict the mode-set of AMR-WB IO mode. The IMS-ALG should only restrict the mode-set if the expected codec EVS will be interworked with (e.g. the first payload type in the received SDP offer) is AMR-WB and has a restricted mode-set.	If the mode-set parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor. If the IMS-ALG decides that EVS will be transcoded to AMR-WB, the IMS-ALG should include the mode-set parameter for the AMR-WB payload in the SDP offer it forwards if this is permissible by AMR-WB offer answer rules in IETF RFC 4867 [54].
mode-change-period (NOTE 3)	The IMS-ALG shall only include the mode-change-period parameter with value 2 in the SDP offer if it desires to restrict the mode-change-period of received packets in AMR-WB IO mode. The IMS-ALG should only restrict the mode-change-period if the expected codec EVS will be interworked with (e.g. the first payload type in the received SDP offer) is AMR-WB and has such a restriction.	If the mode-change-period parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor. If the IMS-ALG decides that EVS will be transcoded to AMR-WB, the IMS-ALG should include the mode-change-period parameter for the AMR-WB payload in the SDP offer it forwards.
mode-change-capability (NOTE 3)	The IMS-ALG shall include the mode-change-capability parameter with value 2 in the SDP offer if it is capable of restricting the mode-change-period of packets it sends in AMR-WB IO mode. The IMS-ALG should consider the mode-change-period of the expected codec EVS will be interworked with (e.g. the first payload type in the received SDP offer) if this is AMR-WB.	If the mode-change-capability parameter is contained in the SDP answer, the IMS-ALG may forward this parameter to the IMS-AGW in the remote descriptor. If the IMS-ALG decides that EVS will be transcoded to AMR-WB, the IMS-ALG should include the mode-change-capability parameter for the AMR-WB payload in the SDP offer it forwards.
mode-change-neighbor (NOTE 3)	The IMS-ALG shall only include the mode-change-neighbor parameter in the SDP offer if it desires to restrict the mode-change within received packets of AMR-WB IO mode to neighboring modes. The IMS-ALG should consider the mode-change-neighbor parameter of the expected codec EVS will be interworked with (e.g. the first payload type in the received SDP offer) if this is AMR-WB.	If the mode-change-neighbor parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor. If the IMS-ALG decides that EVS will be transcoded to AMR-WB, the IMS-ALG should include the mode-change-neighbor parameter for the AMR-WB payload in the SDP offer it forwards.
max-red (NOTE 5)	The IMS-ALG shall only include the max-red parameter in the SDP offer if it desires to restrict the maximum redundancy of received packets. IMS-ALG shall consider the capabilities of the IMS-AGW, and should consider the max-red parameter of the expected codec EVS will be interworked with (e.g. the first payload type in the received SDP offer) if this is AMR-WB.	If the max-red parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor. If the IMS-ALG decides that EVS will be interworked with AMR-WB, the IMS-ALG should include the max-red parameter for the AMR-WB payload in the SDP offer it forwards.
3gpp_mtsi_app_adapt (NOTE 4)	If the IMS-AGW supports RTCP APP based adaptation messages defined in 3GPP TS 26.114 [21], and the IMS-ALG has a policy to negotiate the usage of those messages, the IMS-ALG shall include the 3gpp_mtsi_app_adapt SDP attribute indicating the supported APP messages in the SDP offer.	If the 3gpp_mtsi_app_adapt attribute is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.
NOTE 1: This MIME parameter of the EVS RTP payload type is defined in 3GPP TS 26.445 [51]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [53]. NOTE 2: This number of channels are encoded as "encoding parameters" of the SDP "a=rtpmap" attribute defined in IETF RFC 4566 [53]. NOTE 3: This MIME parameter of the EVS RTP payload type relates to AMR-WB IO mode and is defined in IETF RFC 4867 [54]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [53]. NOTE 4: This SDP attribute is defined in 3GPP TS 26.114 [21]. It applies to all codecs offered in an SDP media line. However, some values are specific to EVS. NOTE 5: This MIME parameter of the EVS RTP payload type is defined in IETF RFC 4867 [54]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [53].

When receiving an SDP offer that contains an EVS codec payload type (denoted as "codec 1" in figure 10.2.5.2 of 3GPP TS 29.162 [20]), the IMS-ALG may add other payload types before forwarding the SDP offer (denoted as "codec 3" in figure 10.2.5.2 of 3GPP TS 29.162 [20]). If that added payload type is selected in the SDP answer, the IMS-ALG needs to transcode, and may select to transcode to the EVS codec. Table 5.13.3.2 describes the IMS-ALG handling of EVS codec parameters when the IMS-ALG receives an EVS payload type in an SDP offer, and selects to transcode between the EVS codec and some other codec. In addition, rules for the parameter handling in 3GPP TS 26.445 [52] shall apply.

Table 5.13.3.2: IMS-ALG handling of EVS related SDP parameters when the IMS-ALG receives the EVS payload type in the SDP offer and decides to transcode between the EVS payload type and some other codec.

Parameter	Handling of EVS payload type parameter received in the SDP offer	EVS payload type supplied in the SDP answer
evs-mode-switch (NOTE 1)	If the evs-mode-switch parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the evs-mode-switch parameter is contained in the SDP offer, the IMS-ALG shall include the evs-mode-switch parameter with unmodified value in the SDP answer. Otherwise, if the IMS-ALG decides to interwork between AMR-WB and EVS (e.g. because AMR-WB was selected in the received SDP answer), it shall include the evs-mode-switch with value 1. Otherwise the IMS-ALG shall not include the evs-mode-switch. If the IMS-ALG supplies the evs-mode-switch in the SDP answer, it shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
hf-only (NOTE 1)	If the hf-only parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the hf-only parameter is contained in the SDP offer, the IMS-ALG shall include the hf-only parameter with unmodified value in the SDP answer. Otherwise, if the IMS-ALG is configured to negotiate using only the header-full EVS RTP payload format, the IMS-ALG shall include the hf-only parameter with a value 1. If the IMS-ALG supplies the hf-only parameter in the SDP answer, it shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
dtx (NOTE 1)	If the dtx parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the dtx parameter is contained in the SDP offer, the IMS-ALG shall include the dtx parameter with unmodified value in the SDP answer. If the dtx parameter is not contained in the SDP offer and if a dtx-recv parameter is contained in the SDP offer, the IMS-ALG may include the dtx parameter in the SDP answer, and the value of the dtx parameter shall then be identical to that of the dtx-recv parameter in the SDP offer (e.g, if that value matches DTX capabilities of expected codecs to transcode with). If the dtx parameter is not contained in the SDP offer and if the dtx-recv parameter is not contained in the SDP offer, and if the usage of DTX is not desired (e.g. due to DTX capabilities of expected codecs to transcode with, e.g. other codecs in the received SDP answer), the IMS-ALG shall include in the SDP answer the dtx parameter with a value 0. If the IMS-ALG supplies the dtx parameter in the SDP answer, it shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
dtx-recv (NOTE 1)	If the dtx-recv parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If no dtx parameter is included in the SDP answer and if the reception of DTX is not desired, the IMS-ALG shall include in the SDP answer the dtx-recv parameter with a value 0. If both the dtx and dtx-recv parameters are included, those parameters shall have the same value; however, inclusion of the dtx-recv parameter is not required if the dtx parameter is included. If the IMS-ALG supplies the dtx-recv parameter in the SDP answer, it should also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
br (NOTE 1)	If the br parameter is contained in the SDP offer, the IMS-ALG shall check if the IMS-AGW supports the indicated bitrates, or a subset of them, in EVS primary mode in the send and receive direction. If the indicated bitrates, and even each subset of them, are not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type, it shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the br parameter is contained in the SDP offer, the IMS-ALG shall select a bitrate value, which is either the received br value or a subset of it, based on IMS-AGW capabilities and possible configured policies, and shall include the br parameter with the selected value that is also supplied towards the IMS-AGW in the SDP answer. Otherwise, if the IMS-ALG desires the same bit rate range for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range to match IMS-AGW capabilities and possible configured policies, it shall supply the br parameter in the SDP answer it sends. Otherwise the IMS-ALG shall not include this parameter in the SDP answer. If the IMS-ALG also supplies the bw, bw-send or bw-recv parameter, the value of the br parameter shall be compatible with the values of those parameters. If the IMS-ALG supplies the br parameter in the SDP answer, it shall also supply to the IMS-AGW the br parameter in the local descriptor for the termination towards the offerer with the same value.
br-send (NOTE 1)	If the br-send parameter is contained in the SDP offer, the IMS-ALG shall check if the IMS-AGW supports the indicated bitrates, or a subset of them, in EVS primary mode in the receive direction. If the indicated bitrates, and even each subset of them, are not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type, it shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the br-recv parameter is contained in the SDP offer, the IMS-ALG shall select a bitrate value, which is either the received br-recv value or a subset of it, based on IMS-AGW capabilities and possible configured policies, and shall include the br-send parameter with the selected value that is also supplied towards the IMS-AGW in the SDP answer. Otherwise, if the IMS-ALG desires a different bit rate (range) for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range for the send direction to match IMS-AGW capabilities and possible configured policies, it shall supply the br-send parameter in the SDP answer it sends. Otherwise the IMS-ALG shall not include the br-send parameter in the SDP answer. If the IMS-ALG also supplies the bw or bw-send parameter, the value of the br-send parameter shall be compatible with the values of those parameters. If the IMS-ALG supplies the br-send parameter in the SDP answer, it shall also supply to the IMS-AGW the br-send parameter in the local descriptor for the termination towards the offerer with the same value.
br-recv (NOTE 1)	If the br-recv parameter is contained in the SDP offer, the IMS-ALG shall check if the IMS-AGW supports the indicated bitrates, or a subset of them, in EVS primary mode in the send direction. If the indicated bitrates, and even each subset of them, are not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type, it shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the br-send parameter is contained in the SDP offer, the IMS-ALG shall select a bitrate value, which is either the received br-send value or a subset of it, based on IMS-AGW capabilities and possible configured policies, and shall include the br-recv parameter with the selected value that is also supplied towards the IMS-AGW in the SDP answer. Otherwise, if the IMS-ALG desires a different bit rate (range) for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range for the receive direction to match IMS-AGW capabilities and possible configured policies, it shall supply the br-recv parameter in the SDP answer it sends. Otherwise the IMS-ALG shall not include the br-recv parameter in the SDP answer. If the IMS-ALG also supplies the bw or bw-recv parameter, the value of the br-recv parameter shall be compatible with the values of those parameters. If the IMS-ALG supplies the br-recv parameter in the SDP answer, it shall also supply to the IMS-AGW the br-recv parameter in the local descriptor for the termination towards the offerer with the same value.
bw (NOTE 1)	If the bw parameter is contained in the SDP offer, the IMS-ALG shall check if the IMS-AGW supports the indicated sampling bandwidth(s), or a subset of them, in EVS primary mode in the send and receive direction. If the indicated sampling bandwidth(s), and even each subset of them, are not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type, it shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the bw parameter is contained in the SDP offer, the IMS-ALG shall select a sampling bandwidth value, which is either the received bw value or a subset of it, based on IMS-AGW capabilities and possible configured policies, and shall include the bw parameter with the selected value that is also supplied towards the IMS-AGW in the SDP answer. Otherwise, if the IMS-ALG desires the same sampling bandwidth(s) for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidth(s) to match IMS-AGW capabilities and possible configured policies, it shall supply the bw parameter in the SDP answer it sends. Otherwise the IMS-ALG shall not include this parameter in the SDP answer. If the IMS-ALG also supplies the br, br-send or br-recv parameter, the value of the bw parameter shall be compatible with the values of those parameters. If the IMS-ALG supplies the bw parameter in the SDP answer, it shall also supply to the IMS-AGW the bw parameter in the local descriptor for the termination towards the offerer with the same value.
bw-send (NOTE 1)	If the bw-send parameter is contained in the SDP offer, the IMS-ALG shall check if the IMS-AGW supports the indicated sampling bandwidths, or a subset of them, in EVS primary mode in the receive direction. If the indicated sampling bandwidths, and even each subset of them, are not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type, it shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the bw-recv parameter is contained in the SDP offer, the IMS-ALG shall select a sampling bandwidths value, which is either the received bw-recv value or a subset of it, based on IMS-AGW capabilities and possible configured policies, and shall include the bw-send parameter with the selected value in the SDP answer. Otherwise, if the IMS-ALG desires different sampling bandwidths for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths for the send direction to match IMS-AGW capabilities and possible configured policies, it shall supply the bw-send parameter in the SDP answer it sends. Otherwise the IMS-ALG shall not include the br-send parameter in the SDP answer. If the IMS-ALG also supplies the bw or bw-send parameter, the value of the br-send parameter shall be compatible with the values of those parameters. If the IMS-ALG supplies the bw-send parameter in the SDP answer, it shall also supply to the IMS-AGW the bw-send parameter in the local descriptor for the termination towards the offerer with the same value.
bw-recv (NOTE 1)	If the br-recv parameter is contained in the SDP offer, the IMS-ALG shall check if the IMS-AGW supports the indicated sampling bandwidths, or a subset of them, in EVS primary mode in the send direction. If the indicated sampling bandwidths, and even each subset of them, are not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type, it shall forward the bw-recv parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the bw-send parameter is contained in the SDP offer, the IMS-ALG shall select a sampling bandwidths value, which is either the received bw-send value or a subset of it, based on IMS-AGW capabilities and possible configured policies, and shall include the bw-recv parameter with the selected value in the SDP answer. Otherwise, if the IMS-ALG desires a different sampling bandwidths for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths for the receive direction to match IMS-AGW capabilities and possible configured policies, it shall supply the bw-recv parameter in the SDP answer it sends. Otherwise the IMS-ALG shall not include the bw-recv parameter in the SDP answer. If the IMS-ALG also supplies the br or br-recv parameter, the value of the bw-recv parameter shall be compatible with the values of those parameters. If the IMS-ALG supplies the bw-send parameter in the SDP answer, it shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
cmr (NOTE 1)	If the cmr parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the cmr parameter is contained in the SDP offer, the IMS-ALG shall include the cmr parameter with unmodified value in the SDP answer. Otherwise, if the IMS-AGW desires to disable codec mode requests within the RTP payload of the EVS primary mode (due to the IMS-AGW capabilities or policies), it shall include the cmr parameter with value -1 in the SDP answer it sends If the IMS-ALG supplies the cmr parameter in the SDP answer, it shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
ch-aw-recv (NOTE 1)	If the ch-aw-recv parameter is contained in the SDP offer the IMS-ALG shall check if the IMS-AGW supports the indicated mode in the send direction. If the indicated mode is not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the IMS-ALG it desires to control the channel-aware mode of EVS in the receive direction, e.g. to disable it with value -1, it shall include the ch-aw-recv parameter in the SDP offer and shall also supply the ch-aw-recv parameter to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value. The IMS-ALG shall consider the capabilities of the IMS-AGW when it chooses an appropriate value.
number of channels (NOTE 2)	If the "number of channels" parameter is contained in the SDP offer the IMS-ALG shall check if the IMS-AGW supports the indicated number of channels. If the indicated number of channels is not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the "number of channels" parameter is contained in the SDP offer, the IMS-ALG shall include the "number of channels" parameter with unmodified value in the SDP answer and shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
ch-send (NOTE 1)	If the ch-send parameter is contained in the SDP offer the IMS-ALG shall check if the IMS-AGW supports the indicated number of channels in the receive direction. If the indicated number of channels is not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type for transcoding, the IMS-ALG shall forward the ch-send parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the ch-recv parameter is contained in the SDP offer, the IMS-ALG shall include the ch-send parameter with unmodified value in the SDP answer and shall also supply the ch-send parameter to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
ch-recv (NOTE 1)	If the ch-recv parameter is contained in the SDP offer the IMS-ALG shall check if the IMS-AGW supports the indicated number of channels in the send direction. If the indicated number of channels is not supported, the IMS-ALG shall not select the EVS payload type for transcoding. If the IMS-ALG selects the EVS payload type for transcoding, the IMS-ALG shall forward the ch-recv parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	If the ch-send parameter is contained in the SDP offer, the IMS-ALG shall include the ch-recv parameter with unmodified value in the SDP answer and shall also supply the ch-recv parameter to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
mode-set (NOTE 3)	If the mode-set parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor. If the mode-set parameter is contained in the SDP offer and the IMS-ALG expects that EVS will be interworked with AMR-WB (e.g. if EVS is the first payload type in the received SDP offer, and the IMS-ALG adds a AMR-WB payload type), the IMS-ALG should include the mode-set parameter with the same value for the AMR-WB payload in the SDP offer it forwards.	If the mode-set parameter is contained in the SDP offer, the IMS-ALG shall include the mode-set parameter with unmodified value in the SDP answer. Otherwise, if the mode-set parameter is contained in the SDP answer for an AMR-WB payload type and the IMS-ALG decides that the EVS codec will be interworked with that AMR-WB payload type, the IMS-ALG should include that mode-set parameter for the EVS payload in the SDP offer it forwards. If the IMS-ALG supplies the mode-set parameter in the SDP answer, it shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
mode-change-period (NOTE 3)	If the mode-change-period parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor. If the mode-change-period parameter is contained in the SDP offer and the IMS-ALG expects that EVS will be interworked with AMR-WB (e.g. if EVS is the first payload type in the received SDP offer, and the IMS-ALG adds the AMR-WB payload type), the IMS-ALG should include the mode-change-period parameter with the same value for the AMR-WB payload type in the SDP offer it forwards.	If the mode-change-period parameter is contained in the SDP answer for the AMR-WB payload type and the IMS-ALG decides the EVS codec will be interworked with that AMR-WB payload type, the IMS-ALG should include the mode-change-period parameter for the EVS payload in the SDP offer it forwards. If the IMS-ALG supplies the mode-change-period parameter in the SDP answer, it shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
mode-change-capability (NOTE 3)	If the mode-change-capability parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG may forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor. If the IMS-ALG expects that EVS will be interworked with AMR-WB (e.g. if EVS is the first payload type in the received SDP offer, and the IMS-ALG adds the AMR-WB payload type), the IMS-ALG should include the mode-change-capability parameter with value 2 for the AMR-WB payload in the SDP offer it forwards.	If the IMS-ALG decides that the EVS codec is selected, the IMS-ALG shall either include the mode-change-capability parameter with value 2 or omit the parameter for the EVS payload in the SDP offer it forwards. If the IMS-ALG supplies the mode-change-capability parameter in the SDP answer, it may also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
mode-change-neighbor (NOTE 3)	If the mode-change-neighbor parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor. If the mode-change-neighbor parameter is contained in the SDP offer and the IMS-ALG expects that EVS will be interworked with AMR-WB (e.g. if EVS is the first payload type in the received SDP offer, and the IMS-ALG adds the AMR-WB payload type), the IMS-ALG should include the mode-change-neighbor with the same value for the AMR-WB payload in the SDP offer it forwards.	If the mode-change-neighbor parameter is contained in the SDP answer for the AMR-WB payload type and the IMS-ALG decides that the EVS codec will be interworked with that AMR-WB payload type, the IMS-ALG should include the mode-change-neighbor parameter for the EVS payload in the SDP offer it forwards. If the IMS-ALG supplies the mode-change-neighbor parameter in the SDP answer, it shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
max-red (NOTE 5)	If the max-red parameter is contained in the SDP offer and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor. If the max-red parameter is contained in the SDP offer and the IMS-ALG expects that EVS will be interworked with AMR-WB (e.g. if EVS is the first payload type in the received SDP offer, and the IMS-ALG adds the AMR-WB payload type), the IMS-ALG should include the max-red parameter with the same value for the AMR-WB payload in the SDP offer it forwards with a value that considers the received value and the capabilities of the IMS-AGW.	The IMS-ALG shall only include the max-red parameter in the SDP answer if it desires to restrict the maximum redundancy of received packets. When selecting the value of the max-red parameter, the IMS-ALG shall consider the capabilities of the IMS-AGW and, if the max-red parameter is contained in the SDP answer for the AMR-WB payload type and the IMS-ALG decides that the EVS codec will be interworked with that AMR-WB payload type, the received value. If the IMS-ALG supplies the max-red parameter in the SDP answer, it shall also supply it to the IMS-AGW in the local descriptor for the termination towards the offerer with the same value.
3gpp_mtsi_app_adapt (NOTE 4)	If the 3gpp_mtsi_app_adapt parameter is contained in the SDP answer, and the IMS-ALG select the EVS payload type for transcoding, the IMS-ALG shall forward this parameter to the IMS-AGW the IMS-ALG shall forward this parameter to the IMS-AGW in the remote descriptor.	If the IMS-AGW supports RTCP APP based adaptation messages defined in 3GPP TS 26.114 [21], and the IMS-ALG has a policy to negotiate the usage of those messages, the IMS-ALG shall include the 3gpp_mtsi_app_adapt SDP attribute indicating the supported APP messages in the SDP answer.
NOTE 1: This MIME parameter of the EVS RTP payload type is defined in 3GPP TS 26.445 [51]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [53]. NOTE 2: This number of channels are encoded as "encoding parameters" of the SDP "a=rtpmap" attribute defined in IETF RFC 4566 [53]. NOTE 3: This MIME parameter of the EVS RTP payload type relates to AMR-WB IO mode and is defined in IETF RFC 4867 [54]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [53]. NOTE 4: This SDP attribute is defined in 3GPP TS 26.114 [21]. It applies to all codecs offered in an SDP media line. However, some values are specific to EVS. NOTE 5: This MIME parameter of the EVS RTP payload type is defined in IETF RFC 4867 [54]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [53].

Table 5.13.3.3 describes the IMS-AGW handling of EVS codec parameters. The IMS-AGW should support transcoding of EVS with bandwidths (sampling rates) which are supported by codec the IMS-AGW is capable to transcode EVS to/from (e.g. NB for AMR, and WB for AMR-WB).

Table 5.13.3.3: IMS-AGW handling of EVS codec parameters

Parameter	Handling in local descriptor	Handling in remote descriptor
evs-mode-switch (NOTE 1)	The IMS-AGW should expect to receive packets with the indicated EVS mode and may use this information when deciding upon the required resources.	The IMS-AGW shall use the indicated EVS mode (e.g. AMR-WB interoperable mode for value 1) when sending packets.
hf-only (NOTE 1)	The IMS-AGW should expect to receive packets with the indicated mode and may use this information when deciding upon the required resources.	The IMS-AGW shall use the indicated mode (e.g. header-full EVS RTP payload format for value 1) when sending packets.
dtx (NOTE 1)	The IMS-AGW should expect to receive packets with this dtx mode and may use this information when deciding upon the required resources. (NOTE 8)	The IMS-AGW shall use this dtx mode (i.e. no usage of DTX for value 0) when sending packets. (NOTE 8)
dtx-recv (NOTE 1)	The IMS-AGW should expect to receive packets with this dtx mode and may use this information when deciding upon the required resources. (NOTE 8)	The IMS-AGW shall use this dtx mode (i.e. no usage of DTX for value 0) when sending packets. (NOTE 8)
br (NOTE 1)	If different values for the br parameter are provided in the local and remote descriptors, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW should expect to receive packets with this bitrate range and may use this information when deciding upon the required resources. The IMS-AGW shall use this bitrate range when sending packets.	If different values for the br parameter are provided in the local and remote descriptors, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW should expect to receive packets with this bitrate range and may use this information when deciding upon the required resources. The IMS-AGW shall use this bitrate range when sending packets.
br-send (NOTE 1)	If different values for the br-send parameter in the local descriptor and for the br-recv parameter in the remote descriptor are provided, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW shall use this bitrate range when sending packets.	If different values for the br-send parameter in the remote descriptor and for the br-recv parameter in the local descriptor are provided, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW should expect to receive packets with this bitrate range and may use this information when deciding upon the required resources.
br-recv (NOTE 1)	If different values for the br-send parameter in the remote descriptor and for the br-recv parameter in the local descriptor are provided, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW should expect to receive packets with this bitrate range and may use this information when deciding upon the required resources.	If different values for the br-send parameter in the local descriptor and for the br-recv parameter in the remote descriptor are provided, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW shall use this bitrate range when sending packets.
bw (NOTE 1)	If different values for the bw parameter are provided in the local and remote descriptors, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW should expect to receive packets with these sampling bandwidth(s) and may use this information when deciding upon the required resources. The IMS-AGW shall use these sampling bandwidth(s) when sending packets.	If different values for the bw parameter are provided in the local and remote descriptors, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW should expect to receive packets with these sampling bandwidth(s) and may use this information when deciding upon the required resources. The IMS-AGW shall use these sampling bandwidth(s) when sending packets.
bw-send (NOTE 1)	If different values for the bw-send parameter in the local descriptor and for the bw-recv parameter in the remote descriptor are provided, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW shall use these sampling bandwidth(s) when sending packets.	If different values for the bw-send parameter in the remote descriptor and for the bw-recv parameter in the local descriptor are provided, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW should expect to receive packets with these sampling bandwidth(s) and may use this information when deciding upon the required resources.
bw-recv (NOTE 1)	If different values for the bw-send parameter in the remote descriptor and for the bw-recv parameter in the local descriptor are provided, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW should expect to receive packets with these sampling bandwidth(s) and may use this information when deciding upon the required resources.	If different values for the bw-send parameter in the local descriptor and for the bw-recv parameter in the remote descriptor are provided, one will be a subset of the other, and the smaller range shall apply. The IMS-AGW shall use these sampling bandwidth(s) when sending packets.
cmr (NOTE 1)	For cmr with value -1 or 0, the IMS-AGW should expect to receive no RTP packets containing codec mode requests for EVS primary mode and may use this information when deciding upon the required resources. For cmr with value -1 or 0, the IMS-AGW shall also send no RTP packets containing codec mode requests for EVS primary mode. Different cmr values in the local and remote descriptors are an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.	For cmr with value -1 or 0, the IMS-AGW should expect to receive no RTP packets containing codec mode requests for EVS primary mode and may use this information when deciding upon the required resources. For cmr with value -1 or 0, the IMS-AGW shall also send no RTP packets containing codec mode requests for EVS primary mode. Different cmr values in the local and remote descriptors are an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.
ch-aw-recv (NOTE 1, NOTE 7)	The IMS-AGW should expect to receive RTP packets containing the indicated partial redundancy mode and may use this information when deciding upon the required resources.	The IMS-AGW shall send RTP packets containing the indicated partial redundancy mode.
number of channels (NOTE 2)	If no ch-recv parameter in the local descriptor and no ch-send parameter in the remote descriptors are received, the IMS-AGW should expect to receive RTP packets containing the indicated number of channels and may use this information when deciding upon the required resources. If no ch-send parameter in the local descriptor and no ch-recv parameter in the remote descriptors are received, the IMS-AGW shall also send RTP packets containing the indicated number of channels. Different number of channels values in the local and remote descriptors is an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.	If no ch-recv parameter in the local descriptor and no ch-send parameter in the remote descriptors are received, the IMS-AGW should expect to receive RTP packets containing the indicated number of channels and may use this information when deciding upon the required resources. If no ch-send parameter in the local descriptor and no ch-recv parameter in the remote descriptors are received, the IMS-AGW shall also send RTP packets containing the indicated number of channels. Different number of channels values in the local and remote descriptors is an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.
ch-send (NOTE 1)	The IMS-AGW shall send RTP packets containing the indicated number of channels. Different number of channels in the ch-send parameter in the local descriptor and the ch-recv parameter in the remote descriptors is an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.	The IMS-AGW should expect to receive RTP packets containing the indicated number of channels and may use this information when deciding upon the required resources. Different number of channels in the ch-send parameter in the local descriptor and the ch-recv parameter in the remote descriptors is an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.
ch-recv (NOTE 1)	The IMS-AGW should expect to receive RTP packets containing the indicated number of channels and may use this information when deciding upon the required resources. Different number of channels in the ch-send parameter in the local descriptor and the ch-recv parameter in the remote descriptors is an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.	The IMS-AGW shall send RTP packets containing the indicated number of channels. Different number of channels in the ch-send parameter in the local descriptor and the ch-recv parameter in the remote descriptors is an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.
mode-set (NOTE 4)	For AMR-WB IO mode, the IMS-AGW should expect to receive RTP packets using only the indicated mode-set and may use this information when deciding upon the required resources. The IMS-AGW shall also send RTP packets only using the indicated mode-set. Different mode-set values in the local and remote descriptors are an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.	For AMR-WB IO mode, the IMS-AGW should expect to receive RTP packets using only the indicated mode-set and may use this information when deciding upon the required resources. The IMS-AGW shall also send RTP packets only using the indicated mode-set. Different mode-set values in the local and remote descriptors are an error situation, but it is permissible that this parameter is only supplied in one of those descriptors.
mode-change-period (NOTE 3)	For AMR-WB IO mode, the IMS-AGW should expect to receive packets with this mode-change-period and may use this information when deciding upon the required resources.	For AMR-WB IO mode, the IMS-AGW shall use this mode-change-period when sending packets.
mode-change-capability (NOTE 6)	For AMR-WB IO mode, mode-change-capability with value 2 indicates that the IMS-AGW should expect to be requested to send packets with restricted mode-change-period and may use this information when deciding upon the required resources.	No IMS-AGW handling of this parameter id defined.
mode-change-neighbor (NOTE 3)	The IMS-AGW should expect to receive packets with this mode-change-period and may use this information when deciding upon the required resources.	The IMS-AGW shall use this mode-change-period when sending packets.
max-red (NOTE 5)	The IMS-AGW should expect to receive packets with redundancy up to the indicated max-red value and may use this information when deciding upon the required resources.	The IMS-AGW shall only send packet with redundancy up to the indicated max-red value.
3gpp_mtsi_app_adapt (NOTE 4)	The IMS-AGW should expect to receive RTCP APP packets of the indicated types and may use this information when deciding upon the required resources.	The IMS-AGW may send RTCP APP packets of the indicated types. The IMS-AGW shall not send other RTCP APP packets. If the parameter is not supplied, the IMS-AGW shall not send any RTCP APP packets.
NOTE 1: This MIME parameter of the EVS RTP payload type is defined in 3GPP TS 26.445 [51]. The values and the defaults if a parameter is omitted, as defined in 3GPP TS 26.445 [51] shall apply. NOTE 2: This number of channels are encoded as "encoding parameters" of the SDP "a=rtpmap" attribute defined in IETF RFC 4566 [53]. NOTE 3: This MIME parameter of the EVS RTP payload type relates to AMR-WB IO mode and is defined in IETF RFC 4867 [54]. The values and the defaults if a parameter is omitted, as defined in IETF RFC 4867 [54] shall apply. NOTE 4: This SDP attribute is defined in 3GPP TS 26.114 [21]. It applies to all codecs offered in an SDP media line. However, some values are specific to EVS. NOTE 5: This MIME parameter of the EVS RTP payload type is defined in IETF RFC 4867 [54]. The values and the defaults if a parameter is omitted, as defined in IETF RFC 4867 [54] shall apply. NOTE 6: This MIME parameter of the EVS RTP payload type relates to AMR-WB IO mode and is defined in IETF RFC 4867 [54]. The values and the defaults if a parameter is omitted, as defined in 3GPP TS 26.445 [51], shall apply. NOTE 7: The frame erasure rate indicator for the channel-aware mode has two permissible values (LO, HI) and this indicator has to be initialized to HI, as specified in clause 5.8.4 of 3GPP TS 26.445 [51]. NOTE 8: If both the dtx and the dtx-recv parameter are provided either in the local or in the remote descriptor, both parameters will have the same value within that descriptor.

5.13.4 Handling of the OPUS speech and audio codec for WebRTC

The OPUS speech and audio codec is defined in IETF RFC 6716 [50]. Its RTP payload type is defined in IETF RFC 7587 [56].

The eP-CSCF and the eIMS-AGW should support transcoding to and from the OPUS speech codec. If they do so, the procedures in the present clause apply.

When receiving an SDP offer from the core network, the IMS-ALG may add an OPUS codec payload type (as specified in IETF RFC 7587 [56]) before forwarding the SDP offer towards the served WebRTC UE (denoted as "codec 3" in figure 10.2.5.2 of 3GPP TS 29.162 [20]). If that OPUS payload type is selected in the SDP answer, the IMS-ALG needs to transcode the OPUS codec. Table 5.13.4.1 describes the IMS-ALG handling of the OPUS codec parameters when the IMS-ALG adds an OPUS payload type to the SDP offer, and that OPUS payload type is selected in the SDP answer. In addition, rules for the parameter handling in IETF RFC 7587 [56] shall apply.

Table 5.13.4.1: IMS-ALG handling of OPUS related SDP parameters when the IMS-ALG adds the OPUS payload type to the SDP offer.

Parameter	Handling for OPUS payload type added to the SDP offer to offer transcoding	Handling if offered OPUS payload type is accepted in the SDP answer
maxplaybackrate (NOTE)	Should be set according to IMS-AGW capabilities and sampling rates of expected codecs to transcode with (E.g. other codecs in the received SDP offer).	If parameter is contained in the SDP answer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the answerer in the remote descriptor.
sprop-maxcapturerate (NOTE)	Should be set according to IMS-AGW capabilities and sampling rates of expected codecs to transcode with (E.g. other codecs in the received SDP offer).	If parameter is contained in the SDP answer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the answerer in the remote descriptor.
maxaveragebitrate (NOTE)	Should be set according to IMS-AGW capabilities and sampling rates of expected codecs to transcode with (E.g. other codecs in the received SDP offer), see IETF RFC 7587 [56].	If parameter is contained in the SDP answer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the answerer in the remote descriptor.
stereo (NOTE)	Should be set to 0 or omitted, unless the expected codecs to transcode with (E.g. other codecs in the received SDP offer) support stereo and the IMS-AGW supports stereo transcoding.	If parameter is contained in the SDP answer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the answerer in the remote descriptor.
sprop-stereo (NOTE)	Should be set to 0 or omitted, unless the expected codecs to transcode with (E.g. other codecs in the received SDP offer) support stereo and the IMS-AGW supports stereo transcoding.	If parameter is contained in the SDP answer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the answerer in the remote descriptor.
cbr (NOTE)	Should be set or omitted according to IMS-AGW capabilities and used encryption.	If parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the answerer in the remote descriptor.
useinbandfec (NOTE)	Should be set or omitted according to IMS-AGW capabilities and delay budget.	If parameter is contained in the SDP answer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the answerer in the remote descriptor.
usedtx (NOTE)	Should be set according to IMS-AGW preferences and DTX capabilities of expected codecs to transcode with (E.g. other codecs in the received SDP offer).	If parameter is contained in the SDP answer, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the answerer in the remote descriptor.
NOTE: This MIME parameter of the OPUS RTP payload type is defined in IETF RFC 7587 [56]. It is encapsulated within the SDP "a=fmtp" attribute defined in IETF RFC 4566 [55].

When receiving an SDP offer from the served WebRTC UE that contains an OPUS codec payload type, the IMS-ALG may add other payload types before forwarding the SDP offer (denoted as "codec 3" in figure 10.2.5.2 of 3GPP TS 29.162 [20]). If that added payload type is selected in the SDP answer, the IMS-ALG needs to transcode, and may select to transcode to the OPUS codec. Table 5.13.4.2 describes the IMS-ALG handling of the OPUS codec parameters when the IMS-ALG receives the OPUS payload type in the SDP offer, and selects to transcode between the OPUS codec and some other codec. In addition, rules for the parameter handling in IETF RFC 7587 [56] shall apply.

Table 5.13.4.2: IMS-ALG handling of OPUS related SDP parameters when the IMS-ALG receives the OPUS payload type to the SDP offer and decides to transcode between the OPUS payload type and some other codec.

Parameter	Handling of OPUS payload type parameter received in the SDP offer	OPUS payload type supplied in the SDP answer
maxplaybackrate (NOTE)	If parameter is contained in the SDP offer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	Should be set according to IMS-AGW capabilities and sampling rates of expected codecs to transcode with (E.g. other codecs in the received SDP offer).
sprop-maxcapturerate (NOTE)	If parameter is contained in the SDP offer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	Should be set according to IMS-AGW capabilities and sampling rates of expected codecs to transcode with (E.g. other codecs in the received SDP offer).
maxaveragebitrate (NOTE)	If parameter is contained in the SDP offer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	Should be set according to IMS-AGW capabilities and sampling rates of expected codecs to transcode with (E.g. other codecs in the received SDP offer), see IETF RFC 7587 [56].
stereo (NOTE)	If parameter is contained in the SDP offer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	Should be set to 0 or omitted, unless the expected codecs to transcode with (E.g. other codecs in the received SDP offer) support stereo and the IMS-AGW supports stereo transcoding.
sprop-stereo (NOTE)	If parameter is contained in the SDP offer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	Should be set to 0 or omitted, unless the expected codecs to transcode with (E.g. other codecs in the received SDP offer) support stereo and the IMS-AGW supports stereo transcoding.
cbr (NOTE)	If parameter is contained in the SDP offer, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	Should be set or omitted according to IMS-AGW capabilities and used encryption.
useinbandfec (NOTE)	If parameter is contained in the SDP offer, the IMS-ALG should forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	Should be set or omitted according to IMS-AGW capabilities and delay budget.
usedtx (NOTE)	If parameter is contained in the SDP offer, the IMS-ALG shall forward this parameter to the IMS-AGW for the termination towards the offerer in the remote descriptor.	Should be set according to IMS-AGW preferences and DTX capabilities of expected codecs to transcode with (E.g. other codecs in the received SDP offer).
NOTE 1: This MIME parameter of the OPUS RTP payload type is defined in IETF RFC 7587 [56]. It is encapsulated within the SDP "a=fmtp" attribute defined in IETF RFC 4566 [55].

Table 5.13.4.3 describes the IMS-AGW handling of the OPUS codec parameters. The IMS-AGW should support transcoding of OPUS with at least the bandwidths (sampling rates) which are supported by codec the IMS-AGW is capable to transcode OPUS to/from (e.g. NB for AMR, and WB for AMR-WB).

Table 15.3.4.3: IMS-AGW handling of OPUS codec parameters.

Parameter	Handling in local descriptor	Handling in remote descriptor
maxplaybackrate (NOTE)	The IMS-AGW should expect to receive RTP packets with sampling rates up to the indicated maximum and may use this information when deciding upon the required resources.	The IMS-AGW should send RTP packets with the indicated sampling rate.
sprop-maxcapturerate (NOTE)	No IMS-AGW handling of this parameter is defined.	The IMS-AGW should expect to receive RTP packets with sampling rates up to the indicated maximum and may use this information when deciding upon the required resources.
maxaveragebitrate (NOTE)	The IMS-AGW should expect to receive RTP packets with average bit rates up to the indicated maximum and may use this information when deciding upon the required resources.	The IMS-AGW shall send RTP packets with average bit rates up to the indicated maximum.
stereo (NOTE)	The IMS-AGW should expect to receive RTP packets containing the indicated stereo mode and may use this information when deciding upon the required resources.	The IMS-AGW should send RTP packets containing the indicated stereo mode.
sprop-stereo (NOTE)	No IMS-AGW handling of this parameter is defined.	The IMS-AGW should expect to receive RTP packets containing the indicated stereo mode and may use this information when deciding upon the required resources.
cbr (NOTE)	The IMS-AGW should expect to receive RTP packets containing the indicated constant bit rate mode and may use this information when deciding upon the required resources.	The IMS-AGW should send RTP packets containing the indicated constant bit rate mode.
useinbandfec (NOTE)	The IMS-AGW should expect to receive RTP packets containing the indicated forward error correction mode and may use this information when deciding upon the required resources.	The IMS-AGW should send RTP packets containing the indicated forward error correction mode.
usedtx (NOTE)	The IMS-AGW should expect to receive RTP packets containing the indicated DTX mode and may use this information when deciding upon the required resources.	The IMS-AGW should send RTP packets using the indicated DTX mode.
NOTE 1: This MIME parameter of the OPUS RTP payload type is defined in IETF RFC 7587 [56]. The default value if a parameter is omitted, as defined in IETF RFC 7587 [56], shall apply.

5.14 Multimedia Priority Service (MPS) Support

The Multimedia Priority Service (MPS) is specified in 3GPP TS 22.153 [22]. The IMS-ALG and IMS-AGW may support the priority treatment of a call/session identified as an MPS call/session. If MPS is supported, the following functional requirements apply:

– Upon receipt of the MPS priority information in the call control signalling:

– The IMS-ALG shall recognise the call/session as having priority.

– The IMS-ALG shall send the priority information for a context to the IMS-AGW to enable the priority treatment described below related to the IMS-AGW.

– The IMS-ALG shall apply priority handling to H.248 transactions related to priority calls/sessions when network resources are congested , e.g., preferential treatment in any queues or buffers.

– The IMS-ALG may send the updated priority information and, if DiffServ is used, provision a suitable DSCP marking for the updated MPS priority level to the IMS-AGW if it needs to change the priority information previously communicated to the IMS-AGW for an MPS call/session.

– If the H.248 control association utilises a transport with the possibility for prioritisation, the IMS-ALG may apply priority using the appropriate prioritisation procedures.

– If the MPS Priority service requires a specific MPS DSCP setting the IMS-ALG shall configure the IMS-AGW to apply a specific MPS DSCP marking to the user data transport packets to indicate that the packets are of a higher priority than those for normal calls.

– If the IMS-AGW receives an indication to apply a specific MPS DSCP marking to the user data transport packets, it shall apply this DSCP marking to the IP headers.

NOTE 1: Support of Diffserv procedures by the IMS-AGW assumes an operator uses Diffserv for prioritising user plane traffic related to an MPS call/session.

– When the IMS-ALG marks a Context with priority information, the IMS-AGW may use the priority information for selecting resources for the media and signaling transport with priority. The following actions may be taken by the IMS-AGW if it has reached a congested state:

i) seize priority reserved resources; or

ii) if resources are congested, indicate that in aCommand Response error code.

NOTE 2: The Priority information can be used to derive Layer 2 QoS marking and trigger priority identification and priority treatment for other QoS technologies than Diffserv.

5.15 Coordination of Video Orientation

The IMS-ALG and the IMS-AGW may support the Coordination of Video Orientation (CVO) as defined in 3GPP TS 26.114 [21].

If the IMS-ALG receives an SDP body containing "a=extmap" attribute(s), as defined in IETF RFC 5285 [23], and the "a=extmap" attribute(s) contain CVO URN(s) (i.e. the CVO URN for a 2 bit granularity of rotation and/or the CVO URN for a higher granularity of rotation) as defined in 3GPP TS 26.114 [21], then:

a) if the IMS-ALG and the IMS-AGW support the CVO feature:

– the IMS-ALG shall include the "extended RTP header for CVO" information element when seizing resources in the IMS-AGW to indicate the IMS-AGW that it shall allow the RTP header extension for CVO to pass; and

Editor´s Note: It is ffs if the IMS-ALG needs to include the "extended RTP header for CVO" information element when seizing terminations of a media agnostic IMS-AGW, or if a media agnostic IMS-AGW always passes any RTP header extension.

– the IMS-ALG shall forward within SIP signalling, the SDP body received from the preceding node with unmodified "a=extmap" attribute(s) to the succeeding node; or

b) if the IMS-AGW does not support the CVO feature, the IMS-ALG shall forward within SIP signalling, the SDP body received from the preceding node without any "a=extmap" attributes to the succeeding node.

NOTE 1: The UE supporting the CVO feature will not send the extended RTP headers for CVO if the UE did not receive any SDP body with the CVO related "a=extmap" attribute.

If the IMS-AGW supports the CVO feature and has been instructed to pass on the extended RTP header for CVO as described above for both incoming and outgoing terminations then:

– if the IMS AGW does not apply video transcoding, it shall pass any received RTP CVO header extension to succeeding RTP streams; or

– if the IMS-AGW applies video transcoding, it shall keep the video orientation unchanged during the transcoding and copy the received RTP CVO header extension to the succeeding outgoing RTP stream(s) after transcoding the associated group of packets.

NOTE 2: IETF RFC 5285 [23] provides a framework for header extensions and can also be used for non-CVO related purposes. It is an implementation decision of the IMS-AGW if it only passes CVO related RTP header extensions, or if it passes any RTP header extension when being instructed with the "extended RTP header for CVO" information element.

NOTE 3: The behaviour of the IMS-AGW when being instructed with an "extended RTP header for CVO" information element only at one termination is an implementation decision.

NOTE 4: Unknown IETF RFC 5285 [23] RTP header extensions are ignored by the destination RTP end system.

5.16 Generic image attributes

The IMS-ALG and the IMS-AGW may support a media-level SDP image attribute "a=imageattr" defined in IETF RFC 6236 [24] to negotiate the image size for sending and receiving video as required by 3GPP TS 26.114 [21].

NOTE: The image attribute may be used within the SDP capability negotiation framework and its use is then specified using the "a=acap" parameter.

If the IMS-ALG:

– supports the negotiation of the image size;

– receives an SDP body containing the image attribute(s) "imageattr" defined in IETF RFC 6236 [24]; and

– does not support or does not apply the video transcoding procedure defined in clause 5.13;

the IMS-ALG shall forward the SDP body with unmodified image attribute(s).

If the IMS-ALG and the IMS-AGW support the ATCF/ATGW functions then during the access transfer procedures the IMS-ALG may apply the procedure described in clause 6.2.14.6 to negotiate and adjust the image size for sending and receiving video of the session.

5.17 TCP bearer connection control

5.17.1 Stateless TCP handling

An IMS‑ALG and IMS‑AGW that supports TCP as transport protocol (see IETF RFC 793 [29] and IETF RFC 4145 [30]) shall support the following procedures.

NOTE 1: It is assumed that pre-Release 12 IMS‑ALGs and IMS‑AGWs also apply these procedures.

When receiving an SDP offer or answer containing a media line for a new TCP based media stream (e.g. with "TCP", "TCP/MSRP" as transport protocol), the IMS‑ALG:

– shall indicate "TCP" (for application-agnostic interworking) or "TCP/MSRP" (for application-aware MSRP interworking) as transport protocol to the IMS‑AGW;

– shall indicate the TCP port numbers received in the SDP from the remote peer as destination port in the remote descriptor at the termination towards the SDP sender;

– shall request the IMS‑AGW to allocate a TCP port number at the destination towards the SDP receiver;

– shall replace the TCP port in the received SDP with the TCP port number allocated by the IMS‑AGW and forward the SDP; and

– shall indicate to the IMS‑AGW to perform TCP stateless handling by not including the TCP session setup direction attribute at the interconnected terminations in the same context.

An IMS‑AGW receiving an indication of "TCP", or "TCP/MSRP" as transport protocol, but no indication to perform TCP state-aware handling (via information about the directionality of the TCP session setup):

– shall send a TCP SYN when receiving a TCP SYN at the interconnected termination in the same context;

– shall forward received TCP payload; and

– shall use its own port number as TCP source port numbers and the remote port number received from the IMS‑ALG as TCP destination port numbers and calculate a new TCP checksum for all TCP packets it sends.

NOTE 2: This mode of operation corresponds to the "TCP Relay" mode in ITU-T Recommendation H.248.84 [38].

5.17.2 State‑aware TCP handling

5.17.2.1 General

An IMS‑ALG and IMS‑AGW that supports TCP as transport protocol (see IETF RFC 793 [29] and IETF RFC 4145 [30]) may support the procedures specified in clause 5.17.2 for state-aware TCP handling.

NOTE 1: State‑aware TCP handling enables modifications of TCP payloads by the IMS‑AGW such as changing the size of the payload and inserting extra protocol layers, e.g. for e2ae media security.

An IMS‑ALG and IMS‑AGW that supports state‑aware TCP handling shall support the procedures specified in clause 5.17.2.2 and may additionally support the procedures specified in clause 5.17.2.3.

NOTE 2: The procedures in clause 5.17.2.3 enable TCP connections between two peers behind remote (far-end) NATs without any other intermediate server capable of acting as a TCP B2BUA (such as a messaging server). However, they are not possible if e2e security is applied for MSRP based media.

5.17.2.2 State‑aware TCP handling without support of modifying the TCP setup direction

When the IMS‑ALG receives an SDP offer containing a media line for a new TCP based media stream (e.g. with "TCP", "TCP/MSRP" as transport protocol), for that TCP based media stream the IMS‑ALG:

– if no media security is applied, shall indicate "TCP" (for application-agnostic interworking) or "TCP/MSRP" (for application-aware MSRP interworking) as transport protocol to the IMS‑AGW;

– if media security is applied, shall indicate a transport protocol according to clause 5.11 to the IMS‑AGW;

– shall request the IMS‑AGW to allocate a TCP port at the destination towards the SDP answerer;

– shall request the IMS‑AGW to allocate a TCP port at the destination towards the SDP offerer;

– shall indicate the TCP port numbers received in the SDP offer as destination in the remote descriptor at the termination towards the SDP offerer;

– shall indicate to the IMS‑AGW to perform TCP state-aware handling (by indicating the "actpass" TCP session setup direction at both interconnected terminations in the same context in the local descriptor);

– if supported by the IMS‑AGW, may indicate to the IMS‑AGW for a given termination to use an incoming TCP connection establishment request (TCP SYN) at that termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context;

– if supported by the IMS‑AGW, may indicate to the IMS‑AGW to discard incoming TCP connection establishment requests; and

– shall replace the TCP port in the received SDP offer with the TCP port number allocated by the IMS‑AGW at the termination towards the SDP answerer, shall maintain a received "a=setup:active" or "a=setup:passsive" SDP attribute (see IETF RFC 4145 [30]) in the SDP offer without modification, and shall forward the SDP offer.

When the IMS‑ALG then receives the SDP answer containing a media line for a new TCP based media stream, for that TCP based media stream the IMS‑ALG:

– shall indicate the TCP port numbers received in the SDP answer as destination in the remote descriptor at the termination towards the SDP answerer;

– if the IMS‑ALG did not indicate to the IMS‑AGW to use the incoming TCP connection establishment request (TCP SYN) at one termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context,

– if the SDP answer contains an "a=setup:active" SDP attribute (see IETF RFC 4145 [30]), shall indicate to the IMS‑AGW to start a TCP connection establishment at the termination towards the SDP offerer; and

– if the SDP answer contains an "a=setup:passive" SDP attribute, shall indicate to the IMS‑AGW to start a TCP connection establishment at the termination towards the SDP answerer;

NOTE 1: Clients only supporting MSRP according to IETF RFC 4975 [25] will not use the SDP "a=setup" attribute, but will assign the TCP client role to the SDP offerer. However, in 3GPP (Release 8 onwards), OMA and GSMA the support of IETF RFC 6135 [45] is mandated, and the "a=setup" attribute will thus be used.

– if the IMS‑ALG previously indicated to the IMS‑AGW to discard incoming TCP connection establishment requests, shall indicate to the IMS‑AGW to process incoming TCP connection establishment requests; and

– shall replace the destination TCP port in the received SDP answer with the TCP port number allocated by the IMS‑AGW at the termination towards the SDP offerer, shall maintain the received "a=setup" SDP attribute (RFC 4145 [30]) in the SDP answer without modification, and shall forward the SDP answer.

An IMS‑AGW receiving an indication of "TCP", or "TCP/MSRP" as transport protocol and an indication to perform TCP state-aware handling (via information about the directionality of the TCP session setup):

– if the IMS‑ALG indicated to start a TCP connection establishment at a given termination, shall start the TCP connection establishment at that TCP termination by sending a TCP SYN;

– if the IMS‑ALG indicated to discard incoming TCP connection establishment requests, shall discard any incoming TCP connection establishment requests (support optional for the IMS‑AGW);

– if

a) the IMS‑ALG indicated to use the incoming TCP connection establishment request (TCP SYN) at one termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context, and

b) the IMS‑ALG did not indicate to discard incoming TCP connection establishment requests,

shall send a TCP SYN when receiving a TCP SYN at the interconnected termination in the same context (support optional for the IMS‑AGW);

– if

a) the IMS‑ALG did not indicate to use the incoming TCP connection establishment request (TCP SYN) at one termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context, and

b) the IMS‑ALG did not indicate to discard incoming TCP connection establishment requests, and

c) the IMS‑ALG already configured the remote IP address and port or requested latching,

shall answer any received TCP SYN at a given termination with appropriate messages according to TCP procedures;

– shall forward received TCP payload, performing any required modifications on the TCP payload according to procedures in other parts of this specification; and

– shall use its own port number as TCP source port and the remote port number indicated by the IMS‑ALG as TCP destination port numbers and shall calculate a new TCP checksum for all TCP packets it sends.

NOTE 2: This mode of operation corresponds to the "TCP Proxy" mode in ITU-T Recommendation H.248.84 [38].

5.17.2.3 State‑aware TCP handling with support of modifying the TCP setup direction

The IMS‑ALG and IMS‑AGW shall perform the same procedures as in clause 5.17.2.2 with modification according to the present clause.

When the IMS‑ALG receives an SDP offer containing a media line for a new TCP based media stream (e.g. with "TCP", "TCP/MSRP" as transport protocol), for that TCP based media stream the IMS‑ALG:

– if an "a=setup:active" SDP attribute (see IETF RFC 4145 [30]) is received in an SDP offer towards a served UE that is possibly behind a remote NAT, the IMS‑ALG

– should replace this attribute with a "a=setup:actpass" or "a=setup:passive" SDP attribute; and

– shall then not indicate to the IMS‑AGW to use the incoming TCP connection establishment request (TCP SYN) at the termination towards the offerer as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context towards the answerer;

– if an "a=setup:active" SDP attribute (see IETF RFC 4145 [30]) is received in an SDP offer from a served UE, the IMS‑ALG

– may replace this attribute with a "a=setup:actpass" SDP attribute; and

– shall then not indicate to the IMS‑AGW to use the incoming TCP connection establishment request (TCP SYN) at the termination towards the answerer as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context towards the offerer;

– shall indicate to the IMS‑AGW to perform TCP state-aware handling, either by indicating the "actpass" TCP session setup direction at both interconnected terminations in the same context in the local descriptors, or by indicating the "passive" TCP session setup direction at both interconnected terminations in the same context.

When the IMS‑ALG then receives the SDP answer containing a media line for a new TCP based media stream, for that TCP based media stream the IMS‑ALG:

– if

a) the IMS‑ALG received an "a=setup:active" SDP attribute in the SDP offer, and

b) the SDP answer containes an "a=setup:active" SDP attribute,

then

– if the IMS‑ALG previously indicated "actpass" TCP session setup direction at both interconnected terminations to the IMS‑AGW, shall indicate to the IMS‑AGW the "passive" TCP session setup direction at both interconnected terminations in the same context in the local descriptors, and

– shall replace the "a=setup:active" SDP attribute in the SDP answer with an "a=setup:passive" SDP attribute before forwarding the answer.

– if

a) the IMS‑ALG received an "a=setup:active" SDP attribute in the SDP offer, and

b) the SDP answer containes an "a=setup:passive" SDP attribute,

then

– if the IMS‑ALG previously indicated "passive" TCP session setup direction at both interconnected terminations to the IMS‑AGW, shall indicate to the IMS‑AGW the "actpass" TCP session setup direction at both interconnected terminations in the same context in the local descriptors, and

– shall retain the "a=setup:passive" SDP attribute in the forwarded SDP answer;

– if the sent SDP answer towards the offerer contains an "a=setup:active" SDP attribute (RFC 4145 [30]), indicate to the IMS‑AGW to start a TCP connection establishment at the termination towards the SDP offerer; and

– if the received SDP answer contains an "a=setup:passive" SDP attribute, indicate to the IMS‑AGW to start a TCP connection establishment at the termination towards the SDP answerer.

When the IMS‑ALG indicated a "passive" TCP setup direction for a termination, the IMS-AGW shall wait for an incoming TCP connection establishment at that termination and shall not start a TCP connection establishment on its own.

NOTE 2: If the "passive" TCP session setup direction has been indicated to the IMS‑AGW at both interconnected terminations, the mode of operation corresponds to the "TCP Merge" mode in ITU-T Recommendation H.248.84 [38]. If the "actpass" TCP session setup direction has been indicated to the IMS‑AGW at both interconnected terminations, the mode of operation corresponds to the "TCP Proxy" mode in ITU-T Recommendation H.248.84 [38].

5.18 Interactive Connectivity Establishment (ICE)

5.18.1 General

The IMS-ALG and the IMS-AGW may support ICE functionality as specified in IETF RFC 8445 [82] and IETF RFC 8839 [83], and 3GPP TS 24.229 [11] to support a UE residing behind a remote NAT. The present clause describes the requirements for P-CSCF (IMS-ALG) and IMS-AGW when the ICE procedures are supported.

Support of full ICE functionality is optional, but if ICE is supported, the IMS-ALG and IMS-AGW shall at least support ICE lite as specified in IETF RFC 8445 [82].

An IMS-ALG and IMS-AGW supporting ICE lite may in addition support ICE for TCP according to IETF RFC 6544 [57].

NOTE 1: ICE for TCP can be used to offer an alternative transport for media streams with default UDP transport to enable a traversal of UDP-blocking NATs or firewalls. In the present release, the support of ICE for TCP is restricted to media streams with default UDP transport, and to ICE lite.

The IMS-ALG and IMS-AGW shall only use host candidates as local ICE candidates.

NOTE 2: IMS-ALG and IMS-AGW are not located behind a NAT (from perspective of the ICE deployment model according to figure 1 in IETF RFC 8445 [82]).

The IMS-ALG with IMS-AGW inserted on the media plane shall perform separate ICE negotiation and procedures with the offerer and the answerer and ICE may be applied independently at either side. Furthermore, the IMS-ALG may be configured to apply ICE procedures only towards the access network side.

When the P-CSCF (IMS-ALG) detects no ICE parameters in the received SDP, it shall not configure the IMS-AGW to apply any ICE and STUN related procedures toward the call leg from where the SDP has been received, and if applicable may apply the remote NAT traversal using latching according to clause 5.4.

Any IMS-AGW supporting ICE shall advertise its support of incoming STUN continuity check procedures. An IMS-AGW supporting full ICE procedures shall in addition advertise its support for originating STUN connectivity check procedures.

If the IMS-AGW does not indicate the support of STUN procedures, or if the IMS-ALG is configured not to apply ICE toward a call leg, the IMS-ALG:

– shall not configure the IMS-AGW to apply STUN procedures;

– shall remove any received SDP candidate information from the SDP it forwards; and

– may apply remote NAT traversal using latching according to clause 5.4.

5.18.2 ICE lite

If the IMS-ALG is configured to use ICE lite, or supports only ICE lite, or controls an IMS-AGW that only support ICE lite, the procedures in the present clause apply.

If the IMS-ALG receives an initial SDP offer with ICE candidate information but no "a=ice-lite" attribute, the IMS-ALG:

– shall not forward the received candidate information in the SDP it sends towards the answerer;

– shall request the IMS-AGW for each media line with UDP as default transport where it decides to use ICE to reserve an ICE host candidate and provide its address information and a related ICE user name fragment and password;

NOTE 1: Requesting only one host candidate per m-line prevents that the IMS-ALG will receive "a=remote-candidates" SDP attributes in a subsequent SDP. Requesting separate ufrag and password for each media line simplifies H.248 encoding.

– may request the IMS-AGW for each media line with UDP as default transport where it decides to use ICE to reserve an additional passive TCP ICE host candidate and provide its address information and a related ICE user name fragment and password;

– shall configure the IMS-AGW to act as STUN server at the host candidate address, i.e. to answer STUN connectivity checks;

– may provide received remote ICE candidates and the received related ICE user name fragment and password to the IMS-AGW;

– if an "a=ice-options" attribute with the value "ice2" was present in the received SDP offer, shall include the "a=ice-options" attribute with the value "ice2" in the SDP answer it forwards;

– shall include the host candidate and related ICE user name fragment and password received from the IMS-AGW in the SDP answer it forwards;

– shall include the "a=ice-lite" attribute in the SDP answer it forwards; and

– shall not apply the remote NAT traversal using latching according to clause 5.4.

If the IMS-ALG receives SDP offer with ICE candidate information and an "a=ice-lite" attribute, the IMS-ALG shall not apply ICE towards that call leg and not include any ICE related SDP attributes in the SDP answer.

NOTE 2: This avoids that the ICE lite peer needs to send extra SDP offers to complete ICE procedures.

If the IMS-ALG sends an SDP offer (or forwards a received SDP offer) towards a call leg where ICE is to be applied, the IMS-ALG:

– shall request the IMS-AGW to reserve a host candidate for each media line with UDP as default transport where it decides to use ICE and provide its address information, user name fragment and password;

– shall configure the IMS-AGW to act as STUN server at the host candidate address, i.e. to answer STUN connectivity checks;

– shall include the "a=ice-options" attribute with the value "ice2" in the SDP offer;

– shall include the host candidate provided by the IMS-AGW and related ICE user name fragment and password in the SDP offer; and

– shall include the "a=ice-lite" attribute in the SDP offer.

If the IMS-ALG then receives an SDP answer with candidate information from the call leg where ICE is to be applied, the IMS-ALG:

– shall not forward the received candidate information in the SDP it sends towards the offerer;

– may provide received remote ICE candidates and the received related ICE user name fragment and password to the IMS-AGW; and

– shall not apply the remote NAT traversal using latching according to clause 5.4.

After the initial SDP offer-answer exchange, the IMS-ALG can receive a new offer from the peer that includes updated address and port information in the SDP "c=" line, "m=" line, or "a=rtcp" line SDP attributes. If the ICE user name fragment and password in the SDP offer differ from the ones received in the previous SDP (i.e. the peer restarts ICE), the IMS-ALG shall apply the same procedures as for the initial SDP offer.

When receiving a request for a host candidate for a media line, the IMS-AGW shall allocate one host candidate for that media line and send it to the IMS-ALG within the reply. The IP address and port shall be the same as indicated separately as Local IP Resources. The IMS-AGW shall also indicate that it supports ICE lite in the reply.

For a passive TCP ICE host candidate, the IMS-AGW shall be prepared to receive and answer the TCP connection establishment requests.

NOTE 3: The TCP connection control procedures in clause 5.17 do not apply to TCP host candidates.

When receiving a request for an ICE user name fragment and password, the IMS-AGW shall generate an ICE user name fragment and password and send it to the IMS-ALG within the reply. The IMS-AGW shall store the password and user name fragment to be able to authenticate incoming STUN binding request according to clause 7.3 of IETF RFC 8445 [82].

When receiving a request to act as STUN server, the IMS-AGW shall be prepared to answer STUN binding request according to clause 7.3 of IETF RFC 8445 [82]. Once a STUN binding request with the "USE-CANDIDATE" flag has been received, the IMS-AGW may send media towards the source of the binding request.

5.18.3 Full ICE

If the IMS-ALG supports and is configured to use full ICE, and controls an IMS-AGW that supports full ICE, the procedures in the present clause apply.

If the IMS-ALG receives an initial SDP offer with ICE candidate information, the IMS-ALG:

– shall not forward the received candidate information in the SDP it sends towards the answerer;

– shall request the IMS-AGW for each media line where it decides to use ICE to reserve an ICE host candidate and provide its address information and a related ICE user name fragment and password;

NOTE: Requesting only one host candidate per m-line prevents that the IMS-ALG will receive "a=remote-candidates" SDP attributes in a subsequent SDP. Requesting separate ufrag and password for each media line simplifies H.248 encoding.

– shall request the IMS-AGW to provide the desired pacing value for connectivity checks (Ta timer value);

– shall configure the IMS-AGW to act as STUN server at the host candidate address, i.e. to answer STUN connectivity checks;

– shall provide received remote ICE candidates and the received related ICE user name fragment and password to the IMS-AGW;

– shall provide the remote pacing value to the IMS-AGW as follows:

a) if the "a=ice-pacing" attribute was present in the received SDP answer, the received pacing value; or

b) otherwise the default pacing value of 50 ms;

– if an "a=ice-options" attribute with the value "ice2" was present in the received SDP offer, shall include the "a=ice-options" attribute with the value "ice2" in the SDP answer it forwards;

– shall include the "a=ice-pacing" attribute with the pacing value provided by the IMS-AGW in the SDP answer it forwards;

– shall include the host candidate and related ICE user name fragment and password received from the IMS-AGW in the SDP answer it forwards;

– shall determine the role of IMS-ALG in ICE (controlling or controlled) according to clause 6.1.1 of IETF RFC 8445 [82];

– shall configure the IMS-AGW to perform connectivity checks in accordance with the determined ICE role;

– shall configure the IMS-AGW to report connectivity check results;

– shall configure the IMS-AGW to report a new peer reflexive candidate if discovered during the connectivity check; and

– shall not apply the remote NAT traversal using latching according to clause 5.4.

If the IMS-ALG sends an SDP offer (or forwards a received SDP offer) towards a call leg where ICE is to be applied, the IMS-ALG:

– shall request the IMS-AGW to reserve a host candidate for each media line were it decides to use ICE and provide its address information, ICE user name fragment and password;

– shall request the IMS-AGW to provide the pacing value for connectivity checks;

– shall configure the IMS-AGW to act as STUN server at the host candidate address, i.e. to answer STUN connectivity checks; and

– shall include the "a=ice-options" attribute with the value "ice2" in the SDP offer it sends;

– shall include the "a=ice-pacing" attribute with the pacing value provided by the IMS-AGW in the SDP offer it sends; and

– shall include the host candidate provided by the IMS-AGW and related ICE user name fragment and password in the SDP offer it sends.

If the IMS-ALG then receives an SDP answer with candidate information from the call leg where ICE is to be applied, the IMS-ALG:

– shall not forward the received candidate information in the SDP it sends towards the offerer;

– shall provide received remote ICE candidates and the received related ICE user name fragment and password to the IMS-AGW;

– shall provide the remote pacing value to the IMS-AGW as follows:

a) if the "a=ice-pacing" attribute was present in the received SDP answer, the received pacing value; or

b) otherwise the default pacing value of 50 ms;

– shall determine the role of IMS-ALG in ICE (controlling or controlled) according to clause 6.1.1 of IETF RFC 8445 [82];

– shall configure the IMS-AGW to perform connectivity checks in accordance with the determined ICE role;

– shall configure the IMS-AGW to report connectivity check results;

– shall configure the IMS-AGW to report a new peer reflexive candidate if discovered during the connectivity check; and

– shall not apply the remote NAT traversal using latching according to clause 5.4.

When the IMS-ALG is informed by the IMS-AGW about new peer reflexive candidate(s) discovered by the connectivity checks, it shall configure the IMS-AGW to perform additional connectivity checks for those candidates.

When the IMS-ALG is informed by the IMS-AGW about successful candidate pairs determined by the connectivity checks, the IMS-ALG shall send a new SDP offer to its peer with contents according to clause 4.4.1 of IETF RFC 8839 [83] if it has the controlling role and the highest-priority candidate pair differs from the default candidates in previous SDP.

When receiving a request to provide a desired pacing value for connectivity checks (Ta timer value), the IMS-AGW shall calculate Ta timer value based on the characteristics of the associated data or shall use the default value of 50 ms and provide it as desired Ta timer value. The IMS-AGW shall compare the own desired Ta timer value with the Ta timer value provided by the IMS-ALG and shall use the higher value for connectivity checks (as specified in IETF RFC 8445 [82]).

When receiving a request to perform connectivity checks and to report connectivity check results, the IMS AGW:

– shall compute ICE candidate pairs according to clause 6.1.2 of IETF RFC 8445 [82];

– shall schedule checks for the ICE candidate pairs according to clause 6.1.4 of IETF RFC 8445 [82];

– shall send STUN connectivity checks for the scheduled checks according to clause 7.2 of IETF RFC 8445 [82];

– shall inform the IMS-ALG about successful candidate pairs determined by the connectivity checks;

– shall inform the IMS-ALG about new peer reflexive candidate(s) discovered by the connectivity checks; and

– should send media using the highest priority candidate pair for which connectivity checks have been completed.

5.18.4 STUN consent freshness for WebRTC

The eIMS-AGW, which implements ICE, shall support the STUN consent freshness test defined in IETF RFC 7675 [49].

If the eP-CSCF supports and is configured to use full ICE, and controls an eIMS-AGW that supports full ICE, to initiate the STUN consent freshness procedures, the eP-CSCF shall request the eIMS-AGW to perform periodic STUN consent tests towards the WIC (WebRTC IMS Client). On receipt of requesting STUN consent test signal, the eIMS-AGW shall start sending STUN binding requests in order to verify consent, based on the interval value indicated by the eP-CSCF, after the tansport address has been selected via the ICE-related connectivity check.

If the eP-CSCF is configured to use ICE lite, or supports only ICE lite, or controls an IMS-AGW that only support ICE lite, the eIMS-AGW shall not send STUN consent request checks. Instead, the IMS-AGW shall act as STUN server and only respond to incoming STUN binding requests received from the WIC (WebRTC IMS Client).

If STUN consent expires on a given transport address, the eIMS-AGW shall stop forwarding media on that transport address, and inform the eP-CSCF about the failure. In addition, the eIMS-AGW shall stop sending STUN consent request checks on the transport address. Once upon an indicated test failure, the eP-CSCF may request for appropriate action related to the H.248 stream, such as the removal of the H.248 stream.

5.19 MSRP handling

5.19.1 General

The IMS-ALG and IMS-AGW may support MSRP handling. If they support MSRP handling, they shall apply the procedures as specified in the present clause 5.19.

For WebRTC terminations, MSRP is transferred over data channels. For WebRTC terminations the procedures in the present clause 5.19 shall apply with the modifications described in clause 5.19.6.

The IMS-AGW shall support application-agnostic MSRP handling.

NOTE 1: Application-agnostic MSRP handling suffices when IETF RFC 6714 [26] or IETF draft-ietf-simple-msrp-sessmatch is supported by both ends (e.g. between Rel-8 onwards IMS UEs) and no MSRP relays are used.

NOTE 2: The expired IETF draft-ietf-simple-msrp-sessmatch modifies the session matching procedure defined by IETF RFC 4975 [25]. A peer applying IETF draft-ietf-simple-msrp-sessmatch will only compare the session-id part of the first MSRP URI in the SDP "a=path" attribute with the session-id part of the first MSRP URI in the "To-Path" header field of the received MSRP packets. This draft is still used by OMA and GSMA as an alternative option to IETF RFC 6714 [26].

The IMS-AGW may in addition support application-aware MSRP interworking, as described in clause 5.19.5..

NOTE 3: Application-aware MSRP interworking enables direct communication:

– between an MSRP client applying IETF RFC 6714 [26] and an MSRP client applying IETF RFC 4975 [25] without extensions by either IETF RFC 6714 [25] or IETF draft-ietf-simple-msrp-sessmatch.

– between an MSRP client applying IETF draft-ietf-simple-msrp-sessmatch and an MSRP client applying IETF RFC 4975 [25] without extensions by either IETF RFC 6714 [26] or IETF draft-ietf-simple-msrp-sessmatch.

– between an MSRP client applying IETF RFC 6714 [26] and an MSRP client applying IETF draft-ietf-simple-msrp-sessmatch.

– between two MSRP clients applying IETF RFC 4975 [25] without extensions by either IETF RFC 6714 [26] or IETF draft-ietf-simple-msrp-sessmatch.

However, to address these scenarios, application aware MSRP interworking can also be applied in other network elements than the IMS-ALG and IMS-AGW, for instance in an CPM Participating Function or CPM Interworking Function as defined in OMA-TS-CPM_Conversation_Function-V2 [46].

NOTE 4: MSRP relays external to the IMS-AGW are not supported in the present release.

The IMS-ALG procedures depend on whether the IMS-AGW applies application-agnostic MSRP interworking or application-aware MSRP interworking, and on the MSRP extensions applied on the interconnected call legs. The support of related procedures in clauses 5.19.2 to 5.19.4 below are all optional, but the IMS-ALG shall support at least one of them.

However the procedures in clauses 5.19.4 and 5.19.5 shall not be applied for media with e2e media security.

Table 5.19.1-1: Behaviour of MSRP clients and related IMS-ALG and IMS-AGW procedures for MSRP with different extensions.

IETF document:	MSRP client takes destination address for TCP connection setup from	Session matching at MSRP client between SDP path and "To-Path" in MSRP messages includes address information	IMS-AGW needs to insert own address into "To‑Path" in MSRP messages	IMS-ALG needs to modify SDP path attribute	Support of extension is negotiated
IETF RFC 4975 [25]	SDP MSRP path attribute	Yes	Yes	Yes	–
Expired draft-ietf-simple-msrp-sessmatch	SDP MSRP path attribute	No	No	Yes	No
IETF RFC 6714 [26]	SDP c-line and m-line	Yes	No (Yes if fallback to IETF RFC 4975 [6] occurs and is supported)	No	Yes, via SDP CEMA attribute

5.19.2 IMS-ALG procedures to support IETF RFC 6714 with application agnostic MSRP handling by the IMS-AGW

A peer applying IETF RFC 6714 [26] will include the "a=msrp-cema" SDP attribute in the first SDP offer it sends.

If the "a=msrp-cema" SDP attribute is contained in an SDP offer, the IMS-ALG:

– shall ensure that the IMS-AGW performs application agnostic MSRP handling by not configuring the IMS-AGW to apply application-aware MSRP interworking;

– shall indicate "TCP" or "TCP/TLS" (if e2ae media security is applied) as transport protocol to the IMS‑AGW;

– shall forward the "a=path" attribute and the "a=msrp-cema" SDP attribute in the SDP offer without modification; and

– shall forward the "a=path" SDP attribute in the corresponding SDP answer without modification (even if the "a=msrp-cema" SDP attribute is not contained in the answer).

NOTE: If the "a=msrp-cema" SDP attribute is not contained in the SDP answer and the "a=path" SDP attribute is not modified, the offerer will discover a mismatch and send a new SDP offer without the "a=msrp-cema" SDP attribute according to IETF RFC 6714 [26] procedures.

If the "a=msrp-cema" SDP attribute is not contained in an SDP offer, the IMS ALG shall either apply the procedures in clause 5.19.3 or clause 5.19.4 (if supported).

5.19.3 IMS-ALG procedures to support IETF draft-ietf-simple-msrp-sessmatch with application agnostic MSRP handling by the IMS-AGW

A peer applying the expired IETF draft-ietf-simple-msrp-sessmatch will not include the "a=msrp-cema" SDP attribute in the SDP it sends, and will only compare the session-id part of the first MSRP URI in the SDP "a=path" attribute with the session-id part of the first MSRP URI in the "To-Path" header field of the first received MSRP packet.

If the "a=msrp-cema" SDP attribute is not contained in an SDP offer, the IMS-ALG:

– shall ensure that the IMS-AGW performs application agnostic MSRP handling by not configuring the IMS-AGW to apply application-aware MSRP interworking;

– shall indicate "TCP" or "TCP/TLS" (if e2ae media security is applied) as transport protocol to the IMS‑AGW; and

– shall replace the IP address and TCP port in the only entry of the "a=path" SDP attribute in received SDP offer or answer with the IP address and TCP port allocated for the media stream at the IMS-AGW before forwarding the SDP.

5.19.4 IMS-ALG procedures for application aware MSRP interworking by the IMS-AGW

The IMS ALG:

– shall provide the SDP "a=path" attribute, as received in SIP/SDP signalling, to the IMS‑AGW as "MSRP Path" with the remote descriptor of the corresponding call leg;

– shall ensure that the IMS-AGW performs application aware MSRP interworking by configuring the IMS-AGW to apply application-aware MSRP interworking; and

– shall indicate "TCP/MSRP" or "TCP/TLS/MSRP" (if e2ae media security is applied) as transport protocol to the IMS‑AGW.

If interworking between an MSRP client applying IETF RFC 6714 [26] and an MSRP client applying IETF RFC 4975 [25] without extensions by either IETF RFC 6714 [26] or IETF draft-ietf-simple-msrp-sessmatch needs to be supported, the IMS ALG should:

– when receiving an SDP offer including the "a=msrp-cema" SDP attribute, include the "a=msrp-cema" SDP attribute in the SDP answer on that call leg;

– when sending an SDP offer, include the "a=msrp-cema" SDP attribute; and

– if the "a=msrp-cema" SDP attribute is not contained in a received SDP answer and the SDP c/m-line address information does not match the "a=path" attribute, send a new SDP offer without the "a=msrp-cema" SDP attribute according to IETF RFC 6714 [26] procedures.

NOTE: The second SDP offer can be omitted if the IMS-ALG knows that there is no SBC in the path (e.g. between the IMS-ALG and the UE).

5.19.5 Application-aware MSRP interworking at the IMS-AGW

The IMS‑AGW shall apply application-aware MSRP interworking either if being statically configured to do so, or if being instructed from the IMS-ALG. Support of dynamic instructions from the IMS-ALG is optional.

To apply application-aware MSRP interworking, the IMS-AGW:

– shall modify the MSRP "To-Path" header field in application (i.e. MSRP) data by replacing the IP address and TCP port of the only entry with the corresponding information in the "MSRP path" provided by the IMS_ALG while retaining the MSRP session ID part of the entry as received in the MSRP "To-Path"; and

– shall forward the MSRP data without further modification.

NOTE: MSRP session matching will be performed only be the MSRP clients.

5.19.6 MSRP data channels

MSRP signalling can be transferred over WebRTC data channels as a data channel sub-protocol using the SDP offer/answer negotiation according to IETF RFC 8873 [62]. WebRTC data channels are described in clause 5.20.2. For WebRTC terminations the procedures in clause 5.19 shall apply with the modifications described in the present clause.

Within received SIP/SDP signalling related to a WebRTC termination MSRP contents within a data channel will be marked with the "subprotocol="MSRP"" subfield in the "a=dcmap" SDP attribute according to IETF RFC 8864 [65]. The MSRP related "a=msrp-cema", "a=path", "a=accept-types" and "a=setup" SDP attributes will be encapsulated in "a=dcsa" SDP attributes according to IETF RFC 8864 [65]. The "a=msrp-cema" can be present or omitted in received SIP/SDP signalling related to a termination where no WebRTC data channel is to be used, but IETF RFC 6714 [26] is always applicable for MSRP within WebRTC data channels and the "a=msrp-cema" shall be present in SIP/SDP signalling related to a WebRTC termination.

When receiving an SDP offer including such MSRP related information in SIP/SDP signalling related to a WebRTC data channel, and forwarding the SDP offer towards a termination where no WebRTC data channel is to be used, the IMS-ALG shall:

– describe each MSRP data channel in a separate SDP media line in the SDP offer it forwards;

– include "a=msrp-cema", "a=path", "a=accept-types" and "a=setup" SDP attributes received encapsulated in "a=dcsa" SDP attributes in the forwarded SDP offer for the corresponding MSRP media line(s) without the encapsulation; and

– execute the procedures in the clause 5.19 as if an "a=msrp-cema" SDP attribute had been received.

When receiving an SDP offer including MSRP related information without an indication of WebRTC data channel usage in SIP/SDP signalling, and forwarding the SDP offer towards a termination where a WebRTC data channel is to be used, the IMS-ALG shall:

– describe each received MSRP media line as a separate data channel;

– include any received "a=msrp-cema", "a=path", "a=accept-types" and "a=setup" SDP attributes received for the MSRP media line(s) encapsulated in "a=dcsa" SDP attributes in the forwarded SDP offer;

– if the "a=msrp-cema" SDP attribute was not received for the MSRP media line(s), include "a=msrp-cema" SDP attribute for the corresponding MSRP media line(s) encapsulated in "a=dcsa" SDP attribute in the forwarded SDP offer;

– include an "subprotocol="MSRP"" subfield in a "a=dcmap" SDP attribute; and

– not include the "max-retr", "max-time" and "ordered" parameters in the "a=dcmap" SDP attribute.

For terminations with MSRP within a WebRTC data channel, the IMS-ALG shall:

– indicate a transport protocol according to clause 5.20.2 to the eIMS-AGW; and

– for application aware MSRP interworking:

a) indicate that MSRP is used within the data channel to the eIMS-AGW; and

b) provide the SDP "a=path" attribute encapsulated in "a=dcsa" SDP attribute, as received in SIP/SDP signalling, to the eIMS‑AGW as "Encapsulated MSRP Path" with the remote descriptor of the corresponding call leg.

5.20 Web Real-Time Communication (WebRTC)

5.20.1 General

The following requirements apply for a "P-CSCF enhanced for WebRTC (eP-CSCF)" and an "IMS-AGW enhanced for WebRTC (eIMS-AGW)":

– End-to-access-edge security for RTP based media using DTLS-SRTP, clause 5.11.2.4, shall be supported.

– End-to-access-edge security for RTP based media using DTLS-SRTP over TCP transport, clause 5.11.2.5, may be supported.

– Interactive Connectivity Establishment (ICE), clause 5.18, shall be supported. ICE for TCP may be supported in addition to offer an alternative transport for UDP based media as specified in clause 5.18.

– STUN Consent Freshness, clause 5.18.4, shall be supported.

– RTP/RTCP transport multiplexing, clause 5.9.2 shall be supported.

– Audio transcoding, clause 5.13, shall be supported. Video transcoding may be supported.

– Transcoding to/from the Opus Audio Codec, IETF RFC 6716 [50], clause 5.13.4, should be supported.

– Procedures for the eIMS-AGW to act as a data channel endpoint should be supported according to IETF draft ietf-rtcweb-data-channel [61], see clause 5.20.2.

– Data channels used for WebRTC to transport MSRP as a data channel sub-protocol, i.e. MSRP data channels between the UE and the eIMS-AGW should be supported according to IETF RFC 8873 [62] and the procedures in clause 5.19.6. SCTP/DTLS/UDP should be transported as protocol stack for data channels and SCTP/DTLS/TCP may be supported.

– Data channels used for WebRTC to transport T.140 (used for Global Text Telephony, GTT) as a data channel sub-protocol, i.e. T.140 data channels between the UE and the eIMS-AGW may be supported according to IETF RFC 8865 [75] and the procedures in clause 5.20.2.6.

– The media plane optimization procedures in clause 5.20.3 may be supported.

5.20.2 WebRTC data channel

5.20.2.1 General

In the WebRTC framework, non-media data communication between UEs is handled by using data channels according to IETF RFC 8831 [61]; within SCTP (see IETF RFC 4960 [63]), encapsulated in DTLS. The related SDP signalling is described in IETF RFC 8841 [64] and IETF RFC 8864 [65].

5.20.2.2 Data Channel Establishment

Data channels can use either a SCTP/DTLS/UDP or SCTP/DTLS/TCP based transport. If the eP-CSCF (IMS-ALG) and the eIMS-AGW support data channels, they shall support the SCTP/DTLS/UDP based transport and may support the SCTP/DTLS/TCP based transport.

NOTE 1: This clause assumes that the UDP based option is used as default ICE candidate for WebRTC terminations. TCP based transport can be offered in addition as alternative transport using ICE for TCP as specified in clause 5.18.

Upon receipt of an SDP offer containing SDP attributes for new SCTP associations and/or new data channels according to IETF RFC 8841 [64] and IETF RFC 8864 [65] from the WebRTC access network, the eP-CSCF (IMS-ALG):

– shall check if a new DTLS association and SCTP association is to be set up or an existing DTLS association and SCTP association are to be reused (NOTE 1) according to IETF RFC 8842 [81] and IETF RFC 8841 [64];

NOTE 2: The present procedures assume that the DTLS association and SCTP association are established together. A separate establishment of DTLS association and SCTP association is not supported in the present release.

– if a new DTLS connection and SCTP association are to be set up:

1) shall request a new H.248 stream group (see details below) on a new termination towards the WebRTC access network from the eIMS-AGW;

2) shall request a deaggregation stream to handle the SCTP association and DTLS association, and for the H.248 deaggregation stream:

a) shall send the remote UDP port and SCTP port to the eIMS-AGW;

b) shall request the local UDP port and SCTP port from the eIMS-AGW;

c) shall insert the local UDP port and SCTP port received from the eIMS-AGW into the SDP answer towards the WebRTC access network;

d) shall provide the remote SCTP maximum message size, as received within the "a=max-message-size" SDP attribute, to the eIMS-AGW;

e) shall request the eIMS-AGW to provide its own local SCTP maximum message size;

f) shall insert the SCTP maximum message size received from the eIMS-AGW into the SDP answer towards the WebRTC access network;

g) shall check the received value of the "a=setup" SDP attribute to determine if the eIMS-AGW needs to act as DTLS client or DTLS server. When the received value is equal to:

i) "active" the eIMS-AGW needs to act as DTLS server;

ii) "passive" the eIMS-AGW needs to act as DTLS client; or

iii) "actpass" the eP-CSCF (IMS-ALG) shall decide if the eIMS-AGW needs to act as DTLS client or DTLS server;

h) if the eIMS-AGW needs to act as DTLS client;

i) shall provide the Establish (D)TLS session information element to request the eIMS-AGW to start the DTLS session setup; and

ii) shall provide the Establish SCTP association information element to request the eIMS-AGW to start the SCTP association setup as soon as DTLS association is data transfer ready;

NOTE 3: Such an H.248 control leads to the emulation of "simultaneous SCTP association establishment" (i.e., the eIMS-AGW behaves according to clause 5.2.1 of IETF RFC 4960 [63]).

i) if the eIMS-AGW needs to act as DTLS server, may include the Notify (D)TLS session establishment information element to request the eIMS-AGW to notify the eP-CSCF (IMS-ALG) about an incoming DTLS session setup;

j) shall indicate to the eIMS-AGW "UDP/DTLS/SCTP" as transport protocol;

k) shall provide to the eIMS-AGW the Remote certificate fingerprint information element with the value of the received fingerprint SDP attribute(s) from the WIC;

l) shall include the Local certificate fingerprint Request information element to request the certificate fingerprint of the eIMS-AGW; and

m) shall indicate to the eIMS-AGW the SCTP stream identifiers of H.248 component stream(s) (i.e. SCTP streams corresponding to data channels) to be de-multiplexed;

3) shall indicate the grouping of the H.248 deaggregation stream and the H.248 component stream(s) with SCTP semantics to the eIMS-AGW; and

4) shall request the eIMS-AGW to provide a notification when receiving an SCTP stream reset request and to autonomously answer that SCTP stream reset request;

– if an existing DTLS association and SCTP association are to be reused, shall modify the existing termination for that SCTP association by:

1) indicating to the eIMS-AGW the SCTP stream identifiers of H.248 component stream(s) (i.e. SCTP streams corresponding to data channels) to be de-multiplexed; and

2) indicating the H.248 stream grouping of the H.248 deaggregation stream and the H.248 component stream(s) with SCTP semantics to the eIMS-AGW;

NOTE 4: The information element relates to an H.248 Stream Group (SG) which allows:
a) to separate the protocol stack in the levels of data channels (DC) and the commonly shared lower transport, and
b) to support multiple DCs. The SG is part of the WebRTC termination.

– for each data channel to be established:

1) shall reserve a separate H.248 stream at the termination towards the WebRTC access network;

2) shall provide the SCTP stream identifier to the eIMS-AGW;

3) shall provide the information received in the SDP "a=dcmap" attribute to the eIMS-AGW;

NOTE 5: For MSRP and T.140 within data channels, the default values of the "max-retr" parameter, the "max-time" parameter and the "ordered" parameter apply and those parameters are not included.

4) if application aware handling of the contents within the data channel is required, may provide the information received in SDP "a=dcsa" attributes to the eIMS-AGW as "remote dcsa" information elements, taking into account the specific procedures defined for the subprotocols within the data channel;

5) if the first data channel is to be established, shall reserve a termination towards the core network;

6) shall reserve a H.248 stream towards the core network;

7) shall indicate to the eIMS-AGW how to interwork the information send or received in data channels with information send or received on streams towards the IMS core network by using the same H.248 stream identifier for the H.248 stream towards the WebRTC access network and towards the core network;

8) shall indicate to the eIMS-AGW an appropriate transport protocol towards the IMS core network (e.g. "TCP" for MSRP) for the media described in the dcmap attribute for the data channel when reserving the transport addresses/resources towards the IMS core network;

9) shall provide an appropriate media line for the media described in the dcmap attribute in the SDP offer towards the IMS core network; and

10) should de-encapsulate SDP attributes within the received SDP "a=dcsa" attributes in the SDP offer and include the de-encapsulated SDP attributes in the SDP offer towards the IMS core network as media attributes for the media line corresponding to the data channel, taking into account specific procedures defined for the subprotocol within the data channel; and

– shall remove the "a=setup", "a=connection" "a=dcmap" and possible "a=dcsa" SDP attributes and fingerprint information from the SDP offer towards the IMS core network.

Upon receipt of a corresponding SDP answer from the IMS core network, if the SDP answer does not indicate that media plane optimization is to be applied (see clause 5.20.3.2), the eP-CSCF (IMS-ALG):

– instead of the media line(s) describing media that are to be transported within data channel(s), shall provide an "m=" line with the transport protocol "UDP/DTLS/SCTP";

– shall insert the fingerprint SDP attribute with the value of the Local certificate fingerprint information element received from the eIMS-AGW;

– if the IMS-ALG received from the WIC an SDP offer with "a=tls-id" media-level SDP attribute for the DTLS association:

1) if an existing DTLS association is reused, shall include the "a=tls-id" SDP attribute with the value assigned to that DTLS association in the SDP answer which the IMS-ALG sends to the WIC; and

2) if a new DTLS association is to be established, shall include the "a=tls-id" SDP attribute with a new unique value in the SDP answer which the IMS-ALG sends to the WIC;

– shall insert the "a=setup" SDP attribute with the value:

1) "active" if the eP-CSCF (IMS-ALG) requested the eIMS-AGW to act as DTLS client; or

2) "passive" if the eIMS-AGW shall take the DTLS server role; and

– for each received media line describing media that are to be transported within a data channel:

1) shall insert an "a=dcmap" attribute with the same values for the SCTP stream identifier, "subprotocol" and "label" parameters as received in the SDP offer, and with possible values for the "max-retr", "max-time", and "ordered" parameters according to the requirements of the transported data flow and capabilities of the eIMS-AGW;

NOTE 6: For MSRP and T.140 within data channels, the default values of the "max-retr" parameter, the "max-time" parameter and the "ordered" parameter apply and those parameters are not included.

2) should insert SDP "a=dcsa" attributes into the SDP answer towards the WebRTC access network encapsulating subprotocol specific SDP attributes received in the SDP answer, taking into account specific procedures defined for the subprotocol within the data channel;

3) shall provide the information in the sent SDP "a=dcmap" attribute to the eIMS-AGW; and

4) may provide the information within the sent SDP "a=dcsa" attributes to the eIMS-AGW as "local dcsa" information elements, taking into account specific procedures defined for the subprotocol within the data channel.

Upon receipt of an SDP offer from the IMS core network for new media streams that need to be transported within a WebRTC data channel on the WebRTC access network, if the SDP offer does not indicate that media plane optimization is to be applied (see clause 5.20.3.3), the eP-CSCF (IMS-ALG):

– shall determine if it can reuse an existing DTLS association and SCTP association or if it needs to set up a new DTLS association and SCTP association;

– if a new DTLS association and SCTP association are to be set up:

1) shall request a new termination towards the WebRTC access network from the eIMS-AGW;

2) shall request a deaggregation stream to handle the SCTP association and DTLS association, and for the H.248 deaggregation stream:

a) shall request the local UDP port and SCTP port from the eIMS-AGW;

b) shall insert the local UDP port and SCTP port received from the eIMS-AGW into the SDP offer towards the WebRTC access network;

c) shall request the eIMS-AGW to provide its own local SCTP maximum message size;

d) shall insert the SCTP maximum message size received from the eIMS-AGW into the SDP offer towards the WebRTC access network;

e) shall add an SDP "a=setup" attribute with value "actpass" into the SDP offer;

f) shall indicate to the eIMS-AGW "UDP/DTLS/SCTP" as transport protocol;

g) shall include the Local certificate fingerprint Request information element to request the certificate fingerprint of the eIMS-AGW;

h shall insert the fingerprint SDP attribute with the value of the Local certificate fingerprint information element received from the eIMS-AGW into the SDP offer towards the WebRTC access network; and

i) shall indicate to the eIMS-AGW the SCTP stream identifiers of H.248 component stream(s) (i.e. SCTP streams corresponding to data channels) to be de-multiplexed;

3) shall indicate the H.248 stream grouping of the H.248 deaggregation stream and the H.248 component stream(s) with SCTP semantics to the eIMS-AGW; and

4) shall request the eIMS-AGW to provide a notification when receiving an SCTP stream reset request and to autonomously answer that SCTP stream reset request;

– if an existing DTLS association and SCTP association are to be reused, shall modify the existing termination towards the WebRTC access network for that SCTP association by:

1) indicating to the eIMS-AGW the SCTP stream identifiers of H.248 component stream(s) (i.e. SCTP streams corresponding to data channels) to be de-multiplexed; and

2) indicating the H.248 stream grouping of the H.248 deaggregation stream and the H.248 component stream(s) with SCTP semantics to the eIMS-AGW;

– instead of the media line(s) describing media that are to be transported within data channel(s), shall provide an "m=" line with the transport protocol "UDP/DTLS/SCTP";

– shall insert an "a=tls-id" SDP attribute in the SDP offer with a new or reused value (depending on whether an existing DTLS association is reused); and

– for each received media line describing media that are to be transported within a data channel:

1) shall reserve a separate H.248 stream at the termination towards the WebRTC access network;

2) shall insert an "a=dcmap" attribute with an unused SCTP stream identifier, and with "subprotocol" and "label" parameters according to the requirements of the transported data flow, and with possible values for the "max-retr", "max-time", and "ordered" parameters according to the requirements of the transported data flow and capabilities of the eIMS-AGW;

NOTE 7: For MSRP and T.140 within data channels, the default values of the "max-retr" parameter, the "max-time" parameter and the "ordered" parameter apply and those parameters are not included.

3) shall provide the SCTP stream identifier to the eIMS-AGW;

4) shall provide the information in the sent SDP "a=dcmap" attribute to the eIMS-AGW;

5) should insert SDP "a=dcsa" attributes into the SDP offer towards the WebRTC access network encapsulating any subprotocol specific SDP attributes received in the SDP offer, taking into account specific procedures defined for the subprotocol within the data channel;

6) if application aware handling of the contents within the data channel is required, may provide the information within the sent SDP "a=dcsa" attributes to the eIMS-AGW as "local dcsa" information elements, taking into account specific procedures defined for the subprotocol within the data channel;

7) if the first data channel is to be established, shall reserve a termination towards the core network;

8) shall reserve a H.248 stream towards the core network; and

9) shall indicate to the eIMS-AGW how to interwork the information sent or received in data channels with information sent or received on terminations and/or streams towards the IMS core network by using the same H.248 stream identifier for the stream towards the WebRTC access network and towards the core network.

Upon receipt of a corresponding SDP answer from the WebRTC access network, the eP-CSCF (IMS-ALG):

– if a new DTLS association and SCTP association are to be set up, for the H.248 deaggregation stream to handle the SCTP association and DTLS connection:

1) shall send the received remote UDP port and SCTP port to the eIMS-AGW;

2) shall include the Remote certificate fingerprint information element with the value of the received fingerprint SDP attribute(s) from the WebRTC access network;

3) shall check the received value of the "a=setup" SDP attribute to determine if the eIMS-AGW needs to act as DTLS client or DTLS server. When the received value is equal to:

a) "active" the eIMS-AGW needs to act as DTLS server; or

b) "passive" the eIMS-AGW needs to act as DTLS client;

4) if the eIMS-AGW needs to act as DTLS client:

a) shall include the Establish (D)TLS session information element to request the eIMS-AGW to start the DTLS session setup; and

b) shall provide the Establish SCTP association information element to request the eIMS-AGW to start the SCTP association setup as soon as DTLS connection is data transfer ready;

5) if the eIMS-AGW needs to act as DTLS server, may include the Notify (D)TLS session establishment information element to request the eIMS-AGW to notify the eP-CSCF (IMS-ALG) about an incoming DTLS session setup; and

6) shall provide the remote SCTP maximum message size, as received within the "a=max-message-size" SDP attribute, to the eIMS-AGW;

– shall remove the "a=setup", "a=connection" "a=dcmap" and possible "a=dcsa" SDP attributes and fingerprint information from the SDP answer and indicate the transport protocol "TCP" in the SDP answer towards the IMS core network; and

– for each accepted data channel:

1) shall provide the information received in the SDP "a=dcmap" attribute to the eIMS-AGW;

2) if application aware handling of the contents within the data channel is required, may provide the information within the received SDP "a=dcsa" attributes in the SDP answer to the eIMS-AGW as "remote dcsa" information elements, taking into account specific procedures defined for the subprotocol within the data channel; and

3) should de-encapsulate SDP attributes within the received SDP "a=dcsa" attributes in the SDP answer and include the de- encapsulated SDP attributes in the SDP answer towards the IMS core network, taking into account specific procedures defined for the subprotocol within the data channel.

If requested to set up a new DTLS association and SCTP association, the eIMS-AGW shall:

– allocate the local UDP port and SCTP port, and send them to the eP-CSCF (IMS-ALG);

– when being instructed to start the DTLS bearer session setup, act as a DTLS client and establish the DTLS bearer session;

– upon request from the eP-CSCF (IMS-ALG), provide the SCTP maximum message size;

– upon request from the eP-CSCF (IMS-ALG), select an own certificate, and send the fingerprint of the own certificate to the eP-CSCF (IMS-ALG);

– uniquely associate the certificate fingerprint(s) received from the eP-CSCF (IMS-ALG) with the corresponding DTLS association, and subsequently use the certificate fingerprint(s) to verify the establishment of the DTLS bearer session;

– if the verification of the remote certificate fingerprint(s) during the DTLS bearer session establishment fails, regard the remote DTLS endpoint as not authenticated, terminate the DTLS bearer session and report the unsuccessful DTLS bearer session setup to the eP-CSCF (IMS-ALG);

– upon completion of the DTLS association establishment, set up the SCTP association according to IETF RFC 4960 [63]; and

– deaggregate H.248 component streams upon request from the eP-CSCF (IMS-ALG).

If the eP-CSCF (IMS-ALG) requests that a termination with an existing SCTP association is being modified, the eIMS-AGW shall reuse an existing DTLS association and SCTP association.

If the eP-CSCF (IMS-ALG) requests that a new H.248 component stream with a H.248 stream group related to an SCTP association is being reserved, the eIMS-AGW shall set up the data channel according to IETF RFC 8831 [61] procedures. The eIMS-AGW shall also interwork the information sent or received in data channels with information sent or received on terminations and/or streams towards the IMS core network according to the configuration received by the eP-CSCF (IMS-ALG).

NOTE 8: The handling of priority information that is part of the dcmap information received from the eP-CSCF (IMS-ALG) is left to the eIMS-AGW implementation.

5.20.2.3 Data Channel Release

5.20.2.3.1 General

In the present Release, the closure of individual WebRTC data channels (clause 5.20.2.3.2) and the complete release of the entire WebRTC data service (clause 5.20.2.3.3) are supported.

NOTE 1: The hierarchical protocol stack for WebRTC data ("DC/SCTP/DTLS/(UDP|TCP)/IP") contains up to four levels of user plane bearer control procedures, from top to bottom:
1) DC: SCTP Stream reconfiguration procedures for resetting SCTP Streams;
2) SCTP Association: shutdown procedure;
3) DTLS: DTLS connection release procedure (apart from resumption and renegotiation procedures); and
4) TCP: TCP connection release procedure. (However, TCP transport of WebRTC data channels is not supported in the present Release).
The present Release does not consider specific release variations at levels 2 to 4, such as the shutdown of an SCTP Association without a DTLS connection release.

A data channel can be closed before the end of the WebRTC call. In the present Release, the H.248 Stream endpoint related to a data channel may be removed after the closure of the data channel, but a subsequent reuse of the corresponding SCTP Stream identifier is possible via an SDP offer-answer exchange triggering the reservation of new H.248 Stream endpoint.

NOTE 2: There are multiple variations possible because the "CLOSURE of a data channel" results in a reset of the SCTP Stream (see clause 6.7 of IETF RFC 8831 [61]), i.e. the concerned SCTP Stream still exists from protocol stack perspective. Such a reset SCTP Stream could be reused again (for the same or another WebRTC data application). There are consequently two options from the eP-CSCF (IMS-ALG) perspective: the correspondent H.248 Stream endpoint remains allocated and part of the H.248 Stream Group for a possible future reuse, or the H.248 Stream endpoint is completely removed from the termination.

5.20.2.3.2 Release of one WebRTC data channel

When the eP-CSCF (IMS-ALG) receives:

– an SDP offer or answer from the WebRTC access network releasing a particular WebRTC data channel while maintaining the corresponding SCTP Association, encoded according to IETF RFC 8864 [65]; or

NOTE 1: Such an SDP offer or answer is characterized by the exclusion of the "a=dcmap:" and "a=dcsa:" attribute lines for an existing data channel (DC). See clause 5.2.4 of IETF RFC 8864 [65] related to the general closure of an application-agnostic DC and clause 5.1.5 of IETF RFC 8873 [62] for an example of an application-aware DC closure.

– an SDP offer or answer from the IMS core network disabling media streams that need to be transported within a WebRTC data channel on the WebRTC access network (i.e. media line with port zero) while maintaining other media streams that are transported within another data channel within the same SCTP Association enabled; or

– a notification from the eIMS-AGW that the peer has reset the incoming SCTP Stream that corresponds to a data channel;

then the eP-CSCF (IMS-ALG):

1) shall provide the Send SCTP Stream Reset Requests Indicator information element to the eIMS-AGW to request the eIMS-AGW to start the SCTP Stream reset for the corresponding outgoing SCTP Stream;

NOTE 2: This will trigger the peer to also reset the corresponding incoming SCTP Stream, unless the peer has already done so before.

2) may provide the Received SCTP Stream Reset Response information element to the eIMS-AGW if the eP-CSCF (IMS-ALG) wants to receive an explicit notification from the eIMS-AGW that the peer has reset the corresponding incoming SCTP Stream;

3) upon the reception of a Notification from the eIMS-AGW that the peer has reset the corresponding incoming SCTP Stream and the additional notification from the eIMS-AGW about the result of the outgoing SCTP Stream (if requested), may release the corresponding H.248 Stream endpoints at the terminations towards the WebRTC access network and towards the IMS core network;

4) if an received SDP offer or answer from the WebRTC access network triggered the release of the data channel, shall forward the SDP offer or answer to IMS core network with the media line corresponding to the media stream in the data channel disabled by port zero;

5) if an received SDP offer or answer from the IMS core network triggered the release of the data channel, shall forward the SDP offer or answer to WebRTC access network with the corresponding WebRTC data channel released with encoding according to IETF RFC 8864 [65]; and

6) if all of the following conditions apply:

– a notification from the eIMS-AGW that the peer has reset the incoming SCTP Stream triggered the release of the data channel;

– the application subprotocol does not mandate that the closing of a data channel is also signalled via a new SDP offer/answer exchange; and

– no corresponding SIP/SDP information is received in due time;

should send the appropriate SIP message with the SDP body to the IMS core network with the media line corresponding to the media stream in the data channel disabled by port zero.

NOTE 3: According to IETF RFC 8864 [65], it is specific to the subprotocol whether this closing of a data channel MUST in addition the the SCTP SCTP SSN reset also be signalled to the peer via a new SDP offer/answer exchange. For MSRP, if the peer triggers a data channel release by resetting the incoming SCTP Stream, it is also mandated to send corresponding SIP/SDP information.

5.20.2.3.3 Release of all or last active WebRTC data channels within an SCTP Association

When the eP-CSCF (IMS-ALG) receives:

– an SDP offer or answer from the WebRTC access network requesting to release the SCTP Association used to transport data channels, encoded according to IETF RFC 8864 [65] (i.e. media line with port zero); or

– an SDP offer or answer from the IMS core network disabling all media stream(s) that need to be transported within a WebRTC data channel on the WebRTC access network (i.e. media line(s) with port zero);

then the eP-CSCF (IMS-ALG):

1) shall release the corresponding H.248 Stream group or termination towards the WebRTC access network;

NOTE 1: In the present release, a separate DTLS connection is used for each for each SCTP Association and for each audio or video media stream (for their DTLS-SRTP-based key exchange).

2) shall release the corresponding H.248 streamendpoint(s) or termination towards the IMS core network;

NOTE 2: If a new SDP offer from the access network arrives that requests a new data channel, then a stream end point and possibly a termination towards the IMS core network has to be added again.

3) if an received SDP offer or answer from the WebRTC access network triggered the release of the SCTP Association, shall forward the SDP offer or answer to the IMS core network with all media line(s) corresponding to the media stream(s) in the data channel(s) within that SCTP Association disabled by port zero; and

4) if an received SDP offer or answer from the IMS core network triggered the release of the SCTP Association, shall forward the SDP offer or answer to WebRTC access network with the corresponding release of the SCTP Association with encoding according to IETF RFC 8864 [65] (i.e. media line with port zero).

When the eP-CSCF (IMS-ALG) requests the eIMS-AGW to release an entire H.248 Stream group or termination associated with an SCTP Association, then the eIMS-AGW should execute appropriate bearer control procedures to release the DTLS connection.

NOTE 3: If one DTLS connection endpoint closes the DTLS connection (e.g. sends a DTLS fatal alert), then the other DTLS connection endpoint unambiguously knows that also the SCTP association and all previously existing data channel instances are implicitly closed.

NOTE 4: ‘TCP’ as L4 protocol is supported for WebRTC audio and video, but not for data in the present release.

5.20.2.4 MSRP within WebRTC data channel

See clause 5.19.6.

5.20.2.5 Void

5.20.2.6 T.140 within WebRTC data channel

T.140 (see ITU‑T Recommendation T.140 [73]) is used for Global Text Telephony (GTT). T.140 signalling can be transferred over WebRTC data channels as a data channel sub-protocol according to IETF RFC 8865 [75]. The WebRTC data channel procedures in clause 5.20.2.2 shall apply with the modifications described in the present clause.

T.140 within a data channel is identified via the "t140" value of the "subprotocol" parameter of the SDP "a=dcmap" attribute.

T.140 transported outside the data channel in the IMS core network is identified via the "RTP/AVP" or "RTP/AVPF" value of the "proto" parameter and the "text" value of the "media" parameter of the SDP m-line, and via the "t140" MIME subtype signalled in the SDP "a=rtpmap" attribute (see IETF RFC 4103 [74]).

The eIMS-ALG shall apply the procedures in clause 5.20.2.2 to configure the eIMS-AGW for an application-aware handling of the contents within the data channel.

For the termination toward the IMS core network, the eIMS-ALG:

– shall provision "RTP/AVP" or "RTP/AVPF" as transport and the "t140" payload type;

– shall de-encapsulate the SDP "fmtp:t140 cps" attributes, "sendrecv", "sendonly", "recvonly", "inactive", "hlang-send" and "hlang-recv" received within "a=dcsa" attributes from the served WIC;

– shall forward those attributes within the SDP body in the corresponding SIP message sent to the IMS core network; and

– shall provision the SDP "fmtp:t140 cps" attributes to the eIMS-AGW.

For the termination towards the WebRTC access network, the eIMS-ALG:

– shall not include the "max-retr", "max-time" and "ordered" parameters in the "a=dcmap" SDP attribute;

– shall encapsulate SDP "fmtp:t140 cps", "sendrecv", "sendonly", "recvonly", "inactive", "hlang-send" and "hlang-recv" attributes received from the IMS core network within "a=dcsa" attributes and forward those attributes within the SDP body in the corresponding SIP message sent to the served WIC; and

– shall provision SDP "fmtp:t140 cps" attributes received from the IMS core network to the eIMS-AGW.

The eIMS-AGW should handle T.140 protocol layer in the following application specific manner:

– the eIMS-AGW should detect inactivity of T.140 traffic from the served WIC and then send empty RTP packets towards the IMS core network;

– the eIMS-AGW should buffer the T.140 payload received within incoming RTP packets from the IMS core network to correct out-of-order delivery; and

– the eIMS-AGW should detect missing RTP packets from the IMS core network and then send new T140 blocks with "missing text marker" information to the served WIC.

5.20.3 Media Plane Optimization

5.20.3.1 General

Media plane optimization procedures for WebRTC are described in 3GPP TS 23.228 [2], annex U.2.4, and in 3GPP TS 24.371 [44], sublause 7.4.5. The purpose of media plane optimization procedures is to convey media between WebRTC clients without bearer level protocol conversion. When both ends are WebRTC IMS clients (WIC), the eIMS-AGWs remain allocated but media plane interworking is disabled, except when LI is needed. Depending on configuration in the eP-CSCF (IMS-ALG), the eIMS-AGW then forwards all protocol layers either including DTLS, or on top of DTLS transparently.

NOTE 1: Terminating the DTLS protocol layer for all calls can improve the transparency of LI.

NOTE 2: In Rel-13, the media plane optimization procedure only supports the transparent forwarding of all protocol layers including DTLS, and no related configuration in the eP-CSCF (IMS-ALG) is thus required. The configuration in the eP-CSCF (IMS-ALG) needs to take into account if the eIMS-AGW supports the media plane optimization procedures with DTLS layer termination added in Rel-14.

The SDP attributes associated with WebRTC media plane optimization procedures "tra-contact", "tra-m-line", "tra-att", "tra-SCTP-association", "tra-media-line-number" and "tra-bw" are defined in 3GPP TS 24.229 [11], clause 7.5.4.

5.20.3.2 WIC originating call

If an eP-CSCF (IMS-ALG) forwards an SDP offer from the WIC, and supports media plane optimization, and does not need to perform legal interception, then the eP-CSCF (IMS-ALG) will include media suitable for non-WebRTC IMS UEs, but also encapsulate information about the media in the original encoding as received in the SDP offer from the WIC in "tra-m-line", "tra-att" and "tra-bw" SDP attributes, as described in 3GPP TS 24.371 [44]. The eP-CSCF (IMS-ALG) shall:

– configure the eIMS-AGW to reserve resources suitable for the media described in the SDP offer outside the "tra-m-line", "tra-att" and "tra-bw" SDP attributes;

– include the IP address received from the eIMS-AGW for the termination towards the IMS core network in the SDP contact line and also encapsulate the address information provided by the eIMS-AGW into a "tra-contact" attribute;

– if the eP-CSCF (IMS-ALG) is configured to apply media plane optimization including the DTLS layer, for each media line in the SDP offer sent on the Mw interface that does not relate to a data channel or that is the first media line within the SDP offer that relates to a data channel, replace the UDP port number with a port number provided by the eIMS-AGW and encapsulate the UDP port number allocated by the eIMS-AGW in the "tra-m-line" SDP attribute; and

– if the eP-CSCF (IMS-ALG) is configured to apply media plane optimization excluding the DTLS layer, in addition for each media line in the SDP offer sent on the Mw interface that does not relate to a data channel or that is the first media line within the SDP offer that relates to a data channel within one SCTP association:

a) reserve a stream endpoint or termination towards the IMS core network in "inactive" mode with "UDP/DTLS" as transport protocol, and the same IP address as allocated by the eIMS-AGW for the termination or stream endpoint with resources suitable for the media described in the SDP offer outside the "tra-m-line", "tra-att" and "tra-bw" SDP attributes;

b) request from the eIMS-AGW a certificate fingerprint for that stream endpoint or termination;

c) encapsulate a "fingerprint" attribute as provided by the eIMS-AGW into an "tra-att" attribute, and add this attribute as a media level attribute in the SDP offer; and

d) for a DTLS association that will be established towards the IMS core network create a DTLS association identity;

e) encapsulate an "a=tls-id" SDP attribute with the new DTLS association identity into an "tra-att" attribute, and add this attribute as a media level attribute in the SDP offer; and

f) replace the UDP port number with a port number provided by the eIMS-AGW and encapsulate the UDP port number allocated by the eIMS-AGW for the stream endpoint or termination towards the IMS core network with "UDP/DTLS" transport in the "tra-m-line" SDP attribute.

If an ePCSCF (IMS-ALG) receives an SDP answer from the IMS core network and the SDP answer includes "tra-m-line" media level SDP attributes, the eP-CSCF (IMS-ALG) will de-encapsulate information to the optimized media from the received SDP answer and construct the SDP answer towards the WIC based on that de-encapsulated information as described in 3GPP TS 24.371 [44]. The eP-CSCF (IMS-ALG) shall:

– for each media line in the SDP answer, which is not marked with a "tra-SCTP-association" SDP attribute or which is the first media line in the SDP answer marked with a "tra-SCTP-association" SDP attribute that indicates an SCTP association:

1. if the eP-CSCF (IMS-ALG) is configured to apply media plane optimization including the DTLS layer, reconfigure the terminations or stream endpoints towards the IMS core network and towards the WIC related to that media line to transport "UDP" and media format agnostic information; or

NOTE: If interconnected H.248 Stream endpoints or terminations at the eIMS-AGW are configured with transport "UDP", they will pass the payload within UDP without modifications, known as UDP transparent forwarding. For WebRTC media plane optimization, the UDP payload will be either DTLS encapsulating SCTP and data channel(s), DTLS-SRTP encapsulating key management information, or SRTP encapsulating audio or video media. However, the eIMS-AGW will be configured at terminations towards the WIC to apply ICE procedures according to clause 5.18.

2. if the eP-CSCF (IMS-ALG) is configured to apply media plane optimization excluding the DTLS layer:

a) configure the eIMS-AGW to release the termination or stream endpoint towards the IMS core network with resources suitable for the media described in the SDP offer outside the "tra-m-line", "tra-att" and "tra-bw" SDP attributes;

b) configure the eIMS-AGW to through-connect the stream endpoint or termination towards the IMS core network with "UDP/DTLS" as transport protocol;

provide the fingerprint(s) received in the corresponding "tra-att" SDP attribute(s) to the eIMS-AGW for the stream endpoint or termination towards the IMS core network and do not provide those fingerprint attribute(s) towards the WIC;

d) reserve a stream endpoint or termination towards the WIC with "UDP/DTLS" as transport protocol;

e) provide the fingerprint(s) received in the corresponding "fingerprint" SDP attribute(s) in the previous SDP offer from the WIC to the eIMS-AGW for the stream endpoint or termination towards the WIC;

f) request from the eIMS-AGW a certificate fingerprint for the stream endpoint or termination towards the WIC;

g) include fingerprint provided by the eIMS-AGW into an "fingerprint" attribute, and add this attribute as a media level attribute in the SDP answer sent towards the WIC;

h) for a DTLS association that will be established towards WIC create a DTLS association identity and include an "a=tls-id" attribute with the new DTLS association identity in the SDP answer sent towards the WIC;

i) determine via the SDP "a=setup" attribute (see IETF RFC 7345 [33]) encapsulated in "tra-att" SDP attribute if the eIMS-AGW needs to act as DTLS client or DTLS server towards the IMS core network and towards the WIC; and

j) for the termination where the eIMS-AGW needs to act as DTLS server, provide the Establish (D)TLS session information element to request the eIMS-AGW to start the DTLS session setup; and

3. include the UDP port number allocated by the eIMS-AGW for the termination or stream endpoint towards the WIC in the SDP media line in the SDP answer to the WIC;

– include the IP address received from the eIMS-AGW for the termination towards the WIC in the SDP contact line sent toward the WIC; and

– if several media lines in the SDP answer are marked with "tra-SCTP-association" SDP attributes indicating the same SCTP association, release the stream endpoints related to the second and subsequent of those media lines (in the order they appear in the SDP answer).

5.20.3.3 WIC terminating call

If an eP-CSCF (IMS-ALG) receives an SDP offer from the IMS core network and the eP-CSCF (IMS-ALG) supports media plane optimization, then the eP-CSCF (IMS-ALG) will determine whether media plane optimization is to be applied as described in 3GPP TS 24.371 [44]. If media plane optimization is to be applied, then the eP-CSCF (IMS-ALG) will de-encapsulate information to the optimized media from the received SDP offer and construct the SDP offer towards the WIC based on that de-encapsulated information as described in 3GPP TS 24.371 [44], and the eP-CSCF (IMS-ALG) shall:

– for each media line in the SDP offer, which is not marked with a "tra-SCTP-association" SDP attribute or which is the first media line in the SDP answer marked with "tra-SCTP-association" SDP attribute that indicates an SCTP association:

1. reserve a termination or stream endpoint towards the WIC related to that media line;

2. if the eP-CSCF (IMS-ALG) is configured to apply media plane optimization including the DTLS layer, provide transport "UDP" and media format agnostic information for the termination or stream endpoint towards the WIC;

NOTE: If interconnected H.248 Stream endpoints or terminations at the eIMS-AGW are configured with transport "UDP", they will pass the payload within UDP without modifications, known as UDP transparent forwarding. For WebRTC media plane optimization, the UDP payload will be either DTLS encapsulating SCTP and data channel(s) or DTLS-SRTP encapsulating key management information, or SRTP encapsulating audio or video media. However, the eIMS-AGW will be configured at terminations towards the WIC to apply ICE procedures according to clause 5.18.

3. if the eP-CSCF (IMS-ALG) is configured to apply media plane optimization excluding the DTLS layer:

a) provide transport "UDP/DTLS" and media format agnostic information for the termination or stream endpoints toward the WIC;

b) request from the eIMS-AGW a certificate fingerprint for the stream endpoint or termination towards the WIC;

c) encapsulate fingerprint provided by the eIMS-AGW into an "fingerprint" attribute, and add this attribute as a media level attribute in the SDP offer sent towards the WIC; and

d) do not provide the fingerprint received in the SDP offer in the corresponding "tra-att" SDP attributes towards the WIC;

e) for a DTLS association that will be established towards WIC create a DTLS association identity, and add an "a=tls-id" SDP attribute with the new DTLS association identity in the SDP offer sent towards the WIC; and

4. include the UDP port number allocated by the eIMS-AGW for the stream endpoint or termination towards the WIC in the SDP media line; and

– include the IP address received from the eIMS-AGW for the termination towards the WIC in the SDP contact line sent toward the WIC.

If the eP-CSCF (IMS-ALG) receives an SDP answer from the WIC and the eP-CSCF (IMS-ALG) decided to apply media plane optimization when processing the corresponding SDP offer, then the eP-CSCF (IMS-ALG) will construct the SDP answer towards the IMS core network encapsulating received information as described in 3GPP TS 24.371 [44], and the eP-CSCF (IMS-ALG) shall:

– reserve a termination or stream endpoint towards the IMS core network;

– for each media line in the received SDP answer:

1. if the eP-CSCF (IMS-ALG) is configured to apply media plane optimization including the DTLS layer, provide transport "UDP" and media format agnostic information for the termination or stream endpoint towards the IMS core network;

2. if the eP-CSCF (IMS-ALG) is configured to apply media plane optimization excluding the DTLS layer:

a) provide the fingerprint(s) received in the "fingerprint" SDP attribute from the WIC to the eIMS-AGW for the stream endpoint or termination towards the WIC;

b) provide transport "UDP/DTLS" and media format agnostic information for the termination or stream endpoint towards the IMS core network;

c) request from the eIMS-AGW a certificate fingerprint for the stream endpoint or termination towards the IMS core network;

d) encapsulate fingerprint provided by the eIMS-AGW for the termination or stream endpoint towards the IMS core network into a "tra-att" SDP attribute, and add this attribute as a media level attribute in the SDP answer sent towards the IMS core network;

e) for a DTLS association that will be established towards the IMS core network create a DTLS association identity;

f) encapsulate an "a=tls-id" SDP attribute with the new DTLS association identity into an "tra-att" attribute, and add this attribute as a media level attribute in the SDP answer sent towards the IMS core network;

g) determine via the SDP "a=setup" attribute (see IETF RFC 7345 [33]) if the eIMS-AGW needs to act as DTLS client or DTLS server towards the IMS core network and towards the WIC; and

h) for the termination where the eIMS-AGW needs to act as DTLS server, provide the Establish (D)TLS session information element to request the eIMS-AGW to start the DTLS session setup; and

3. encapsulate the UDP port number allocated by the eIMS-AGW for the stream endpoint or termination towards the IMS core network in the "tra-m-line" SDP attribute; and

– include the IP address received from the eIMS-AGW for the termination towards the IMS core network in the SDP contact line.

5.21 Alternate Connection (ALTC) Addresses Management

5.21.1 General

The IMS-ALG and the IMS-AGW may support the functionalities related to the support of the ALTC functionality as specified in IETF RFC 6947 [59] and 3GPP TS 24.229 [11] to support dual stack UEs. The present clause describes the requirements for P-CSCF (IMS-ALG) and IMS-AGW when the ALTC procedures are supported.

If the IMS-ALG supports ALTC and, based on local policies, decides to insert ALTC information in the SDP offer sent to the terminating side, the IMS-ALG shall request the IMS-AGW to reserve two sets of transport addresses/resources towards the access network to enable media to traverse the IMS-AGW, one for each media line associated to ALTC information. The IMS-ALG shall request the IMS-AGW to release the transport resources reserved for the address type finally not used.

5.22 Video Region-of-Interest (ROI)

5.22.1 General

The IMS-ALG and the IMS-AGW may support the video Region-of-Interest (ROI) as defined in 3GPP TS 26.114 [21]. Three modes are specified for supporting ROI, including "Far End Camera Control (FECC)", "Arbitrary ROI" and "Predefined ROI". The IMS-ALG and the IMS-AGW may independently support any of these modes.

5.22.2 "Far End Camera Control" mode

The IMS-ALG and IMS-AGW may support the "Far End Camera Control" mode as specified in 3GPP TS 26.114 [21]. If the IMS-ALG and IMS-AGW support the "Far End Camera Control" mode, the IMS-ALG and IMS-AGW shall apply the procedures in the present clause.

If the IMS-ALG receives an SDP body containing an "m=" line with a media type "application/h224", as defined by IETF RFC 4573 [68] which indicates support for FECC (ITU-T Recommendation H.281 [70]) using ITU-T Recommendation H.224 [69], the IMS-ALG shall:

– forward within SIP signalling the SDP body received from the preceding node with unmodified SDP "m=" and "a=" lines related to the "application/h224" media types (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [21]) to the succeeding node; and

NOTE 1: There may be one media type "application/h224" "m=" line for each video "m=" line.

– request the IMS-AGW to provide a separate IP/UDP/RTP transport for the "application/h224" media stream by setting the "m=" line media type to "application" and "RTP/AVP" or "RTP/AVPF" over UDP as transport protocol when reserving the transport addresses/resources towards the MTSI client and IMS core network.

NOTE 2: The use of FECC itself is internal to the H.224 frame and is identified by the client ID field of the H.224 packet. The IMS-ALG only indicates the use of IP/UDP/RTP. The use of FECC is signalled via H.224 by a MTSI client.

The IMS-AGW shall then:

– assign resources for the requested media stream, i.e., resources for a media-format agnostic RTP flow; and

– forward transparently RTP/UDP packets (with the transparent (H.224)-PDU) between the incoming and outgoing network.

5.22.3 "Predefined ROI" mode

The IMS-ALG and IMS-AGW may support the "Predefined ROI" mode as specified in 3GPP TS 26.114 [21]. If the IMS-ALG and IMS-AGW support the "Predefined ROI", the IMS-ALG and IMS-AGW shall apply the procedures in the present clause.

If the IMS-ALG receives an SDP body containing an "a=rtcp-fb" line with the "Predefined ROI" type expressed by the parameter "3gpp-roi-predefined", as described in 3GPP TS 26.114 [21], the IMS-ALG shall:

– forward within SIP signalling the SDP body received from the preceding node with unmodified SDP "a=rtcp-fb" lines related to the "3gpp-roi-predefined" parameter to the succeeding node (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [21]); and

– include the "Predefined ROI" information element when seizing resources in the IMS-AGW to request the IMS-AGW to assign the resources for the corresponding RTCP control flow to convey pre-defined ROI information.

The IMS-AGW shall then assign resources for the requested RTCP control flow and forward transparently the RTCP "FB ROI" packets between the incoming and outgoing network. The procedures described in clause 5.9 shall also apply.

NOTE 1: The RTCP control flow contains multiple RTCP packet types.

If the IMS-ALG receives an SDP body containing the predefined ROI attribute(s) "a=predefined_ROI" defined in 3GPP TS 26.114 [21], the IMS-ALG shall forward the SDP body with unmodified predefined ROI attribute(s) for the send and receive directions when seizing or modifying resources in the IMS-AGW.

If the IMS-ALG receives an SDP body containing "a=extmap" attribute(s), as defined in IETF RFC 5285 [23], and the "a=extmap" attribute(s) contain the pre-defined ROI URN(s) (i.e. the ROI URN for carriage of pre-defined region of interest information in the sent video stream is given by "urn:3gpp:predefined-roi-sent") as defined in 3GPP TS 26.114 [21], then the IMS-ALG shall:

– include the "Extended RTP header for Sent ROI" information element when seizing resources in the IMS-AGW to indicate to the IMS-AGW that it shall allow the RTP header extension for predefined ROI to pass; and

– forward within SIP signalling, the SDP body received from the preceding node with unmodified "a=extmap" attribute(s) to the succeeding node (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [21]).

NOTE 2: The UE supporting the Predefined ROI feature will not send the extended RTP headers for Sent ROI if the UE did not receive any SDP body with the Predefined ROI related "a=extmap" attribute.

If the IMS-AGW has been instructed to pass on the extended RTP header for predefined ROI as described above for both incoming and outgoing terminations then:

– if the IMS AGW does not apply video transcoding, it shall pass any received RTP header extension for Predefined ROI to succeeding RTP streams; or

– if the IMS-AGW applies video transcoding, it shall keep the predefined ROI information unchanged during the transcoding and copy the received RTP header extension for Predefined ROI to the succeeding outgoing RTP stream(s) after transcoding the associated group of packets.

5.22.4 "Arbitrary ROI" mode

The IMS-ALG and IMS-AGW may support the "Arbitrary ROI" mode as specified in 3GPP TS 26.114 [21]. If the IMS-ALG and IMS-AGW support the "Arbitray ROI", the IMS-ALG and IMS-AGW shall apply the procedures in the present clause.

If the IMS-ALG receives an SDP body containing an "a=rtcp-fb" line with the "Arbitrary ROI" type expressed by the parameter "3gpp-roi-arbitrary", as described in 3GPP TS 26.114 [21], the IMS-ALG shall:

– forward within SIP signalling the SDP body received from the preceding node with unmodified SDP "a=rtcp-fb" lines related to the "3gpp-roi-arbitrary" parameter to the succeeding node (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [21]); and

– include the "Arbitrary ROI" information element when seizing resources in the IMS-AGW to request the IMS-AGW to assign the resources for the corresponding RTCP control flow to convey arbitrary ROI information.

NOTE 1: The RTCP control flow contains multiple RTCP packet types.

If the IMS-ALG receives an SDP body containing "a=extmap" attribute(s), as defined in IETF RFC 5285 [23], and the "a=extmap" attribute(s) contain the arbitrary ROI URN(s) (i.e. the ROI URN for carriage of arbitrary region of interest information in the sent video stream is given by "urn:3gpp:roi-sent") as defined in 3GPP TS 26.114 [21], then the IMS-ALG shall:

NOTE 2: The UE supporting the Arbitrary ROI feature will not send the extended RTP headers for Sent ROI if the UE did not receive any SDP body with the Arbitrary ROI related "a=extmap" attribute.

If the IMS-AGW has been instructed to pass on the extended RTP header for arbitrary ROI as described above for both incoming and outgoing terminations then:

– if the IMS AGW does not apply video transcoding, it shall pass any received RTP header extension for Arbitrary ROI to succeeding RTP streams; or

– if the IMS-AGW applies video transcoding, it shall keep the arbitrary ROI information unchanged during the transcoding and copy the received RTP header extension for Arbitrary ROI to the succeeding outgoing RTP stream(s) after transcoding the associated group of packets.

5.23 SDP Capability Negotiation (SDPCapNeg)

The SDP Capability Negotiation (SDPCapNeg) as specified in IETF RFC 5939 [66] is adopted as an optional functionality to negotiate capabilities and their associated configurations according to 3GPP TS 24.229 [11]. If the ICS service is supported then the IMS-ALG and the IMS-AGW may further optionally support SDP Media Capability Negotiation as specified in IETF RFC 6871 [67] for alternative CS configuration.

Upon receipt of an incoming SDP offer containing the attributes of SDP capability negotiation, e.g. offer AVPF and AVP together for the RTP profile negotiation using "a=tcap", "a=pcfg" and "a=acfg" attributes, the IMS-ALG shall:

– request the IMS-AGW to reserve resources only for the default configuration without SDPCapNeg, and make the decision on support of the alternative configurations based on the IMS-ALG/IMS-AGW capability as provisioned before forwarding the SDP offer, i.e. handling SDPCapNeg at the controller level; or

– request the IMS-AGW to reserve resources for all of these configurations by signalling SDPCapNeg to the IMS-AGW, and update the SDP offer based on the response from the IMS-AGW before forwarding.

NOTE: The additional benefit of signalling SDPCapNeg between the IMS-ALG and the IMS-AGW is to check the resource availability for the corresponding configurations and to avoid the further session failure in case of inadequate resources for the configuration changes in the final confirmation. However, due to the extra resources reserved only during the call establishment phase, there is increased risk of call establishment failure.

In case the IMS-ALG decides to request the IMS-AGW to reserve resources for all of those configurations, the IMS-ALG shall:

– use legacy SDP attributes as specified in IETF RFC 4566 [53] to do the mapping of actual and potential configurations with the H.248 ReserveGroup concept; or

– use SDP extensions for SDP capability negotiation as specified in IETF RFC 5939 [66], if supported by the IMS-AGW.

Before using SDP extensions for SDP capability negotiation as specified in IETF RFC 5939 [66] towards the IMS-AGW, the IMS-ALG shall perform the necessary checks (i.e. through auditing or via prior provisioning) to ensure that the IMS-AGW supports the syntax and capabilities requested. For an auditing the procedure in clause 6.1.8.1 is used with the "SDPCapNeg Supported Capabilities" as the object.

When receiving a request from the IMS-ALG with information element "SDPCapNeg configuration" indicating the potential use of multiple configurations, the IMS-AGW shall reserve resources for all of those configurations that it supports and shall send indicate the configurations for which it reserved resources in an "SDPCapNeg configuration" information element in the response. The IMS-ALG shall update the SDP offer with SDPCapNeg configurations in the response from the IMS-AGW and shall forward the SDP offer to the next hop.

The IMS-ALG may also provide SDP configurations to the IMS-AGW with no dependency on the incoming SDP offer, e.g. the IMS-ALG may wildcard the supported configurations in order to construct or update an SDP offer with the addition of alternative configurations via SDPCapNeg attributes.

On receipt of an SDP answer with SDPCapNeg, the IMS-ALG shall request the IMS-AGW to configure the resources for the selected configuration. If the IMS-AGW previously reserved any temporary resources for configurations that were not selected, the IMS-ALG shall also request the IMS-AGW to release those resources.

5.24 RTP-level pause and resume

The IMS-ALG and the IMS-AGW may support the "RTP-level pause and resume" signalling as defined in 3GPP TS 26.114 [21] and IETF RFC 7728 [79].

RTCP feedback messages to request for pause and resume of media streams can be used by conference participants supporting Multi-stream Multiparty Conferencing Media Handling feature, as specified in 3GPP TS 26.114 [21] annex S. Usage of the RTCP feedback "pause and resume" messages is negotiated via SDP offer/answer exchange through an extension of RTCP feedback capability attribute "a=rtcp-fb" (defined in IETF RFC 4585 [77]).

If the IMS-ALG and IMS-AGW support the "RTP-level pause and resume" signalling, the IMS-ALG and IMS-AGW shall apply the procedures in the present clause.

If the IMS-ALG receives an SDP offer containing "a=rtcp-fb" line(s) with a "CCM" parameter (as defined in IETF RFC 5104 [78]) and a "pause" CCM parameter (as defined in IETF RFC 7728 [79]), and if the IMS-ALG does not support or does not apply the transcoding procedure defined in clause 5.13, the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node with unmodified "a=rtcp-fb" line(s) with a "pause" CCM parameter. Otherwise, if the IMS-ALG does insert any transcoding or if the IMS-AGW does not support the "RTP-level pause and resume" signalling, the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node without any "a=rtcp-fb" line(s) with a "pause" CCM parameter.

If the IMS-ALG forwarded the SDP offer containing the "a=rtcp-fb" line(s) with a "pause" CCM parameter and receives an SDP answer also containing the "a=rtcp-fb" line(s) with a "pause" CCM parameter (the reception of the attribute indicates a successful "RTP-level pause and resume" negotiation) then the IMS-ALG shall:

a) when requesting the IMS-AGW to configure resources towards the succeeding node and towards the preceding node, include the "CCM pause-resume" information element to indicate that the IMS-AGW shall forward RTCP feedback "CCM PAUSE-RESUME" messages transparently; and

b) forward the SDP answer containing the "a=rtcp-fb" line(s) with a "pause" CCM parameter to its preceding node.

The IMS-AGW shall then assign resources for the requested RTCP control flow and shall transparently forward the RTCP "CCM PAUSE" packets between incoming and outgoing networks.

5.25 RTCP Codec Control Commands and Indications

The IMS-ALG and the IMS-AGW may support signalling of "RTCP Codec Control Commands and Indications", as defined in 3GPP TS 26.114 [21] and IETF RFC 5104 [78].

NOTE 1: 3GPP TS 26.114 [21] specifies support of the following RTCP feedback codec control messages (CCM): "Full Intra Request (FIR)", "Temporary Maximum Media Stream Bit Rate Request (TMMBR)" and "Temporary Maximum Media Stream Bit Rate Notification (TMMBN)".

The RTCP feedback FIR message can be used both by point-to-point video calls, and by conference participants supporting Multi-stream Multiparty Conferencing Media Handling feature, as specified in 3GPP TS 26.114 [21] annex S, to request the media sender to send a decoder refresh point.

The RTCP TMMBR and TMMBN feedback messages can also be used in reaction to the Explicit Congestion Notification, as specified in clause 5.12.

Usage of the RTCP feedback "CCM" messages is negotiated via SDP offer/answer exchange through an extension (defined in IETF RFC 5104 [78]) of the RTCP feedback capability attribute "a=rtcp-fb" (defined in IETF RFC 4585 [77]).

NOTE 2: The SDP offer/answer negotiation is performed with a separate "a=rtcp-fb" attribute line for each CCM message type.

If the IMS-ALG and IMS-AGW support the "RTCP Codec Control Commands and Indications" signalling, the IMS-ALG and IMS-AGW shall apply the procedures in the present clause.

If the IMS-ALG receives an SDP offer containing "a=rtcp-fb" line(s) with a "CCM" parameter and with a "fir" and/or "tmmbr" CCM parameters (defined in IETF RFC 5104 [78]) under video "m=" line(s), and if the IMS-ALG does not configure the IMS-AGW to transcode the corresponding video media stream and/or to act as ECN endpoint for the corresponding video media stream, the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node with unmodified "a=rtcp-fb" line(s) with the "CCM" parameter and with "fir" and/or "tmmbr" CCM parameters.

NOTE 3: If the IMS-ALG configures the IMS-AGW to transcode a video media stream and/or to act as ECN endpoint for the corresponding video media stream, the IMS-ALG can insert "a=rtcp-fb" line(s) with the "CCM" parameter and with "fir" and/or "tmmbr" CCM parameters within SDP offer irrespective of whether they were received from the preceding node.

If the IMS-ALG does not configure the IMS-AGW to transcode the corresponding video media stream and/or to act as ECN endpoint, and if the IMS-ALG received an SDP answer also containing the "a=rtcp-fb" line(s) with the "CCM" parameter and with the same "fir" and/or "tmmbr" CCM parameters (the presence of the same "a=rtcp-fb ccm" line(s) in the SDP answer indicates a successful negotiation of the particular CCM message), then the IMS-ALG shall:

– when requesting the IMS-AGW to configure resources towards the succeeding node and towards the preceding node, include the "CCM BASE" information element with the "fir" and/or "tmmbr" CCM parameters to indicate that the IMS-AGW shall be prepared to receive and is allowed to send the RTCP CCM "FIR" and/or "TMMBR/TMMBN" feedback messages; and

– forward the SDP answer containing the "a=rtcp-fb" line(s) with the "fir" and/or "tmmbr" CCM parameters (from the received SDP answer) to its preceding node.

If the IMS-ALG configures the IMS-AGW to transcode the corresponding video media stream and/or to act as ECN endpoint:

– if the IMS-ALG did not send towards the succeeding node the SDP offer containing the "a=rtcp-fb" line(s) with the "CCM" parameter and the with "fir" and/or "tmmbr" CCM parameters, then the IMS-ALG may:

a) when requesting the IMS-AGW to configure resources towards the preceding node, include the "CCM BASE" information element with the "fir" and/or "tmmbr" CCM parameters to indicate that the IMS-AGW shall be prepared to receive and is allowed to send the RTCP CCM "FIR" and/or "TMMBR/TMMBN" feedback messages; and

b) include in the SDP answer it sends to the preceding node the "a=rtcp-fb" line(s) with the "fir" and/or "tmmbr" CCM parameters (as received SDP offer); and

– if the IMS-ALG sent towards the succeeding node the SDP offer containing the "a=rtcp-fb" line(s) with the "CCM" parameter and the with "fir" and/or "tmmbr" CCM parameters, and received an SDP answer also containing the "a=rtcp-fb" line(s) with the "CCM" parameter and with the same "fir" and/or "tmmbr" CCM parameters, then the IMS-ALG shall:

a) when requesting the IMS-AGW to configure resources towards the succeeding node, include the "CCM BASE" information element with the "fir" and/or "tmmbr" CCM parameters to indicate that the IMS-AGW shall be prepared to receive and is allowed to send the RTCP CCM "FIR" and/or "TMMBR/TMMBN" feedback messages; and

b) if the the IMS-ALG received from the preceding node the SDP offer containing the "a=rtcp-fb" line(s) with the "CCM" parameter and the with "fir" and/or "tmmbr" CCM parameters, include in the SDP answer it sends to the preceding node the "a=rtcp-fb" line(s) with the "fir" and/or "tmmbr" CCM parameters (as received SDP offer).

The IMS-AGW shall then assign resources for the requested RTCP control flow:

– if the IMS-AGW acts as an ECN endpoint (as described in clause 5.12) or applies the video transcoding procedure, the IMS-AGW:

a) may send the RTCP TMMBR feedback message with an "IMS-AGW-generated" value in an "SSRC of media sender" field that is kept constant for the duration of the session, different from any SSRC value in the active RTP streams for the session, to request the media sender to limit the maximum bit rate for a media stream to, or below, the provided value;

NOTE 4: Trigger for sending of the RTCP TMMBR feedback message can be reception of RTP packets marked with ECN-CE, as described in clause 5.12. The reason to use an "IMS-AGW-generated" value in "SSRC of media sender" and to keep that value constant in the session is that the IMS-AGW must be possible to identify as being a separate source of sending TMMBR messages, to avoid TMMBR induced by ECN restrictions interfering with other TMMBR restrictions set by other media receivers in the media path, as described in clause 3.5.4 of IETF RFC 5104 [78].

b) upon reception of the RTCP TMMBR feedback message and if performing transcoding, shall adjust the sent media rate to the requested rate or lower and shall respond by sending the RTCP TMMBN feedback message; and

c) may send the RTCP FIR feedback message to request the media sender to send a decoder refresh point; or

– if the IMS-AGW does not act as an ECN endpoint and does not apply the video transcoding procedure, the IMS-AGW shall transparently forward received RTCP FIR feedback message, and received RTCP TMMBR and TMMBN feedback messages between the incoming and outgoing networks.

5.26 Delay Budget Information (DBI)

The IMS-ALG and the IMS-AGW may support the "DBI" signalling as defined in 3GPP TS 26.114 [21].

RTCP feedback messages to report or request additional delay budget for voice and video media streams (as defined in 3GPP TS 26.114 [21] clause 7.3.8) can be used by participants in a point-to-point MTSI session, and by conference participants, as specified in 3GPP TS 26.114 [21].

If the IMS-ALG and IMS-AGW support the "DBI" signalling, the IMS-ALG and IMS-AGW shall apply the procedures in the present clause.

If the IMS-ALG receives an SDP offer containing an "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter as defined in 3GPP TS 26.114 [21], the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node with the unmodified "a=rtcp-fb" line(s) with "3GPP-delay-budget" parameter. Otherwise, if the IMS-AGW does not support the "DBI" signalling, the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node without any "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter.

If the IMS-ALG forwarded the SDP offer containing the "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter and receives an SDP answer also containing the "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter (the reception of the attribute indicates a successful "3GPP-delay-budget" negotiation) then the IMS-ALG shall:

a) when requesting the IMS-AGW to configure resources towards the succeeding node and towards the preceding node, include the "DBI" information element to indicate that the IMS-AGW shall forward RTCP DBI feedback messages transparently; and

b) forward the SDP answer containing the "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter to its preceding node.

The IMS-AGW shall then assign resources for the requested RTCP control flow and shall transparently forward the RTCP DBI feedback messages between incoming and outgoing networks.