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.3 Handling of Mobile Originated Calls in the IM-SSF
...

4.6.1.3 Handling of Mobile Originated Calls in the IM-SSF p. 33

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

Process MO_IM_SSF;
Procedure CAMEL_IMCN_MO_O_IM_CSI_INIT;
Procedure CAMEL_IMCN_MO_D_IM_CSI_INIT;
Procedure CAMEL_IMCN_MO_CANCEL;
Procedure CAMEL_IMCN_MO_ANSWER;
Procedure CAMEL_IMCN_MO_UNSUCCESSFUL;
Procedure CAMEL_IMCN_MO_DISC1;
Procedure CAMEL_IMCN_MO_DISC2;
Procedure CAMEL_OCH_CTR.

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

4.6.1.3.1 Actions of the IM-SSF on receipt of Int_Error p. 33

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 MS. 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.3.2 Actions of the IM-SSF on receipt of Int_Continue p. 33

The IM-SSF continues processing without any modification of call parameters.

4.6.1.3.3 Actions of the IM-SSF on receipt of Int_Continue_With_Argument p. 33

The IM-SSF continues processing with modified call parameters. The IM-SSF shall modify 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.3.4 Actions of the IM-SSF on receipt of Int_Connect p. 33

The IM-SSF continues processing with modified call parameters. The IM-SSF shall transparently modify the call parameters with the received information. Call parameters, which are not included in the Int_Connect message, are unchanged.

4.6.1.3.5 Actions of the IM-SSF on receipt of Int_Release_Call p. 33

A BYE is sent to the MS, and a BYE is sent to the destination CSCF. The release cause received in the Int_Release_Call is used. The IM-SSF then releases all call resources and all CAMEL processing ends.

4.6.1.3.6 Handling of procedure CAMEL_OCH_CTR, sheet 1 p. 33

The IM-SSF behaves as a B2BUA (Back-2-Back User Agent) when a SIP INVITE is received for an outgoing 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.3.7 Handling of procedure CAMEL_OCH_CTR, sheet 5 p. 34

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 the 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.3.8 Receipt of 100 Trying Provisional Response (Process MO_IM_SSF) p. 34

The IM-SSF (acting as B2BUA) uses the S-CSCF as the next-hop server when sending the SIP INVITE to the destination S-CSCF. 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.

4.6.1.3.9 Handling of internal timers in Process MO_IM_SSF p. 34

The SIP B timer defined in TS 24.229 is used for IM-SSF handling of no response condition for an INVITE request, similar to the Circuit Switched handling of TNRy Timer for No Reply. The use of B timer in the IM-SSF is indicated in the SDL Process MO_IM_SSF. There are other SIP timers defined in TS 24.229 that are not specified in the SDLs for IM-SSF processing. The usage of these timers is based on the network's implementation of the IM-SSF (e.g. choice of UDP or TCP for transport of SIP, and how IM-SSF operates as both a UAS and a UAC - i.e. back-to-back UA).

The following clauses provide additional information on Process MO_IM_SSF's handling of the internal timers:

Sheets 1-2:

The inclusion of Expires header field in the INVITE method is optional and is used to indicate the duration of the invitation in seconds. When the timer fires before a final response is generated by the IM-SSF, the INVITE message is considered to be "expired". The IM-SSF shall report a call abandon event to the gsmSCF if requested and return a 487 Request Terminated to the originating S-CSCF.

When the IM-SSF (taking the role of a UAC) sends out the INVITE request, the B timer (i.e. Tb timer) shall be used for the INVITE transaction timeout timer. Refer to TS 24.229 for the recommended B timer value.

Sheet 3:

When the IM-SSF (taking the role of a UAS) sends the 200 OK final response to the S-CSCF that sent the INVITE request, the IM-SSF shall start the Tack timer to monitor the receipt of the ACK request. Refer to TS 24.229 for the recommended ACK timer value.

Sheet 4:

The expiration of Tb timer shall be reported as a no answer event to the gsmSCF if requested. If the Tinvite timer expires, the IM-SSF shall report a call abandon event to the gsmSCF if requested.

Sheet 5:

The expiration of the Tack shall be reported to the gsmSCF as a call disconnect from the originating party if requested.