Vo IP — Moving from protocols to architecture s

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

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 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, 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 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 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 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 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 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

RFC publication June 2005 11

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

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 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 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 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 TCP IP Ethernet June 2005 26

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 sip: bob@example. com TLS columbia. edu example. com Visited network NSIS NTLP for Qo. S 802. 1 x AP DIAMETER server alice@isp. net June 2005 28

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 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 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 (with filter) June 2005 32

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

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 36

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 37

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? ” Yahoo, MSN, Skype presence services: n on-line & off-line n n n useful in modem days – but many people are (technically) on-line 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 38

Presence data model person “calendar” “cell” “manual” (presentity) (views) alice@example. com audio, video, text services r 42@example. com video devices June 2005 39

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 40

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 41

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 42

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 43

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

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 45

LESS snapshot incoming call If the call from my boss

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 47

When Tom is online, …

When I am in a movie theatre, … June 2005 49

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 51

Conference control n IETF XCON WG struggling with model and complexity June 2005 52

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 53

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 54

Spam and spit June 2005 55

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 56

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 57

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

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

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

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 61

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 62

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 63

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 64

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 65

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 66

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 67

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 68

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 69

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 70

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 71 • June 2005 out-of-box experience not good

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 user@domain format” use DNS NAPTR and SRV for STUN server June 2005 72

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 73

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 74

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 75

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 76

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 77

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 78

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 79

UMA* functional architecture June 2005 *Unlicensed Mobile Access 80

UMA signaling June 2005 81

UMA GSM speech bearer architecture June 2005 82

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 83