Programming IP Telephony
Services
with the Call Processing Language (CPL)
and CGI
Jonathan Rosenberg
Bell Laboratories
October 15, 1999
OpenSig ‘99
1
7/15/2016
Services, services, services!
• IP telephony cost
benefits to consumer
declining
• Must be differentiators
– higher quality?
– ease of use - UI
– new services and
features
OpenSig ‘99
2
7/15/2016
• 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
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!
OpenSig ‘99
3
7/15/2016
INVITE
INVITE
redirection
Web Page
IWR Service
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
OpenSig ‘99
4
7/15/2016
– 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 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
OpenSig ‘99
5
7/15/2016
• Web Caller ID
– When A calls B, B’s
homepage appears in
A’s browser
– “homepage”
dynamically generated
for B perhaps
Email
• E-mail not good for
interactive
communications
• Great for notification
related services!
– Type of information
unbounded
OpenSig ‘99
6
7/15/2016
• Notification possibilities
– call information
• call attempts
– subscriber information
• monthly bill
– Messaging
• emails contain URLs to
streaming media controls
Presence
• ICQ concept
– “buddy lists” and
subscriptions
– know who is online
– normally for instant
messages
• Big idea:
Presence propagates information about
a users willingness, ability, and desire to
communicate using a variety of mediums
OpenSig ‘99
7
7/15/2016
• 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
Example Presence Service
• Phone status subscription
Presence
server
– 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
OpenSig •
‘99 unsubscribe to B
8
7/15/2016
hangup
SUBSCRIBE
NOTIFY
Challenge - Service Programmability
• Where do services
live?
• What controls do the
programs have?
• When can the program
execute controls?
OpenSig ‘99
9
7/15/2016
• What information are the
programs provided?
• What resources do the
programs have access to?
• Who can create the
programs?
• How are the programs
instantiated?
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
OpenSig ‘99
10
7/15/2016
Request
Response
SIP Redirect
Server
Location Service
2
3
5
4
1
12
6
11
7
10
SIP Proxy
SIP Proxy
8
9
SIP Client
SIP Client
(User Agent
Server)
Location of logic
• SIP User Agents
– trust issues
– heterogeneity of
platforms
– always on problem
• SIP servers
– natural place for
routing, screening, precall services
OpenSig ‘99
11
7/15/2016
• 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)
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
OpenSig ‘99
12
7/15/2016
• Lowest level
– full control - send
message X
• Not a single answer!
– Fundamental tradeoffs:
• simplicity vs. flexibility
• safety vs. flexibility
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.)
OpenSig ‘99
13
7/15/2016
• Lowest level
– Full messages
• Same tradeoffs...
Who can write them?
• Creator determines
tradeoff operating
point
• Three principals
– Administrator
– Third party provider
– End user
OpenSig ‘99
14
7/15/2016
• Lines can be blurry
• Real operating point
depends largely on
trust
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
OpenSig ‘99
15
7/15/2016
• 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)
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
OpenSig ‘99
16
7/15/2016
• What’s different from
HTTP CGI
– persistence model
– multiple actions per
script output
– response naming
– request naming
Persistence Model
• Transaction more complex
than request-response
– proxying
– provisional responses
• Many points during
transaction where script
might execute
• “points” = message
arrivals
OpenSig ‘99
17
7/15/2016
• 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)
Multiple Actions
• Many actions possible
–
–
–
–
–
new request
proxy request
create response
return response
default
OpenSig ‘99
18
7/15/2016
• Each action looks like
a message in script
output
– parser reuse
• Multiplex actions
using SIP message
multiplexing rules
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 ‘99
19
7/15/2016
1
2
2
3
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
OpenSig ‘99
20
7/15/2016
a
a
b
2
b
c
c
Message Merging
• When script outputs
response or proxied
request
– server computes default
resp/request
– header fields are
merged with script
output
OpenSig ‘99
21
7/15/2016
• 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.
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
OpenSig ‘99
22
7/15/2016
Status
• Draft 1 submitted to
IETF Dec98, draft 2
May 21, 1999
• No wg to do it
– likely we will submit as
informational
OpenSig ‘99
23
7/15/2016
• Two known
implementations
Solution II: CPL
• Call Processing
Language
– targeted for end user
service creation
– controls at high level
– information available at
high level
– Describes basic service
OpenSig ‘99
24
7/15/2016
• 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
Example DAG
Busy
Proxy to
joe@att.com
Call
String Switch
field = “From”
otherwise
Proxy to
voicemail
OpenSig ‘99
25
7/15/2016
Proxy to
555-1212
<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>
OpenSig ‘99
26
7/15/2016
Representation
• Use XML
– links = subtags
– parameters = attributes
– extensibility
mechanisms useful
– easy transport
– generation/parsing by
tools
• GUI for creation
Conclusion
• Services key
• Programmability
serious problem
• Two solutions
proposed:
– SIP CGI
– CPL
OpenSig ‘99
27
7/15/2016