8 About Session Control

This chapter describes how Oracle Communications Evolved Communications Application Server (OCECAS) implements session control through several example message flows that illustrate call establishment, SRVCC, and Supplementary Services.

About Session Control

The Session Initiation Protocol (SIP) specifies messages that control communication sessions for voice and video calls over Internet Protocol (IP) networks. These messages establish, terminate, and comprise other required elements of a communication session between two or more endpoints. You can use SIP for communication sessions consisting of one or more media streams. SIP applications can include voice calls, instant messaging, online games, video conferencing, streaming, and file transfer, as well as others.

SIP is a text-based protocol that is standardized in RFC 3261 under the auspices of the Internet Engineering Task Force (IETF).

About Back-to-Back User Agent

OCECAS is an Application Server (AS) in the IMS network. As an application server, the SIP signalling for call establishment can be sent to the AS for originating and terminating sessions (configured as trigger points in the S-CSCF). The OCECAS control flow can react to these call establishment messages by acting as either a Redirect Server or a back-to-back user agent (B2BUA).As a Redirect Server the control flow makes a decision and allows the call to continue to the original destination or a new destination, or drops the call. In either case, the AS drops out of the call signalling.By default, the VoLTE control flows operate as a B2BUA. The back-to-back user agent splits the communication channel into two legs and moderates all signaling between the end points, from call setup to termination. For a full description of application server modes, refer to 3GPP TS 24.229 section 5.7.

Normally, OCECAS acts as a back-to-back user agent for all established sessions.

About Session Establishment

The signal flow diagrams in this section illustrate the role of OCECAS in session establishment.

Basic Call

Figure 8-1 shows a basic call between two parties, in which all requests and responses are received and the call setup completes with OCECAS returning a success outcome to fully establish the call.

In this sequence, OCECAS takes the following actions:

  1. Sends an INVITE message to the destination address.

  2. Waits for SIP responses that match the call ID, and the To and From fields of the new call leg.

  3. On receipt of 18x response, sends the same response back to the calling party, copying any body content sent by the called party.

  4. Waits for ACK from the calling party that matches the call ID and the To and From fields of the original call leg.

  5. On receipt of an ACK from the calling party, sends an ACK (success) to the called party. Raises an Answered event for the control flow.

Caller Hangs Up

As seen in Figure 8-2, when the caller abandons the call before any significant setup occurs, OCECAS sends the CANCEL message to the called party before a reply to the INVITE occurs and the called party responds accordingly. The exit illustrates that the caller hung up.

Figure 8-2 Caller Abandons Call (Basic)

Description of Figure 8-2 follows
Description of ''Figure 8-2 Caller Abandons Call (Basic)''

OCECAS takes the following actions when the caller hangs up:

  1. Waits for SIP requests that match the call ID, and the To and From fields of the original call leg.

  2. On receipt of a CANCEL message from the caller, generates a CANCEL message on the new call leg.

  3. On receipt of a CANCEL 200 response from the called party, generates the same response back to the calling party.

  4. On receipt of an INVITE 4xx response from the called party, the sequence is complete.

Called Party Busy

When the called party is busy, OCECAS simply returns a status of busy upon receipt of a 486 INVITE message from the called party. Figure 8-3 illustrates this signalling flow.

If OCECAS receives a 486 response from the called party, by default it returns a 486 (Busy) to the calling party.

The original SIP session is still active to allow the control flow to perform any further tasks before fully dropping the session. For example the control flow might wish to try to connect to a different party, effectively invoking a back-to-back session with a different destination address.

No Answer

Figure 8-4 illustrates the signalling flow that occurs when the called party does not answer. When the called party does not answer within a specified amount of time, OCECAS sends a CANCEL message. The called party responds and the sequence exits on no answer.

When OCECAS receives the first 18x response from the called party, it sets a session timer to the number of seconds specified by the Timeout parameter. If the timer expires before it receives the 200 response, it takes the following actions:

  1. Generates a CANCEL on the new call leg.

  2. Waits for a CANCEL 200 response from the called party.

  3. Raises a No Answer event for the control flow.

  4. Returns a 480 (Temporarily Unavailable) to the calling party.

The original SIP session remains active to allow the control flow to perform any additional tasks before dropping the session. For example the control flow might wish to connect to a different party, effectively invoking a back-to-back session with a different destination address.

Called Party Not Reachable

Figure 8-5 illustrates the signalling flow that occurs when the called party is not reachable. When the called party is not reachable, OCECAS handles any 4xx, 5xx or 6xx response (barring a 486) from the called party. OCECAS returns not reachable.

Figure 8-5 Called Party Not Reachable

Description of Figure 8-5 follows
Description of ''Figure 8-5 Called Party Not Reachable''

This sequence is similar to the Busy scenario, except that OCECAS receives a fail status (4xx, 5xx, or 6xx) other than 486. In this case, OCECAS returns not-reachable back to the control flow, which exits on the Not Reachable branch. OCECAS sends a fail status (4xx, 5xx, or 6xx) to the calling party.

The original SIP session remains active to allow the control flow to perform any further tasks before fully dropping the session. For example the control flow might wish to connect to a different party, effectively invoking a back-to-back session activity with a different destination address.

Called Party Deflection

Figure 8-6 illustrates a called-party deflection. In this sequence, OCECAS sends a redirect response.

Figure 8-6 Called Party Deflection

Description of Figure 8-6 follows
Description of ''Figure 8-6 Called Party Deflection''

If OCECAS receives a 302 response from the called party, it returns Redirected back to the control flow. It does not send a 302 response to the calling party.

The original SIP session remains active to allow the control flow to act upon the redirection. If it wants to honour the redirection request, it can invoke another back-to-back session, taking the destination address from the Contact SIP header in the 302 response. (In the context map that would be /Incoming/Sip/Response/Header/Contact/Uri). Because the new destination address is different than the original destination address, the control flow first sends a 181 response to the caller to inform the caller about the redirection.

Called Party Ends Call Early

When OCECAS receives an early BYE request from the called party, it does not directly forward it onto the calling party. It responds to the request and the control flow returns on a called party hangup event. Figure 8-7 illustrates the signalling flow.

Figure 8-7 Called Party Ends Call Early

Description of Figure 8-7 follows
Description of ''Figure 8-7 Called Party Ends Call Early''

When the called party hangs up before the call is fully established, causing a BYE request before the final ACK is sent from the originator, OCECAS takes the following actions:

  1. Waits for SIP requests matching the call ID and the To and From fields of the new call leg.

  2. On receipt of the BYE from the called party, generates a BYE 200 response and returns it on the new call leg.

  3. Sets the call state to indicate a BYE has been received from the called party. Raises a "B hungup" event for the control flow.

  4. Continues to wait for and send on the ACK from caller to called party.

The original SIP session remains active to allow the control flow to perform any further tasks before fully dropping the session. For example, the control flow could play an announcement to the calling party.

Called Party Does Not Answer or Abandons Call

Figure 8-8 illustrates the scenario in which the called party does not answer or abandons the call. In this scenario, OCECAS responds to a timeout, sending a CANCEL message, and the calling party hanging up. OCECAS ignores the second CANCEL, from the Called party, and waits for a response from its message. OCECAS handles the reply to the Calling Party, sending the 200 CANCEL and 4xx INVITE messages. OCECAS exits showing that the Called Party hung-up.

Figure 8-8 Called Party Does Not Answer or Abandons Call (Advanced)

Description of Figure 8-8 follows
Description of ''Figure 8-8 Called Party Does Not Answer or Abandons Call (Advanced)''

When OCECAS receives the first 18x response from the called party, it starts a session timer that expires after a specified number of seconds. If the timer expires before the 200 response is received, OCECAS takes these actions:

  1. Generates a CANCEL message on the new call leg.

  2. Waits for a CANCEL 200 response from the called party.

  3. Waits for an INVITE 4xx response from called party.

  4. Raises a No Answer event for the control flow.

The original SIP session remains active to allow the control flow to perform any further tasks before fully dropping the session. For example the control flow may wish to connect to a different party, effectively invoking another back-to-back activity with a different destination address.

Caller Abandons Call

When the calling party hangs up early but OCECAS subsequently receives a response to the original INVITE, OCECAS handles the replies to the CANCEL for the calling party and sends a CANCEL to the called party. Once it receives the 200 CANCEL and 4xx INVITE, OCECAS exits with a calling party hangup event. Figure 8-9 illustrates this scenario.

Figure 8-9 Caller Abandons Call (Advanced)

Description of Figure 8-9 follows
Description of ''Figure 8-9 Caller Abandons Call (Advanced)''

When the caller hangs up before the call is established, OCECAS takes these actions:

  1. Waits for SIP requests matching the call ID and the To and From fields of the original call leg.

  2. On receipt of a CANCEL message from the caller, generates a CANCEL message on the new call leg.

  3. On receipt of a CANCEL 200 response from the called party, generates the same response back to the calling party.

  4. On receipt of INVITE 4xx response from the called party, action is complete.

  5. Returns a calling party hungup event to the control flow.

The original SIP session remains active to allow the control flow to perform any further tasks before fully dropping the session. However, because the caller has effectively hung up OCECAS is not able to perform any further interaction with the caller. It is up to the control flow to end the original SIP session with a suitable release cause, such as 487 Request Terminated, when it is ready to do so.

Caller Abandons Call (Early BYE)

Figure 8-10 illustrates an end-to-end BYE call flow, which occurs when a caller finishes before OCECAS receives a 200 message.

Figure 8-10 Caller Abandons Call (Early BYE, Advanced)

Description of Figure 8-10 follows
Description of ''Figure 8-10 Caller Abandons Call (Early BYE, Advanced)''

About SRVCC

The following session control flow diagrams illustrate key aspects of the messages exchanged between an Access Transfer Control Function (ATCF) and the Service Centralization and Continuity Application Server (SCC AS).

Registration

The Access Transfer Control Function (ATCF) sends a REGISTER message to S-CSCF with the STN-SR and C-MSISDN. The S-CSCF then sends the SCC AS a third-party REGISTER message. The SCC AS checks this information with the HSS, and possibly updates it, and then sends a MESSAGE directly to the ATCF with the C-MSISDN and ATU-STI. Figure 8-11 illustrates this scenario.

Origination

The SRVCC impact to originate a call is minimal. Figure 8-12 illustrates that as part of normal back-to-back user agent behavior, OCECAS passes the INVITE and Session Progress response through the SCC AS.

Attachment

Figure 8-13 describes the signalling message flow for attachment.

Call Establishment - Calling Party

Figure 8-14 and Figure 8-15 describe call establishment for the calling party.

Figure 8-14 Call Establishment - Calling Party

Description of Figure 8-14 follows
Description of ''Figure 8-14 Call Establishment - Calling Party''

Figure 8-15 Cont'd: Call Establishment - Calling Party

Description of Figure 8-15 follows
Description of ''Figure 8-15 Cont'd: Call Establishment - Calling Party''

Call Establishment - Called Party

Figure 8-16 and Figure 8-17 describe the signalling message flow for call establishment for the called party.

Figure 8-16 Call Establishment - Called Party

Description of Figure 8-16 follows
Description of ''Figure 8-16 Call Establishment - Called Party''

Figure 8-17 Cont'd: Call Establishment - Called Party

Surrounding text describes Figure 8-17 .

Packet-Switched to Circuit-Switched

Figure 8-18 describes the signalling message flow for packet-switched to circuit-switched handoff.

Figure 8-18 Packet-Switched to Circuit-Switched

Description of Figure 8-18 follows
Description of ''Figure 8-18 Packet-Switched to Circuit-Switched''

Packet-Switched to Circuit-Switched with ATGW Anchoring

Figure 8-19 illustrates the signalling flow that occurs when a packet-switched to circuit-switched handoff occurs with ATGW anchoring. In the packet-switched to circuit-switched handoff with ATGW anchoring, the original INVITE that arrives at the SCC AS contains a Target-Dialog header.

Figure 8-19 Packet-Switched to Circuit-Switched with ATGW Anchoring

Description of Figure 8-19 follows
Description of ''Figure 8-19 Packet-Switched to Circuit-Switched with ATGW Anchoring''

Packet-Switched to Circuit-Switched for Speech and Video

VRSCC for video is the same as a standard transfer, except that the MSC server requests information about the latest active session using a SIP OPTIONS message. The SCC AS uses the C-MSISDN to find the latest active session. The OK response contains the SDP information for that session. Figure 8-20 illustrates this scenario.

Figure 8-20 Packet-Switched to Circuit-Switched for Speech and Video

Description of Figure 8-20 follows
Description of ''Figure 8-20 Packet-Switched to Circuit-Switched for Speech and Video''

About Supplementary Services

OCECAS provides VoLTE supplementary services as required by the GSMA document "IR.92 IMS Profile for Voice and SMS". These services help to deliver the characteristics of a traditional telephony service for IP transport access.

The following message flows illustrate services for barring of an incoming call, unconditional communication forwarding, and a communication hold.

Barring of Incoming Call

Figure 8-21 shows a signalling flow that illustrates the barring of an anonymous call (UE-Anon) for user endpoint B (UE-B) using the anonymous call rejection (ACR) service:

Figure 8-21 Signal Flow for Barring of Anonymous Call

Description of Figure 8-21 follows
Description of ''Figure 8-21 Signal Flow for Barring of Anonymous Call''

This example of the barring of an incoming anonymous call includes the following sequence of messages and events:

  • The incoming INVITE request is sent to the S-CSCF serving user endpoint B.

  • The called user subscribes to the Anonymous Call Rejection (ACR) service so the INVITE request is forwarded to the AR AS.

  • AS identifies the call as anonymous and sends a 433 (Anonymity Disallowed) response.

  • The caller acknowledges (Ack) the final response.

Communication Forwarding

Figure 8-22 shows a sample signalling flow for unconditional communication forwarding with AS providing the forwarding.

Figure 8-22 Unconditional Communication Forwarding

Description of Figure 8-22 follows
Description of ''Figure 8-22 Unconditional Communication Forwarding''

This example of unconditional communication forwarding includes the following sequence of messages and events:

  • INVITE request is sent towards user B (UE-B) who has activated.

  • The INVITE is forwarded to the AS using the Initial Filter Criteria (IFC).

  • Procedures for communication forwarding unconditional (CFU) are executed.

  • The caller is notified that communication has been forwarded or deflected; a 181 response (Call is Being Forwarded) is sent to user A.

  • An INVITE request for user C is sent back to S-CSCF.

  • S-CSCF queries HSS to lookup user C (UE-C) and identify the location.

  • Communication is routed to user C.

  • The 200 (OK) response is sent to user A (UE-A).

  • User A sends an Ack to user B.

  • Real-time transport protocol (RTP) media is established.

Communication Hold

Figure 8-23 shows a sample signalling flow for a communication hold.

Figure 8-23 Communication Put on Hold

Description of Figure 8-23 follows
Description of ''Figure 8-23 Communication Put on Hold''

This example shows a communication session put on hold using a re-INVITE request with AS playing an announcement to the held party.