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.
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).
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.
The signal flow diagrams in this section illustrate the role of OCECAS in session establishment.
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:
Sends an INVITE message to the destination address.
Waits for SIP responses that match the call ID, and the To and From fields of the new call leg.
On receipt of 18x response, sends the same response back to the calling party, copying any body content sent by the called party.
Waits for ACK from the calling party that matches the call ID and the To and From fields of the original call leg.
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.
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.
OCECAS takes the following actions when the caller hangs up:
Waits for SIP requests that match the call ID, and the To and From fields of the original call leg.
On receipt of a CANCEL message from the caller, generates a CANCEL message on the new call leg.
On receipt of a CANCEL 200 response from the called party, generates the same response back to the calling party.
On receipt of an INVITE 4xx response from the called party, the sequence is complete.
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.
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:
Generates a CANCEL on the new call leg.
Waits for a CANCEL 200 response from the called party.
Raises a No Answer event for the control flow.
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.
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.
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.
Figure 8-6 illustrates a called-party deflection. In this sequence, OCECAS sends a redirect response.
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.
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.
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:
Waits for SIP requests matching the call ID and the To and From fields of the new call leg.
On receipt of the BYE from the called party, generates a BYE 200 response and returns it on the new call leg.
Sets the call state to indicate a BYE has been received from the called party. Raises a "B hungup" event for the control flow.
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.
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)
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:
Generates a CANCEL message on the new call leg.
Waits for a CANCEL 200 response from the called party.
Waits for an INVITE 4xx response from called party.
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.
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)
When the caller hangs up before the call is established, OCECAS takes these actions:
Waits for SIP requests matching the call ID and the To and From fields of the original call leg.
On receipt of a CANCEL message from the caller, generates a CANCEL message on the new call leg.
On receipt of a CANCEL 200 response from the called party, generates the same response back to the calling party.
On receipt of INVITE 4xx response from the called party, action is complete.
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.
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)
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).
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.
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.
Figure 8-14 and Figure 8-15 describe call establishment for the calling party.
Figure 8-14 Call Establishment - Calling Party
Figure 8-15 Cont'd: Call Establishment - Calling 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
Figure 8-18 describes the signalling message flow for packet-switched to circuit-switched handoff.
Figure 8-18 Packet-Switched to Circuit-Switched
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
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
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.
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
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.
Figure 8-22 shows a sample signalling flow for unconditional communication forwarding with AS providing the forwarding.
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.
Figure 8-23 shows a sample signalling flow for a communication hold.
This example shows a communication session put on hold using a re-INVITE request with AS playing an announcement to the held party.