close

Вход

Забыли?

вход по аккаунту

?

Programming IP Telephony Services with the Call Processing

код для вставкиСкачать
Programming IP Telephony
Services
with the Call Processing Language (CPL)
and CGI
Jonathan Rosenberg
Bell Laboratories
October 15, 1999
OpenSig �99
1
9/23/2014
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
9/23/2014
• 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
9/23/2014
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
9/23/2014
– 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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
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
9/23/2014
• 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
9/23/2014
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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
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
9/23/2014
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
9/23/2014
• 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
9/23/2014
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
9/23/2014
• 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
9/23/2014
• 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
9/23/2014
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
9/23/2014
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
9/23/2014
Документ
Категория
Презентации
Просмотров
16
Размер файла
240 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа