An Application Component Architecture for SIP Jonathan Rosenberg Chief Scientist

SIP APIs for Next-Generation Service Creation Building Complex Applications is Hard Auto-Conference Application Procedure Enter 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) Presence HTTP SIP Calls Application Server Conference Server Presence Server

SIP APIs for Next-Generation Service Creation 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

SIP APIs for Next-Generation Service Creation 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 /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

SIP APIs for Next-Generation Service Creation 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 Participant Presence IM if OK? Authorize Web Yes/No Conference call addresses Yes/no available OK/No Coordinator

SIP APIs for Next-Generation Service Creation 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 CS CS

SIP APIs for Next-Generation Service Creation 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! CS INVITE

SIP APIs for Next-Generation Service Creation 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 Media Server Conf. Server Conf. Server Media Server HTTP SIP

SIP APIs for Next-Generation Service Creation Its 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! AS Media Server Conf. Server Conf. Server Media Server Softswitch MGCP

SIP APIs for Next-Generation Service Creation 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 Would you like coffee, tea, milk, or nothing?

SIP APIs for Next-Generation Service Creation 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 done AS MS INVITE/200/ACK HTTP GET VoiceXML Doc HTTP POST BYE/200 RTP

SIP APIs for Next-Generation Service Creation 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 BYE/200 Context created Context destroyed XY Conf. Srvr X/- Y/X X/Y

SIP APIs for Next-Generation Service Creation Auto-Conference Once More Web form with users POSTED to controller Presence HTTP IM SIP 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 Rosenberg Chief Scientist draft-rosenberg-sip-app-components-00.txt