The Interactive Connectivity Establishment (ICE) described in RFC 5245 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.
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;
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:
RFC 5626"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.
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 which is used by the UE to maintain the NAT bindings.
Additionally the P-CSCF shall transmit signalling packets from the same port on which it expects to receive signalling packets.
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.
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.
This procedure is initiated by the UE at network registration time, and allows for the establishment of a flow between a UE and its assigned P-CSCF. This flow can then be used by the P-CSCF to allow an initial inbound request to traverse the NAT.
UE-A sends a Keep-Alive request to its assigned P-CSCF using the same transport address information (source and destination) which was used for the registration request. This Keep-Alive ensures that a NAT binding exists between UE-A and the P-CSCF allowing for inbound session requests from the P-CSCF to UE-A.
The P-CSCF responds with a Keep-Alive response which also reflects the received source transport address information. Inclusion of such information allows UE-A to determine if the NAT has rebooted and assigned a new binding and take appropriate action.
The following procedure illustrates the session establishment procedures when both UEs support the ICE methodology. These procedures apply to both the terminating and originating side of the session regardless of whether the UE is behind a NAT.
In the following Figure the STUN element represents both a STUN server and STUN Relay server as a single logical element. It would be equally valid if these functions we represented in separate logical elements. The procedures are unaffected by the grouping. Further, this call flow represents a simplified view to illustrate the NAT traversal procedures only. Other network elements not show may be involved in the session establishment process.
The STUN server reserves one of its transport addresses for each media flow and sends the reserved transport address information back to the UE. The STUN server also reflects the source transport address of the original request for a transport address.
If the UE fails to identify STUN servers it concludes that ICE and Outbound procedures are not supported by the network and defaults to operation using the procedures described in clause G.4.
With its three candidates (locally assigned, server reflected and relay) UE-A forms an offer and forwards to its assigned P-CSCF. The UE includes the SP cand-type, SP rel-addr and SP rel-port in the candidate attribute as defined in RFC 5245.
The P-CSCF for UE-A forwards the Answer to UE-A based on the previously stored transport address information. Media can being to flow at this point using the default transport addresses (recommended to be the STUN Relay provided address).
This procedure is applied to by the UE if the IMS-ALG function is not supported by the network, but the network does support ICE and Outbound procedures. Normal session release procedures are followed with the following exception. If a STUN Relay allocated transport address was used for the session, it shall be released by the UE for which the transport address was allocated.
In the following Figure the STUN element represents both a STUN server and STUN Relay server as a single logical element. It would be equally valid if these functions we represented in separate logical elements. The procedures are unaffected by the grouping.
A session modification can cause the creation, and/or modification, and/or release of media flows.
This procedure is applied to by the UE if the IMS-ALG function is not supported by the network, but the network does support ICE and Outbound procedures. When a new media flow is created the procedure used during session establishment for updating the transport addresses (steps 15-17. of the session establishment procedures) shall be applied.
When an existing media flow is released the procedure for session termination shall be applied for the particular media flow.
When an existing media flow is modified, this may lead to a modification of the media flow directly, or to the establishment of a new media flow and release of the existing one.
When PCC is to be employed for a session, the P-CSCF is responsible for providing the PCRF/PCF with IMS media flow information related to the service. If the UE has indicated that the active transport address corresponds to a relayed address, the P-CSCF shall be responsible for using the additional information provided by the UE to convert the media flows derived from the SDP into flow descriptions which will traverse the Policy and Charging Enforcement Point.
The deployment of STUN relay servers requires that the UE be able to communicate with such servers prior to session establishment. The PCC for the IP-CAN must be set up to allow communication with the STUN relay server prior to IMS session establishment. This may impact gating control in some IP-CANs which do not support a default or best effort flow which can be used to communicate with the STUN relay server prior to session establishment.
The UE shall be able to determine whether the IMS CN supports the Outbound procedures by the capabilities indicated in the registration response to the UE. If the indication of the capability is present, the UE knows that the IMS CN supports Outbound and the associated procedures.
IMS entities processing SDP, such as the P-CSCF, IBCF or MRFs, may or may not be updated to understand the "candidate alternative addresses" that are part of the ICE procedures, RFC 5245. IMS entities processing SDP that do not understand the ICE procedures will, in accordance with there compatibility procedures, ignore the "alternative addresses", and media entities, such as the IMS Access Gateway, PCEF, MRFP and TrGW, controlled by the IMS entities processing SDP will not pass connectivity check requests and media on those addresses. IMS entities processing SDP which behave as B2BUAs may or may not pass on the alternative address in accordance with their own compatibility procedures.