G.5 Network elements for employing NAT Traversal for ICE and Outbound

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

G.5.1 General requirements

In addition to the general requirements outline in clause G.1.1, the following NAT traversal solution also addresses the following additional requirements:

– Does not require the network to be aware of the presence of a NAT;

– Avoid unnecessarily long media paths due to media pinning;

– It shall be possible to establish communication towards a remote UE that does not support of the functionality listed in G.5;

– Minimize the impacts on Policy and Charging Control functionality.

G.5.2 ICE

G.5.2.1 Overview

The Interactive Connectivity Establishment (ICE) described in IETF RFC 5245 [45] defines a methodology for media traversal of NAT devices.

However, ICE is not a complete solution in of itself as ICE only addresses address advertisement and NAT binding maintenance. ICE does not address RTP and RTCP port symmetry requirements or non-sequential RTP and RTCP port assignment. A complete UE managed NAT traversal solution shall take into account each of these issues.

G.5.2.2 Required functions of the UE

When supporting ICE, the UE is responsible for managing the overall NAT traversal process and for invoking the various protocol mechanisms to implement the NAT traversal approach. As such, the following functions shall be performed by the UE:

– STUN relay server and STUN server discovery;

NOTE: A configuration mechanism can be used to provision STUN server and STUN relay server addresses in the UE.

– Transmission of media packets from the same port on which it expects to receive media packets;

– RTCP port advertisement.

– ICE functionality which includes:

– Maintaining of NAT bindings to insure inbound media packets are allowed to traverse the NAT device.

– Address advertisement, which consists of the following operations:

– Gathering candidate addresses for media communications;

– Advertising the candidate addresses in a special SDP attribute (a=candidate) along with the active transport address in the m/c lines of the SDP.

– Perform connectivity checks on the candidate addresses in order to select a suitable address for communications.

Depending on the results of the connectivity checks, one of the candidate addresses may be promoted to become the active transport address.

Depending on the active transport address, provide additional information in the session description to insure that correct policy and charging functionality can be applied on relayed media packets.

Given the desire to minimize session establishment delays during connectivity checks, the UE shall advertise its active address in the SDP offer or answer in the following order based on their availability:

1. STUN relay server assigned address;

2. STUN derived address;

3. Locally assigned address.

G.5.2.3 Required functions of the STUN relay server

The STUN relay server and associated signalling requirements are documented in IETF RFC 5766 [46] and its use is detailed in IETF RFC 5245 [45]. No additional requirements are placed on this server.

NOTE: While it is not required that a STUN relay server be deployed in the network, a STUN Relay server would allow for media exchange in the presence of all NAT types.

G.5.2.4 Required functions of the STUN server

The STUN server and associated signalling requirements are documented in RFC 5389 [47] and its use is detailed in IETF RFC 5245 [45]. No additional requirements are placed on this server.

NOTE: While it is not required that STUN servers be deployed in the network, a STUN server would allow for UEs to discover the WAN facing transport address of the NAT. Such discovery may minimize the need for STUN Relay server resources by allowing UEs to directly exchange media in the presence of the majority of NAT types.

G.5.3 Outbound

G.5.3.1 Overview

RFC 5626 [48] "Managing Client-Initiated Connections in the Session Initiation Protocol" (Outbound) defines a methodology for signalling traversal of NAT devices. This methodology involves the establishment of flows to allow for the routing of inbound dialog initiating requests and the maintenance of the flow through keep-alive messages. Outbound does not however address inbound response routing or inbound mid-dialog requests. A complete UE managed NAT traversal solution shall take into account each of these issues.

This clause is restricted to the use of Outbound in the context of SIP NAT traversal and not to the usage of Outbound for multiple registration support.

NOTE: ICE and Outbound are not dependent on each other, and can be deployed separately or together. The STUN keep-alive function, for SIP signalling, can also be implemented as a standalone function, without ICE or Outbound.

G.5.3.2 Required functions of the P‑CSCF

When supporting Outbound, the P‑CSCF’s primary role in NAT traversal is to ensure that requests and responses occur across a flow for which there is an existing NAT binding. The P‑CSCF shall ensure that inbound dialog initiating requests can be forwarded to the UE on a flow for which there is an existing NAT binding.

The P‑CSCF shall ensure that all responses to the UE including those from mid-dialog requests are sent to the same source IP address and port which the request was received from.

The P‑CSCF shall also implement a limited STUN server functionality to support the STUN keep-alive usage as defined in RFC 5389 [47] which is used by the UE to maintain the NAT bindings.

NOTE: The STUN server implementation on the P‑CSCF need only support the STUN functionality required for the STUN binding request operation.

Additionally the P‑CSCF shall transmit signalling packets from the same port on which it expects to receive signalling packets.

G.5.3.3 Required functions of the S‑CSCF

When supporting Outbound, the S‑CSCF should be responsible for indicating to the UE that Outbound procedures are supported.

G.5.3.4 Required functions of the UE

When supporting Outbound, the UE is responsible for managing the overall NAT traversal process and for invoking the various protocol mechanisms to implement the NAT traversal approach. As such, the following functions shall be performed by the UE:

– Maintaining of NAT bindings between the UE and the P‑CSCF through the use of a keep-alive mechanism to insure inbound signalling packets are allowed to traverse the NAT device.

NOTE: Solutions to determine the frequency of the keep-alive are not defined in this version of the specification. A configuration mechanism can be used in place of a dynamic discovery process.

– Transmission of signalling packets from the same port on which it expects to receive signalling packets;

– Establishment of signalling flows to its assigned P‑CSCF(s) during registration.

NOTE 1: The UE can determine that STUN based keep-alive can be used towards the P‑CSCF based on the presence of the STUN keep-alive parameter from the P‑CSCF SIP URI received during P‑CSCF discovery.

NOTE 2: If a UE supports only STUN keep-alives, but not Outbound, it does not need to determine Outbound support, and it does not need to register flows as defined by Outbound. It only sends STUN requests to the P‑CSCF to keep NAT bindings open.