370 likes | 488 Views
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 mark.rayburn@cptii.com. Bogies. Share a real world experience SIP, not just for breakfast anymore
E N D
SIP-Based Control forLegacy Infrastructure(SIP-09) Mark E. Rayburn Advanced Technology Group CPT International Inc. Atlanta, GA Creators of Voice Harbor™, Voice Application Hosting mark.rayburn@cptii.com
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
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) The Pain
Legacy Inbound Flow : Analysis PSTN Proprietary DNIS/URI Mapping Switch DNIS Synchronization Issues Tandem Switch Proprietary Log Format DNIS DNIS Complex Conversion and Data Acquisition VoiceXML Logs CDRs Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs Each blind transfer used 4 switch ports and 2 VoiceXML ports Application
Legacy Outbound Flow : Analysis Vendor API to kick off call PSTN Internet Switch Proprietary Log Format Switch Tandem HTTP API Complex Conversion and Data Acquisition Service VoiceXML CPA Logs Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs Application CDRs
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 : Changes PSTN Proprietary DNIS/URI Mapping Switch DNIS Synchronization Issues Tandem Switch Proprietary Log Format DNIS DNIS Complex Conversion and Data Acquisition VoiceXML Logs CDRs Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs Each blind transfer used 4 switch ports and 2 VoiceXML ports Application
Legacy Inbound Flow : Changes SIP eliminates DSP board in VoiceXML Gateway. DTMFs sent via RFC 2833 PSTN Switch Tandem Switch SIP DNIS DNIS VoiceXML Logs CDRs Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs Application
Legacy Inbound Flow : Changes PSTN Proprietary DNIS/URI Mapping Switch DNIS Synchronization Issues Tandem Switch Proprietary Log Format SIP DNIS DNIS Complex Conversion and Data Acquisition VoiceXML Logs CDRs Each blind transfer used 4 switch ports and 2 VoiceXML ports Application
Legacy Inbound Flow : Changes SIP Invite allows passing the URL from the switch. PSTN Proprietary DNIS/URI Mapping Switch DNIS Synchronization Issues Tandem Switch SIP DNIS/URL VoiceXML Switch application DNIS database expanded to include starting URL. Logs CDRs Application
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 4 switch ports and 2 VoiceXML ports Application
Legacy Inbound Flow : Changes Switch application now drops call information directly to the CDR database. No conversions or complex data acquisition required. PSTN Switch Tandem Switch Proprietary Log Format SIP CDRs DNIS/URL Complex Conversion and Data Acquisition VoiceXML Proprietary VoiceXML logs no longer needed. Application
Legacy Inbound Flow : Changes PSTN Switch Tandem Switch SIP CDRs DNIS/URL VoiceXML Each blind transfer used 4 switch ports and 2 VoiceXML ports Application
Legacy Inbound Flow : Changes Switch application sees the REFER and bridges the call through the Switch and frees the VoiceXML ports for other calls. PSTN Switch Tandem Switch SIP CDRs DNIS/URL VoiceXML VoiceXML sends a REFER to the Switch on a blind transfer. Each blind transfer used 4 switch ports and 2 VoiceXML ports Application
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 Switch to VoiceXML gateway is now SIP Vendor API to kick off call PSTN Internet Switch Proprietary Log Format Switch Tandem HTTP API Complex Conversion and Data Acquisition Service VoiceXML CPA Logs Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs Application CDRs
Legacy Outbound Flow : Changes PSTN Internet Switch Proprietary Log Format Switch Tandem HTTP Complex Conversion and Data Acquisition CPA CDRs VoiceXML API Service Switch is now writing CDRs directly, so no VoiceXML logs are needed. Application
Legacy Outbound Flow : Changes Vendor API to kick off call PSTN Internet Switch Switch Tandem HTTP CPA CDRs VoiceXML API Data Acquisition for CPA data Service Application
SIP Outbound Flow : Changes Vendor API to kick off call Switch application now performing CPA, so the outdial service is the same for all VoiceXML gateways PSTN Internet Switch Switch Tandem HTTP SIP Service VoiceXML CDRs Data Acquisition for CPA data Switch application now performing CPA, so this data can be logged with CDR Application
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 Internet Switch Switch Tandem HTTP SIP Invite with URL & CPA Service CDRs VoiceXML Call ID exposed to Application Application
Legacy Outbound Flow : BEFORE PSTN Internet Switch Switch Tandem HTTP API Service VoiceXML CPA Logs Application CDRs
SIP Outbound Flow : AFTER PSTN Internet Switch Switch Tandem HTTP SIP Invite with URL & CPA Service CDRs VoiceXML Call ID exposed to Application 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 YOUfor your Time, Thoughts, and Attention Feedback, suggestions, or follow up is very welcome: Mark.Rayburn@CPTii.com
What is VoiceXML? • An XML variant used to describe DTMF, Advanced Speech Recognition (ASR), and/or Text-to-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