Transcript SIP2003-ServiceMobility

Service Mobility
Henning Schulzrinne
(with Stefan Berger, Jonathan Lennox, Xiaotao Wu)
Columbia University
SIP 2003 – January 2003
Paris, France
Overview


Mobility – more than cell phones
Components of service mobility



Location-based services




configuration and synchronization
discovery
determining locations for SIP systems
call routing and presence services
End system service creation
Work in progress within Columbia IRT lab
Mobility modes

Terminal mobility



User mobility



move on-going session to new terminal(s)
Service mobility


multiple users, same identifier
 SIP registration with multiple Contact’s
Session mobility


multiple network attachment points, same identifier
IP mobility or SIP registration & re-INVITE
keep same services when moving
Mobile services

create services on device itself
Session mobility

Walk into office, switch
from cell phone to desk
phone


call transfer problem 
REFER
related problem: split
session across end
devices



e.g., wall display + desk
phone + PC for
collaborative application
assume devices (or
stand-ins) are SIPenabled
third-party call control
Session mobility via 3PCC
INVITE speakerphone
m=audio
c=pc42
192.0.2.1
INVITE display
m=video
c=192.0.2.7
m=audio
c=192.0.2.1
INVITE display
m=video
c=pc42
192.0.2.7
How to find services?

Two complementary developments:


smaller devices carried on user instead of stationary devices
devices that can be time-shared






Need to discover services in local environment

SLP (Service Location Protocol) allows querying for services




large plasma displays
projector
hi-res cameras
echo-canceling speaker systems
wide-area network access
“find all color displays with at least XGA resolution”
SLP in multicast mode
SLP in DA mode
Need to discover services before getting to environment


“is there a camera in the meeting room?”
SLP extension: find remote DA via DNS SRV
Service mobility

Same services, independent of device and network used





user address book
speed dial entries
SIP configuration
network preferences (carrier)
call handling  already handled by CPL, sip-cgi, servlets, … in home server


In mobile networks, provided by



need remote update capability  SIP PUBLISH
GSM SIM (difficult to move to different devices)
HLR in domain domain
Need small, portable token for identification

temporary device may not be completely trustworthy




e.g., airport payphone
one-time passwords (OTP)
used as key into database (challenge-response)
protocol unclear  SIP? LDAP?
Service mobility

Modes:

synchronization




central database


good if intermittent connectivity
Sync-ML?
XPath-based system under development
works only if permanently connected
SIP configuration:


get notified if global or device configuration changes (e.g.,
security update, new end system services)
retrieval via HTTP or similar, not SIP


partial or full updates
related to Internet media guide problem
Locations

Geographic location


Civil location (≠ postal location!)



street address, city
some countries are a bit difficult…
Categorical


latitude, longitude, altitude, velocity, heading
office, library, theater, hospital, …
Behavioral


“public location, don't expect privacy”
“silence is encouraged, don't ring the phone”
Determining locations


SIP entities are often far away from physical user or his current
network (intentionally)
For many devices, can’t afford hardware to determine location

different precision requirements:






GPS doesn’t work indoors, but Assisted GPS (A-GPS) may
Use location beacons: BlueTooth, 802.11



may not offer network connectivity
see our 7DS project: offer local content + location
Physically close by network entities:



“in Fayette County” (within driving distance of service or person)
“on campus”
“in room 815”
“in corner, talking to Bob”
DHCP (same broadcast domain)
PPP (tail circuit)
Not always true with VPNs, but end system knows that it’s using a VPN
DHCP for locations

Proposal: DHCP extensions for geographic and civil
location


geographic: resolution (bits), long/lat, altitude (meters or
floors)
civil:



Also, some LAN switches broadcast port and switch
identification


what: end system, switch or DHCP server
hierarchical subdivisions, from country to street, landmark
name, occupant
CDP for Cisco, EDP for Extreme Networks
Can also use backtracking via SNMP switch tables

locally implemented for emergency services (Perl sip-cgi
script)
Location-based services

Services:

Location-aware call routing






Location-based events





“do not forward call if time at callee location is [11 pm, 8 am]”
“only forward time-for-lunch if destination is on campus”
“contact nearest emergency call center”
“do not ring phone if I’m in a theater”
“send [email protected] to nearest branch”
subscribe to locations, not people
“Alice has entered the meeting room”
subscriber may be device in room  our lab stereo changes
CDs for each person that enters the room
Person + location events
We’re implementing SIP, caller-preferences and CPL
extensions for these services
SIP extensions for location-based
services

Location information is highly sensitive



complete tracking of person
stalkers and burglars would kill for this information
IETF GEOPRIV principle: “target” can control dissemination of
location information




restrict time of day, information (location, heading, velocity)
resolution, number of times queried, destination, retention, …
“Alice is in time zone MET” may be ok for strangers, but “Alice is at
41.872833 N, 087.624417 W, heading NE at 45 mph” is not
GEOPRIV still defining application scenarios
in many cases, easiest to include location information “in-band”
with protocol, as this avoids delegating authorization


otherwise, need to give access key to database to recipient
we propose adding SIP Location header field
SIP service interfaces



<?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL
1.0//EN" "cpl.dtd">
CPL
SIP CGI
<cpl>
<incoming>
SIP Servlet
<address-switch field="origin" subfield="user">
@ECHO OFF
<address is="anonymous">
IF %SIP_FROM%==sip:[email protected]
GOTO BLOCK
<reject status="reject"
public
boolean
doInvite(SipRequest
req) { calls" />
GOTO EXIT
reason="I don't accept anonymous
SipResponse
res = req.createResponse();
</address>
:BLOCK res.setStatus(486);
</address-switch>
echo SIP/2.0 486
Busy
</incoming>
res.send();
</cpl>
:EXIT
return true;
}
CPL
Scripts
#! /usr/bin/env perl -w
# Reject messages whose 'From:' matches 'sip:hgs@' by
# responding with 486 Busy, redirect the others to voicemail
print "SIP/2.0 100 Wait\n\n";
if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ "sip:hgs@") {
print "SIP/2.0 486 Don't disturb, I am working\n\n";
} else {
print "SIP/2.0 302 Redirect\n";
print "Contact: sip:xiaotaow\@voicemail.cs.columbia.edu\n\n";
}
End system services

Techniques for network services are not
good for end system services:



different service creators
end system requirements
Currently available:


XML-based screen interaction (Cisco)
Java applets (Pingtel, 3G phones)
Network Services v.s.
End System Services
Call
Call
Connection
Connection
Address1
Address2
a. Network service call model
Address
app1
app2
app3
b. End system service call model
Network Services v.s.
End System Services
Network
services
Developer
experienced
developers
Media and other indirect
end system
control via
applications
SDP
User interaction indirect
End system
services
nonprogrammers
direct control
direct
End system service languages






Simple and easy to understand by nonprogrammers
Platform neutral
Express user interactions
Control media and other end system
applications
Extensible to accommodate new services
Restricted to certain class of services, not
necessarily Turing-complete
Endpoint Service Markup
Language (ESML)

XML based language



Defined as an XML schema




Platform and underlying programming language
neutral
Readable by non-programmers
Derivation of new types
Pre-defined types
Tree-like structure
Use packages to group events and actions
ESML example













<esml name="online_call"
require="generic presence ui">
<notification status="online"
priority="0.5">
<address-switch field="origin">
<address is="[email protected]">
<call />
<alert sound=“foo.au"
text="Calling [email protected]" />
</address>
</address-switch>
</notifying>
</esml>
ESML packages
SIP user agent
im
email
web
Presence
presence
agent
calendar conference
SIP
Basic user agent
Generic Media UI
x10
vcr
Device agent
Extend ‘general’ to ‘sip’














<xs:schema targetNamespace="esml:sip"
xmlns:sip="esml:sip"
xmlns:generic="esml:generic"
..........
<xs:complexType name="IncomingType">
<xs:complexContent>
<xs:extension
base="generic:IncomingType">
<xs:attribute name="priority"
type="PriorityType"/>
..........
</xs:extension>
</xs:complexContent>
</xs:complexType>
ESML Service Creation
ESML editor
XML editor
esml.xsl
service.esml
(template)
XSLT
service.html
user
translate.cgi
service_foo.esml
ESML
designer
Configuration
editor
Conclusion

All SIP devices are mobile


integrate devices in environment




easier than trying to carry around
fewer security issues
needs service discovery
service mobility


but mobility is more than a cell phone
remote configuration & synchronization
mobile services via end system service
creation