Service Mobility Henning Schulzrinne with Stefan Berger Jonathan

Service Mobility Henning Schulzrinne (with Stefan Berger, Jonathan Lennox, Xiaotao Wu) Columbia University SIP 2003 – January 2003 Paris, France

Overview n n Mobility – more than cell phones Components of service mobility n n n Location-based services n n 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 n Terminal mobility n n n User mobility n n n move on-going session to new terminal(s) Service mobility n n multiple users, same identifier SIP registration with multiple Contact’s Session mobility n n multiple network attachment points, same identifier IP mobility or SIP registration & re-INVITE keep same services when moving Mobile services n create services on device itself

Session mobility n Walk into office, switch from cell phone to desk phone n n call transfer problem REFER related problem: split session across end devices n n n e. g. , wall display + desk phone + PC for collaborative application assume devices (or stand -ins) are SIP-enabled third-party call control

Session mobility via 3 PCC INVITE speakerphone m=audio c=pc 42 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=pc 42 192. 0. 2. 7

How to find services? n Two complementary developments: n n smaller devices carried on user instead of stationary devices that can be time-shared n n n Need to discover services in local environment n SLP (Service Location Protocol) allows querying for services n n 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 n n “is there a camera in the meeting room? ” SLP extension: find remote DA via DNS SRV

Service mobility n Same services, independent of device and network used n n n user address book speed dial entries SIP configuration network preferences (carrier) call handling already handled by CPL, sip-cgi, servlets, … in home server n n In mobile networks, provided by n need remote update capability SIP PUBLISH GSM SIM (difficult to move to different devices) HLR in domain Need small, portable token for identification n temporary device may not be completely trustworthy n n e. g. , airport payphone one-time passwords (OTP) used as key into database (challenge-response) protocol unclear SIP? LDAP?

Service mobility n Modes: n synchronization n n central database n n good if intermittent connectivity Sync-ML? XPath-based system under development works only if permanently connected SIP configuration: n n get notified if global or device configuration changes (e. g. , security update, new end system services) retrieval via HTTP or similar, not SIP n n partial or full updates related to Internet media guide problem

Locations n Geographic location n n Civil location (≠ postal location!) n n n street address, city some countries are a bit difficult… Categorical n n latitude, longitude, altitude, velocity, heading office, library, theater, hospital, … Behavioral n n “public location, don't expect privacy” “silence is encouraged, don't ring the phone”

Determining locations n n SIP entities are often far away from physical user or his current network (intentionally) For many devices, can’t afford hardware to determine location n different precision requirements: n n n GPS doesn’t work indoors, but Assisted GPS (A-GPS) may Use location beacons: Blue. Tooth, 802. 11 n n n may not offer network connectivity see our 7 DS project: offer local content + location Physically close by network entities: n n n “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 n Proposal: DHCP extensions for geographic and civil location n n geographic: resolution (bits), long/lat, altitude (meters or floors) civil: n n n Also, some LAN switches broadcast port and switch identification n n 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 n locally implemented for emergency services (Perl sip-cgi script)

Location-based services n Services: n Location-aware call routing n n n Location-based events n n n “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 delivery@pizza. com 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 n Location information is highly sensitive n n n complete tracking of person stalkers and burglars would kill for this information IETF GEOPRIV principle: “target” can control dissemination of location information n n 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 n n otherwise, need to give access key to database to recipient we propose adding SIP Location header field

<? xml version="1. 0" ? > <!DOCTYPE cpl PUBLIC "@ECHO OFF //IETF//DTD RFCxxxx CPL 1. 0//EN" IF "cpl. dtd"> %SIP_FROM%==sip: wxt@cs. columbia. edu <cpl> GOTO BLOCK <incoming> GOTO EXIT <address-switch field="origin" subfield="user"> : BLOCK <address is="anonymous"> echo SIP/2. 0 486 <reject status="reject" Busy reason="I don't accept anonymous calls" /> public boolean do. Invite(Sip. Request req) { : EXIT Sip. Response res</address> = req. create. Response(); </address-switch> res. set. Status(486); </incoming> res. send(); </cpl> SIP service interfaces n n n CPL SIP CGI SIP Servlet } return true;

#! /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 Waitnn"; if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ "sip: hgs@") { print "SIP/2. 0 486 Don't disturb, I am workingnn"; } else { print "SIP/2. 0 302 Redirectn"; print "Contact: sip: xiaotaow@voicemail. cs. columbia. edunn"; }

End system services n Techniques for network services are not good for end system services: n n n different service creators end system requirements Currently available: n n XML-based screen interaction (Cisco) Java applets (Pingtel, 3 G phones)

Network Services v. s. End System Services

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 n n n 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) n XML based language n n n Defined as an XML schema n n 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 n n n n <esml name="online_call" require="generic presence ui"> <notification status="online" priority="0. 5"> <address-switch field="origin"> <address is="xyz@foo. com"> <call /> <alert sound=“foo. au" text="Calling xyz@foo. com" /> </address-switch> </notifying> </esml>

ESML packages SIP user agent im email web Presence presence agent calendar conference SIP Basic user agent Generic Media UI x 10 vcr Device agent

Extend ‘general’ to ‘sip’ n n n n <xs: schema target. Namespace="esml: sip" xmlns: sip="esml: sip" xmlns: generic="esml: generic". . <xs: complex. Type name="Incoming. Type"> <xs: complex. Content> <xs: extension base="generic: Incoming. Type"> <xs: attribute name="priority" type="Priority. Type"/>. . </xs: extension> </xs: complex. Content> </xs: complex. Type>

ESML Service Creation

Conclusion n All SIP devices are mobile n n integrate devices in environment n n easier than trying to carry around fewer security issues needs service discovery service mobility n n but mobility is more than a cell phone remote configuration & synchronization mobile services via end system service creation