When%20will%20the%20telephone%20network%20disappear? - PowerPoint PPT Presentation

About This Presentation
Title:

When%20will%20the%20telephone%20network%20disappear?

Description:

First packetized speech over SATNET between Lincoln Labs and NTA (Norway) and UCL (UK) ... to be better than the rat LBR. Allows a more 'fair' comparison ... – PowerPoint PPT presentation

Number of Views:136
Avg rating:3.0/5.0
Slides: 65
Provided by: csCol
Category:

less

Transcript and Presenter's Notes

Title: When%20will%20the%20telephone%20network%20disappear?


1
When 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)

2
Overview
  • Why voice over IP?
  • why not yet?
  • a multimedia "PBX" CINEMA
  • voice quality
  • creating services
  • emergency calls and notification

3
A 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)

4
A 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)

5
Status in 2002
  • 2000 6b wholesale, 15b minutes retail
  • 2001 10b worldwide 6 of traffic (only
    phone-to-phone)
  • e.g., net2phone 341m min/quarter

6
VoIP 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), ...

7
VoIP applications
  • PC-to-phone, PC-to-PC
  • net2phone, dialpad, iConnectHere, mediaring, ...
  • Push-to-talk (call centers, conferences)
  • eStara, edial

8
PSTN vs. Internet Telephony
PSTN
Signaling Media
Signaling Media
Internet telephony
Signaling
Signaling
Media
9
VoIP 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

10
VoIP components
  • gateways
  • analog 1-8 lines
  • T1 to multiple T3
  • IP phones

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

12
IP Centrex
13
Example 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

14
CINEMA 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
15
Experiences
  • 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

16
Experiences
  • 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

17
SIP doesnt have to be in a phone
siplava_at_cs.columbia.edu
18
QoS components
  • Dominant QoS factors
  • loss ? clipping, distortion in audio
  • delay ? lower interactivity (lt 200 ms)
  • jitter ? late loss delay

19
Delay 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

20
Loss 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

21
Perceived 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)

22
Comparison 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
23
Loss Model Comparison
  • Loss burstiness on FEC performance
  • FEC less efficient under bursty loss
  • Final loss pattern (after playout, FEC)
  • Generally also bursty

24
Loss to Perceived Quality
  • Random vs. bursty loss
  • Bursty ? lower MOS
  • Effect of loss burstiness
  • Sometimes very bursty loss does not lead to lower
    quality

25
A New Delay Model
  • Conditional CCDF (C3DF)
  • Allows estimation of burstiness in the late
    losses introduced by (fixed) playout algorithm

26
Objective 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
27
Objective MOS Correlation
  • Stronger saturation effect observed for MNB1
    and MNB2, but not for PESQ

Linear-16 reference signal
G.729 reference signal
28
Auditory 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

29
Auditory Distance vs. MOS
Linear-16 reference signal
G.729 reference signal
30
Objective 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
31
ASR 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

32
Recognition Ratio vs. MOS
  • Both MOS and Rabs decrease w.r.t loss
  • Then, eliminate middle variable p

33
Speaker Dependency Check
  • Absolute performance is speaker-dependent
  • But relative word recognition ratio is not

34
Speech Intelligibility Results
  • Human listeners are asked to do transcription
  • Human recognition result curves are less smooth
    than MOS curves.

35
Voice On-Off Patterns
  • Past study finds spurt gap distributions to be
    exponential
  • Modern voice codecs and silence detectors have
    different behaviors

36
Voice 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

37
Aggregation 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

38
Simulation 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

39
Comparisons 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

40
MOS 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
41
MOS 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
42
Optimizing FEC Quality
  • Packet interval? ? loss burstiness? ? FEC
    efficiency ?
  • Result FEC MOS performance also improves

43
Optimizing 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

44
Optimizing FEC MOS, contd.
  • Validating E-model based prediction with real MOS
    test results

45
SIP personal mobility
46
Programmable 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
47
APIs (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

48
SIP 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

49
sip-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

50
sip-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

51
sip-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"

52
Call 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

53
CPL
  • 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

54
CPL example
55
CPL 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

56
CPL 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

57
Emergency 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

58
Emergency 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

59
Where 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

60
911 deployment
61
Emergency 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

62
SIP-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

63
Emergency notification
64
Conclusion
  • 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
Write a Comment
User Comments (0)
About PowerShow.com