1. introduction to telephony & voip

12/15/11

1

Introduction to Telephony & VoIP

Henning Schulzrinne Columbia University

1

*  The Public Switched Telephone System (PSTN) *  VoIP as black phone replacement à interactive communications enabler *  Presence as a service enabler *  Peer-‐to-‐peer VoIP

2

Overview

12/15/11

2

*  Commonly used interchangeably: *  Voice-‐over-‐IP (VoIP) – but includes video *  Internet telephony – but may not run over Internet *  IP telephony (IPtel)

*  Also: VoP (any of ATM, IP, MPLS) *  Some reserve Internet telephony for transmission across the

(public) Internet *  Transmission of telephone services over IP-‐based packet

switched networks *  Also includes video and other media, not just voice

3

Name confusion

*  1876 invention of telephone *  1915 first transcontinental telephone (NY–SF) *  1920’s first automatic switches *  1956 TAT-‐1 transatlantic cable (35 lines) *  1962 digital transmission (T1) *  1965 1ESS analog switch *  1974 Internet packet voice (2.4 kb/s LPC) *  1977 4ESS digital switch *  1980s Signaling System #7 (out-‐of-‐band) *  1990s Advanced Intelligent Network (AIN) *  1992 Mbone packet audio (RTP) *  1996 early commercial VoIP implementations (Vocaltec); PC-‐to-‐PC calling

4

A bit of history

12/15/11

3

*  analog narrowband circuits to “central office” *  48 Volts DC supply

*  64 kb/s continuous transmission, with compression across ocean *  µ-‐law: 12-‐bit linear range à 8-‐bit bytes *  everything clocked at a multiple of 125 µs *  clock synchronization à framing errors *  old AT&T: 136 “toll”switches in U.S. *  interconnected by T1 and T3 digital circuits à SONET rings (AT&T:

50) *  call establishment “out-‐of-‐band” using packet-‐switched signaling

system (SS7)

5

Phone system

Circuit diagram

6 ringing: 25 Hz, 50 V AC

12/15/11

4

WE 2500 diagram

7

System Year (use)

technology cost ($M) circuits $/circuit $/minute

TAT-‐1 1956-‐78 Coax + tubes $49.6 40 213,996 2.443

TAT-‐2 1569 Coax $42.7 44 167,308 1.910

TAT-‐3 1963 Coax $50.6 79 111,027 1.267

TAT-‐4 1965 Coax $50.4 62 140,238 1.601

TAT-‐5 1970 Coax $70.4 648 18,773 0.214

TAT-‐6 1976-‐94 Coax $197 3,200 10,638 0.121

TAT-‐7 1978-‐94 Coax $180 3,821 8,139 0.093

TAT-‐8 1988-‐02 Fiber (20 Mb/s) $360 6,048 10,285 0.117

TAT-‐9 1992-‐04 Fiber $406 10,584 6,628 0.076

TAT-‐10 1992-‐03 Fiber (2x565 Mb/s) $300 18,144 2,857 0.033

TAT-‐11 1993-‐04 Fiber (2x565 Mb/s) $280 18,144 2,667 0.030

TAT-‐12 1996-‐08 Fiber ring (5 Gb/s) $378 60,480 1,080 0.012

TAT-‐13 1996-‐08 Fiber (2x5 Gb/s) $378 60,480 1,080 0.012 8

Transatlantic cable systems

12/15/11

5

9

Transatlantic cable systems System Year technology cost ($M) circuits $/circuit $/minute

TAT-‐13 1996 Fiber $378 60,480 1,080 0.012

Gemini 1998 Fiber $520 214,920 371 0.004

AC-‐1 1998 120 Gb/s $850 483,840 304 0.003

TAT-‐14 2001 WDM 16xOC-‐192 $1,500 4x2.5M <75 0.001

Call load over the week

10

12/15/11

6

Signaling System #7

11

SS7 network

12

12/15/11

7

Typical signaling network

13

AIN SCP

LNP SCP

LTF/800 SCP

Low Speed Link (56 kb/s)

High Speed Link (1.544 Mb/s)

Local STP

Gateway STP

SSP (CO)

A

A-‐Links

A-‐Links

D-‐Link

B-‐Link

B-‐Link

A-‐Link

A-‐Link B-‐L

ink

‘A’

D-‐Link

NOTE: ‘C’ Links exist between each mated STP pair

Tandem

A-‐Link

D

D. Finn (BellSouth 2006)

*  Class 5 End Office (or C. O.) *  Connects subscribers’ telephone lines to the telecommunications network *  Provides BORSCHT functionality (Battery, Overvoltage protection, Ringing,

Supervision, Codec, Hybrid and Testing) *  Provides line and trunk concentration *  Serves as a “Host” for Remote Offices *  Serves as an ‘SSP’ -‐ Connects to SS7 for signaling and AIN functions

*  Tandem Central Office *  Serves as a ‘hub’ for connecting voice trunks from numerous Class 5 end offices *  Provides voice trunk connections to Long Distance carriers and Wireless providers *  Provides E9-‐1-‐1 Routing to PSAPs *  Types include LATA/Access Tandem, Toll Tandem, E911 Tandem, TOPS Tandem

14

Types of switching entities


12/15/11

8

*  Signaling Transfer Points (STPs) *  Provide efficient, fast call setup and teardown of telephone

calls *  Provide routing for database lookups (AIN, LNP, 800, etc.) *  Are the primary switches used in a “packet-‐based” network

as opposed to the circuit based network *  Provide Gateway Screening for Customer Access (IXCs, ITCs,

CLECs, Wireless) *  Serve as the PSTN entry point into the VoIP Network

15

Types of switching entities: STP


*  32 Analog 1AESS COs (SSPs) *  856 Lucent 5ESS COs *  355 5ESS “Hosts’ and 501 Remotes

*  581 Nortel DMS COs *  285 DMS “Hosts” and 283 Remotes and 10 DMS-‐10

*  138 Siemens COs (includes 85 Remotes) *  1607 Total COs with approx. 20.3 million NALs *  hosts ~ 24,000 lines *  remotes ~ 3,500 lines

*  109 tandems

16

Example: BellSouth


12/15/11

9

CO picture

17

copper wires: home à cable vault à distribution frame


CO picture

18

distribution frame

12/15/11

10

CO pictures

19

fiber cross connect point: fiber leaves CO


*  SSP: service switching point = voice switch + adjunct *  STP: signal transfer point router *  SCP: service control point = interface to databases *  call management service database *  line information database *  home location register (cellular) *  visitor location register (cellular)

*  traditionally, connected by 64 kb/s & T1 leased lines *  future: IP (à IETF Sigtran WG)

20

SS7

12/15/11

11

SS7 protocol stack

21

*  Level 1 (physical) *  DS0A = 56/64 kb/s in DS1 facility

*  Level 2 (data link) *  error detection/correction, link-‐by-‐link

*  Level 3 (network) *  routing message discrimination ➠ “point codes” distribution

*  Level 4 (user parts) *  basic signaling (ISUP) *  Transaction Capabilities Application (TCAP) *  Operations, Maintenance, Administration (OMAP) *  Mobile Application Part (MAP)

22

SS7 protocol stack

12/15/11

12

SS7 call

23

Reliability

24

#9’s reliability outage/year example

1 90% 36.5 days

2 99% 3.65 days

3 99.9% 8.8 hours good ISP

4 99.99% 53 minutes

5 99.999% 5 minutes phone system

6 99.9999% 32 seconds

12/15/11

13

*  FCC incidents: ≥ 90,000 customers, > 30 minutes (972 between 1992 and 1997) *  FCC ARMIS (Automated Reporting Management Information System) *  ANSI T1A1: logarithmic outage index = f(duration, # affected, time, functions, ...) *  call defects per million (e.g., AT&T 173 ppm)

25

Reliability

http://vallfoss.fcc.gov/eafs7/PresetMenu.cfm

*  median outage lasts 2.9 hours *  (natural disasters: 13.4 hours) *  causes: *  facilities (45%) *  local switches (18%), CCS (13%), CO power (7.3%)

*  facility failures: *  dig-‐ups (“back-‐hoe fade”, 58%) *  cable electronics (8%)

*  ARMIS example: *  Bell Atlantic 1998: 180 switches, combined downtime of 628

minutes, or 6.6 ·∙10-‐6

26

Outages

12/15/11

14

27

The phone works – why bother with VoIP

user perspective carrier perspective

variable compression: tin can to broadcast quality à no need for dedicated lines

better codecs + silence suppression – packet header overhead = maybe reduced bandwidth

security through encryption shared facilities simplify management, redundancy

caller & talker identification advanced services

better user interface (more than 12 keys, visual feedback, semantic rather than stimulus)

cheaper bit switching

no local access fees (but dropping to 1c/min for PSTN)

fax as data rather than voiceband data (14.4 kb/s)

adding video, application sharing is easy

Old vs. new

28

old reality new idea new reality

service provider

ILEC, CLEC email-like, run by enterprise, homes

E.164-driven; MSOs, some ILECs, Skype, European SIP providers, Vonage, SunRocket

media 4 kHz audio wideband audio, video, IM, shared apps, …

4 kHz audio

services CLASS (CLID, call forwarding, 3-way calling, ...)

user-created services (web model) presence

still CLASS

user IDs E.164 email-like E.164 IM handles

12/15/11

15

29

Evolution of VoIP

“amazing – the phone rings”

“does it do call transfer?”

“How can I make it stop ringing?”

1996-2000 2000-2003 2004-2005

catching up with the digital PBX

long-distance calling, ca. 1930

going beyond the black phone

2006-

“Can it really replace the phone system?”

replacing the global phone system

VoIP Signaling Protocols

30

*  H.323 *  ITU standard, ISDN-‐based, distributed

topology *  early on, used to be 90%+ of all Service

Provider VoIP networks *  video conferencing (Microsoft

NetMeeting, room units [Polycom, Tandberg, …])

*  Skinny *  Centralized call control architecture *  CallManager controls all features *  over 1 mio. IP Phones deployed –

probably most popular corporate IP-‐PBX

*  MGCP *  IETF RFC 2705 *  Centralized call control architecture *  Call-‐Agents (MGC) & Gateways (MG)

*  SIP *  IETF RFC 2543 and RFC 3261 *  Distributed call control *  Used for more than VoIP…SIMPLE:

Instant Messaging / Presence

Brian Gracely, Cisco, 2001 (mod.)

12/15/11

16

IETF VoIP & presence efforts

31

SIPCORE (protocol) DISPATCH

(spin off mini-‐WGs)

ECRIT (emergency calling)

AVT (RTP, SRTP, media)

ENUM (E.164 translation)

SIMPLE (presence)

GEOPRIV (geo + privacy)

uses may use

uses

usually used with

IETF RAI area

MMUSIC (SDP, RTSP, ICE)

XCON (conf. control)

SPEERMINT (peering)

uses

SPEECHSC (speech services)

uses

BLISS (services) DRINKS

(registry)

MEDIACTRL (media servers)

P2PSIP (DHT protocol)

XMPP (presence)

32

PBX features call 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

cent

rex-

styl

e fe

atur

es

boss/admin features

attendant features

12/15/11

17

RTP

33

RTP stack

34

RTCP

RFC 3550 (RTP, RTCP) pair

12/15/11

18

*  Real-‐Time Transport Protocol (RTP) = data + control *  data (media): *  timing *  loss detection *  content labeling *  talkspurts & video frames *  encryption

*  control (RTCP): *  ➠ periodic with T ∼ population *  QoS feedback *  membership estimation in multicast *  loop detection

35

RTP

36

RTP Packet Header

ver 2 # contributor

padding (for fixed size block), last

byte of pkt is the pad count

static or dynamic

granularity determined by payload type

if this RTP stream is mixed

RFC 3551 audio-video profile

1 = first pkt of a talkspurt, after a silence period

12/15/11

19

*  +1 per sample (e.g., 160 for 20 ms packets @ 8000 Hz) *  random starting value *  time per packet may vary *  different fixed rate for each audio PT *  typically, 20 – 100 ms / packet *  90 kHz for video *  several video frames may have same timestamp *  ➠ gaps ≡ silence *  split video frame (carefully. . . ) across packets

37

RTP timestamp

*  mixer: *  several media stream ➠ one new stream (new encoding) *  e.g., audio/video conferencing

*  appears as new source, with own identifier

*  translator: *  single media stream *  may convert encoding *  e.g., protocol translation (IPv4 à IPv6) *  all packets: source address = translator address

38

RTP mixer & translator

12/15/11

20

RTP mixer & translator

39

stackable packets, similar to data packets

*  sender report (SR) *  bytes send ➠ estimate rate *  timestamp ➠ synchronization

*  reception reports (RR): *  number of packets sent and expected ➠ loss, interarrival jitter, round-‐trip delay

*  source description (SDES): *  name, email, location,…

*  canonical name (CNAME) = user@host *  identifies user across media

*  explicit leave (BYE): in addition to time-‐out

*  extensions (APP): application-‐specific (none yet)

40

RTCP

12/15/11

21

41

RTCP

Value Abbreviation Name Document

194 SMPTETC SMPTE time-‐code mapping RFC 5484

195 IJ Network interarrival jitter RFC 5450

200 SR Sender report RFC 3550

201 RR Receiver report RFC 3550

202 SDES Source description RFC 3550

203 BYE Good bye RFC 3550

204 APP Application-‐defined RFC 3550

205 RTPFB Generic RTP feedback (loss) RFC 4585

206 PSFB Payload-‐specific feedback RFC 4585

207 XR Extended report (RLE, delay, R factor) RFC 3611

208 AVB Audio-‐video bridging IEEE 1733

209 RSI Receiver summary information ietf-‐avt-‐rtcpssm

42

RTCP (detail)

12/15/11

22

RTCP SR packet example

43

*  next packet = last packet + max(5 s, T ) ·∙ random(0.5. . . 1.5) *  randomization prevents “bunching” *  to reduce RTCP bandwidth, alternate between SDES components

44

RTCP bandwidth scaling

12/15/11

23

*  = sync different streams (audio, video, slides, . . .)

*  timestamps are offset with random intervals

*  may not tick at nominal rate

*  SRs correlate “real” time (wallclock time) with RTP timestamp

45

RTCP intermedia synchronization

Round-‐trip time estimation

46

compute round-‐trip time between sender and receiver

12/15/11

24

Internet services – the missing entry

Service/delivery synchronous asynchronous

push instant messaging presence event notification session setup media-‐on-‐demand

messaging

pull data retrieval file download remote procedure call

peer-‐to-‐peer file sharing

47

48

Filling in the protocol gap

Service/delivery synchronous asynchronous

push SIP RTSP, RTP

SMTP

pull HTTP ftp SunRPC, Corba, SOAP

(not yet standardized)

12/15/11

25

SIP as service enabler

49

*  Rendezvous protocol *  lets users find each other by only

knowing a permanent identifier *  Mobility enabler: *  personal mobility *  one person, multiple terminals

*  terminal mobility *  one terminal, multiple IP addresses

*  session mobility *  one user, multiple terminals in

sequence or in parallel *  service mobility *  services move with user

50

What is SIP? n  Session Initiation Protocol à protocol that

establishes, manages (multimedia) sessions n  also used for IM, presence & event notification n  uses SDP to describe multimedia sessions

n  Developed at Columbia U. (with others) n  Standardized by

n  IETF (RFC 3261-‐3265 et al) n  3GPP (for 3G wireless) n  PacketCable

n  About 100 companies produce SIP products n  Microsoft’s Windows Messenger (≥4.7) includes

SIP

12/15/11

26

*  Session establishment & event notification *  Any session type, from audio to circuit emulation *  Provides application-‐layer anycast service *  Provides terminal and session mobility *  Based on HTTP in syntax, but different in protocol

operation *  Peer-‐to-‐peer system, with optional support by proxies *  even stateful proxies only keep transaction state, not call

(session, dialogue) state *  transaction: single request + retransmissions *  proxies can be completely stateless

51

Philosophy

52

Basic SIP message flow

12/15/11

27

53

SIP trapezoid

SIP trapezoid

outbound proxy

[email protected]: 128.59.16.1

registrar

1st request

2nd, 3rd, … request

voice traffic RTP

destination proxy (identified by SIP URI domain)

SIP message format

54

SDP

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP here.com:5060 From: Alice <sip:[email protected]> To: Bob <sip:[email protected]> Call-‐ID: [email protected] CSeq: 1 INVITE Subject: just testing Contact: sip:[email protected] Content-‐Type: application/sdp Content-‐Length: 147

v=0 o=alice 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

SIP/2.0 200 OK

Via: SIP/2.0/UDP here.com:5060 From: Alice <sip:[email protected]> To: Bob <sip:[email protected]> Call-‐ID: [email protected] CSeq: 1 INVITE Subject: just testing Contact: sip:[email protected] Content-‐Type: application/sdp Content-‐Length: 134

v=0 o=bob 2890844527 2890844527 IN IP4 there.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m

essage

bod

y he

ader fields

requ

est line

request response

12/15/11

28

*  Format description (payload), not a protocol *  Used in MGCP and SIP to describe media characteristics *  Type of stream (audio, video, real-‐time text, …) *  Codec type *  IP address & port

*  Sent within a SIP message as a message body *  Content-Type: application/sdp

*  Originally designed for multicast sessions (SAP) *  limited extensibility *  capability (“can”) vs. request (“want”) *  media alignment problems

55

SDP RFC 2327 4566

SDP example

56

v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf [email protected] (Jane Doe) c=IN IP4 224.2.17.12/127 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-‐1998/90000

send data to

RTP audio with PT 0 (µ-‐law) on port 49170

RTP video with PT 99, defined in

a=

session description (mainly for multicast)

RTP timestamp frequency =

90 kHz

12/15/11

29

*  = the process of negotiating codecs using SDP *  SDP can be sent in SIP INVITE, 18x/200 responses, and ACK *  The first SDP sent in either direction is considered to be an offer *  An SDP consequently sent in the reverse direction is an answer

57

Offer/Answer RFC 3264

58

SDP offer/answer INVITE(sdp)

180

200(sdp)

ACK

INVITE(sdp + video)

200(sdp)

ACK

Let me see you !

Caller Callee

12/15/11

30

59

PSTN vs. Internet Telephony

Signaling & Media Signaling & Media

Signaling Signaling

Media

PSTN:

Internet telephony:

China

Belgian customer, currently visiting US

Australia

*  Users identified by SIP or tel URIs *  sip:[email protected]

*  tel: URIs describe E.164 number, not dialed digits (RFC 2806bis)

*  tel URIs à SIP URIs by outbound proxy

*  A person can have any number of SIP URIs

*  The same SIP URI can reach many different phones, in different networks *  sequential & parallel forking

*  SIP URIs can be created dynamically: *  GRUUs *  conferences *  device identifiers (sip:[email protected])

*  Registration binds SIP URIs (e.g., device addresses) to SIP “address-‐of-‐record” (AOR)

60

SIP addressing

tel:110 sip:sos@domain

domain à 128.59.16.17 via NAPTR + SRV

12/15/11

31

61

3G Architecture (Registration)

visited IM domain

home IM domain

serving CSCF interrogating proxy

interrogating

mobility management signaling

registration signaling (SIP)_

*  notify (small) group of users when something of interest happens *  presence = change of

communications state *  email, voicemail alerts *  environmental conditions *  vehicle status *  emergency alerts

*  kludges *  HTTP with pending response *  inverse HTTP -‐-‐> doesn’t work with

NATs

*  Lots of research (e.g., SIENA) *  IETF efforts starting *  SIP-‐based *  XMPP

62

Event notification

12/15/11

32

*  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

63

Context-‐aware communication

time CPL capabilities caller preferences

location location-based call routing location events

activity/availability presence

sensor data (mood, bio) privacy issues similar to location data

The role of presence

64

*  Guess-‐and-‐ring *  high probability of failure: *  “telephone tag” *  inappropriate time (call during

meeting) *  inappropriate media (audio in public

place) *  current solutions: *  voice mail à tedious, doesn’t scale,

hard to search and catalogue, no indication of when call might be returned

*  automated call back à rarely used, too inflexible

*  à most successful calls are now scheduled by email

*  Presence-‐based *  facilitates unscheduled

communications *  provide recipient-‐specific

information *  only contact in real-‐time if

destination is willing and able *  appropriately use synchronous

vs. asynchronous communication *  guide media use (text vs. audio) *  predict availability in the near

future (timed presence)

Prediction: almost all (professional) communication will be presence-initiated or pre-scheduled

12/15/11

33

GEOPRIV and SIMPLE architectures

65

target location server

location recipient

rule maker

presentity

caller

presence agent watcher

callee

GEOPRIV

SIP presence

SIP call

PUBLISH NOTIFY

SUBSCRIBE

INVITE

publication interface

notification interface

XCAP (rules)

INVITE

DHCP

66

Presentity and Watchers

Bob’s status, location

Watchers

Available, Busy, Somewhat available, Invisible

wife

son

external world

PUBLISH SUBSCRIBE

NOTIFY

Bob’s Presentity Watchers Watchers

Bob’s Presence User Agents (PUA)

PC-‐IM Client

R u there ?

Bob’s play station

Cell

Phone

BUZZ

PUBLISH

Bob’s Filters (Rules), PIDF *)

Presence Server (PS)

*) -‐ PIDF = Presence Information Data Format

friend

12/15/11

34

*  Role of presence *  initially: “can I send an instant message and expect a response?” *  now: “should I use voice or IM? is my call going to interrupt a meeting?

is the callee awake?” *  Yahoo, MSN, Skype presence services: *  on-‐line & off-‐line *  useful in modem days – but many people are (technically) on-‐line 24x7 *  thus, need to provide more context *  + simple status (“not at my desk”)

*  entered manually à rarely correct *  does not provide enough context for directing interactive communications

67

Basic presence

Presence data architecture

68

raw presence document

create view (compose)

privacy filtering

draft-ietf-simple-presence-data-model

composition policy

privacy policy

presence sources

XCAP XCAP

(not defined yet)

depends on watcher select best source resolve contradictions

PUBLISH

12/15/11

35

Presence data architecture

69

candidate presence document

watcher filter

raw presence document

post-processing composition (merging)

final presence document

difference to previous notification

SUBSCRIBE

NOTIFY

remove data not of interest

watcher

*  Provide watchers with better information about the what, where, how of presentities *  facilitate appropriate communications: *  “wait until end of meeting” *  “use text messaging instead of phone call” *  “make quick call before flight takes off”

*  designed to be derivable from calendar information *  or provided by sensors in the environment

*  allow filtering by “sphere” – the parts of our life *  don’t show recreation details to colleagues

70

Rich presence

12/15/11

36

*  automatically derived from *  sensors: physical presence, movement *  electronic activity: calendars

*  Contains: *  multiple contacts per presentity *  device (cell, PDA, phone, …) *  service (“audio”)

*  activities, current and planned *  surroundings (noise, privacy, vehicle, …) *  contact information *  composing (typing, recording audio/video IM, …)

71

Rich presence

*  Two modes: *  watcher uses presence

information to select suitable contacts *  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)

72

The role of presence for call routing

LESS

translate RPID

CPL

PA

PUBLISH

NOTIFY

INVITE

12/15/11

37

*  All presence data, particularly location, is highly sensitive *  Basic location object (PIDF-‐LO) describes *  distribution (binary) *  retention duration *  Policy rules for more detailed access control *  who can subscribe to

my presence *  who can see what

when

73

Presence and privacy

<tuple id="sg89ae"> <status> <gp:geopriv> <gp:location-info>

<gml:location> <gml:Point gml:id="point1“

srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W

</gml:coordinates>

</gml:Point> </gml:location>

</gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no

</gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z

</gp:retention-expiry>

</gp:usage-rules> </gp:geopriv>

</status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple>

Privacy rules

74

*  Conditions *  identity, sphere *  time of day *  current location *  identity as <uri> or <domain> +

<except> *  Actions *  watcher confirmation

*  Transformations *  include information *  reduced accuracy

*  User gets maximum of permissions across all matching rules *  privacy-‐safe composition:

removal of a rule can only reduce privileges

*  Extendable to new presence data *  rich presence *  biological sensors *  mood sensors

12/15/11

38

Example rules document

75

<identity><id>[email protected]</id></identity>

<sub-handling>allow</sub-handling>

<provide-services> <service-uri-scheme>sip</service-uri-scheme> <service-uri-scheme>mailto</service-uri-scheme> </provide-services> <provide-person>true</provide-person> <provide-activities>true</provide-activities> <provide-user-input>bare</provide-user-input>

<ru

lese

t>

<rule id=1> <

cond

ition

s>

<tr

ansf

orm

atio

ns>

<

actio

ns>

Location-‐based services

12/15/11

39

77

Location-‐based services

Finding services based on location

physical services (stores,

restaurants, ATMs, …)

electronic services (media I/O, printer, display,

…)

Using location to improve (network) services

communication

incoming communications changes based on

where I am

configuration

devices in room adapt to their current users

awareness

others are (selectively) made

aware of my location

security

proximity grants temporary access to local resources

*  Location-‐aware inbound routing *  do not forward call if time at callee location is [11 pm, 8 am] *  only forward time-‐for-‐lunch if destination is on campus *  do not ring phone if I’m in a theater

*  outbound call routing *  contact nearest emergency call center *  send [email protected] to nearest branch

*  location-‐based events *  subscribe to locations, not people *  Alice has entered the meeting room *  subscriber may be device in room à our lab stereo changes

CDs for each person that enters the room

78

Location-‐based SIP services

12/15/11

40

Location delivery

79

DHCP

HTTP

GPS

HELD

LLDP-‐MED

wire map

Location determination options

80

Method CDP or LLDP-MED

DHCP HELD GPS manual entry

Layer L2 L3 L7 (HTTP) - user

advantages •  simple to implement

•  built into switch •  direct port/room

mapping

•  simple to implement

•  network locality

•  traverses NATs

•  can be operated by L2 provider

•  accurate • mobile

devices •  no carrier

cooperation

•  no infrastructure changes

•  no carrier cooperation

problems may be hard to automate for large enterprises

mapping MAC address to location?

mapping IP address to switch port?

•  indoor coverage

•  acquisition time

•  fails for mobile devices

•  unreliable for nomadic

Use Ethernet LANs Enterprise LANs Some ISPs

DSL, cable mobile devices fall back

12/15/11

41

81

Program location-‐based services

82

12/15/11

42

P2P

Each peer must act as both a client and a server.

Peers provide computational or storage resources for other peers.

Self-‐organizing and scaling.

84

Defining peer-‐to-‐peer systems

1 & 2 are not sufficient: DNS resolvers provide services to others Web proxies are both clients and servers SIP B2BUAs are both clients and servers

12/15/11

43

NETWORK ENGINEER’S WARNING P2P systems may be *  inefficient *  slow *  unreliable *  based on faulty and short-‐term economics *  mainly used to route around copyright laws

85

P2P systems are … P2P

vs.

*  Saves money for those offering services *  addresses market failures

*  Scales up automatically with service demand *  More reliable than client-‐

server (no single point of failure) *  No central point of control

*  mostly plausible deniability *  Networks without

infrastructure (or system manager) *  New services that can’t be

deployed in the ossified Internet *  e.g., RON, ALM

86

Motivation for peer-‐to-‐peer systems

12/15/11

44

HTTP web, 33%

HTTP audio/video, 33%

P2P, 20%

Other, 14%

AT&T backbone

87

P2P traffic is not devouring the Internet…

steady percentage

88

Energy consumption

http://www.legitreviews.com/article/682/

Monthly cost = $37

@ $0.20/kWh

12/15/11

45

*  Transit bandwidth: $40 Mb/s/month ~ $0.125/GB *  US colocation providers charge $0.30 to $1.75/GB *  e.g., Amazon EC2 $0.17/GB (outbound) *  CDNs: $0.08 to $0.19/GB

89

Bandwidth costs

*  Service provider view *  save $150/month for single rented server in

colo, with 2 TB bandwidth *  but can handle 100,000 VoIP users *  But ignores externalities *  home PCs can’t hibernate à energy usage *  about $37/month

*  less efficient network usage *  bandwidth caps and charges for consumers *  common in the UK *  Australia: US$3.20/GB

*  Home PCs may become rare *  see Japan & Korea

90

Economics of P2P

bandwidth

charge

($)

12/15/11

46

*  Typically, P2P hosts only lightly used *  energy efficiency/computation highest at full load *  à dynamic server pool most efficient *  better for distributed computation (SETI@home)

*  But: *  CPU heat in home may lower heating bill in winter *  but much less efficient than natural gas (< 60%)

*  Data center CPUs always consume cooling energy *  AC energy ≈ server electricity consumption

*  Thus, *  deploy P2P systems in Scandinavia and Alaska

91

Which is greener – P2P vs. server?

*  CW: “P2P systems are more reliable” *  Catastrophic failure vs. partial failure *  single data item vs. whole system *  assumption of uncorrelated failures wrong *  Node reliability *  correlated failures of servers (power,

access, DOS) *  lots of very unreliable servers (95%?) *  Natural vs. induced replication of data items

92

Reliability

Some of you may be having problems logging into Skype. Our engineering team has determined that it’s a software issue. We expect this to be resolved within 12 to 24 hours. (Skype, 8/12/07)

12/15/11

47

*  Security much harder *  user authentication and credentialing *  usually now centralized

*  sybil attacks *  byzantine failures

*  Privacy *  storing user data on somebody else’s machine

*  Distributed nature doesn’t help much *  same software à one attack likely to work everywhere

*  CALEA?

93

Security & privacy

*  P2P systems are hard to debug *  No real peer-‐to-‐peer management systems *  system loading (CPU, bandwidth) *  automatic splitting of hot spots

*  user experience (signaling delay, data path) *  call failures

*  Later: P2PP & RELOAD add mechanisms to query nodes for characteristics *  Who gathers and evaluates the overall system health?

94

OA&M

12/15/11

48

P2P for VoIP

95

96

The role of SIP proxies

sip:[email protected]

tel:1-‐212-‐555-‐1234



Translation may depend on caller, time of day, busy

status, …

REGISTER

12/15/11

49

*  Why? *  no infrastructure available: emergency

coordination *  don’t want to set up infrastructure: small

companies *  Skype envy :-‐)

*  P2P technology for *  user location *  only modest impact on expenses *  but makes signaling encryption cheap

*  NAT traversal *  matters for relaying

*  services (conferencing, transcoding, …) *  how prevalent?

*  New IETF working group formed *  multiple DHTs *  common control and look-‐up protocol?

97

P2P SIP

LAN

P2P provider A

P2P provider B

p2p network

traditional provider

DNS

zeroconf

generic DHT service

XOR

Finger table

Parallel requests Recursive routing

Successor

Modulo addition Prefix-‐match

Leaf-‐set

Routing-‐table stabilization Lookup correctness

Lookup performance

Proximity neighbor selection

Proximity route selection

Routing-‐table size

Strict vs. surrogate routing

Bootstrapping

Updating routing-‐table from lookup requests

Tree

Hybrid

Reactive recovery

Periodic recovery

Routing-‐table exploration 98

More than a DHT algorithm

12/15/11

50

*  Multicast-‐DNS (zeroconf) SIP enhancements for LAN *  announce UAs and their

capabilities *  Client-‐P2P protocol *  GET, PUT mappings *  mapping: proxy or UA *  P2P protocol *  get routing table, join, leave, … *  independent of DHT *  replaces DNS for SIP and basic

proxy

99

P2P SIP -‐-‐ components

Bootstrap & authentication server

100

P2PSIP architecture

SIP

P2P STUN

TLS / SSL

peer in P2PSIP

NAT

NAT

client

[email protected]

[email protected] Overlay 1

Overlay 2

[email protected] à 128.59.16.1

INVITE [email protected]

12/15/11

51

*  Originally, effort to perform SIP lookups in p2p network *  Initial proposals based on SIP itself *  use SIP messages to query and update entries *  required minor header additions

*  P2PSIP working group formed *  now SIP just one usage

*  Several protocol proposals (ASP, RELOAD, P2PP) merged *  still in “squishy” stage – most details can change

101

IETF peer-‐to-‐peer efforts

*  Generic overlay lookup (store & fetch) mechanism *  any DHT + unstructured

*  Routed based on node identifiers, not IP addresses *  Multiple instances of one DHT, identified by DNS name *  Multiple overlays on one node *  Structured data in each node *  without prior definition of data types *  PHP-‐like: scalar, array, dictionary *  protected by creator public key *  with policy limits (size, count, privileges)

*  Maybe: tunneling other protocol messages

102

RELOAD

12/15/11

52

103

Typical residential access

10.0.0.2

10.0.0.3

130.233.240.9

Home Network ISP NetworkInternet

192.168.0.1

Sasu Tarkoma, Oct. 2007

104

NAT traversal

STUN / TURN server

SIP server

peer

media

P2P

get public IP address

12/15/11

53

gather prioritize encode offer & answer check complete

105

ICE (Interactive Connectivity Establishment)

106

OpenVoIP snapshots

call through a relay call through a NAT direct

12/15/11

54

*  Google Map interface

107

OpenVoIP snapshots

*  Tracing lookup request on Google Maps

108

OpenVoIP snapshots

12/15/11

55

Emergency calling

Modes of emergency communications

110

emergency call

civic coordination

emergency alert (“inverse 911”)

dispatch

information “I-am-alive”

12/15/11

56

*  Established in Feb. 1968 *  1970s: selective call routing *  late 1990s: 93% of population/96% of area covered by 9-‐1-‐1 *  95% of 9-‐1-‐1 is Enhanced 9-‐1-‐1 *  US and Canada

*  Roughly 200 mio. calls a year (6 calls/second) *  1/3 wireless

*  6146 PSAPs in 3135 counties *  most are small (2-‐6 call takers) *  83.1% of population have some Phase II (April 2007)

*  “12-‐15 million households will be using VoIP as either primary or secondary line by end of 2008” (NENA)

111

Background on 9-‐1-‐1

http://www.nena.org/

112

Local Switch

Automatic Number Identification

Automatic Location Identification Collaboration between

local phone providers and local public safety agencies

12/15/11

57

E9-1-1 Tandem w/SRDB

PSAP

End office

Loop Access Control ie DLC System

Update Links

The Local Loop

EM Trunks ES Trunks Public Safety Answering Point

PSAP ALI Data Links

Recent Change Links

DBMS

Service Providers ALI Database Elements

SCP GATEWAY (Firewall)

E9-‐1-‐1 Call flow elements -‐ wireline

113

ALI

Wireless 911 Phase II -‐ TDOA

114 BellSouth

12/15/11

58

Wireless 911 Phase II accuracy

115

Accuracy 67% 95%

Handset-based 50m 150m

Network-based 100m 300m

ALI/SR DBASE

PSAP

Public Safety Answering Point

MSC

MPC PDE

E2

E9-1-1 Tandem w/SRDB

1

2

3 4

5 6

7

8

E9-1-1 CALL FLOW ELEMENTS - WIRELESS

TDL’s 9

#9 is only applicable in a CAS-Hybrid architecture, such as BellSouth’s WLS911 Solution

116

12/15/11

59

What makes VoIP 112/911 hard?

117

POTS PSTN-‐emulation VoIP end-‐to-‐end VoIP

(landline) phone number limited to limited area

landline phone number anywhere in US (cf. German 180)

no phone number or phone number anywhere around the world

regional carrier national or continent-‐wide carrier

enterprise “carrier” or anybody with a peer-‐to-‐peer device

voice provider = line provider (~ business relationship)

voice provider ≠ ISP voice provider ≠ ISP

national protocols and call routing

probably North America + EU

international protocols and routing

location = line location mostly residential or small business

stationary, nomadic, wireless

*  Each country and region has their own *  subject to change

*  Want to enable *  traveler to use familiar home

number *  good samaritan to pick up cell

phone *  Some 3/4-‐digit numbers are used

for non-‐emergency purposes (e.g., directory assistance)

118

Emergency numbers

Emergency number

12/15/11

60

*  Idea: Identifiers to denote emergency calls *  and other generic (communication) services

*  Described in IETF ECRIT RFC 5031 *  Emergency service identifiers:

sos General emergency services sos.animal-‐control Animal control sos.fire Fire service sos.gas Gas leaks and gas emergencies sos.marine Maritime search and rescue sos.mountain Mountain rescue sos.physician Physician referral service sos.poison Poison control center sos.police Police, law enforcement

119

Service URN

LoST: Location-‐to-‐URL Mapping

120

cluster serves VSP2

NY US

NJ US

Bergen County NJ US

123 Broad Ave Leonia Bergen County NJ US

cluster serving VSP1 replicate root information

search referral

root nodes

Leonia NJ US


VSP1

LoST

12/15/11

61

Emergency Services Network (ESN)

Emergency Services Routing Proxy (ESRP) Call Distributor

SIP Back-to-back User Agent

PSAP A

PSAP SIP Proxy

.

.

.

Location-to-Service Translation (LoST)

Server

.

.

.

Call Takers

PSAP Z

PSAP SIP Proxy

.

.

.

Call TakersCall DistributorSIP Back-to-back

User Agent

Public Safety Answering Points (PSAP)

Conference Server

RTP

LoST

Cellular

Access Network

SIP

9-‐ 9-‐1-‐1 9-‐1-‐ 9-‐1-‐1

121

122

The POC system is deployed in 5 real PSAPs and 3 labs across the USA. PSAP: Public Safety Answering Point (=Emergency call center)

Fort Wayne, IN

Rochester, NY

Bozeman, MT

King County, WA

St. Paul, MN

BAH Lab

Columbia Univ. Lab

TAMU Lab

1. introduction to telephony & voip

Documents