The Operator of an IMS infrastructure may base the implementation on IPv4 only, IPv6 only or both. The choice is an operator option. The IMS may support UEs using IPv4 only, IPv6 only or both at an IP-based User-Network Interface. The choice is an operator option.

The IMS may support UEs using simultaneous multiple IP addresses.

IMS interconnect represents the interconnection of IMS functionality between 2 IMS networks over an underlying IP infrastructure. A distinction can be made between:

• Direct IMS interconnect, and
• Indirect IMS interconnect.

Direct IMS interconnect is interconnection of IMS functionality between 2 IMS networks using a common IP interconnect network that is not SIP aware. In this case there is only one IMS-NNI (see Figure 10.1-1).

Indirect IMS interconnect is interconnection of IMS functionality between 2 IMS networks using a common IP interconnect network that is SIP aware. In this case there are two or more IMS-NNIs (see Figure 10.1-2). One or more of the intermediate networks may also be IMS networks providing "transit" functionality.

An IMS network B delivers originating IMS services (e.g. least cost routing, service dependant routing, call barring, number translation, break-out) to a network A if the services are delivered for a session that arrives in the IMS network B over an IMS NNI from network A (Figure 10.1-3).

An IMS network C delivers terminating IMS services (e.g. bulk rerouting, redundancy, profile based reachability, number translation) to a network D in case the services are delivered for a session that shall continue from the IMS network C over an IMS NNI to network D (Figure 10.1-4).

The IP connection used for IMS IP interconnect shall be generic such that it can support all combinations of core network interconnection. E.g. the IP interconnection shall be shared between the IMS interconnection and the CS IP interconnection. It shall be possible to handle the inter-connection of all services over this generic IP interface. The handling of security and charging shall also be generic for all IP inter-connect scenarios.

The following requirements apply at the interconnection point (IMS NNI) between two different IMS networks or between an IMS network and a SIP based network that conforms to the IMS specification at the interconnect interface. The IMS network and intermediate networks shall support the capability for service identification, when such information is available. The IMS intermediate networks shall be able to apply operator defined policy at the interconnection point. The IMS intermediate networks shall support the capability for control of the session resources when two different IMS networks are connected which have different IP addressing schemes. The IMS network shall support both bilateral interconnection between two networks and multilateral interconnection (e.g. GSMA IPX [18]) provided by intermediate network(s). The IMS network shall support both international interconnect and national interconnect (e.g. as specified in ETSI TR 180 003 [34]). The IMS network and intermediate networks shall support service aware interconnection. The IMS network and intermediate networks shall be able to support multiple peering points for the interconnection to another IMS network or intermediate network. An IMS network shall be able to deliver IMS originating application services and terminating application services to other networks interconnected over the IMS NNI . An IMS network shall be able to deliver IMS originating application services and/or terminating application services to users that are registered to another network. The IMS network and intermediate networks shall support codec negotiation across one or multiple interconnects to minimise transcoding (and preferably eliminate it) to provide the highest quality service to the user. If two UEs, belonging to two IMS networks, do not support a common codec for voice service session, the network and/or intermediate networks shall be capable to provide transcoding functionality at the interconnection point. In case of interconnect between an IMS network and a SIP based network (e.g. SIP-I) the following requirements apply. The IMS network and intermediate networks shall support the capability for service interoperability by means of service interworking requirements defined in clause 8. In case of interconnection between two networks using the same non-IMS SIP Profile (e.g. SIP-I), the intermediate network shall transparently transport the non-IMS signalling information.

Use cases and requirements for Web Real-Time Communication (WebRTC) are defined in RFC 7478. The support of WebRTC IMS client access to IMS significantly expands the pool of clients able to access IMS. The WebRTC IMS client access to IMS feature provides a means by which an IMS operator can offer IMS services to a user running a compatible WebRTC-enabled web application in their WebRTC-enabled browser. The user will access the application from a web page offered either directly by the IMS operator or by a third party. The WebRTC IMS clients can access capabilities that may not be available in IMS, including use of WebRTC media capabilities without the need to convert to/from IMS protocols and end to end WebRTC security, subject to regulatory constraints. For example, in situations where data communications do not traverse the operator network, WebRTC media travels end to end between two WebRTC IMS clients without any protocol conversion. The media may then not be subject to the same regulatory constraints as communications that do traverse the operator network. In such cases, end to end security may be provided on the data stream as an optional service enhancement.

When accessing IMS services via WebRTC IMS client the IMS shall allow a user to access IMS services from an application offered either directly by the IMS operator or by a third party. The IMS shall be able to support access to the following IMS services and capabilities for WebRTC IMS client access:

• multimedia telephony TS 22.173, excluding fax and CS data,
• early media, and
• network tones and announcements.

The IMS shall support online and offline charging for WebRTC IMS client access (including clients provided by the operator or a third party). The available services and capabilities for WebRTC IMS clients accessing IMS shall be determined according to operator policy and user subscription settings in IMS. The IMS shall support service origination and service termination with a WebRTC IMS Client. The IMS shall support media and protocol interworking and/or transcoding, when necessary. 3GPP system shall provide the appropriate QoS (based on operator policy and user subscription) for WebRTC IMS client traffic originating from an access network supporting QoS. When accessing IMS services via a WebRTC IMS client, the IMS shall provide the equivalent levels of security and integrity as it provides when accessing IMS services in other ways. The 3GPP UE shall make available for use by the WebRTC IMS client the codecs whose support is mandatory for the access technology being used to access IMS services. The IMS shall authenticate the user that accesses IMS services using credentials provided by the operator or credentials provided by authorized third party (for web-identity based authentication) via a WebRTC IMS client and associate the user to one or more public identities (e.g. IMS Public User Identity or MSISDN). When supporting WebRTC IMS client access, the IMS shall maintain compliance with regulatory requirements for IMS services. When accessing IMS services via WebRTC IMS client, the IMS shall allow a subscriber to access call management. For WebRTC IMS client to WebRTC IMS client communication, the IMS shall support traversal of media across NAT devices.

The IMS shall provide a mechanism to support data communication between WebRTC IMS clients without requiring bearer level protocol conversions between WebRTC and IMS protocols. The IMS shall be able to support data communication between WebRTC IMS clients using WebRTC end to end security mechanisms.