Programming IP Telephony Services with the Call Processing Language (CPL) and CGI

1
Programming IP Telephony Serviceswith the Call
Processing Language (CPL)and CGI

• Jonathan Rosenberg
• Bell Laboratories
• October 15, 1999

2
Services, services, services!

• 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

• IP telephony cost benefits to consumer declining
• Must be differentiators
• higher quality?
• ease of use - UI
• new services and features

3
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
INVITE
redirection
Web Page
IWR Service
4
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
• email for non-urgent stuff
• URL for recording voicemail
• mailto URL for sending email

5
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, Bs homepage appears in As
  browser
• homepage dynamically generated for B perhaps

6
Email

• Notification possibilities
• call information
• call attempts
• subscriber information
• monthly bill
• Messaging
• emails contain URLs to streaming media controls

• E-mail not good for interactive communications
• Great for notification related services!
• Type of information unbounded

7
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
8
Example Presence Service

• Phone status subscription
• A subscribes to Bs phone
• When Bs 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

Presence server
hangup
SUBSCRIBE
NOTIFY
9
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?

10
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

11
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)

12
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

13
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...

14
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

15
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)

16
Solution ISIP CGI

• Benefits of CGI as a basis
• programming language independence
• full control over headers/messages
• leverage existing tools
• SIP similar to HTTP

• Whats different from HTTP CGI
• persistence model
• multiple actions per script output
• response naming
• request naming

17
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)

18
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

19
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

1
2
2
3
20
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
a
b
2
b
c
c
21
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 Vias, MaxForwards, etc.

22
Example Output
INVITE sipjdrosen_at_bell-labs.com SIP/2.0 To
sipjdrosen_at_bell-labs.com From
sipmachine_at_bell-labs.com Call-ID 10 Cseq 0
INVITE Content-Length 0 PROXY_REQUEST_TO
siphgs_at_cs.columbia.edu SIP/2.0 Max-Forwards SIP
/2.0 180 Ringing User CGI_SCRIPT_COOKIE
aoi988ans0naa SIP/2.0
23
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

24
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 SIBs from IN
• service DAG
• Two types of nodes
• action nodes outputs results
• decision nodes ouputs possible values
• Safety
• Bounds on compute time

25
Example DAG
Call
26
Representation
ltcallgt ltstring-switch fieldfromgt ltstring
isboss_at_company.comgt ltlocation
urlsipjoe_at_att.comgt ltproxygt ltbusygt
ltlocation urltel5551212gt ltproxygt
ltbusygt ltlocation urlsipvoicemail_at_
att.com linkvmgt
ltproxy/gt lt/locationgt lt/busygt
ltnoanswergt ltlink idvm/gt
lt/noanswergt lt/proxygt lt/locationgt
lt/busygt ltnoanswergt ltlink idvm/gt
lt/noanswergt lt/proxygt lt/locationgt
lt/stringgt ltotherwisegt ltlink idvm/gt
lt/otherwisegt lt/string-switchgt lt/callgt

• Use XML
• links subtags
• parameters attributes
• extensibility mechanisms useful
• easy transport
• generation/parsing by tools
• GUI for creation

27
Conclusion

• Services key
• Programmability serious problem
• Two solutions proposed
• SIP CGI
• CPL