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

SIP-Based Control forLegacy Infrastructure

(SIP-09)

Mark E. Rayburn

Advanced Technology GroupCPT 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

SwitchPSTN

VoiceXML

Switch

Logs

DNISDNIS

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 used4 switch ports and 2 VoiceXML ports

: Analysis

Legacy Outbound Flow

SwitchPSTN

VoiceXML

Switch

Logs

CDRs

Service

Tandem

Internet

CPA

Application

HTTP

API

Vendor API to kick off call



Data Acquisition

Proprietary DSP and Network Interface CardsExcess Resources:

Switch already has DSPs

: Analysis

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

SwitchPSTN

VoiceXML

Switch

Logs

DNISDNIS

CDRs

Tandem

Application



: Changes





Data Acquisition


Legacy Inbound Flow

SwitchPSTN

Switch

Logs

DNISDNIS

CDRs

Tandem

Application

: Changes

VoiceXML

SIP

SIP eliminates DSP board in VoiceXML Gateway.

DTMFs sent via RFC 2833



Legacy Inbound Flow

SwitchPSTN

Switch

Logs

DNISDNIS

CDRs

Tandem

Application

: Changes

VoiceXML

SIP





Data Acquisition


Legacy Inbound Flow

SwitchPSTN

Switch

Logs

CDRs

Tandem

Application

: Changes

VoiceXML

SIP

DNIS/URL

Switch application DNIS database expanded to include starting URL.



SIP Invite allows passing the URL from the switch.

Legacy Inbound Flow

SwitchPSTN

Switch

Logs

CDRs

Tandem

Application

: Changes

VoiceXML

SIP Proprietary Log Format


Data Acquisition


DNIS/URL

Legacy Inbound Flow

SwitchPSTN

Switch

CDRs

Tandem

Application

: Changes

VoiceXML

SIP

DNIS/URL



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.

Legacy Inbound Flow

SwitchPSTN

Switch

CDRs

Tandem

Application

: Changes

VoiceXML

SIP


DNIS/URL

Legacy Inbound Flow

SwitchPSTN

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.


VoiceXML sends a REFER to the Switch

on a blind transfer.

SIP Phase 1 Inbound Call Flow

SwitchPSTN

VoiceXML

Switch

DNIS/URL

CDRs

Tandem

Application

SIP Invite with URL

Legacy Inbound Flow

SwitchPSTN

VoiceXML

Switch

Logs

DNISDNIS

CDRs

Tandem

Application

: BEFORE

SIP Inbound Flow

SwitchPSTN

VoiceXML

Switch

DNIS/URL

CDRs

Tandem

Application

SIP Invite with URL

: AFTER


SwitchPSTN

Switch

Logs

CDRs

Service

Tandem

Internet

CPA

Application

HTTP

API




Data Acquisition

Proprietary DSP and Network Interface CardsExcess Resources:

Switch already has DSPs

: ChangesSwitch to VoiceXML

gateway is now SIP

VoiceXML


SwitchPSTN

Switch

CDRs

Service

Tandem

Internet

CPA

Application

HTTP

API



Data Acquisition

: Changes

VoiceXML

Switch is now writing CDRs directly, so no VoiceXML logs are

needed.


SwitchPSTN

Switch

CDRs

Service

Tandem

Internet

CPA

Application

HTTP

API

: Changes

VoiceXML


Data Acquisition for CPA data

SwitchPSTN

VoiceXML

Switch

CDRs

Service

Tandem

Internet

Application

HTTP

SIP

Data Acquisition for CPA data

Vendor API to kick off callSwitch 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

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

SwitchPSTN

VoiceXML

Switch

CDRs

Service

Tandem

Internet

Application

HTTP

SIP Invite with URL & CPA

Call ID exposed to Application


SwitchPSTN

Switch

Logs

CDRs

Service

Tandem

Internet

CPA

Application

HTTP

API

: BEFORE

VoiceXML

SIP Outbound Flow

SwitchPSTN

VoiceXML

Switch

CDRs

Service

Tandem

Internet

Application

HTTP

SIP Invite with URL & CPA

Call ID exposed to Application

: AFTER

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]

mailto:[email protected]

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

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

Documents

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