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

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

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

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

6. Legacy Inbound Flow Switch PSTN VoiceXML Switch Logs DNIS CDRs Tandem Proprietary DNIS/URI Mapping DNIS Synchronization Issues Proprietary Log Format Complex Conversion and Data Acquisition Application Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs Each blind transfer used 4 switch ports and 2 VoiceXML ports : Analysis

7. Legacy Outbound Flow Switch PSTN VoiceXML Switch Logs CDRs Service Tandem Internet CPA Application HTTP API Vendor API to kick off call Proprietary Log Format Complex Conversion and Data Acquisition Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs : Analysis

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

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

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

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

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

13. Legacy Inbound Flow Switch PSTN VoiceXML Switch Logs DNIS CDRs Tandem Application Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs : Changes Proprietary DNIS/URI Mapping DNIS Synchronization Issues Proprietary Log Format Complex Conversion and Data Acquisition Each blind transfer used 4 switch ports and 2 VoiceXML ports

14. Legacy Inbound Flow Switch PSTN Switch Logs DNIS CDRs Tandem Application : Changes VoiceXML SIP SIP eliminates DSP board in VoiceXML Gateway. DTMFs sent via RFC 2833 Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs

15. Legacy Inbound Flow Switch PSTN Switch Logs DNIS CDRs Tandem Application : Changes VoiceXML SIP Proprietary DNIS/URI Mapping DNIS Synchronization Issues Proprietary Log Format Complex Conversion and Data Acquisition Each blind transfer used 4 switch ports and 2 VoiceXML ports

16. Legacy Inbound Flow Switch PSTN Switch Logs CDRs Tandem Application : Changes VoiceXML SIP DNIS/URL Switch application DNIS database expanded to include starting URL. Proprietary DNIS/URI Mapping DNIS Synchronization Issues SIP Invite allows passing the URL from the switch.

17. Legacy Inbound Flow Switch PSTN Switch Logs CDRs Tandem Application : Changes VoiceXML SIP Proprietary Log Format Complex Conversion and Data Acquisition Each blind transfer used 4 switch ports and 2 VoiceXML ports DNIS/URL

18. Legacy Inbound Flow Switch PSTN Switch CDRs Tandem Application : Changes VoiceXML SIP DNIS/URL Proprietary Log Format Complex Conversion and Data Acquisition Switch application now drops call information directly to the CDR database. No conversions or complex data acquisition required. Proprietary VoiceXML logs no longer needed.

19. Legacy Inbound Flow Switch PSTN Switch CDRs Tandem Application : Changes VoiceXML SIP Each blind transfer used 4 switch ports and 2 VoiceXML ports DNIS/URL

20. Legacy Inbound Flow Switch PSTN Switch CDRs Tandem Application : Changes VoiceXML SIP DNIS/URL Switch application sees the REFER and bridges the call through the Switch and frees the VoiceXML ports for other calls. Each blind transfer used 4 switch ports and 2 VoiceXML ports VoiceXML sends a REFER to the Switch on a blind transfer.

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

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

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

24. Legacy Outbound Flow Switch PSTN Switch Logs CDRs Service Tandem Internet CPA Application HTTP API Vendor API to kick off call Proprietary Log Format Complex Conversion and Data Acquisition Proprietary DSP and Network Interface Cards Excess Resources: Switch already has DSPs : Changes Switch to VoiceXML gateway is now SIP VoiceXML

25. Legacy Outbound Flow Switch PSTN Switch CDRs Service Tandem Internet CPA Application HTTP API Proprietary Log Format Complex Conversion and Data Acquisition : Changes VoiceXML Switch is now writing CDRs directly, so no VoiceXML logs are needed.

26. Legacy Outbound Flow Switch PSTN Switch CDRs Service Tandem Internet CPA Application HTTP API : Changes VoiceXML Vendor API to kick off call Data Acquisition for CPA data

27. Switch PSTN VoiceXML Switch CDRs Service Tandem Internet Application HTTP SIP Data Acquisition for CPA data Vendor API to kick off call Switch application now performing CPA, so the outdial service is the same for all VoiceXML gateways Switch application now performing CPA, so this data can be logged with CDR SIP Outbound Flow : Changes

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

29. SIP Phase 1 Outbound Call Flow Switch PSTN VoiceXML Switch CDRs Service Tandem Internet Application HTTP SIP Invite with URL & CPA Call ID exposed to Application

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

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

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

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

34. Questions? and/or Discussion

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

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