This clause specifies concepts of IMS service provisioning for the following scenarios:
When a device or devices that perform address and/or port translation are located between the UE and the P-CSCF performing translation both of signalling and media packets.
When IP address and/or port translation is needed between the IP-CAN and the IMS domain (e.g. different IP versions) on the media path only. This scenario covers the case when a device or devices that perform address and/or port translation are located on the media path only.
The IP address and/or port translation device can be a NAT or a NAPT as defined in RFC 2663. Another type of translation is NA(P)T-PT as specified in RFC 2766. In the rest of this clause, NAT will be used for all of the devices that perform one or more of NA(P)T and NA(P)T-PT functions.
Note that the procedures of this Annex shall only be applied when they are necessary. If the terminal and/or the access network provide a transparent way of NAT traversal or no IP address translation is needed between the IP-CAN and the IMS domain on the media path then the function as defined in this Annex shall not be invoked.
It is expected the NAT traversal methods of this Annex will co-exist. UE may support one or more of these methods. It shall be possible for an operator to use one or more of NAT traversal methods in its IMS domain. The selection of the method for a particular case shall depend on the UE's capabilities, the capabilities of the network and policies of the operator.
Where possible, usage of these procedures shall not adversely impact usage of power saving modes in the UEs, i.e. when the NAT is integrated with the IMS Access Gate way which is under operator control, the reserved temporary addresses and port (binding) should be retained without requiring keep-alive messages from the UE. If the access type to IMS is GPRS, then the UE is not required to initiate any keep-alive messages, see clause E.6 for more information.
Figure G.1 presents the general reference model for IMS access when both the signalling and media traverses NAT devices. Figure G.2 presents the general reference model when IP address translation is needed between the IP-CAN and the IMS domain. The IMS network architecture is the same for both cases. The NAT integrated with the IMS Access Gateway is under operator control in this reference model.
(not reproduced yet)
Figure G.1: Reference model for IMS access when both the signalling and media traverses NAT
(not reproduced yet)
Figure G.2: Reference model for IMS access when NAT is needed between the IP-CAN and the IMS domain
Figure G.2a presents the general reference model for IMS access when both the signalling and media traverses NAT devices. Functional elements with dashed lines represent optional functionality. The transport of the Gm signalling is also subject to the policy enforcement.
(not reproduced yet)
Figure G.2a: Reference model for ICE and Outbound Methodology
The STUN Function shown within the P-CSCF is a limited STUN Server for supporting STUN keep-alive messages as described in clause G.5.3.2.
For deployments where the IMS Access gateway (or other media manipulating functional entities, such as a MRFP, are used (see clause G.2.1), such functional entities shall be placed on the network side of the STUN server and STUN relay server (i.e. not between the UE and the STUN server or STUN relay server) as shown in Figure G.2a. Otherwise they will prevent STUN messages from reaching the STUN Relay/Server outside of a session.
When supporting IMS communication for a UE residing behind a NAT or when IP address translation is needed between the IP-CAN and the IMS domain on the media path only, the P-CSCF may include the IMS-ALG function that is defined in Annex I of this specification. The following functions shall be performed in the P-CSCF:
The P-CSCF shall be able to recognize that the UE is behind a NAT device or IP address translation is needed between the IP-CAN and the IMS domain on the media path only.
The IMS-ALG function in the P-CSCF shall control the IMS Access Gateway, e.g. request transport addresses (IP addresses and port numbers) from the IMS Access Gateway, and shall perform the necessary changes of the SDP parameters.
The IMS-ALG function in the P-CSCF shall perform the necessary changes of headers in SIP messages.
The IMS-ALG function in the P-CSCF shall be able to support scenarios where IMS CN domain and IP-CAN use the same IP version and where they use different IP versions.
The IMS-ALG function in the P-CSCF shall be able to request opening and closing of gates on the IMS Access Gateway.
The IMS-ALG function in the P-CSCF may configure the IMS Access Gateway to police the remote source address/port of the associated media flow(s).
The IMS-ALG function in the P-CSCF may configure the IMS Access Gateway to police the bandwidth/data rate of the associated media flow(s) (see TS 23.333).
The IMS-ALG may configure the IMS Access Gateway to set the differentiated service code point for egress packets to an explicit value or alternately to allow the differentiated service code point of the ingress packet to be copied into the corresponding egress packet. An IMS Access Gateway can also support differentiated service code point marking based on local configuration.
The IMS-ALG may request an IMS Access Gateway to detect and report inactive media flows.
The required functions of the IMS Access Gateway for NAT translation are the following:
1) It allocates and releases transport addresses according to the requests coming from the IMS-ALG function of the P-CSCF.
2) It ensures proper forwarding of media packets coming from or going to the UE.
3) It shall support the scenarios where IMS CN domain and IP-CAN use the same IP version and where they use different IP versions.
4) It shall support opening and closing of gates, under control of the IMS-ALG.
5) It shall support policing of the remote source address/port and bandwidth/data rate of media flows, as configured by the IMS-ALG.
6) It shall support the setting of the differentiated service code point for egress packets as configured by the IMS-ALG or else based on local configuration.
7) It may support detection and reporting of inactive media flows.
8) It shall support remote NAT traversal.
The Iq reference point is between the P-CSCF and the IMS Access Gateway. It conveys the information necessary for the IMS-ALG to activate the procedures defined in clause G.3.2. Those procedures are further detailed in TS 23.334.
When supporting the IMS-ALG function, the P-CSCF, based on information received in a SIP request message (e.g. a REGISTER request), shall detect if there is NAT between the UE and itself and shall make a decision if IMS-ALG function shall be invoked for the session of subscriber. In addition to when a NAT is detected between the UE and the P-CSCF, the IMS-ALG function may be invoked for other reasons (e.g. UEs using IP address from a Private IP address range).
This procedure is applied when P-CSCF invokes the IMS-ALG function for a session. This can happen at terminating side if the called party is behind a NAT or at the originating side if the session initiator is behind a NAT. Both cases are handled in the P-CSCF and the IMS Access Gateway as described in this clause.
(not reproduced yet)
Figure G.3: Session establishment procedure with NAT traversal
The P-CSCF receives a SIP message with an SDP offer from UE_A and decides to invoke the IMS-ALG function for this session. The session can either an originating or a terminating session. The SDP offer contains the transport address(es) of UE_A where the media flow(s) should be sent.
The P-CSCF requests a transport address for each media flow from the IMS Access Gateway. Each request contains sufficient information to determine the side of the IMS access gateway that the transport request is being requested for. (e.g. local or remote side with respect to UE_A).
The IMS Access Gateway reserves one of its transport addresses for the given side of the media flow and this transport address is sent back to the P-CSCF. The IMS Access Gateway shall keep the reserved temporary transport address (binding) until the session is released.
The P-CSCF requests a transport address for each media flow in the routing domain of its own IMS network from the IMS Access Gateway. The request contains sufficient information to correlate to the transport address request performed in step 2.
A session modification can cause the creation, and/or modification, and/or release of media flows.
When a new media flow is created the procedure used during session establishment 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.
After receiving the media packet the IMS Access Gateway recognizes the media flow based on the transport address where the packet arrived at. The IMS Access Gateway changes the source transport address to its own transport address that was given to the UE_B as the destination transport address during session establishment/modification and the destination transport address to the transport address of UE_B.
The IMS Access Gateway can learn the transport addresses where the inbound (i.e. towards the UE) media packets shall be forwarded to in two ways, depending on whether there is a NAT device in the path or not. In absence of a NAT device in the path, it is the P-CSCF that signals the destination transport address for the inbound media flows. In presence of NAT device in the path, it is the IMS Access Gateway that may, upon being informed that there is a NAT in the network, determine the destination transport address of the inbound media flow based on previously received media packets in the opposite direction.
Beyond the changes of transport addresses the IMS Access Gateway shall perform the other necessary changes in the IP header as it is specified in the NAT related IETF specifications, RFC 2766 and RFC 2663.