Content for TS 23.278 Word version: 17.0.0

1… 4… 4.4… 4.6… 4.6.1.1 4.6.1.2 4.6.1.3 4.6.1.4 4.6.1.5 4.6.1.6 4.7… 4.7.2… 4.7.3… 4.7.4… 4.7.5… 5… 6…

4.6.1.4 Handling of Mobile Terminated IP Multimedia sessions in the IM-SSF
...

4.6.1.4 Handling of Mobile Terminated IP Multimedia sessions in the IM-SSF p. 63

The functional behaviour of the S-CSCF for handling terminating calls is specified in TS 23.218.The process and the procedures specific to CAMEL are specified in this clause:

Process MT_IM_SSF;
Procedure Check_Registration;
Procedure CAMEL_IMCN_MT_VT_IM_CSI_INIT;
Procedure CAMEL_IMCN_MT_RECONNECT;
Procedure CAMEL_IMCN_MT_CANCEL;
Procedure CAMEL_IMCN_MT_ANSWER;
Procedure CAMEL_IMCN_MT_UNSUCCESSFUL;
Procedure CAMEL_IMCN_MT_DISC1;
Procedure CAMEL_IMCN_MT_DISC2;
Procedure CAMEL_CAMEL_MT_CTR.

Internal interface indicated with the "Int_SRF_" prefix within this clause indicates internal interface with the MRFC.

4.6.1.4.1 Actions of the IM-SSF on receipt of Int_Error p. 64

The IM-SSF checks the default Call Handling parameter in the relevant CSI.

If the default call handling is release, a BYE indication is sent to the originating CSCF. The IM-SSF then releases all resources and the invoked CAMEL procedure ends.

If the call handling is continue, the IM-SSF continues processing without CAMEL support.

4.6.1.4.2 Actions of the IM-SSF on receipt of Int_Release_Call p. 64

The IM-SSF BYE message is sent to the originating CSCF and resources are released.

4.6.1.4.3 Actions of the IM-SSF on receipt of Int_Continue_With_Argument p. 64

The IM-SSF shall replace the call parameters by the information received in the Int_Continue_With_Argument message. Call parameters that are not included in the Int_Continue_With_Argument_Message are unchanged.

4.6.1.4.4 Actions of IM-SSF in procedure CAMEL_IMCN_MT_INVITE for Unregistered Subscriber p. 64

When querying the HSS for the subscriber's IM CSI data, the IM-SSF does not have to wait for the HSS's response on the first query before the subsequent queries are done. i.e. Sending of multiple Any Time Interrogation operations can be done in parallel. However, the IM-SSF shall wait for all the responses from the HSS before it shall continue with the handling of the terminating IP multimedia session.

4.6.1.4.5 Handling of procedure CAMEL_MT_CTR, sheet 1 p. 64

The IM-SSF behaves as a B2BUA (Back-2-Back User Agent) when a SIP INVITE is received for an terminating call and SIP INVITE is sent to the MRFC (via S-CSCF) as a result of a CAP ConnectToResource request received from the SCF.

A SIP response 100 Trying is sent after each INVITE but is not shown in the SDLs.

The IM-SSF shall handle the 200 OK response from the MRFC as specified in TS 23.218.

4.6.1.4.6 Handling of procedure CAMEL_MT_CTR, sheet 5 p. 64

The specifics on transporting information between the MRFC and the Application Server such as the IM-SSF, has not been standardised in 3GPP Rel-5 specifications for IMS. i.e. the SIP method to return Prompt_And_Collect result from the MRFC to the IM-SSF, the SIP method for sending notification of play announcement completion to the IM-SSF when a request for a Specialised Resource Report was received, the SIP method to request the MRFC to play announcement and the SIP method to request the MRFC to prompt and collect user information, are not standardised.

4.6.1.4.7 Receipt of 100 Trying Provisional Response (Process MT_IM_SSF) p. 65

The IM-SSF (acting as a B2BUA) uses the S-CSCF as a next-hop server when sending the SIP INVITE to the terminating subscriber. The 100 Trying provisional response received in the IM-SSF is actually generated and sent from the S-CSCF to indicate that the INVITE request has been received by the next-hop server (i.e. the S-CSCF) and is currently being processed.