Title: When%20will%20the%20telephone%20network%20disappear?
1When will the telephone network disappear?
- Henning Schulzrinne
- (with Knarig Arabshian, Wenyu Jiang, Jonathan
Lennox, Sankaran Narayanan, Kundan Singh, Xiaotao
Wu and other members of the IRT Lab)
2Overview
- Why voice over IP?
- why not yet?
- a multimedia "PBX" CINEMA
- voice quality
- creating services
- emergency calls and notification
3A brief history
- August 1974
- Realtime packet voice between USC/ISI and MIT/LL,
using CVSD and NVP. - December 1974
- Packet voice between CHI and MIT/LL, using LPC
and NVP - January 1976
- Live packet voice conferencing between USC/ISI,
MIT/LL, SRI, using LPC and NVCP - Approximately 1976
- First packetized speech over SATNET between
Lincoln Labs and NTA (Norway) and UCL (UK) - 1990
- ITU recommendation G.764 (Voice packetization
packetized voice protocols)
4A brief history
- February 1991
- DARTnet voice experiments
- August 1991
- LBL's audio tool vat released for DARTnet use
- March 1992
- First IETF MBONE broadcast (San Diego)
- January 1996
- RTP standardized (RFC 1889/1890)
- November 1996
- H.323v1 published
- February/March 1999
- SIP standardized (RFC 2543)
5Status in 2002
- 2000 6b wholesale, 15b minutes retail
- 2001 10b worldwide 6 of traffic (only
phone-to-phone) - e.g., net2phone 341m min/quarter
6VoIP applications
- Trunk replacements between PBXs
- Ethernet trunk cards for PBXs
- T1/E1 gateways
- IP centrex outsourcing the gateway
- Denwa, Worldcom, Vonage
- Enterprise telephony
- Cisco Avvid, 3Com, Mitel, Nortel, snom, Pingtel,
Avaya, ... - Consumer calling cards (phone-to-phone)
- net2phone, iConnectHere (deltathree), ...
7VoIP applications
- PC-to-phone, PC-to-PC
- net2phone, dialpad, iConnectHere, mediaring, ...
- Push-to-talk (call centers, conferences)
- eStara, edial
8PSTN vs. Internet Telephony
PSTN
Signaling Media
Signaling Media
Internet telephony
Signaling
Signaling
Media
9VoIP protocols
- Builds on standard Internet protocols
- IP-over-x QoS (802.1p, DiffServ)
- UDP, TCP, SCTP TLS
- Media transport
- RTP/RTCP
- Session setup (signaling)
- interactive SIP, H.323
- streaming RTSP
- Directory services
- ENUM (DNS)
- LDAP
- TRIP for gateway location
10VoIP components
- gateways
- analog 1-8 lines
- T1 to multiple T3
- IP phones
11Where are we?
- Variety of robust SIP phones (and lots of
proprietary ones) - not yet in Wal-Mart
- SIP carriers terminate LAN VoIP
- number portability?
- 911
- 50 vendors at SIPit
- Building blocks media servers, unified
messaging, conferencing, VoiceXML,
12IP Centrex
13Example Columbia Dept. of CS
- About 100 analog phones on small PBX
- DID
- no voicemail
- T1 to local carrier
- Added 2 T1 trunks and small (Cisco 2600) gateways
- department Nortel PBX
- Columbia University Siemens PBX
- Dial plan call to 7134 becomes sip7134_at_cs
- Ethernet phones, soft phones and conference room
- CINEMA set of servers, running on 1U rackmount
server
14CINEMA components
Cisco 7960
MySQL
rtspd
sipconf
user database
LDAP server
plug'n'sip
RTSP
conferencing
media
server
server
(MCU)
wireless
sipd
802.11b
RTSP
proxy/redirect server
unified
messaging
server
Pingtel
sipum
Cisco
Nortel
2600
Meridian
VoiceXML
PBX
server
T1
T1
SIP
sipvxml
PhoneJack interface
sipc
SIP-H.323
converter
sip-h323
15Experiences
- Need flexible name mapping
- Alice.Cueba_at_cs ? alice_at_cs
- sources database, LDAP, sendmail aliases,
- Automatic import of user accounts
- In university, thousands each September
- /etc/passwd
- LDAP, ActiveDirectory,
- much easier than most closed PBXs
- Integrate with Ethernet phone configuration
- often, bunch of tftp files
- Integrate with RADIUS and PBX accounting ("call
detail records") - fixed user for each phone
- PIN dialing
16Experiences
- Password integration difficult
- Digest needs plain-text, not hashed
- Different user classes students, faculty, admin,
guests, - Who pays if call is forwarded/proxied?
- authentication and billing behavior of PBX and
SIP system may differ - but much better real-time rating
17SIP doesnt have to be in a phone
siplava_at_cs.columbia.edu
18QoS components
- Dominant QoS factors
- loss ? clipping, distortion in audio
- delay ? lower interactivity (lt 200 ms)
- jitter ? late loss delay
19Delay and Loss Measurement
- Solutions for clock synchronization
- Telephone-based synchronization
- RTT-based, assume symmetric delays
- GPS-based
- Dealing with Clock drift
- De-skewing by linear regression
- One-way vs. round-trip measurement
- Internet load often asymmetric
- One-way loss and delay are more relevant to
real-time multimedia
20Loss and Delay Models
- Loss models
- Gilbert model
- Extended Gilbert model
- Others
- Delay models
- More difficult to construct
- No universal distribution function
- Temporal correlation between delays
21Perceived Quality Estimation
MOS Grade Score
Excellent 5
Good 4
Fair 3
Poor 2
Bad 1
- Mean Opinion Score (MOS)
- Requires human listeners
- Labor and time intensive
- Reflective of real quality
- Objective perceptual quality estimation
algorithms - PESQ, PSQM/PSQM, MNB, EMBSD
- Speech recognition based (new)
22Comparison of Loss Models
- Loss burst distribution
- Roughly, but not exactly exponential
- Inter-loss distance
- Clustering between adjacent loss bursts
1000
Packet trace
Gilbert model
100
number of occurrences
10
1
0
0
2
4
6
8
10
12
Loss burst length
23Loss Model Comparison
- Loss burstiness on FEC performance
- FEC less efficient under bursty loss
- Final loss pattern (after playout, FEC)
- Generally also bursty
24Loss to Perceived Quality
- Random vs. bursty loss
- Bursty ? lower MOS
- Effect of loss burstiness
- Sometimes very bursty loss does not lead to lower
quality
25A New Delay Model
- Conditional CCDF (C3DF)
- Allows estimation of burstiness in the late
losses introduced by (fixed) playout algorithm
26Objective vs. Subjective MOS
- Algorithms PESQ, PSQM, PSQM, MNB, EMBSD
Using original linear 16 samples as reference
signal
Using G.729 (no loss) clip as reference signal
27Objective MOS Correlation
- Stronger saturation effect observed for MNB1
and MNB2, but not for PESQ
Linear-16 reference signal
G.729 reference signal
28Auditory Distance vs. MOS
- EMBSD and PSQM appear to have the largest
spread, i.e., least correlation w. MOS - PSQM seems to be similar to MNB in terms of
correlation
29Auditory Distance vs. MOS
Linear-16 reference signal
G.729 reference signal
30Objective MOS Correlation
Algorithm Test set 1 Test set 1 Test set 2 Test set 2
Algorithm ?l16 ?g729 ?l16 ?g729
MNB1 0.897 0.885 0.767 0.798
MNB2 0.910 0.935 0.844 0.870
PESQ 0.888 0.902 0.892 0.910
31ASR as a MOS predictor
- Evaluation of automatic speech recognition (ASR)
based MOS prediction - IBM ViaVoice Linux version
- Codec used G.729
- Performance metric
- absolute word recognition ratio
- relative word recognition ratio
32Recognition Ratio vs. MOS
- Both MOS and Rabs decrease w.r.t loss
- Then, eliminate middle variable p
33Speaker Dependency Check
- Absolute performance is speaker-dependent
- But relative word recognition ratio is not
34Speech Intelligibility Results
- Human listeners are asked to do transcription
- Human recognition result curves are less smooth
than MOS curves.
35Voice On-Off Patterns
- Past study finds spurt gap distributions to be
exponential - Modern voice codecs and silence detectors have
different behaviors
36Voice Traffic Aggregation
- Simulation environment
- DiffServ token bucket filter
- Exponential, CDF and trace-based model
simulations - N voice sources
- Token buffer size B (packets)
- R ratio of reserved vs. peak bandwidth
- Key performance figure
- Probability of out-of-profile packet
37Aggregation Simulation Results
- Results based on G.729 VAD
- CDF model resembles trace model in most cases
- Exponential (traditional) model
- Under-predicts out-of-profile packet probability
- The under-prediction ratio increases as token
buffer size B increases
38Simulation Results, contd.
- Results based on NeVoT SD (default parameters
high threshold, long hangover) - Similar behavior, although the gap between
exponential and CDF model is smaller for NeVoT
case
39Comparisons of FEC and LBR
- Forward error correction
- Bit-exact recovery
- No decoder state drift upon recovery
- Low bit-rate redundancy (LBR)
- Just the opposite to FEC
- Design of an optimal LBR algorithm
- State repair via redundant codec
- Optimal packet alignment
- MOS quality verified to be better than the rat
LBR - Allows a more fair comparison with FEC
40MOS Quality of FEC vs. LBR
- FEC shows a substantial and consistent advantage
over LBR - This is true for all LBR configurations we tested
- Main codec is G.729 except for AMR LBR
DoD-CELP LBR
DoD-LPC LBR
41MOS of FEC vs. LBR, contd.
- AMR LBR narrowest gap with FEC
- (Not shown here) FEC out-performs LBR under
random loss as well
G.723.1 LBR
AMR LBR
42Optimizing FEC Quality
- Packet interval? ? loss burstiness? ? FEC
efficiency ? - Result FEC MOS performance also improves
43Optimizing Conversational MOS for FEC
- A larger packet interval ? more delay
- Trade-off between quality and delay
- The E-model
- Considers both delay and loss (and many other
transmission quality factors) - Optimizing FEC MOS with the E-model
44Optimizing FEC MOS, contd.
- Validating E-model based prediction with real MOS
test results
45SIP personal mobility
46Programmable service creation
API servlets sip-cgi CPL
language-independent no Java only yes own
secure no mostly can be yes
end user service creation no yes power users yes
GUI tools no no no yes
Multimedia some yes yes yes
call creation yes no no no
47APIs (e.g., JAIN)
- Tradition of TAPI, JTAPI, ...
- Typically, call model
- Treat calls as objects to be manipulated
- e.g., JAIN
- bearer independent (PSTN, IP, ATM)
- protocol-independent (ISUP, SIP, H.323, BICC,
...) - protocol APIs and application APIs
48SIP servlets
- Servlet runs in SIP server
- Receives SIP objects and processes them
- Example call rejection application
- import org.ietf.sip.
- public class RejectServlet extends
SipServletAdapter - protected int statusCode
- protected String reasonPhrase
- public void init(ServletConfig config)
- super.init(config)
- try
- statusCode Integer.parseInt(getInitParam
eter("status-code")) - reasonPhrase getInitParameter("reason-ph
rase") - catch (Exception _) ...
-
- public boolean doInvite(SipRequest req)
- SipResponse res req.createResponse()
- res.setStatus(statusCode, reasonPhrase)
- res.send()
- return true
49sip-cgi
- web common gateway interface (cgi)
- oldest (and still most commonly used) interface
for dynamic content generation - web server invokes process and passes HTTP
request via - stdin (POST body)
- environment variables ? HTTP headers, URL
- arguments as POST body or GET headers
(?arg1var1arg2var2) - new process for each request ? not very efficient
- but easy to learn, robust (no state)
- support from just about any programming language
(C, Perl, Tcl, Python, VisualBasic, ...) - Adapt cgi model to SIP ? sip-cgi
- RFC 3050
50sip-cgi
- Designed for SIP proxies and end systems
- call routing
- controlling forking
- call rejection
- call modification (Priority, Call-Info,
Alert-Info) - cgi once per HTTP request
- sip-cgi maintain state via an opaque token
- script gets body of request on stdin
- script gets SIP headers via environment variables
- initiates actions via stdout
- proxy request
- return response
- generate request
- generate response
51sip-cgi examples
- Block _at_vinylsiding.com
- if (defined ENVSIP_FROM ENVSIP_FROM
"sip_at_vinylsiding.com") - print "SIP/2.0 600 I can't talk right
now\n\n" -
- Make calls from boss urgent
- if (defined ENVSIP_FROM ENVSIP_FROM
/sipboss_at_mycompany.com/) - foreach reg (get_regs())
- print "CGI-PROXY-REQUEST reg SIP/2.0\n"
- print "Priority urgent\n\n"
-
52Call Processing Language (CPL)
- XML-based language for processing requests
- intentionally restricted to branching and
subroutines - no variables, no loops
- thus, easily represented graphically
- mostly used for SIP, but protocol-independent
- integrates notion of calendaring (time ranges)
- structured tree describing actions performed on
call setup event - top-level events incoming and outgoing
53CPL
- Location set stored as implicit global variable
- operations can add, filter and delete entries
- Switches
- address
- language
- time, using CALSCH notation (e.g., exported from
Outlook) - priority
- Proxy node proxies request and then branches on
response (busy, redirection, noanswer, ...) - Reject and redirect perform corresponding
protocol actions - Supports abstract logging and email operation
54CPL example
55CPL example
- lt?xml version"1.0" ?gt
- lt!DOCTYPE call SYSTEM "cpl.dtd"gt
- ltcplgt
- ltincominggt
- ltlookup source"http//www.example.com/cgi-bin
/locate.cgi?userjones" - timeout"8"gt
- ltsuccessgt
- ltproxy /gt
- lt/successgt
- ltfailuregt
- ltmail url"mailtojones_at_example.comSubjec
tlookup20failed" /gt - lt/failuregt
- lt/lookupgt
- lt/incominggt
- lt/cplgt
56CPL example anonymous call screening
- ltcplgt
- ltincominggt
- ltaddress-switch field"origin" subfield"user"gt
- ltaddress is"anonymous"gt
- ltreject status"reject"
- reason"I don't accept anonymous calls" /gt
- lt/addressgt
- lt/address-switchgt
- lt/incominggt
- lt/cplgt
57Emergency services
- Two types of emergency services
- emergency calls ("911", "112")
- emergency notification ("inverse 911")
- emergency calls are hard
- PSTN gateway dialing 911 may be located anywhere,
far away from IP phone - VPNs ? IP address may not reveal network location
58Emergency calls
- Work for both "legacy" PSAPs and IP-based PSAPs
- Define "sos" universal emergency address
- find location of phone based on
- street address ? geocoding ? long/lat, or
- mobile longitude, latitude
- find appropriate jurisdiction and PSAP
- find ESR (routing number) ? call appears like 911
call - convey location to PSAP
59Where is the phone?
- FCC requirement ?50m 67, ?150m 95
- Regular GPS doesn't work well
- doesn't work indoors
- long time to first fix 30"-15'
- assisted GPS (A-GPS)
- HDTV-based
- Landline and 802.11 phones
- LAN jack tracing via traceroute, ARP, Cisco
Discovery Protocol (CDP) and SNMP vLAN tables - 802.11 field strength triangulation
- hardware identification
- IR/RF tags
- user entry
60911 deployment
61Emergency notification
- notify public officials and citizens of
emergencies - "tornado coming"
- "fugitive alert"
- current systems are typically single-mode (fax,
telex, phone, TV, loudspeaker) - don't scale well
- very limited information content
- don't reach citizens outside calling area
- people at work
- hard to authenticate
62SIP-based emergency notification
- SIP has scalable event notification feature
- use for hierarchical notification reflecting
civil lines of authority - use XML/WSDL message bodies to semantically
describe emergency - location
- type of emergency
- instructions
- ...
- allow automated reaction
- routing to legacy systems (pagers, police radios)
- translation
63Emergency notification
64Conclusion
- IP telephony long history, finally being
commercially deployed slowly - slow migration
- (larger) enterprise PBX
- core networks (Genuity)
- voice quality evaluation without human subjects ?
traffic measurements - service creation "web-enabling" VoIP
- emergency services as precondition to deployment