ubiquitous programmable internet telephony services
Post on 05-Jan-2016
38 Views
Preview:
DESCRIPTION
TRANSCRIPT
Ubiquitous Programmable Ubiquitous Programmable Internet Telephony Internet Telephony ServicesServices
Xiaotao WuInternet Real Time Laboratory
Thesis defense
2
OverviewOverview
Where to put services Services
Ubiquitous – SIP-based ubiquitous computing
Programmable – CPL, LESS and FI handling Rich – existing services and new services Smart – Feature learning
Implementations Other works
3
Where to put services Services
Ubiquitous Programmable Rich Smart
Implementations Other works
4
Services can be everywhereServices can be everywhere
End devices
End users’ server
User agents in the network
Proxy server
B2BUA
5
Where to put servicesWhere to put servicesEnd devices
End servers
Net UAs Proxy B2BUA
Number of users
Single Single/trusted users
Multiple Multiple Multiple
Call/dialog states
Yes Yes Yes No Yes
Media Yes Yes/no Yes No Yes/no
Number of entities
Single Multiple Single Multiple Multiple
Direct interaction
Yes No/yes No No No
Admin. End user End user Admin. Admin. Admin.
Store services in the network, though they may get executed in end systemsKeep the peer-to-peer architecture, avoid the master/slave architecture
6
Peer-to-peer v.s. Peer-to-peer v.s. master/slavemaster/slave
Pickup call
D1 D2
D3
C
D1 D2
D3
C
notificationtriggeredINVITE
MGC
MGCPMegaco
7
Where to put services Services
Ubiquitous Programmable Rich Smart
Implementations Other works
8
-- Mark Weiser
Ubiquitous computing using Ubiquitous computing using SIPSIP
What is ubiquitous computing Enhance computer use by making many computers
available throughout the physical environment, but making them effectively invisible to the user.
where are we
what’s available
how to controlautomate the control
Front deskService location server
room 123
what’s availablein room 123?
video displaymicrophonevideo camera
Bob I am in room 123
Bob can usedevices in 123
use the devicesin room 123 totalk to Tom
Tom
send mediato Tom
NOSSDAV03IEEE Communications
9
System ArchitectureSystem Architecture
LocationSensing
ResourceDiscovery
ResourceControl
CallControl
GPS
BlueTooth
DHCP
Wireless triangulation
NOTIFY
PUBLISH
REGISTER
REGISTER
SIP Home domainRegistrar and AAA serverLocation
Server
Local domainSIP server
SLP DA
INVITE
SLP SA
SLP query
result
10
Room confLocation agent
Bob
RFID readeriButtonreader
ProxyLS
Bob is in conf
NOTIFYLocation
You areIn conf
SLP DA
SLP SA
Device GWSLinke
X10
Turn onconf’s light
Turn on light
What’savailable
sip:conf_pingtelfor audio
sip:conf
Tracking
Triggeran action
Resourcediscovery
IEEE CCNC’05
Location-basedLocation-basedServices in our Services in our lablab
11
Location-basedLocation-basedServices in our Services in our lablab
Location agent
Bob
RFID readeriButtonreader
ProxyLS
Bob is in conf
NOTIFYLocation
You areIn conf
SLP DA
SLP SA
Device GWSLinke
X10
Turn onconf’s light
Turn on light
What’savailable
sip:conf_pingtelfor audio
sip:conf
INVITE sip:anyone_roomconf
Guard communicatio
n behavior
‘Talk’ to alocation
Room conf
IEEE CCNC’05
12
Location in Emergency Services
Emergency Call Center
Call Flow Prototype Architecture
SIP Proxy
SIP Proxy
Internet
ALI ServerDHCP Server
DNS Server
911112
sip:sos@domainw/location or w/out location
geo location
POTS/Wireless Network
IP Network
911
IP Gateway
sip:sos@domainwithout location
Envinsa Server
sip:psap@domainwith location
location
GeoLynx Display
DHCP InformMAC Address
Location Info
TCP Socket Telephone Number
PSAP Info
HTTP SOAPgeo location
verifiedcivil
location
civil location**
PSAP Info
DNS Querycivil location
IEEE ICCCN’05
13
Program location-based Program location-based servicesservices<incoming> <LOC:where-switch type="civil"> <LOC:where country="USA" A1="New York" A3="New York" A6="West 120th" HNO="450" LOC="Room 563"> <location url="sip:bob-office@example.com"> <redirect/> </location> </LOC:where> <otherwise> <location url="sip:bob-mobile@example.com"> <redirect/> </location> </otherwise> </LOC:where-switch></incoming>
14
Where to put services Services
Ubiquitous Programmable Rich Smart
Implementations Other works
15
Easy service creationEasy service creation
Using a tree-like structure to represent communication services
Natural thinking of call decision making – a rule set
For an incoming call, if I am in a conference, I will reject all the calls that are not from my boss.
A decision tree to represent a rule set
CPL and LESS
For an incoming call
If I am in a conference
Vibratemy device
Rejectthe call
YES
YES
NO
If the call is from my boss
16
Timer Timer triggered triggered outgoing calloutgoing call
<?xml version="1.0" encoding="UTF-8"?><less xmlns="urn:ietf:params:xml:ns:less“ xmlns:IM="urn:ietf:params:xml:ns:less:im“ xmlns:xsi=“…" xsi:schemaLocation=“…"> <timer dtstart="20050307T110000Z"> <status-switch uri="sip:bob@example.com" status-name="presence"> <status is="open"> <location url="sip:bob@example.com"> <call> <busy> <location url="sip:bob@example.com"> <IM:sendmsg> Hi, please call me back. I am in office </IM:sendmsg> </location>…………….
17
CPL and LESSCPL and LESS CPL: Call Processing Language LESS: Language for End System Services Simple
Four kinds of elements: trigger, switch, action, modifier Tree-like structure, easy for feature interaction analysis
Safe Type safety: XML-based, no user defined variables Control flow safety: tree-like structure without back-reference No direct memory access Default behavior for every tree branch
Portability Handle user interactions and media operations Beyond call control
presence, IM, Web, location
IEEE ICC’03RFC3880
18
LESS elementsLESS elementstrigger an incoming call
switch
check the caller
switchcheck time
switch
check priority
action
redirect
action
accept
action
reject
modifier
to Bob
= ≠
= ≠ ≠
19
LESS elementsLESS elements
20
LESS elementsLESS elements
Triggers incoming: incoming call handling outgoing: user invoked outgoing call timer: timer triggered actions UI:command: user interaction commands IM:message: incoming instant messaging Event:subscription: incoming subscription Event:notification: incoming notification
21
LESS elements (cont.)LESS elements (cont.) Switches
time-switch: make decisions based on time address-switch: make decisions based on caller, callee
priority-switch: make decisions based on call priority string-switch: make decisions based on subject, … language-switch: make decisions based on languages status-switch: make decisions based on users’ status (remote user or local user, status includes presence, activity, mood, …, as listed in RPID)
Event:event-switch: check values in event notifications
LOC:where-switch: check users’ physical location information (remote or local user)
LOC:where-relation-switch: check relative physical locations between two people
22
LESS elements (Cont.)LESS elements (Cont.) Actions
accept: accept an incoming call reject: reject an incoming call redirect: redirect an incoming
call authenticate: authenticate an
incoming request call: make an outgoing call terminate: disconnect a call wait: wait for a certain time
before next action mail: send email log: log request handling process Media:mediaupdate: update
media attributes Midcall:transfer: transfer a call
Midcall:merge: merge multiple calls UI:alert: alert user UI:getinput: get user input IM:sendmsg: send an instant message Event:approve: approve subscription Event:deny: deny event subscription Event:defer: defer the decision on
event subscription Event:subscribe: send subscription
out Event:notify: send notification out Queue:enqueue: put a call and its
context into a queue Queue:dequeue: get a call and its
context from a queue
23
LESS elements (Cont.)LESS elements (Cont.) Two smaller concepts might be simpler
and more flexible than one more powerful but complicated concept
Modifiers location: to which a request to be directed lookup: lookup locations from a source remove-location: remove locations from
location set Media:media: provide media attributes
24
Automatic Call Back (ACB)Automatic Call Back (ACB)<less xmlns="urn:ietf:params:xml:ns:less“ xmlns:Event="urn:ietf:params:xml:ns:less:event“ xmlns:Queue="urn:ietf:params:xml:ns:less:queue“ xmlns:xsi=“….“ xsi:schemaLocation=“……"><incoming> <status-switch status-name=“activity”> <status is=“on-the-phone"> <reject reason=“busy”> <next> <Queue:enqueue queue="callback"/> </next> </reject> </status> </status-switch></incoming>
In ITU Q.1211
“This feature allows the called party to automatically call back the calling party of the last call directed to the called party.”
Check my activity for an incoming call
Use Event and Queue extension
If I am on-the-phoneReject and enqueue
25
<Event:notification> <address-switch field="origin"> <address uri="{agent.uri}"> <Event:event-switch> <Event:event package=“presence" name=“activity" is=“normal"> <Queue:dequeue queue="callback"> <Queue:success> <call/> </Queue:success> </Queue:dequeue> </Event:event> </Event:event-switch> </address> </address-switch> </Event:notification></less>
A event notification for myself
I am available
Dequeue and make a call
Automatic Call Back (ACB) Automatic Call Back (ACB) (cont.)(cont.)
26
27
<?xml version="1.0"?><less> <incoming> <address-switch field="origin"> <address is="sip:hgs@cs.columbia.edu"> <accept/> </address> <otherwise> <location url="sip:foo@example.com"> <redirect/> </location> </otherwise> </address-switch> </incoming></less>
28
29
LESS script customizationLESS script customization
xsl:if
LESS editor
service.less(template)
XSLT
less.xsl
configurationeditor
service.html
translate.cgi
service_foo.less
address is=$var
30
Open issuesOpen issues Can we use LESS for B2BUA?
‘lookup’ from database coordinate multiple sessions multi-user feature interaction handling
Loop and user-defined variables needed? Based on our exercises, no But, what about unknown new services? Convert loop to a high-level abstraction? What’s the impact on feature interaction
handling
31
accept
accept
EasyEasy feature interaction analysis feature interaction analysis
Tree merging
+ =If time is between
10:00AM and 11:00AMIf address is hgs
Forward to conf
Incoming call Incoming call
Incoming call
If time is between 10:00AM and 11:00AM
If address is hgs
rejectForward to conf
rejectaccept
Take actions from both scripts. Simply setting precedence rules cannot work.ICFI’05 (FIW)
32
Easy feature interaction Easy feature interaction analysisanalysis
FI handling between multiple CPL/LESS scripts Action conflict tables Tree merging algorithm Multi-component feature interactions
e.g., parallel forking with all end systems automatically accept an incoming call
34
Pre-condition and expected Pre-condition and expected resultsresults
pre-condition expected results
accept The call setup is pending. The audio device is available.
The call setup is finalize. The communication session is setup. The audio device is occupied.
reject The call setup is pending. The call setup is finalized.
redirect
The call setup is pending. The call setup is finalized on the current end system.
call The audio device is available. If the callee side accepts the call, a communication session is setup and audio device is occupied.
35
Action conflict tableAction conflict tableaccept reject redirec
tcall
accept A(media) C C R
reject C A(reason) C -
redirect
C C A(target) -
call R - - A(target)
-: no interaction, A: attribute conflict, C: action conflict,E: enabling, R: resource competition
36
Tree mergingTree merging
set base-rule-set emptyforeach LESS-tree { convert the LESS-tree into a rule set foreach rule in the rule set { normalize the rule } merge the normalized rule set into base-
rule-set}convert base-rule-set into a decision tree
37
Tree merging (cont.)Tree merging (cont.)if (two rules have different triggers) { no rule conflict except timer trigger} else if actions in two rules do not conflict { no rule conflict} else if no overlap between rule path in two rules { no rule conflict} else { two rules conflict with each other, return the rule path overlap and action conflict
information prompt to the script owner to judge}
38
Where to put services Services
Ubiquitous Programmable Rich Smart
Implementations Other works
39
Rich signaling informationRich signaling information
Rich signaling information SIP headers Caller preference and callee capabilities MIME contents Event notification Other means
Web calendar, Directory services
40
Rich servicesRich services Be able to handle services in PSTN networks
ITU Q.1211 ABD, ACB, CFC, CHA, QUE, CRG, OCS, …
Services in 5ESS switches Attendant camp-on, Automatic recall, …
Services in CSTA Phase III defined as signaling actions in LESS, e.g., mediaupdate
Emergency provide location information
New services Interact with existing Internet services
web, email, SLP, SAP, IM, presence, location, networked appliance control, directory service, calendar service, conferencing
Not named services, but programmable services Programmable conferencing services
41
Where to put services Services
Ubiquitous Programmable Rich Smart
Implementations Other works
42
DefinitionDefinition
What is service learning Automatically generate user desired
services Help users, not bypass users Services on both proxy servers and end
systems What is service risk management
Risk caused by automation How to reduce the overall risks
IEEE ICC’05
43
MotivationMotivation Causal relationship between call information
and call decisions SIP headers Other Internet services
Learning burden caused by new services Not named services, but programmable services What and how
Examples Spam filtering, calendar-based services
Service risks Lose connectivity, lose privacy, …
44
DesignDesign
Using decision tree induction for learning In CPL/LESS terms: find switches that
can best partition actions What algorithm
Incremental Prune Quality measurement
30*3+10*2+7=117 30*2+3*2+10*3+4*3=108
45
Incremental Tree InductionIncremental Tree Induction Incremental
Incorporating Transposition
Virtual prune Direct metrics
Expected number of tests Leaf counts Minimum description length Expected misclassication cost
address=a1
time=t1 time=t1
B DCA
Y N
Y N Y N
time=t1
address=a1 address=a1
A DCB
Y N
Y N Y N
46
Simulation
40 servicesEach for 300 calls80% match10% different way10% mismatch
47
PerformancePerformance
Fast vs. incremental (20 samples) training
IBM ThinkPad, Linux 1GHz PIII Mobile256MB memory
48
PerformancePerformance
20 vs. 250 incremental samples
IBM ThinkPad, Linux 1GHz PIII Mobile256MB memory
49
IntegrationIntegration Gather information
Transaction history Calendar Location sensing Idle time Communication activities Timestamp
Alert users Service risk management
50
Service risk managementService risk management Identify
Lose connection: reject, redirect, transfer, accept on wrong branch Lose privacy: accept, call, notify Lose money: accept, transfer to higher rate endpoint Lose attention: alert, accept, appliance control
Analyze Possibility: number of occurrence in the decision tree, switch
attributes Impact: (connection, privacy) > money > attention, customizable Overall risk: avoiding high impact risks, though may cause low
impact risks Resolve
Change communication methods Transfer Reduce overall risk
Contingency plan Backup
51
Where to put services Services
Ubiquitous Programmable Rich Smart
Implementations Other works
52
ImplementationsImplementations
53
54
Function overviewFunction overview
SIPMultimediacall control
Real time streaming
Location sensing
Network appliance control
Floorcontrol
SIP for presence
SAPInstantmessage
SIP CGI engine
LESS/CPLengine
Third party call control
Emergency handling
Service LocationDetection (SLP)
audio
video
whiteboard
desktopsharing
locationsensors
Email clients
RTP: RFC 1889SDP: RFC 2327RTSP: RFC 2326
SIP Event Arch.: RFC 3265 RFC3903
SAP: RFC 2974SIP: RFC 3261
SLP: RFC 2608
CPL, SIP 3PCC,SIP Device ControlGEOPRIV location format, SIP for IM
Web browsers
MMNS’04
55
Call
SIP
SDPRTP
Session broadcasting SAP
RTSP
SIP eventnotification
Locationsensing
Emergency handling
Location tracking
Device controlir/x10
MapLynx
Messagewaitingindication
Voicemailhandling
Presencenotification
Conferencingfloor control
Servicedetection
SLP
Instantmessaging
xcon
Function reuseFunction reuse
56
SDP
SAP
RTP
RTP
RTP
RTSP
SIP
SIP
SIP
location
SLP3pccSIP DO
SLPSIP
NOTIFY
MESSAGE
DO
SIP
location
location
Function interactionFunction interaction
57
Other workOther work
Building Box project (AT&T Labs Research)
Conferencing floor control Networked appliance control Shared web browsing Joined some other projects (CINEMA,
SIP 911, session mobility, project for FAA, …)
58
ConclusionConclusion
Services are more distributed in Internet telephony. We need techniques specifically for end system service creation
LESS is designed for end system services Easy to build SCE Easy to analyze Enable feature learning
Different information and different functions converged at end systems and will introduce many new services, e.g., location-based services.
59
Some linksSome links SIPc: http://www.cs.columbia.edu/IRT/sipc CINEMA: http://www.cs.columbia.edu/IRT/cinema LESS: http://www.ietf.org/internet-drafts/draft-wu-iptel-less-00.txt Ubiquitous Computing: http://www1.cs.columbia.edu/~xiaotaow/
rer/Research/Paper/ieeecomm_inhome.pdf Service examples:
http://www.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-048-04.pdf
Feature interaction handling: http://www.cs.columbia.edu/ ~
xiaotaow/rer/Research/Paper/fiw.pdf Service learning: http://www.cs.columbia.edu/~xiaotaow/rer
/Research/Paper/icc2005.pdf
60
AcknowledgementsAcknowledgements
Dr. Henning Schulzrinne SIPQuest Colleagues in IRT lab Colleagues in AT&T Labs Research
Thank you!
top related