Jump to: navigation, search

Supported Functionality with IP Telephony

This topic describes the IP telephony functionality that Outbound Contact supports.

Overview

This topic describes Outbound Contact dialing scenarios that include SIP Server and Genesys Voice Platform (GVP).

  • Outbound Contact Server (OCS) and SIP Server provide support for audio or audio/video outbound campaigns in both Predictive and Progressive dialing modes, in the following scenarios:
  • Using SIP Server as a dialer and a VDN as the DN on behalf of which OCS originates calls with Genesys Media Server (a GVP component), which is able to perform Call Progress Analysis (CPA).
  • Using SIP Server as a dialer and Trunk Group DN as the DN on behalf of which OCS originates calls with Genesys Media Server to perform CPA in Transfer and Active Switching Matrix (ASM) modes.
  • OCS, SIP Server, and GVP 8.1 together provide support for self-service campaigns that may or may not involve an agent. SIP Server performs dialing, Genesys Media Server provides CPA, and the interaction outcome is supplied to OCS by the VXML application using HTTP protocol requests. Power GVP and Progressive GVP modes are supported in this scenario.

Note:

For an architectural description and configuration information about using Outbound Contact in a VoIP environment, see the Outbound Contact 8.1 Deployment Guide.

Power GVP dialing mode supports the Proactive Contact Solution. For more information on the Proactive Contact Solution, see the Proactive Contact 8.0 Solution Guide, which is located on the Genesys Technical Support web site and the Genesys Documentation Library DVD.

For backwards compatibility, Outbound Contact also continues to support use of CPD Server and a Dialogic board.

  • Using CPD Server/Dialogic board as a dialer in a Transfer mode.
  • Using CPD Server/Dialogic board as a dialer in the ASM mode.
  • Using CPD Server/Dialogic’s Host Media processing (HMP) software as a dialer.
  • OCS and T-Server for Cisco Unified Communications Manager provide support for audio outbound campaigns in both Predictive and Progressive dialing modes for the following scenarios:
  • Using CPD Server/Dialogic board in the ASM mode only.
  • Using CPD Server/HMP in the ASM or Transfer modes.

OCS with SIP Server Overview with Media Server or CPD Server and OCS with SIP Server Overview with GVP MCP provide an overview of each of these scenarios.

OCS with SIP Server Overview with Media Server or CPD Server


OCS with SIP Server Overview with GVP MCP

The following sections describe predictive and progressive dialing mode scenarios for a VoIP environment. Each scenario describes the media flow, which can contain either audio or audio/video information. The type of media used is identified within the Session Description Protocol (SDP) parameter in SIP Server messages. Video media flows using HMP is not supported.

Note:

Refer to the Genesys Supported Media Interfaces Reference Manual for more information about supported media gateways.

Please consult with your media gateway provider regarding CPA availability, and for configuration information.

When using a Dialogic board, Genesys recommends that you use Transfer mode, which provides the most efficient usage of Dialogic resources. Contact your Dialogic card provider for further configuration information.

Outbound Contact with SIP Server

The following scenarios describe how to use Outbound Contact with SIP Server:

Note:

This section provide detailed descriptions of supported calling scenarios involving Outbound Contact in a VoIP environment. In general, there are no differences in supported scenarios for OC dialing in both ASM and Transfer modes with CPA, regardless of where CPA is done, either on MCP or on MGW.

Transfer Mode (MGW with CPA)

The following scenario describes a media flow that involves a MGW (Media Gateway) with CPA (Call Progress Analysis) capabilities. The following hardware is supported in this scenario:

  • AudioCodes
  • Paraxip

Note:

In this scenario, you can also use GVP 8.1 Media Control Platform (MCP) to handle CPA in place of MGW.

Transfer-Mode Call Flow (MGW with CPA) with a SIP Agent Endpoint illustrates a Transfer-mode call flow in VoIP environment that involves an MGW with CPA and a SIP agent endpoint.

Transfer-Mode Call Flow (MGW with CPA) with a SIP Agent Endpoint

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends a RequestMakePredictiveCall message to SIP Server. This request contains AttributeOtherDN, which is the customer’s DN.
  2. SIP Server creates call leg 10 with MGW 1 and establishes a call with the customer DN.
  3. MGW 1 performs CPA and sends the call results to SIP Server.

Step 2

  1. SIP Server reports the call state to OCS.
  2. SIP Server generates EventQueued and RouteRequest messages and establishes call leg 20 with a SIP agent end point.
  3. All media streams will be between the SIP agent end point and the customer when SIP Server joins call leg 10 and call leg 20.

Transfer Mode (MGW without CPA)

The following scenario describes a media flow that involves an MGW without CPA abilities.
Transfer-Mode Call Flow (MGW without CPA) in Two Locations with a SIP Agent Endpoint illustrates a Transfer -mode call flow in two locations in VoIP environment that involves an MGW without CPA and a SIP agent endpoint.

Transfer-Mode Call Flow (MGW without CPA) in Two Locations with a SIP Agent Endpoint

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends Req_MakePredictiveCall to CPD Server. This request contains SAttr_DialTo, which is the customer’s phone number.
  2. CPD Server selects a Dialogic channel DN and places it off hook.
  3. CPD Server makes a call via Dialogic board through MGW 1 from a selected Dialogic channel DN to a customer’s phone number.
  4. MGW 1 creates leg 10 of a call by sending INVITE to SIP Server to establish a session with a destination endpoint defined by SAttr_DialTo.
  5. SIP Server resolves the destination endpoint address and, assuming that this address matches the trunk address on MGW 2, creates leg 20 of a call by sending INVITE to MGW 2 to establish a call with the customer’s phone number. All media streams are now between the MGW1 endpoint and the customer.
  6. SIP Server conferences call leg 10 and call leg 20.
  7. CPD Server performs CPA and reports the call result to OCS.

Note:

  • When using CPD Server with Dialogic board connected to MGW the CPD Server tscall option must be set to no.
  • MGW must be configured to match a channel number from which it originates an outbound call with a DN assigned to the Dialogic channel selected by CPD Server.

Step 2

  1. CPD Server sends a request to SIP Server to initiate the transfer of the customer call to a SIP agent endpoint.
  2. SIP Server creates and establishes call leg 30 with the SIP agent endpoint.
  3. SIP Server joins call leg 20 and call leg 30. All media streams are now between the SIP agent endpoint and the customer.
  4. CPD Server places the Dialogic channel DN on-hook when the transfer has been completed, and SIP Server issues the EventReleased message. This causes the MGW to drop call leg 10.

The Dialogic channel DN is now freed from the MGW to dial another outbound call.

Transfer-Mode Call Flow (MGW without CPA) in One Location with a SIP Agent Endpoint illustrates a Transfer-mode call flow in one location in VoIP environment that involves a MGW without CPA and a SIP agent end point.

The MGW in this scenario must be able to support multiple T1/E1 lines and provide bridging capabilities.

Transfer-Mode Call Flow (MGW without CPA) in One Location with a SIP Agent Endpoint

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends Req_MakePredictiveCall to CPD Server. This request contains SAttr_DialTo, which is the customer’s phone number.
  2. CPD Server selects a Dialogic channel DN and places it off hook.
  3. CPD Server makes a call via Dialogic board through MGW 1 from a selected Dialogic channel DN to a customer’s phone number.
  4. MGW creates leg 10 of a call by sending INVITE to SIP Server to establish a session with a destination endpoint defined by SAttr_DialTo.
  5. SIP Server resolves the destination endpoint address and creates leg 20 of a call by sending INVITE back to MGW to establish a call with the customer’s phone number. All media streams are now between the MGW endpoint and the customer.
  6. SIP Server conferences call leg 10 and call leg 20.
  7. CPD Server performs CPA and reports the call result to OCS.

Note:

When using CPD Server with Dialogic board connected to MGW the CPD Server tscall option must be set to no.
MGW must be configured to match a channel number from which it originates an outbound call with a DN assigned to the Dialogic channel selected by CPD Server.

Step 2

  1. CPD Server sends a request to SIP Server to initiate the transfer of the customer call to a SIP agent endpoint.
  2. SIP Server creates and establishes call leg 30 with the SIP agent endpoint.
  3. SIP Server joins call leg 20 and call leg 30. All media streams are now between the SIP agent endpoint and the customer.
  4. CPD Server places the Dialogic channel DN on-hook when the transfer has been completed, and SIP Server issues the EventReleased message. This causes the MGW to drop call leg 10.

The Dialogic channel DN is now freed from the MGW to dial another outbound call.

Transfer Mode (MCP as the CPA Provider)

The following scenario describes a media flow that involves an GVP 8.1 MCP providing CPA abilities, and using SIP Server as the dialer for the Trunk Group DN.

Transfer-Mode Call Flow (MCP as the CPA Provider) with a SIP Agent Endpoint illustrates a Transfer mode call flow in VoIP environment that involves MCP as the CPA provider and a SIP agent endpoint.

Transfer-Mode Call Flow (MCP as the CPA Provider) with a SIP Agent Endpoint

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends a RequestMakePredictiveCall message to SIP Server. This request contains AttributeOtherDN, which is the customer's DN.
  2. SIP Server invites MCP/Genesys Media Server to handle CPA.
  3. SIP Server creates the call leg with MCP and establishes a call with the customer DN.
  4. MCP performs CPA and sends the call result to SIP Server.
  5. SIP Server reports the call state to OCS by either EventReleased (for negative call results) or EventEstablished (for positive ones) on the Trunk Group DN.

Step 2

  1. For a positive call result (EventEstablished received), OCS requests SIP Server to transfer the outbound call from the Trunk Group DN to Voice Transfer Destination DN.
  2. SIP Server generates EventQueued and/or RouteRequest messages and establishes the call leg with a SIP agent endpoint.
  3. When SIP Server joins the customer call leg to the agent call leg, all media streams are between the SIP agent endpoint and the customer.

ASM Mode (MCP as the CPA Provider)

The following scenario describes a media flow that involves an GVP 8.1 MCP providing CPA abilities, and using SIP Server as the dialer for the Trunk Group DN.

ASM-Mode Call Flow (MCP as the CPA Provider) with a SIP Agent Endpoint illustrates a Transfer mode call flow in VoIP environment that involves MCP as the CPA provider and a SIP agent endpoint.

ASM-Mode Call Flow (MCP as the CPA Provider) with a SIP Agent Endpoint

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends a RequestMakeCall to SIP Server. This request contains the ‘GSW_CALL_TYPE’: ‘ENGAGING’ key-value -pair in its AttributeUserData, that identifies an engage call and the AttributeOtherDN, that is the Voice Transfer Destination DN.
  2. SIP Server invites MCP/Genesys Media Server to handle the bridging of the engaging and customer legs and perform CPA on the customer leg.
  3. SIP Server initiates an engaging call leg from the Trunk Group DN to the Voice Transfer Destination DN.
  4. SIP Server generates an EventQueued and/or RouteRequest message and establishes the engaging call leg with a SIP agent endpoint.
  5. The agent answers the engaging call, which generates an EventEstablished message (that includes the Genesys Media Server ID). The agent now waits for OCS and SIP Server to generate a second call leg to a calling list number.

Step 2

  1. OCS sends a RequestMakePredictiveCall message to SIP Server. This request contains ‘GSW_CALL_TYPE’: ‘REGULAR’ key-value pair in its AttributeUserData, that identifies the customer call leg and AttributeOtherDN, that is the customer's DN.
  2. SIP Server invites MCP/Genesys Media Server to handle CPA.
  3. SIP Server creates call leg with MCP and establishes a call with the customer DN.
  4. MCP performs CPA and sends the call result to SIP Server.
  5. SIP Server reports the call state to OCS by either EventReleased (for negative call results) or EventEstablished (for positive ones) on the Trunk Group DN.

Step 3

  1. For a positive call result (EventEstablished received), OCS sends a RequestMergeCalls to SIP Server. This request contains both the engage and customer calls Connection IDs.
  2. MCP connects the internal engaging and external customer call legs. The call is established between the agent and the customer.

Note:

MCP bridges these legs by either merging them or transferring the agent to the customer call, depending on the configuration of the merge-method option. For more information on this option or on bridging calls, see the Outbound Contact 8.1 Deployment Guide.

ASM Mode (MGW with CPA)

Supported scenarios are the same as in the previous section ASM Mode (MCP as the CPA Provider).

ASM Mode (MGW without CPA)

The following scenario describes a media flow that involves an MGW without CPA abilities, using a Dialogic card in an ASM mode.

ASM-Mode Call Flow (MGW without CPA) in Two Locations with a SIP Agent Endpoint illustrates an ASM-mode call flow in two locations in VoIP environment that involves a MGW without CPA and a SIP agent endpoint:

ASM-Mode Call Flow (MGW without CPA) in Two Locations with a SIP Agent Endpoint

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends an engage agent request to CPD Server.
  2. CPD Server instructs the Dialogic board to create an engage call (leg 10) with an available agent’s queue.
  3. The engage call is queued, which generates an EventQueued message.
  4. The agent’s queue diverts the engage call to an agent’s desktop.
  5. The agent answers the engage call, which generates an EventEstablished message. The agent now waits for OCS and CPD Server to generate a second call (leg 20) to a calling list number.

Step 2

  1. OCS sends Req_MakePredictiveCall to CPD Server. This request contains SAttr_DialTo, which is the customer phone number.
  2. CPD Server instructs the Dialogic board to place a call to the customer number that OCS provided.
  3. If CPA has determined that there is a live voice, CPD Server attaches any customer data to the engage call (leg 20).
  4. SIP Server delivers this data to the engaged agent’s desktop as a screen pop.
  5. CPD Server connects the call’s internal and external leg. The call is established between the agent and the customer.
  6. CPD Server informs OCS of the call result. The call is now handled as a normal outbound call.

ASM-Mode Call Flow (MGW without CPA) in One Location with a SIP Agent Endpoint illustrates an ASM-mode call flow in one location in VoIP environment that involves an MGW without CPA and a SIP agent endpoint.

ASM-Mode Call Flow (MGW without CPA) in One Location with a SIP Agent Endpoint

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends an engage agent request to CPD Server.
  2. CPD Server instructs the Dialogic board to create an engage call (leg 10) with an available agent’s queue.
  3. The engage call is queued, which generates an EventQueued message.
  4. The agent’s queue diverts the engage call to an agent’s desktop.
  5. The agent answers the engage call, which generates an EventEstablished message. The agent now waits for OCS and CPD Server to generate a second call (leg 20) to a calling list number.

Step 2

  1. OCS sends Req_MakePredictiveCall to CPD Server. This request contains SAttr_DialTo, which is the customer phone number.
  2. CPD Server instructs the Dialogic board to place a call to the customer number that OCS provided.
  3. If CPA has determined that there is a live voice, CPD Server attaches any customer data to the engage call (leg 20).
  4. SIP Server delivers this data to the engaged agent’s desktop as a screen pop.
  5. CPD Server connects the call’s internal and external leg. The call is established between the agent and the customer.
  6. CPD Server informs OCS of the call result. The call is now handled as a normal outbound call.

ASM-Mode Call Flow with a SIP Agent Endpoint illustrates an ASM-mode call flow in VoIP environment that involves a SIP agent endpoint. HMP software is used for CPA.

ASM-Mode Call Flow with a SIP Agent Endpoint

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends an engage agent request to CPD Server.
  2. CPD Server instructs HMP to create an engage call (leg 10) through SIP Server with an available agent’s route point.
  3. The RoutePoint strategy diverts the engage call to an agent’s desktop.
  4. The agent answers the engage call, which generates an EventEstablished message. An RTP Stream is opened between the Agent’s Endpoint and an HMP Voice Channel.
The agent now waits for OCS and CPD Server to generate a second call (leg 20) to a calling list number.

Step 2

  1. OCS sends Req_MakePredictiveCall to CPD Server. This request contains SAttr_DialTo, which is the customer phone number.
  2. CPD Server instructs HMP to place a call through SIP Server to the customer number that OCS provided.
  3. If CPA has determined that there is a live voice, CPD Server attaches any customer data to the engage call (leg 10).
  4. SIP Server delivers this data to the engaged agent’s desktop as a screen pop.
  5. HMP connects the Agent (internal) and Customer (external) call legs. RTP is established between the agent and the customer through HMP.

CPD Server informs OCS of the call result. The call is now handled as a normal outbound call.

Outbound Contact with Cisco Unified Communications Manager

This section describes an ASM mode scenario and a Transfer mode scenario using T-Server for Cisco Unified Communications Manager (UCM) and agents.

ASM Mode

The following scenario describes a media flow for Outbound Contact with HMP in ASM mode and the T-Server for Cisco UCM.

ASM-Mode Call Flow—Cisco Unified Communications Manager illustrates the architecture/call flow.

ASM-Mode Call Flow—Cisco Unified Communications Manager

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends an engage agent request to CPD Server.
  2. CPD Server places an engage call using HMP (SIP protocol) to SIP Server.
  3. Using the Trunk Group DN configuration, SIP Server redirects the engage call to Cisco UCM Route Point DN.
  4. As a result of a IRD strategy, URS routes the engage call to an agent who is Ready.
  5. The agent answers the call; in other words the established agent is engaged.

Step 2

OCS sends Req_MakePredictiveCall to CPD Server. This request contains SAttr_DialTo, which is the customer phone number.

  1. CPD Server initiates an outbound call to SIP Server, where another Trunk points to either a Media Gateway or an IP SIP client endpoint.
  2. The SIP call in initiated call.
  3. Using HMP resources, CPD Server performs call progress analysis.
  4. If a positive voice detection occurs, CPD Server bridges the internal leg (the engaged call) and the external leg (the outbound call).
      The call is established between the agent and the customer.

  5. CPD Server informs OCS of the call result.
  6. After the calls are bridged between the customer and the agent, SIP signalling occurs and RTP streams go through HMP.

Transfer Mode

For Transfer mode, Outbound Contact is configured with a centralized CPD Server. In this configuration, SIP Server is used as a switch for dialing to customers and Cisco UCM switch is used to control outbound agents. So, when a call is established with the customer, the outbound call is transferred to the Cisco UCM agent using ISCC (data).

The following scenario describes a media flow for Outbound Contact with HMP in the Transfer mode and the T-Server for Cisco UCM.

Transfer Mode—Cisco UCM illustrates the architecture/call flow.

Transfer Mode—Cisco UCM

Step 1

  1. The OCS sends a dial request to the CPD Server. (Both the OCS and CPD Server are at the central location.)
  2. CPD Server sends a dial request to HMP.
  3. HMP dials the customer’s number.
  4. SIP Server directs the call to the customer through the MGW.
  5. HMP performs call progress detection and sends the call result to CPD Server/OCS.

Step 2

  1. After receiving an Answer call result, CPD Server transfers the call to a Routing Point. (HMP sends REFER to SIP Server and SIP Server sends INVITE to Cisco UCM.
  2. Cisco UCM T-Server, which is monitoring the Cisco Unified Call Manager switch, informs the URS that the call was routed to the Routing Point.
  3. URS routes the call (per the routing strategy, also stored at the central location) sends to Inter Server Call Control (ISCC).
  4. ISCC sends the call to the Cisco UCM switch that is being monitored by the T-Server for Cisco UCM.
  5. The Cisco UCM switch relays the call to Route Point for a group of agents.
After the call is routed to an agent, no SIP signaling or RTP streams go through HMP.

Note:

In this scenario, a transfer of the outbound call occurs rather than a bridging of two calls, as no engage call is placed, The agent is found after the outbound call is placed rather than before.

Outbound Contact with GVP 8.1 (Proactive Contact Solution)

In this scenario, OCS, SIP Server, and GVP 8.1 provide support for self-service campaigns that may or may not involve and agent. SIP Server performs the dialing and MCP provides CPA. The VXML application using HTTP protocol supplies OCS with the interaction outcome. The Power GVP and Progressive GVP modes are supported.

Outbound Contact, GVP 8.1—MCP as the CPA Provider illustrates how to use Outbound Contact with GVP 8.1.

Outbound Contact, GVP 8.1—MCP as the CPA Provider

In this scenario, the call flow proceeds as follows:

Step 1

  1. OCS sends a RequestMakePredictiveCall message to SIP Server. This request contains AttributeOtherDN, which is the customer’s DN.
  2. SIP Server invites MCP/Genesys Media Server to handle CPA.
  3. SIP Server creates the call leg with MCP and establishes a call with the customer DN.
  4. MCP performs CPA and sends the call result to SIP Server.
  5. SIP Server reports the call state to OCS by either EventReleased (for negative call results) or EventEstablished (for positive ones) on the Trunk Group DN.

Step 2

  1. For a positive call result (EventEstablished received), OCS sends the RequestApplyTreatment message to SIP Server to trigger a GVP Voice Application.
  2. SIP Server generates an EventTreatmentApplied message.
      All media streams are between the GVP Voice Application and the customer.

T-Library Functions in an Outbound-VoIP Environment

This section provides attached data and extensions information for T-Library functions when they are used in a VoIP environment.

Note:

For information on the options identified in this section, see the Outbound Contact 8.1 Deployment Guide.

TMakeCall Attached Data and Extensions

OCS uses TMakeCall to initiate an engaging call. TMakeCall Attached Data lists the attached data for TMakeCall.

TMakeCall Attached Data

Data Key

Type

Key Required

Value

Description

GSW_CALL_TYPE

String

Yes

ENGAGING

Identifies the call as an engaging call.

GSW_QUEUE_DBID

Int

Yes

DBID

Identifies the DBID of the Voice Transfer Group DN

GSW_SESSION_DBID

Int

Yes

DIBD

Identifies the DBID of the Campaign Group (Dialing Session) for the initiated call.

TMakeCall Extensions lists the extensions for TMakeCall.
 

TMakeCall Extensions

Data Key

Value

Description

beep

on or off

Enables the playing of a beep tone on an engaging call right before its bridged to a customer call.
This key is associated with beep-on-merge option.

TMakePredictiveCall Attached Data and Extensions

OCS uses TMakePredictiveCall to initiate a customer call. TMakePredictiveCall Attached Data lists the attached data for TMakePredictiveCall

TMakePredictiveCall Attached Data

Data Key

Type

Key Required

Value

Description

GSW_CALL_TYPE

String

Yes

REGULAR

Identifies the call as customer call.

GSW_QUEUE_DBID

Int

Yes

DBID

Identifies the DBID of the Voice Transfer Group DN

GSW_SESSION_DBID

Int

Yes

DIBD

Identifies the DBID of the Campaign Group (Dialing Session) for the initiated call.

TMakePredictiveCall Extensions lists the extensions for TMakePreictiveCall.

TMakePredictiveCall Extensions

Data Key

Value

Description

cpd-record

on or off

Enables or disables the recording of the call progress detection phase of the call, as set in the cpd-recording option.

call_answer_type_recognition

String

Identifies the call progress analysis (CPA) for both the pre-connect (via SIT tones) and the post-connect (either a fax or an answering machine) phases of the call, as set in the call_answer_type_recognition option.

cpd-on-connect

on or off

Indicates when CPA begins, according to the cpd-on-connect option. For Outbound-VoIP ASM modes, set this option to yes to specify that CPA begins after the call is connected.

Note: Setting this option to yes accounts for the use of color ring back tones. If cpd-on-connect does not appear in the extensions, CPA starts as soon as the media stream is available.

Color ring back tones (CRBT) refers to the ability to play other audio sounds (music, voice, and so on) for a busy signal for example, instead of a standard ring back tone.

call_timeguard_timeout

Time in milliseconds

Reflects the setting of the call_timeguard_timeout option, which specifies the maximum time allowed for CPA after the call is connected.

TMergeCall Extensions

TMergeCall Extensions lists the extensions for TMergeCall.

TMergeCall Extensions

Data Key

Value

Description

method

bridging or transfer

Specifies the method of connection to be used. For more information on these methods, see the “Outbound-VoIP Deployment" chapter of the Outbound Contact 8.1 Deployment Guide.

TApplyTreatment Extensions

TApplyTreatment Extensions lists the extensions for TApplyTreatment.

TApplyTreatment Extensions

Data Key

Value

Description

am-beep-detection

on or off

Specifies whether GVP is forced to detect an answering machine beep tone before playing music or starting the VXML application in Outbound VoIP dialing modes, as set in the am-beep-detection option.

This page was last edited on September 15, 2020, at 21:45.
Comments or questions about this documentation? Contact us for support!