DoCoMo Eurolabs Munich Multimedia Standardization – A Snapshot Henning Schulzrinne Dept. of...
-
date post
21-Dec-2015 -
Category
Documents
-
view
218 -
download
0
Transcript of DoCoMo Eurolabs Munich Multimedia Standardization – A Snapshot Henning Schulzrinne Dept. of...
DoCoMo Eurolabs Munich
Multimedia Standardization – A
Snapshot
Henning Schulzrinne
Dept. of Computer Science
Columbia University
DoCoMo Eurolabs Munich
Overview
Quick overview of Columbia IRT Lab IETF standardization effort Multimedia control challenges
DoCoMo Eurolabs Munich
Networking research at Columbia University Columbia Networking Research Center spans Electrical Engineering & Computer Science
Department 15 faculty – one of the largest networking
research groups in the US about 40 PhD students spanning optical networks and wireless channels
to operating systems, security and applications theory (performance analysis) to systems
(software, protocols)
Keren Bergman
Andrew Campbell
Ed Coffman
Predrag Jelenkovic
Angelos Keromytis
Aurel Lazar
Nick Maxemchuk
Vishal Misra
Jason Nieh
Dan Rubenstein
Henning Schulzrinne
Xiaodong Wang
Yechiam Yemini
DoCoMo Eurolabs Munich
Overall IRT lab goals Reliable, flexible and programmable communication
infrastructure for Internet-based collaboration applications
Systematic evaluation by analysis and simulation Demonstrate capability via prototypes Contribute protocols to standardization Convert prototypes into products and open-source
software Train students at all levels in current Internet
research and engineering
DoCoMo Eurolabs Munich
IRT research topics Internet telephony and
multimedia CINEMA – VoIP/multimedia
and collaboration system QoS measurements network application reliability APIs for SIP IM and presence
systems ubiquitous computing using
SIP emergency services (“911”) SIP security
non-PKI-based assertions service creation languages
CPL LESS
Mobile and wireless systems 802.11 handoff acceleration 802.11 VoIP performance
improvements personal, service and session
mobility Peer-to-peer messaging
7DS Service and event discovery
(GloServ) Generic signaling protocols
(GIMPS) for QoS, NAT/FW, … Autonomic computing
service discovery mSLP automated server pooling
DotSlash
DoCoMo Eurolabs Munich
IETF Multimedia Standardization Largest application-related
effort Working groups:
NSIS generic data plane signaling
protocol, including QoS AVT
mainly codec payload formats TFRC for multimedia
IPTEL finishing RFC 2806bis (tel
URI) MMUSIC
RTSP revision media guide SDPng (eventually)
SIMPLE XCAP auth. policy for presence rich presence filtering
GEOPRIV auth. policy for location PIDF-LO DHCP for location
SPEECHSC text-to-speech conrol
DoCoMo Eurolabs Munich
SIP and SIPPING SIPPING = requirements,
examples, data service examples MWI conferences QSIG configuration session policy early media e2m security transcoding emergency calling trait-based authorization
SIP = protocol standardization and extensions session timer Replaces header (session
replacement) Referred-By Join header AIB compression communication resource
priority GRUU request history
DoCoMo Eurolabs Munich
Standardization process
initialidea
draft-somebody-wg-idea-00
draft-ietf-wg-idea-00
-01 -02-xx
WGlast call
IESGcomments
IETF last call
RFC
1-5 yrs
DoCoMo Eurolabs Munich
Major RFCs published recently Third-party call control (RFC
3275) allows non-media entity to
control sessions Event package for
registrations (RFC 3680) Security mechanism
agreement (RFC 3329) negotiate algorithms with
next hop Requirements for resource
priority (RFC 3487) prioritization of calls in
military networks and emergencies
REFER method (RFC 3515) call transfer
DHCPv6 for SIP (RFC 3319) automatic outbound
proxy configuration Proxy-to-proxy extensions
for PacketCable (RFC 3603)
Symmetric response routing (RFC 3581) improved NAT interaction
DoCoMo Eurolabs Munich
Major RFCs published Service route discovery (RFC
3806) REGISTER returns “preloaded
route” to be used by UA for services
SIP and SDP compression (RFC 3485/3486) compress SIP headers and
body via dynamic dictionary Call flows (RFC 3665/3666)
explain behavior by example useful for testing common
cases not a spec replacement
Summary: except for REFER, mostly relevant to subsets of SIP developer community PacketCable 3G Military, emergency
response
DoCoMo Eurolabs Munich
RFCs in the pipeline
Ready & done, but typically waiting for normative references
Examples: message waiting indication caller preferences CPL user agent capabilities ENUM for SIP H.323 interworking requirements presence – events, CPIM, watcher info, …
DoCoMo Eurolabs Munich
When are we going to get there?
In 2003, 6 SIP + 2 SIPPING RFCs published In 2002, 14 SIP + 4 SIPPING RFCs Currently, 20 SIP + 24 SIPPING + 22 SIMPLE WG Internet
Drafts does not count individual drafts likely to be “promoted” to WG
status The .com consultant linear extrapolation technique®
pessimist 8.5 more years if no new work is added to the queue
optimist 4 more years
DoCoMo Eurolabs Munich
SIP is PBX/Centrex readycall waiting/multiple calls
RFC 3261
hold RFC 3264
transfer RFC 3515/Replaces
conference RFC 3261/callee caps
message waiting message summary package
call forward RFC 3261
call park RFC 3515/Replaces
call pickup Replaces
do not disturb RFC 3261
call coverage RFC 3261
from Rohan Mahy’s VON Fall 2003 talk
simultaneous ringing RFC 3261
basic shared lines dialog/reg. package
barge-in Join
“Take” Replaces
Shared-line “privacy” dialog package
divert to admin RFC 3261
intercom URI convention
auto attendant RFC 3261/2833
attendant console dialog package
night service RFC 3261
centr
ex-s
tyle
featu
res
boss/admin features
attendant features
DoCoMo Eurolabs Munich
SIP, SIPPING & SIMPLE –00 drafts
0
10
20
30
40
50
60
70
1999 2000 2001 2002 2003
SIPSIPPINGSIMPLE
includes draft-ietf-*-00 and draft-personal-*-00
DoCoMo Eurolabs Munich
Competition Old competition: H.323 no longer
active development but still in wide use (including
CallManager) New competition:
IAX Skype Cisco SCCP (Skinny) ~ MGCP Jabber (IM)
Usually, dominated by single company faster (fewer “what is a tuple
discussions”…) concentrated company resources
usually make-or-break for company H.323 = Microsoft NetMeeting compatible
tend to favor efficiency over generality and protocol niceties (internationalization, congestion control, XML, …)
had NAT story from very beginning Skype NAT solution appears to be
technically similar to STUN
Limited focus, e.g.,: silo model
audio only (IAX) for Jabber, classical IM/presence
focused no capability negotiation no proxy support limited security support limited services
call forwarding, transfer, early media, …
Unpublished protocols “trust us, we wouldn’t do anything stupid,
would we?” hard to get protocol eco system
variety of end systems diagnostics and protocol
analyzers
DoCoMo Eurolabs Munich
SIP – a bi-cultural protocol
• overlap dialing• 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
DoCoMo Eurolabs Munich
SIP spam Threats:
unsolicited (multimedia) calls presence authorization
requests IMs (“spim”)
Could be worse than email and phone telemarketing: immediate interruption “the death of distance”
aluminum siding at 2 am, direct from China
do-not-call list and CAN-SPAM may not apply
Not a SIP problem – Applies to other systems as well
Spam mechanisms have limited applicability can’t do content analysis
(Bayesian filtering) even for IM attention
grabbed after first “Hello” message
human reachability measures interfere with real-time
nature
DoCoMo Eurolabs Munich
SIP spam solutions – some options Failure of content-based identity-based global, personal PKI tried and failed
economics, liability to scale, must be cheap and easy to get
cheap and easy for spammers, too hard to install on end systems
But domain-level authentication works TLS certificates orders of magnitude fewer servers than
phones Other server ID alternatives:
DNS certificate server SPF SRV records for domain servers
Increase value of identity: social networks bonding and warranties identity policy (“we card”) verifiable location information
stranded relative from payphone vs. former rebel leader from Namibia
outbound proxyexample.com
From: [email protected]
shared secret(Digest) verify
example.com
DoCoMo Eurolabs Munich
Multimedia communications problems
Old problems and approaches: efficient codecs ubiquitous reachability audio/video
synchronization network-layer mobility quality-of-service APIs and middleware
New problems: controlled reachability
spam cell phone ringing in
lecture service availability information privacy service & personal mobility service creation by non-
experts
DoCoMo Eurolabs Munich
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:
time CPL
capabilities caller preferences
location location-based call routing
location events
activity/availability “rich” presence
sensor data (mood, bio) not yet, but similar in many aspects to location data
DoCoMo Eurolabs Munich
Multimedia communications problems
Old problems and approaches: efficient codecs ubiquitous reachability audio/video
synchronization network-layer mobility quality-of-service APIs and middleware
New problems: controlled reachability
spam cell phone ringing in
lecture service availability information privacy service & personal mobility service creation by non-
experts
DoCoMo Eurolabs Munich
GEOPRIV and SIMPLE architectures
targetlocationserver
locationrecipient
rulemaker
presentity
caller
presenceagent
watcher
callee
GEOPRIV
SIPpresence
SIPcall
PUBLISHNOTIFY
SUBSCRIBE
INVITE
publicationinterface
notificationinterface
ruleinterface
INVITE
DoCoMo Eurolabs Munich
RPIDS: rich presence data Basic IETF presence (CPIM) only gives you
contact information (SIP, tel URI) priority “open” or “closed”
Want to use presence to guide communications
PA
watcher
PUA watcher
watcher
PUBLISH
NOTIFY
everything
"vague"
CPL
INVITE
<activity><place-type><privacy><mood><sphere>
DoCoMo Eurolabs Munich
Policy relationships
geopriv-specific presence-specific
common policy
RPID CIPID
future
DoCoMo Eurolabs Munich
Presence policy
subscriptionpolicy
event generatorpolicy
subscriberfilter
rate limiter
change to previousnotification?
for eachwatcher
subscriber (watcher)
SUBSCRIBE
NOTIFY
DoCoMo Eurolabs Munich
Policy rules
There is no sharp geospatial boundary Presence contains other sensitive data (activity,
icons, …) and others may be added Example: future extensions to personal medical data
“only my cardiologist may see heart rate, but notify everybody in building if heart rate = 0”
Thus, generic policies are necessary
DoCoMo Eurolabs Munich
Presence/Event notification Three places for policy enforcement
subscription binary only policy, no geo information subscriber may provide filter could reject based on
filter (“sorry, you only get county-level information”) greatly improves scaling since no event-level checks needed
notification content filtering, suppression only policy, no geo information
third-party notification e.g., event aggregator can convert models: gateway subscribes to event
source, distributes by email both policy and geo data
DoCoMo Eurolabs Munich
Processing models
Sequential model: for each subscriber, apply rules to new data doesn’t scale well to large groups
Relational database model: re-use indexing and other query optimizations well-defined query and matching semantics e.g., mySQL and PostGres have geo extensions At time of subscription:
SELECT address FROM policies WHERE person=$subscriber (AND now() between(starttime,endtime) OR starttime is null) AND (a3=$a3 or a3 is null) …
DoCoMo Eurolabs Munich
Location filtering language SIP presence information will be updated using REGISTER and UPDATE Need to constrain
who is allowed to see what detail presentity privacy who wants to see what detail
how often what granularity of change
Proposal to allow SUBSCRIBE to include frequency limitation Working on CPL-like language invoked (logically) at publication time
classes of users, e.g., based on entry in my address book classes get mapped to restriction
“12 bits of long/lat resolution, 6 bits of altitude resolution, 0 bits of velocity” “time zone only”, “category only”
watchers can then add filters that restrict the delivery: location difference > threshold entering or leaving certain area entering or leaving category or behavioral type
DoCoMo Eurolabs Munich
Service creation
programmer, carrier
end user
network servers SIP servlets, sip-cgi
CPL
end system VoiceXML
SMIL
VoiceXML (voice),
LESS
Tailor a shared infrastructure to individual users traditionally, only vendors (and sometimes carriers) learn from web models