1 / 26

Service Mobility

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 configuration and synchronization discovery

Download Presentation

Service Mobility

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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; }

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

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

  17. Network Services v.s. End System Services

  18. Network Services v.s. End System Services

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

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

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

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

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

  24. ESML Service Creation

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

More Related