1 / 36

SIP-Based Control for Legacy Infrastructure (SIP-09)

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

ellis
Télécharger la présentation

SIP-Based Control for Legacy Infrastructure (SIP-09)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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.

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. SIP Phase 1 Inbound Call Flow PSTN Switch Tandem Switch SIP Invite with URL VoiceXML DNIS/URL CDRs Application

  21. Legacy Inbound Flow : BEFORE PSTN Switch Tandem Switch DNIS DNIS VoiceXML Logs CDRs Application

  22. SIP Inbound Flow : AFTER PSTN Switch Tandem Switch SIP Invite with URL VoiceXML DNIS/URL CDRs Application

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. Legacy Outbound Flow : BEFORE PSTN Internet Switch Switch Tandem HTTP API Service VoiceXML CPA Logs Application CDRs

  30. SIP Outbound Flow : AFTER PSTN Internet Switch Switch Tandem HTTP SIP Invite with URL & CPA Service CDRs VoiceXML Call ID exposed to Application Application

  31. 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

  32. 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

  33. Questions? and/or Discussion

  34. THANK YOUfor your Time, Thoughts, and Attention Feedback, suggestions, or follow up is very welcome: Mark.Rayburn@CPTii.com

  35. 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

More Related