Title: An Application Component Architecture
1An Application Component Architecture for SIP
Jonathan Rosenberg Chief Scientist
2Building 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)
Conference Server
4
Application Server
2
Presence Server
1
3
3Why 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
Authorize Service
Presence of Participants
Ask if its OK (IM, IVR)
Accept/Reject (Web, IVR)
Conference call
4Big 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
addresses
Authorize Service
Yes/no
Presence of Participants
available
Ask if its OK
Accept/Reject
OK/No
Conference call
5Big 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
addresses
Authorize
Yes/no
Participant Presence
available
Coordinator
IM if OK?
Web Yes/No
OK/No
Conference call
6Big 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
7Big 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!
INVITE
C
S
8Putting 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
Media Server
Conf. Server
Conf. Server
Media Server
HTTP
SIP
9Its Decomposition!
- What about MGCP/megaco?
- Alternate model
- Master Slave
- Differences
- Tight vendor and provider coupling
- Cant 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!
Media Server
Conf. Server
Softswitch
MGCP
AS
Media Server
Conf. Server
10Media 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
lt?xml version"1.0"?gtltvxml version"1.0"gtltformgt
ltfield name"drink"gtltpromptgtWould you like
coffee, tea, milk, or nothing?lt/promptgtltgrammar
src"drink.gram" type"application/x-jsgf"/gtlt/fie
ldgtltblockgtltsubmit next"http//www.drink.example
/drink2.asp"/gtlt/blockgtlt/formgtlt/vxmlgt
11SIP, 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 done
INVITE/200/ACK
RTP
HTTP GET
VoiceXML Doc
HTTP POST
VoiceXML Doc
BYE/200
AS
MS
12Conferencing 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 sipa
Context created
X/-
INV/200/ACK sipa
Y/X
X/Y
BYE/200
BYE/200
Context destroyed
X
Y
Conf. Srvr
13Auto-Conference Once More
Media Server
- Web form with users POSTED to controller
Conference Server
- Controller initiates SUBSCRIBE session with
presence server
- On NOTIFYs update presence
Application Server
Presence Server
- When all online
- Send IM to some with HTTP URL for accept
- Use 3pcc to connect others to MS
- MS fetches VoiceXML from AS
- HTTP POST of each accept/reject
Presence HTTP IM SIP Call
- Use 3pcc to connect each to same conference URL
14Information Resource
- Jonathan Rosenberg
- Chief Scientist
- 1 973.952.5060
- jdrosen_at_dynamicsoft.com
draft-rosenberg-sip-app-components-00.txt