collaboration - Columbia University

advertisement
SIP for Collaboration
Henning Schulzrinne
Columbia University
Dept. of Computer Science
June 2005
SIP for collaboration
1
Overview



Evolution from service to protocol to
eco-system
Quick intro to SIP
SIP foundations: sessions, messages,
events
June 2005
SIP for collaboration
2
Philosophy transition
One
computer/phone,
many users
mainframe era
home phone
party line
PC era
cell phone era
One
computer/phone,
one user
Many
computers/phones,
one user
many identifiers
Many
computers/phones,
one user
one identifier
~ ubiquitous computing
~ converged ubiquitous
computing &
communication
right place (device),
right time,
right media
anywhere,
any time
any media
June 2005
SIP for collaboration
3
Evolution of VoIP
“how can I make it
stop ringing?”
long-distance calling,
ca. 1930
“amazing – the
phone rings”
1996-2000
June 2005
“does it do
call transfer?”
going beyond
the black phone
catching up
with the digital PBX
2000-2003
SIP for collaboration
20044
Collaboration in transition
inter-organization
multiple
technology
generations
diverse end points
intra-organization;
small number of
systems (meeting
rooms)
standards-based
solutions
proprietary (singlevendor) systems
June 2005
SIP for collaboration
5
Internet services – the missing
entry
Service/delivery
synchronous
asynchronous
push
instant messaging
presence
event notification
session setup
media-on-demand
messaging
pull
data retrieval
file download
remote procedure call
peer-to-peer file sharing
June 2005
SIP for collaboration
6
Filling in the protocol gap
Service/delivery
synchronous
asynchronous
push
SIP
RTSP, RTP
SMTP
pull
HTTP
ftp
SunRPC, Corba, SOAP
(not yet standardized)
June 2005
SIP for collaboration
7
SIP as service enabler

SIP = rendezvous protocol


lets users find each other by
only knowing a permanent
identifier
Mobility enabler:

personal mobility


terminal mobility


one terminal, multiple IP
addresses
session mobility


one person, multiple terminals
one user, multiple terminals in
sequence or in parallel
service mobility

June 2005
services move with user
SIP for collaboration
8
A constellation of SIP RFCs
Non-adjacent (3327)
Symmetric resp. (3581)
Service route (3608)
User agent caps (3840)
Caller prefs (3841)
Request routing
Resource mgt. (3312)
SIP (3261)
DNS for SIP (3263)
Events (3265)
REFER (3515)
ISUP (3204)
sipfrag (3240)
Content types
Reliable prov. (3262)
INFO (2976)
UPDATE (3311)
Reason (3326)
Mostly PSTN
Core
Digest AKA (3310)
Privacy (3323)
P-Asserted (3325)
Agreement (3329)
Media auth. (3313)
AES (3853)
SIP for collaboration
June 2005
Security & privacy
DHCP (3361)
DHCPv6 (3319)
Configuration
9
An eco system, not just a
protocol
configures
XCAP
(config)
SIMPLE
XCON
(conferencing)
policy
RPID
….
initiates
SIP
RTSP
SDP
carries
provide addresses
controls
STUN
TURN
RTP
June 2005
carries
SIP for collaboration
10
SIP trapezoid
outbound proxy
destination proxy
(identified by SIP URI domain)
1st request
SIP trapezoid
2nd, 3rd, … request
a@foo.com:
128.59.16.1
registrar
voice traffic
RTP
June 2005
SIP for collaboration
11
message body
header fields
request line
SIP message format
response
request
INVITE sip:bob@there.com SIP/2.0
SIP/2.0 200 OK
Via: SIP/2.0/UDP here.com:5060
From: Alice <sip:alice@here.com>
To: Bob <sip:bob@there.com>
Call-ID: 1234@here.com
CSeq: 1 INVITE
Subject: just testing
Contact: sip:alice@pc.here.com
Content-Type: application/sdp
Content-Length: 147
Via: SIP/2.0/UDP here.com:5060
From: Alice <sip:alice@here.com>
To: Bob <sip:bob@there.com>
Call-ID: 1234@here.com
CSeq: 1 INVITE
Subject: just testing
Contact: sip:alice@pc.here.com
Content-Type: application/sdp
Content-Length: 134
v=0
o=alice 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=bob 2890844527 2890844527 IN IP4 there.com
s=Session SDP
c=IN IP4 110.111.112.113
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
SDP
June 2005
SIP for collaboration
12
SIP design objectives

new features and services



not a PSTN replacement





clients can be smart or dumb (terminal adapter)
mobile or stationary
hardware or software
client multiplicity


not just SS7-over-IP
even similar services use different models (e.g., call transfer)
client heterogeneity


support features not available in PSTN
e.g., presence and IM, session mobility
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
SIP for collaboration
13
SIP architectural principles (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


component-based
design



call fails only if endpoints
fail
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
SIP for collaboration
14
SIP architectural principles (2)

designed for the (large)
Internet




does not assume
particular network
topology
congestion-controlled
deals with packet loss
uses core Internet
services:





generality over
efficiency
DNS for load balancing
DHCP for configuration
S/MIME for e2e security
TLS for channel security






June 2005
SIP for collaboration
focuses on algorithm
efficiency, not constantfactor encoding efficiency
“efficiency penalty is
temporary, generality is
permanent”
text encoding
extensibility
use shim layer for
compression where
needed
allow splitting of
functionality for scaling
15
SIP architectural principles (3)

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)


facilitates mobility


without constraining service delivery (1s matters)
avoid “hair pinning”, “tromboning”
facilitates vertical split between ISP and VSP
June 2005
SIP for collaboration
16
SIP division of labor
proxy
B2BUA
UA
State
stateless
transactionstateful
call stateful
call stateful
Headers
inspect
insert
modify (rarely)
inspect
insert
modify
inspect
reflect
Bodies
ignore
some inspect
inspect
insert
modify
inspect
Fork
yes
separate call legs
no
Media
no
maybe
yes
Services
rendezvous
call routing
call stateful
media-related
June 2005
SIP for collaboration
17
Major SIP users

VoIP service providers



Vonage, 8x8, sipgate.de, fwd,
…
Internet Multimedia
Subsystem (IMS) in 3GPP
PacketCable


interconnection
still PSTN
all major cable providers in
planning
Enterprise

all major enterprise IP-PBX
vendors
June 2005
SIP for collaboration
18
SIP devices and software
June 2005
SIP for collaboration
19
Classical “silo” model
+1 201 555 1234
im:losr32@aol.com
h323:foo.example.com
+1 917 555 3210
June 2005
home phone, work phone, mobile
phone, home email, work email,
fax, gmail, AOL, Yahoo, MSN,
SMS, sametime, softphone URL,
personal 1-800 audio conference,
schedule conference, blog,
website (C. Jennings)
SIP for collaboration
20
The SIP (converged) model
audio
video
real-time text
MSRP
app sharing
(text) messages
device control
shared web browsing
sessions
messages
INVITE
BYE
MESSAGE
DO
call events (transfer)
message waiting
conference events
basic & rich presence
calendar data
file updates
events
PUBLISH
SUBSCRIBE
NOTIFY
sip:alice@example.com
mobility
load balancing & redundancy
authentication, integrity
NAT traversal
June 2005
SIP for collaboration
21
SIP identity model

Old models:




no domain authentication  spam,
phishing
single domain login (e.g., AOL)  no
cross-domain authentication
PKI with user certificates  expensive, not
readily portable
Single SIP identity (address-of-record =
AOR) simplifies identity assertion and
management
June 2005
SIP for collaboration
22
SIP identity
digest
authentic
ation
example.com
foo.com
INVITE
Challenge
INVITE
1. Alice calls
Bob
2. Outbound proxy verifies
that alice@example.com is
calling
June 2005
INVITE
(signed)
3. This assertion is
signed with the
example.com
certificate from a
well- known
certificate authority
SIP for collaboration
INVITE
4. The foo.com proxy
receives this and checks
that the signature on the
assertion is validC. Jennings
23
Presence & communications

Presence  facilitate
communications

Communications




Presence
availability
activities
communication privacy
choice of media
Communications 
derive presence


“on the phone”
typing/composing
C. Jennings
June 2005
SIP for collaboration
24
Presence data model
person
“calendar”
“cell”
“manual”
(presentity)
(views)
alice@example.com
audio, video, text
services
r42@example.com
video
devices
June 2005
SIP for collaboration
25
Presence data architecture
presence sources
PUBLISH
create
view
(compose)
raw
presence
document
XCAP
select best source
resolve contradictions
depends on watcher
XCAP
privacy
policy
composition
policy
(not defined yet)
June 2005
privacy
filtering
draft-ietf-simple-presence-data-model
SIP for collaboration
26
Presence data architecture
candidate
presence
document
remove data not of
interest
watcher
June 2005
watcher
filter
raw
presence
document
post-processing
composition
(merging)
SUBSCRIBE
difference
to previous notification
NOTIFY
SIP for collaboration
final
presence
document
27
Rich presence extensions
<person> <tuple>
<device>
<activities>
<class>
<mood>
derived from
sensors,
human
input,
calendars
<place-is>
<place-type>
<privacy>
<relationship>
<service-class>
<sphere>
<status-icon>
<time-offset>
<user-input>
June 2005
SIP for collaboration
28
Service creation



Tailor a shared infrastructure to individual users
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
June 2005
SIP for collaboration
CPL
29
XCON System
Logical XCON Server
TEMPLATE
Of the SYSTEM:
TEMPLATE Policy:
•Of TYPE RULES
•Pre-configured
•Initial/Default values
RESERVATION
RESERVATION Policy:
Of the INSTANCE:
•Of TYPE RULES
•Of TYPE CONFERENCE-INFO
STATE
Of the CURRENT INSTANCE:
CURRENT Policy:
•Of TYPE RULES
CPCP
Server
CPCP
CPCP
Client
Logical
June
2005
•Of TYPE CONFERENCE-INFO
CCCP
Server
CCCP
CCCP
Client
XCON Client
Focus
Conf Event
Notification
Server
Floor
Control
Server
SIP/
PSTN/
SIP NOTIFY/
H.323
BFCP
Etc.
T.120/
Etc.
Floor
Call
Notification
Control
Signaling
Client
Client
Client
SIP for collaboration
30
Conclusion


Avoid silo model
Collaboration needs sessions, messages and
events



plus stored context and asynchronous
collaboration  Wikis, blog, conference
recordings, structured data stores, shared
calendars, …
SIP addresses multi-modal communication
needs
Need more than basic presence

automatically derived, not user input
June 2005
SIP for collaboration
31
Download