Contents
1 Introduction
This document describes how to configure the Video Fallback to Audio service in the MTAS.
1.1 Prerequisites
It is assumed that the user of this document is familiar with the O&M area, in general.
1.1.1 Licenses
To enable the Video Fallback to Audio service, the Video Fallback to Audio license must be installed. For more information about the Video Fallback to Audio license, refer to MTAS Licenses.
1.1.2 Documents
Before starting any procedure in this document, ensure that the following documents are available:
1.1.3 Conditions
The following condition must apply:
An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
2 Overview
The Video Fallback to Audio service improves the user experience if the originating multimedia User Equipment (UE) calls a destination network that does not support media capability negotiation based on SDP offer/answer protocol. These networks can drop the call with a 500 SIP error response if the media capabilities requested in the Session Description Protocol (SDP) offer cannot be satisfied. One example of such behavior is when video call is placed to a terminal connected to a circuit-switched network. In this case if the destination terminal does not support video calling capability or the circuit-switched network has no capacity for video call, the circuit-switched network drops the call instead of falling back to an audio-only call. Video Fallback to Audio service detects such a failed call and repeats the call as an audio-only call. The caller is not aware of the fallback mechanism, it is only seen as a successful audio-only call.
2.1 Subfunctions
The subfunctions included in the Video Fallback to Audio service are described in this section.
2.1.1 Fallback Call
The Fallback Call subfunction initiates an audio-only fallback call if the original multimedia call was rejected and the 500 SIP error response carries Q.850 cause code in the Reason header that matches a configured value. Originating Party call with multimedia capabilities, for example, video and audio. The call is routed to a network (for example circuit-switched) that is not able to handle the requested multimedia capabilities. Precondition negotiation can optionally occur between the Originating Party and the gateway providing access to Terminating Network. Terminating Network rejects the call with a specific cause code. Video Fallback to Audio service repeats the call as audio-only.
2.2 Terminal and Network Interaction
Other network elements interacting with Terminating Networks must be configured to return well-defined Q.850 cause codes in the 500 SIP error response for which fallback to audio can be applied.
2.3 Interaction with Other Services
This section describes the Video Fallback to Audio interaction with other services.
2.3.1 Flexible Communication Distribution
Calls to related and non-IMS primary users initiated by the Flexible Communication Distribution (FCD) service must be subject to Video Fallback to Audio processing.
For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.
2.3.2 Communication Diversion
A diverted call initiated by any variant of Communication Diversion (CDIV) service must be subject to Video Fallback to Audio processing.
For more information about the CDIV service, refer to MTAS Communication Diversion Management Guide.
2.3.3 Charging
Video Fallback to Audio service uses the same IMS Charging Identifier for both the first call and the fallback call.
In the originating case, charging messages are generated only for the fallback call. In the terminating transit case, the first call must be charged as a failed call and the fallback call must be charged according to its outcome.
For more information about the charging service, refer to MTAS Charging Management Guide.
2.3.4 Outgoing Communication Barring
If Outgoing Communication Barring (OCB) is applicable, OCB applies to the fallback call.
For more information about the Barring services, refer to MTAS Barring and Dial Plan Services Management Guide.
2.3.5 Call Admission Control
The fallback call is not affected by the Group Call Admission Control (GCAC) or User Call Admission Control (UCAC) counters if the original call was admitted by the Call Admission Control (CAC) services.
For more information about the CAC services, refer to MTAS Call Admission Control Management Guide.
2.3.6 Communication Completion
Calls initiated by any version of Communication Completion (CC) services are subject to Video Fallback to Audio service processing.
For more information about the CC services, refer to MTAS Communication Completion Management Guide.
2.3.7 Conference
Calls initiated by the conference focus are subject to Video Fallback to Audio processing.
For more information about the Ad-hoc conference service, refer to MTAS Ad-hoc Conference Management Guide.
2.3.8 Carrier Select and Carrier Pre-Select
If Crank Back service and Video Fallback to Audio are both configured to process error responses with the same Q.850 cause code, the Crank Back processing repeats the call first. If Crank Back fails, Video Fallback to Audio executes its fallback logic.
For more information about the Carrier Select and Carrier Pre-Select service, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.
2.3.9 AS Interworking
The Interworking processing applies to Video Fallback to Audio fallback calls.
For more information about the AS Interworking service, refer to MTAS Application Server Interworking Management Guide.
2.3.10 Priority Call
Fallback call initiated by Video Fallback to Audio processing has the same priority indicator as the first, failed call.
For more information about the Priority Call service, refer to MTAS Priority Call Management Guide.
2.3.11 Gateway Model
Provisional responses can be sent by the Terminating Network before the 500 SIP error response is sent for the first, failed call. These provisional responses can create an early dialog for the first, failed call. If such an early dialog is created, Gateway Model uses the same dialog for the first, failed call, and the fallback call to the Originating Party.
For more information about the Gateway Model service, refer to MTAS Gateway Model Management Guide.
3 Video Fallback to Audio Configuration
The Video Fallback to Audio service of the MTAS is controlled by the MtasVideoFB MO and its attributes. The MO structure of the Video Fallback to Audio service is shown in Figure 1.
Configurable MOs and attributes related to the Video Fallback to Audio service are defined in Managed Object Model (MOM).
3.1 Q.850 Cause Code Configuration
The attribute mtasVideoFBReasonCodes defines the Q.850 cause codes that trigger fallback call. The value of this attribute is a list of strings, each string specifying a valid Q.850 cause code. The attribute has a default value, the list of "47", "57", "58", "88".
3.2 Video Fallback to Audio Administrative State Configuration
The Video Fallback to Audio service is enabled by setting the mtasVideoFBAdministrativeState attribute to 1 (Unlocked). If the mtasVideoFBAdministrativeState is set to 0 (Locked), no Video Fallback to Audio service is provided by the MTAS.
3.3 Wholesale for Video Fallback to Audio Configuration
The Video Fallback to Audio service supports Wholesale. Video Fallback to Audio is configurable on Virtual Telephony Provider level.
Wholesale for Video Fallback to Audio is activated when the following attributes are set to 1 (Unlocked):
- The vtasVideoFBAdministrativeState attribute in the VtasVideoFB MO
- The mtasVideoFBAdministrativeState attribute in the MtasVideoFB MO
For more information about the Wholesale service, refer to MTAS Wholesale Support Management Guide.
3.4 Service Data Configuration
No service data for the Video Fallback to Audio service is configured for the subscriber data.
4 Performance Management
The Video Fallback to Audio service has no measurements.
5 Fault Management
Alarms related to the Video Fallback to Audio service are listed in MTAS Alarm List.