Internet Telephony: VoIP, SIP & more

Shivkumar Kalyanaraman
: “shiv kalyanaraman rpi”
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

2
 What is VoIP?
Why VoIP?
Where is VoIP Today?

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

3
 What is VoIP?
 VoIP = “Voice over IP”
 Transmission of telephony services via IP infrastructure
 => need history/concepts reg. both “telephony” (or “voice”) and “IP”

 Complements or replaces other Voice-over-data architecture

 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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

4
 What is VoIP? Protocol Soup
P
SG G C SDP
CP M

H.323
Megaco SIP

IPDC
MD
CP “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]
Si
gt IG
ra S
ns H.GCP Q.
H.245 VPIM
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

6
 Why VoIP? Telephony: Mature Industry
AT&T Divestiture

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

7
 Why VoIP: Price/call plummeting due to overcapacity
AT&T Divestiture

1996
deregulation

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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…

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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?
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
10
 Trends: Total Phone vs Data Revenues

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

11
 Motivations and drivers
Class-4/5 switches bulky,
expensive. Incentive to switch
PSTN
to cheaper easily managed IP
Class 4
Class 5 switch
Voice
switch Class 5
switch
Users ISDN Switch Users

Data H.323 gateway

Initial gateway between

PSTN and Internet was
H.323. Gateway did
signaling, call control, Packet networks
translation in one box. Not
scalable.
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

13
 VoIP Volumes Are Accelerating While Adoption of
M of
Applications is Growing
Minutes VoIP VPN Traffic
Enterprise Adoption of VoIP / IPT Applications
200000
180000 Respondents
160000
140000
120000
100000
80000
60000
40000
20000
0
2001 2002 2003 2004 2005 2006 2007

North America Rest of the World

M of
Minutes Virtual PBX + Managed IP PBX traffic
350000
300000
Source: Giga Group, "Next Generation IP Telephony Applications
250000
Deliver Strategic Business Value", October 20, 2003
200000
150000 • VoIP VPNs will continue to be driven by
100000 increased IPT deployments in larger
50000 enterprises, coupled with economic benefits
0
accruing, especially for MNCs
2001 2002 2003 2004 2005 2006 2007 • IPT Deployments are the leading edge
North America Rest of the World market driver for the development of
Source: Probe Research Inc.: Reaching the Big Guys + Global Enterprise
Forecast. September 2002
converged LANs and WANs

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

14
 Drivers Are Evolving From Cost Savings to Added
Business Value…
Cost Savings
• Toll By-Pass
• Effective Use of Bandwidth Business Case
• Personnel / Staffing Efficiencies Justification
• Less Expensive Moves, Adds Changes Based on
• Convergence / Consolidation
Percentage Investment
IP Phones Business Protection
• Decreased Capital Performing Case Business
• Upgrading to an IP PBX Functions
Other Than Justification Case
POTS Based on Justification
Increased Investment Protection Cost Savings Based on
• Contact Center Functions
Business
• Future Proofing Infrastructure
Value
• Leveraging embedded infrastructure with a phased
V2 Apps V3 Apps
roll-out V1 Apps
• Networking Expertise for Integration From
Concept to Deployment 2002 2003 2004 2005 2006 2007 2008

V1 Apps - e.g. IP-PBX, Basic Call Functions, Branch offices, Toll-bypass

Optimized Business Value V2 Apps - e.g. Call Center Functions, Messaging, Administration Tools and Reports
• Services over IP V3 Apps - e.g. Unified Communications, Application Integration With Communications
• Consistent Client / User Experience
• Integrated Infrastructure Gartner Group, Sept. 16, 2003
• End-to-End Interoperability

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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”

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
18
 Consumer VoIP at home with cable

PacketCable standard with DOCSIS 1.1 access infrastructure

Call Management Server

Media
Gateway
Cable Modem Term. Sys.
MGC
Signaling
Cable Modem Gateway

MTA
(Media Terminal Adapter)
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
Other access mechanisms
19 will similarly hand over to an MGC
 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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

20
 Skype: p2p VoIP
over Internet
 Skype is entirely peer-to-
peer 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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
22
 Enterprise: Private Branch Exchange (PBX)
Post-divestiture phenomenon...
7040

External line 212-8538080

7041
Corporate/Campus Private Branch Telephone
switch Another
Exchange switch
7042

7043

Corporate/Campus LAN Internet

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
26
 AT&T’s Integrated Infrastructure Supports Multiple
Endpoints, Access Technologies and Application Services
• VoIP infrastructure is
Voice Applications: converged onto a single IP/
IP Centrex, IP Call Center and Distant Worker MPLS network
• Open standards architecture
AT&T Call based on SIP protocol
Control
Element
• Call Control Element manages
all SIP signaling within our
Common VoIP Connectivity Layer core network
• Access Agnostic: TDM, ATM,
H.323 MGCP Frame, MIS, IP Enabled Frame
NG Border SIP Border Border
Elements Border
Elements Elements Elements and EVPN
• Border Elements: “translate”
the multiple protocols into SIP,
IP/MPLS Converged Network
provide compression and
security
• Provides secure, integrated
SIP H.323 MGCP voice / data / video access
PSTN endpoints endpoints endpoints • Flexibility to support future
applications

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

27
 VoIP Network Utilities
Ensure Seamless Operations
 Outbound Call
• IP to Circuit Switched Circuit Switched
Network

 Inbound Call Network

Customer
• Circuit Switched to IP Adjunct
Records

 800 Call
• Circuit Switched to IP
App. Media App.
Server Server Server Gateway
Softswitch
 Redirect Call
• Circuit Switched to IP
IP Network
 SDN Call
• IP to Circuit Switched
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
28
 IP-enabled circuit switches

VoIP
 PBX with VoIP trunk
Gateway card
 trunk between PBX
 Key system or PBX
CO with VoIP line card
 for IP phones

Switch

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

29
 Telephony-enabled packet networks

Central
 Enterprise Router with
Office telco interfaces
 T1/PRI
 BRI
 Branch office router
with telco interfaces
Router  BRI
VoIP  Analog trunk/line
Gateway  Analog “dongle”
 a few analog lines
for fax/phone
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

31
Voice over Packet: Market Forecast – North America

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

32
 Telephony: History, Review & Trends

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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, B-ISDN]

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

35
 PSTN Evolution

Full Mesh Office Switched Office Switched

W/ Hierarchy

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

36
 AT&T Telephony Hierarchy
3 4
2 5

10 regional
6 offices
1
(full mesh)

7
10
9 Class 1
8

67 sectional Class 2
1 2 3 65 66 67
offices

230 primary
1 2 3 228 229 230
offices
Class 3

1300 toll
1 2 3 1298 1299 1300
offices Class 4
19,000 end
offices Class 5
19,000
1 2 3 4 5
200 million telephones Source: Computer Networks, Andrew S. Tanenbaum

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

38
 Advanced Intelligent Network
•Out-of-band signaling
•Introduce adv services like Signaling Network
caller-id easily
•Reduced wastage of circuits
in voice network
Customer Info for
•Signaling could be over a
Voice Network Advanced services
packet network
•E.g. SS7 stack

Local Office

User A
User B

Sometimes also called Intelligent Network, arrival of services

Rensselaer Polytechnic Institute
other Kalyanaraman
Shivkumar than voice
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

Central Digital Trunks

Office
(CO)

Digital Analog
Analog Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute

40
 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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

41
 Quantization

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

42
 Companding

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

44
 The PSTN – Digital Voice Transmission
 The digital trunks between the COs are based upon the T-
carrier 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 Framing Bit
Channel 3 Channel Channel Channel Channel
TDM
1 2 3 … 24
…

Channel 24
1 D4 Frame

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

46
 Legacy Digital Circuit Switch
SS7 Network

• Centralized Switch Controller

Intelligence
Line Trunk
• Proprietary Card Card
Next Switch

Code
Line Trunk
Next Switch
• Proprietary Card Card

service
deployment
Line Trunk
Next Switch
Card Card

• Very
expensive

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

47
 What’s the difference between a Class 5
and a Class 4 switch?
Class 5 Class 4
 Located at the edge of the  Located in the Core of the
network network
 Trunk to Line/Line to Line  Trunk to Trunk
 Aprox. 30,000 deployed  Aprox. 800 deployed
 Services: Caller ID, call  Services: call routing,
waiting, voice mail, E911, screening, 800 services,
billing, etc. calling cards, etc.
 Ex: Lucent 5ESS, Nortel  Ex: Lucent 4ESS, Nortel
DMS, Siemens EWSD DMS, Siemens

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 LEC
212 555
(212) 555 4210
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
49
 The PSTN – Call Routing
 Both NANP and International Numbering Plan – E.164, use
prefix-based dialing
SS7

408 212 555 5644

PSTN

1+212+555+5644 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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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 packet-
switched signaling system (SS7)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 (inter-
exchange 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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

53
 US Telephone Network Structure (after
1984)
Eg: AT&T, Sprint, MCI

Eg: SBC, Verizon, BellSouth

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 long-distance
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

55
 VoIP Technologies

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

57
 Inside the Endpoint: Data-plane
 … I.e.after signaling is done…
 Consists of three components:

User speaks into microphone, either PC

User attached, regular analogue phone or IP
phone

A/D Device digitizes voice according to

Codec certain codecs:
G.711 / G.723.1 / G.729 ...

IP Voice gets transmitted via RTP over an

Gateway IP infrastructure

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

58
 Internet Multimedia Protocol Stack

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

59
 Packet Encapsulation
RTP datagram
Version, Payload Sequence Synchronization CSRC ID
Timestamp Codec Data
flags & CC Type Number Source ID (if any)
1 1 2 4 4 0-60 0-1460

UDP datagram
Source Destination
UDP length UDP checksum Data
Port Number Port Number
2 2 2 2 0-1472

Version &
header length Protocol
IP packet
Total Packet Flags & Header Source Destination Options
TOS TTL Data
Length ID Frag Offset Checksum Address Address (if any)
1 1 2 2 2 1 1 2 4 4 0-40 0-1480

Start of frame Length or

delimiter Ethertype
Ethernet Frame
Inter-frame Destination Source
Preamble Data Pad Checksum
gap Address Address
12 7 1 6 6 2 0-1500 0-46 4

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

60
 RTP – Real-time Transport Protocol
RTP datagram
Version, Payload Sequence Synchronization CSRC ID
Timestamp Codec Data
flags & CC Type Number Source ID (if any)
1 1 2 4 4 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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 point-
to-point protocols, but some boxes don’t implement it
 Uses another UDP port (usually RTP’s port + 1)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

62
 SIP

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

63
 Signaling: VoIP Camps

Netheads Circuit switch “Convergence”

Conferencing
“IP over engineers ITU standards
Industry
Everything” “We over IP”

H.323 SIP “Softswitch” BICC

ISDN LAN I-multimedia Call Agent BISDN, AIN
conferencing WWW SIP & H.323 H.xxx, SIP

IP IP IP “any packet”

Rensselaer Polytechnic Institute

Our focus Shivkumar Kalyanaraman
64
 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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
65
 SIP

Audio Codec Video Codec

G.711 H.261
G.723 H.263
G.729

RTP RTCP
SIP

TCP UDP

IP

LAN Interface

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

67
 SIP Addresses Food Chain

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

69
 IP SIP Phones and Adaptors
1
Are true Internet hosts
• Choice of application
• Choice of server Analog phone adaptor
• IP appliances 2
Implementations
• 3Com (3)
 3
               
• Columbia University
• MIC WorldCom (1) Palm
control
• Mediatrix (1)
• Nortel (4)
• Siemens (5) 44 5

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

70
 SIP: Personal Mobility
Users maintain a single externally visible identifier regardless
of their network location

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

71
 Expand existing PBXs w/ IP phones

 Transparently …
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
72
 SIP as Event Notification Protocol

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

73
 SIP: Presence

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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)
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

76
 SIP-based Architecture
rtspd
Quicktime
RTSP media RTSP
server
Telephone sipconf RTSP clients
SIP
conference sipum
Telephone server SIP/RTSP
switch Unified Web based
messaging configuration

sipd Web server

T1/E1 SIP proxy,
redirect SQL
RTP/SIP server database e*phone

Cisco 2600 gateway

Hardware
Internet (SIP)
sipc phones

NetMeeting
sip323

Software SIP SIPH.323 H.323

user agents convertor

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

77
 Example Call
• Bob signs up for the service from • sipd canonicalizes the destination to
the web as “bob@ecse.rpi.edu” sip:bob@ecse.rpi.edu
• He registers from multiple • sipd rings both e*phone and sipc
phones • Bob accepts the call from sipc
• Alice tries to reach Bob and starts talking
INVITE ip:Bob.Wilson@ecse.rpi.edu
Web based
configuration
Call Bob sipd Web
SIP proxy, server
redirect SQL
server database e*phone

Hardware
Internet (SIP)
sipc phones

ecse.rpi.edu

Software SIP
user agents
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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.

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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.

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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).

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

82
 SIP Design Choices

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 us.gov
From: sip:dcheney@wh
parliament.uk Location Server

1&5

george.w.bush

dcheney@wh
tony@parliament.uk
4
dcheney@wh
2&6

4. SIP/2.0 100 OK
From: sip:president@us.gov Proxy server
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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
84
 Redirect Server
us.gov

Location Server

george.w.bush
parliament.uk 1&3

dcheney@wh
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 4. INVITE sip:dcheney@wh.us.gov
6. ACK sip:dcheney@wh.us.gov
Contact: sip:dcheney@wh.us.gov From: tony@parliament.uk From: sip:tony@parliament.uk
3. ACK sip:president@us.gov 5. SIP/2.0 200 OK
From: sip:tony@parliament.uk To: tony@parliament.uk

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

85
 SIP Call Signaling

Assumes Endpoints(Clients)
know each other’s IP addresses

SIP SIP
Endpoint Gateway

Signaling Invite
SIP + SDP
Plane 180 Ringing
200 OK
(TCP or UDP)
Ack

RTP Stream
Bearer RTP Stream Media (UDP)
Plane RTCP Stream

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

86
 PSTN to IP Call

PSTN PBX Gateway

Internal T1/CAS
External T1/CAS (Ext:7130-7139)

1 Call 9397134 2 Call 7134

Ethernet

Regular phone 5 3
(internal)
SIP server SQL
database

sipc sipd
Bob’s phone 4 7134 => bob

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

87
 IP to PSTN Call

PSTN PBX Gateway

(10.0.2.3)
External T1/CAS Internal T1/CAS
5 Call 5551212 4 Call 85551212
3
Ethernet

5551212 Bob calls

Regular phone 1 5551212
(internal, 7054)
SIP server SQL
database

sipc sipd
2
Use sip:85551212@10.0.2.3

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

88
 Traditional voice mail system

Dial 853-8119

Phone is ringing
Alice Bob
939-7063 .. The person is not available now 853-8119
please leave a message ...
... Your voice message ...

Disconnect

Bob can listen to his voice mails by dialing some number.

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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
Rensselaer server.
Polytechnic Institute Shivkumar Kalyanaraman
90
 Voicemail Architecture Bob

phone1.office.com;

CANCEL

200 OK
Alice

200 OK

RTP/RTCP v-mail
vm.office.com;
After 10 seconds vm contacts the
SETUP
RTSP server for recording.
vm accepts the call.
Sipd cancels the other branch and ... rtspd
...accepts the call from Alice.
Now user message gets recorded
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
91
 IETF SIP Architecture Tour: Roundup
Registrar & Proxy

PSTN, *Gateway or Redirect Server

ISDN,
ATM,
etc

*User Agent *User Agent *User Agent

*Endpoints
Media streams: RTP/RTCP (G.911, G.723.1, … )

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

92
 IETF SIP Architecture Tour: Roundup
Registrar & Proxy

PSTN, *Gateway or Redirect Server

ISDN,
ATM,
etc

System Management
Interface to • admission control
non-IP or H.323 *
• address
User Agent *User Agent *User Agent
translation/forwarding
*Endpoints
networks • Firewall bypassing

Media streams: RTP/RTCP (G.911, G.723.1, … )

Conferencing does
not need another End-user devices
box (MCU) and network proxies

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

93
 IETF SIP Architecture Tour: Roundup
Registrar & Proxy

PSTN, *Gateway or Redirect Server

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 = almost all signaling, optional services, etc.
•SDP = negotiation/capabilities
•DNS = address translation
•RSVP = QoS bandwidth guarantee

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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.
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

101
 Device Configuration

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

102
 SIP Scaling Issues

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

103
 SIP Scaling (contd)

SIP Load Characteristics:

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

104
 H.323

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

105
 SIP vs H.323 vs Megaco

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

106
 H.323 vs SIP

Typical UserAgent Protocol stack for Internet

Terminal Control/Devices Terminal Control/Devices

Codecs Codecs
Q.931 H.245 RAS RTCP SIP SDP RTCP
RTP RTP
TPKT
TCP UDP
Transport Layer
IP and lower layers

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 • Modular, simplistic design

• Difficult to extend & update • Easily extended & updated
• Based on H.320 conferencing and • Based on Web principals (“Internet-
ISDN Q.931 legacy (“Bell headed”) friendly”)
• Powerful for video-conferencing • Readily extensible beyond telephony

Stds Status • H.450.x series provides minimal feature • Few real end-device features
(end device) set only, and not implemented by many standard, and not implemented by
• Options and versions cause interop many
problems • Many options for advanced telephony
• Slow moving features
• Good velocity
Industry • Established now, primarily system level • Rapidly growing industry momentum,
Acceptance • Few H.323-based telephones at system and device level
• End-user primarily driven by Microsoft • Growing interest in SIP-phones and
(NetMeeting), Siemens, Intel soft clients

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

108
 SIP-H.323: Interworking Problems
Eg: Call setup translation
H.323 SIP
Q.931 SETUP INVITE
Destination address
Q.931 CONNECT (Bob@office.com)

Terminal Capabilities 200 OK

Media capabilities
Terminal Capabilities (audio/video)
ACK
Open Logical Channel
Open Logical Channel Media transport address
(RTP/RTCP receive)

• H.323: Multi-stage dialing

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

109
 H.323 Standard Series
Audio Codec Video Codec
System Control
G.711 H.261
H.245 Control G.723 H.263
G.729
H.225 Call Setup
Data Interface
T.120 RAS Gatekeeper RTP RTCP

TCP UDP

IP

LAN Interface

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

110
 Internet Telephony Protocols: H.323

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

111
 H.323 (contd)
 Terminals, Gateways, Gatekeepers, and Multipoint
Control Units (MCUs)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

112
 H.323 Model - Gatekeeper Routed Call

Gatekeeper

Ca
g ll S
l in R
S na Ca etup AS
ig l ll C /Si
RA p/S ntro on g n a
etu Co tro
l
li n
g
ll
S all
Ca C

Voice Channel

Endpoint
Gateway
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
113
 H.323 Model - Gatekeeper Direct Call

Gatekeeper

RAS RAS

Call Setup/Signaling

Call Control

Voice Channel

Endpoint
Gateway
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
114
 H.323 Call Signaling
Assumes Endpoints(Clients)
know each other’s IP addresses

H.323 H.323
Setup
Endpoint H.225 (TCP) Gateway
Alerting
(Q.931)
Connect

Terminal Capability Set

Signaling
Terminal Capability Set & Acknowledge
Plane
Terminal Capability Set Acknowledge

Open Logical Channel H.245 (TCP)

Open Logical Channel & Acknowledge
Open Logical Channel Acknowledge

RTP Stream
Bearer RTP Stream Media (UDP)
Plane RTCP Stream

H.323v1 (5/96) - 7 or 8 Round Trips

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
H.323v2 Fast Start (2/98) - 2 Round Trips
115
 ITU-T H.323 Architecture Tour
Gate Keeper

PSTN, *Gateway (GW) (GK)

ISDN,
ATM,
etc

*Multipoint Control
Unit (MCU)
Multipoint Multipoint
Controller Processor *Terminal *Terminal *Terminal
(MC) (MP)

*Endpoints Media streams: RTP/RTCP (G.911, G.723.1, … )

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

116
 ITU-T H.323 Architecture Tour
Gate Keeper

PSTN, *Gateway (GW) (GK)

ISDN,
ATM,
etc

*Multipoint Control System Management

Unit (MCU) • zone management
Multipoint Multipoint
Interface to Processor
Controller *
• b/w management
Terminal & * Terminal * Terminal
non-IP networks
(MC) (MP) admission control
• address translation
• centralized control
*Endpoints (“gatekeeper
Media control
streams: RTP/RTCP (G.911, G.723.1, … )
mode”)
Conferencing
End-user devices
and network proxies

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

117
 ITU-T H.323 Architecture Tour
Gate Keeper
H.225.0 RAS
PSTN, *Gateway (GW) (GK)
H.225.0 CS
ISDN,
ATM, H.245 CC
etc H.450.x SS

*Multipoint Control
Unit (MCU)
Multipoint Multipoint
Controller Processor *Terminal *Terminal *Terminal
(MC) (MP)

*Endpoints 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!
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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 223-4211
10.0.0.5 192.168.0.3
4, 8, 12, 16 3, 7, 11, 15

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 Gatekeeper
132.177.120.5

223-2749 223-4211
3, 5, 7, 9
10.0.0.5 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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

120
 MEGACO/H.248,
Softswitch Concepts

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

121
 Master/Slave vs. Peer Comparison
Master/Slave (Thin Client) Peer (Thick Client)
Operation •Simple/dumb slave end device •Smart/complex end device
•Stimulus control, proxy in •Functional control, peer
network interaction
Cost •Lowest cost end device •Higher cost end device

Performance •Lower performance “local” •Higher performance local

services services
•Sometimes higher •High performance User
performance distributed Interface
services (e.g.. call
control)
Feature •Generic development tools •Device-specific development
development •Shorter time to market for new •Possibly shorter time to market
features on a range of end devices for new features on specific
•End device does not “get out of devices
date” as quickly •End device may need hardware
upgrade over time
Feature •Update servers only •Update / download all end
deployment •Services can come and go devices in network (yikes!)
dynamically •Features more static per-device

Protocols •MEGACO/H.248, MGCP •H.323, SIP

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

122
 Megaco/H.248

Audio Codec Video Codec

G.711 H.261
G.723 H.263
G.729

RTP RTCP
Megaco

TCP UDP

IP

LAN Interface

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

123
 Megaco/H.248 – Convoluted History
PacketCable Network-based Call Signaling (NCS)
DSM-CC based on earlier version of MGCP (March 99)

Diameter
Industry
PacketCable Defacto
IPDC NCS Std.

SGCP MGCP I-RFC 2705 Non-

(proposal)
Standard
MGCP released as
MGCP proposal Informational RFC (Oct 99)
MDCP
Not fully accepted by Megaco WG, (proposal)
diverged (Spring 99) Megaco
Protocol
Megaco Protocol stream created, true
consensus (March 99)
ITU: H.GCP
ITU SG-16 initiates gateway
control project, H.GCP starting Megaco/H.248 WORLD
from MDCP (May 99)
STANDARD
Agreement reached between ITU SG16 and IETF Megaco
to work together to create one standard (Summer 99)
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
124
 Megaco Vs MGCP
Megaco/H.248
Call Model Command Grouping Protocol Encoding
Termination +Context +Topology Transaction Binary & Text
P2P Single Media Events Transport
Single Media Conferencing Event Buffering TCP + UDP +SCTP
P2P Multimedia Event Packages Security
Multimedia Conferencing (MGCP Packages Authentication Header
Terminations + Additional Packages) MGC Backup
Physical & Ephemeral & Muxing National Variants
Template Media Session Description
SDP + H.245

MGCP
Call Model Event Packages
Termination + Connection
P2P Single Media
(MGCP)
Media Session Description
Bold entries indicate
Single Media Conferencing SDP additional features in
Terminations Protocol Encoding
Physical & Ephemeral Text Megaco vs. MGCP
Command Grouping Transport
Ad hoc Embedding UDP
Event
Quarantine

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

125
 Megaco Architecture Whirlwind Tour
Signalling Gateway Layer (SG)
SS7 etc Signalling Gateway • Interface to SS7 signalling etc
• Not in Megaco scope (IETF Sigtran)
Sigtran

Call Agent Call control (e.g.. H.323, SIP…)

Gateway
Media Gateway Controller Media Gateway Control Layer (MGC)
PSTN, Endpoint
Function
• Contains all call control intelligence
• Implements call level features (forward,
ATM,
Megaco Protocol transfer, conference, hold, …)
etc
(e.g..H.323
PSTN (e.g..
trunking H.323Gateway,
Gateway, Media Gateway Control Protocol
trunks Media Gateway Megaco Scope • Master / slave control of MGs by MGCs
Terminal, MCU)
Terminal, MCU) – Connection control
– Device control and configuration
lines PSTN line • Orthogonal to call control protocols
Media Gateway
Media Gateway Layer (MG)
Analog • Implements connections to/from IP cloud
Media Gateway
(through RTP)
• Implements or controls end device features
IP Phone (including UI)
Media Gateway • No knowledge of call level features

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

126
 Framework for H248/Megaco Protocol
Media GW Controller Media Gateway
• Call processing and Service logic • Connection and device control
• Call routing • No call processing, no call model
• Inter-peer entity communication via • Service-independent
call control protocols (e.g. H.323, SIP, • Cost effective
etc)

Media GW Controller

Media Gateway Device Device

PBX/CO control
control
PBX/
PSTN trunking PBX CO
Media Gateway
Media
PSTN line Gateway
Media Gateway
Telephone/Residential
Media Gateway IP (or ATM) Network
IP Phone
Media
Gateway

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

127
 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
Media Gateways Gateway
PSTN Trunking Sigtrans
Media Gateway
Media GW
PSTN Line Controller
Media Gateway Megaco/ H.323
H.323
H.248
Telephone/Residential Device
Media Gateway SIP
RTP
Cable Modem
Media Gateway SIP
Device
RTP
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
128
 Megaco call in action (optional)
MG1 MG2
MGC

ServiceChange: Restart ServiceChange: Restart Powered On

Powered On
Reply: ServiceChange Reply: ServiceChange

Modify: Look for Off-Hook Modify: Look for Off-Hook

Ready Reply: Modify Reply: Modify

Ready

Off-Hook Notify: Off-Hook

Reply: Notify

Modify: Dial Tone, Digit Map

Dial Tone,
Reply: Modify
User Dials
Notify: number “19782886160”

Reply: Notify

Add: TDM to RTP, what codecs?

Reply: Add, codec G.729

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

129
 Megaco call in action (continued)
MG1 MG2
MGC

Add: TDM to RTP, ring phone

Reply: Add
Phone Rings
Modify: ip of MG2, ringback
Hears Ring Reply: Modify Notify: Off-hook
Off-Hook
Reply: Notify

Modify: stop ring

Modify: stop ringback, fullduplex Reply: Modify Stops Ring

Reply: Modify

Open RTP Active Call/End of Invite Request Open RTP

Notify: On-hook On-Hook

Reply: Notify

Subtract: TDM and RTP Subtract:TDM and RTP

Disconnect
Reply: Subtract Reply: Subtract

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

130
 Megaco/H.248 IP Phone Control
Cisco’s Skinny,
Nortel’s UNIStim, MGC H.323 GW
etc., are very H.323
similar protocols
but they’re not
l Voice (RTP)
ro

M
interoperable t

ed
on
In theory the RTP

i
C

a,
ey stream should go

Voice (RTP)
k

CD
oft direct phone<-

,
S

So
, >GW, but many
D Vo

ftk
LC ic today tandem

e
, e
ia

y
)
TP

ed (R

Co
through the MGC
(R

M TP

nt
)

ro
e
ic

l
Vo

Voice (RTP)
IP Phone IP Phone
Media Gateway Media Gateway
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

H.323 V1 73
77
H.323 V2 26
57
H.323 other versions 17
32
SIP (orig. RFC 2543) 40
66
SIP (Latest spec) 30
81
MGCP (orig. RFC2705) 42
56
MGCP (latest spec) 30
54
H.248 (Megaco) 11
64
Other 22
30

0 10 20 30 40 50 60 70 80 90

Source: Network World and Mier Communications - August, 2001

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
133
 MGCP/H.248/Megaco
SIP
Media Gateway Controller Media Gateway Controller
(MGC) (MGC)

Master/Slave
MGCP

Media Gateway Signaling Gateway Media Gateway Signaling Gateway

Distributed entities acting in co-ordination

Connect to variety Interface to

Separate signaling of networks, home users variety of
and voice planes, but and other media receptors signaling
user unaware of it like H.323 terminals etc mechanisms

User A
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
For examples of gateways see RFC 3435
134
 Softswitch: Motivation
Class-4/5 switches bulky,
expensive. Incentive to switch
PSTN
to cheaper easily managed IP
Class 4
Class 5 switch
Voice
switch Class 5
switch
Users ISDN Switch Users

Data H.323 gateway

Initial gateway between

PSTN and Internet was
H.323. Gateway did
signaling, call control, Packet networks
translation in one box. Not
scalable.
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

138
 Softswitch Architecture
Application
• Distributed functionality Server

• Open platforms Media Gateway

Controller
• Open interfaces enable
new services
Signaling
Gateway
• Leverages the
intelligence of endpoints Media
Gateway
• Media agnostic
PSTN/
End users

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 Media Gateway
call Controller

• May be distributed across Signaling

the globe Gateway

• May or may not be Media

Gateway
collocated with SS7
Signaling Gateway
PSTN/
End users

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

140
 Softswitch - Media Gateway Controller Functions

Application
Server
• Connections (call setup
and teardown)
Media Gateway
• Events (detection and Controller

processing)
Signaling
• Device management Gateway

(gateway startup,
Media
shutdown, alerts) Gateway

PSTN/
End users

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

141
 Softswitch - Media Gateways
Media Gateways provide interaction between audio in the
network and software controlled applications
Application
• Convert PSTN to IP Server

packets
• Convert IP packets to Media Gateway
Controller
PSTN
• In-band event detection Signaling
and generation Gateway

• Compression (G.7xx,…) Media

Gateway
• May be distributed
across the globe PSTN/
End users

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

142
 MGC and MG Roles
Media Gateway Controller
Media Gateway

MGC’s allow intelligence to

be distributed in the MG’s are purpose built
network specialist devices

 Basic call routing

 Trunking gateways
functions  VoATM gateways
 Synchronization of Media  Access gateways
Gateways  Circuit switches
 Protocol Conversion  Network Access Servers

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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
• Signaling transport (SS7, Gateway

SIP-T, Q.931…)
Media
Gateway
• Extremely secure
• Extremely fault tolerant PSTN/
End users

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 Signaling
parties Gateway

Media
Gateway

PSTN/
End users

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

145
 Softswitch – Application Server
Application Servers(AS) Can be broken apart and distributed in
the network

LDAP

Directory Server Feature Server

COPS Corba
Network Elements
Policy Server
SIP
Corba
Media Server Management Server

Connectivity Server

SIP,Parlay,JAIN

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

147
 Softswitch Architecture – Interdomain protocols
Application specific
Application Application
Server Server

SIP, Parlay, Jain

Media Gateway
Media Gateway
Controller
Controller
Sigtran SIP-T,BICC
Signaling Signaling
Gateway Gateway
H.248,MGCP

Media RTP Media

Gateway Gateway

PSTN/ PSTN/
End users End users

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

148
 SIP vs MEGACO: Summary

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

149
 SIP vs MEGACO (contd)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

151
 Speech Coding and
Speech Coders for VoIP

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

152
 Taxonomy of Speech Coders
Speech Coders

Waveform Coders Source Coders

Time Domain: Frequency Domain: Linear Vocoder

PCM, ADPCM e.g. Sub-band coder, Predictive
Adaptive transform Coder
coder
 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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
Hybrids: Combine best of153 both… Eg: CELP (used in GSM)
 Speech Quality of Various Coders

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

154
 Speech Quality (Contd)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

155
 Actual Bandwidth Used
Frame Packet + RTP+ LAN T-LAN WAN
size In bytes UDP+IP frame in kbps kbps
in ms in bytes bytes
G.711 10 80 120 146 116.8 96.0
(64 kbps) 20 160 200 226 90.4 80.0
30 240 280 306 81.5 74.6
G.729A 10 10 50 76 60.8 40.0
/G.729 20 20 60 86 34.4 24.0
( 8 kbps) 30 30 70 96 25.6 18.6

G.723.1 30 20 60 86 22.9 16.0

(5.3 kbps)

G.723.1 30 24 64 90 24.0 17.0

(6.3 kbps)

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)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

157
 Pulse Amplitude Modulation (PAM)

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

158
 Pulse Code Modulation (PCM)

* PCM = PAM + quantization

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
160
 How it works for T1 Lines

• Companding blocks are shared by all 16 channels

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
161
 Recall: Taxonomy of Speech Coders
Speech Coders

Waveform Coders Source Coders

Time Domain: Frequency Domain: Linear Vocoder

PCM, ADPCM e.g. Sub-band coder, Predictive
Adaptive transform Coder
coder
 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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
Hybrids: Combine best of162 both… Eg: CELP
 Vocoders

Encode only perceptually important aspects of speech w/ fewer bits than

waveform coders: eg: power spectrum vs time-domain accuracy
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
163
 LPC Analysis/Synthesis

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

164
 Speech Generation in LPC

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

165
 CELP Encoder

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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).

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

167
 Codecs: Quality Measures
Standard Algorithm Bit Rate (Kbit/s) Codec Induced Delay Resultant Voice
(msecs) Quality
G.711 PCM 56, 64 <<1 Excellent
G.723.1 MPE/ACELP 5.3, 6.3 67-97 Fair(5.3), Good(6.3)
G.728 LD-CELP 16 <<2 Good
G.729 CS-ACELP 8 25-35 Good
G.722 Sub-band 64 5-10 Good-Excellent (it’s
ADPCM wideband)
G.726 ADPCM 16, 24, 32, 40 <<1 Fair(24), Good(40)
GSM-EF ACELP 12.2 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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

168
 Packet Encapsulation
RTP datagram
Version, Payload Sequence Synchronization CSRC ID
Timestamp Codec Data
flags & CC Type Number Source ID (if any)
1 1 2 4 4 0-60 0-1460

UDP datagram
Source Destination
UDP length UDP checksum Data
Port Number Port Number
2 2 2 2 0-1472

Version &
header length Protocol
IP packet
Total Packet Flags & Header Source Destination Options
TOS TTL Data
Length ID Frag Offset Checksum Address Address (if any)
1 1 2 2 2 1 1 2 4 4 0-40 0-1480

Start of frame Length or

delimiter Ethertype
Ethernet Frame
Inter-frame Destination Source
Preamble Data Pad Checksum
gap Address Address
12 7 1 6 6 2 0-1500 0-46 4

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

169
 G.711 (10ms) Clear Channel Voice
80 byte
RTP Frame 12 80
voice bundles RTP Header Voice Payload
Destination

UDP Datagram 2 2 2 2 12 80
Source
Length
Checksum RTP Header Voice Payload
Destination
IP Packet Header 12 4 4 8 12 80
Source
Type UDP Header RTP Header Voice Payload CRC.
Destination

IP into Ethernet 6 6 2 120 4

8
Preamble Source IP Payload

IP into Frame Relay Flag 12 120 21

IP Payload Flag
Address Frame Check

IP into ATM 5 48 + 5 48 + 5 24 16 8
IP Payload IP Payload IP Payload
Header Header Header Padding Trailer

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

170
 G.729 (30ms) Clear Channel Voice
30 byte
RTP Frame 12 30
voice bundles RTP Header Voice Payload
Destination

UDP Datagram 2 2 2 2 12 30
Source
Length
Checksum RTP Header Voice Payload
Destination
IP Packet Header 12 4 4 8 12 30
Source
Type UDP Header RTP Header Voice Payload CRC.
Destination

IP into Ethernet 6 6 2 70 4
8
Preamble Source IP Payload

IP into Frame Relay Flag 12 70 21

IP Payload Flag
Address Frame Check

IP into ATM 5 48 + 5 22 18 8
IP Payload IP Payload
Header Header Padding Trailer

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

171
 G.729 (20ms) Clear Channel Voice
20 byte
RTP Frame 12 20
voice bundles RTP Header Voice Payload
Destination

UDP Datagram 2 2 2 2 12 20
Source
Length
Checksum RTP Header Voice Payload
Destination
IP Packet Header 12 4 4 8 12 20
Source
Type UDP Header RTP Header Voice Payload CRC.
Destination

IP into Ethernet 6 6 2 60 4
8
Preamble Source IP Payload

IP into Frame Relay Flag 12 60 21

IP Payload Flag
Address Frame Check

IP into ATM 5 48 + 5 12 28 8
IP Payload IP Payload
Header Header Padding Trailer

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

172
 G.723.1 (30ms) Clear Channel Voice
20-24 byte
RTP Frame 12 20-24
voice bundles RTP Header Voice Payload
Destination

UDP Datagram 2 2 2 2 12 20-24

Source
Length
Checksum RTP Header Voice Payload
Destination
IP Packet Header 12 4 4 8 12 20-24
Source
Type UDP Header RTP Header Voice Payload CRC.
Destination

IP into Ethernet 6 6 2 60-64 4

8
Preamble Source IP Payload

IP into Frame Relay Flag 12 60-64 21

IP Payload Flag
Address Frame Check

IP into ATM 5 48 + 5 12-16 28-24 8

IP Payload IP Payload
Header Header Padding Trailer

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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.

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

177
Recap: Speech Quality of Various Coders

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

178
 Miscl: Other standards, ENUM, E-911,
Presence etc

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 Signaling
Gateway Gateway
Sigtrans
SS7

ans

ans
CO

Sigtr

Sigtr
Virtual Switch
Trunk Gateway
D-channel Signalling Gateway Sigtrans SIP, H.323
PRI Media Gateway
B-channels Megaco/
H.248 Media GW
PBX Virtual
Controller Switch

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 User Adaptation Modules
4 - Transport SCTP
3 - Network IP
2 - Link MLPPP / FR / ATM
1 -Institute
Rensselaer Polytechnic Physical Shivkumar Kalyanaraman
Ethernet / SONET/Serial
181
 (1) SS7 Signaling Using IP Transport

SSP The IETF M2UA SSP

MTP2-User Adaptation Layer
from the Sigtran WG

Applications Applications

STP

TCAP TCAP
ISUP ISUP
SCCP SCCP

MTP3 MTP3* MTP3

M2UA M2UA
MTP2 MTP2 SCTP SCTP
IP IP

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

182
 (2) SS7 / IP Interworking
The IETF M3UA
SSP MTP3-User Adaptation Layer MGC
from the Sigtran WG

Call SS7 SG Call

Processing Processing
Application Application
Nodal
Inter-working Function

ISUP ISUP

MTP3 MTP3 M3UA M3UA

SCTP SCTP
MTP2 MTP2
IP IP

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 BICC ISN
BICC ISUP
ISUP

PSTN PSTN
TDM TDM

Class 4 Switch Class 4 Switch

Data Network

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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
VPIM Browser

PBX SIP/H.323
Plain
Unified Unified
Phone
Messaging Messaging
System System SIP
Device
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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 us.gov
From: sip:dcheney@wh
parliament.uk Location Server

1&5

george.w.bush

dcheney@wh
tony@parliament.uk
4
dcheney@wh
2&6

4. SIP/2.0 100 OK
From: sip:president@us.gov Proxy server
Firewall 3
5. ACK sip:president@us.gov SIP/2.0
From: sip:tony@parliament.uk
6. ACK sip:dcheney@wh SIP/2.0 3.5 Midcom Protocol
From: sip:tony@parliament.uk
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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)
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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 To Duratio Details
n
16:45 Call req. 5551212 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 Shivkumar Kalyanaraman

189
 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  Fault tolerant
 Audit capabilities  Local cache
 Highly available  Roll back
 Support of standards
 Integration with other OSS/BSS systems (fraud, churn, etc)
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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.
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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@service-provider.com.

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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…

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

193
 E911 - Requirements
 911 Services

 Power stays on when building power fails

 Need 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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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.
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

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…)
Rensselaer Polytechnic Institute Shivkumar Kalyanaraman
198
 IPtel for appliances: “Presence”

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

199
 VoIP Standards (Enterprise View)
H.323
annex G, Enterprise H.323, SIP, Q.Sig
3rd Party SIP Call IP-enabled
Call Servers & Server PBX/KS
Gatekeepers H.248,
Stimulus

H.323
H.323
SIP H.248, SIP, H.323
Stimulus
SIP, H.323

RTP RTP H.323 RTP

SIP
Gateway Stimulus Gateway Thick
Terminal Terminal
s s

RTP
RTP
RTP

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

200
 VoIP Standards (Carrier View)

H.323, SIP-T Sigtrans, Q.BICC

3rd Party BICC
Softswitch/ Signalling
Call Agents & Call Agent/ (SS7)
Gatekeepers MGC Gateway

SIP Megaco/ SIP

H.248 MGCP

RTP RTP RTP Application/

SIP
Megaco MGCP
Gateway Media Server
Gateway Gateway

RTP

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

201
 VoIP Summary: Big Picture

Rensselaer Polytechnic Institute Shivkumar Kalyanaraman

202