Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  16.6.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.2.4…   4.3…   4.4…   4.13…   4.16…   5…   5.2…   5.3…   5.4…   5.4.7…   5.4.8…   5.4a…   5.5…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.8…   5.11…   5.11.3…   5.11.4…   5.11.5…   5.11.6…   5.12…   5.16…   5.19   5.20…   A…   E…   E.2.2…   G…   G.5…   H…   J…   L…   N…   Q…   Q.2.5…   R…   S…   U…   U.2…   V…   Y…   Z…   AA…   AA.3…

 

5.12  Mobile Terminating call procedures to unregistered Public User IdentitiesWord‑p. 185

5.12.0  General |R6|

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.
Up

5.12.1  Mobile Terminating call procedures to unregistered Public User Identity that has services related to unregistered state

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:
(not reproduced yet)
Figure 5.43: Mobile Terminating call procedures to unregistered IMS Public User Identity that has services related to unregistered state
Up
Step 1.
I-CSCF receives an INVITE message.
Step 2.
I-CSCF queries the HSS for current location information.
Step 3.
HSS either responds with the required S-CSCF capabilities which I-CSCF should use as an input to select a S-CSCF for the unregistered Public User Identity of the user or provides the I-CSCF with the previously allocated S-CSCF name for that user.
Step 4.
If the I-CSCF has not been provided with the location of the S-CSCF, the I-CSCF selects an S-CSCF for the unregistered Public User Identity of the user.
Step 5.
I-CSCF forwards the INVITE request to the S-CSCF.
Step 6.
The S-CSCF sends Cx-Put/Cx-Pull (Public User Identity, S-CSCF name) to the HSS. When multiple and separately addressable HSSs have been deployed by the network operator, then the S-CSCF needs to query the SLF to resolve the HSS. The HSS stores the S-CSCF name for unregistered Public User Identities of that user. This will result in all terminating traffic for unregistered Public User Identities of that user being routed to this particular S-CSCF until the registration period expires or the user attaches the Public User Identity to the network. Note: Optionally the S-CSCF can omit the Cx-Put/Cx-Pull request if it has the relevant information from the user profile.
Step 7.
The HSS shall stores the S-CSCF name for that user and return the information flow Cx-Put Resp/Cx-Pull Resp (user information) to the S-CSCF. The S-CSCF shall store it for that indicated Public User Identity.
Step 8.
S-CSCF invokes whatever service logic is appropriate for this call attempt.
Step 9.
S-CSCF performs whatever further actions are appropriate for this call attempt (in the case where the S-CSCF decides to redirect the session towards CS domain, the Mobile Termination Procedure MT#3 (clause 5.7.2a) applies).
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.
Up

5.12.2  Mobile Terminating call procedures to unregistered Public User Identity that has no services related to unregistered stateWord‑p. 187
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):
(not reproduced yet)
Figure 5.44: Mobile Terminating call procedures to unregistered Public User Identity that has no services related to unregistered state
Up
Step 1.
I-CSCF receives an INVITE message.
Step 2.
I-CSCF queries the HSS for current location information.
Step 3.
HSS responds with an indication that the Public User Identity is unregistered, but no services are related to unregistered state.
Step 4.
I-CSCF responds to the origin of the request that the user is not reachable at the moment.

5.13  IMS Emergency Sessions

Emergency sessions via IMS are specified in TS 23.167.

5.14  Interactions involving the MRFC/MRFP

5.14.0  General |R6|

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.

5.14.1  Interactions between the UE and the MRFC

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.
Up

5.14.2  Service control based interactions between the MRFC and the ASWord‑p. 188
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.
Up

5.14.3  Interactions for services using both the Ut interface and MRFC capabilities |R6|

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.
Up

5.14.4  Transcoding services involving the MRFC/MRFP |R8|

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.
Up

5.15  Mobile Terminating session procedure for unknown userWord‑p. 189

5.15.0  General |R6|

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.
Up

5.15.1  Unknown user determined in the HSS.

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.
(not reproduced yet)
Figure 5.45: HSS determination of unknown user
Up
Step 1.
I-CSCF receives an INVITE.
Step 2.
I-CSCF queries the HSS for current location information.
Step 3.
HSS responds with an indication that the user is unknown.
Step 4.
The I-CSCF responds to the origin of the request that the user is unknown.

5.15.2  Unknown user determined in the SLFWord‑p. 190
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.
(not reproduced yet)
Figure 5.46: SLF determination of unknown user
Up
Step 1.
The ICSCF receives an INVITE request and now has to query for the location of the user's subscription data.
Step 2.
The I-CSCF sends a DX_SLF_QUERY to the SLF and includes as parameter the user identity which is stated in the INVITE request.
Step 3.
The SLF looks up its database for the queried user identity.
Step 4.
The SLF answers with an indication that the user is unknown.
Step 5.
The I-CSCF responds to the origin of the request that the user is unknown.


Up   Top   ToC