Multimedia Standardization A Snapshot

1
Multimedia Standardization A Snapshot

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

2
Overview

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

3
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
4
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

5
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

6
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

7
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

8
Standardization process
WG last call
IETF last call
RFC
draft-ietf-wg-idea-00
IESG comments
-xx
-02
draft-somebody- wg-idea-00
-01
initial idea
1-5 yrs
9
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

10
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

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

12
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

13
SIP is PBX/Centrex ready
boss/admin features
centrex-style features
attendant features
from Rohan Mahys VON Fall 2003 talk
14
SIP, SIPPING SIMPLE 00 drafts
includes draft-ietf--00 and draft-personal--00
15
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 wouldnt do anything stupid, would
  we?
• hard to get protocol eco system
• variety of end systems
• diagnostics and protocol analyzers

16
SIP a bi-cultural protocol

• multimedia
• IM and presence
• location-based service
• user-created services
• decentralized operation
• everyone equally suspect

• overlap dialing
• key systems
• notion of lines
• per-minute billing
• early media
• ISUP BICC interoperation
• trusted service providers

17
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
• cant do content analysis (Bayesian filtering)
• even for IM ? attention grabbed after first
  Hello message
• human reachability measures
• interfere with real-time nature

18
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 proxy example.com
shared secret (Digest)
verify example.com
From alice_at_example.com
19
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

20
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

21
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

22
GEOPRIV and SIMPLE architectures
rule maker
rule interface
target
location server
location recipient
notification interface
publication interface
GEOPRIV
SUBSCRIBE
presentity
presence agent
watcher
SIP presence
PUBLISH
NOTIFY
caller
callee
SIP call
INVITE
INVITE
23
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

watcher
everything
PA
PUA
watcher
"vague"
PUBLISH
watcher
NOTIFY
CPL
ltactivitygt ltplace-typegt ltprivacygt ltmoodgt ltspheregt
INVITE
24
Policy relationships
common policy
geopriv-specific
presence-specific
future
RPID
CIPID
25
Presence policy
SUBSCRIBE
subscription policy
subscriber (watcher)
for each watcher
event generator policy
subscriber filter rate limiter
change to previous notification?
NOTIFY
26
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

27
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

28
Processing models

• Sequential model
• for each subscriber, apply rules to new data
• doesnt 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
  personsubscriber (AND now() between(starttime,en
  dtime) OR starttime is null) AND (a3a3 or a3 is
  null)

29
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 gt threshold
• entering or leaving certain area
• entering or leaving category or behavioral type

30
Location-based IM presence
31
Service creation

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

32
Service creation environment for CPL and LESS
33
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