OpenSig ‘99 1 8/20/2014 Programming IP Telephony Services with the Call Processing Language (CPL) and CGI Jonathan Rosenberg Bell Laboratories October 15, 1999

OpenSig ‘99 2 8/20/2014 Services, services, services! IP telephony cost benefits to consumer declining Must be differentiators –higher quality? –ease of use - UI –new services and features Key is new services –integration services , web, presence, IM, chat part of telephony –control services allow parameters to be defined by consumer –presentation services new look and feel for old friends

OpenSig ‘99 3 8/20/2014 Web Integration I IWR - Interactive Web Response –user calls a number –web page “answers” –use hyperlinks instead of keypresses to navigate much easier than voice –final link makes phone call –VXML for non-PC access SIP Accept headers for MIME negotiations! INVITE redirection Web Page IWR Service

OpenSig ‘99 4 8/20/2014 Web Integration II Web Agents –A calls B –B is not home –After N rings, A gets web page instead possibly dynamically created for caller –Web page lists alternate contact information and times –cell phone after 5pm – for non-urgent stuff URL for recording voic mailto URL for sending

OpenSig ‘99 5 8/20/2014 Web Integration III Shared Web Talking –“web” another form of media stream - like audio and video –Users can talk and simultaneously browse web Show each other pages Discuss stocks Read the paper Web Caller ID –When A calls B, B’s homepage appears in A’s browser –“homepage” dynamically generated for B perhaps

OpenSig ‘99 6 8/20/ not good for interactive communications Great for notification related services! –Type of information unbounded Notification possibilities –call information call attempts –subscriber information monthly bill –Messaging s contain URLs to streaming media controls

OpenSig ‘99 7 8/20/2014 Presence ICQ concept –“buddy lists” and subscriptions –know who is online –normally for instant messages Big idea: Users can subscribe to each other, and learn: –when they pick up and hang up the phone –when they are available to talk or not –when they are in the office or not chair sensor! –when the cell-phone is on or not Presence propagates information about a users willingness, ability, and desire to communicate using a variety of mediums

OpenSig ‘99 8 8/20/2014 Example Presence Service Phone status subscription –A subscribes to B’s phone –When B’s phone state changes hook state willingness to talk –Notification sent to A , instant message, presence notification –A can then call B unsubscribe to B SUBSCRIBE hangup NOTIFY Presence server

OpenSig ‘99 9 8/20/2014 Challenge - Service Programmability Where do services live? What controls do the programs have? When can the program execute controls? What information are the programs provided? What resources do the programs have access to? Who can create the programs? How are the programs instantiated?

OpenSig ‘ /20/2014 Session Initiation Protocol Invite user to sessions Basic signaling and session description (SDP) Allows to search for the user to be invited –Mobility –Redirect/proxy –Multicast SIP Client SIP Redirect Server SIP Proxy SIP Client (User Agent Server) Location Service Request Response

OpenSig ‘ /20/2014 Location of logic SIP User Agents –trust issues –heterogeneity of platforms –always on problem SIP servers –natural place for routing, screening, pre- call services External devices to SIP servers –SCP/SSP model in IN safety, load balancing, good for third parties latency issues in IP –what replaces INAP? DIAMETER? COPS? MGCP+? SIP (same syntax, wrong semantics)

OpenSig ‘ /20/2014 Nature of Control High Level –“forward”, “reject”, “redirect” –common to all SP Medium Level –controlled device abstracted to a model –call models in IN –control = goto state N Lowest level –full control - send message X Not a single answer! –Fundamental tradeoffs: simplicity vs. flexibility safety vs. flexibility

OpenSig ‘ /20/2014 Nature of Information Highest level –“new call from Joe to Bob” –can be SP independent Medium level –state machine transitions + basic data (caller, callee, etc.) Lowest level –Full messages Same tradeoffs...

OpenSig ‘ /20/2014 Who can write them? Creator determines tradeoff operating point Three principals –Administrator –Third party provider –End user Lines can be blurry Real operating point depends largely on trust

OpenSig ‘ /20/2014 Other issues Access to resources –What else can program do besides control –General purpose program - anything –Java script - lots, but not everything –configuration script - very limited How does it get there? –Linked in (API model) server must be taken down, recompiled not clean –separate process (CGI) –data read in (servlet model)

OpenSig ‘ /20/2014 Solution I:SIP CGI Benefits of CGI as a basis –programming language independence –full control over headers/messages –leverage existing tools –SIP similar to HTTP What’s different from HTTP CGI –persistence model –multiple actions per script output –response naming –request naming

OpenSig ‘ /20/2014 Persistence Model Transaction more complex than request-response –proxying –provisional responses Many points during transaction where script might execute “points” = message arrivals Script reinvoked on message arrivals State maintained by cookie –opaque to server –passed from script to server and back on reinvocation Reinvocation points controllable (triggers)

OpenSig ‘ /20/2014 Multiple Actions Many actions possible –new request –proxy request –create response –return response –default Each action looks like a message in script output –parser reuse Multiplex actions using SIP message multiplexing rules

OpenSig ‘ /20/2014 Response Naming Wish to return a response received during previous invocation Server names responses Tell server to return named response –script need not store message

OpenSig ‘ /20/2014 Request Naming Multiple requests proxied (forking) When response comes, script wants to match response to request Can use branch-id, but complex Solution: request-token Passed back to script when response comes Not same as response token: multiple responses per request a b c 2 a b c

OpenSig ‘ /20/2014 Message Merging When script outputs response or proxied request –server computes default resp/request –header fields are merged with script output Merging –header in script replaces header in message –header in script with no value deletes header in message Simplifies life –Script ignores Via’s, MaxForwards, etc.

OpenSig ‘ /20/2014 Example Output INVITE SIP/2.0 To: From: Call-ID: 10 Cseq: 0 INVITE Content-Length: 0 PROXY_REQUEST_TO SIP/2.0 Max-Forwards: SIP/ Ringing User CGI_SCRIPT_COOKIE aoi988ans0naa SIP/2.0

OpenSig ‘ /20/2014 Status Draft 1 submitted to IETF Dec98, draft 2 May 21, 1999 No wg to do it –likely we will submit as informational Two known implementations

OpenSig ‘ /20/2014 Solution II: CPL Call Processing Language –targeted for end user service creation –controls at high level –information available at high level –Describes basic service Model: SIB’s from IN –service = DAG –Two types of nodes action nodes: outputs = results decision nodes: ouputs = possible values –Safety –Bounds on compute time

OpenSig ‘ /20/2014 Example DAG String Switch field = “From” Proxy to Proxy to voic Proxy to otherwise No answer Busy No answer Call

OpenSig ‘ /20/2014 Representation Use XML –links = subtags –parameters = attributes –extensibility mechanisms useful –easy transport –generation/parsing by tools GUI for creation <location link=“vm”>

OpenSig ‘ /20/2014 Conclusion Services key Programmability serious problem Two solutions proposed: –SIP CGI –CPL