270 likes | 289 Views
Explore the benefits and incorporation of CPL in IP telephony services for enhanced quality, ease of use through UI, and integration with email, web, presence, and chat. Learn about Interactive Web Response (IWR), web integration with SIP, and the concept of Presence to optimize communication experiences.
E N D
Programming IP Telephony Serviceswith the Call Processing Language (CPL)and CGI Jonathan Rosenberg Bell Laboratories October 15, 1999
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 email, 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 Services, services, services!
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! Web Integration I INVITE INVITE redirection Web Page IWR Service
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 email for non-urgent stuff URL for recording voicemail mailto URL for sending email Web Integration II
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 Web Integration III
E-mail 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 emails contain URLs to streaming media controls Email
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 Presence propagates information about a users willingness, ability, and desire to communicate using a variety of mediums
Phone status subscription A subscribes to B’s phone When B’s phone state changes hook state willingness to talk Notification sent to A email, instant message, presence notification A can then call B unsubscribe to B Example Presence Service Presence server hangup SUBSCRIBE NOTIFY
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? Challenge - Service Programmability
Request SIP Redirect Server Response Location Service 2 3 5 4 6 1 7 11 12 10 SIP Proxy SIP Proxy 8 9 SIP Client SIP Client (User Agent Server) 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 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) Location of logic
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 Nature of Control
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... Nature of Information
Creator determines tradeoff operating point Three principals Administrator Third party provider End user Lines can be blurry Real operating point depends largely on trust Who can write them?
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) Other issues
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 Solution I:SIP CGI
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) Persistence Model
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 Multiple Actions
Wish to return a response received during previous invocation Server names responses Tell server to return named response script need not store message Response Naming 1 2 2 3
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 Request Naming a a b 2 b c c
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. Message Merging
Example Output INVITE sip:jdrosen@bell-labs.com SIP/2.0 To: sip:jdrosen@bell-labs.com From: sip:machine@bell-labs.com Call-ID: 10 Cseq: 0 INVITE Content-Length: 0 PROXY_REQUEST_TO sip:hgs@cs.columbia.edu SIP/2.0 Max-Forwards: SIP/2.0 180 Ringing User CGI_SCRIPT_COOKIE aoi988ans0naa SIP/2.0
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 Status
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 Solution II: CPL
Busy Proxy to 555-1212 Proxy to joe@att.com Boss@company.com No answer Busy String Switch field = “From” No answer otherwise Proxy to voicemail Example DAG Call
Use XML links = subtags parameters = attributes extensibility mechanisms useful easy transport generation/parsing by tools GUI for creation <call> <string-switch field=“from”> <string is=“boss@company.com”> <location url=“sip:joe@att.com”> <proxy> <busy> <location url=“tel:5551212”> <proxy> <busy> <location url=“sip:voicemail@att.com” link=“vm”> <proxy/> </location> </busy> <noanswer> <link id=“vm”/> </noanswer> </proxy> </location> </busy> <noanswer> <link id=“vm”/> </noanswer> </proxy> </location> </string> <otherwise> <link id=“vm”/> </otherwise> </string-switch> </call> Representation
Services key Programmability serious problem Two solutions proposed: SIP CGI CPL Conclusion