SIP for Collaboration

1
SIP for Collaboration

• Henning Schulzrinne
• Columbia University
• Dept. of Computer Science

2
Overview

• Evolution from service to protocol to eco-system
• Quick intro to SIP
• SIP foundations sessions, messages, events

3
Philosophy transition
One computer/phone, many users
PC era cell phone era
One computer/phone, one user
mainframe era home phone party line
Many computers/phones, one user many identifiers
Many computers/phones, one user one identifier
ubiquitous computing
converged ubiquitous computing communication
anywhere, any time any media
right place (device), right time, right media
4
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-
5
Collaboration in transition
inter-organization multiple technology
generations diverse end points
intra-organization small number of systems
(meeting rooms)
standards-based solutions
proprietary (single-vendor) systems
6
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
7
Filling in the protocol gap
Service/delivery synchronous asynchronous
push SIP RTSP, RTP SMTP
pull HTTP ftp SunRPC, Corba, SOAP (not yet standardized)
8
SIP as service enabler

• SIP rendezvous protocol
• lets users find each other by only knowing a
  permanent identifier
• Mobility enabler
• personal mobility
• one person, multiple terminals
• terminal mobility
• one terminal, multiple IP addresses
• session mobility
• one user, multiple terminals in sequence or in
  parallel
• service mobility
• services move with user

9
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) Reliable prov. (3262) INFO
(2976) UPDATE (3311) Reason (3326)
SIP (3261) DNS for SIP (3263) Events (3265) REFER
(3515)
ISUP (3204) sipfrag (3240)
Mostly PSTN
Core
Content types
Digest AKA (3310) Privacy (3323) P-Asserted
(3325) Agreement (3329) Media auth. (3313) AES
(3853)
DHCP (3361) DHCPv6 (3319)
Configuration
Security privacy
10
An eco system, not just a protocol
configures
XCAP (config)
SIMPLE policy RPID .
XCON (conferencing)
initiates
carries
SIP
RTSP
SDP
carries
controls
provide addresses
STUN TURN
RTP
11
SIP trapezoid
destination proxy (identified by SIP URI domain)
outbound proxy
1st request
SIP trapezoid
2nd, 3rd, request
a_at_foo.com 128.59.16.1
registrar
voice traffic RTP
12
SIP message format
SDP
13
SIP 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
14
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
• 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
15
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
• 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

16
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)
• without constraining service delivery (1s
  matters)
• facilitates mobility
• avoid hair pinning, tromboning
• facilitates vertical split between ISP and VSP

17
SIP division of labor
proxy B2BUA UA
State stateless transaction-stateful 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
18
Major SIP users
interconnection still PSTN

• VoIP service providers
• Vonage, 8x8, sipgate.de, fwd,
• Internet Multimedia Subsystem (IMS) in 3GPP
• PacketCable
• all major cable providers in planning
• Enterprise
• all major enterprise IP-PBX vendors

19
SIP devices and software
20
Classical silo model
1 201 555 1234
imlosr32_at_aol.com
h323foo.example.com
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)
1 917 555 3210
21
The SIP (converged) model
audio video real-time text MSRP app sharing
(text) messages device control shared web browsing
call events (transfer) message waiting conference
events basic rich presence calendar data file
updates
sessions
messages
events
INVITE BYE
MESSAGE DO
PUBLISH SUBSCRIBE NOTIFY
sipalice_at_example.com mobility load balancing
redundancy authentication, integrity NAT traversal
22
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

23
SIP identity
example.com
digest authentication
foo.com
INVITE
Challenge
INVITE
1. Alice calls Bob
INVITE (signed)
INVITE
2. Outbound proxy verifies that alice_at_example.com
is calling
3. This assertion is signed with the example.com
certificate from a well- known certificate
authority
4. The foo.com proxy receives this and checks
that the signature on the assertion is valid
C. Jennings
24
Presence communications

• Presence ? facilitate communications
• availability
• activities
• communication privacy
• choice of media
• Communications ? derive presence
• on the phone
• typing/composing

Communications
Presence
C. Jennings
25
Presence data model
calendar
cell
manual
person (presentity) (views)
alice_at_example.com audio, video, text
r42_at_example.com video
services
devices
26
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
27
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
28
Rich presence extensions
ltpersongt lttuplegt ltdevicegt
ltactivitiesgt
ltclassgt
ltmoodgt
ltplace-isgt
ltplace-typegt
ltprivacygt
ltrelationshipgt
ltservice-classgt
ltspheregt
ltstatus-icongt
lttime-offsetgt
ltuser-inputgt
derived from sensors, human input, calendars
29
Service creation

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

programmer, carrier end user
network servers SIP servlets, sip-cgi CPL
end system VoiceXML VoiceXML (voice), LESS
30
XCON System
31
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