CS supplementary services apply to the CS component of the CSI call only. The present clause describes how best to configure and utilize CS Supplementary Services in the context of CSI.
This TS covers only the Supplementary Services that are identified as having an impact on CSI within the current release as stated in TS 22.279.
It is beneficial to utilize CLIP in the context of CSI.
The called party uses the CLI of the calling party to correlate an incoming SIP INVITE with the CS call.
When the called party wishes to establish an IMS session with the calling party in the context of the CS call, the called party uses the CLI of the calling party to derive the destination URI of the IMS session. The UE may use the CLI as TEL URL or may use the CLI to derive a SIP URI.
If the calling party is subscribed to the automatic suppression of the presentation of her CLI, then it must be anticipated that the network must also automatically suppress her "IMS CLI", and, that her UE shall not reveal her CLI to other parties without her explicit permission. This can be achieved by either:
The network operator refuses to give an IMS subscription to her.
Appropriate mechanism for the HSS to control the removal of "CLI" based on subscription information.
The calling party may also wish to use CLIR on a "per call" basis. In this case, the UE shall not include any CLI information in any OPTIONS data exchange linked to the CS call.
There are several mechanisms that can be imagined for the UEs to swap static terminal information as a background task, e.g., outside of CS calls and 'user initiated' IMS sessions. Because the E.164/identity information may need to be restricted from transmission to certain destinations, the UE shall ensure that the user's permission is obtained before such sensitive information is transmitted.
Given that CLIP is highly desirable and useful for CSI, it is accepted that the use of CLIR causes significant degradation to the overall user experience in case of CSI.
It is beneficial to utilize COLP in the context of CSI:
The calling party uses the COL of the connected party to correlate an incoming SIP INVITE with the CS call.
When the calling party wishes to establish an IMS session with the connected party, the calling party uses the COL of the called party as the destination URI of the IMS session. The UE may use the COL as TEL URL or may use the COL to derive a SIP URI.
If the presentation of her COL is suppressed by means of a subscription or on a per call basis, then automatic combination of the IMS session and the CS call is unavailable. Note that user can still manually combine the CS call and the IMS session.
When a call is subject to CS call forwarding, the calling party is notified that the call has been forwarded. In CS first scenario, when the user would like to establish an IMS session that is to be automatically combined with this call then the user initiates the IMS session to the forwarded-to user. In IMS first scenario, if the UE can not associate the Public User Identity of the remote UE (of the IMS session) with the COL of the CS connected party, the UE realizes that the CS call can't be established in context of the existing IMS session and appropriately notifies the user.
Call forwarding may result in the restriction of the presentation of the COL, depending on subscriber option settings. Refer to the clause on Line Identification for the usage of the CLI and COL for establishing an IMS session associated with the CS call and for correlating an incoming IMS session with the CS call.
For CSI termination scenario, if CSI AS gets the information that the CS call is forwarded, (e.g. MGCF gets this information from the COL number in CS Connect message and sends it to CSI AS), or CSI AS gets the information that the IMS session is forwarded/will be forwarded, it may decide what the further action will be based on local policy, i.e. keep the successfully established CS call or/and IMS session with the calling party.
If a UE has an ongoing IMS session with one of two parties and invokes ECT, the end user may keep or terminate this IMS session when ECT is invoked.
The two parties that have established a CS session after ECT will not have each others line identification and are therefore incapable of establishing a CSI call / session.
If the IMS session is established prior to the establishment of the CS call/session, then the two parties will not have each others line identification and are therefore incapable of establishing a CSI call/session.
When a subscriber (calling or called) is engaged in a CS call and a second call is offered to her (Call Waiting), an IMS session may be ongoing between that subscriber and her speech partner of the ongoing call. The offering of the second call (i.e. the alerting) does not affect the ongoing IMS session.
When a subscriber (calling or called) receives a CS call when already engaged in another CS call, then she may act as follows.
Reject the incoming call. This action does not affect the IMS session of the active call.
Release the first CS call and answer the second CS call. The user may decide whether to keep the IMS session that was established in the context of the first CS call. The user may also decide to establish a new IMS session to be combined with the second CS call.
Invoke Call Hold. The first call is placed on hold and the second call is answered. The following options apply to the IMS session for the first call:
Option I: The IMS session is retained, but the sending and receiving of streaming data is suspended.
Option II: The IMS session is retained and the sending and receiving of non real-time data continues.
Similar principles apply to the case where A-party places an ongoing call on hold and establishes a second CS call.
For CSI termination scenario, if the CSI AS gets the information that CS call is being held/retrieved (e.g. MGCF maps CS Call Hold/Call Retrieve signalling into SIP message and sends it to CSI AS), or the CSI AS gets the information that the non voice media is suspended/resumed, it may initiate session modification request to perform corresponding media modification towards the peer IMS UE.
If a CS call is barred, then IMS sessions in the context of the CS call are not applicable.
If an IMS session is active and the user intends to establish a CS call, then Call Barring categories apply.
For CSI termination scenario, if the CSI AS cannot establish a voice call/IMS session with the CSI capable UE, e.g. due to Call Barring service, it may remove the voice/non voice component by negotiating /renegotiating media with the calling party.
Handover from DTM GERAN or UTRAN to non-DTM GERAN
If, during a simultaneous IMS session and CS call between two end-users, one of the end-users makes an intersystem handover into a non-DTM GERAN access, in this case the data traffic on the PDP contexts are handled as per procedures described in TS 23.060.
Handover from non-DTM GERAN to DTM GERAN or UTRAN
When a UE is participating in a CS call and not able to operate in Class A mode of operation, the UE cannot perform IMS capability exchange procedures. When the UE is again able to operate in Class A mode of operation, the UE can perform the IMS capability exchange procedures during the CS call, if required according to procedures outlined in clause 7 and clause 8.