In-network Support for VoIP and Multimedia Applications

1
In-network Support for VoIP and Multimedia
Applications

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

2
Overview

• signaling support for
• DOS prevention
• permission-based networking
• support for in-band media functionality
• such as media translation
• STUN/TURN support
• code delivery
• on-path caching for media streams

3
Separation of signaling and media

• Router functionality no excuse for merging
  application signaling and media
• mobility (avoid tromboning)
• logical separation of ISP/IAP and VSP
• network neutrality issues
• Thus, need media-path specific functions
• Avoid application-specific traffic admission
  functions (IMS)

4
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
5
Permission-based networking
may I send 100 kb/s?
NSIS (QoS)
yes, you may, for 10 minutes
sets up pinhole
NSIS requests are rate-limited possibly with
proof-of-work
6
NSIS (Next steps in signaling)
Georgios Karagiannis
7
NSIS in brief

• RSVP 2.0
• unicast-focused, mobility, security
• keeps soft state
• sender or receiver-based
• see RFC 4080 for requirements

• Layer separation
• GIST (NTLP) NSLP1, NSLP2
• Separate next-node discovery from signaling
• UDP and router alerts for discovery
• TCP/SCTP for signaling

8
STUN/TURN support

• STUN detect external IP addresses
• can embed in NATs ( edge routers)
• should be on public Internet and reasonably close
  (call setup delay)
• TURN relay node for bad NATs (symmetric)
• Relays need to be close to media path
• typically, operated by access provider

9
Rentable in-network application logic

• Not really routing or media path-related, but
  useful
• better close to backbone than at edges
• need to instantiate hundreds or thousands of
  clones
• Example SIP P2P networks

SIP proxy registrar
media storage (voicemail, media assets)
p2p node
generic mapping function
10
Code delivery to on-path nodes

• In progress Using NSIS to deliver code to
  on-path nodes
• NSIS well-suited since not constrained by MTU
  size
• congestion-controlled
• soft state and reroute discovery
• Supports authentication and authorization
• (Largely) avoids security issues
• influence own traffic only
• or offer services invoked by others
• Open issue near-path and off-path installation

11
On-path caching for media streams
cache
media server
need cacheable protocols, not layer violations
12
Conclusions

• Opportunities for (semi-)static and dynamic
  functionality
• Functionality created by end users, VSPs, ISPs
• On-path, near-path and off-path
• on-path DOS prevention
• near-path media relaying
• off-path P2P
• Help with media flow enforcement
• None of these require programmability, but helpful