voip-tutorial - Computer Science & Engineering

advertisement
Internet Telephony: VoIP, SIP & more
Shivkumar Kalyanaraman
: “shiv kalyanaraman rpi”
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
1
Adapted from slides of Henning Schulzrinne, Doug Moeller
Overview





Telephony: history and evolution
IP Telephony: What, Why & Where?
 Adding interactive multimedia to the web
 Being able to do telephony on IP with a variety of devices
 Consumer & business markets
 Key element of convergence in carrier infrastructure
Basic IP telephony model
Protocols: SIP, H.323, RTP, Coding schemes, Megaco
Future: Invisible IP telephony and control of appliances
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
2
What is VoIP?
Why VoIP?
Where is VoIP Today?
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
3
What is VoIP?

VoIP = “Voice over IP”



Complements or replaces other Voice-over-data architecture




Transmission of telephony services via IP infrastructure
=> need history/concepts reg. both “telephony” (or “voice”) and “IP”
Voice-over-TDM
Voice-over-Frame-Relay
Voice-over-ATM
First proprietary IP Telephony implementations in 1994,
VoIP-related standards available 1996


Buzzwords related to VoIP:
H.323 v2, SIP, MEGACO/H.248, Sigtrans
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
4
What is VoIP? Protocol Soup
“The nice thing about standards is that you
have so many to choose from; furthermore,
if you do not like any of them, you can just
wait for next year’s model.” [Tanenbaum]
H.GCP
H.245
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
5
Telephony over IP standards bodies






ITU - International Telecommunication Union
 http://www.itu.org
IETF - Internet Engineering Task Force.
 http://www.ietf.org
ETSI - European Telecommunications Standards Institute
 http://www.etsi.org/tiphon
ANSI - American National Standards Institute
 http://www.ansi.org
TIA - Telecommunications Industry Association
 http://www.tiaonline.org
IEEE - Institute for Electrical and Electronics Engineers
 http://www.ieee.org
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
6
Why VoIP? Telephony: Mature Industry
AT&T Divestiture
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
7
Why VoIP: Price/call plummeting due to overcapacity
AT&T Divestiture
1996
deregulation
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
8
Relevant Telecom Industry Trends



1984: AT&T breakup: baby bells vs long distance carriers
1996: Telecom deregulation, Internet takeoff
Late 1990s: explosion of fiber capacity in long-distance + many new
carriers







Long-distance prices plummet
Despite internet, the last-mile capacity did not grow fast enough
2000s: shakeout & consolidation in developed countries
Wireless substitution in last mile => cell phone instead of land-lines
 Developing countries leap frog to cell phones
 3G, WiMax => broadband, VoIP & mobility
Broadband rollouts happening slowly, but picking up steam now.
Cable offering converged & bundled services:
 digital cable, VoIP, video
Recent mergers: AT&T (long-distance & data network provider) bought by
SBC (baby bell); Verizon/Qwest vs MCI saga…
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
9
Why VoIP ? Data vs Voice Traffic
Note: quantity
 quality
 value-added
Interactive svcs
(phone, cell, sms)
still dominate on a
$$-per-Mbps basis
Infrastructure convergence: Since we are building future networks
for data, can we slowly junk the voice infrastructure and
move over to IP?
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
10
Trends: Total Phone vs Data Revenues
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
11
Motivations and drivers
Class-4/5 switches bulky,
expensive. Incentive to switch
to cheaper easily managed IP
Voice
PSTN
Class 4
switch
Class 5
switch
Users
Class 5
switch
ISDN Switch
Data
Initial gateway between
PSTN and Internet was
H.323. Gateway did
signaling, call control,
translation in one box. Not
scalable.
Users
H.323 gateway
Packet networks
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
12
Voice Over IP Marketplace Drivers







Rate arbitrage declining but still has importance as cost driver
 TDM origination and termination with IP transport in the WAN
 International settlement and domestic access cost avoidance
Enterprises seeking to save on intra-company calls and faxes on converged network
Emergence of native IP origination environments
 IP PBX, IP Phones, Soft Phones, Multimedia on the LAN
 3G Wireless, Broadband Networks
Companies: web-based call centers/web callback/e-commerce with IP Enablement
New network-based IP features and services
 Hosted IP PBX/IP Centrex , Unified Messaging, Multimedia Conferencing
 Presence: Mobility, Follow me, Teleworker, Voice Portal Services, WiFi
Technology maturing with open standards for easier, faster innovation
Converging Local, long-distance (LD) and data services
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
13
VoIP Volumes Are Accelerating While Adoption of
Applications is Growing
M of
Minutes
VoIP VPN Traffic
Enterprise Adoption of VoIP / IPT Applications
200000
180000
160000
140000
120000
100000
80000
60000
40000
20000
0
Respondents
2001
2002
2003
2004
North America
M of
Minutes
2005
2006
2007
Rest of the World
Virtual PBX + Managed IP PBX traffic
350000
300000
Source: Giga Group, "Next Generation IP Telephony Applications
Deliver Strategic Business Value", October 20, 2003
250000
200000
•
150000
100000
50000
0
2001
2002
2003
2004
North America
2005
2006
2007
•
Rest of the World
Source: Probe Research Inc.: Reaching the Big Guys + Global Enterprise
Forecast. September 2002
VoIP VPNs will continue to be driven by
increased IPT deployments in larger
enterprises, coupled with economic benefits
accruing, especially for MNCs
IPT Deployments are the leading edge
market driver for the development of
converged LANs and WANs
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
14
Drivers Are Evolving From Cost Savings to Added
Business Value…
Cost Savings
• Toll By-Pass
• Effective Use of Bandwidth
• Personnel / Staffing Efficiencies
• Less Expensive Moves, Adds Changes
• Convergence / Consolidation
• Decreased Capital
• Upgrading to an IP PBX
Percentage
IP Phones
Performing
Functions
Other Than
POTS
Increased Investment Protection
• Contact Center Functions
• Future Proofing Infrastructure
• Leveraging embedded infrastructure with
a phased roll-out
• Networking Expertise for Integration
From Concept to Deployment
Business
Case
Justification
Based on
Cost Savings
Business Case
Justification
Based on
Investment
Protection
Business Case
Justification
Based on
Business
Value
V2 Apps
V1 Apps
2002
2003
2004
2005
V3 Apps
2006
2007
2008
V1 Apps - e.g. IP-PBX, Basic Call Functions, Branch offices, Toll-bypass
V2 Apps - e.g. Call Center Functions, Messaging, Administration Tools and Reports
V3 Apps - e.g. Unified Communications, Application Integration With Communications
Gartner Group, Sept. 16, 2003
Optimized Business Value
• Services over IP
• Consistent Client / User Experience
• Integrated Infrastructure
• End-to-End Interoperability
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
15
Summary: Why VoIP?

Cost reduction:
Toll by-pass
 WAN Cost Reduction
 Lowered Infrastructure Costs


Operational Improvement:
Simplification of Routing Administration
 LAN/Campus Integration
 Policy and Directory Consolidation


Business Tool Integration:
Voice mail, email and fax mail integration
 Mobility enabled by IP networking
 Web + Overseas Call Centers
 Collaborative applications
 New Integrated Applications

3Cs: “Convergence” & “Costs” & “Competition”
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
16
Where is VoIP? Consumer VoIP Markets

Convergence & Competition
 Vonage: pure VoIP CLEC (300K subscribers)
 Cable companies:
 Eg: Time Warner (220K subscribers and signing on 10K per week
(end of 2004)):
 Bundled with digital cable services
 Skype (computer-computer p2p VoIP): tens of millions…
 Also has a WiFi service & a product co-developed by Motorola
(over 3G networks)
 Long-distance providers: AT&T CallVantage
 Local (ILECs): Verizon

Future: convergence of VoIP + WiMax (802.16) as a open low-cost
competitor to 3G wireless (closed system)
 Combines: broadband Internet, mobility and VoIP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
17
Consumer VoIP over broadband
Broadband Infrastructure
Residential
Media Gateway
Media Gateway Controller
Traditional phone
Signaling and media gateways
To reach PSTN or other networks
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
18
Consumer VoIP at home with cable
PacketCable standard with DOCSIS 1.1 access infrastructure
Call Management Server
Cable Modem Term. Sys.
Media
Gateway
MGC
Signaling
Gateway
Cable Modem
MTA
(Media Terminal Adapter)
Rensselaer Polytechnic Institute
Shivkumar Kalyanaraman
Other access mechanisms
will similarly hand over to an MGC
19
Consumer VoIP: AT&T CallVantage

New consumer services:
 Personal conferencing: earlier available to businesses only
 Prepaid Calling cards offering personal conferencing
 Portable TA (terminal adaptor): can plug into any ethernet
jack or WiFi (eg: many hotels providing free internet)
 Universal messaging: voice messages in email
 LocateMe,
 Do-Not-Disturb,
 Unified Portal
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
20
Skype: p2p VoIP
over Internet



Skype is entirely peer-topeer and is equivalent to
two H.323 terminals or 2
SIP terminals talking to
each other
 Provides a namespace
 Efficient coding of voice
packets
Instant messaging with
voice
Uses Kazaa-like p2p
directory + secure
authentication (login
server) and e2e encryption
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
21
VoIP over Wireless

Cellular networks with 2.5G and 3G have packet services
 1xRTT on 2.5 G
 EV-DO on 3G

The voice on these networks is circuit switched voice…

However, …



Combined with bluetooth or USB interfaces, a PC-based VoIP software
can do VoIP anywhere there is cellular coverage.
Or Cellphone can be a SIP terminal
Near Future: VoIP over WiMax (802.16) and WiFi (802.11)
networks
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
22
Enterprise: Private Branch Exchange (PBX)
Post-divestiture phenomenon...
7040
212-8538080
External line
7041
Corporate/Campus Private Branch
Exchange
Telephone
switch
Another
switch
7042
7043
Corporate/Campus LAN
Internet
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
23
Enterprise VoIP: Yesterday’s networks
Circuit Switched Networks (Voice)
CO
PBX
PBX
CO
CO
Headquarters
Branch Offices
Router
Router
Router
Router
Router
Packet Switched Networks (IP)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
24
Enterprise VoIP: Today’s networks
Toll by-pass
Circuit Switched Networks (Voice)
PBX
CO
PBX
CO
Headquarters
CO
Branch Offices
Router
Router
Router
Router
Router
Packet Switched Networks (IP)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
25
Enterprise VoIP: Tomorrow’s networks
Unified/Converged Networks
CO
CO
Legacy PSTN
Router
Router
Router
Router
Router
Unified Networks (Voice over IP)
Headquarters
Branch Offices
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
26
AT&T’s Integrated Infrastructure Supports Multiple
Endpoints, Access Technologies and Application Services
• VoIP infrastructure is
Voice Applications:
IP Centrex, IP Call Center and Distant Worker
•
AT&T Call
Control
Element
•
Common VoIP Connectivity Layer
NG Border
Elements
SIP Border
Elements
H.323
Border
Elements
•
MGCP
Border
Elements
•
IP/MPLS Converged Network
•
PSTN
SIP
endpoints
H.323
endpoints
MGCP
endpoints
•
converged onto a single IP/
MPLS network
Open standards architecture
based on SIP protocol
Call Control Element manages
all SIP signaling within our
core network
Access Agnostic: TDM, ATM,
Frame, MIS, IP Enabled Frame
and EVPN
Border Elements: “translate”
the multiple protocols into SIP,
provide compression and
security
Provides secure, integrated
voice / data / video access
Flexibility to support future
applications
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
27
VoIP Network Utilities
Ensure Seamless Operations

Outbound Call
• IP to Circuit Switched
Circuit Switched
Network
 Inbound Call
Network
Adjunct
• Circuit Switched to IP
Customer
Records
 800 Call
• Circuit Switched to IP
App.
Server
Media
Server
App.
Server
Gateway
 Redirect Call
Softswitch
• Circuit Switched to IP
IP Network
 SDN Call
• IP to Circuit Switched
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
28
IP-enabled circuit switches
PBX with VoIP trunk
card
 trunk between PBX
 Key system or PBX
with VoIP line card
 for IP phones

VoIP
Gateway
CO
Switch
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
29
Telephony-enabled packet networks
Enterprise Router with
telco interfaces
 T1/PRI
 BRI
 Branch office router
with telco interfaces
 BRI
 Analog trunk/line
 Analog “dongle”
 a few analog lines
for fax/phone

Central
Office
VoIP
Gateway
Router
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
30
VoFR (Voice over Frame Relay)
FRF.11 standard
 Allows for G.711, 729, 728, 726, and 723.1
 Signaling is done by transporting CAS natively or
CCS as data
 Has support for T.30 Fax, and Dialed Digits natively

Router
Switch
PBX VFRAD
VFRAD
PBX
Switch
Switch
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
31
Voice over Packet: Market Forecast – North America
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
32
Telephony: History, Review & Trends
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
33
VoIP: Where Does it Fit in Trends ?

Phase 1: Analog Networks:


Voice carried as analog signal
Phase 2: Digital Networks & the rise of the Internet



Network is digital: analog conversion at end systems
Benefits: [Noise , capacity]
Egs: TDM and T-hierarchy (T1, T3, SONET etc)
 Used as the base for the internet & private data networks

Phase 3: Voice-over-X:

Voice over Packets: VoFR, VoIP
 Key: Voice moves to a higher layer (from layer 1)
 I.e. an app over a frame relay, ATM or IP network
VoIP Sales pitch: Convergence, Choice, Services, Integration with Web
applications
[Better chance of convergence compared to earlier attempts: ISDN, BISDN]


Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
34
Public Telephony (PSTN) History
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
 1977 4ESS digital switch
 1980s Signaling System #7 (out-of-band)
 1990s Advanced Intelligent Network (AIN)

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
35
PSTN Evolution
Full Mesh
Office Switched
Office Switched
W/ Hierarchy
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
36
AT&T Telephony Hierarchy
3
4
5
2
7
10
9
1
2
1
2
2
65
3
66
228
3
3
Class 1
8
3
2
1
1
10 regional
offices
(full mesh)
6
1
229
67
230
1298 1299 1300
4
5
19,000
200 million telephones
67 sectional
offices
Class 2
230 primary
offices
Class 3
1300 toll
offices
Class 4
19,000 end
offices
Class 5
Source: Computer Networks, Andrew S. Tanenbaum
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
37
PSTN early days 40s-60s
1. In-band signaling: voice
and control channel same
2. Complex and dedicated
hardware
3. Hard to add new apps like
caller-id, 800 calling etc
Tandem Office
Local Office
Local Office
User A
User B
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
38
Advanced Intelligent Network
•Out-of-band signaling
•Introduce adv services like
caller-id easily
•Reduced wastage of circuits
in voice network
•Signaling could be over a
packet network
•E.g. SS7 stack
Signaling Network
Voice Network
Customer Info for
Advanced services
Local Office
User A
User B
Sometimes also called Intelligent Network, arrival of services
other Kalyanaraman
than voice
Shivkumar
Rensselaer Polytechnic Institute
39
The PSTN – Architecture



PSTN – Public Switched Telephone Network
Uses digital trunks between Central Office switches (CO)
Uses analog line from phones to CO
Analog line
Digital Trunks
Central
Office
(CO)
Analog
Digital
Rensselaer Polytechnic Institute
40
Analog
Shivkumar Kalyanaraman
The PSTN – Digitization



Voice frequency is 100 - 5000 Hz, with the main portion from
300 – 3400 Hz
Nyquist Theorem states that sampling must be done at twice
the highest frequency to recreate. 4000 Hz was chosen as the
maximum frequency, thus sampling at 8000 Hz
PCM = 8kHz * 8 bits per sample = 64 kbit/s
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
41
Quantization
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
42
Companding
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
43
The PSTN – Digitization
The PCM encoding used in the PSTN is standardized
as G.711 by the ITU
 Each sample is represented by one byte
 The voice signal is companded to improve voice
quality at low amplitude levels (Which most
conversation is at)
 The ITU standards for companding are called A-law
and u-law
 G.711 A-law is used in Europe
 G.711 -law is used in the US and Japan

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
44
The PSTN – Digital Voice Transmission



The digital trunks between the COs are based upon the Tcarrier system, developed in the 1960s
Each frame carries one sample (8 bits) for each 24 channels,
plus one framing bit = 193 bits
193 * 8000 (samples/sec) = 1.544 Mbit/sec = T-1
Channel 1
Channel 2
…
Channel 3
Framing Bit
TDM
Channel
1
Channel
2
Channel
3
…
Channel
24
Channel 24
1 D4 Frame
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
45
The PSTN – Architecture, Switches




PSTN – Public Switched Telephone Network
As the name says, it’s switched…
Each conversation requires a channel switched throughout the network
Circuit setup uses a separate out-of-band intelligent network (SS7)
1. Call is requested
3. Channel is established
2. Call is accepted
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
46
Legacy Digital Circuit Switch
SS7 Network
•
•
•
•
Centralized
Intelligence
Proprietary
Code
Proprietary
service
deployment
Switch Controller
Line
Card
Trunk
Card
Next Switch
Line
Card
Trunk
Card
Next Switch
Line
Card
Trunk
Card
Next Switch
Very
expensive
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
47
What’s the difference between a Class 5
and a Class 4 switch?
Class 5
 Located at the edge of the
network
 Trunk to Line/Line to Line
 Aprox. 30,000 deployed
 Services: Caller ID, call
waiting, voice mail, E911,
billing, etc.
 Ex: Lucent 5ESS, Nortel
DMS, Siemens EWSD
Class 4
 Located in the Core of the
network
 Trunk to Trunk
 Aprox. 800 deployed
 Services: call routing,
screening, 800 services,
calling cards, etc.
 Ex: Lucent 4ESS, Nortel
DMS, Siemens
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
48
The PSTN – NANP




NANP – North American Numbering Plan
3 digits area code + 3 digits office code + 4 digits phone
Each Local Exchange Carrier (LEC) switch are assigned a
block of at least 10,000 numbers
The Inter-Exchange Carrier (IXC) switches are responsible for
transmitting long distance
PSTN
4210
IXC
212
LEC
555
(212) 555 4210
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
49
The PSTN – Call Routing

Both NANP and International Numbering Plan – E.164, use
prefix-based dialing
SS7
408
PSTN
1+212+555+5644
212
5644
555
555+5644
5644
The first LEC receives a call, seeing ‘1’ as the first digit and then passing the call on to the
IXC switch. The IXC then routes the call to the remote IXC responsible for ‘212’
The ‘212’ IXC looks at the office code and passes it on to the ‘555’ LEC switch
The ‘555’ LEC switch then checks the station code and signals the appropriate phone
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
50
Telephone System Summary
Analog narrowband circuits: home-> central office
 64 kb/s continuous transmission, with compression
across oceans
 -law: 12-bit linear range -> 8-bit bytes
 Everything clocked a multiple of 125 s
 Clock synchronization  framing errors
 AT&T: 136 “toll”switches in U.S.
 Interconnected by T1, T3 lines & SONET rings
 Call establishment “out-of-band” using packetswitched signaling system (SS7)

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
51
Telecommunications Regulation History

FCC regulations cover telephony, cable, broadcast TV, wireless
etc

“Common Carrier”: provider offers conduit for a fee and does
not control the content


Customer controls content/destination of transmission & assumes
criminal/civil responsibility for content
Local monopolies formed by AT&T’s acquisition of
independent telephone companies in early 20th century



Regulation forced because they were deemed natural monopolies (only
one player possible in market due to enormous sunk cost)
FCC regulates interstate calls and state commissions regulate intra-state
and local calls
Bells + 1000 independents interconnected & expanded
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
52
Deregulation of telephony

1960s-70s: gradual de-regulation of AT&T due to technological
advances
 Terminal equipment could be owned by customers (CPE)
=> explosion in PBXs, fax machines, handsets
 Modified final judgement (MFJ): breakup of AT&T into
ILECs (incumbent local exchange carrier) and IXC (interexchange carrier) part
Long-distance opened to competition, only the local part
regulated…
 Equal access for IXCs to the ILEC network
 1+ long-distance number introduced then…

800-number portability: switching IXCs => retain 800
number
 1995: removed price controls on AT&T

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
53
US Telephone Network Structure (after
1984)
Eg: AT&T, Sprint, MCI
Eg: SBC, Verizon, BellSouth
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
54
Telecom Act of 1996

Required ILECs to open their markets through unbundling of
network elements (UNE-P), facilities ownership of CLECs….


Today UNE-P is one of the most profitable for AT&T and other longdistance players in the local market: due to apparently below-cost
regulated prices…
ILECs could compete in long-distance after demonstrating
opening of markets
Only now some ILECs are aggressively entering long distance markets
 CLECs failed due to a variety of reasons…
 But long-distance prices have dropped precipitously (AT&T’s customer
unit revenue in 2002 was $11.3 B compared to 1999 rev of $23B)
ILECs still retain over 90% of local market
Wireless substitution has caused ILECs to develop wireless business units
VoIP driven cable telephony + wireless telephony => more demand
elasticity for local services




Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
55
VoIP Technologies
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
56
IP Telephony Protocols: SIP, RTP

Session Initiation Protocol - SIP
Contact “office.com” asking for “bob”
 Locate Bob’s current phone and ring
 Bob picks up the ringing phone


Real time Transport Protocol - RTP
 Send and receive audio packets
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
57
Inside the Endpoint: Data-plane


… I.e.after signaling is done…
Consists of three components:
User
A/D
Codec
User speaks into microphone, either PC
attached, regular analogue phone or IP
phone
Device digitizes voice according to
certain codecs:
G.711 / G.723.1 / G.729 ...
IP
Gateway
Voice gets transmitted via RTP over an IP
infrastructure
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
58
Internet Multimedia Protocol Stack
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
59
Packet Encapsulation
RTP datagram
Version,
flags & CC
Payload
Type
1
1
Sequence
Number
Synchronization
Source ID
Timestamp
2
4
CSRC ID
(if any)
Codec Data
0-60
0-1460
4
UDP datagram
Source
Port Number
Destination
Port Number
2
2
Version &
header length
1
UDP length
2
Total
Length
1
2
Packet
ID
2
Ethernet Frame
Inter-frame
gap
Preamble
12
7
Flags &
TTL
Frag Offset
2
2
1
Header
Checksum
1
Source
Address
2
Destination
Address
4
Start of frame
delimiter
0-1472
Options
(if any)
4
Data
0-40
0-1480
Length or
Ethertype
Destination
Address
1
Data
Protocol
IP packet
TOS
UDP checksum
6
Source
Address
6
Data
2
0-1500
Pad Checksum
0-46
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
60
4
RTP – Real-time Transport Protocol
RTP datagram
Version,
flags & CC
Payload
Type
1
1
Sequence
Number
2
Timestamp
4
Synchronization
Source ID
4
CSRC ID
(if any)
Codec Data
0-60
0-1460
Byte 1: Version number, padding yes/no, extension y/n,
CSRC count
 Byte 2: Marker, Payload type
 Bytes 3,4: Sequence number for misordered and lost packet
detection
 Bytes 5-8: Timestamp of first data octet for jitter calculation
 Bytes 9-12: Random syncronization source ID
 Bytes 13-x: Contributing Source ID for payload
 Codec Data: the actual Voice or Video bytes

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
61
RTCP – Real-time Transport Control
Protocol



RTCP is sent between RTP endpoints periodically to provide:
 Feedback on quality of the call by sending jitter,
timestamps, and delay info back to sender
 Carry a persistent transport-level identifier called the
canonical name (CNAME) to keep track of participants and
synchronize audio with video
 Carry minimal session information (like participant IDs),
although signaling protocols do this much better
RTCP is mandatory for multicast sessions and for many pointto-point protocols, but some boxes don’t implement it
Uses another UDP port (usually RTP’s port + 1)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
62
SIP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
63
Signaling: VoIP Camps
Conferencing
Industry
Netheads
“IP over
Everything”
Circuit switch
engineers
“We over IP”
“Convergence”
ITU standards
H.323
SIP
“Softswitch”
BICC
ISDN LAN
conferencing
I-multimedia
WWW
Call Agent
SIP & H.323
BISDN, AIN
H.xxx, SIP
IP
IP
IP
“any packet”
Rensselaer Polytechnic Institute
Our focus
64
Shivkumar Kalyanaraman
H.323 vs SIP



H.323: ITU standard
 Derived from telephony protocol (Q.931)
 Follows ISDN model: same control message sequences
 Interfaces well with telephony services (H.450, Q.SIG)
SIP: IETF standard
 Derived from HTTP style signaling,
 Simple and interfaces well with IP networks, instant
messaging (IM)
 Services are not explicitly exposed to protocol
 Well-defined methods can be used to design services: most
telephony services have analogs in the SIP world today
SIP is gathering market share rapidly
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
65
SIP
Audio Codec
Video Codec
G.711
H.261
G.723
H.263
G.729
RTP
SIP
TCP
RTCP
UDP
IP
LAN Interface
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
66
SIP functionality
IETF-standardized peer-to-peer signaling protocol (RFC
2543):
 Locate user given email-style address
 Setup session (call)
 (Re)-negotiate call parameters
 Manual and automatic forwarding
 Personal mobility: different terminal, same identifier
 Call center: reach first (load distribution) or reach all
(department conference)
 Terminate and transfer calls

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
67
SIP Addresses Food Chain
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
68
Why is SIP interesting?

SIP is IETF’s equivalent for H.323 to provide a peer-based signaling
protocol for session setup, management and teardown

Simple, did not inherit the complexity of ISDN
 Analogy: CISC architecture
 Though all services arent defined as in H.323, you can compose them
with primitives

Was designed with multimedia in mind
 Just requires a MIME type
 Tremendous flexibility – can add video, text etc to a voice session,
similar to what HTTP did to Internet content

Like H.323, can use SIP end-to-end with no network infrastructure (MGC
etc.) – peer-to-peer
Lightweight  can be embedded in small devices like handhelds

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
69
IP SIP Phones and Adaptors
1
Are true Internet hosts
• Choice of application
• Choice of server
Analog phone adaptor
2
• IP appliances
Implementations
• 3Com (3)
3
• Columbia University
Palm
control
• MIC WorldCom (1)
• Mediatrix (1)
• Nortel (4)
• Siemens (5)
44
5
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
70
SIP: Personal Mobility
Users maintain a single externally visible identifier regardless
of their network location
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
71
Expand existing PBXs w/ IP phones

Transparently …
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
72
SIP as Event Notification Protocol
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
73
SIP: Presence
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
74
Light-weight signaling: Session Initiation
Protocol (SIP)
IETF MMUSIC working group
 Light-weight generic signaling protocol
 Part of IETF conference control architecture:
 SAP for “Internet TV Guide” announcements
 RTSP for media-on-demand
 SDP for describing media
 others: malloc, multicast, conference bus, . . .
 Post-dial delay: 1.5 round-trip time (with UDP)
 Network-protocol independent: UDP or TCP (or
AAL5 or X.25)

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
75
SIP components
UAC: user-agent client (caller application)
 UAS: user-agent server: accept, redirect, refuse call
 redirect server: redirect requests
 proxy server: server + client
 registrar: track user locations
 user agent = UAC + UAS
 often combine registrar + (proxy or redirect server)

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
76
SIP-based Architecture
rtspd
Quicktime
RTSP media
server
RTSP
sipconf
Telephone
SIP
conference
server
Telephone
switch
RTSP clients
sipum
SIP/RTSP
Unified
messaging
Web server
sipd
T1/E1
RTP/SIP
Web based
configuration
SIP proxy,
redirect
server
SQL
database
e*phone
Cisco 2600 gateway
Hardware
Internet (SIP)
phones
sipc
NetMeeting
sip323
SIPH.323
convertor
Software SIP
user agents
H.323
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
77
Example Call
• Bob signs up for the service from
the web as “bob@ecse.rpi.edu”
• He registers from multiple
phones
• sipd canonicalizes the destination to
sip:bob@ecse.rpi.edu
• sipd rings both e*phone and sipc
• Bob accepts the call from sipc
and starts talking
• Alice tries to reach Bob
INVITE ip:Bob.Wilson@ecse.rpi.edu
Web based
configuration
sipd
SIP proxy,
redirect
server
Call Bob
SQL
database
Web
server
e*phone
Hardware
Internet (SIP)
phones
sipc
ecse.rpi.edu
Software SIP
user agents
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
78
SIP Sessions








“Session”: exchange of data between an association of
participants
Users may move between endpoints
Users may be addressable by multiple names
Users may communicate in several different media
SIP: enables internet endpoints to
 Discover each other
 Characterize the session
Location infrastructure: proxy servers, invite/register…
 Name mapping and redirection services
Add/remove participants from session
Add/remove media from session
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
79
SIP Capabilities





User location: determination of the end system to be used for
communication;
User availability: determination of the willingness of the
called party to engage in communications;
User capabilities: determination of the media and media
parameters to be used;
Session setup: "ringing", establishment of session parameters
at both called and calling party;
Session management: including transfer and termination of
sessions, modifying session parameters, and invoking services.
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
80
What SIP is not…



SIP is not a vertically integrated communications system.
 It is a component in a multimedia architecture.
SIP does not provide services.
 Rather, SIP provides primitives that can be used to
implement different services.
 For example, SIP can locate a user and deliver an opaque
object to his current location.
SIP does not offer conference control services
 … such as floor control or voting
 SIP does not prescribe how a conference is to be managed.
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
81
SIP Structure

3 “layers”, loosely coupled, fairly independent processing stages
Lowest layer: syntax, encoding (augmented BNF)
Second layer: transport layer.
 Defines how a client sends requests and receives responses and how a
server receives requests and sends responses over the network.
Third layer: transaction layer.
 A transaction is a request sent by a client transaction (using the transport
layer) to a server transaction …
 …along with all responses to that request sent from the server
transaction back to the client.
 The transaction layer handles application-layer retransmissions,
matching of responses to requests, and application-layer timeouts

The layer above the transaction layer is called the transaction user (TU).



Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
82
SIP Design Choices
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
83
Proxy Server
1. INVITE sip:president@us.gov SIP/2.0
From: sip:tony@parliament.uk
2. INVITE sip:dcheney@wh SIP/2.0
From: sip:tony@parliament.uk
3. SIP/2.0 200 ok
From: sip:dcheney@wh
parliament.uk
Location Server
george.w.bush
1&5
tony@parliament.uk
us.gov
4
2&6
4. SIP/2.0 100 OK
From: sip:president@us.gov
Proxy server
dcheney@wh
3
5. ACK sip:president@us.gov SIP/2.0
From: sip:tony@parliament.uk
6. ACK sip:dcheney@wh SIP/2.0
From: sip:tony@parliament.uk
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
84
Redirect Server
us.gov
parliament.uk
george.w.bush
Location Server
1&3
2
tony@parliament.uk
dcheney@wh.us.gov
Redirect Server
4&6
5
1. INVITE sip:president@us.gov
From: sip:tony@parliament.uk
2. SIP/2.0 320 Moved temporarily
Contact: sip:dcheney@wh.us.gov
3. ACK sip:president@us.gov
From: sip:tony@parliament.uk
4. INVITE sip:dcheney@wh.us.gov6. ACK sip:dcheney@wh.us.gov
From: tony@parliament.uk
From: sip:tony@parliament.uk
5. SIP/2.0 200 OK
To: tony@parliament.uk
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
85
SIP Call Signaling
Assumes Endpoints(Clients)
know each other’s IP addresses
SIP
Endpoint
Signaling
Plane
SIP
Gateway
Invite
180 Ringing
200 OK
SIP + SDP
(TCP or UDP)
Ack
Bearer
Plane
RTP Stream
RTP Stream
RTCP Stream
Media (UDP)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
86
PSTN to IP Call
PBX
PSTN
External T1/CAS
1 Call 9397134
Gateway
Internal T1/CAS
(Ext:7130-7139)
2
Call 7134
Ethernet
Regular phone
(internal)
5
3
SIP server
SQL
database
sipd
sipc
Bob’s phone
4
7134 => bob
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
87
IP to PSTN Call
PBX
PSTN
External T1/CAS
5 Call 5551212
Gateway
(10.0.2.3)
Internal T1/CAS
4 Call 85551212
3
Ethernet
5551212
Regular phone
(internal, 7054)
1
Bob calls
5551212
SIP server
sipc
2
SQL
database
sipd
Use sip:85551212@10.0.2.3
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
88
Traditional voice mail system
Dial 853-8119
Alice
939-7063
Phone is ringing
Bob
853-8119
.. The person is not available now
please leave a message ...
... Your voice message ...
Disconnect
Bob can listen to his voice mails by dialing some number.
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
89
SIP-based Voicemail Architecture
Bob
INVITE bob@phone1.office.com
phone1.office.com
INVITE
bob@office.com
REGISTER bob@vm.office.com
Alice
INVITE bob@vm.office.com
vm.office.com
The voice mail server registers with the SIP proxy, sipd
Alice calls bob@office.com through SIP proxy.
SIP proxy forks the request to Bob’s phone as well as to
a voicemail
server.
Shivkumar Kalyanaraman
Rensselaer
Polytechnic Institute
90
Voicemail Architecture
Bob
phone1.office.com;
CANCEL
200 OK
Alice
200 OK
RTP/RTCP
After 10 seconds vm contacts the
RTSP server for recording.
vm accepts the call.
Sipd cancels the other branch and ...
...accepts the call from Alice.
Now user message gets recorded
Rensselaer Polytechnic Institute
91
v-mail
vm.office.com;
SETUP
rtspd
Shivkumar Kalyanaraman
IETF SIP Architecture Tour: Roundup
PSTN,
ISDN,
ATM,
etc
Registrar & Proxy
or Redirect Server
*Gateway
*User Agent
*User Agent
*User Agent
*Endpoints
Media streams: RTP/RTCP (G.911, G.723.1, … )
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
92
IETF SIP Architecture Tour: Roundup
PSTN,
ISDN,
ATM,
etc
Registrar & Proxy
or Redirect Server
*Gateway
System Management
• admission control
User Agent
• address
translation/forwarding
• Firewall bypassing
Interface to
non-IP or H.323
networks
*Endpoints
*
*User Agent
*User Agent
Media streams: RTP/RTCP (G.911, G.723.1, … )
Conferencing does
not need another
box (MCU)
End-user devices
and network proxies
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
93
IETF SIP Architecture Tour: Roundup
Registrar & Proxy
or Redirect Server
*Gateway
PSTN,
ISDN,
ATM,
etc
*User Agent
*User Agent
*User Agent
*Endpoints
Media streams: RTP/RTCP (G.911, G.723.1, … )
Components of the SIP protocol suite:
•
•
•
•
SIP
SDP
DNS
RSVP
=
=
=
=
almost all signaling, optional services, etc.
negotiation/capabilities
address translation
QoS bandwidth guarantee
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
94
SDP: Session Description Protocol

Not really a protocol – describes data carried by other
protocols
 Used by SAP, SIP, RTSP, H.332, PINT. Eg:
v=0
o=g.bell 877283459 877283519 IN IP4 132.151.1.19
s=Come here, Watson!
u=http://www.ietf.org
e=g.bell@bell-telephone.com
c=IN IP4 132.151.1.19
b=CT:64
t=3086272736 0
k=clear:manhole cover
m=audio 3456 RTP/AVP 96
a=rtpmap:96 VDVI/8000/1
m=video 3458 RTP/AVP 31
m=application 32416 udp wb
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
95
Upcoming SIP Extensions (probable)













Call Admission Control
Caller Preferences and Callee Capabilities
Call Transfer
SIP to ISUP mapping
SIP to H.323 mapping
Resource Management (QoS preconditions)
Caller/Callee Name Privacy
SIP Security
Supported Options Header
Session Timer Refresh
Distributed Call State
3rd Party Call Control
Early media for PSTN interoperability
 There

are currently 47 drafts in the pipeline!
174 Drafts have expired
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
96
SIP Dialogs (RFC 3261)






A dialog represents a peer-to-peer SIP relationship between two
user agents that persists for some time.
The dialog facilitates sequencing of messages between the user
agents and proper routing of requests between both of them.
The dialog represents a context in which to interpret SIP
messages.
A dialog is identified at each UA with a dialog ID, which
consists of a Call-ID value, a local tag and a remote tag.
A dialog contains certain pieces of state needed for further
message transmissions within the dialog.
Note: dialog is within SIP whereas sessions are outside SIP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
97
UPDATE method (RFC 3311)



INVITE method: initiation and modification of sessions.
 INVITE affects two pieces of state: session (the media streams SIP sets
up) and dialog (the state that SIP itself defines).
Issue: need to modify session aspects before the initial INVITE has been
answered.
 A re-INVITE cannot be used for this purpose: impacts the state of the
dialog, in addition to the session.
 Ans: The UPDATE method
Operation: (Offer/Answer model)
 The caller begins with an INVITE transaction, which proceeds
normally.
 Once a dialog is established, either early or confirmed, …
 … the caller can generate an UPDATE method that contains an SDP
offer for the purposes of updating the session.
 The response to the UPDATE method contains the answer.
 Similarly, once a dialog is established, the callee can send an UPDATE
offer
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
98
Locating SIP Servers (RFC 3263)

UA  Proxy  Remote Proxy  UA
 I.e Go via proxies (per-domain)
 Issue: need to locate remote proxy (use DNS)
 DNS NAPTR (type of server) and SRV (server
URL) queries are used to locate the specific
servers.
 Different transport protocols can be used
(TLS+TCP, TCP, UDP, SCTP)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
99
SIP for instant messaging: IM (RFC 3428)



IM: transfer of (short) messages in near real-time, for
conversational mode.
 Current IM: proprietary, server-based and linked to buddy
lists etc
MESSAGE method: inherits SIP’s request routing and security
features
 Message content as MIME body parts
 Sent in the context of some SIP dialog
 (note: slightly different from pager mode: asynchronous)
 Sent over TCP (or congestion controlled transports): lots of
messaging volumes…
Allows IM applications to potentially interoperate and also
provides SIP-based integration with other multimedia streams.
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
100
SIP compression (RFC 3486)


Cannot use DNS SRV and NAPTR techniques: non-scalable
(only useful for specifying transport protocol options)
Use an application-level exchange to specify compression of
signaling info
sip:alice@atlanta.com;comp=sigcomp
 Via: SIP/2.0/UDP
server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp
SIGCOMP is the compression protocol


Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
101
Device Configuration
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
102
SIP Scaling Issues
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
103
SIP Scaling (contd)
SIP Load Characteristics:
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
104
H.323
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
105
SIP vs H.323 vs Megaco
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
106
H.323 vs
SIP
Typical UserAgent Protocol stack for Internet
Terminal Control/Devices
Q.931
H.245 RAS RTCP
TPKT
TCP
Terminal Control/Devices
Codecs
Codecs
SIP SDP
RTP
RTCP
RTP
UDP
Transport Layer
IP and lower layers
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
107
SIP versus H.323
H.323 and SIP are direct competitors in peer-level call control space
H.323
SIP
Stds Body
• ITU-T SG-16
• IETF SIP
Properties
• Complex, monolithic design
• Difficult to extend & update
• Based on H.320 conferencing and
ISDN Q.931 legacy (“Bell headed”)
• Powerful for video-conferencing
• Modular, simplistic design
• Easily extended & updated
• Based on Web principals (“Internetfriendly”)
• Readily extensible beyond telephony
Stds Status
(end device)
• H.450.x series provides minimal feature
set only, and not implemented by many
• Options and versions cause interop
problems
• Slow moving
• Few real end-device features standard,
and not implemented by many
• Many options for advanced telephony
features
• Good velocity
Industry
Acceptance
• Established now, primarily system level
• Few H.323-based telephones
• End-user primarily driven by Microsoft
(NetMeeting), Siemens, Intel
• Rapidly growing industry momentum,
at system and device level
• Growing interest in SIP-phones and
soft clients
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
108
SIP-H.323: Interworking Problems
Eg: Call setup translation
H.323
SIP
Q.931 SETUP
Q.931 CONNECT
INVITE
Destination address
(Bob@office.com)
200 OK
Terminal Capabilities
Terminal Capabilities
Open Logical Channel
Open Logical Channel
Media capabilities
(audio/video)
ACK
Media transport address
(RTP/RTCP receive)
• H.323: Multi-stage dialing
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
109
H.323 Standard Series
System Control
H.245 Control
Audio Codec
Video Codec
G.711
H.261
G.723
H.263
G.729
Data Interface
T.120
H.225 Call Setup
RTP
RAS Gatekeeper
TCP
RTCP
UDP
IP
LAN Interface
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
110
Internet Telephony Protocols: H.323
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
111
H.323 (contd)

Terminals, Gateways, Gatekeepers, and Multipoint
Control Units (MCUs)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
112
H.323 Model - Gatekeeper Routed Call
Gatekeeper
Voice Channel
Endpoint
Gateway
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
113
H.323 Model - Gatekeeper Direct Call
Gatekeeper
RAS
RAS
Call Setup/Signaling
Call Control
Voice Channel
Endpoint
Gateway
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
114
H.323 Call Signaling
Assumes Endpoints(Clients)
know each other’s IP addresses
H.323
Endpoint
Setup
Alerting
H.323
H.225 (TCP) Gateway
(Q.931)
Connect
Terminal Capability Set
Signaling
Plane
Terminal Capability Set & Acknowledge
Terminal Capability Set Acknowledge
Open Logical Channel
H.245 (TCP)
Open Logical Channel & Acknowledge
Open Logical Channel Acknowledge
Bearer
Plane
Rensselaer Polytechnic Institute
RTP Stream
RTP Stream
RTCP Stream
Media (UDP)
H.323v1 (5/96) - 7 or 8 Round Trips
H.323v2 Fast Start (2/98) - 2 Round Trips
Shivkumar Kalyanaraman
115
ITU-T H.323 Architecture Tour
PSTN,
ISDN,
ATM,
etc
Gate Keeper
(GK)
*Gateway (GW)
*Multipoint Control
Unit (MCU)
Multipoint Multipoint
Controller Processor
(MC)
(MP)
*Endpoints
*Terminal
*Terminal
*Terminal
Media streams: RTP/RTCP (G.911, G.723.1, … )
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
116
ITU-T H.323 Architecture Tour
PSTN,
ISDN,
ATM,
etc
Gate Keeper
(GK)
*Gateway (GW)
*Multipoint Control
Unit (MCU)
Multipoint Multipoint
Interface
to Processor
Controller
(MC)
(MP)
non-IP networks
*Endpoints
System Management
• zone management
• b/w management
Terminal &
Terminal
Terminal
admission control
• address translation
• centralized control
(“gatekeeper
control
Media
streams: RTP/RTCP
(G.911, G.723.1, … )
mode”)
*
*
*
Conferencing
End-user devices
and network proxies
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
117
ITU-T H.323 Architecture Tour
PSTN,
ISDN,
ATM,
etc
Gate Keeper
(GK)
*Gateway (GW)
H.225.0 RAS
H.225.0 CS
H.245 CC
H.450.x SS
*Multipoint Control
Unit (MCU)
Multipoint Multipoint
Controller Processor
(MC)
(MP)
*Endpoints
*Terminal
*Terminal
*Terminal
Media streams: RTP/RTCP (G.911, G.723.1, … )
Components of the H.323 protocol suite:
• Q.931 = ISDN call signalling
• H.225.0 = RAS (registration/admissions/status) gatekeeping functions
+ Call signalling channel (CS), contains Q.931
• H.245 = Control channel (CC), negotiation/capabilities, logical signalling, maintenance
• H.450.x = Supplementary services (SS), transfer, hold, park, msg wait, … incomplete!
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
118
Gatekeeper Routed Call
1. Setup called: 5551234
caller: 9642749::10.0.0.5
2. Setup called: 5551234::192.168.0.3
caller: 9642749
3. Connect
Atlanta Zone (404)
2, 6, 10, 14
1, 5, 9, 13
Gatekeeper
132.177.120.5
223-2749
10.0.0.5
3, 7, 11, 15
4, 8, 12, 16
223-4211
192.168.0.3
4. Connect
9. Open Channel G.729/30ms, 10.0.0.5:6400
5. TCS media: G.711/30ms, G.729/30ms
10. Open Channel G.729/30ms, 10.0.0.5:6400
6. TCS media: G.711/30ms, G.729/30ms
11. Open Channel G.729/20ms, 192.168.0.3:2300
7. TCS media: G.729/20ms, G.723
12. Open Channel G.729/20ms, 192.168.0.3:2300
8. TCS media: G.729/20ms, G.723
13. ACK
14. ACK
15. ACK
16. ACK
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
119
Gatekeeper Direct Call
1. ARQ called: 5551234
caller: 9642749::10.0.0.5
2. ACF called: 5551234::192.168.0.3
3. Setup called: 5551234
caller: 9642749::10.0.0.5
Atlanta Zone (404)
1
2
223-2749
10.0.0.5
Gatekeeper
132.177.120.5
3, 5, 7, 9
223-4211
192.168.0.3
4, 6, 8, 10
4. Connect
9. ACK
5. TCS media: G.711/30ms, G.729/30ms
10. ACK
6. TCS media: G.729/20ms, G.723
7. Open Channel G.729/30ms, 10.0.0.5:6400
8. Open Channel G.729/20ms, 192.168.0.3:2300
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
120
MEGACO/H.248,
Softswitch Concepts
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
121
Master/Slave vs. Peer Comparison
Master/Slave (Thin Client)
Peer (Thick Client)
• Simple/dumb slave end device
• Stimulus control, proxy in network
• Smart/complex end device
• Functional control, peer interaction
• Lowest cost end device
• Higher cost end device
Performance
• Lower performance “local”
services
• Sometimes higher performance
distributed services (e.g.. call
control)
• Higher performance local
services
• High performance User Interface
Feature
development
• Generic development tools
• Shorter time to market for new
features on a range of end devices
• End device does not “get out of
date” as quickly
• Device-specific development
• Possibly shorter time to market for
new features on specific devices
• End device may need hardware
upgrade over time
• Update servers only
• Services can come and go
dynamically
• Update / download all end
devices in network (yikes!)
• Features more static per-device
• MEGACO/H.248, MGCP
• H.323, SIP
Operation
Cost
Feature
deployment
Protocols
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
122
Megaco/H.248
Audio Codec
Video Codec
G.711
H.261
G.723
H.263
G.729
RTP
Megaco
TCP
RTCP
UDP
IP
LAN Interface
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
123
Megaco/H.248 – Convoluted History
PacketCable Network-based Call Signaling (NCS)
based on earlier version of MGCP (March 99)
DSM-CC
Diameter
IPDC
SGCP
MGCP
NonStandard
I-RFC 2705
(proposal)
MGCP proposal
MDCP
Not fully accepted by Megaco WG,
diverged (Spring 99)
Industry
Defacto
Std.
PacketCable
NCS
(proposal)
MGCP released as
Informational RFC (Oct 99)
Megaco
Protocol
Megaco Protocol stream created, true
consensus (March 99)
ITU: H.GCP
ITU SG-16 initiates gateway
control project, H.GCP starting
from MDCP (May 99)
Megaco/H.248
WORLD
STANDARD
Agreement reached between ITU SG16 and IETF Megaco
to work together to create one standard (Summer 99)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
124
Megaco Vs MGCP
Megaco/H.248
Call Model
Termination +Context +Topology
P2P Single Media
Single Media Conferencing
P2P Multimedia
Multimedia Conferencing
Terminations
Physical & Ephemeral & Muxing
Template
Command Grouping
Transaction
Events
Event Buffering
Event Packages
(MGCP Packages
+ Additional Packages)
National Variants
Media Session Description
SDP + H.245
Protocol Encoding
Binary & Text
Transport
TCP + UDP +SCTP
Security
Authentication Header
MGC Backup
MGCP
Call Model
Termination + Connection
P2P Single Media
Single Media Conferencing
Terminations
Physical & Ephemeral
Command Grouping
Ad hoc Embedding
Event
Quarantine
Event Packages
(MGCP)
Media Session Description
SDP
Protocol Encoding
Text
Transport
UDP
Bold entries indicate
additional features in
Megaco vs. MGCP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
125
Megaco Architecture Whirlwind Tour
SS7 etc
Signalling Gateway Layer (SG)
Signalling Gateway
• Interface to SS7 signalling etc
• Not in Megaco scope (IETF Sigtran)
Sigtran
Call Agent
PSTN,
ATM,
Call control (e.g.. H.323, SIP…)
Gateway
Endpoint
Function
Media Gateway Controller
Media Gateway Control Layer (MGC)
Megaco Protocol
• Contains all call control intelligence
• Implements call level features (forward,
transfer, conference, hold, …)
etc
(e.g..H.323
H.323Gateway,
Gateway,
PSTN (e.g..
trunking
Megaco Scope
trunks Media Gateway
Terminal, MCU)
Terminal, MCU)
lines
PSTN line
Media Gateway
Media Gateway Control Protocol
• Master / slave control of MGs by MGCs
–Connection control
–Device control and configuration
• Orthogonal to call control protocols
Media Gateway Layer (MG)
Analog
Media Gateway
IP Phone
Media Gateway
• Implements connections to/from IP cloud
(through RTP)
• Implements or controls end device features
(including UI)
• No knowledge of call level features
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
126
Framework for H248/Megaco Protocol
Media Gateway
Media GW Controller
• Call processing and Service logic
• Call routing
• Inter-peer entity communication via
call control protocols (e.g. H.323, SIP,
etc)
•
•
•
•
Connection and device control
No call processing, no call model
Service-independent
Cost effective
Media GW Controller
PBX/CO
Media Gateway
Device
control
Device
control
PSTN trunking
Media Gateway
PSTN line
Media Gateway
Telephone/Residential
Media Gateway
PBX
Media
Gateway
IP (or ATM) Network
IP Phone
Media
Gateway
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
127
PBX/
CO
Megaco Framework



The MGC and MGs form a virtual IP-based switch
Looks like an H.323 Gateway to other H.323 devices, and a SIP Server to
other SIP devices
RTP (the voice media itself) is still point-to-point
Virtual Switch
SS7 Signalling
Gateway
Media Gateways
PSTN Trunking
Media Gateway
PSTN Line
Media Gateway
Telephone/Residential
Media Gateway
Sigtrans
Media GW
Controller
H.323
Megaco/
H.248
H.323
Device
SIP
RTP
Cable Modem
Media Gateway
RTP
SIP
Device
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
128
Megaco call in action (optional)
MG1
Powered On
ServiceChange: Restart
ServiceChange: Restart
Reply: ServiceChange
Modify: Look for Off-Hook
Ready
Off-Hook
MG2
MGC
Reply: Modify
Powered On
Reply: ServiceChange
Modify: Look for Off-Hook
Reply: Modify
Ready
Notify: Off-Hook
Reply: Notify
Dial Tone,
User Dials
Modify: Dial Tone, Digit Map
Reply: Modify
Notify: number “19782886160”
Reply: Notify
Add: TDM to RTP, what codecs?
Reply: Add, codec G.729
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
129
Megaco call in action (continued)
MG1
MG2
MGC
Add: TDM to RTP, ring phone
Reply: Add
Hears Ring
Phone Rings
Modify: ip of MG2, ringback
Reply: Modify
Notify: Off-hook
Reply: Notify
Off-Hook
Modify: stop ring
Reply: Modify
Modify: stop ringback, fullduplex
Stops Ring
Reply: Modify
Open RTP
Active Call/End of Invite Request
Open RTP
Notify: On-hook
Reply: Notify
Disconnect
Subtract: TDM and RTP
Reply: Subtract
On-Hook
Subtract:TDM and RTP
Reply: Subtract
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
130
Megaco/H.248 IP Phone Control
Cisco’s Skinny,
Nortel’s UNIStim,
etc., are very
similar protocols
but they’re not
interoperable
H.323 GW
MGC
H.323
Voice (RTP)
In theory the RTP
stream should go
direct phone<>GW, but many
today tandem
through the MGC
Voice (RTP)
IP Phone
Media Gateway
IP Phone
Media Gateway
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
131
Vendor Support for Standards
VoIP Protocol Support
Percentage of Vendors currentlly supporting the protocol
Percentage of vendors planning to add support within the next year
73
H.323 V1
26
H.323 V2
57
17
H.323 other versions
77
32
40
SIP (orig. RFC 2543)
66
30
SIP (Latest spec)
81
42
MGCP (orig. RFC2705)
56
30
MGCP (latest spec)
54
11
H.248 (Megaco)
64
22
Other
0
10
20
30
30
40
50
60
70
80
90
Source: Network World and Mier Communications August,
Shivkumar Kalyanaraman
Rensselaer Polytechnic
Institute 2001
132
H.323 limitations
Gateway did a lot of things that were easily
decomposed into functionally complete pieces
 Key insight from layering – separate functionally
complete pieces as far as possible.
 Quickly faced scaling problems
 Call setup and control was a complex control plane
operation
 Media translation between a variety of networks
 Take-away point  Build a distributed system that
acts as a single logical entity to the user

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
133
MGCP/H.248/Megaco
Media Gateway Controller
(MGC)
Master/Slave
SIP
Media Gateway Controller
(MGC)
MGCP
Media Gateway
Signaling Gateway
Media Gateway
Signaling Gateway
Distributed entities acting in co-ordination
Separate signaling
and voice planes, but
user unaware of it
User A
Rensselaer Polytechnic Institute
Connect to variety
of networks, home users
and other media receptors
like H.323 terminals etc
Interface to
variety of
signaling
mechanisms
Shivkumar Kalyanaraman
For examples of gateways see RFC 3435
134
Softswitch: Motivation
Class-4/5 switches bulky,
expensive. Incentive to switch
to cheaper easily managed IP
Voice
PSTN
Class 4
switch
Class 5
switch
Users
Class 5
switch
ISDN Switch
Data
Initial gateway between
PSTN and Internet was
H.323. Gateway did
signaling, call control,
translation in one box. Not
scalable.
Users
H.323 gateway
Packet networks
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
135
What is a Softswitch?
A Softswitch is a device independent software
platform designed to facilitate telecommunication
services in an IP network
•
A Softswitch controls the network
•
At a high level, a Softswitch is responsible for:
•
Protocol Conversion
•
Control and synchronization of Media Gateways
•
It’s an Architecture, NOT a box
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
136
The softswitch concept

Build a distributed system that performs the functions of the Class-4/5
switches
 Use generic computing platforms to reduce cost, size and flexibility
 E.g., DSPs or other programmable architectures
 Software components to implement many of the switching tasks give the
“soft” part of “softswitch”

The MGC which does the call control and is the brain of the system is
usually referred to as the softswitch or call agent
The gateways are dumb devices which do whatever MGC instructs them to
do
MGC therefore does
 Call setup, state maintenance, tear-down
Megaco was an earlier non-standard framework which was later
standardized jointly by ITU and IETF as MGCP



Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
137
Softswitch: What’s the big deal?

Unprecedented flexibility
 Smaller offices can have just gateways, MGCs can be at
some remote data center
 Standards-based interactions drive down costs and offer
wider architectural choices
 Fast introduction of services and applications that can again
be located remotely – only need MGCs to upgrade
 New hosted-services solutions due to flexibility

Dramatic space savings
 Sometimes as much as 10 times smaller even with all the
components of the softswitch architecture
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
138
Softswitch Architecture
•
Distributed functionality
•
Open platforms
•
Open interfaces enable
new services
•
•
Application
Server
Media Gateway
Controller
Signaling
Gateway
Leverages the
intelligence of endpoints
Media
Gateway
Media agnostic
PSTN/
End users
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
139
Softswitch - Media Gateway Controller
An SS7 Enabled Media Gateway Controller integrates the
functionality of new applications with the large installed based of
legacy systems.
Application
Server
•
Multiple controllers can
collaborate on a single
call
•
May be distributed across
the globe
•
May or may not be
collocated with SS7
Signaling Gateway
Media Gateway
Controller
Signaling
Gateway
Media
Gateway
PSTN/
End users
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
140
Softswitch - Media Gateway Controller Functions
•
•
•
Application
Server
Connections (call setup
and teardown)
Media Gateway
Controller
Events (detection and
processing)
Signaling
Gateway
Device management
(gateway startup,
shutdown, alerts)
Media
Gateway
PSTN/
End users
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
141
Softswitch - Media Gateways
Media Gateways provide interaction between audio in the
network and software controlled applications
Application
Server
•
Convert PSTN to IP
packets
•
Convert IP packets to
PSTN
•
In-band event detection
and generation
Signaling
Gateway
•
Compression
(G.7xx,…)
Media
Gateway
•
May be distributed
across the globe
PSTN/
End users
Media Gateway
Controller
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
142
MGC and MG Roles
Media Gateway Controller
MGC’s allow intelligence to
be distributed in the
network



Basic call routing
functions
Synchronization of Media
Gateways
Protocol Conversion
Media Gateway
MG’s are purpose built
specialist devices





Trunking gateways
VoATM gateways
Access gateways
Circuit switches
Network Access Servers
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
143
Softswitch - Signaling Gateway
Signaling Gateways provide interaction between the SS7 network
and Media Gateway Controllers.
Application
Server
•
•
•
Convert SS7 to IP
packets
Media Gateway
Controller
Convert IP to SS7
packets
Signaling
Gateway
Signaling transport (SS7,
SIP-T, Q.931…)
•
Extremely secure
•
Extremely fault tolerant
Media
Gateway
PSTN/
End users
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
144
Softswitch – Application Server
Application Servers(AS) provide the new services that are the
real “value-add” for Softswitches.
Application
Server
•
•
Many core features are
part of the MGC
Media Gateway
Controller
Allows new features to
be developed by third
parties
Signaling
Gateway
Media
Gateway
PSTN/
End users
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
145
Softswitch – Application Server
Application Servers(AS) Can be broken apart and distributed in
the network
LDAP
Feature Server
Directory Server
COPS
Corba
Network Elements
Policy Server
SIP
Corba
Media Server
Management Server
Connectivity Server
SIP,Parlay,JAIN
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
146
Softswitch Architecture – The protocols
Application
Server
SIP, Parlay, Jain
Media Gateway
Controller
Sigtran w/SCTP
Signaling
Gateway
H.248,MGCP
Media
Gateway
PSTN/
End users
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
147
Softswitch Architecture – Interdomain protocols
Application
Server
Application specific
Application
Server
SIP, Parlay, Jain
Media Gateway
Controller
Media Gateway
Controller
Sigtran
SIP-T,BICC
Signaling
Gateway
Signaling
Gateway
H.248,MGCP
Media
Gateway
RTP
Media
Gateway
PSTN/
End users
PSTN/
End users
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
148
SIP vs MEGACO: Summary
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
149
SIP vs MEGACO (contd)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
150
VoIP Signaling Model: Summary
End-system: SIP signaling (beat out H.323)
 PSTN gateway, with interfaces looking into PSTN and
interfaces looking into VoIP networks
 Media Gateway Controller (MGC): “intelligent”
endpoint: supervises call services end-end
 Media Gateway (MG): interface to the IP network or
PSTN: “simple” endpoint instructed by MGC
 MEGACO: MG  MGC interaction protocol;
 ITU (H.248) and IETF (RFC 3525) standard
 Replaces proprietary APIs and RFC 3435 (MGCP)

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
151
Speech Coding and
Speech Coders for VoIP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
152
Taxonomy of Speech Coders
Speech Coders
Waveform Coders
Time Domain:
PCM, ADPCM
Source Coders
Frequency Domain:
e.g. Sub-band coder,
Adaptive transform
coder
Linear
Predictive
Coder
Vocoder
Waveform coders: attempts to preserve the signal
waveform not speech specific (I.e. general A-to-D conv)
 PCM 64 kbps, ADPCM 32 kpbs, CVSDM 32 kbps
Vocoders:
 Analyse speech, extract and transmit model parameters
 Use model parameters to synthesize speech
 LPC-10: 2.4 kbps
Hybrids: Combine best of both… Eg: CELP
(used Kalyanaraman
in GSM)
Shivkumar
Rensselaer Polytechnic Institute

153
Speech Quality of Various Coders
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
154
Speech Quality (Contd)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
155
Actual Bandwidth Used
Frame
size
in ms
10
20
30
10
20
30
Packet
In bytes
G.723.1
(5.3 kbps)
G.723.1
(6.3 kbps)
G.711
(64 kbps)
G.729A
/G.729
( 8 kbps)
T-LAN
kbps
WAN
kbps
116.8
90.4
81.5
60.8
34.4
25.6
96.0
80.0
74.6
40.0
24.0
18.6
86
22.9
16.0
90
24.0
17.0
80
160
240
10
20
30
+ RTP+
UDP+IP
in bytes
120
200
280
50
60
70
LAN
frame in
bytes
146
226
306
76
86
96
30
20
60
30
24
64
Note: (1) 26-bytes Ethernet overhead was removed for WAN calculation.
(2) No backbone protocol overhead was used for WAN bandwidth.
(3) This is per voice direction, so multiply by 2 if on a shared (half-duplex) media
(4) No Ethernet Interframe Gap was included (another 12 bytes)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
156
Applications of Speech Coding
Telephony, PBX
 Wireless/Cellular Telephony
 Internet Telephony
 Speech Storage (Automated call-centers)
 High-Fidelity recordings/voice
 Speech Analysis/Synthesis
 Text-to-speech (machine generated speech)

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
157
Pulse Amplitude Modulation (PAM)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
158
Pulse Code Modulation (PCM)
* PCM = PAM + quantization
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
159
Companded PCM
•Small quantization intervals to small samples and large
intervals for large samples
• Excellent quality for BOTH voice and data
• Moderate data rate (64 kbps)
• Moderate cost: used in T1 lines etc
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
160
How it works for T1 Lines
• Companding blocks are shared by all 16 channels
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
161
Recall: Taxonomy of Speech Coders
Speech Coders
Waveform Coders
Time Domain:
PCM, ADPCM
Source Coders
Frequency Domain:
e.g. Sub-band coder,
Adaptive transform
coder
Linear
Predictive
Coder
Vocoder
Waveform coders: attempts to preserve the signal
waveform not speech specific.
 PCM 64 kbps, ADPCM 32 kpbs, CVSDM 32 kbps
Vocoders:
 Analyse speech, extract and transmit model parameters
 Use model parameters to synthesize speech
 LPC-10: 2.4 kbps
Hybrids: Combine best of both… Eg: CELP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute

162
Vocoders
Encode only perceptually important aspects of speech w/ fewer bits than
waveform coders: eg: power spectrum vs time-domain accuracy
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
163
LPC Analysis/Synthesis
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
164
Speech Generation in LPC
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
165
CELP Encoder
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
166
Example: GSM Digital Speech Coding

PCM: 64kbps too wasteful for wireless

Regular Pulse Excited -- Linear Predictive Coder (RPE-LPC) with a Long Term Predictor loop.

Subjective speech quality and complexity (related to
cost, processing delay, and power)

Information from previous samples used to predict the
current sample: linear function.

The coefficients, plus an encoded form of the residual
(predicted - actual sample), represent the signal.

20 millisecond samples: each encoded as 260 bits =>13
kbps (Full-Rate coding).
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
167
Codecs: Quality Measures
Standard
G.711
G.723.1
G.728
G.729
G.722
G.726
GSM-EF
Algorithm
PCM
MPE/ACELP
LD-CELP
CS-ACELP
Sub-band
ADPCM
ADPCM
ACELP
Bit Rate (Kbit/s)
Codec Induced Delay
(msecs)
56, 64
5.3, 6.3
16
8
64
<<1
67-97
<<2
25-35
5-10
16, 24, 32, 40
12.2
<<1
40
Resultant Voice
Quality
Excellent
Fair(5.3), Good(6.3)
Good
Good
Good-Excellent (it’s
wideband)
Fair(24), Good(40)
Good
Only G.711, G.723.1, and G.729 are popular
(because they are mandatory for several specs)
 G.711 is the best (obviously), but G.729 isn’t much
worse
 G.723.1 is HORRIBLE

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
168
Packet Encapsulation
RTP datagram
Version,
flags & CC
Payload
Type
1
1
Sequence
Number
Synchronization
Source ID
Timestamp
2
4
CSRC ID
(if any)
Codec Data
0-60
0-1460
4
UDP datagram
Source
Port Number
Destination
Port Number
2
2
Version &
header length
1
UDP length
2
Total
Length
1
2
Packet
ID
2
Ethernet Frame
Inter-frame
gap
Preamble
12
7
Flags &
TTL
Frag Offset
2
2
1
Header
Checksum
1
Source
Address
2
Destination
Address
4
Start of frame
delimiter
0-1472
Options
(if any)
4
Data
0-40
0-1480
Length or
Ethertype
Destination
Address
1
Data
Protocol
IP packet
TOS
UDP checksum
6
Source
Address
6
Data
2
0-1500
Pad Checksum
0-46
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
169
4
G.711 (10ms) Clear Channel Voice
80 byte
voice bundles
RTP Frame
UDP Datagram
Voice Payload
80
2 2 2 2 12
Source
Length
Checksum
Destination
12 4 4
Header
80
RTP Header
Destination
IP Packet
12
8
RTP Header Voice Payload
80
12
Source
Type
Destination
IP into Ethernet
Source
IP into Frame Relay
Flag
5
CRC.
4
120
12
21
IP Payload
+
48
IP Payload
Header
Voice Payload
IP Payload
Address
IP into ATM
RTP Header
120
6 6 2
8
Preamble
UDP Header
5
Frame Check
+
48
IP Payload
Header
Header
5
24
16
IP Payload
Padding
Flag
8
Trailer
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
170
G.729 (30ms) Clear Channel Voice
30 byte
voice bundles
RTP Frame
UDP Datagram
Voice Payload
30
2 2 2 2 12
Source
Length
Checksum
Destination
12 4 4
Header
30
RTP Header
Destination
IP Packet
12
8
RTP Header Voice Payload
30
12
Source
Type
Destination
IP into Ethernet
Preamble
IP into Frame Relay
UDP Header
Source
Flag
CRC.
4
IP Payload
70
12
21
IP Payload
Address
IP into ATM
Voice Payload
70
6 6 2
8
RTP Header
48
5
Frame Check
+
5
IP Payload
Header
Header
22
18
IP Payload
Padding
Flag
8
Trailer
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
171
G.729 (20ms) Clear Channel Voice
20 byte
voice bundles
RTP Frame
UDP Datagram
Voice Payload
20
2 2 2 2 12
Source
Length
Checksum
Destination
12 4 4
Header
20
RTP Header
Destination
IP Packet
12
8
RTP Header Voice Payload
20
12
Source
Type
Destination
IP into Ethernet
Preamble
IP into Frame Relay
UDP Header
Source
Flag
CRC.
4
IP Payload
60
12
21
IP Payload
Address
IP into ATM
Voice Payload
60
6 6 2
8
RTP Header
48
5
Frame Check
+
5
IP Payload
Header
Header
12
28
IP Payload
Padding
Flag
8
Trailer
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
172
G.723.1 (30ms) Clear Channel Voice
20-24 byte
voice bundles
RTP Frame
UDP Datagram
Voice Payload
20-24
2 2 2 2 12
Source
Length
Checksum
Destination
12 4 4
Header
20-24
RTP Header
Destination
IP Packet
12
8
RTP Header Voice Payload
20-24
12
Source
Type
Destination
IP into Ethernet
Preamble
IP into Frame Relay
UDP Header
Source
Flag
CRC.
4
IP Payload
60-64
12
21
IP Payload
Address
IP into ATM
Voice Payload
60-64
6 6 2
8
RTP Header
48
5
Frame Check
+
5
IP Payload
Header
Header
Flag
12-16 28-24 8
IP Payload
Padding
Trailer
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
173
Coding Technology Side-effects


Coded VoIP is NOT the same as a telephone line (I.e. it is not a
content-neutral “carrier”):
 Without special support, you cannot send “fax” or “modem
traffic” over VoIP
 The “carrier” is now IP (or some data-transport protocol like
frame-relay or ATM)
 The same is true for 3G or GSM telephony
 Why? Voice is encoded and the encoding works only for
voice! (it is no longer a 64 kbps bit stream)
Fax support: Fax Passthru, T.38 fax Relay
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
174
Voice Quality: Loss Tolerance


Voice codecs are unevenly tolerant of packet loss,
 but loss above 2 to 5 percent will have a perceptible
effect on quality.
 Losses also associated with higher jitter
 1-way delay > 150 milliseconds, => trouble
 Jitter buffer (major component of delay budget)
 Capacity reservations & priority for key packets: setup
through RSVP
 Priority: using TOS bits: 8 levels of precedence
Carrier networks use some combination of:
 MPLS (traffic engineering, stable routing) and
 Diff-serv (expedited forwarding) to provide superior
service for VoIP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
175
VoIP QoS Myths

Packet voice=> voice could take multiple paths or failover.
 But it usually does not…

VoIP is sensitive to routing failures or congestion in paths
 OSPF and BGP convergence times too bad for VoIP:
SONET and (now) MPLS much better

However, FEC packets for VoIP can be sent on a separate path
or on the same path:
 hedge against performance fluctuations (eg: congestion) on
the primary path,
 but limited hedge against failure of the primary path.
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
176
Voice codecs: Summary





G.711
 uncompressed PCM audio stream
 8ks/s of 8 bit values = 64kbps
 packet “sizes” = 10, 20, 30 and 60ms
G.722 - Wideband (7kHz)
G.726
 ADPCM - 10,20,30,60ms - 32kbps
G.723.1
 MLQ - 30ms - 5.3 or 6.3kbps
 Silence suppression
G.729
 CS-ACELP - 10, 20, 30ms - 8kbps
 Annex B adds silence suppression
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
177
Recap: Speech Quality of Various Coders
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
178
Miscl: Other standards, ENUM, E-911,
Presence etc
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
179
Sigtrans (Signaling Transport)
 Signalling transport protocol and adaptation layers for SG to
MGC communication, and for SG to SG communication
 Signalling Gateways can be stand-alone or co-located with an
MGC
Signaling
Gateway
Signaling
Gateway
Sigtrans
SS7
CO
Virtual Switch
Trunk Gateway
D-channel
PRI
B-channels
PBX
Signalling Gateway
Media Gateway
Sigtrans
SIP, H.323
Megaco/
H.248
Media GW
Controller
Virtual
Switch
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
180
RTP
SCTP (Stream Control Transmission Protocol)




Sigtrans needs to carry SS7
Needed a reliable transport mechanism (like TCP) without the
overhead of a connection-oriented protocol
SCTP created: like UDP, but with acknowledgment,
fragmentation, and congestion-avoidance
This has much broader use than just carrying SS7: it’s being
looked at for SIP, RTP, T.38, and more...
6 - Presentation
5 - Session
4 - Transport
3 - Network
2 - Link
Rensselaer Polytechnic
1 -Institute
Physical
User Adaptation Modules
SCTP
IP
MLPPP / FR / ATM
Shivkumar Kalyanaraman
Ethernet / SONET/Serial
181
(1) SS7 Signaling Using IP Transport
SSP
The IETF M2UA
MTP2-User Adaptation Layer
from the Sigtran WG
Applications
SSP
Applications
STP
TCAP
TCAP
ISUP
ISUP
SCCP
SCCP
MTP3
MTP2
MTP3*
MTP2
MTP3
M2UA
M2UA
SCTP
SCTP
IP
IP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
182
(2) SS7 / IP Interworking
SSP
The IETF M3UA
MTP3-User Adaptation Layer
from the Sigtran WG
SS7 SG
Call
Processing
Application
MGC
Call
Processing
Application
Nodal
Inter-working Function
ISUP
ISUP
MTP3
MTP3
MTP2
MTP2
M3UA
M3UA
SCTP
SCTP
IP
IP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
183
BICC (Bearer Independent Call Control)



Offers a migration path from SS7/TDM to packet-based
voice
Defines Interface Serving Node for Bearer, Bearer Control,
and Call Serving Functions
Specifies Transit Serving Nodes to change bearer types,
and Gateway Serving Node to transit operators
BICC ISN
ISUP
BICC ISN
BICC
ISUP
PSTN
PSTN
TDM
TDM
Class 4 Switch
Class 4 Switch
Data Network
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
184
VPIM (Voice Profile for Internet Mail)





Uses SMTP to send/receive voice/faxmail messages
Attaches messages as wav/mpeg/tiff files in MIME
Useful for transferring across voicemail systems
Adds more useful info: vcard, signature, multiple addresses
POP3 still used to download voicemail to your favorite email
client (Outlook, Eudora, Pine, etc.)
POP3
Email
Browser
VPIM
Plain
Phone
SIP/H.323
PBX
Unified
Messaging
System
Unified
Messaging
System
SIP
Device
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
185
TRIP – Telephony Routing over IP
TRIP is a protocol for advertising the reachability of telephony
destinations between location servers, and for advertising
attributes of the routes to those destinations.
Can serve as a routing protocol for any signaling protocol
 TRIP is used to distribute telephony routing information
between telephony administrative domains.
 TRIP is essentially BGP for phone numbers and the protocol
is actually based on BGP-4

Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
186
Midcom (Middlebox Communication)
1. INVITE sip:president@us.gov SIP/2.0
From: sip:tony@parliament.uk
2. INVITE sip:dcheney@wh SIP/2.0
From: sip:tony@parliament.uk
3. SIP/2.0 200 ok
From: sip:dcheney@wh
parliament.uk
Location Server
george.w.bush
1&5
tony@parliament.uk
us.gov
4
2&6
4. SIP/2.0 100 OK
From: sip:president@us.gov
Firewall
Proxy server
dcheney@wh
3
5. ACK sip:president@us.gov SIP/2.0
From: sip:tony@parliament.uk
3.5 Midcom Protocol
6. ACK sip:dcheney@wh SIP/2.0
From: sip:tony@parliament.uk
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
187
Mediation and Billing
Current State
 Non
real time
 Non-scalable
 Limited functionality
 No revenue assurance capabilities
 Proprietary CDR formats
 No OSS functionality (fraud, churn, etc.)
 Mainly stand alone systems (no integration with the
legacy systems)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
188
Call Detail Records
• To be able to run reports and bill, Call Detail Records (CDRs)
must be recorded for each call:
Time
Reason
From
16:45
Call req. 5551212
To
Duratio
n
Details
6663434
01:45
Normal disc.
With VoIP far more detail is necessary:
 Packets transmitted
 Packets lost
 Jitter
 Delay
 Call Control / Gateway used
 Codec used
…
Rensselaer Polytechnic Institute
189
Shivkumar Kalyanaraman

Mediation and Billing Requirements
Complete call details including
 Call descriptors

caller ID, called #, time, length, disconnect reason, QoS requested, etc.,
Complete network QoS information (dropped packets, trunk
failure, etc.)
 Complete application level QoS (dropped frames, disconnect
reason, CODEC type, etc.)
Carrier-grade solution
 Scalable



Large number of calls/sec

Cover large, distributed networks
 Real
Time

Revenue Assurance
 99.999% accuracy
 Audit capabilities
 Highly available

Support of standards
Integration with other OSS/BSS systems (fraud, churn, etc)

 Fault
tolerant
 Local cache
 Roll back
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
190
IPDR – IP Data Records
The purpose of the IPDR initiative is to define the
essential elements of data exchange between network
elements, operation support systems and business
support systems. Specific goals include:
 Define
an open, flexible record format (the IPDR
record) for exchanging usage information.
 Define essential parameters for any IP transaction.
 Provide an extension mechanism so network
elements and support systems exchange optional
usage metrics for a particular service.
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
191
ENUM vs DNS



DNS (or internet) names: interpreted right to left:
 Eg: www.rpi.edu
Telephone numbers: interpreted left to right:
 Eg: +1 518 276 8979
ENUM: (RFC 3761)
 telephone numbers written DNS-style,
Rooted at the domain e164.arpa.
 So, 1.212.543.6789 becomes 9.8.7.6.3.4.5.2.1.2.1.e164.arpa.
 When queried, DNS can return an IP address for the telephone
number,
 or it can return a rule for re-formatting the original number
 For example, rules can be returned to rewrite 1.212.543.6789 as
sip:36789@nyc-gw.example.net, sip:caryfitz@serviceShivkumar Kalyanaraman
Rensselaer Polytechnic Institute
provider.com.

192
Continuity of Telephone Svcs in VoIP

A number of basic features remain same:
 Phone looks and behaves like a phone
 DTMF (touch-tone) features: mid-call signaling
 E.911 will provide 911 location services
 Bearer (“data-plane”) is separated from signaling
(“control-plane”) and is handled differently
 But, unlike telephony, it is multiplexed on the
same network
 Interfaces smoothly with internet applications: IM,
Web, email…
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
193
E911 - Requirements

911 Services
 Power
 Need
stays on when building power fails
callers phone number and location
 Services
must be modified during a 911 call
Disable call-waiting
Disable three-party calls
Caller cannot hangup and place another call
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
194
E911 – VoIP Enhancements
VoIP has the potential of enhancing E911 functionality
 Multimedia communication
 Audio – emulate existing services
 Video – images and/or biometrics to/from emergency
technicians
 Text – for hearing impaired
 Call setup could contain medical background
 Can be locally maintained, does not a master database
 Calls can easily be forwarded or transferred
 Fast call setup times
 PSAP could easily be deployed or relocated anywhere
Internet access is available.
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
195
E911 – Using DNS to convey location

Based on network device name
pigface 192.168.200.20
GL S3.US.95401.4500 “110 Stony Point Rd.,Santa Rosa CA”

Based on Geographic location (longitude/latitude)
pigface 192.168.200.20
GPOS -38.43954 122.72821 10.0

Binary (includes precision indicator)
pigface 192.168.200.20
LOC 23 45 32 N 89 23 18 W –24m 30m
Issues


Only works if mapping between device and location is correct.
Not secure/private
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
196
Invisible Internet Telephony
VoIP technology
will appear in . . .
 Internet appliances
 home security cameras, web cams
 3G mobile terminals
 fire alarms
 chat/IM tools
 interactive multiplayer games
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
197
VoIP Reliability & Manageability


Reliability: PSTN benchmarks…
 Work all the time, except for maintenance windows
 Faults: network, hardware, software
 Duplicated systems: no upgrade downtime
 Monitors, automatic failovers
Manageability:
 accurate and flexible billing systems,
 error reporting and resolution,
 call tracing, adds/moves/changes,
 Lack of network state (IP model) makes this difficult =>
mediated calls (eg: softswitch etc reinstate some of
this…)
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
198
IPtel for appliances: “Presence”
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
199
VoIP Standards (Enterprise View)
3rd Party
Call Servers &
Gatekeepers
H.323
annex G,
SIP
Enterprise
Call
Server
H.323, SIP, Q.Sig
IP-enabled
PBX/KS
H.248,
Stimulus
H.323
H.248,
Stimulus
SIP
H.323
SIP, H.323
SIP, H.323
SIP
Gateway
RTP
RTP
Stimulus
Terminals
RTP
H.323
Gateway
Thick
Terminals
RTP
RTP
RTP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
200
VoIP Standards (Carrier View)
3rd Party
Call Agents &
Gatekeepers
H.323, SIP-T
Softswitch/
BICC
Call Agent/
MGC
SIP
SIP
Gateway
Sigtrans, Q.BICC
Megaco/
H.248
RTP
Signalling
(SS7)
Gateway
SIP
MGCP
RTP
Megaco
Gateway
MGCP
Gateway
RTP
Application/
Media Server
RTP
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
201
VoIP Summary: Big Picture
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
202
Download