ReInventing the Phone System

1
Re-Inventing the Phone System

• Henning Schulzrinne
• Dept. of Computer Science
• Columbia University
• (Brooklyn Poly)

2
Overview

• Predictions some plausible outcomes
• Internet from research dominance to
  consumer-driven
• Interconnection vs. islands
• peer-to-peer vs. server-based
• The end of phone tag?
• The future of telephone numbers
• Challenges
• setup and configuration
• reliability
• unsolicited communications
• creating new services
• emergency services (911)

3
Lifecycle of technologies
traditional technology propagation
military
corporate
consumer
opex/capex doesnt matter expert support
capex/opex sensitive, but amortized expert
support
capex sensitive amateur
Can it be done?
Can I afford it?
Can my mother use it?
4
Cause of death for the next big thing
5
Evolution of VoIP
how can I make it stop ringing?
does it do call transfer?
long-distance calling, ca. 1930
going beyond the black phone
amazing the phone rings
catching up with the digital PBX
1996-2000
2000-2003
2004-
6
(Early) Adulthood

• fully developed and mature
• Not quite yet, but no longer a teenager
• probably need another 6 years to be grown up
• Responsibilities
• Dealing with elderly relatives ? POTS
• Financial issues ? payments, RADIUS
• Family emergencies ? 911

7
PSTN vs. Internet Telephony
PSTN
Signaling Media
Signaling Media
China
Internet telephony
Signaling
Signaling
Media
Australia
Belgian customer, currently visiting US
8
Evolution disaggregation

• All devices are nomadic
• new location, but same identifier
• Telephone companies are no longer needed
• there are still carriers for DSL and cable IP
  dial tone
• but unaware of type of data carried (voice, web,
  IM, )
• VSP may be in another state or country
• anybody can be their own VSP
• Corporations and universities dont have email
  carriers, either

voice service provider VSP (TCP, RTP, SIP)
Yahoo
ISP (IP, DHCP)
MCI
dark fiber provider (?)
NYSERNET
9
Alternative evolution duopoly

• block port 25 (email)
• reduce QoS for UDP
• restrictive (symmetric) NATs
• QoS only through application negotiation

web
web
ILEC voice
ILEC VoD
MSO voice
MSO VoD
ILEC ISP
MSO ISP
ILEC DSL
MSO cable modem
10
Internet evolution alternatives
ISP1
vs.
IPv6
ISP3
SBC
ISP2
stacked NATs
11
Technology evolution of PSTN
SS7 1987-1997
12
The end of the beginning and the beginning of the
end

• Already, most large PBX ? VoIP
• but interconnect largely via PSTN
• development of digital switches has ceased
• Large fraction of international traffic VoIP
• most prepaid calling cards
• Japan BB Phone 3.85m (4/2004)
• US Vonage 400,000 (1/2005)
• Likely PSTN for residential/SOHO users for
  decade
• maybe forced upgrade residential gateway at line
  termination

13
Challenges and Opportunities

• User-visible complexity and reliability
• Will there be telephone numbers?
• Peer-to-peer vs. server-based
• Presence as service enabler
• Spam
• 911
• Service creation

14
User-visible complexity

• Lots of obscure configuration parameters
• trivial mistakes cause silent failures
• NATs and firewalls
• strange failures one-way voice, interrupted
  calls
• Reliability
• user has no clue whether malfunction is due to
• software/phone or operating system
• voice service provider
• Internet service provider
• Callee service provider

15
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
• out-of-box experience not good

16
NAT and VPN troubles

• Unplanned transition from Internet one global
  address space to clouds (realms) of unknown
  scope
• Cant know without help whether directly
  reachable
• Any number of concentric spaces
• There is no universally workable NAT solution
• always problems with inbound calls
• may need to maintain and refresh permanent
  connections to globally routable entity
• may need relay agent for media (TURN)

Internet
?
home NAT
?
?
ISP NAT
17
Server-based vs peer-to-peer

• Server-based
• Cost maintenance, configuration
• Central points of failures
• Managed SIP infrastructure
• Controlled infrastructure (e.g., DNS)
• Peer-to-peer
• Robust no central dependency
• Self organizing, no configuration
• Scalability ?

18
Will there be telephone numbers?

• Yes
• Some locality (shorter)
• Easy to convey orally
• There are lots of them
• No
• Hard to keep when moving
• Becoming 10/12-digit random number
• Already have email address
• Prediction
• slow fade, with ENUM as bridge

1 212 555 1234
DNS NAPTR
sipbob_at_example.com
19
P2P-SIP

• Differences to proprietary Skype architecture
• Robust and efficient lookup using DHT
• Interoperability
• DHT algorithm uses SIP protocol messages
• Hybrid architecture
• First try DNS NAPTR/SRV
• if no SIP server there, then lookup in SIPP2P
• Unlike file-sharing applications
• Data storage, caching, delay, reliability
• Disadvantages
• Lookup delay and security

20
(SIP) unsolicited calls and messages

• Possibly at least as large a problem as spam
• 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

mutual PK authentication (TLS)
home.com
Digest
21
Domain 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

22
Reputation service
David
Carol
has sent IM to
has sent email to
Frank
Emily
is this a spammer?
Bob
Alice
23
Traditional Emergency Calling

• Basic 911 just route to local PSAP
• based on local switch
• no location delivery
• Enhanced 911 route location delivery (90?)
• multiple PSAPs per PSTN switch
• multiple switches per PSAP
• location delivered out-of-band via caller number
• Phase I wireless (70)
• call delivery based on cell tower and face
• no location delivery
• Phase II wireless (30)
• call delivery based on geo address
• geo location delivery to PSAP

24
Core problems

• PSTN approximate routing often works
• same switch
• based on cell tower
• based on caller number
• PSTN relatively few, regionally-limited telecom
  providers (carriers)
• IP carrier bobs-bakery.com
• IP no such approximations (usually)
• application layer (e.g., SIP) has no clue as to
  location
• L1L3 may know about location (at least
  approximately), but dont know about emergency
  calls

25
911 Location-based call routing UA knows its
location
GPS
INVITE sipssos_at_
48 49' N 2 29' E
outbound proxy server
DHCP
48 49' N 2 29' E ? Paris fire department
26
Presence as communication facilitator
27
The 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, doesnt 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
28
Basic 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?
• 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

29
Context-aware communication

• 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

30
Presence and event notification

• Presence special case of event notification
• user Alice is available for communication
• Human users
• 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, )

• Events in multimedia systems
• REFER (call transfer)
• message waiting indication
• conference floor control
• conference membership
• push-to-talk
• system configuration
• General events
• emergency alert (reverse 911)
• industrial sensors (boiler pressure too high)
• business events (more than 20 people waiting for
  service)

31
IETF efforts

• SIP, SIPPING and SIMPLE working groups
• but also XCON (conferencing)
• Define SIP methods PUBLISH, SUBSCRIBE, NOTIFY
• GEOPRIV
• geospatial privacy
• location determination via DHCP
• information delivery via SIP, HTTP,
• privacy policies
• SIMPLE
• architecture for events and rich presence
• configuration (XCAP)
• session-oriented IM (? page mode)
• filtering, rate limiting and authorization

32
Presence data model
calendar
cell
manual
person (presentity) (views)
alice_at_example.com audio, video, text
r42_at_example.com video
services
devices
33
Presence data architecture
presence sources
PUBLISH
raw presence document
privacy filtering
create view (compose)
depends on watcher
XCAP
XCAP
select best source resolve contradictions
composition policy
privacy policy
(not defined yet)
draft-ietf-simple-presence-data-model
34
Presence data architecture
candidate presence document
raw presence document
post-processing composition (merging)
watcher filter
SUBSCRIBE
remove data not of interest
difference to previous notification
final presence document
watcher
NOTIFY
35
RPID rich presence
36
Rich presence time information

• Presence is currently about here and now
• but often only have (recent) past e.g.,
  calendar
• or future
• will be traveling in two hours
• will be back shortly
• allows watcher to plan communication

RPID
from
until
time
timed-status
timed-status
now
37
Privacy rules

• Conditions
• identity, sphere
• time of day
• current location
• identity as 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

38
Example rules document

user_at_example.com

allow

sipvice-uri-scheme mailtorvice-uri-scheme sontrue true
bareovide-user-input


39
User service creation

• Old model
• Killer application
• small set of applications created by experts
• ISDN CLASS application caller ID, call forward,
  speed dial
• New model
• web model end-user and entrepreneur-created
  applications
• based on open platforms (ASP, PHPmysql, )
• often, hosted by content-neutral computation
  network providers
• blogs, RSS, Wiki, podcasting,

40
Service creation

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

41
Program location-based services
42
Location-based service language
NOTIFY
true
false
action
alert
IM
alert
incoming
proximity
message
outgoing
log
conditions
occupancy
actions
events
notify
call
message
time
transfer
subscription
join
43
Automating media interaction service examples

• 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 900AM 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

44
LESS Decision tree

• No loops
• Limited variables
• Not necessarily
• Turing-complete

45
When Tom is online,

46
(No Transcript)
47
Tracking
48
Conclusion

• At inflection point from trials to widespread
  deployment
• legacy will fade except for access
• Risks to competition
• duopoly of access ? tying access to applications
• Risks to usability