Content for  TS 23.228  Word version:  19.0.0

This clause describes information flows for the procedures of Mobile Terminating call flows for unregistered IMS Public User Identities. The detection of an unregistered Public User Identity is done in HSS and if this Public User Identity has services related to unregistered state, a S-CSCF is selected for the unregistered Public User Identity. S-CSCF performs whatever further actions are appropriate for the call attempt to the unregistered IMS Public User Identity. Two basic examples for "services related to unregistered" are call redirection to CS domain and voice mailbox service. Call redirection to CS domain is supported to cover the cases when the UE is not registered in IMS but can be reached via the CS domain. Then, a temporary S-CSCF is selected and performs whatever further actions are appropriate for the call attempt. The principle established in clause 4.3.3.4, where the Public User Identities for the same profile are allocated to the same S-CSCF, is followed.

In Figure 5.43 below the Public User Identity is unregistered for IMS and the Public User Identity has services related to unregistered state. In this case, the HSS responds back to I-CSCF with an indication that I-CSCF should select S-CSCF for this MT call to the unregistered Public User Identity of the user or provide the I-CSCF with the previously allocated S-CSCF name. Before S-CSCF selection, I-CSCF shall query HSS for the information related to the required S-CSCF capabilities. I-CSCF selects a S-CSCF to invoke service logic and I-CSCF routes the call further to the selected destination. If the S-CSCF does not have the relevant information from the user profile then the S-CSCF shall download the relevant information from HSS before it invokes service logic and any further actions in the call attempt. The service implemented by this information flow could be e.g. "Call Forward Unconditional". This is shown by the information flow in Figure 5.43:

The S-CSCF may deregister the Public User Identity at any time (e.g. according to operator network engineering requirements) by issuing a Cx-Put2 (Public User Identity, clear S-CSCF name) clearing the S-CSCF name stored in the HSS. If S-CSCF name stored by the HSS does not match the name of the S-CSCF that originated the Cx-Put2 then the HSS will acknowledge the clearing request but take no further action.

In the example information flow the Public User Identity of the user is unregistered and the Public User Identity has no services related to unregistered state. This is shown in the following information flow (Figure 5.44):

The MRFC/MRFP are resources of the IMS that provide support for bearer related services such as for example multi-party sessions, announcements to a user or bearer transcoding. This clause describes how the resources of the MRFC/MRFP are used.

In some cases an operator may wish to make an MRFC available directly to a UE, for example to support ad-hoc multi-party sessions to be initiated by the UE. In this case, the operator advertises the name of one or more MRFCs and a UE will invite an MRFC to a session. The session invitation would need to contain additional information indicating the specific capabilities (e.g. multi-party) desired. A conference ID would be assigned by the MRFC and returned to the UE. This would then be used by the UE in subsequent interactions with the MRFC and other UEs participating in the session. There are two approaches to invite new participants to the multiparty session. In the first, a UE directs other UEs to join the multiparty session based on the use of the SIP REFER method. This allows session invitations with consultation. In the second method, the MRFC uses information received from a UE e.g. within a list of session participants to invite other UEs to the multiparty session. This allows session invitations without consultation.

The MRFC/MRFP resources may also be used, based on service control in an IMS, for services such as multiparty sessions, announcements or transcoding. In this case an Application Server interacts with an MRFC. Session control messages are exchanged between the AS and the MRFC. There are two approaches for the AS to control the sessions. In the first, the AS uses 3rd party call control. The second approach uses the SIP REFER method. In either case, the appropriate service in the AS would be triggered by a UE initiated SIP message containing information indicating the specific capabilities desired. This session invitation would also carry additional information indicating the specific capabilities (e.g. multi-party). A conference ID would be assigned by the MRFC and would be used by the AS in subsequent interactions with the MRFC in INVITE messages connecting other endpoints. 3rd party call control can also be used to invoke announcement and transcoding services. That is, the AS will send an INVITE to the MRFC with an indication of the capability being requested and with additional information related to the specific service such as identification of the announcement to be played or identification of the specific transcoding requirements.

Network services hosted on an AS and configurable by the user via the Ut interface may also use the capabilities provided by the MRFC. For this case, the AS either supports MRFC capabilities, or communicates with an MRFC. Communications across the Ut interface between the UE and the AS allow the UE to securely manage and configure data for such services (e.g. conference type services). Means for the AS to propagate this management and configuration information to the MRFC is not standardized in this Release.

Network services involving MRFC and MRFP are not limited to conferencing and announcements, but also involve transcoding support for interworking between IMSs or inter-domain sessions, and intra-domain sessions between access technologies supported in an IMS (e.g. wireline wireless interworking, or interworking with non-3GPP wireless technologies). The MRFC and MRFP act as transcoding entity in an IMS solving media encoding mismatches due to codec selection between operator networks, as well as to deal with encoding formats in a converged service environment. Service requests sent to the MRFC shall contain sufficient information to associate the systems that require media transcoding, and also for reservation of resources required at the MRFP. The MRFC shall always grant the requests from the control plane, unless there is a lack of resources. Media transcoding support based on MRFC/MRFP shall support the offer/answer procedure as defined in RFC 3264. Additional description of transcoding support involving the MRFC/MRFP is provided in Annex P.

This clause describes information flows Mobile Terminating procedure for an unknown user. The unknown user cases include those where session requests are made towards Public User Identities that are incorrect, un-issued or have been cancelled/deleted. The determination of unknown user is carried out in the HSS and/or the SLF (for networks that require SLF functionality). The information flows of Figure 5.45 and Figure 5.46 illustrate how SIP messages can be used to inform the requesting party that the requested user is not known within the network. In the case where the destination Public User Identity is an E.164 number in the SIP URI with user=phone parameter format, the I-CSCF shall first translate it into the Tel: URI format per RFC 3966 prior to sending to the HSS a Cx_LocQuery (or to the SLF a DX_SLF_QUERY). If a failure occurs under these circumstances, the Mobile Terminating user is not an IMS user of this network. In this case, the I-CSCF may invoke the portion of transit functionality that translates the E.164 address contained in the Request-URI of the Tel: URI format to a routable SIP URI, or BGCF for further routing as described in clause 5.19.

In Figure 5.45 the unknown status of the requested party is determined in the HSS. The I-CSCF requests information on the user to be reached and the HSS responds back to the I-CSCF with an indication that the user is unknown. The I-CSCF uses the indication that the user is unknown returned from the HSS to formulate the correct SIP message back towards the originating party to inform them that the user is unknown. The case where the SLF determines unknown status is in clause 5.15.2. The flows of Figure 5.45 could include SLF determination of the HSS, however these are not shown for clarity.

In Figure 5.46 the unknown status of the requested party is determined in the SLF. The I-CSCF requests information on the user to be reached and the SLF responds back to the I-CSCF with an indication that the user is unknown. The I-CSCF uses the indication that the user is unknown returned from the SLF to formulate the correct SIP message back towards the originating party to inform them that the user is unknown.