Transcript What is VoiceXML?

SIP-Based Control for
Legacy Infrastructure
(SIP-09)
Mark E. Rayburn
Advanced Technology Group
CPT International Inc. Atlanta, GA
Creators of Voice Harbor™, Voice Application Hosting
[email protected]
Bogies





Share a real world experience
SIP, not just for breakfast anymore
Tips for encouraging Vendor collaboration
Reinforce the value of Standards
Inspire developers to innovate with SIP

SIP, the new duct tape?
 Exposure to VoiceXML Hosting
The Situation
Hosted IVR Service Provider
 Large Scale, Carrier Class, Vendor Neutral




Hundreds of Applications
Thousands of ports per application
Very fast start-up or expansion requirements
Multiple sites
 VoiceXML gateways (for Interactive Voice Response)


Connected to switching fabric via ISDN
Proprietary DSP boards required
The Pain
Growth
 Need to scale quickly
 Need to add and support multiple vendors easily
Cost
 Need to maximize the density of all components
 Need to remove wasteful resources
 Perform “smarter” bridges (hairpin in the Switch)
Legacy Inbound Flow:
PSTN
Switch
Analysis
Proprietary DNIS/URI Mapping
DNIS Synchronization Issues
Tandem
Switch
Proprietary Log Format
DNIS
DNIS
VoiceXML
Complex Conversion
and
Data Acquisition
Logs
CDRs
Each blind
transfer used
Application
4 switch ports and
2 VoiceXML ports
Excess Resources:
Switch already has DSPs
Proprietary DSP and
Network Interface Cards
Legacy Outbound Flow:
Analysis
Vendor API to kick off call
PSTN
Switch
Internet
Proprietary Log Format
Switch
Tandem
HTTP
API
Logs
Application
Complex Conversion
and
Data Acquisition
Service
VoiceXML
CPA
Excess Resources:
CDRs
Switch already has DSPs
Proprietary DSP and
Network Interface Cards
Analysis Recap
Too much work for each VoiceXML Gateway Vendor
 DNIS/URL Administration


Train Support on new Admin interface
Handle sync issues with switch database
 Call record logging




Understand the format
Schedule data acquisition
Provide data access to VoiceXML log storage
Convert VoiceXML log to internal CDR format
 Outdial API


Convert to Customer facing UI
Retain and integrate CPA, if necessary
Analysis Recap (continued)
Squeeze out excesses
 DSP Resources

Why have this in Switch AND VoiceXML?
 Network Interfaces

Buying 2 additional network interfaces (DS1) to connect the
VoiceXML gateway to the Switch
 Transfers

Stop using DSP board to bridge the call
Strategy: Phase the Work
Phase 1
 Use SIP between Switch and VoiceXML gateways
 Design “Smart” blind transfers (Switch Only)
 KISS Philosophy



no carrier issues
all under “our roof” (more control)
less interoperability and testing issues
 Biggest gains – lowest risk
SIP Phase 1 Development
 Develop a Switch-centric architecture
 Identify needs from vendors


Call Progress Analysis (CPA) – must be done using the
DSPs in the switch
Need to pass URL to VoiceXML on Invite
 Identify other gaps & dependencies in “other”
areas

Reporting, CDRs, Etc.
Phase 1 SIP Expected Benefits
 Densest configuration for the Switch

Doubles the capacity per chassis
 Densest configuration for the VXML gateways

Doubles the capacity per chassis
 Eliminate the need for a DSP board in the gateway




Thousands of dollars saved per DS1
Hundreds of dollars saved per gateway chassis
Saves rack space, power, and cooling costs
Enables blade server option for gateways
Legacy Inbound Flow:
PSTN
Switch
Changes
Proprietary DNIS/URI Mapping
DNIS Synchronization Issues
Tandem
Switch
Proprietary Log Format
DNIS
DNIS
VoiceXML
Complex Conversion
and
Data Acquisition
Logs
CDRs
Each blind
transfer used
Application
4 switch ports and
2 VoiceXML ports
Excess Resources:
Switch already has DSPs
Proprietary DSP and
Network Interface Cards
Legacy Inbound Flow:
Changes
SIP eliminates DSP board in
VoiceXML Gateway.
PSTN
Switch
DTMFs sent via RFC 2833
Tandem
Switch
SIP
DNIS
DNIS
VoiceXML
Logs
CDRs
Application
Excess Resources:
Switch already has DSPs
Proprietary DSP and
Network Interface Cards
Legacy Inbound Flow:
PSTN
Switch
Changes
Proprietary DNIS/URI Mapping
DNIS Synchronization Issues
Tandem
Switch
Proprietary Log Format
SIP
DNIS
DNIS
Complex Conversion
and
Data Acquisition
VoiceXML
Logs
CDRs
Each blind
transfer used
Application
4 switch ports and
2 VoiceXML ports
Legacy Inbound Flow:
Changes
SIP Invite allows
passing the URL
from the switch. Proprietary DNIS/URI Mapping
PSTN
Switch
DNIS Synchronization Issues
Tandem
Switch
SIP
DNIS/URL
VoiceXML
Logs
CDRs
Application
Switch application DNIS
database expanded to
include starting URL.
Legacy Inbound Flow:
Changes
PSTN
Switch
Tandem
Switch
Proprietary Log Format
SIP
DNIS/URL
Complex Conversion
and
Data Acquisition
VoiceXML
Logs
CDRs
Each blind
transfer used
Application
4 switch ports and
2 VoiceXML ports
Legacy Inbound Flow:
Changes
Switch application now
drops call information
directly to the CDR
database. No conversions
or complex data acquisition
required.
PSTN
Switch
Switch
Tandem
Proprietary Log Format
SIP
DNIS/URL
CDRs
Complex Conversion
and
Data Acquisition
VoiceXML
Application
Proprietary VoiceXML
logs no longer needed.
Legacy Inbound Flow:
Changes
PSTN
Switch
Switch
Tandem
SIP
DNIS/URL
VoiceXML
Each blind
transfer used
Application
4 switch ports and
2 VoiceXML ports
CDRs
Legacy Inbound Flow:
Switch application sees the REFER
and bridges the call through the
Switch and frees the VoiceXML
ports for other calls.
PSTN
Switch
Switch
Changes
Tandem
SIP
DNIS/URL
CDRs
VoiceXML
Each blind
transfer used
Application
4 switch ports and
2 VoiceXML ports
VoiceXML sends a
REFER to the Switch
on a blind transfer.
SIP Phase 1 Inbound Call Flow
PSTN
Switch
Tandem
Switch
SIP Invite with URL
VoiceXML
DNIS/URL
CDRs
Application
Legacy Inbound Flow:
BEFORE
PSTN
Switch
Tandem
Switch
DNIS
DNIS
VoiceXML
Logs
CDRs
Application
SIP Inbound Flow:
AFTER
PSTN
Switch
Tandem
Switch
SIP Invite with URL
VoiceXML
DNIS/URL
CDRs
Application
Legacy Outbound Flow:
Changes
Vendor API to kick off call
Switch to VoiceXML
gateway is now SIP Internet
PSTN
Switch
Proprietary Log Format
Switch
Tandem
HTTP
API
Complex Conversion
and
Data Acquisition
Service
VoiceXML
Logs
Application
CPA
Excess Resources:
CDRs
Switch already has DSPs
Proprietary DSP and
Network Interface Cards
Legacy Outbound Flow:
PSTN
Switch
Changes
Internet
Proprietary Log Format
Switch
Tandem
HTTP
CPA
VoiceXML
CDRs
API
Service
Application
Complex Conversion
and
Data Acquisition
Switch is now writing
CDRs directly, so no
VoiceXML logs are
needed.
Legacy Outbound Flow:
Changes
Vendor API to kick off call
PSTN
Switch
Internet
Switch
Tandem
HTTP
CPA
VoiceXML
CDRs
API
Service
Application
Data Acquisition for CPA
data
SIP Outbound Flow
: Changes
Vendor API to kick off call
Switch application now performing
CPA,PSTN
so the outdial service is the same
Switch
for all VoiceXML gateways
Switch
Internet
Tandem
HTTP
SIP
Service
VoiceXML
CDRs
Data Acquisition for CPA
data
Application
Switch application now performing
CPA, so this data can be logged
with CDR
Secondary Problem Set
SIP design introduced 2 new challenges
 Communication of CPA info to VXML Gateway


Added an additional parameter to the INVITE message
which contained the CPA information
VoiceXML gateway Vendor exposed the INVITE
parameter in the VoiceXML environment
 Tying application records to CDRs

Used the SIP “CALL ID” header to provide a unique,
unifying field that both the Switch and VoiceXML
application could access
SIP Phase 1 Outbound Call Flow
PSTN
Switch
Internet
Switch
Tandem
SIP Invite with
URL & CPA
Service
CDRs
VoiceXML
Call ID
exposed to
Application
HTTP
Application
Legacy Outbound Flow:
PSTN
Switch
Internet
Switch
Tandem
HTTP
API
Service
VoiceXML
CPA
Logs
Application
CDRs
BEFORE
SIP Outbound Flow:
AFTER
PSTN
Switch
Internet
Switch
Tandem
SIP Invite with
URL & CPA
Service
CDRs
VoiceXML
Call ID
exposed to
Application
HTTP
Application
Conclusions
 SIP greatly simplified the architecture


Reduced points of failure
Reduced long term Development and Operations
 SIP cut costs dramatically


Density
Eliminated excess resources
 SIP cut time to market


Provided a non-proprietary framework
Easy to engage Vendors
Next Steps
SIP Phase 2
 Extend the SIP transfer functionality for more
sophisticated call routing scenarios
 Local number presence by going SIP to the
network
Research
 Prototype to better understand the interplay and
associated strengths of SIP and CCXML
Questions?
and/or
Discussion
THANK YOU
for your
Time, Thoughts, and Attention
Feedback, suggestions, or follow up is very welcome:
[email protected]
What is VoiceXML?
 An XML variant used to describe DTMF,
Advanced Speech Recognition (ASR), and/or Textto-Speech (TTS) applications
 Based on IP and web-centric technologies
 Submitted to the W3C in early 2000, it is now the
preferred IVR (Interactive Voice Response)
 Additional information:

www.voicexml.org