An Application Component Architecture for SIP Jonathan Rosenberg Chief Scientist.

An Application Component Architecture for SIP

Jonathan RosenbergChief Scientist

www.dynamicsoft.comSIP 2001 2.23.01APIs for Next-Generation Service Creation

Building Complex Applications is Hard Auto-Conference Application

Procedure Enter email addresses into a

web form (1) Application subscribes to users (2) Notifications come as users come and

go When all online, application sends

each an IM For PSTN only users, it calls them

and asks if now is OK Users indicate if now is OK

Web click for PC users Say “yes” for phone users

If now is good with everyone, the users are dropped into a conference call (3,4)

PresenceHTTPSIP Calls

Application Server

Conference Server

Presence Server

1

2

4

3


Why is this hard? Many components

Call control Conferencing IVR Messaging Web Instant Messaging Presence Database

Different expertise domains for each component

Varying end device capabilities Web enabled Voice enabled Small display

Web Setup

Presence of Participants

Ask if its OK (IM, IVR)

Authorize Service

Accept/Reject (Web, IVR)

Conference call


Big Idea I: Components are Coarse Grained Coarse Grained Components

Concrete start and stop Internal details not important Application dependent outputs

Acceptance of conference call start

Web form with email/phones of participants

Authorization success/failure

Some components are UI

Define inputs/outputs independent of how component works UI Independence!!

Web Setup

Presence of Participants

Ask if its OK

Authorize Service

Accept/Reject

Conference call

addresses

Yes/no

available

OK/No


Big Idea II: Isolate the Essence of the Application Essence of the application

Sequence of components Input/Output of each component

Isolate this into a coordinator Application starts here Invokes components as needed Provides input to components Receives outputs of components

Benefits Easy to completely change UI –

just invoke different component Easy to break application into

pieces Each piece handles

interaction with a component Servlets!

Web Setup

ParticipantPresence

IM if OK?

Authorize

Web Yes/No

Conference call

addresses

Yes/no

available

OK/No

Coordinator


Big Idea III: Model Components as Resources Transactional Resources

Short duration No prior establishment Discrete data in, discrete operation,

discrete data out DB Authorization

Session Resources Long duration Must be established and torn down Continuous interaction May have side channel for getting back

“results” of interaction IVR, Conference servers

Resources are identified by URIs

HTTP for transactional resources

SIP for session resources

C S

C S


Big Idea IV: Third Party Control Problem

Session Resources have a continuous interaction between entities

Session resources accessed by controller

But controller is not the entity in the continuous interaction!

Solution: Third Party Call Control Controller initiates session SDP in initiation is that of the

device that needs to interact with the resource

Allows controller to have any component continuously interact with any other!

C S

INVI

TE


Putting it All Together Components themselves can be

controllers! Same interface between client

and controller and controller and components

Result: an application component hierarchy

Controllers use 3pcc to connect session resources to clients or other components

HTTP critical for data input and output to components

Controller

MediaServer

Conf.Server

Conf.Server

MediaServer

HTTPSIP


Its Decomposition! What about MGCP/megaco?

Alternate model Master Slave

Differences Tight vendor and provider coupling

Can’t say no MS/Conf. Server USELESS

by themselves No longer modular

AS knows nitty details of all component functions

Limited to voice and black phones that do DTMF

Application and UI tightly integrated

Difficult to reuse components Significantly more messaging!

AS

MediaServer

Conf.Server

Conf.Server

MediaServer

Softswitch MGCP


Media Server Component Media Server provides a dialog

with an entity

How can we specify the dialog? VoiceXML!!!

What is it? XML based dialog language, Voice equivalent of HTML Dialog modeled as filling a form Form results HTTP POSTed Response to HTTP POST is next

VoiceXML to run

<?xml version="1.0"?><vxml version="1.0"><form><field name="drink"><prompt>Would you like coffee, tea, milk, or nothing?</prompt><grammar src="drink.gram" type="application/x-jsgf"/></field><block><submit next="http://www.drink.example/drink2.asp"/></block></form></vxml>


SIP, VoiceXML and HTTP – the Eternal Golden Braid Controller INVITEs MS w/ SDP

of user to interact with MS

R-URI contains HTTP URL for VoiceXML script

HTTP URL fetched back from AS Provides initial VoiceXML script to

start dialog

Voice form is filled out

MS sends HTTP POST back to AS with result of form Same as if form filled out by web

browser

AS returns next VoiceXML script

AS sends BYE when doneAS MS

INVITE/200/ACK

HTTP GET

VoiceXML Doc

VoiceXML Doc

HTTP POST

BYE/200

RTP


Conferencing Server Component Conference server provides a

generic mixing service

How do we know which devices to mix? Mixer is represented as a

resource with a URI All calls to same URI are mixed Mixer context exists as long as

calls are active for that URI

More complex applications built by placing logic on the controller

INV/200/ACK sip:a

INV/200/ACK sip:a

BYE/200

BYE/200

Contextcreated

Contextdestroyed

X Y Conf. Srvr

X/-

Y/X

X/Y


Auto-Conference Once More Web form with users POSTED

to controller

PresenceHTTPIMSIP Call

Application Server

Conference Server

Presence Server

Media Server

Controller initiates SUBSCRIBE session with presence server

On NOTIFYs update presence

When all online

Send IM to some with HTTP URL for accept

Use 3pcc to connect others to MS

HTTP POST of each accept/reject

Use 3pcc to connect each to same conference URL

MS fetches VoiceXML from AS

Information Resource Jonathan RosenbergChief Scientist+1 973.952.5060 [email protected]

draft-rosenberg-sip-app-components-00.txt

mailto:[email protected]

mailto:[email protected]

An Application Component Architecture for SIP Jonathan Rosenberg Chief Scientist.

Documents

Transcript of An Application Component Architecture for SIP Jonathan Rosenberg Chief Scientist.