9.2.12 Interactive Connectivity Establishment Support

29.1633GPPInterworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networksTS

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

9.2.12.1 General

The MGCF and the IM-MGW may support ICE functionality as specified in IETF RFC 8445 [156] and IETF RFC 8839 [157], and 3GPP TS 24.229 [9] to support a UE residing behind a remote NAT. The present clause describes the requirements for MGCF and IM-MGW when the ICE procedures are supported.

Support of full ICE functionality is optional, but if ICE is supported, the MGCF and IM-MGW shall at least support ICE lite as specified in IETF RFC 8445 [156].

The MGCF and IM-MGW shall only use host candidates as local ICE candidates.

NOTE 1: MGCF and IM-MGW are not located behind a NAT (from perspective of the ICE deployment model according to figure 1 in IETF RFC 8445 [156]).

When the MGCF detects no ICE parameters in the received SDP, it shall not configure the IM-MGW to apply any ICE and STUN related procedures (see IETF RFC 8489 [158]) toward the call leg from where the SDP has been received.

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

If the IM-MGW does not indicate the support of STUN procedures, or if the MGCF is configured not to apply ICE toward a call leg, the MGCF shall not configure the IM-MGW to apply STUN procedures.

9.2.12.2 ICE lite

If the MGCF is configured to use ICE lite, or supports only ICE lite, or controls an IM-MGW that only support ICE lite, the procedures in the present clause apply.

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

– shall request the IM-MGW 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 1: Requesting only one host candidate per m-line prevents that the MGCF 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 configure the IM-MGW 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 IM-MGW;

– 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 sends;

– shall include the host candidate and related ICE user name fragment and password received from the IM-MGW in the SDP answer it sends; and

– shall include the "a=ice-lite" attribute in the SDP answer it sends.

If the MGCF receives SDP offer with ICE candidate information and an "a=ice-lite" attribute, the MGCF shall not apply ICE and shall 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 MGCF sends an SDP offer and ICE is to be applied, the MGCF:

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

– shall configure the IM-MGW 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 IM-MGW 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 MGCF then receives an SDP answer with candidate information from the call leg where ICE is to be applied, the MGCF may provide received remote ICE candidates and the received related ICE user name fragment and password to the IM-MGW.

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

When receiving a request for an ICE user name fragment and password, the IM-MGW shall generate an ICE user name fragment and password and send it to the MGCF within the reply. The IM-MGW 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 [156].

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

9.2.12.3 Full ICE

If the MGCF supports and is configured to use full ICE, and controls an IM-MGW that supports full ICE, the procedures in the present clause apply.

If the MGCF receives an initial SDP offer with ICE candidate information, the MGCF:

– shall request the IM-MGW 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;

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

– shall configure the IM-MGW 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 IM-MGW;

– shall provide the remote pacing value to the IM-MGW 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 sends;

– shall include the "a=ice-pacing" attribute with the pacing value provided by the IM-MGW in the SDP answer it sends;

– shall include the host candidate and related ICE user name fragment and password received from the IM-MGW in the SDP answer it sends;

– shall determine the role of MGCF in ICE (controlling or controlled) according to clause 6.1.1 of IETF RFC 8445 [156];

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

– shall configure the IM-MGW to report connectivity check results; and

– shall configure the IM-MGW to report a new peer reflexive candidate if discovered during the connectivity check.

If the MGCF sends an SDP offer and ICE is to be applied, the MGCF:

– shall request the IM-MGW 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 IM-MGW to provide the pacing value for connectivity checks;

– shall configure the IM-MGW 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 it sends;

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

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

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

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

– shall provide the remote pacing value to the IM-MGW 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 MGCF in ICE (controlling or controlled) according to clause 6.1.1 of IETF RFC 8445 [156];

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

– shall configure the IM-MGW to report connectivity check results; and

– shall configure the IM-MGW to report a new peer reflexive candidate if discovered during the connectivity check.

When the MGCF is informed by the IM-MGW about new peer reflexive candidate(s) discovered by the connectivity checks, the MGCF shall configure the IM-MGW to perform additional connectivity checks for those candidates,

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

After the initial SDP offer-answer exchange, the MGCF 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 are the same as received in the previous SDP, the MGCF shall then configure the IM-MGW to send media towards the address and port in the SDP "c=" line, "m=" line. If the STUN user name and password in the SDP offer differ from the ones received in the previous SDP (i.e. the peer restarts ICE), the MGCF shall apply the same procedures as for the initial SDP offer.

When receiving a request to provide a desired pacing value for connectivity checks (Ta timer value), the IM-MGW 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 IM-MGW shall compare the own desired Ta timer value with the Ta timer value provided by the MGCF and shall use the higher value for connectivity checks (as specified in IETF RFC 8445 [156]).

When receiving a request to perform connectivity checks and to report connectivity check results, the IM-MGW:

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

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

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

– shall inform the MGCF about successful candidate pairs determined by the connectivity checks;

– shall inform the MGCF 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.

9.2.12.4 Procedures for Interactive Connectivity Establishment (ICE)

9.2.12.4.1 ICE lite

Figure 9.2.12.4.1.1 shows a message sequence chart example for performing the ICE lite procedure towards the offerer.

Figure 9.2.12.4.1.1: Procedure for interactive connectivity establishment using ICE lite towards the offerer

9.2.12.4.2 Full ICE

Figure 9.2.12.4.2.1 shows a message sequence chart example for performing the full ICE procedure towards the offerer.

Figure 9.2.12.4.2.1: Procedure for interactive connectivity establishment using full ICE towards the offerer

9.2.12.4.3 Connectivity check result notification (full ICE)

Figure 9.2.12.4.3.1 shows the message sequence chart example for an ICE connectivity check result Event.

Figure 9.2.12.4.3.1: Procedure to report ICE connectivity check result

9.2.12.4.4 New peer reflexive candidate notification (full ICE)

Figure 9.2.12.4.4.1 shows the message sequence chart example for additional connectivity check when new peer reflexive candidate is discovered in full ICE.

Figure 9.2.12.4.4.1: Procedure to perform additional connectivity check upon the report of new peer reflexive candidate