Скачать презентацию Vo IP — Moving from protocols to architecture s Скачать презентацию Vo IP — Moving from protocols to architecture s

77aa2d16c743eb6b2dcbdb0ee864b08b.ppt

  • Количество слайдов: 105

Vo. IP - Moving from protocols to architecture(s) Henning Schulzrinne Dept. of Computer Science Vo. IP - Moving from protocols to architecture(s) Henning Schulzrinne Dept. of Computer Science Columbia University January 2006 June 2005

Overview n n n The big transitions in Vo. IP An Internet protocol framework Overview n n n The big transitions in Vo. IP An Internet protocol framework Open issues in Vo. IP and interactive multimedia communications n n n service creation Vo. IP: poll model presence model SIP architecture and design philosophy Philosophies: Skype, IETF, NGS, … Reflections on standardization Integration of cellular and IP end systems June 2005 2

Philosophy transition One computer/phone, many users mainframe era home phone party line PC era Philosophy transition One computer/phone, many users mainframe era home phone party line PC era cell phone era One computer/phone, one user Many computers/phones, one user ~ ubiquitous computing anywhere, any time any media June 2005 right place (device), right time, right media 3

Evolution of Vo. IP “how can I make it stop ringing? ” long-distance calling, Evolution of Vo. IP “how can I make it stop ringing? ” long-distance calling, ca. 1930 “amazing – the phone rings” 1996 -2000 June 2005 “does it do call transfer? ” going beyond the black phone catching up with the digital PBX 2000 -2003 20044

Collaboration in transition inter-organization multiple technology generations diverse end points intra-organization; small number of Collaboration in transition inter-organization multiple technology generations diverse end points intra-organization; small number of systems (meeting rooms) standards-based solutions proprietary (singlevendor) systems June 2005 5

Internet services – the missing entry Service/delivery synchronous asynchronous push instant messaging presence event Internet services – the missing entry Service/delivery synchronous asynchronous push instant messaging presence event notification session setup media-on-demand messaging pull data retrieval file download remote procedure call peer-to-peer file sharing June 2005 6

Filling in the protocol gap Service/delivery synchronous asynchronous push SIP RTSP, RTP SMTP pull Filling in the protocol gap Service/delivery synchronous asynchronous push SIP RTSP, RTP SMTP pull HTTP ftp Sun. RPC, Corba, SOAP (not yet standardized) June 2005 7

A constellation of SIP RFCs Non-adjacent (3327) Symmetric resp. (3581) Service route (3608) User A constellation of SIP RFCs Non-adjacent (3327) Symmetric resp. (3581) Service route (3608) User agent caps (3840) Caller prefs (3841) Request routing Resource mgt. (3312) SIP (3261) DNS for SIP (3263) Events (3265) REFER (3515) ISUP (3204) sipfrag (3240) Content types Reliable prov. (3262) INFO (2976) UPDATE (3311) Reason (3326) Mostly PSTN Core Digest AKA (3310) Privacy (3323) P-Asserted (3325) Agreement (3329) Media auth. (3313) AES (3853) Security & privacy June 2005 DHCP (3361) DHCPv 6 (3319) Configuration 8

An eco system, not just a protocol configures XCAP (config) SIMPLE XCON (conferencing) policy An eco system, not just a protocol configures XCAP (config) SIMPLE XCON (conferencing) policy RPID …. initiates SIP RTSP SDP carries provide addresses controls RTP June 2005 carries STUN TURN 9

SIP, SIPPING & SIMPLE – 00 drafts includes draft-ietf-*-00 and draft-personal-*-00 June 2005 10 SIP, SIPPING & SIMPLE – 00 drafts includes draft-ietf-*-00 and draft-personal-*-00 June 2005 10

RFC publication June 2005 11 RFC publication June 2005 11

SIP – a bi-cultural protocol • overlap dialing • DTMF carriage • key systems SIP – a bi-cultural protocol • overlap dialing • DTMF carriage • key systems • notion of lines • per-minute billing • early media • ISUP & BICC interoperation • trusted service providers June 2005 • multimedia • IM and presence • location-based service • user-created services • decentralized operation • everyone equally suspect 12

SIP design objectives n new features and services n not a PSTN replacement n SIP design objectives n new features and services n not a PSTN replacement n n n clients can be smart or dumb (terminal adapter) mobile or stationary hardware or software client multiplicity n n not just SS 7 -over-IP even similar services use different models (e. g. , call transfer) client heterogeneity n n support features not available in PSTN e. g. , presence and IM, session mobility one user – multiple clients – one address multimedia n nothing in SIP assumes a particular media type Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00 June 2005 13

SIP architectural principles (1) n proxies are for routing n do not maintain call SIP architectural principles (1) n proxies are for routing n do not maintain call state n n n availability scalability flexibility extensibility (new methods, services) end point call state and features dialog models, not call models n n does not standardize features endpoint fate sharing n n component-based design n call fails only if endpoints fail building blocks call features = notification and manipulation logical components, not physical n n UA, proxy, registrar, redirect server can be combined into one box Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00 June 2005 14

SIP architectural principles (2) n designed for the (large) Internet n n does not SIP architectural principles (2) n designed for the (large) Internet n n does not assume particular network topology congestion-controlled deals with packet loss uses core Internet services: n n DNS for load balancing DHCP for configuration S/MIME for e 2 e security TLS for channel security n generality over efficiency n n n June 2005 focuses on algorithm efficiency, not constantfactor encoding efficiency “efficiency penalty is temporary, generality is permanent” text encoding extensibility use shim layer for compression where needed allow splitting of functionality for scaling 15

SIP architectural principles (3) n separation of signaling and media n n path followed SIP architectural principles (3) n separation of signaling and media n n path followed by media packets independent of signaling path allows direct routing of latency-sensitive media packets (10 ms matters) n n facilitates mobility n n without constraining service delivery (1 s matters) avoid “hair pinning”, “tromboning” facilitates vertical split between ISP and VSP June 2005 16

SIP design principles (1) n Proxies are method, body and header independent n n SIP design principles (1) n Proxies are method, body and header independent n n Full-state nature of INVITE n does not depend on method n n n except CANCEL, ACK can add new methods without upgrading proxies primarily rely on URI, Via, Route and Record-Route header fields extensions: Accept. Contact and Request. Disposition may use anything to guide routing decision June 2005 n n n each (re)INVITE contains full session state facilitates MIDCOM-style interactions allows session transfer SIP URIs identify resources n can be device instance, service, person n n but cannot tell from URI which (good!) can specify services and service parameters 17

SIP design principles (2) n Extensibility and compatibility n n n can define new SIP design principles (2) n Extensibility and compatibility n n n can define new methods, header fields, body types, parameters supported by OPTIONS, Accept-Language, Allow, Supported, Require, Proxy-Require, Accept. Encoding and Unsupported “asking permission” n n n UTF-8 for freeform text negotiation of languages Explicit intermediaries n n = SIP proxies unlike transparent HTTP proxies or NAT boxes, announce themselves n OPTIONS, dialog establishment n use extension without asking (Proxy)-Require: “please reject if you don’t understand it” n Via, Record-Route only involved if asked by UA or proxy should ask endpoints, rather than just do n e. g. , session policy “use if you like” n n Internationalization “asking forgiveness” n n n allow recipients to safely ignore information must provide fallback! June 2005 18

SIP design principles (3) n Guided proxy routing n n n predetermine a set SIP design principles (3) n Guided proxy routing n n n predetermine a set of downstream proxy resource that must be visited supported by Record. Route, Path, Service. Route Transport protocol independence n n n can use UDP, TCP, SCTP, … only requires packet-based (unreliable) delivery design decision that comes with some regret June 2005 n Protocol reuse n n n n MIME for body transport S/MIME for end-to-end security HTTP header field and semantics HTTP digest authentication URI framework non-SIP URIs (e. g. , tel: ) re-use TLS for channel security use DNS SRV and NAPTR for server failover and reliability 19

SIP division of labor proxy B 2 BUA UA State stateless transactionstateful call stateful SIP division of labor proxy B 2 BUA UA State stateless transactionstateful call stateful Headers inspect insert modify (rarely) inspect insert modify inspect reflect Bodies ignore some inspect insert modify inspect Fork yes separate call legs no Media no maybe yes Services rendezvous call routing call stateful media-related June 2005 20

UMTS Reference Architecture by Kimmo Raatikainen June 2005 21 UMTS Reference Architecture by Kimmo Raatikainen June 2005 21

3 G Architecture (Registration) describes deployment architecture mobility management signaling serving CSCF interrogating proxy 3 G Architecture (Registration) describes deployment architecture mobility management signaling serving CSCF interrogating proxy interrogating home IM domain registration signaling (SIP)_ visited IM domain June 2005 22

Classical IETF interfaces “UNI” host end system UA signaling name mapping L 3 config Classical IETF interfaces “UNI” host end system UA signaling name mapping L 3 config L 3 L 2 June 2005 router proxy server “NNI” SIP DNS DHCP, PPP BGP OSPF IPv 4/IPv 6 Ethernet SONET 23

IETF interface approach n Essentially, only two types of entities n n n No IETF interface approach n Essentially, only two types of entities n n n No functional definitions or assumptions n n n IP-layer interface can change without SIP changing Can replace routing protocol without affecting HTTP Function defined by protocol actions n n SIP UA can be PSTN gateway or cell phone (Mostly) strong separation of layers n n end systems (user agents, hosts, clients, …) network systems (proxies, routers, servers, …) not general behavior (“gateway”) Does not describe functional entities as such n web server + SIP UAC + router June 2005 24

IP “hourglass” email WWW phone. . . SMTP HTTP RTP. . . TCP UDP… IP “hourglass” email WWW phone. . . SMTP HTTP RTP. . . TCP UDP… IP ethernet PPP… CSMA async sonet. . . copper fiber radio. . . June 2005 Steve Deering, IETF Aug. 2001 25

The real Internet hourglass (slightly simplified) p 2 p (port 80) web services HTTP The real Internet hourglass (slightly simplified) p 2 p (port 80) web services HTTP TCP IP Ethernet June 2005 26

Interconnection approaches Property NGN, 3 GPP “Internet” interconnection per service neutral end device control Interconnection approaches Property NGN, 3 GPP “Internet” interconnection per service neutral end device control carrier-controlled user-provided end device type mostly hardware software, maybe hardware state preference call state-full stateless transaction-stateful interconnect arrangement pre-arranged serendipitous interconnect discovery pre-configured DNS billing preference per service usage-based bandwidth-based services fixed-rate or adsupported billing arrangement clearing house sender keeps independent June 2005 27

IETF “ 4 G” (access-neutral) model Check reputation of columbia. edu sip: alice@columbia. edu IETF “ 4 G” (access-neutral) model Check reputation of columbia. edu sip: [email protected] edu sip: [email protected] com TLS columbia. edu example. com Visited network NSIS NTLP for Qo. S 802. 1 x AP DIAMETER server [email protected] net June 2005 28

Session Border Controllers (SBCs) n n Provider border element SIP terms: either B 2 Session Border Controllers (SBCs) n n Provider border element SIP terms: either B 2 BUA or proxies n n Functions differ n n but often ill-defined (may change roles) similar definitional problem as “soft switches” May force convergence of media and signaling path June 2005 29

SBCs: High-level motivations n n n Why application-layer elements in SIP that are not SBCs: High-level motivations n n n Why application-layer elements in SIP that are not quite proxies? SMTP has various MTAs, but they are just MTAs (e. g. , spam filter) Guesses: n media vs. control separation n n good idea in theory, harder in today’s limited-functionality Internet force media through single control point (IP address) n n n rather than from millions of sources see Asterix, Skype proxy model of no content (SDP) inspection or modification too limited CALEA (needs to be invisible) charging for services n June 2005 not an issue for email and web 30

SBC functionality, cont’d n Signaling functionality: n n n n Protocol Conversion H. 323 SBC functionality, cont’d n Signaling functionality: n n n n Protocol Conversion H. 323 SIP Protocol integrity - SIP normalization ENUM – SIP redirect Policy enforcement and access control CDR creation Firewall (dest. port, source) Least-cost routing Certificate handling Caller-ID authorization Signaling encryption S/MIME encapsulation TCP/UDP-TLS bridging Do. S attack mitigation June 2005 n Media functionality: n n n n n Codec conversion SLA enforcement Legal Intercept & CALEA compliance Bandwidth Management Packet marking Qo. S guarantees Packet steering Media encryption Firewall (pinholes) Do. S attack mitigation 31

SBC: Network evolution stand-alone networks (Vonage, Skype) media earlier: email, IM SBC only IP-level SBC: Network evolution stand-alone networks (Vonage, Skype) media earlier: email, IM SBC only IP-level (with filter) June 2005 32

SBC: Concerns n Common concerns: n n n may drop some header fields may SBC: Concerns n Common concerns: n n n may drop some header fields may fail to understand some request methods may modify headers inserted by others may modify session descriptions may inspect session descriptions Not all SBCs do this all the time, but some do some of this sometimes… June 2005 33

SBC: The dangers n May not be present in all instances n n SBCs SBC: The dangers n May not be present in all instances n n SBCs are a box description, not a function description cannot tell where SBC is located n n hard to diagnose failures see HTTP “transparent proxy” experience n n one example: TP thought SIP was HTTP n n hard to address content cryptographically to such box Lack of transparency n Lack of security n Lack of visibility n not all features make it through SBC header support copying content routing loops n Inherent conflict between need for media session inspection and session privacy Session description modification removes accountability Lack of scalability n n needs to handle all media packets often, call stateful n June 2005 rather than stateless or transaction-stateful 34

What’s left to do? n n n Transition from “poll” model to context-based communications What’s left to do? n n n Transition from “poll” model to context-based communications Higher-level service creation in end systems Dealing with NATs n n n The role of intermediaries n n n STUN (and SIP modifications) as first step ICE and BEHAVE WG as longer-term solutions session-border controllers end-to-middle security session policies Conference control Application sharing Security issues (spam, spit --> identity and reputation management) June 2005 35

P 2 P for autonomic computing n Autonomic at the application layer: n n P 2 P for autonomic computing n Autonomic at the application layer: n n Robust against partial network faults Resources grow as user population grows Self-configuring Traditional p 2 p systems n file storage n n n motivation is often legal, not technical, efficiency usually unstructured, optimized for Zipf-like popularity Other p 2 p applications: n Skype demonstrates usefulness for Vo. IP n n n June 2005 identifier lookup NAT traversal: media traversal Open. DHT (and similar) as emerging common infrastructure? Non-DHT systems with smaller scope web hotspot rescue Network management (see our IRTF slides) 36

What is SIP? Why P 2 P-SIP? (1) REGISTER alice@columbia. edu =>128. 59. 194 What is SIP? Why P 2 P-SIP? (1) REGISTER [email protected] edu =>128. 59. 194 (2) INVITE [email protected] edu (3) Contact: 128. 59. 194 columbia. edu Bob’s host Alice’s host 128. 59. 194 Problem in client-server: maintenance, configuration, controlled infrastructure (2) INVITE alice (3) 128. 59. 194 Peer-to-peer network (1) REGISTER Alice 128. 59. 194 No central server, but more lookup latency June 2005 37

How to combine SIP + P 2 P? n SIP-using-P 2 P n n How to combine SIP + P 2 P? n SIP-using-P 2 P n n Replace SIP location service by a P 2 P protocol P 2 P-over-SIP Additionally, implement P 2 P using SIP messaging n SIP-using-P 2 P SIP proxies P 2 P-over-SIP Maintenance P 2 P SIP Lookup P 2 P SIP P 2 P network FIND INSERT INVITE sip: [email protected] 59. 194 INVITE alice REGISTER P 2 P-SIP overlay Alice 128. 59. 19. 194 June 2005 38

Deployment scenarios P P P P 2 P clients Plug and play; May use Deployment scenarios P P P P 2 P clients Plug and play; May use adaptors; Untrusted peers P 2 P proxies Zero-conf server farm; Trusted servers and user identities P 2 P database Global, e. g. , Open. DHT; Clients or proxies can use; Trusted deployed peers (? ) Interoperate among these! June 2005 39

Hybrid architecture n n Cross register, or Locate during call setup n n June Hybrid architecture n n Cross register, or Locate during call setup n n June 2005 DNS, or P 2 P-SIP hierarchy 40

What else can be P 2 P? n n n Rendezvous/signaling (SIP) Configuration storage What else can be P 2 P? n n n Rendezvous/signaling (SIP) Configuration storage Media storage (e. g. , voice mail) Identity assertion (? ) PSTN gateway (? ) NAT/media relay (find best one) Trust models are different for different components! June 2005 41

What is our P 2 P-SIP? n n Unlike server-based SIP architecture Unlike proprietary What is our P 2 P-SIP? n n Unlike server-based SIP architecture Unlike proprietary Skype architecture n n Robust and efficient lookup using DHT Interoperability n n Hybrid architecture n n Lookup in SIP+P 2 P Unlike file-sharing applications n n DHT algorithm uses SIP communication Data storage, caching, delay, reliability Disadvantages n June 2005 Lookup delay and security 42

Implementation: SIPpeer n n Platform: Unix (Linux), C++ Modes: n n n Chord: using Implementation: SIPpeer n n Platform: Unix (Linux), C++ Modes: n n n Chord: using SIP for P 2 P maintenance Open. DHT: using external P 2 P data storage Scenarios: n n P 2 P client, P 2 P proxies Adaptor for existing phones n n June 2005 Cisco, X-lite, Windows Messenger, SIPc Server farm 43

Implementation: SIPpeer User interface (buddy list, etc. ) On reset Signout, transfer On startup Implementation: SIPpeer User interface (buddy list, etc. ) On reset Signout, transfer On startup Leave Discover Peer found/ Detect NAT IM, call User location Find Join DHT (Chord) Multicast REGISTER ICE Signup, Find buddies REGISTER Audio devices REGISTER, INVITE, MESSAGE SIP Codecs RTP/RTCP SIP-over-P 2 P-using-SIP June 2005 44

SIP p 2 p summary and open issues n Advantages n n Out-of-box experience SIP p 2 p summary and open issues n Advantages n n Out-of-box experience Robust n n n catastrophic failure-unlikely Inherently scalable Security issues n n Trust, reputation malicious node, sybil attack SPAM, DDo. S Privacy, anonymity (? ) Other issues Lookup latency, proximity and n P 2 P-SIP n Status http: //www. cs. columbia. edu/IRT/p 2 p-sip vs SIP- 45 June 2005 using-P 2 P more with more nodes http: //www. p 2 psip. org n n

The role of presence n Guess-and-ring n high probability of failure: n n current The role of presence n Guess-and-ring n high probability of failure: n n current solutions: n n n “telephone tag” inappropriate time (call during meeting) inappropriate media (audio in public place) voice mail tedious, doesn’t scale, hard to search and catalogue, no indication of when call might be returned automated call back rarely used, too inflexible most successful calls are now scheduled by email n Presence-based n n n facilitates unscheduled communications provide recipient-specific information only contact in real-time if destination is willing and able appropriately use synchronous vs. asynchronous communication guide media use (text vs. audio) predict availability in the near future (timed presence) Prediction: almost all (professional) communication will be presence-initiated or pre-scheduled June 2005 46

Context-aware communication n context = “the interrelated conditions in which something exists or occurs” Context-aware communication n context = “the interrelated conditions in which something exists or occurs” anything known about the participants in the (potential) communication relationship both at caller and callee time CPL capabilities caller preferences location-based call routing location events activity/availability presence sensor data (mood, bio) privacy issues similar to location data June 2005 47

The role of presence n n n “Is the callee likely to be reachable? The role of presence n n n “Is the callee likely to be reachable? ” user-level presence glue logic for loosely-coupled systems events related to calls: n n n voicemail notification call transfer notification Events are a superset of presence: n n publish, subscribe & notify in SIMPLE, just differ in their n n n unlike other event systems, cross-domain, with security n June 2005 event type and bodies (typically, XML) privacy policies but no content-dependent replication (Siena, Elvin, …) 48

Basic presence n n Role of presence n initially: “can I send an instant Basic presence n n Role of presence n initially: “can I send an instant message and expect a response? ” n now: “should I use voice or IM? is my call going to interrupt a meeting? is the callee awake? ” n note: may not be continuous subscription, but rather ondemand (when trying to reach somebody) Yahoo, MSN, Skype presence services: n on-line & off-line n n n useful in modem days – but many people are (technically) online 24 x 7 thus, need to provide more context + simple status (“not at my desk”) n n June 2005 entered manually rarely correct does not provide enough context for directing interactive communications 49

The role of presence for call routing n Two modes: n watcher uses presence The role of presence for call routing n Two modes: n watcher uses presence information to select suitable contacts n n PUBLISH advisory – caller may not adhere to suggestions and still call when you’re in a meeting user call routing policy informed by presence n n n likely less flexible – machine intelligence “if activities indicate meeting, route to tuple indicating assistant” “try most-recently-active contact first” (seq. forking) PA translate RPID CPL NOTIFY LESS INVITE June 2005 50

GEOPRIV and SIMPLE architectures rule maker DHCP XCAP (rules) publication interface target presentity caller GEOPRIV and SIMPLE architectures rule maker DHCP XCAP (rules) publication interface target presentity caller PUBLISH INVITE June 2005 location server presence agent notification interface location recipient GEOPRIV watcher SIP presence SUBSCRIBE NOTIFY INVITE callee SIP call 51

Presence data architecture presence sources PUBLISH create view (compose) raw presence document XCAP select Presence data architecture presence sources PUBLISH create view (compose) raw presence document XCAP select best source resolve contradictions composition policy (not defined yet) June 2005 privacy filtering depends on watcher XCAP privacy policy draft-ietf-simple-presence-data-model 52

Presence data architecture candidate presence document remove data not of interest watcher June 2005 Presence data architecture candidate presence document remove data not of interest watcher June 2005 watcher filter raw presence document post-processing composition (merging) SUBSCRIBE difference to previous notification NOTIFY final presence document 53

Presence data model person “calendar” “cell” “manual” (presentity) (views) alice@example. com audio, video, text Presence data model person “calendar” “cell” “manual” (presentity) (views) [email protected] com audio, video, text services r [email protected] com video devices June 2005 54

Rich presence n n More information automatically derived from n n n sensors: physical Rich presence n n More information automatically derived from n n n sensors: physical presence, movement electronic activity: calendars Rich information: n multiple contacts per presentity n n n device (cell, PDA, phone, …) service (“audio”) activities, current and planned surroundings (noise, privacy, vehicle, …) contact information composing (typing, recording audio/video IM, …) June 2005 55

Privacy policy relationships common policy geopriv-specific presence-specific RPID June 2005 future CIPID 56 Privacy policy relationships common policy geopriv-specific presence-specific RPID June 2005 future CIPID 56

Privacy rules n Conditions n n n Actions n n identity, sphere time of Privacy rules n Conditions n n n Actions n n identity, sphere time of day current location identity as or + watcher confirmation Transformations n n n User gets maximum of permissions across all matching rules n n privacy-safe composition: removal of a rule can only reduce privileges Extendable to new presence data n n n rich presence biological sensors mood sensors include information reduced accuracy June 2005 57

<actions> <conditions> <transformations> <ruleset> Example rules document <rule id=1> <identity><id>user@example. com</id></identity> <sub-handling>allow</sub-handling> <provide-services> <service-uri-scheme>sip</service-uri-scheme> Example rules document [email protected] com allow sip mailto true true bare June 2005 58

Location-based services n Finding services based on location physical services (stores, restaurants, ATMs, …) Location-based services n Finding services based on location physical services (stores, restaurants, ATMs, …) n electronic services (media I/O, printer, display, …) n not covered here Using location to improve (network) services n communication n n configuration n n devices in room adapt to their current users awareness n n incoming communications changes based on where I am others are (selectively) made aware of my location security n June 2005 proximity grants temporary access to local resources 59

Location-based SIP services n Location-aware inbound routing n n outbound call routing n n Location-based SIP services n Location-aware inbound routing n n outbound call routing 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 do not ring phone if I’m in a theater contact nearest emergency call center send [email protected] com to nearest branch location-based events n subscribe to locations, not people n Alice has entered the meeting room n subscriber may be device in room our lab stereo changes CDs for each person that enters the room June 2005 60

Presence Composition n composition = combines multiple presence or event sources into one view Presence Composition n composition = combines multiple presence or event sources into one view n n n Tries to resolve information conflicts n n n remove information: stale, contradictory, redundant create new information (e. g. , new composite services) update diligence, multiple devices in different places, no sensor data, … Focus on PIDF/RPID, but probably applicable to other event sources Depends on presentity, but not on watcher n i. e. , provides maximum information set for later stages June 2005 61

Sources of presence data n Reported current n n n Reported scheduled n n Sources of presence data n Reported current n n n Reported scheduled n n communication status Measured by sensors n n n from a calendar Measured device information n n added manually a brief time ago assumed correct when entered, but decays location, type of location, activity, … sensors = GPS, acceleration sensors, PIRs, . . . Derived n from other presence data June 2005 62

Composition steps discard closed + old source union with replacement n n resolve ambiguities Composition steps discard closed + old source union with replacement n n resolve ambiguities combine identical contacts Working on policy language that describes desired composition policy Complicated policies will require “real” languages June 2005 63

Service creation n Tailor a shared infrastructure to individual users traditionally, only vendors (and Service creation n Tailor a shared infrastructure to individual users traditionally, only vendors (and sometimes carriers) learn from web models programmer, carrier end user network servers SIP servlets, sip-cgi CPL end system Voice. XML (voice), LESS June 2005 64

Automating media interaction – service examples n n n If call from my boss, Automating media interaction – service examples n n n If call from my boss, turn off the stereo call handling with device control As soon as Tom is online, call him call handling with presence information Vibrate instead of ring when I am in movie theatre call handling with location information At 9: 00 AM on 09/01/2005, find the multicast session titled “ABC keynote” and invite all the group members to watch call handling with session information When incoming call is rejected, send email to the callee call handling with email June 2005 65

LESS: simplicity n n Generality (few and simple concepts) Uniformity (few and simple rules) LESS: simplicity n n Generality (few and simple concepts) Uniformity (few and simple rules) n n n Trigger rule Switch rule Action rule Modifier rule modifiers trigger switches actions Familiarity (easy for user to understand) Analyzability (simple to analyze) June 2005 66

LESS: Decision tree §No loops §Limited variables §Not necessarily Turing-complete June 2005 67 LESS: Decision tree §No loops §Limited variables §Not necessarily Turing-complete June 2005 67

LESS: Safety n Type safety n n n Control flow safety n n n LESS: Safety n Type safety n n n Control flow safety n n n No direct memory access LESS engine safety n n No loop and recursion One trigger appear only once, no feature interaction for a defined script Memory access n n Strong typing in XML schema Static type checking Ensure safe resource usage Easy safety checking n Any valid LESS scripts can be converted into graphical representation of decision trees. June 2005 68

LESS snapshot incoming call <less> If the call from my boss <incoming> <address-switch> <address LESS snapshot incoming call If the call from my boss

Turn off the stereo Accept the call with only audio trigger, switch, modifier, action June 2005 69

LESS packages Use packages to group elements n SIP user agent im email web LESS packages Use packages to group elements n SIP user agent im email web Presence presence agent Event calendar conference session June 2005 location SIP Basic user agent Generic Media UI x 10 vcr Device agent 70

When Tom is online, …

……… June 2005 71

When I am in a movie theatre, … <less> <incoming> <location-switch> <location placetype=“quiet”> <alert When I am in a movie theatre, … June 2005 72

XCON System Logical XCON Server TEMPLATE Of the SYSTEM: TEMPLATE Policy: • Of TYPE XCON System Logical XCON Server TEMPLATE Of the SYSTEM: TEMPLATE Policy: • Of TYPE RULES • Pre-configured • Initial/Default values RESERVATION Policy: Of the INSTANCE: • Of TYPE RULES • Of TYPE CONFERENCE-INFO STATE Of the CURRENT INSTANCE: CURRENT Policy: • Of TYPE RULES CPCP Server CPCP Client Logical June 2005 • Of TYPE CONFERENCE-INFO CCCP Server CCCP Client XCON Client Focus SIP/ PSTN/ H. 323 T. 120/ Etc. Call Signaling Client Conf Event Notification Server SIP NOTIFY/ Etc. Notification Client Floor Control Server BFCP Floor Control Client 74

Conference control n n n IETF XCON WG struggling with model and complexity Web Conference control n n n IETF XCON WG struggling with model and complexity Web services? Specialized (binary) protocol? API or document modification? Inheritance model – blue prints and templates June 2005 75

Open issues: application sharing n Current: T. 120 n n Current: web-based sharing n Open issues: application sharing n Current: T. 120 n n Current: web-based sharing n n doesn’t integrate well with other conference control mechanisms hard to make work across platforms (fonts) ill-defined security mechanisms hard to integrate with other media, control and record generally only works for Windows mostly limited to shared Power. Point Current: vnc n n whole-screen sharing only can be coerced into conferencing, but doesn’t integrate well with control protocols June 2005 76

IETF effort: standardized application sharing n n Remote access = application sharing Four components: IETF effort: standardized application sharing n n Remote access = application sharing Four components: n n n window drawing ops PNG keyboard input mouse input window operations (raise, lower, move) Uses RTP as transport n n n synchronization with continuous media but typically, TCP allow multicast large group sessions June 2005 77

Spam and spit June 2005 78 Spam and spit June 2005 78

SIP unsolicited calls and messages n Possibly at least as large a problem n SIP unsolicited calls and messages n Possibly at least as large a problem n n n more annoying (ring, pop-up) Bayesian content filtering unlikely to work identity-based filtering PKI for every user unrealistic Use two-stage authentication n mutual PK authentication (TLS) home. com Digest SIP identity work June 2005 79

Domain Classification of domains based on their identity instantiation and maintenance procedures plus other Domain Classification of domains based on their identity instantiation and maintenance procedures plus other domain policies. n Admission controlled domains n Strict identity instantiation with long term relationships n n Bonded domains n n Membership possible only through posting of bonds tied to a expected behavior Membership domains n No personal verification of new members but verifiable identification required such as a valid credit card and/or payment n n Example: E-bay, phone and data carriers Open domains n No limit or background check on identity creation and usage n n Example: Employees, students, bank customers Example: Hotmail Open, rate limited domains n Open but limits the number of messages per time unit and prevents account creation by bots n June 2005 Example: Yahoo 80

Reputation service Carol has sent IM to David has sent email to Emily Frank Reputation service Carol has sent IM to David has sent email to Emily Frank is this a spammer? Alice June 2005 Bob 81

SIP standards & deployment issues and competition n n Interoperability Proprietary systems June 2005 SIP standards & deployment issues and competition n n Interoperability Proprietary systems June 2005 82

Provider combinations Skype software ISP IAP June 2005 Cisco CM cable DSL op hardware Provider combinations Skype software ISP IAP June 2005 Cisco CM cable DSL op hardware mobile operators? VSP 83

Protocol interoperability problems n Three core interoperability problems: n syntactic robustness n “You mean Protocol interoperability problems n Three core interoperability problems: n syntactic robustness n “You mean you could have a space there? ” n n n implementation by protocol example limiting assumptions (e. g. , user name format) see “SIP Robustness Testing for Large-Scale Use”, First International Workshop on Software Quality (SOQA) semantic assumptions n n often occurs when testing only against common reference implementations need “stress test” (also for buffer overflows) “I didn’t expect this error” mutually incompatible extensions n June 2005 expect extension to make something work 84

Protocol interoperability: proprietary protocols n Proprietary protocol n n n Example: Skype quicker evolution Protocol interoperability: proprietary protocols n Proprietary protocol n n n Example: Skype quicker evolution – not dependent on IETF “volunteers” with day jobs can do “hacks” without IESG objection: n n n Can only reverse-engineer only backwardscompatibility problems n n media over TCP inefficient search bypass routing policies circumvent firewall policies incentive to force upgrades (see Microsoft Word) less Metcalfe’s law value June 2005 85

Why is Skype successful? n n n All the advantages of a proprietary protocol Why is Skype successful? n n n All the advantages of a proprietary protocol Peer-to-peer coincidental Good out-of-box experience n n Didn’t know that you couldn’t do voice quality beyond PSTN n n others too focused on PSTN interoperability – why do better voice than PSTN? Simpler solutions for NAT traversal n n Software vendor = service provider use TCP if necessary use port 80 Did encryption from the very beginning Kazaa marketing vehicle June 2005 86

Skype vs. SIP-based systems Skype SIP-based providers Protocol proprietary, encrypted SIP to gateways open Skype vs. SIP-based systems Skype SIP-based providers Protocol proprietary, encrypted SIP to gateways open (SIP), often plain-text sometimes IAX to gateway Business model prepaid outbound PSTN calls (Skype. Out) monthly fee (Vonage) free (FWD) prepaid (SIPgate. de) Protocol model single “network”, bridge to PSTN some closed some semi-open (*-codes) Allow federation? not currently yes NAT traversal integrated separated (STUN) User agent software only (USB phones) software and hardware primarily market hardware User interface presence-like phone-like June 2005 87

Open standard, dominant vendor n n Example: H. 323 doesn’t matter what the standard Open standard, dominant vendor n n Example: H. 323 doesn’t matter what the standard says Net. Meeting and H. 323 test with Microsoft implementation limits feature evolution to dominant vendor speed and interests June 2005 88

Open standard, multiple vendors n n n Example: SIP More than just one application: Open standard, multiple vendors n n n Example: SIP More than just one application: n Software UAs, proxies, phones, gateways, media servers, test tools, OA&M, … interoperability problems likely until product maturity harder to test internally against all (competing) products divergent views and communities in IETF and other SDOs n likely have to support union of requirements n emphasis on extensibility, modularity and protocol re-use n temptation to not implement everything security SIP: generality over efficiency better long-term outcome, but slower n n n June 2005 89

Why SIP extensions? n n Good interoperability in basic call setup Extensions are sometimes Why SIP extensions? n n Good interoperability in basic call setup Extensions are sometimes indications where work is needed n or “I didn’t know this existed” n n n unfortunately, no good SIP Roadmap document some “wrong protocol, buddy” some “I don’t have the resources to participate in standardization” currently, 68 SIP/SIPPING/SIMPLE I-Ds 26 SIP RFCs (+ 13 SIPPING RFCs) June 2005 90

SIP proprietary extensions n n Examples based on informal email survey Shared line support SIP proprietary extensions n n Examples based on informal email survey Shared line support to emulate key systems: n n n TCAP over SIP n not dialogs, but state of AORs see SIMPLE for LNP general: pick up information along the way Auto-answer support (intercom) June 2005 n Caller-indicated ringing preferences n n Billing and dialing plan Tone for charged vs. free calls Caller name identification added by proxies n n visual ringing P-Asserted-Identity extension Call routing diagnostics 91

SIP proprietary extensions, cont’d n n n “upgrade your endpoint!” Caller time zone NAT SIP proprietary extensions, cont’d n n n “upgrade your endpoint!” Caller time zone NAT support n STUN servers not widely available – no incentive n n some use simple HTTP query (just needs cgi-bin) probably biggest advantage that Skype has many, make SIP work well in old world on phone look-alikes reason given: n n local interest only takes too long to standardize June 2005 92

The SIP complexity fallacy n n IAX (for example) is simpler than SIP but The SIP complexity fallacy n n IAX (for example) is simpler than SIP but you could build the IAX functionality in SIP at just about the same complexity: n n no proxies no codec negotiation no distributed services Difficulty: extracting those simple pieces from 269 pages of specification (+ SDP + RTP) SIP still more complex due to signaling-data separation IAX model Signaling & Media Signaling Media SIP, H. 323, MCGP model June 2005 93

Does it have to be that complicated? • • highly technical parameters, with differing Does it have to be that complicated? • • highly technical parameters, with differing names inconsistent conventions for user and realm made worse by limited end systems (configure by multi-tap) usually fails with some cryptic error message and no indication which parameter 94 • June 2005 out-of-box experience not good

Solving the configuration mess n Initial development assumed enterprise deployment n n pre-configured via Solving the configuration mess n Initial development assumed enterprise deployment n n pre-configured via tftp or (rarely) DHCP not suitable for residential use, except if box is shipped pathetic security – password accessible to anybody who knows MAC address of phone Short term n n adopt simple default conventions should only need SIP URI (Ao. R), display name and password n n n provide and expose error feedback n n n realm = URI outbound proxy = domain not “authentication failure” but “realm not recognized – change to [email protected] format” use DNS NAPTR and SRV for STUN server June 2005 95

Solving the configuration mess – longer term n IETF efforts on configuration management n Solving the configuration mess – longer term n IETF efforts on configuration management n n n retrieve via HTTP (+ TLS) change notification via SIP event notification problem of configuring initial secret remains probably need embedded public keys Still need better diagnostics n n one-way voice issues authentication failures June 2005 96

Vo. IP end system configuration AOR DNS SIP SUBSCRIBE/NOTIFY MAC address DHCP registrar address Vo. IP end system configuration AOR DNS SIP SUBSCRIBE/NOTIFY MAC address DHCP registrar address STUN/TURN – local and global general configuration document (media, UI, protocol behavior, …) geographical location (for 911) outbound proxy that’s all it should take June 2005 97

Problems in Standards Land n June 2005 data exchange L 2. 5 -L 7 Problems in Standards Land n June 2005 data exchange L 2. 5 -L 7 protocols IEEE, IETF, W 3 C, OASIS, ISO L 1 -L 2 Packet. Cable, ETSI, 3 GPP 2, OMA, UMA, … operational, marketing: n data formats IETF architectural: n n W 3 C ISO (MPEG) primary: n n OASIS SIP Forum, IPCC, … Packet. Cable n Proliferation of transition standards: 2. 5 G, 2. 6 G, 3. 5 G, … Splintering of standardization efforts across SDOs 3 GPP n 98

IETF issues n SIP WGs: small number (dozen? ) of core authors (80/20) n IETF issues n SIP WGs: small number (dozen? ) of core authors (80/20) n n some now becoming managers… IETF: research engineering maintenance n many groups are essentially maintaining standards written a decade (or two) ago n n often dealing with transition to hostile network Stale IETF leadership n n DNS, IPv 4, IPv 6, BGP, DHCP; RTP, SIP, RTSP constrained by design choices made long ago often from core equipment vendors, not software vendors fair amount of not-invented-here syndrome n n n late to recognize wide usage of XML and web standards late to deal with NATs security tends to be per-protocol (silo) n n some efforts such as SAML and SASL tendency to re-invent the wheel in each group June 2005 99

IETF issue: timeliness n Most drafts spend lots of time in 90%-complete state n IETF issue: timeliness n Most drafts spend lots of time in 90%-complete state n n lack of energy (moved on to new -00) optimizers vs. satisfiers n n Notorious examples: n n n occasional interim meetings IETF meetings are often not productive n n SIP request history: Feb. 2002 – May 2005 (no RFC yet) Session timers: Feb. 1999 – May 2005 (RFC 4028) Resource priority: Feb. 2001 – now (LC) New framework/requirements phase adds 1 -2 years of delay Three bursts of activity/year, with silence in-between n n multiple choices that have non-commensurate trade-offs most topics gets 5 -10 minutes lack context, focus on minutiae no background same people as on mailing list 5 people discuss, 195 people read email No formal issue tracking n some WGs use tools, haphazardly June 2005 100

IETF issues: timeliness n WG chairs run meetings, but are not managing WG progress IETF issues: timeliness n WG chairs run meetings, but are not managing WG progress n very little control of deadlines n n n little push to come to WGLC limited timeliness accountability of authors and editors chairs often provide limited editorial feedback IESG review can get stuck in long feedback loop n n n e. g. , all SIMPLE deadlines are probably a year behind author – AD – WG chairs sometimes lack of accountability (AD-authored documents) RFC editor often takes 6+ months to process document n n dependencies; IANA; editor queue; author delays e. g. , session timer: Aug. 2004 – May 2005 June 2005 101

Interworking Vo. IP -- Cellular n n A whole separate talk Options: n registration Interworking Vo. IP -- Cellular n n A whole separate talk Options: n registration n n integration -- cellular in charge n n n single tel/SIP URI; forward calls to mobile access: UMA -- make look like GSM BSC system: use Vo. IP as VLR or HLR cellular as transport n June 2005 treat cellular as another access network 102

UMA* functional architecture June 2005 *Unlicensed Mobile Access 103 UMA* functional architecture June 2005 *Unlicensed Mobile Access 103

UMA signaling June 2005 104 UMA signaling June 2005 104

UMA GSM speech bearer architecture June 2005 105 UMA GSM speech bearer architecture June 2005 105

Conclusion n Slow transition from emulating PSTN to new services n n n Emphasis Conclusion n Slow transition from emulating PSTN to new services n n n Emphasis moving from protocol mechanics to architecture n n presence-based embedded (e. g. , games) slow transition to open systems different combinations of software vendors, IAP/ISP, VSP, hardware vendors Still need to fill out infrastructure for collaboration and presence Standardization bodies face challenges of overlap and resource exhaustion June 2005 106