VoIP - Moving from protocols to architecture(s)

transcript

VoIP - Moving from VoIP - Moving from protocols to protocols to architecture(s)architecture(s)

Henning SchulzrinneDept. of Computer Science

Columbia UniversityJanuary 2006

June 2005 2

OverviewOverview The big transitions in VoIP An Internet protocol framework Open issues in VoIP and interactive

multimedia communications service creation VoIP: 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 3

Philosophy transitionPhilosophy transitionOne computer/phone,

many usersOne computer/phone,

one user

Many computers/phones,one user

anywhere,any time

any media

right place (device),right time,right media

~ ubiquitous computing

mainframe erahome phone

party line

PC eracell phone era

June 2005 4

Evolution of VoIPEvolution of VoIP

“amazing – thephone rings”

“does it docall transfer?”

“how can I make itstop ringing?”

1996-2000 2000-2003 2004-

catching upwith the digital PBX

long-distance calling,ca. 1930 going beyond

the black phone

June 2005 5

Collaboration in transitionCollaboration in transition

intra-organization;

small number of systems

(meeting rooms)

inter-organization

multiple technology generationsdiverse end

points

proprietary (single-vendor)

systems

standards-based solutions

June 2005 6

Internet services – the Internet services – the missing entrymissing entry

Service/delivery

synchronous asynchronous

push instant messagingpresenceevent notificationsession setupmedia-on-demand

messaging

pull data retrievalfile downloadremote procedure call

peer-to-peer file sharing

June 2005 7

Filling in the protocol gapFilling in the protocol gap

Service/delivery

synchronous asynchronous

push SIPRTSP, RTP

pull HTTPftpSunRPC, Corba, SOAP

(not yet standardized)

June 2005 8

A constellation of SIP RFCsA constellation of SIP RFCs

Resource mgt. (3312)Reliable prov. (3262)INFO (2976)UPDATE (3311)Reason (3326)SIP (3261)

DNS for SIP (3263)Events (3265)REFER (3515)

DHCP (3361)DHCPv6 (3319)

Digest AKA (3310)Privacy (3323)P-Asserted (3325)Agreement (3329)Media auth. (3313)AES (3853)

Non-adjacent (3327)Symmetric resp. (3581)Service route (3608)User agent caps (3840)Caller prefs (3841)

ISUP (3204)sipfrag (3240)

Security & privacy

Configuration

Mostly PSTN

Content types

Request routing

June 2005 9

An eco system, not just a An eco system, not just a protocolprotocol

XCAP(config)

SIMPLEpolicyRPID….

XCON(conferencing)

STUNTURNRTP

configures

initiates carries

carriescontrols provide addresses

June 2005 10

SIP, SIPPING & SIMPLE –00 draftsSIP, SIPPING & SIMPLE –00 drafts

includes draft-ietf-*-00 and draft-personal-*-00

1999 2000 2001 2002 2003 2004 2005

SIPSIPPINGSIMPLE

June 2005 11

RFC publicationRFC publication

2001 2002 2003 2004 2005

SIPSIPPINGSIMPLE

June 2005 12

SIP – a bi-cultural protocolSIP – a bi-cultural protocol

• overlap dialing• DTMF carriage• key systems• notion of lines• per-minute billing• early media• ISUP & BICC interoperation• trusted service providers

• multimedia• IM and presence• location-based service• user-created services• decentralized operation• everyone equally suspect

June 2005 13

SIP design objectivesSIP design objectives new features and services

support features not available in PSTN e.g., presence and IM, session mobility

not a PSTN replacement not just SS7-over-IP even similar services use different models (e.g., call transfer)

client heterogeneity clients can be smart or dumb (terminal adapter) mobile or stationary hardware or software

client multiplicity one user – multiple clients – one address

multimedia nothing in SIP assumes a particular media type

Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00

June 2005 14

SIP architectural principles SIP architectural principles (1)(1) proxies are for

routing do not maintain call

state availability scalability flexibility extensibility (new

methods, services) end point call state

and features dialog models, not

call models does not standardize

features

endpoint fate sharing call fails only if

endpoints fail component-based

design building blocks call features =

notification and manipulation

logical components, not physical

UA, proxy, registrar, redirect server

can be combined into one box

Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00

June 2005 15

SIP architectural principles SIP architectural principles (2)(2) designed for the

(large) Internet does not assume

particular network topology

congestion-controlled deals with packet loss uses core Internet

services: DNS for load

balancing DHCP for

configuration S/MIME for e2e

security TLS for channel

security

generality over efficiency

focuses on algorithm efficiency, not constant-factor 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

June 2005 16

SIP architectural principles SIP architectural principles (3)(3) separation of signaling and media

path followed by media packets independent of signaling path

allows direct routing of latency-sensitive media packets (10 ms matters)

without constraining service delivery (1s matters) facilitates mobility

avoid “hair pinning”, “tromboning” facilitates vertical split between ISP and VSP

June 2005 17

SIP design principles (1)SIP design principles (1) Proxies are method, body

and header independent does not depend on

method 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

Full-state nature of INVITE

each (re)INVITE contains full session state

facilitates MIDCOM-style interactions

allows session transfer SIP URIs identify

resources can be device instance,

service, person but cannot tell from URI

which (good!) can specify services and

service parameters

June 2005 18

SIP design principles (2)SIP design principles (2) Extensibility and compatibility

can define new methods, header fields, body types, parameters

supported by OPTIONS, Accept, Accept-Language, Allow, Supported, Require, Proxy-Require, Accept-Encoding and Unsupported

“asking permission” OPTIONS, dialog establishment

“asking forgiveness” use extension without asking (Proxy)-Require: “please reject

if you don’t understand it” “use if you like”

allow recipients to safely ignore information

must provide fallback!

Internationalization UTF-8 for freeform text negotiation of languages

Explicit intermediaries = SIP proxies unlike transparent HTTP

proxies or NAT boxes, announce themselves

Via, Record-Route only involved if asked by UA

or proxy should ask endpoints,

rather than just do e.g., session policy

June 2005 19

SIP design principles (3)SIP design principles (3) Guided proxy routing

predetermine a set of downstream proxy resource that must be visited

supported by Record-Route, Path, Service-Route

Transport protocol independence

can use UDP, TCP, SCTP, …

only requires packet-based (unreliable) delivery

design decision that comes with some regret

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

June 2005 20

SIP division of laborSIP division of laborproxy B2BUA UA

State statelesstransaction-stateful

call stateful call stateful

Headers inspectinsertmodify (rarely)

inspectinsertmodify

inspectreflect

Bodies ignoresome inspect

inspectinsertmodify

inspect

Fork yes separate call legs

Media no maybe yesServices rendezvous

call routingcall stateful media-related

June 2005 21

UMTS Reference UMTS Reference Architecture Architecture

by Kimmo Raatikainen

R UuMGW

Signalling and Data TransferInterface

SignallingInterface

TE MT UTRAN

SGSN GGSN

R-SGW *)

MultimediaIP Networks

PSTN/Legacy/External

Applications &Services *)

Legacy mobilesignallingNetwork

AlternativeAccess

Network

CSCFMg

T-SGW *)

HSS *)

Applications& Services *)

MSC server GMSC server

R-SGW *)Mh

CAPCAP

R UmTE MT

BSS/GERAN

*) those elements are duplicated for figurelayout purpose only, they belong to the samelogical element in the reference model

June 2005 22

3G Architecture 3G Architecture (Registration)(Registration)

visited IM domain

home IM domain

servingCSCF

interrogating

mobility managementsignaling

registration signaling (SIP)_

describesdeploymen

t architectur

June 2005 23

Classical IETF interfacesClassical IETF interfaces

L2Ethernet

L3 IPv4/IPv6

L3 config DHCP, PPP

namemapping

BGPOSPF

IPv4/IPv6

DNS DNS

signaling SIP SIP

“UNI” “NNI”

routerproxyserver

June 2005 24

IETF interface approachIETF interface approach Essentially, only two types of entities

end systems (user agents, hosts, clients, …) network systems (proxies, routers, servers, …)

No functional definitions or assumptions SIP UA can be PSTN gateway or cell phone

(Mostly) strong separation of layers IP-layer interface can change without SIP changing Can replace routing protocol without affecting HTTP

Function defined by protocol actions not general behavior (“gateway”)

Does not describe functional entities as such web server + SIP UAC + router

June 2005 25

IP “hourglass”IP “hourglass”

email WWW phone...

SMTP HTTP RTP...

TCP UDP…

ethernet PPP…

CSMA async sonet...

copper fiber radio...Steve Deering, IETF Aug. 2001

June 2005 26

The real Internet hourglass The real Internet hourglass (slightly simplified)(slightly simplified)

Ethernet

webweb services

p2p (port 80)

June 2005 27

Interconnection Interconnection approachesapproaches

Property NGN, 3GPP “Internet”interconnection per service service neutralend device control carrier-controlled user-providedend device type mostly hardware software, maybe

hardwarestate preference call state-full stateless

transaction-statefulinterconnect arrangement

pre-arranged serendipitous

interconnect discovery

pre-configured DNS

billing preference per serviceusage-based

bandwidth-basedservices fixed-rate or ad-supported

billing arrangement clearing house sender keepsindependent

June 2005 28

IETF “4G” (access-neutral) IETF “4G” (access-neutral) modelmodel

columbia.edu example.com

sip:alice@columbia.edu sip:bob@example.com TLS

DIAMETERserver

802.1xNSIS NTLPfor QoS

Visitednetwork

Checkreputation ofcolumbia.edu

alice@isp.net

isp.net

June 2005 29

Session Border Controllers Session Border Controllers (SBCs)(SBCs) Provider border element SIP terms: either B2BUA or proxies

but often ill-defined (may change roles) Functions differ

similar definitional problem as “soft switches”

May force convergence of media and signaling path

June 2005 30

SBCs: High-level SBCs: High-level motivationsmotivations 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:

media vs. control separation good idea in theory, harder in today’s limited-functionality

Internet force media through single control point (IP address)

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

not an issue for email and web

June 2005 31

SBC functionality, cont’dSBC functionality, cont’d Signaling functionality:

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 DoS attack mitigation

Media functionality: Codec conversion SLA enforcement Legal Intercept & CALEA

compliance Bandwidth Management Packet marking QoS guarantees Packet steering Media encryption Firewall (pinholes) DoS attack mitigation

June 2005 32

SBC: Network evolutionSBC: Network evolution

earlier: email, IM

only IP-level(with filter)

stand-alone networks(Vonage, Skype)

June 2005 33

SBC: ConcernsSBC: Concerns Common concerns:

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 34

SBC: The dangersSBC: The dangers May not be present in all

instances SBCs are a box description, not

a function description Lack of visibility

cannot tell where SBC is located

hard to diagnose failures see HTTP “transparent proxy”

experience one example: TP thought SIP

was HTTP hard to address content

cryptographically to such box Lack of transparency

not all features make it through SBC

header support copying content routing loops

Lack of security Inherent conflict

between need for media session inspection and session privacy

Session description modification removes accountability

Lack of scalability needs to handle all

media packets often, call stateful

rather than stateless or transaction-stateful

June 2005 35

What’s left to do?What’s left to do? Transition from “poll” model to context-based

communications Higher-level service creation in end systems Dealing with NATs

STUN (and SIP modifications) as first step ICE and BEHAVE WG as longer-term solutions

The role of intermediaries session-border controllers end-to-middle security session policies

Conference control Application sharing Security issues (spam, spit --> identity and

reputation management)

June 2005 36

P2P for autonomic P2P for autonomic computingcomputing Autonomic at the application layer:

Robust against partial network faults Resources grow as user population grows Self-configuring

Traditional p2p systems file storage

motivation is often legal, not technical, efficiency usually unstructured, optimized for Zipf-like popularity

Other p2p applications: Skype demonstrates usefulness for VoIP

identifier lookup NAT traversal: media traversal

OpenDHT (and similar) as emerging common infrastructure?

Non-DHT systems with smaller scope web hotspot rescue

Network management (see our IRTF slides)

June 2005 37

What is SIP? Why P2P-SIP?What is SIP? Why P2P-SIP?

Bob’s hostAlice’s host128.59.19.194

(1) REGISTER alice@columbia.edu =>128.59.19.194

(2) INVITE alice@columbia.edu

(3) Contact: 128.59.19.194

columbia.edu

Problem in client-server: maintenance, configuration, controlled infrastructure

Peer-to-peer network

Alice128.59.19.194

(1) REGISTER(2) INVITE alice

(3) 128.59.19.194

No central server, but more lookup latency

June 2005 38

How to combine SIP + How to combine SIP + P2P?P2P?

SIP-using-P2P Replace SIP location

service by a P2P protocol

P2P-over-SIP Additionally, implement

P2P using SIP messaging

P2P network

Alice128.59.19.194

INSERT

INVITE sip:alice@128.59.19.194

P2P-SIPoverlay Alice

128.59.19.194

REGISTERINVITE aliceFIND

SIP-using-P2P P2P SIP proxies

P2P-over-SIP

Maintenance P2P P2P SIPLookup P2P SIP SIP

June 2005 39

Deployment scenariosDeployment scenarios

P2P proxies

P2P database

P2P clients

Plug and play; May use adaptors;Untrusted peers

Zero-conf server farm; Trusted servers and user identities

Global, e.g., OpenDHT; Clients or proxies can use;Trusted deployed peers (?)

Interoperate among these!

June 2005 40

Hybrid architectureHybrid architecture

Cross register, or Locate during call

setup DNS, or P2P-SIP hierarchy

June 2005 41

What else can be P2P?What else can be P2P? 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 42

What is our P2P-SIP?What is our P2P-SIP? Unlike server-based SIP architecture Unlike proprietary Skype architecture

Robust and efficient lookup using DHT Interoperability

DHT algorithm uses SIP communication Hybrid architecture

Lookup in SIP+P2P Unlike file-sharing applications

Data storage, caching, delay, reliability Disadvantages

Lookup delay and security

June 2005 43

Implementation: Implementation: SIPpeerSIPpeer Platform: Unix (Linux), C++ Modes:

Chord: using SIP for P2P maintenance OpenDHT: using external P2P data

storage Scenarios:

P2P client, P2P proxies Adaptor for existing phones

Cisco, X-lite, Windows Messenger, SIPc Server farm

June 2005 44

Implementation: Implementation: SIPpeerSIPpeer

User interface (buddy list, etc.)

SIPICE RTP/RTCPCodecs

Audio devicesDHT (Chord)

On startup

Discover

User location

Multicast REGISTERPeer found/Detect NAT

REGISTERREGISTER, INVITE,MESSAGE

Signup,Find buddies

JoinFind

On resetSignout,transfer

IM,call

SIP-over-P2P

P2P-using-SIP

June 2005 45

SIP p2p summary and open SIP p2p summary and open issuesissues

Advantages Out-of-box experience Robust

catastrophic failure-unlikely

Inherently scalable more with more nodes

Status IETF involvement Columbia SIPpeer

Security issues Trust, reputation malicious node, sybil

attack SPAM, DDoS Privacy, anonymity (?)

Other issues Lookup latency,proximity P2P-SIP vs SIP-using-P2P Why should I run as

super-node?

http://www.cs.columbia.edu/IRT/p2p-sip http://www.p2psip.org and

June 2005 46

The role of presenceThe role of presence Guess-and-ring

high probability of failure: “telephone tag” inappropriate time (call

during meeting) inappropriate media (audio

in public place) current solutions:

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

Presence-based 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 47

Context-aware Context-aware communicationcommunication

context = “the interrelated conditions in which something exists or occurs”

anything known about the participants in the (potential) communication relationship

both at caller and calleetime CPLcapabilities caller preferenceslocation location-based call routing

location eventsactivity/availability presencesensor data (mood, bio)

privacy issues similar to location data

June 2005 48

The role of presenceThe role of presence “Is the callee likely to be reachable?” user-

level presence glue logic for loosely-coupled systems events related to calls:

voicemail notification call transfer notification

Events are a superset of presence: publish, subscribe & notify in SIMPLE, just differ in their

event type and bodies (typically, XML) privacy policies

unlike other event systems, cross-domain, with security

but no content-dependent replication (Siena, Elvin, …)

June 2005 49

Basic presenceBasic presence Role of presence

initially: “can I send an instant message and expect a response?”

now: “should I use voice or IM? is my call going to interrupt a meeting? is the callee awake?”

note: may not be continuous subscription, but rather on-demand (when trying to reach somebody)

Yahoo, MSN, Skype presence services: on-line & off-line

useful in modem days – but many people are (technically) on-line 24x7

thus, need to provide more context + simple status (“not at my desk”)

entered manually rarely correct does not provide enough context for directing interactive

communications

June 2005 50

The role of presence for call The role of presence for call routingrouting Two modes:

watcher uses presence information to select suitable contacts

advisory – caller may not adhere to suggestions and still call when you’re in a meeting

user call routing policy informed by presence

likely less flexible – machine intelligence

“if activities indicate meeting, route to tuple indicating assistant”

“try most-recently-active contact first” (seq. forking)

translateRPID

PUBLISH

NOTIFY

INVITE

June 2005 51

GEOPRIV and SIMPLE GEOPRIV and SIMPLE architecturesarchitectures

target locationserver

locationrecipient

rulemaker

presentity

caller

presenceagent watcher

callee

GEOPRIV

SIPpresence

SIPcall

PUBLISHNOTIFY

SUBSCRIBE

INVITE

publicationinterface

notificationinterface

XCAP(rules)

INVITE

June 2005 52

Presence data architecturePresence data architecture

rawpresencedocument

createview

(compose)privacyfiltering

draft-ietf-simple-presence-data-model

compositionpolicy

privacypolicy

presence sources

XCAP XCAP

(not defined yet)

depends on watcherselect best sourceresolve contradictions

PUBLISH

June 2005 53

Presence data architecturePresence data architecture

candidatepresencedocument

watcherfilter

rawpresencedocument

post-processingcomposition(merging)

finalpresencedocument

differenceto previous notification

SUBSCRIBE

NOTIFY

remove data not of interest

watcher

June 2005 54

Presence data modelPresence data model

“calendar” “cell” “manual”

alice@example.comaudio, video, text

r42@example.comvideo

person(presentity)

(views)

services

devices

June 2005 55

Rich presenceRich presence More information automatically derived from

sensors: physical presence, movement electronic activity: calendars

Rich information: multiple contacts per presentity

device (cell, PDA, phone, …) service (“audio”)

activities, current and planned surroundings (noise, privacy, vehicle, …) contact information composing (typing, recording audio/video IM, …)

June 2005 56

Privacy policy Privacy policy relationshipsrelationships

geopriv-specific presence-specific

common policy

RPID CIPID

future

June 2005 57

Privacy rulesPrivacy rules Conditions

identity, sphere time of day current location identity as <uri> or

Actions watcher

confirmation Transformations

include information reduced accuracy

User gets maximum of permissions across all matching rules privacy-safe

composition: removal of a rule can only reduce privileges

Extendable to new presence data rich presence biological sensors mood sensors

June 2005 58

Example rules documentExample rules document

<identity><id>user@example.com</id></identity>

<sub-handling>allow</sub-handling>

<provide-services> <service-uri-scheme>sip</service-uri-scheme> <service-uri-scheme>mailto</service-uri-scheme></provide-services><provide-person>true</provide-person><provide-activities>true</provide-activities><provide-user-input>bare</provide-user-input>

June 2005 59

Location-based servicesLocation-based services Finding services based on location

physical services (stores, restaurants, ATMs, …) electronic services (media I/O, printer, display, …) not covered here

Using location to improve (network) services communication

incoming communications changes based on where I am configuration

devices in room adapt to their current users awareness

others are (selectively) made aware of my location security

proximity grants temporary access to local resources

June 2005 60

Location-based SIP Location-based SIP servicesservices Location-aware inbound 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 do not ring phone if I’m in a theater

outbound call routing contact nearest emergency call center 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

June 2005 61

Presence CompositionPresence Composition composition = combines multiple presence or

event sources into one view remove information: stale, contradictory, redundant create new information (e.g., new composite

services) Tries to resolve information conflicts

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 i.e., provides maximum information set for later

stages

June 2005 62

Sources of presence dataSources of presence data Reported current

added manually a brief time ago assumed correct when entered, but decays

Reported scheduled from a calendar

Measured device information communication status

Measured by sensors location, type of location, activity, … sensors = GPS, acceleration sensors, PIRs, ...

Derived from other presence data

June 2005 63

Composition stepsComposition steps

Working on policy language that describes desired composition policy

Complicated policies will require “real” languages

source

sourceunion with

replacement

discardclosed +

combineidenticalcontacts

resolveambiguities

June 2005 64

Service creationService creation

programmer, carrier

end user

network servers

SIP servlets, sip-cgi

end system VoiceXML VoiceXML (voice),LESS

Tailor a shared infrastructure to individual users traditionally, only vendors (and sometimes carriers) learn from web models

June 2005 65

Automating media Automating media interaction – service interaction – service examplesexamples 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:00AM 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 66

LESS: simplicityLESS: simplicity Generality (few and simple concepts) Uniformity (few and simple rules)

Trigger rule Switch rule Action rule Modifier rule

Familiarity (easy for user to understand)

Analyzability (simple to analyze)

switchestrigger actions

modifiers

June 2005 67

LESS: Decision treeLESS: Decision treeNo loopsLimited variablesNot necessarily Turing-complete

June 2005 68

LESS: SafetyLESS: Safety Type safety

Strong typing in XML schema Static type checking

Control flow safety No loop and recursion One trigger appear only once, no feature interaction for a

defined script Memory access

No direct memory access LESS engine safety

Ensure safe resource usage Easy safety checking

Any valid LESS scripts can be converted into graphical representation of decision trees.

June 2005 69

LESS snapshotLESS snapshot<less> <incoming> <address-switch> <address is=“sip:myboss@abc.com"> <device:turnoff device=“sip:stereo_room1@abc.com”/> <media media=“audio”> <accept/> </media> </address> </address-switch> </incoming></less>

incoming call

If the call from my boss

Turn off the stereo

Accept the call with only audio

trigger, switch, modifier, action

June 2005 70

Device agentx10 vcr

SIP user agentSIP

LESS packagesLESS packages

Basic user agentGeneric Media UI

conference

email web

calendar

Presence agent

presenceEvent

Use packages to group elements

locationsession

June 2005 71

When Tom is online, …When Tom is online, …<less><EVENT:notification> <address-switch> <address is="sip:tom@example.com"> <EVENT:event-switch> <EVENT:event is="open"> <location url="sip:tom@example.com"> <IM:im message="Hi, Tom"/> </location> </EVENT:event> </EVENT:event-switch> ………</less>

June 2005 72

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

vibrate=“yes”/> </location> </location-switch></incoming></less>

June 2005 74

XCON SystemXCON SystemLogical XCON Server

Floor ControlClient

TEMPLATEOf the SYSTEM:•Pre-configured•Initial/Default values

Conf EventNotification Server

CPCP Client

CCCPClient

CPCPServer

CCCPServer

CallSignaling

Client

TEMPLATE Policy:•Of TYPE RULES

RESERVATION Policy:•Of TYPE RULES

CURRENT Policy:•Of TYPE RULES

RESERVATIONOf the INSTANCE:•Of TYPE CONFERENCE-INFO

STATEOf the CURRENT INSTANCE:•Of TYPE CONFERENCE-INFO

NotificationClient

FloorControl Server

SIP/PSTN/H.323T.120/Etc.

CCCPCPCP SIP NOTIFY/Etc. BFCP

Logical XCON Client

June 2005 75

Conference controlConference control 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 76

Open issues: application Open issues: application sharingsharing Current: T.120

doesn’t integrate well with other conference control mechanisms

hard to make work across platforms (fonts) ill-defined security mechanisms

Current: web-based sharing hard to integrate with other media, control and record generally only works for Windows mostly limited to shared PowerPoint

Current: vnc whole-screen sharing only can be coerced into conferencing, but doesn’t

integrate well with control protocols

June 2005 77

IETF effort: standardized IETF effort: standardized application sharingapplication sharing Remote access = application sharing Four components:

window drawing ops PNG keyboard input mouse input window operations (raise, lower, move)

Uses RTP as transport synchronization with continuous media but typically, TCP allow multicast large group sessions

June 2005 78

Spam and spitSpam and spit

June 2005 79

SIP unsolicited calls and SIP unsolicited calls and messagesmessages Possibly at least as

large a problem more annoying (ring,

pop-up) Bayesian content

filtering unlikely to work

identity-based filtering

PKI for every user unrealistic

Use two-stage authentication

SIP identity work

home.comDigest

mutualPK authentication (TLS)

June 2005 80

Domain ClassificationDomain Classification Classification of domains based on their identity instantiation and

maintenance procedures plus other domain policies. Admission controlled domains

Strict identity instantiation with long term relationships Example: Employees, students, bank customers

Bonded domains Membership possible only through posting of bonds tied to a expected

behavior Membership domains

No personal verification of new members but verifiable identification required such as a valid credit card and/or payment

Example: E-bay, phone and data carriers Open domains

No limit or background check on identity creation and usage Example: Hotmail

Open, rate limited domains Open but limits the number of messages per time unit and prevents account

creation by bots Example: Yahoo

June 2005 81

Reputation serviceReputation service

Alice Bob

Carol David

Emily Frank

has sentemail to

has sentIM to

is this a spammer?

June 2005 82

SIP standards & deployment SIP standards & deployment issues and competitionissues and competition Interoperability Proprietary systems

June 2005 83

cableDSL op

CiscoCM

Provider combinationsProvider combinations

software hardware

ISPIAP VSP

mobileoperators?

June 2005 84

Protocol interoperability Protocol interoperability problemsproblems Three core interoperability problems:

syntactic robustness “You mean you could have a space there?”

often occurs when testing only against common reference implementations

need “stress test” (also for buffer overflows) 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 “I didn’t expect this error”

mutually incompatible extensions expect extension to make something work

June 2005 85

Protocol interoperability: Protocol interoperability: proprietary protocolsproprietary protocols Proprietary protocol

Example: Skype quicker evolution – not dependent on IETF

“volunteers” with day jobs can do “hacks” without IESG objection:

media over TCP inefficient search bypass routing policies circumvent firewall policies

Can only reverse-engineer only backwards-compatibility problems incentive to force upgrades (see Microsoft Word)

less Metcalfe’s law value

June 2005 86

Why is Skype successful?Why is Skype successful? All the advantages of a proprietary protocol Peer-to-peer coincidental Good out-of-box experience

Software vendor = service provider Didn’t know that you couldn’t do voice quality

beyond PSTN others too focused on PSTN interoperability – why do

better voice than PSTN? Simpler solutions for NAT traversal

use TCP if necessary use port 80

Did encryption from the very beginning Kazaa marketing vehicle

June 2005 87

Skype vs. SIP-based Skype vs. SIP-based systemssystems

Skype SIP-based providersProtocol proprietary, encrypted

SIP to gatewaysopen (SIP), often plain-textsometimes IAX to gateway

Business model prepaid outbound PSTN calls (SkypeOut)

monthly fee (Vonage)free (FWD)prepaid (SIPgate.de)

Protocol model single “network”, bridge to PSTN

some closedsome semi-open (*-codes)

Allow federation? not currently yesNAT traversal integrated separated (STUN)User agent software only

(USB phones)software and hardwareprimarily market hardware

User interface presence-like phone-like

June 2005 88

Open standard, dominant Open standard, dominant vendorvendor Example: H.323 doesn’t matter what the standard

says NetMeeting and H.323 test with

Microsoft implementation limits feature evolution to

dominant vendor speed and interests

June 2005 89

Open standard, multiple Open standard, multiple vendorsvendors Example: SIP More than just one application:

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 likely have to support union of requirements emphasis on extensibility, modularity and protocol re-

use temptation to not implement everything

security SIP: generality over efficiency better long-term outcome, but slower

June 2005 90

Why SIP extensions?Why SIP extensions? Good interoperability in basic call setup Extensions are sometimes indications

where work is needed or “I didn’t know this existed”

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 91

SIP proprietary extensionsSIP proprietary extensions Examples based on

informal email survey Shared line support to

emulate key systems: not dialogs, but state

of AORs see SIMPLE

TCAP over SIP for LNP general: pick up

information along the way

Auto-answer support (intercom)

Caller-indicated ringing preferences

visual ringing Billing and dialing

plan Tone for charged vs.

free calls Caller name

identification added by proxies

P-Asserted-Identity extension

Call routing diagnostics

June 2005 92

SIP proprietary extensions, SIP proprietary extensions, cont’dcont’d “upgrade your endpoint!” Caller time zone NAT support

STUN servers not widely available – no incentive

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: local interest only takes too long to standardize

June 2005 93

The SIP complexity fallacyThe SIP complexity fallacy IAX (for example) is simpler

than SIP but you could build the IAX

functionality in SIP at just about the same complexity:

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

Signaling & Media Signaling & Media

Signaling Signaling

IAX model

SIP, H.323, MCGP model

June 2005 94

Does it have to be that Does it have to be that complicated?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• out-of-box experience not good

June 2005 95

Solving the configuration Solving the configuration messmess Initial development assumed enterprise deployment

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

adopt simple default conventions should only need SIP URI (AoR), display name and

password realm = URI outbound proxy = domain

provide and expose error feedback not “authentication failure” but “realm not recognized – change to user@domain format”

use DNS NAPTR and SRV for STUN server

June 2005 96

Solving the configuration Solving the configuration mess – longer termmess – longer term IETF efforts on configuration

management 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 one-way voice issues authentication failures

June 2005 97

VoIP end system VoIP end system configurationconfiguration

MACaddress

registrar addressSTUN/TURN – local and global

general configuration document(media, UI, protocol behavior, …)

geographical location (for 911)outbound proxy

SIP SUBSCRIBE/NOTIFY

that’s all it should take

June 2005 98

Problems in Standards Problems in Standards LandLand Proliferation of transition

standards: 2.5G, 2.6G, 3.5G, …

Splintering of standardization efforts across SDOs

primary: IEEE, IETF, W3C, OASIS, ISO

architectural: PacketCable, ETSI, 3GPP,

3GPP2, OMA, UMA, … operational, marketing:

SIP Forum, IPCC, …

W3CISO (MPEG)

L2.5-L7protocols

dataexchange

dataformats

June 2005 99

IETF issuesIETF issues SIP WGs: small number (dozen?) of core authors (80/20)

some now becoming managers… IETF: research engineering maintenance

many groups are essentially maintaining standards written a decade (or two) ago

DNS, IPv4, IPv6, BGP, DHCP; RTP, SIP, RTSP constrained by design choices made long ago

often dealing with transition to hostile network Stale IETF leadership

often from core equipment vendors, not software vendors fair amount of not-invented-here syndrome

late to recognize wide usage of XML and web standards late to deal with NATs security tends to be per-protocol (silo)

some efforts such as SAML and SASL tendency to re-invent the wheel in each group

June 2005 100

IETF issue: timelinessIETF issue: timeliness Most drafts spend lots of time in 90%-complete state

lack of energy (moved on to new -00) optimizers vs. satisfiers

multiple choices that have non-commensurate trade-offs Notorious examples:

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

occasional interim meetings IETF meetings are often not productive

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 some WGs use tools, haphazardly

June 2005 101

IETF issues: timelinessIETF issues: timeliness WG chairs run meetings, but are not managing

WG progress very little control of deadlines

e.g., all SIMPLE deadlines are probably a year behind 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 author – AD – WG chairs sometimes lack of accountability (AD-authored

documents) RFC editor often takes 6+ months to process

document dependencies; IANA; editor queue; author delays e.g., session timer: Aug. 2004 – May 2005

June 2005 102

Interworking VoIP -- Interworking VoIP -- CellularCellular A whole separate talk Options:

registration single tel/SIP URI; forward calls to mobile

integration -- cellular in charge access: UMA -- make look like GSM BSC system: use VoIP as VLR or HLR

cellular as transport treat cellular as another access network

June 2005 103

UMAUMA** functional functional architecturearchitecture

*Unlicensed Mobile Access

June 2005 104

UMA signalingUMA signaling

June 2005 105

UMA GSM speech bearer UMA GSM speech bearer architecturearchitecture

June 2005 106

ConclusionConclusion Slow transition from emulating PSTN to new

services presence-based embedded (e.g., games)

Emphasis moving from protocol mechanics to architecture

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

VoIP - Moving from protocols to architecture(s)

Documents