Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.334  Word version:  17.2.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.11…   5.12…   5.14…   5.18…   5.19…   5.20…   5.21…   6…   6.1.6…   6.1.11…   6.2…   6.2.10…   6.2.10.3.1.2   6.2.10.3.2   6.2.10.4…   6.2.10.4.3…   6.2.10.5   6.2.10.6…   6.2.10A…   6.2.13…   6.2.14…   6.2.14.3   6.2.14.4…   6.2.15…   6.2.17…   6.2.17.3…   6.2.17.5…   6.2.18…   6.2.20   6.2.21…   6.2.22…   6.2.22.3…   6.2.22.3.2   6.2.23   6.2.24   6.2.25   7   8…   8.3   8.4   8.5…   8.23…

 

5.18  Interactive Connectivity Establishment (ICE) |R12|p. 53

5.18.1  Generalp. 53

The IMS-ALG and the IMS-AGW may support ICE functionality as specified in RFC 8445 and RFC 8839, and TS 24.229 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 RFC 8445.
An IMS-ALG and IMS-AGW supporting ICE lite may in addition support ICE for TCP according to RFC 6544.
The IMS-ALG and IMS-AGW shall only use host candidates as local ICE candidates.
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.
Up

5.18.2  ICE litep. 53

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;
  • 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.
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;
  • 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;
  • 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.
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 Section 7.3 of RFC 8445.
When receiving a request to act as STUN server, the IMS-AGW shall be prepared to answer STUN binding request according to Section 7.3 of RFC 8445. 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.
Up

5.18.3  Full ICEp. 55

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;
  • 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:
    1. if the "a=ice-pacing" attribute was present in the received SDP answer, the received pacing value; or
    2. 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 Section 6.1.1 of RFC 8445;
  • 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:
    1. if the "a=ice-pacing" attribute was present in the received SDP answer, the received pacing value; or
    2. otherwise the default pacing value of 50 ms;
  • shall determine the role of IMS-ALG in ICE (controlling or controlled) according to Section 6.1.1 of RFC 8445;
  • 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 Section 4.4.1 of RFC 8839 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 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.
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 RFC 8445).
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 Section 7.3 of RFC 8445.
When receiving a request to act as STUN server, the IMS-AGW shall be prepared to answer STUN binding request according to Section 7.3 of RFC 8445. 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.
When receiving a request to perform connectivity checks and to report connectivity check results, the IMS AGW:
  • shall compute ICE candidate pairs according to Section 6.1.2 of RFC 8445;
  • shall schedule checks for the ICE candidate pairs according to Section 6.1.4 of RFC 8445;
  • shall send STUN connectivity checks for the scheduled checks according to Section 7.2 of RFC 8445;
  • 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.
Up

5.18.4  STUN consent freshness for WebRTCp. 57

The eIMS-AGW, which implements ICE, shall support the STUN consent freshness test defined in RFC 7675.
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.
Up

Up   Top   ToC