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


Overview

Quick overview of Columbia IRT Lab IETF standardization effort Multimedia control challenges


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


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


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


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


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


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


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


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


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, …


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


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


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


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


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


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


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


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


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


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


GEOPRIV and SIMPLE architectures

targetlocationserver

locationrecipient

rulemaker

presentity

caller

presenceagent

watcher

callee

GEOPRIV

SIPpresence

SIPcall

PUBLISHNOTIFY

SUBSCRIBE

INVITE

publicationinterface

notificationinterface

ruleinterface

INVITE


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>


Policy relationships

geopriv-specific presence-specific

common policy

RPID CIPID

future


Presence policy

subscriptionpolicy

event generatorpolicy

subscriberfilter

rate limiter

change to previousnotification?

for eachwatcher

subscriber (watcher)

SUBSCRIBE

NOTIFY


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


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


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) …


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


Location-based IM & presence


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


Service creation environment for CPL and LESS


Conclusion

Basic multimedia framework in place both on-demand and interactive multimedia

need to develop surrounding eco system security control (privacy) policy automated configuration diagnostics, interworking, …

emphasis no longer on media transport

docomo eurolabs munich multimedia standardization – a snapshot henning schulzrinne dept. of...

Documents

docomo eurolabs munich

engineering slide

yrs slide

protocol standardization

speech conrol slide

multimedia iptel

sip im

ds service