There is no requirement to support standardised subscription mechanisms for IP multimedia applications. IP multimedia applications may require to be provisioned and configured by users and operators. Since the source and variety of IP multimedia applications may not be standardised, the specific feature codes to provision, enable and configure IP multimedia applications may not be standardised either. .

The IMS shall provide the capability for IP multimedia applications (whether it is an application of a user or the network) to negotiate their capabilities to identify and select the available media components, QoS etc. of IP multimedia sessions. It shall be possible for the capability negotiation to take place on invocation, acceptance and during an IP multimedia session (e.g. following a change in UE capabilities, change in media types etc.). Capability negotiation may be initiated by the user, operator or an application on behalf of them. In order to support the user's preferences for IP multimedia applications, the capability negotiation shall take into account the information in the user profile whenever applicable. This includes the capability to route the IP multimedia session to a specific UE, when multiple UEs share the same IMS service subscription. In the Telepresence case, this may also include the UE capability for handling media, e.g. UE profile (screen size, number of screens and cameras, etc.). The IMS shall provide the capability for IP multimedia applications to exchange information about negotiated media components so that a sending system, receiving system, or intermediate system can make decisions about transmitting, selecting, and rendering media streams (e.g., decide which video stream is to be displayed on the left screen or how audio stream is to be rendered on the loudspeaker to maintain the spatial effect if multiple media streams are exchanged).

The IMS shall support the capability for the user, or the network on behalf of the user, to identify an alternative destination for an IP multimedia session or individual media of an IP multimedia session. Redirection to alternative destinations may be initiated by the sending party, receiving party or the network on their behalf. It shall be possible for redirection to be initiated at various stages of an IP Multimedia session. For example:

• Prior to the set up of an IP Multimedia session
• During the initial request for an IP Multimedia session
• During the establishment of an IP Multimedia session
• While the IP Multimedia session is ongoing

Redirection can be applied for all Multimedia sessions unconditionally or it can be caused by any of a set list of events or conditions. Typical causes could be:

• Identity of the caller
• Location or presence of the calling or called party
• If the called party is already in a session
• If the called party is unreachable or unavailable in some other way
• If the called party does not respond
• After a specified alerting interval
• User's preference on routing for specific IP Multimedia session based on the capabilities of multiple UEs sharing the same IMS service subscription.
• Time of day.

There are other causes that could be applied that do not require standardisation.

The user shall be able to end an IP multimedia session at any time during the session. The network may end an IP multimedia session at any time during the session (e.g. in failure conditions).

Multicast services allow IMS users and service providers to send multimedia to a group of IMS users simultaneously in an unidirectional way of communication. The underlying network may be able to support mechanisms that optimize the delivery of multimedia to the individual members of that group (e.g. MBMS [7])

• An IMS application located on an application server in the network shall be able to request that multimedia is sent to a group of IMS users, which are specified by this request.
• Depending on the capabilities of the underlying network IMS shall be able to use optimized mechanisms of the network (e.g. multicast capabilities such as MBMS [7]) for the delivery of multimedia to the group of IMS users.

A number or short code originating from a UE may correspond to a local number based on HPLMN/VPLMN's numbering plan, a service number in the HPLMN/VPLMN, or a private numbering plan. A number or short code may have a local context indicator (LCI) added to it. The value of an LCI helps the HPLMN to route the call and, if necessary, route the call to the country/VPLMN/private network of origin. The LCI may include:

• access specific information consist of e.g. country code plus network code, country code plus area code, or an identification of a private numbering plan;
• the home domain;
• an indication that UE does not support processing of the dialled string; or
• any other value entered by the user.

If the HPLMN cannot interpret the number or short code based on the included LCI, the HPLMN may apply policies to translate local numbers to globally routable identity and to route the call. The HPLMN shall analyse the received number and route the call as follows:

• If the number or short code has an LCI, the HPLMN should interpret the short code to a globally routable URI or E.164 [26] number according to the value of the LCI, and then correctly route the call. If the HPLMN is unable to resolve or route the received number then an error message shall be returned to the originating UE.

The network shall support the capability of a user to reject an incoming IMS session with an indication of "user busy". This indication may be used by the network as a trigger for certain services e.g. Call Forwarding on Busy. If the session rejection is propagated back to the originator, the "user busy" indication must be provided as the cause of the rejection. The conditions for user determined "user busy" include:

• the session is offered to a single contact that rejects with a "user busy" indication; or
• the session is offered to multiple contacts with a single public identity, and one contact rejects with a "user busy" indication on behalf of the set of contacts; or
• the session is offered to multiple contacts; and
  • none of the contacts progress the session; and
  • one or more of the contacts rejects with a "user busy" indication.

The IMS shall be able to provide IMS Inter-UE Transfer between:

• different UEs connected via the same IP-CAN,
• different UEs connected via different 3GPP IP-CANs,
• different UEs connected via a 3GPP IP-CAN and a non-3GPP IP-CAN (e.g. fixed line connectivity),
• different UEs connected via different non-3GPP IP-CANs.

In addition the IMS shall be able to provide IMS Inter-UE Transfer from UEs connected via an IP-CAN to ICS entities that provide interworking with UEs in the CS Domain. The following requirements are applicable for IMS Inter-UE Transfer.

• The IMS shall support the capability to transfer/retrieve some or all of the media components to/from different IMS UEs belonging to the same or different user(s) while providing continuous service experience to these users. In order to provide continuous service experience to the user, the receiving IMS UE capabilities (e.g. display resolutions, codecs capabilities, and access network data rate, etc.) shall be taken into consideration and the transferred sessions adapted accordingly.
• It shall be possible to provide continuous service experience when the session is transferred between IMS UEs of different capabilities.
• It shall be possible to transfer some or all media components to the target IMS UE(s) belonging to the same or different user(s) that are subscribed to the same operator. This can be initiated either directly from the controlling IMS UE or on request from the IMS UE where the media will be transferred.
• It shall be possible to replicate some or all media components to the target IMS UE(s) belonging to the same or different user(s) that are subscribed to the same operator. This can be initiated either directly from the controlling IMS UE or on request from the IMS UE where the media will be replicated.
• Replication / transfer of some or all media components to target IMS UE(s), belonging to the same or to different user(s) that are subscribed to the same operator, shall not be performed when the remote end (e.g. the source of the media) of the session restricts such operation.
• It shall be possible to transfer service control related to all media components to the target IMS UE that belongs to the same user and has subscription with the same operator. This can be initiated either directly from the controlling IMS UE or on request from the IMS UE where the control will be transferred.
• Inter-UE Transfer shall be subject to operator policy.
• It shall be possible to discover information on ongoing IMS sessions on different IMS UEs belonging to the IUT e.g. available IMS sessions, media components, controller/controllee capability.

IMS shall support the capability to add /delete media components across different UEs belonging to the same or different user(s) that are subscribed to the same operator, while providing continuous service experience to these users. An IMS user shall be able to control media components of an IMS session between different UEs as following:

• Add new media components to different UEs at session setup and session modification.
• Remove media components of an ongoing multimedia session from different UEs.

IMS shall support the capability to share control of media components among multiple UEs belonging to one or more users that are subscribed to the same operator. Shared control of media components may be exclusive (i.e. only one UE has the control at a time) or simultaneous (i.e. more than one UE has the control at the same time). It shall be possible for the network to authorise shared control of media components among multiple IMS users. It shall be possible for the IMS user controlling the session to allow one or more IMS users in the session to share control of media components.

The IMS shall be able to support SIP based Push Notification Service as defined in [28].