Transcript Endpoint vs. Network VoIP services

Endpoint vs. Network
Services
Henning Schulzrinne
(with Xiaotao Wu)
Columbia University
Siemens ICN Innovation Symposium
Munich – December 16, 2003
Adding value through applications

What are services?






will focus on VoIP
difference most obvious
applies also to video-on-demand
Where can services reside?
Who can create services?
Preventing user service creation
Old service model

small number of well-defined
(named) services, e.g.,
CLASS










call return
caller ID
calling number blocking
call trace
repeat dialing
call block
…
widely used
charged by the month
high initial cost (e.g., for
switch generic)

but pure profit once
amortized

stimulus interface


end system does not know
service
almost no user customization


partially caused by poor UI
hardware model:




push button to get feature
expectation of “killer service”
“content is king”
vertical integration
New service model

Provide protocol and API building blocks


(Mostly) open interfaces




service ingredients
protocol specifications
API specifications
common OS platforms (Symbian, Java,
WinCE/Win32, Palm, Linux)
Works best if very narrow interfaces


IP, HTTP
Posix API
New service model

Don’t expect a single killer service or application



except at large scale: web, email, IM, VoIP (eventually…) 
don’t expect the carrier to come up with one
users create their own services


vertical niche applications




requires domain knowledge
encourages experimentation


users not just consumers
risk is borne by those needing service the most
no infrastructure changes required
“connectivity is king”
slicing of service provision
Aside: Internet services

Push services

content delivery


inter-machine
communications



RPC (Corba, web
services, …)
games
asynchronous messaging


streaming media
email
synchronous messaging


SMS, IM
general event delivery
(SIP)

Pull services

content retrieval



ftp  gopher  web
peer-to-peer
IMAP, POP
IP “hourglass”
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP
ethernet PPP…
CSMA async sonet...
copper fiber radio...
Steve Deering,
IETF Aug. 2001
The real Internet hourglass
(slightly simplified)
p2p (port 80)
web
web services
HTTP
TCP
IP
Ethernet
VoIP: What are services?

Call routing services  subset of CLASS services

name/number translation




call forward busy/no answer
call forward conditional (time-of-day, call center)
Directory services

white and yellow pages


global and corporate
Media services




terminal, user mobility
media encoding translation for bandwidth
media type conversion: language, speech-to-text
media combining: conferencing
Identity services



identity assertion (“Columbia attests that Joe Smith, an employee, is calling”)
identity hiding (“[email protected] is calling”)
configuration repository


media preferences
address book and speed dial
PSTN vs. Internet Telephony
PSTN
Internet Telephony
end system
Number of lines
or pending calls
is virtually unlimited
Single line,
12 buttons and
hook flash to signal
More (per-user)
processing power than
most network servers
PSTN vs. Internet Telephony
PSTN:
Signaling & Media
Signaling & Media
can be far away
from either user
Internet
Telephone:
Signaling
Signaling
Media
PSTN vs. VoIP

PSTN: only carriers can get full
signaling functionality (SS7)


UNI vs. NNI signaling
VoIP: same signaling, same
functionality
Network vs. end system services

Really two meanings:


services implemented in user agent (instead of proxy)
services implemented in server run by end user (instead of
by carrier or equipment vendor) 



Variation on old Centrex vs. PBX argument


business
residential
except that media routing no longer an issue
Often, services require or can use both:

e.g., the history of speed dial



CLASS service: translation in CO
(semi)intelligent end systems: locally, possibly with hotsync to
PC
intelligent end system, but network-synchronized
End system vs. network tradeoffs
Criteria
network
end system
availability
high (backup systems &
power)
lower, but maintain local
services during network outage
bandwidth
high
lower ( large centralized
conferences)
addressing
global IPv4 addresses
often NATs  can’t run servers
IPv6 may fix
security
professional maintenance
more visible target
trust third party with
content
update tracking
lower disruption
end-to-end encryption
user
control
protection of shared resources 
limit user programmability
full control
processing
high aggregate,
lower per-user
low on residential GW,
unbounded on PCs
End system vs. Network services
– the easier cases

Network services

PSTN gateway



Backup services



multiplexing gain
SS7 access
e.g., no answer from
enterprise due to failure
no permanent
connectivity for
residential users
Large-scale conferences
for residential users

bandwidth availability

End system/user
services



media processing
distinctive ringing
programmable services


user control
but: security
maintenance
Network service: call routing
services


Outsourcing allows temporarily
disconnected end users
Staged service:
carrier proxy
user proxy
basic call
routing
personal
preferences
Peer-to-peer call routing
H(aor) = node
REGISTER
supernode
Network service: identity and
trust management

Identity assertion (notary) services





Anonymity services


best done by larger organization
server certificates
name recognition
recourse
needs to have large user population to provide
effective hiding
Portable services

high availability and universal reachability
Internet service ecology



False either/or choice
See email and web for
precedent
carrier-provided (ISPs)






basic transport service
name portability issues

provide and manage own
infrastructure
only purchase “raw bits”


albeit actively
discouraged
hosting companies =
bandwidth + service

enterprise

home user
shared and dedicated
facilities
but not an ISP in the
traditional sense
service-only companies


web mail
mail forwarding
The vanishing phone company

Old model:



explicit, user-visible signaling  dialing, ringing
small number of phone lines, (mostly) each with one E.164
identifier
New model:

session initiation from




IM session  no dialing and ringing
game session  proximity triggers conversation
event based  connect if event occurs
no notion of lines


teenager (or telemarketer…) may have dozens of chat windows open
some identifiers may make no PSTN calls at all


from monthly service  calling card-like
any number of identifiers

one per wire or device  multiple per person (role-based)
How to prevent user service
creation

The PTT approach




stimulus signaling only
force congruent media
and signaling path
limit vendor choices for
end systems

hidden APIs
baroque interfaces,
subject to change




require new content
restrictive technology
licensing



cell phones not
programmable
restrict to certain cell
phone models (US)
air interface regulation
and licensing
The ISP approach

The WAP approach

The cell phone
approach

The Microsoft approach



port blocking
NATs
restrict upstream
bandwidth
The lawyer approach

patents and trade secrets
Conclusions

VoIP enables, but does not force, end point services


Move service location decision to end user, with
trade-offs in






separation of data and control planes
cost
control
availability
functionality
technical sophistication needed
Carriers and vendors have vital role:




service creation environments
reliable network service
trust and identity
service hosting
Annex: technical background
on service creation
Service location examples
Service
End system
Network (proxy)
Network with media
(UA)
Distinctive ringing
Yes
Can assist
Can assist
Visual call id
Yes
Can assist
Can assist
Call waiting
Yes
No
Yes(*)
CF busy
Yes
Yes(*)
Yes(*)
CF no answer
Yes
Yes
Yes
CF no device
No
Yes
Yes
Location hiding
No
Yes
Yes
Transfer
Yes
No
No
Conference bridge
Yes
No
Yes
Gateway to PSTN
No
No
Yes
Firewall control
No
No
Yes
Voicemail
Yes
No
Yes
(*) = with information provided by end system
Example: VoIP embedded in VR
Network service: service mobility

Network server acts as repository for
user cross-device configuration





address book
caller preferences (media, carrier, …)
authentication information
Devices can update user configuration
Automatically propagates to all other
devices at next opportunity

not just explicit sync’ing (Palm-style)
Example: user-adaptive device
configuration
802.11 signal
strength  location
SLP
“all devices that are in the building”
RFC 3082?
device
controller
REGISTER
To: 815cepsr
Contact: alice@cs
PA
HTTP
SUBSCRIBE
to each room
1. discover room URI
2. REGISTER as contact for room URI
tftp
SIP
SUBSCRIBE to configuration
for users currently in rooms
room 815
Service architecture
Programming language model
Service Logic
Programming
Interface
Requests
Requests
SIP Server Function
Responses
Responses
Service creation

Few common service creation styles


extend base language with domain APIs (OO  Java)
create domain-specific or domain-tuned language



C-like:



specific: CPL, voiceXML
tuned: PHP
programming: C  C++  Java  C#
web: PHP (with built-in web abstractions)
For auto-generation (“wizard”):



programming: spread sheets
web: HTML, XML
VoIP, IM, presence: CPL, LESS, voiceXML
Service creation: encouraging reuse



Web: client-side code available
Encourages learning and imitation
PHP, Perl, ASP, …: lots of common libraries
Example: Yahoo calendar
code
Service creation



Promise of faster service creation
traditionally, only vendors (and sometimes carriers)
learn from web models
end user
network
servers
programmer,
carrier
SIP servlets,
sip-cgi
end system
VoiceXML
VoiceXML (voice),
LESS
CPL
Service creation – a comparison
API
servlets
sip-cgi
CPL
languageindependent
no
Java only
yes
own
secure
no
mostly
can be
yes
end user
service
creation
no
yes
power users yes
GUI tools
no
no
no
yes
Multimedia
some
yes
yes
yes
call creation
yes
no
no
no
Example: LESS service generation
Columbia sipc SIP user agent
LESS service creation
CPL example: anonymous call
screening
<cpl>
<incoming>
<address-switch field="origin"
subfield="user">
<address is="anonymous">
<reject status="reject"
reason="I don't accept anonymous calls"
/>
</address>
</address-switch>
</incoming>
</cpl>
Feature interaction


Undesirable interaction of services
Some causes avoidable in Internet
environment:



lack of expressiveness (“what’s the # do here?”)
no prioritization (“call blocking precedes call
forwarding”)
Some issues harder:



distribution of services
routing loops
how to anticipate problems  service testing
The impact of regulations

Phone (service) companies are not required any more, but may be
useful



don’t have (many) email companies, either
Regulation should not bias technical and business decisions on in-house
vs. out-sourcing
Avoid conflicts of interest for ISPs that provide phone service:



no port blocking except by user request
traffic neutrality  provide differentiated services to all
provide externally routable addresses



distinguish residential / business via application-neutral measures, e.g.,
bandwidth or availability
Goal:



address shortage excuse  NAT  difficult to have inbound connections
ensure “transparent Internet” + service providers for added value
encourages service innovation
encourages service competition