Enhancing Service Mobility: Challenges and Solutions in SIP Systems

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

2. Overview • Mobility – more than cell phones • Components of service mobility • configuration and synchronization • discovery • Location-based services • determining locations for SIP systems • call routing and presence services • End system service creation • Work in progress within Columbia IRT lab

3. Mobility modes • Terminal mobility • multiple network attachment points, same identifier • IP mobility or SIP registration & re-INVITE • User mobility • multiple users, same identifier •  SIP registration with multiple Contact’s • Session mobility • move on-going session to new terminal(s) • Service mobility • keep same services when moving • Mobile services • create services on device itself

4. 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 SIP-enabled • third-party call control

5. 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

6. How to find services? • Two complementary developments: • smaller devices carried on user instead of stationary devices • devices that can be time-shared • large plasma displays • projector • hi-res cameras • echo-canceling speaker systems • wide-area network access • Need to discover services in local environment • SLP (Service Location Protocol) allows querying for services • “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

7. 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 • need remote update capability  SIP PUBLISH • In mobile networks, provided by • 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?

8. Service mobility • Modes: • synchronization • good if intermittent connectivity • Sync-ML? • XPath-based system under development • central database • 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

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

10. 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: • “in Fayette County” (within driving distance of service or person) • “on campus” • “in room 815” • “in corner, talking to Bob” • 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: • DHCP (same broadcast domain) • PPP (tail circuit) • Not always true with VPNs, but end system knows that it’s using a VPN

11. DHCP for locations • Proposal: DHCP extensions for geographic and civil location • geographic: resolution (bits), long/lat, altitude (meters or floors) • civil: • what: end system, switch or DHCP server • hierarchical subdivisions, from country to street, landmark name, occupant • Also, some LAN switches broadcast port and switch identification • CDP for Cisco, EDP for Extreme Networks • Can also use backtracking via SNMP switch tables • locally implemented for emergency services (Perl sip-cgi script)

12. Location-based services • Services: • Location-aware call routing • “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” • Location-based events • 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

13. 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

14. SIP service interfaces <?xml version="1.0" ?> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <cpl> <incoming> <address-switch field="origin" subfield="user"> <address is="anonymous"> <reject status="reject" reason="I don't accept anonymous calls" /> </address> </address-switch> </incoming> </cpl> @ECHO OFF IF %SIP_FROM%==sip:wxt@cs.columbia.edu GOTO BLOCK GOTO EXIT :BLOCK echo SIP/2.0 486 Busy :EXIT • CPL • SIP CGI • SIP Servlet public boolean doInvite(SipRequest req) { SipResponse res = req.createResponse(); res.setStatus(486); res.send(); return true; }

16. #! /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"; }

17. 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)

18. Network Services v.s. End System Services

19. Network Services v.s. End System Services

20. End system service languages • Simple and easy to understand by non-programmers • 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

21. Endpoint Service Markup Language (ESML) • XML based language • Platform and underlying programming language neutral • Readable by non-programmers • Defined as an XML schema • Derivation of new types • Pre-defined types • Tree-like structure • Use packages to group events and actions

22. ESML example • <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> • </address-switch> • </notifying> • </esml>

23. SIP user agent SIP Device agent Presence agent Basic user agent presence Generic Media UI x10 vcr ESML packages im email web calendar conference

24. 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>

25. ESML Service Creation

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