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

Henning SchulzrinneDept. of Computer Science

Columbia UniversitySeptember 2005

September 2005 2

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

multimedia communications service creation and programmable systems VoIP: poll model presence model application sharing

SIP architecture and design philosophy Philosophies: Skype, IETF, NGS, …

September 2005 3

Philosophy transitionPhilosophy transition

One computer/phone,many users

One 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

September 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

September 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

September 2005 6

Current challengesCurrent challenges Protocol (point)

challenges 9-1-1 support

location mapping presence

configuration and policy

automated system configuration

System challenges 9-1-1 reliability (incl.

consistent QoS) manageability

by non-experts cross-domain AAA inter-domain trust

September 2005 7

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

September 2005 8

Filling in the protocol gapFilling in the protocol gap

Service/delivery

synchronous asynchronous

push SIPRTSP, RTP

SMTP

pull HTTPftpSunRPC, Corba, SOAP

(not yet standardized)

September 2005 9

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

SIP

XCAP(config)

RTSP

SIMPLEpolicyRPID

….

SDP

XCON(conferencing)

STUNTURN

RTP

configures

initiates carries

carriescontrols provide addresses

September 2005 10

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

Core

Mostly PSTN

Content types

Request routing

September 2005 11

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

September 2005 12

SIP is PBX/Centrex readySIP is PBX/Centrex readycall waiting/multiple calls

RFC 3261

hold RFC 3264

transfer RFC 3515/Replaces

conference RFC 3261/callee caps

message waiting message summary package

call forward RFC 3261

call park RFC 3515/Replaces

call pickup Replaces

do not disturb RFC 3261

call coverage RFC 3261

from Rohan Mahy’s VON Fall 2003 talk

simultaneous ringing

RFC 3261

basic shared lines

dialog/reg. package

barge-in Join

“Take” Replaces

Shared-line “privacy”

dialog package

divert to admin RFC 3261

intercom URI convention

auto attendant RFC 3261/2833

attendant console

dialog package

night service RFC 3261

centr

ex-s

tyle

featu

res

boss/admin features

attendant features

September 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

September 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

September 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

September 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

September 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

September 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

September 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

September 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

no

Media no maybe yes

Services rendezvouscall routing

call stateful media-related

September 2005 21

Interconnection Interconnection approachesapproaches

Property NGN, 3GPP “Internet”

interconnection per service service neutral

end device control carrier-controlled user-provided

end device type mostly hardware software, maybe hardware

state preference call state-full statelesstransaction-stateful

interconnect 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

September 2005 22

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

columbia.edu example.com

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

TLS

DIAMETERserver

802.1x

NSIS NTLPfor QoS

Visitednetwork

AP

Checkreputation ofcolumbia.edu

alice@isp.net

isp.net

September 2005 23

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

September 2005 24

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

September 2005 25

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

September 2005 26

SBC: Network evolutionSBC: Network evolution

SBC

earlier: email, IM

only IP-level(with filter)

stand-alone networks(Vonage, Skype)

media

September 2005 27

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…

September 2005 28

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

September 2005 29

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)

September 2005 30

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

September 2005 31

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 callee

time CPL

capabilities caller preferences

location location-based call routinglocation events

activity/availability presence

sensor data (mood, bio)

privacy issues similar to location data

September 2005 32

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

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

September 2005 33

Presence data modelPresence data model

“calendar” “cell” “manual”

alice@example.comaudio, video, text

r42@example.comvideo

person(presentity)

(views)

services

devices

September 2005 34

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

September 2005 35

Presence data architecturePresence data architecture

candidatepresencedocument

watcherfilter

rawpresencedocument

post-processingcomposition(merging)

finalpresencedocument

differenceto previous notification

SUBSCRIBE

NOTIFY

remove data not of interest

watcher

September 2005 36

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

September 2005 37

RPID: rich presenceRPID: rich presence<person>

<tuple>

<device>

<activities>

<class>

<mood>

<place-is>

<place-type>

<privacy>

<relationship>

<service-class>

<sphere>

<status-icon>

<time-offset>

<user-input>

September 2005 38

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)

LESS

translateRPID

CPL

PA

PUBLISH

NOTIFY

INVITE

September 2005 39

Presence and privacyPresence and privacy

All presence data, particularly location, is highly sensitive

Basic location object (PIDF-LO) describes

distribution (binary) retention duration

Policy rules for more detailed access control

who can subscribe to my presence

who can see what when

<tuple id="sg89ae">

<status>

<gp:geopriv>

<gp:location-info>

<gml:location>

<gml:Point gml:id="point1“

srsName="epsg:4326">

<gml:coordinates>37:46:30N 122:25:10W

</gml:coordinates>

</gml:Point>

</gml:location>

</gp:location-info>

<gp:usage-rules>

<gp:retransmission-allowed>no

</gp:retransmission-allowed>

<gp:retention-expiry>2003-06-23T04:57:29Z

</gp:retention-expiry>

</gp:usage-rules>

</gp:geopriv>

</status>

<timestamp>2003-06-22T20:57:29Z</timestamp>

</tuple>

September 2005 40

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

September 2005 41

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

September 2005 42

Program location-based Program location-based servicesservices

September 2005 43

Service creationService creation

programmer, carrier

end user

network servers

SIP servlets, sip-cgi

CPL

end system VoiceXMLscripting, RPC

VoiceXML (voice),LESS

Tailor a shared infrastructure to individual users traditionally, only by vendors (and sometimes carriers) learn from web models: killer app vertical apps

September 2005 44

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

September 2005 45

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

September 2005 46

LESS: Decision treeLESS: Decision tree

No loopsLimited variablesNot necessarily Turing-complete

September 2005 47

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.

September 2005 48

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

September 2005 49

Device agent

x10 vcr

SIP user agent

SIP

LESS packagesLESS packages

Basic user agent

Generic Media UI

conference

email web

calendar

im

Presence agent

presence

Event

Use packages to group elements

locationsession

September 2005 50

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>

September 2005 51

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>

September 2005 53

Programming VoIP clientsProgramming VoIP clients Precursor: CTI

but rarely used outside call centers Call external programs

e.g., Google maps, local search Scripting APIs

e.g., call Tcl or PHP scripts sip-cgi Controllable

COM, XML RPC used for media agents in sipc

Embeddable no UI, just signaling and media

September 2005 54

Interfacing with GoogleInterfacing with Google911: caller locationIM/presence: location of friendscall: “I’m here”

September 2005 55

Interfacing with GoogleInterfacing with Googleshow all files from caller Xiaotao Wu

September 2005 56

Embedding VoIP: FAA Embedding VoIP: FAA trainingtraining

controls pilot and ATC

agents – using multicast and

unicast (“landlines”)

September 2005 57

Conference controlConference control

Setting up parameterized conferences SIP INVITE and NOTIFY suffice for

basic dial-in conference functionality and change notification

IETF XCON WG struggling with model and complexity

September 2005 58

XCON SystemXCON SystemLogical XCON Server

Floor ControlClient

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

Conf EventNotification Server

Focus

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.

CCCPCPCPSIP NOTIFY/Etc. BFCP

Logical XCON Client

September 2005 59

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

September 2005 60

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

September 2005 61

Spam and spitSpam and spit

September 2005 62

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)

September 2005 63

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

September 2005 64

Reputation serviceReputation service

Alice Bob

CarolDavid

Emily Frank

has sentemail to

has sentIM to

is this a spammer?

September 2005 65

SIP standards & deployment SIP standards & deployment issues and competitionissues and competition

Interoperability Proprietary systems

September 2005 66

cableDSL op

CiscoCM

Provider combinationsProvider combinations

software hardware

ISPIAP

VSP

Skype

mobileoperators?

September 2005 67

VoIP service providersVoIP service providers

GoogleMSNYahoo!Xbox

mostly IMno PSTN (now)

AT&T (Vantage)Verizon (VoiceWing)JP SoftBank (8.3m)

Cable (911,000):ComCast

primary line replacementvoice only

SkypeVonage (1m)

September 2005 68

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

September 2005 69

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

September 2005 70

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

September 2005 71

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

Skype SIP-based providers

Protocol proprietary, encryptedSIP to gateways

open (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 yes

NAT traversal integrated separated (STUN)

User agent software only(USB phones)

software and hardwareprimarily market hardware

User interface presence-like phone-like

September 2005 72

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

September 2005 73

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

September 2005 74

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

Media

IAX model

SIP, H.323, MCGP model

September 2005 75

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

September 2005 76

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

September 2005 77

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

September 2005 78

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