FAQs and Glossary

Our MTI – Video Tutorials can be accessed here.

Our toll free Hosting Support hotline is 855-424-9022 or 770-240-8008. You can also send us an email at: hostingsupport@messagetech.com.

Since MTI is the “customer of record” for Genesys and  Nuance, technical issues normally are routed through our technical department. If the problem is new and has not been addressed previously by MTI’s technical group, a trouble ticket is opened. Genesys is contacted in one of a number of ways, depending on the severity of the problem. It is not unusual for MTI to create a conference bridge between our clients and Genesys/Nuance to resolve client problems. MTI is committed to learning as much as possible about its platforms and software, so we will remain part of the discussion group until the trouble ticket is closed.

Normal, non-disruptive maintenance is conducted before 4 PM on Monday -Thursday and before 12:30 PM on Friday. This maintenance does not interrupt the performance of production systems, and occurs regularly without customer notice.
Disruptive maintenance must be scheduled and is normally performed after hours when traffic impact can be minimized. Customers are notified a minimum of 48 hours in advance of any disruptive maintenance.
All production maintenance, either normal or disruptive, requires a documented maintenance plan that is signed off by senior management. The maintenance plan undergoes third-party review and includes test and contingency plans.

For critical service issues or any failure significantly impacting your applications, our emergency support can be contacted using our 24/7 Toll-Free number 855-424-9022 or 770-240-8008. For non-critical service issues or requests, a support ticket can be submitted through the MTI client portal. MTI will provide a response within 1 business day for non-critical issues.

The log files track information about the platform’s health and the processing running on it. It also contains information related to billing which shows date, time, duration and termination of inbound and outbound calls. It also tracks the number of bytes transferred during a call. Additionally, it contains information about rejected inbound calls that did not result in platform answer supervision and a connection.

The metrics information is the most helpful to our clients. This contains information about all the events in a call – every page fetch, bad fetch, recognition event, audio (prompt) event, recording, user logging, etc. MTI has developed a web service to allow our clients to retrieve their metrics log records. Other log files can be turned on as needed but since they consume large amounts of disk space, they are used only when a problem can not be resolved through the use of the standard log files. These additional log files include the trace logs and the ASR logs. When needed, MTI turns these logging facilities on and delivers the logs to the client and/or the Vendor for analysis.

We currently support carrier service from Verizon Business, AT&T, and Global Crossing. We also have the unique ability to cross-connect TDM or SIP based carrier service from most other common carriers at our facilities. MTI is carrier agnostic which provides our customers with a great degree of flexibility when it comes to transport options.

We partner with our customers to continually monitor and understand projected call volumes on a monthly basis. This includes identifying any marketing programs, new rollouts, or other events that would drive a significant increase in traffic.We then look at our customers’ current volumes and projections in aggregate, and build out our capacity such that we’re operating normally at a peak of 70-80% of our total capacity. This leaves an additional 20-30% of capacity for peaks, bursts, or other unanticipated traffic. When our normal operating threshold reaches 80%, or if customer projections dictate, we have internal procedures that trigger us to add incremental capacity. Adding capacity is something we do on a regular basis, so we have established processes for telephony provisioning, software licensing, hardware procurement, etc. that enable us to expand significantly in a matter of days.

Genesys 7.2x is a VOIP (SIP based) platform. MTI supports Voice over IP (VoIP) traffic through Paraxip and Audiocodes gateways that are connected to our switches. These gateways provide comprehensive and highly flexible bridge between the traditional telephony network and IP-based platforms and applications.

We currently support in-network routing/transfer features from both AT&T, via Transfer Connect, and MCI, via ECR. We have developed proprietary templates that enable our platform to interact with these carrier-based features.

We allow our customers to choose from the industry’s best -of-breed ASR and TTS engine–Genesys.

The Genesys environment’s ASR is decoupled from the platform. It supports a number of third-party vendors of ASR and TTS speech engine resources (such as Nuance, IBM, and AT&T Watson or any MRCP compliant ASR). Currently most of our customers on the Genesys platform use Nuance’s “Open Speech Recognizer” for ASR and Realspeak for TTS.

Does MTI allow customers to terminate calls using the SIP protocol? Yes, MTI will allow calls to terminate as SIP at our Atlanta data center. Please contact an account representative for further information.

MTI’s philosophy has been to create “high-availability” systems within its facilities with redundancy layered in to complement the infrastructure.  For example, MTI uses multiple voice gateway platforms, each with redundant power supplies, redundant network interface cards, and RAID-5 technology.  The redundant power supplies are each connected toredundant UPS systems.  The redundant NICs are each connected to redundant internal LANs. The redundant power supplies, NICs, and RAID-5 technology create high-availability, while the use of multiple voice gateway platforms provides high redundancy. This high-availability strategy covers most common “disaster” events, such as a power loss, or a LAN segment failure.

VXML Hosting Upgrade Policy: 
MTI will upgrade to the latest Generally Available(GA) version of VoiceGenie software on non dedicated platforms within 30 days of it’s release date or the confirmation of approval by all customers on that platform for the upgrade.

MTI may delay or roll back an upgrade if it is found to adversely affect system performance. Dedicated platforms will be upgraded at the hosting customer’s request. In either case the following procedures should be followed.
Procedure for platform upgrades – MTI will notify the hosting customer’s technical contact of the schedule for planned software upgrades. This will include:

• The date the new version is available on the VoiceGenie developer node.
• The date the software is Generally Available.
• The scheduled date of the roll in.
• The current status of an upgrade one week and also the day prior to the roll in.
• Any available documentation or links thereto on the software release.

MTI will install the new version on the MTI test nodes within one week of GA. Platform upgrades will only be performed during non-peak hours.
This is MTI’s recommended procedure for testing hosted applications prior to a VoiceGenie software upgrade.

• Read the software release notes for changes and analyze your applications for any potential issues.
• Confirm that the new version of the VoiceGenie software is running on the VoiceGenie development nodes.
• Test the existing applications on the VoiceGenie development nodes.
• Make any required modifications to a new version of the hosted application.

Once the new version of the VoiceGenie software is on MTI’s test node, test the modified version of the hosted application on MTI’s test node. When the application is ready for the new version of the VoiceGenie software contact MTI hosting support to give approval for the software upgrade. Coordinate the roll-in of the hosted application with the upgrade of the VoiceGenie software on the production nodes.

The redundant systems are in play all the time. That is, we support n+1 redundancy with our platforms, and all of those platforms are carrying load. It’s just that there are enough platforms so that if one goes off-line, the rest can handle the load. With respect to power, we test the UPS systems quarterly but we are hesitant to actually pull power from equipment by taking a UPS off-line. In our current configuration, UPS “C” is handling just about all the equipment. UPS “A” and “B” provide redundancy for UPS “C”. All of our gear has dual power supplies, so each piece of equipment is connected to UPS “C” and either UPS “A” or UPS “B”.

Our hosting infrastructure is shared across our entire customer base, and our platform consists of thousands of IVR ports. We monitor volume trends closely and work with each of our customers on a monthly basis to understand volume projections and business events that may lead to bursts and spikes in call traffic.

We build out our capacity such that at projected volume levels we are operating at 70 – 80% utilization of our infrastructure. This means that we consistently have 20 – 30% of our capacity available to absorb unanticipated bursts and spikes in customer traffic. As utilization levels approach 80%, automated triggers within our platform indicate that additional capacity is required. Because capacity is added on a regular basis, our standardized processes enable us to significantly expand our infrastructure within a matter of days

Additionally, our contracted service levels guarantee that we successfully process 99.97% of call traffic with no inbound busy signals or other platform-related disruptions.

Test environments have their own dedicated resources, including speech resources, databases, administrative interfaces, data switches, and controls – which are run on production grade equipment.

Production environments likewise have their own, dedicated resources. The production environment is distributed across multiple servers making use of redundant power supplies, RAID arrays, and NIC teaming/bonding to prevent single points of failure.  Additionally, this distributed architecture allows for scalability as required by customer volume growths.

We have a primary data center on-site in our Atlanta, GA headquarters and a backup/disaster recovery data center in Dallas, TX. The Atlanta facility handles our day-to-day operations. The Dallas facility is part of our business continuity plan, enabling calls destined for Atlanta to be re-routed to Dallas in the event of a major outage in Atlanta.

Yes, we have situations where the database systems are not resident in our local hosting environment. Security and access to the database systems are handled on a case-by-case basis. VPN often works nicely for this. We also suggest implementing IP address restrictions to further control access to remote systems. In some cases, dedicated circuits are used to pass data to and from remote database systems. In addition to direct database connections, MTI commonly performs integrations that make use of web services.

Yes,  MTI provides the capability to initiate an SMS message from IVRapplications via an XML request to a 3rd party SMS aggregator. If you are developing your own applications, you will be responsible for contracting and providing the SMS aggregator service.

The Platforms routinely maintain log files that track information about the platform’s health and the processing running on it. This information is used internally by MTI. These files contain information about all the events in a call – every page fetch, bad fetch, recognition event, audio (prompt) event, recording, user logging, etc. MTI has developed a web service to allow our clients to retrieve their log records. Other log files can be turned on as needed but since they consume large amounts of disk space, they are used only when a problem can not be resolved through the use of the standard log files. These additional log files include the trace logs and ASR logs. When needed, MTI turns these logging facilities on and delivers the logs to the client for analysis.

Yes. In fact we recommend that our customers use a three-step development process. The first step is to use our development environment that provides access to log files and other information necessary to debug applications.
Once your application is fully developed and debugged, it is migrated to our staging environment where the code is tested a final time to ensure that it will operate without issues on our production environment.
Once the code is fully vetted in the staging environment, it is migrated to our production environment. If the application runs without issues in the development and staging environments, it is assured to run without errors in the production environment.

MTI presents the Genesys platforms as is with almost no additional software wrapped around it. There are two notable exceptions. First, MTI developed a web service to handle client’s requests for outbound calling. Second, MTI developed a web site to allow clients to access their metrics log records. MTI does not allow clients access to the platform pool manager or direct access to the platform OS. Our goal is to provide a stable production grade platform to our hosting clients, so we control direct access to the platform, the changing of platform parameters and the enabling or disabling of platform features.

The data center is fully protected with a state-of-the-art FM-200 Clean Agent fire suppression system by Cerberus Pyrotronics, controlled with a MRP-4424 Extinguishing Agent Release Panel. The system is fully automated and also is coupled to a Manual Pull, Manual Abort and two stage alert alarms. All technical personnel have been trained on the operation of this system.

We support user level VPN as well as site-to-site VPN where required. This allows remote administration to hosted services.
Client’s can either contract with MTI to monitor their specific applications or can coordinate self-directed or independent monitoring and administration of their platform and applications. MTI on its part continually monitors the integrity of its systems using an array of methods, including automated log parsers, automated health monitors and automated calling systems. In terms of applications, MTI’s software is appropriately instrumented to monitor all activities, whether on the front or back end of the application. We produce logs and audit trails of all activity which allows us and our customers to easily monitor who initiates activity, when it occurs, and on what platform it takes place.

We accomplish load balancing through the use of multiple SIP proxy servers, which distribute traffic evenly across multiple platforms.

Atlanta- The overall facility’s physical security is modeled using HIPAA (The Health Insurance Portability and Accountability Act of 1996) security guidelines. Visitors must check in and are accompanied by an employee while in our space. The front entrance area is isolated from the remainder of the premise by locked doors. After 5:00pm access to the MTI floor is restricted to employees with an electronic key fob. After gaining entrance to the floor, employees must enter an access code to gain access to the remainder of the premise. The Atlanta datacenter is secured at all times via an electronic key fob system. All admissions are recorded for demand review by security and/or management.
Dallas- Access to the InfoMART facility is controlled by a 24/7 security guard. Access to the floor is controlled by the security guards. Access to the co-location facility is controlled by electronic key-card. Access to the racks are controlled by multiple combination locks, to which the combinations are known only by MTI’s CEO/CTO and Network Manager. In addition to MTI’s technical team, Broadwing has access to the co-location in case emergency technical assistance is required. InfoMART personnel do not have direct access to the co-location, but must go through Broadwing.

MTI has modeled its security process against the HIPAA standard. In addition to the physical security that protects computers and databases, we have a variety of protocols in place such as: requiring workstations to become password locked after five minutes of inactivity; limiting logical access to database systems to the appropriate personnel; limiting access to certain database systems to certain physical workstations; requiring all personnel to be familiar with the security rules at MTI; recurring training of personnel on security rules; discouraging the use of paper printouts of client data containing any personal information and requiring the shredding of any printouts that do contain data of a personal nature. Additionally, as a matter of policy, MTI will release client information to a third party only when required by law.

Genesys provides a developer portal with tutorials and comprehensive documentation.  http://devzone.genesyslab.com/default.aspx Using the portal is easy. Just sign up for an account and click the resources tab.

Here are a couple of good resources:

VoiceXML Forum
W3C Consortium

How to build a Speech Recognition Application, Second Edition This is a useful book by Bruce Balentine and David P. Morgan. It is a style guide for telephony dialogues. It is considered to be a thorough, practical, step-by-step guide to using speech recognition, written by experts who have been designing and developing successful applications for years.

MTI supports the following modules:

• SpeechSecure
• Commerce
• Core
• Address
• Name

From Webopedia:
Short for Voice Extensible Markup Language. VXML, or VoiceXML, technology allows a user to interact with the Internet through voice-recognition technology. Instead of a traditional browser that relies on a combination of HTML and keyboard and mouse, VXML relies on a voice browser and/or the telephone. Using VXML, the user interacts with voice browser by listening to audio output that is either pre-recorded or computer-synthesized and submitting audio input through the user’s natural speaking voice or through a keypad, such as a telephone. AT&T, IBM, Lucent Technologies, and Motorola created VXML 1.0 in a joint effort to promote the technology.

ECR numbers are MCI/Verizon numbers that are capable of performing  take back and transfers. ECR stands for Enhanced Call Routing. This service enables calls routed to your application hosted at MTI to be transferred to another number under certain conditions. An example would be to escalate a caller that is having trouble with the application to a support person in a call center.

Yes. MTI supports the SpeechSecure dialog module from Nuance.

No. Cached files are maintained on the VXML platform. Please contact technical support if your application requires preloading of files.

No, the DOCTYPE tag should not be used in grammar files.

Yes, MTI supports Spanish TTS voices using Nuance RealSpeak. The MTI resource names which should be specified in your VXMLapplications are REALSPEAK_JAVIER and REALSPEAK_PAULINA.

Yes, the speed can be controlled by placing the TTS text within SSML<prosody/> tags. Using the prosody tags allows the developer to control the pitch, rate, duration, and volume of the text that will be spoken by the TTS Engine. For additional information, please visit Genesys at: http://developer.voicegenie.com/voicexml2tagref.php?tag=ss_prosody&display=ssmltags.

Yes, MTI supports German TTS using Nuance Realspeak. The resource name that should be specified in your VXML application is REALSPEAK_STEFI.

A line representing a T1 takes an average of 3 to 4 weeks.

To specify an ASR engine, use the following property tag: <property name=”ASRENGINE” value=”SPEECHWORKS”/>. To specify a TTSengine, use this tag: <property name=”TTSENGINE” value=”REALSPEAK_TOM”/> NOTE: you can also specify “REALSPEAK_JILL” for the value.

Use the following property tag:<property name=”bargein” value=”false”/>

• true – any user input can barge in during prompts. Note that if bargein is true for a queued prompt, all subsequent prompts in the queue will be treated as if bargein is true.
• false – no user input can barge in during prompts.
• dtmf – only DTMF input can barge in during prompts; speech input is ignored until the completion of the prompts; both speech and DTMF input can be collected after the completion of the prompts.

In order for a property to take effect in an OSDM you have to pass it to the OSDM. It should also be noted that OSDMs have different contexts and therefore the property needs to be set for a specifc context. For example if you need to set the incomplete_time out property for the confirmation context of the DM you will need to use the variable: property_confirmation_incompletetimeout
Similarly for collection context you will need to use:  property_collection_incompletetimeout

Here is an example of how this property is set for the confirmation phase of the Currency OSDM:

<?xml version=”1.0″?>
<vxml version=”2.0″ xmlns=”http://www.w3.org/2001/vxml“>
<meta name=”application” content=”AUDIO/ASR/TTS Test Application”/>
<property name=”METRICSLEVEL” value=”3″/>
<property name=”asrengine” value=”SPEECHWORKS” />
<property name=”ttsengine” value=”REALSPEAK_JILL” /> <form id=”TestCurrencyDM”>

<var name=”dmname” expr=”‘myCurrencyDM'”/>
<var name=”property_confirmation_incompletetimeout” expr=”‘7000ms'” />

<subdialog name=”my_Currency”
realrealsrc=”   namelist=”dmname property_confirmation_incompletetimeout”>
<filled>
<if cond = “my_Currency.returncode == ‘SUCCESS'”>
<prompt>
You said:
<say-as interpret-as=”currency”>
<value expr=”my_Currency.returnvalue”/>
</say-as>.
</prompt>
<else/>
<prompt> The OSDM failed </prompt>
</if>
</filled>
</subdialog>

</form>

</vxml>

Please contact your MTI Account Manager to do this.

Please contact your account manager with an initial URL for your application and request a test number for the staging platform.

Use the following property tag: <property name=”confidencelevel” value=”0.45″/> Values range from 0.0 (minimum confidence) to 1.0 (maximum confidence).

The SSML lexicon tag allows you to reference a user dictionary in your application. Included below is a sample app the shows how this can be done.

The “TestLexiconTag.vxml”application just plays a prompt with the word Verizon in it. Verizon is one of the words being pronounced incorrectly by the RealSpeak TTS. Before we play the prompt we define a user dictionary (SampleDic.tdc) through the SSML lexicon tag, which has the correct pronunciation for the word Verizon. When the word Verizon is played it picks up the correct pronunciation from the defined user dictionary.

TestLexiconTag.vxml

<?xml version=”1.0″?>

<vxml version=”2.0″ xmlns=”http://www.w3.org/2001/vxml” application=”AppRoot.vxml”>

<form id=”greeting”>

<block>

<prompt bargein=”false”>

<lexicon uri=”The_Complete_HTTP_Path/SampleDic.tdc” />

I am trying to say Verizon.

</prompt>

</block>

</form>

</vxml>

SampleDic.tdc

[Header]

[SubHeader]

Language=ENU

Content=EDCT_CONTENT_BROAD_NARROWS

Representation=EDCT_REPR_SZZ_STRING

[Data]

Verizon            //         ‘vE0R=a&Iz$n

[SubHeader]

Language=ENU

Content=EDCT_CONTENT_ORTHOGRAPHIC

Representation=EDCT_REPR_WSZ_STRING

[Data]

You should add the following tags to your top-level VoiceXML page: <meta name=”maintainer” content=”my.address@mydomain.com”/> <meta name=”application” content=”My Application Name”/>

Yes, user defined dictionaries are supported through the use of the <lexicon> tag. These pronunciation dictionaries are simple XML files that list vocabulary items and their phonemic representations.

Yes, The IVR application can be designed to route callers based on point of origin adhering to routing and business rules defined by our customers. For example, callers from a particular area code or exchange can be routed to a particular call center. Calls can be routed based on NPA alone, or based on the NPA and NXX.

MTI currently has Nuance SpeechSecure speaker verification software. However, we currently have no clients using the package, so we can’t attest to its performance. SpeechSecure uses biometric technology to verify a caller’s identity based on the characteristics of his or her unique vocal patterns. SpeechSecure provides a convenient and extremely tight level of security for callers who access personal information over the telephone. From financial services to telephony services, SpeechSecure opens the door to a host of commercial applications where high security and/or high convenience is required.

No, DTD’s and XML schemas should not be used in our production environments. DTD/Schemas can be used during development to make sure that generated XML documents are in the correct format. All references to DTD’s and XML schemas should be removed prior to migrating to production.

You can specify parameters for the <audio> and <goto>/<submit> tag URIs, allowing dynamic generation of the responses. Note that for <goto>/<submit> you must specify method=”GET” as well.

At this time, there are no restrictions on the size of the application data, bandwidth usage, etc. Well designed applications tend to use limited amounts of data at one time. We do provide a mechanism to compile large grammars for faster loading. We also support the caching of grammars, audio and applications as a means of reducing bandwidth requirements. We routinely evaluate our client’s bandwidth utilization to determine if adjustments need to be made to our infrastructure or the client’s modus operandi.

Clients must explicitly specify the TTS and ASR engines to use in their application. Do not assume a default exists or will stay the same throughout your application’s life cycle.

Clients must request permission to use whole call recording. Additionally, clients will be given a subdirectory destination to write recordings. Whole call recording is for limited use only and on a limited number of concurrent calls.

Program your defaults into your applications. Do not rely on the use of custom default files associated with specific DNISs. Since custom default files require manual modification of parms.dat on the VG platform and since manual changes to that file do not take effect until VG services are restarted, it is not a recommended procedure.

Yes! While OSDMs are designed to work with any VoiceXML interpreter that follows the VXML 1.0 or 2.0, 2.1 standard, it is recommended to use the Nuance OSR engine. Please schedule a call with our technical support team to discuss implementation options.

MTI generates bills using VoiceGenie’s “billing” logs. When matching these log records to our carrier’s call detail records, we found matching in excess of 99.99%.

If our client is using MTI’s long-distance facilities (i.e., they are not terminating call traffic at MTI that is billed to a third-party elsewhere), then MTI will provide upon request copies of the carrier’s call detail records for the cleint’s toll-free numbers terminating at MTI.

If the client is using cross-corp billing to route traffic to MTI, then the call detail records are not available to MTI. In any case, comparing MTI’s billing records to the carrier’s call detail records is an excellent way to validate billing minutes.

Call detail records typically are provided via email attachments. We also can provide the records in hard-copy or via CD or DVD. The bills themselves are presented electronically via email or in hard copy.

For more information on hosting your application, you can email our sales team at:

sales@messagetech.com

or have one of our sales representatives contact you by filling out our contact form.

You can also call us and ask to speak with a sales representative: 770-240-8000