lucent-05-03 - Computer Science, Columbia University

Download Report

Transcript lucent-05-03 - Computer Science, Columbia University

SIP in wireless applications
Henning Schulzrinne
Dept. of Computer Science
Columbia University
Overview

New developments




Standardization status
Issues




presence and IM  location-based services
identity management
complexity
integration
spam
Resources
New developments: presence,
location-based services, IM


Old ring-and-hope (or ring-and-annoy) model is obsolete
Presence and event notification model:




human availability
environmental events (alarms)
business events (e.g., machine malfunction)
Mobile devices as prime sources of presence information:

recent device use:




location information (from Phase II 911)


outbound calls
answered calls
unanswered calls
including motion (driving)
longer term: activity information
GEOPRIV and SIMPLE
architectures
rule
maker
DHCP
XCAP
(rules)
target
presentity
caller
publication
interface
PUBLISH
INVITE
location
server
presence
agent
notification
interface
location
recipient
GEOPRIV
watcher
SIP
presence
SUBSCRIBE
NOTIFY
INVITE
callee
SIP
call
The role of presence for call
routing

Two modes:

watcher uses presence
information to select
suitable contacts


PUBLISH
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)
PA
translate
RPID
CPL
NOTIFY
LESS
INVITE
RPID: rich presence
<person> <tuple>
<activities>
<class>
<mood>
<place-is>
<place-type>
<privacy>
<relationship>
<service-class>
<sphere>
<status-icon>
<time-offset>
<user-input>
<device>
New developments: locationbased services




My lab working on language for endsystem services (LESS), including
location-based services
User (or administrator) creates services
Designed to be portable across devices
Java APIs  alternatives with different
trade-offs
SIP is PBX/Centrex ready
centrex-style features
boss/admin features
call waiting/multiple RFC 3261
calls
simultaneous
ringing
RFC 3261
hold
RFC 3264
basic shared lines
dialog/reg. package
transfer
RFC 3515/Replaces
barge-in
Join
conference
RFC 3261/callee caps
“Take”
Replaces
message waiting
message summary
package
Shared-line
“privacy”
dialog package
call forward
RFC 3261
divert to admin
RFC 3261
call park
RFC 3515/Replaces
intercom
URI convention
call pickup
Replaces
auto attendant
RFC 3261/2833
do not disturb
RFC 3261
attendant console
dialog package
call coverage
RFC 3261
night service
RFC 3261
attendant features
from Rohan Mahy’s VON Fall 2003 talk
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)
DHCP (3361)
DHCPv6 (3319)
Configuration
Security & privacy
An eco system, not just a
protocol
configures
XCAP
(config)
SIMPLE
XCON
(conferencing)
policy
RPID
….
initiates
SIP
RTSP
carries
SDP
carries
provide addresses
controls
RTP
STUN
TURN
SIP, SIPPING & SIMPLE –00 drafts
70
60
50
40
SIP
SIPPING
SIMPLE
30
20
10
0
1999
2000
2001
2002
2003
2004
includes draft-ietf-*-00 and draft-personal-*-00
RFC publication
14
12
10
8
SIP
SIPPING
SIMPLE
6
4
2
0
2001
2002
2003
2004
When are we going to get there?

Currently, 14 SIP + 33 SIPPING + 17 SIMPLE
WG Internet Drafts = 64 total


does not count individual drafts likely to be
“promoted” to WG status
The .com consultant linear extrapolation
technique®


pessimist  4 more years if no new work is added
to the queue and we can keep up productivity
optimist  3 more years (lots of drafts are in
almost-done stage)
SIP – 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
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
Issues for SIP in 3GPP/3GPP2

Complexity






14+ messages
PSTN-based worldview
somewhat peculiar notions of scaling
may be able to combine multiple logical elements
Cross-carrier roaming
Integration with non-3G systems

e.g., seamless integration with enterprise SIP systems or
landline service providers



separation of bearer and identity
possibly share same mobile device
Service creation by non-carriers

e.g., vertical applications
3G Architecture (Registration)
mobility management
signaling
serving
CSCF
interrogating
proxy
interrogating
home IM domain
registration signaling (SIP)_
visited IM domain
SIP network architecture
Scalability requirement depends on role
Cybercafe
ISP
IP network
IP phones
ISP
SIP/MGC
SIP/PSTN
Carrier network
GW
GW
MG
IP
PSTN
GW
MG
MG
PBX
PSTN phones
SIP/MGC
T1 PRI/BRI
PSTN
Reliability and scalability
Analysis, simulation and measurement proposal
Rp Mp
a1
Master
Rs M s
s1
 =  R + P
REGISTER+
INVITE, etc
ex

S=3
s2
s3

P=1+1
a2
Slave
B=2
/B
s
b1
Master
b2
Slave
r, p
When is stateless proxy stage needed
What are the optimal values for S,B,P


for required scalability (1-10 million BHCA) and reliability (99.999%)
using commodity hardware
Scaling example
Scaling and reliability



No single point of failure
Geographical redundancy
Can use commodity servers to build 6nines system:


Each cluster with 3 servers with 99%
uptime (3 days/year outage)  99.9999%
availability
Scalable to roughly 10 million BHCA

5ESS: 4 m BHCA
Software Resources

Lots of commercial and open-source
components, e.g.,

proxies


application servers


Ubiquity, Broadsoft
SIP stacks


iptel.org (OSS), sipd, …
reSIProcate (OSS), Hughes, RADvision, various Java
stacks
SIP test tools

sipsak, SIP Forum test suite (SFTF)
http://www.cs.columbia.edu/sip/implementations.html
Why is Skype successful?



All the advantages of a proprietary protocol
Peer-to-peer coincidental
Good out-of-box experience


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


Software vendor = service provider
use TCP if necessary
use port 80
Did encryption from the very beginning
Kazaa marketing vehicle