7 Call origination and termination

24.3713GPPProtocol specificationRelease 17Stage 3TSWeb Real-Time Communications (WebRTC) access to the IP Multimedia (IM) Core Network (CN) subsystem (IMS)

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

7.1 General

This clause specifies procedures that are related to call origination and termination in the IM CN subsystem that are required for support of WebRTC.

It is assumed that prior to the call origination and termination procedure, a WebSockets connection hase been established between the WIC and the eP-CSCF. The call control signalling between the WIC and the eP-CSCF is transport over the WebSockets connection.

The WIC shall support ICE procedures as described in RFC 8445 [45] and RFC 8839 [46], and RFC 6544 [28], with the additions specified in RFC 7675 [21]. The WIC shall perform ICE procedures when initiated by other clauses in this document.

7.2 WIC (WebRTC IMS Client)

7.2.1 General

The WIC shall support RFC 5763 [5] and RFC 5764 [6].

The WIC shall support RFC 5761 [38] as updated by RFC 8035 [42] and RFC 8858 [39], and the WIC shall support sending and receiving RTP and RTCP either on the same port or on separate ports.

The WIC using Gm shall follow the procedures as described in 3GPP TS 24.229 [3]. For the WIC using Gm, the appropriate signalling protocol is defined in 3GPP TS 24.229 [3]. The WIC using Gm shall include the Authorization header field with the Bearer scheme containing the valid access token in all SIP requests, as specified in RFC 8898 [27].

The WIC using non-Gm SIP shall support RFC 3261 [19]. For the WIC using non-Gm, the appropriate signalling protocol is defined in RFC 3261 [19].

The WIC using non-SIP shall support RFC 3264 [20]. For the WIC using non-SIP, the appropriate signalling protocol is out of scope of this specification.

7.2.2 WIC originating call

When the WIC originates a call, the WIC shall:

a) perform the ICE procedures as defined in RFC 8445 [45] and RFC 8839 [46] and possibly RFC 6544 [28]; and

b) generate an SDP offer and send it towards the eP-CSCF using the appropriate signalling protocol as described in clause 7.2.1.

Upon generating an SDP offer with RTP based media, for each RTP based media, the WIC

a) shall offer UDP transport protocol according RFC 5763 [5], with the proto field in the "m=" line containing the "UDP/TLS/RTP/SAVPF" value according to RFC 5764 [6];

b) may additionally, within the same "m=" line, offer TCP transport protocol with appropriate ICE candidates according to RFC 6544 [28];

c) shall additionally, within the same "m=" line, indicate an SDP "a=3ge2ae:requested" attribute;

d) if the WIC desires to receive multiplexed RTP and RTCP on the same port but is also able to use separate ports, shall additionally, within the same "m=" line, indicate an SDP "rtcp-mux" attribute according to RFC 5761 [38] as updated by RFC 8035 [42]; and

e) if the WIC only supports sending and receiving multiplexed RTP and RTCP on the same port, shall additionally, within the same "m=" line, indicate an SDP "rtcp-mux-only" attribute according to RFC 8858 [39].

7.2.3 WIC terminating call

Upon receipt of an SDP offer, the WIC shall:

a) perform the ICE procedures as defined in RFC 8445 [45] and RFC 8839 [46], and possibly RFC 6544 [28]; and

b) generate an SDP answer and send it towards the eP-CSCF using the appropriate signalling protocol as described in clause 7.2.1.

Upon receiving an SDP offer containing an RTP based media:

– transported using RFC 5763 [5], with the proto field in the "m=" line containing the "UDP/TLS/RTP/SAVPF" value according to RFC 5764 [6]; and

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

and if the WIC accepts the RTP based media, then the WIC shall generate the SDP answer with the related RTP based media transported. In order to do so, the WIC:

a) shall use RFC 5763 [5], and provide the proto field in the "m=" line containing the "UDP/TLS/RTP/SAVPF" value according to RFC 5764 [6];

b) may additionally, within the same "m=" line, offer TCP transport protocol with appropriate ICE candidates according to RFC 6544 [28]; and

c) if the WIC desires to receive multiplexed RTP and RTCP on the same port and the corresponding "m=" line in the SDP offer contained SDP "rtcp-mux" attribute or if the WIC only supports sending and receiving multiplexed RTP and RTCP on the same port, shall additionally, within the same "m=" line, indicate an SDP "rtcp-mux" attribute according to RFC 5761 [38] as updated by RFC 8035 [42].

7.2.4 WIC emergency call

A WIC shall not attempt to establish a session when the WIC can detect that the number dialled is an emergency number.

NOTE 1: Emergency calls originated from a WIC are not supported in this version of the specification.

If a WIC

a) receives a response indicating that a UE non detected emergency call has happened and was not supported by the network; and

b) supports detecting such responses as indicating UE non detected emergency call;

then the WIC shall:

1) indicate to the user that an attempt for an UE non detected emergency call has happened and was not supported by the network; and

2) not retry the emergency call via W2 interface.

If Gm based W2 is used, then the response indicating rejection of a request for a UE non detected emergency call is a 380 (Alternative Service) response with contents as specified in 3GPP TS 24.229 [3] clause 5.2.10.4.

NOTE 2: The details how to indicate the rejection of a UE non detected emergency call to the user are not specified.

7.3 WWSF (WebRTC Web Server Function)

No additional procedure is specified for WWSF.

7.4 eP-CSCF (P-CSCF enhanced for WebRTC)

7.4.1 General

The eP-CSCF using Gm towards the WIC shall follow the procedures as described in 3GPP TS 24.229 [3]. For the eP-CSCF using Gm, the appropriate signalling protocol is defined in 3GPP TS 24.229 [3].

The eP-CSCF using non-Gm SIP towards the WIC shall support RFC 3261 [19]. For the eP-CSCF using non-Gm, the appropriate signalling protocol is defined in RFC 3261 [19].

The eP-CSCF using non-SIP towards the WIC shall support RFC 3264 [20]. For the eP-CSCF using non-SIP, the appropriate signalling protocol is out of scope of this specification.

The eP-CSCF shall support RFC 5763 [5] and RFC 5764 [6].

The eP-CSCF shall support RFC 5761 [38] as updated by RFC 8035 [42] and RFC 8858 [39], and the eP-CSCF shall support sending and receiving RTP and RTCP either on the same port or on separate ports.

Support of media plane optimization as specified in 3GPP TS 23.228 [4] is optional. If the eP-CSCF supports media plane optimization, then the eP-CSCF shall in addition to the procedures in clauses 7.4.2 and 7.4.3 apply the procedures in clause 7.4.5.

7.4.2 WIC originating call

Upon receipt of an SDP offer, the eP-CSCF shall:

a) perform ICE procedures as defined in 3GPP TS 24.229 [3];

b) not perform OMR procedures; and

c) generate an SDP offer based on the SDP offer received from the WIC and forward it using the appropriate signalling protocol as described in clause 7.4.1. The eP-CSCF shall replace the SDP offer with updated SDP provided by eIMS-AGW, which contains the eIMS-AGW IP addresses and ports. The eP-CSCF shall not use bundled media as described in RFC 8843 [25], i.e. the eP-CSCF shall remove the SDP group attribute BUNDLE value, and any m- line that in the received SDP offer contained an SDP "bundle-only" attribute, from the SDP offer. The eP-CSCF shall remove every instance of the SDP "rtcp-mux-only" attribute from the SDP offer.

NOTE: At this point, the eP-CSCF interacts with eIMS-AGW to reserve resources and provide the information needed for media handling. The details of the interaction between eP-CSCF and eIMS-AGW are out of scope of this document.

Upon receiving an SDP offer from the served WIC containing an DTLS-SRTP based media stream with end-to-access-edge protection, i.e. an "m=" line:

– with the proto field containing the "UDP/TLS/RTP/SAVPF" value as specified in RFC 5764 [6]; and

– with the SDP "a=3ge2ae:requested" attribute or, if permitted by operator policy, without the SDP "a=3ge2ae:requested" attribute;

the eP-CSCF shall invoke IMS-ALG procedures, shall remove the SDP "a=3ge2ae:requested" attribute, if included, and the SDP fingerprint attribute (defined in RFC 8122 [15]) and shall act as defined in 3GPP TS 24.229 [3] as far as SDP and RTP is concerned.

Upon receiving an SDP answer over the Mw interface, for each DTLS-SRTP based media stream with end-to-access-edge protection of the SDP offer from the served WIC which is accepted in the received SDP answer, the eP-CSCF shall invoke IMS-ALG procedures. In the SDP answer to served WIC, the eP-CSCF

a) shall use RFC 5763 [5] and shall provide the proto field in the "m=" line with the "UDP/TLS/RTP/SAVPF" value according to RFC 5764 [6]; and

b) may additionally, within the same "m=" line, offer TCP transport protocol with appropriate ICE candidates according to RFC 6544 [28].

If the SDP offer contained bundled media as described in RFC 8843 [25], the eP-CSCF shall reject the bundling of media, i.e. the eP-CSCF shall not add a SDP group BUNDLE attribute to the SDP answer, and the eP-CSCF shall assign a zero port value to any m- line that in the SDP offer contained an SDP "bundle-only" attribute.

NOTE: Stage 2 has specified that the architecture does not support media multiplexing that is defined for WebRTC, so the SDP answer sent to the served WIC will not contain bundled media.

If one or more "m=" lines related to the RTP based media in the received SDP answer did not contain an SDP "rtcp-mux" attribute, the corresponding "m=" lines in the SDP offer from the served WIC contained an SDP "rtcp-mux" attribute, and the eP-CSCF desires to receive multiplexed RTP and RTCP on the same port, then the eP-CSCF shall add the SDP "rtcp-mux" attribute to the corresponding "m=" lines in the SDP answer, as described in RFC 5761 [38] as updated by RFC 8035 [42]. If one or more "m=" lines in the SDP offer contained an SDP "rtcp-mux-only" attribute, the eP-CSCF shall add an SDP "rtcp-mux" attribute to the corresponding "m=" lines in the answer, as described in RFC 8858 [39].

7.4.3 WIC terminating call

Upon receiving an SDP offer over the Mw interface with an RTP based media, for each RTP based media, the eP-CSCF:

1) shall invoke IMS-ALG procedures;

2) shall perform ICE procedures as defined in 3GPP TS 24.229 [3];

3) shall not perform OMR procedures; and

4) in the SDP offer to served WIC:

– shall indicate the transport protocol according to RFC 5763 [5], with the proto field in the "m=" line containing the "UDP/TLS/RTP/SAVPF" value according to RFC 5764 [6];

– may additionally, within the same "m=" line, offer TCP transport protocol with appropriate ICE candidates according to RFC 6544 [28];

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

– shall, within each RTP-based "m=" line, include the SDP "rtcp-mux" attribute according to RFC 5761 [38] as updated by RFC 8035 [42].

NOTE: Stage-2 has specified that the architecture does not support media multiplexing that is defined for WebRTC, so the SDP offer sent to the served WIC will not contain bundled media.

Upon receipt of an SDP answer, the eP-CSCF:

a) shall perform ICE procedures as defined in3GPP TS 24.229 [3];

b) shall generate an SDP answer based on the SDP answer received from the WIC and forward it using the appropriate signalling protocol as described in clause 7.4.1;

c) for each RTP based media of the SDP offer from the remote UE which is accepted in the SDP answer shall remove the SDP fingerprint attribute (defined in RFC 8122 [15]); and

d) shall act as defined in 3GPP TS 24.229 [3] as far as SDP and RTP is concerned;

7.4.4 WIC emergency call

If the eP-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a registered user, the eP-CSCF shall inspect the Request-URI. The eP-CSCF shall consider the Request URI of the initial request as a emergency service identifier, if it is an emergency numbers or an emergency service URN from the configurable lists that are associated with:

1) the country of the operator to which the eP-CSCF belongs to; and

2) the country of roaming partners, if the request originates from a different country then the country of the network to which the eP-CSCF belongs to. If Gm based W2 is used, then access technology specific procedures are described in each access technology specific annex of 3GPP TS 24.229 [3] to determine from which country and roaming partner the request was originated; and

3) if the country from which the request originates cannot be determined then all lists are associated.

If the eP-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method matches one of the emergency service identifiers in the associated lists then the eP-CSCF shall:

A) If item 1) applies then determine whether the request originates from the same country as the country of the network to which the eP-CSCF belongs. If Gm based W2 is used, then access technology specific procedures are used as described in each access technology specific annex of 3GPP TS 24.229 [3] to determine from which country and roaming partner the request was originated. If the request originates from the same country, then the eP-CSCF depending on operator policy shall:

a) reject the request as appropriate for the signalling in use. If Gm based W2 is used, then send 380 (Alternative Service) response with the contents as specified in 3GPP TS 24.229 [3] clause 5.2.10.4; or

b) proceed the request as specified in of 3GPP TS 24.229 [3] clause 5.2.10.4 for the case where the request is not rejected; or

B) in all other cases the eP-CSCF shall reject the request as appropriate for the signalling in use. If Gm based W2 is used, then send a 380 (Alternative Service) response with the contents as specified in 3GPP TS 24.229 [3] clause 5.2.10.4.

7.4.5 Media optimization procedure

7.4.5.1 WIC originating call

If an eP-CSCF forwards an SDP offer from the WIC, and supports media plane optimization, and does not need to perform legal interception, then the eP-CSCF shall in addition to the SDP information described in clause 7.4.2, encapsulate the previously received SDP offer from the WIC. In order to do so, the eP-CSCF shall:

1) encapsulate each received session level SDP attribute into an "tra-att" attribute and add this attribute as a session level attribute;

2) encapsulate each received session-level bandwidth line into an "tra-bw" attribute and add this attribute as a session level attribute;

3) if the eP-CSCF decides to include a session level contact line in the SDP offer, include the address information as received from the eIMS-AGW in that contact line and also encapsulate the address information into an "tra-contact" attribute and add this attribute as a session level attribute;

4) provide the total number of media lines in the SDP offer the eP-CSCF forwards, excluding any media lines with port zero, in the "tra-media-line-number" attribute;

5) for all media lines in the SDP offer sent on the Mw interface that relate to media stream(s) that are transported within data channel(s) within the same SCTP association between the eP-CSCF and the WIC, provide the "tra-SCTP-association" SDP attribute with a number designating the SCTP association that shall be assigned by the eP-CSCF and that shall be unique within the related SIP dialogue;

6) for each media line in the SDP offer sent on the Mw interface that does not relate to a data channel, encapsulate each received media level attribute except for the "fingerprint" attribute(s) and the "tls-id" attribute (that are handled according to bullets 9d and 9e below) of the corresponding received media line into an "tra-att" attribute, and add this attribute as a media level attribute for the media line;

7) for each media line in the SDP offer sent on the Mw interface that is the first media line within the SDP offer that relates to a data channel within one SCTP association, encapsulate each received media level attribute of the corresponding received media line, except for the "fingerprint" attribute(s) and the "tls-id" attribute (that are handled according to bullets 9d and 9e below) and except for "dcmap" and "dcsa" attributes corresponding to media streams described in different media lines on the Mw interface, into an "tra-att" attribute, and add this attribute as a media level attribute for the media line;

8) for each media line in the SDP offer sent on the Mw interface that is a subsequent media line within the SDP offer that relates to a data channel within one SCTP association, encapsulate each received "dcmap" and "dcsa" media level attribute of the corresponding received media line corresponding to the media stream described in this media lines on the Mw interface, into an "tra-att" attribute, and add this attribute as a media level attribute for this media line; and

9) 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) if the eP-CSCF decides to include a media level contact line in the SDP offer, include the address information as received from the eIMS-AGW in that contact line and also encapsulate the address information into an "tra-contact" attribute and add this attribute as a media level attribute for the media line;

b) encapsulate the corresponding received media line into an "tra-m-line" attribute and add this attribute as a media level attribute for the media line, replacing the port number with a port number provided by the eIMS-AGW;

c) encapsulate each received bandwidth line for the corresponding received media line into an "tra-bw" attribute, and add this as a media level attribute for the media line;

d) if the eP-CSCF is configured to negotiate media plane optimization where the DTLS protocol layer is passed, encapsulate the received "fingerprint" attribute(s) and the received "tls-id" attribute of the corresponding received media line into "tra-att" attributes, and add these attributes as a media level attributes for the media line; and

e) if the eP-CSCF is configured to negotiate media plane optimization where the DTLS protocol layer is terminated, remove the received "fingerprint" attribute(s) and the received "tls-id" attribute of the corresponding received media line, encapsulate a "tls-id" attribute" with a value assigned by the eP-CSCF into an "tra-att" attribute, encapsulate a "fingerprint" attribute as provided by the eIMS-AGW into an "tra-att" attribute, and add these attributes as a media level attributes for the media line.

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

NOTE 2: When interacting with the eIMS-AGW to reserve resources and provide the information needed for media handling the eP-CSCF will ask for resources suitable for the media described in the SDP offer outside the "tra-m-line", "tra-att" and "tra-bw" SDP attributes. If the eP-CSCF is configured to negotiate media plane optimization where the DTLS protocol layer is terminated, the eP-CSCF will also request a "fingerprint" attribute from the eIMS-AGW. The details of the interaction between the eP-CSCF and the eIMS-AGW are out of scope of this document.

If an eP-CSCF receives an SDP answer over Mw interface and the SDP answer includes "tra-m-line" media level SDP attributes, the eP-CSCF shall:

1) when invoking the IMS-ALG procedures, use the media information received in "tra-m-line", "tra-att", and "tra-bw" SDP attributes;

2) remove all received SDP attributes and bandwidth lines from the forwarded SDP answer;

NOTE 3: This also includes the "tra-m-line", "tra-att", "tra-SCTP-association", "tra-media-line-number" and "tra-bw" SDP attributes.

3) de-encapsulate any SDP attributes received within session level "tra-att" SDP attributes and provide them as session level attributes in the SDP answer towards the WIC;

4) de-encapsulate any bandwidth lines received within session level "tra-bw" SDP attributes and provide them as session level bandwidth lines in the SDP answer towards the WIC;

5) for all media lines marked to belong to the same SCTP association by the "tra-SCTP-association" media level SDP attribute, provide a single media line in the SDP answer sent towards the WIC;

6) for each media line in the SDP answer sent towards the WIC:

a) de-encapsulate the media line received within the "tra-m-line" SDP attribute and provide it as media line in the SDP answer towards the WIC, replacing the port number with the port allocated by its eIMS-AGW;

b) de-encapsulate any media level SDP attributes received within "tra-att" SDP attributes for the corresponding media line except for the "fingerprint" attribute(s) and the received "tls-id" attribute (that are handled according to bullets 6d and 6e below), and provide them as media level attributes for the media line in the SDP answer towards the WIC;

c) de-encapsulate any media level bandwidth lines received within "tra-bw" SDP attributes for the corresponding media line and provide them as media level bandwidth line for the media line in the SDP answer towards the WIC;

d) if the eP-CSCF is configured to negotiate media plane optimization where the DTLS protocol layer is passed, de-encapsulate the received "fingerprint" attribute(s) and the received "tls-id" attribute within "tra-att" SDP attributes of the corresponding received media line, and add these attributes as a media level attributes for the media line; and

e) if the eP-CSCF is configured to negotiate media plane optimization where the DTLS protocol layer is terminated, remove the received "fingerprint" attribute(s) and the received "tls-id" attribute within "tra-att" SDP attributes of the corresponding received media line, and insert a "tls-id" attribute" with a value assigned by the eP-CSCF and a "fingerprint" attribute as provided by the eIMS-AGW as media level attributes for the media line;

7) include the IP address received from the eIMS-AGW in the contact line in the SDP answer sent towards the WIC; and

8) use the so generated SDP answer to invoke IMS-ALG procedures.

NOTE 4: When interacting with eIMS-AGW the eP-CSCF will deactivate media plane interworking in the eIMS-AGW. Depending on configuration, the eP-CSCF will either configure the eIMS-AGW to terminate or to transparently forward the DTLS layer for transparent media. Terminating the DTLS protocol layer for all calls can improve the transparency of LI. The details of this interaction are out of scope of this document. The eP-CSCF will use the "tra-SCTP-association" SDP attributes to determine which media streams need to be multiplexed into the same SCTP association.

7.4.5.2 WIC terminating call

If an eP-CSCF receives an SDP offer over the Mw interface and the eP-CSCF supports media plane optimization, then the eP-CSCF shall determine for each media line whether media plane optimization is to be applied. Media plane optimization is to be applied when all of the following conditions are met:

1) the eP-CSCF forwards the SDP offer towards a WIC;

2) the eP-CSCF does not need to perform legal interception;

3) for each media line, either a "tra-m-line" or a "tra-SCTP-association" media level SDP attribute has been received;

4) if a session level contact line is included in the received SDP offer, a "tra-contact" session level SDP attribute is also included in the received SDP offer, and the "contact-line" is the same as encapsulated within the " tra-contact" attribute;

5) if a media level contact line is included in the received SDP offer for any media line, a "tra-contact" media level SDP attribute is also included in the received SDP offer for that media line, and the "contact-line" is the same as encapsulated within the "tra-contact" attribute; and

6) a "tra-media-line-number" SDP attribute is included in the received SDP offer and the number in the received "tra-media-line-number" SDP attribute matches the real number of media lines in the SDP, excluding any media lines with port zero.

If media plane optimization is to be applied, then the eP-CSCF shall:

1) when invoking the IMS-ALG procedures, use the media information received in "tra-contact", "tra-m-line", "tra-att", "tra-SCTP-association" and "tra-bw" SDP attributes;

NOTE 1: When interacting with eIMS-AGW the eP-CSCF will deactivate media plane interworking in the eIMS-AGW. The details of this interaction are out of scope of this document. Depending on configuration, the eP-CSCF will either configure the eIMS-AGW to terminate or to transparently forward the DTLS layer for transparent media. Terminating the DTLS protocol layer for all calls can improve the transparency of LI. The eP-CSCF will use the "tra-SCTP-association" SDP attribute to determine which media streams need to be multiplexed into the same SCTP association.

2) remove all received SDP attributes and bandwidth lines from the forwarded SDP offer;

NOTE 2: This also includes the "tra-contact", "tra-m-line", "tra-att", "tra-SCTP-association", "tra-media-line-number" and "tra-bw" SDP attributes.

3) de-encapsulate any SDP attributes received within session level "tra-att" SDP attributes and provide them as session level attributes in the SDP offer towards the WIC;

4) de-encapsulate any bandwidth lines received within session level "tra-bw" SDP attributes and provide them as session level bandwidth lines in the SDP offer towards the WIC;

5) for all media lines marked to belong to the same SCTP association by the "tra-SCTP-association" media level SDP attribute, provide a single media line in the SDP offer sent towards the WIC; and

6) for each media line in the SDP offer sent towards the WIC:

a) de-encapsulate the media line received within the "tra-m-line" SDP attribute and provide it as media line in the SDP offer towards the WIC, replacing the port number with the port allocated by its eIMS-AGW;

b) de-encapsulate any media level SDP attributes received within "tra-att" SDP attributes for the corresponding media line except for the "fingerprint" attribute(s) and the "tls-id" attribute (that are handled according to bullet 6d and 6e below), and provide them as media level attributes for the media line in the SDP offer towards the WIC;

e) if the eP-CSCF is configured to negotiate media plane optimization where the DTLS protocol layer is terminated, remove the received "fingerprint" attribute(s) and the received "tls-id" attribute within "tra-att" SDP attributes of the corresponding received media line, and insert a "tls-id" attribute" with a value assigned by the eP-CSCF and a "fingerprint" attribute as provided by the eIMS-AGW as a media level attributes for the media line; and

7) include the IP address received from the eIMS-AGW in the contact line in the SDP offer towards the WIC.

If media plane optimization is not to be applied, then the eP-CSCF shall:

1) remove all received the "tra-contact", "tra-m-line", "tra-att", "tra-SCTP-association", "tra-media-line-number" and "tra-bw" SDP attributes from the forwarded SDP offer;

2) when invoking the IMS-ALG procedures, use the media information received outside "tra-contact", "tra-m-line", "tra-att", "tra-SCTP-association" and "tra-bw" SDP attributes; and

3) not include any "tra-contact", "tra-m-line", "tra-att", "tra-SCTP-association", "tra-media-line-number" and "tra-bw" SDP attributes in the SDP answer over the Mw interface.

If the eP-CSCF receives an SDP answer from the WIC and the eP-CSCF decided to apply media plane optimization when processing the corresponding SDP offer, then the eP-CSCF shall:

1) generate an SDP answer based on the related SDP offer and the SDP answer received from the WIC which is compliant with RFC 3264 [20];

NOTE 3: The selected formats of the answer need to be compliant with the offered formats. Media lines are disabled via port 0 if the corresponding media lines are disabled in the answer from the WIC. If data channels within one SCTP association are offered via dcmap attributes, the WIC can reject a data channel by excluding the corresponding dcmap attribute from the answer. The eP-CSCF then disables the media line, where the corresponding "tra-att:dcmap" attribute has been received in the SDP offer.

2) encapsulate each received session level SDP attribute into an " tra-att" attribute and add this attribute as a session level attribute;

3) encapsulate each received session-level bandwidth line into an "tra-bw" attribute and add this attribute as a session level attribute;

4) for all media line in the SDP answer sent on the Mw interface that relate to media stream(s) that are transported within the data channels within the same SCTP association between the eP-CSCF and the WIC, provide the "tra-SCTP-association" SDP attribute with a number designating the SCTP association that shall be the same as received for the corresponding media line in the SDP offer on the Mw interface;

5) for each media line in the SDP answer sent on the Mw interface that does not relate to a data channel, encapsulate each received media level attribute of the corresponding received media line except for the "fingerprint" attribute(s) and the "tls-id" attribute (that are handled according to bullet 8c and 8d below) into an "tra-att" attribute, and add this attribute as a media level attribute for the media line;

6) for each media line in the SDP answer sent on the Mw interface that is the first media line within the SDP answer that relates to a data channel within one SCTP association, encapsulate each received media level attribute of the corresponding received media line, except for the "fingerprint" attribute(s) and the "tls-id" attribute (that are handled according to bullets 8c and 8d below) and except for "dcmap" and "dcsa" attributes corresponding to media streams described in different media lines on the Mw interface, into an "tra-att" attribute, and add this attribute as a media level attribute for the media line;

7) for each media line in the SDP answer sent on the Mw interface that is a subsequent media line within the SDP answer that relates to a data channel within one SCTP association, encapsulate each received "dcmap" and "dcsa" media level attribute of the corresponding received media line corresponding to the media stream described in this media lines on the Mw interface, into an "tra-att" attribute, and add this attribute as a media level attribute for this media line; and

8) for each media line in the SDP answer sent on the Mw interface that does not relate to a data channel or that is the first media line within the SDP answer that relates to a data channel within one SCTP association:

a) encapsulate the corresponding received media line into an "tra-m-line" attribute and add this attribute as a media level attribute for the media line, replacing the port number with a port number provided by the eIMS-AGW;

b) encapsulate each received bandwidth line for the corresponding received media line within into an "tra-bw" attribute, and add this as a media level attribute for the media line;

c) if the eP-CSCF is configured to negotiate media plane optimization where the DTLS protocol layer is passed, encapsulate the received "fingerprint" attribute(s) and the received "tls-id" attribute of the corresponding received media line into "tra-att" attributes, and add these attributes as a media level attributes for the media line; and

d) if the eP-CSCF is configured to negotiate media plane optimization where the DTLS protocol layer is terminated, remove the received "fingerprint" attribute(s) and the received "tls-id" attribute of the corresponding received media line, encapsulate a "tls-id" attribute" with a value assigned by the eP-CSCF into an "tra-att" attribute, encapsulate a "fingerprint" attribute as provided by the eIMS-AGW into an "tra-att" attribute, and add these attributes as a media level attributes for the media line; and

9) include the IP address received from the eIMS-AGW in the contact line.