Voice over IP
Prof. Anirudha Sahoo
KReSIT,
IIT Bombay
17 July 2016
IIT Bombay
1
Voice Over IP (VOIP)
• Transmission of digitized voice in IP
network
• Enables telephone conversation to be
carried over IP network (in part or end-toend)
• Provides a toll bypass path for telephone
calls
• Enables Telephony providers to provide
cheaper service
17 July 2016
2
VOIP System
PSTN gateway
IP Network
PSTN Network
gatekeeper
PBX
PSTN gateway
PBX
typical
PSTNbased)
system)
(A (A
typical
(H323
VOIP system)
17 July 2016
Copyright© IIT Bombay
3
VOIP System (cont.)
IP Network
CPE router
CPE router
PSTN Gateway
LAN
LAN
SIP proxy
IP phone
PSTN
Soft phone
17 July 2016
(A (SIP based) VOIP system)
IP phone
4
VOIP Session Protocols
• Session Protocols are used to setup VOIP
connections
• Primarily two competing protocols where
endpoints are intelligent
– H.323
– SIP
• MGCP is the other protocol with masterslave model where the end points are
slaves.
17 July 2016
5
H.323
• Defines interworking of
– Call signaling
– Call control
– Media stream protocols
to build a packet-based multimedia
communication system
• Also defines network components that are
used to build up such a communication
system
17 July 2016
6
Components of H323
network
17 July 2016
7
H.323 Terminals
• An endpoint on the
network which provides for
real-time, two-way
communications with
another H.323 terminal,
Gateway or MCU using
H.323 protocol
• Communication can consist
of any multimedia data
(e.g. speech, data or
video).
17 July 2016
8
Multipoint Control Unit
(MCU)
• Used for conference control
• Content mixing.
• Consists of a mandatory Multipoint Controller
(MC)
– Responsible for call signaling, conference control
• An optional Multipoint Processor (MP)
– Responsible for switching/mixing of media streams.
– Can do real-time transcoding of audio/video streams
• Transcoding is expensive, so usually done in dedicated
hardware (e.g. dsp)
17 July 2016
9
Gateway
• Provides two way communication between
terminals belonging to networks with
different protocol stack
H323
terminal
Gateway
ISDN
Speech
terminal
17 July 2016
SIP
terminal
10
GateKeeper (GK)
• Provides address translation and controls access
to the network resources for H.323 terminals,
Gateways and MCUs.
• Endpoints register themselves at a GK
• All H.323 endpoints registered to a single GK build
an H.323 zone
– H.323 zones are independent of physical network
topology
– Each zone has only one GK
• An optional element in H.323. Without GK, there
will not be any BW/admission control in the
network and address resolution has to be done
via other mechanism
17 July 2016
11
GK functionality
• Address Translation
– End point register their H323 aliases (address)
and IP address
– A GK translates H.323 aliases into call signaling
IP addresses
– Multiple GKs can communicate to build a multizone address translation service
17 July 2016
12
GK functionality (cont.)
• Admission
control/bandwidth
control
– Every call in the zone
gets authorized by GK
for admission
Direct signaling
GK routed signaling
• Call control
– Direct call
signaling/control and GK
routed call
signaling/control
17 July 2016
13
H323 protocol overview
17 July 2016
14
RAS
17 July 2016
15
Q.931 and H.245
17 July 2016
16
Audio Codecs
17 July 2016
17
H.323 Call Setup
• Three phases to establish a call
– Phase A : GK Communication (Address
resolution and admission)
– Phase B : Call Signaling (Setup, CallProc, Alert
, Connect etc.)
– Phase C : Call Control (Capability Exchange,
open/close media streams) (slow start mode)
17 July 2016
18
H323 call setup
• Basic setup without any GK
endpoint2
endpoint1
setup
CallProc
Alert
connect
RTP media
17 July 2016
19
H323 call setup with GK
endpoint1
endpoint2
GK
ARQ
ACF
setup
CallProc
setup
CallProc
ARQ
ACF
Alert
Alert
connect
connect
17 July 2016
20
H.323 Call SETUP (multi GK)
17 July 2016
21
SIP Overview
• Application Layer Signaling Protocol
• Used to establish, modify, and terminate
multimedia sessions
• Part of Internet Multimedia Architecture
• Can use UDP, TCP, TLS etc.
• Based on HTTP (Web)
– Similar text-based structure
– Uses URIs (Uniform Resource Indicators)
• Applications include (but not limited to):
– Voice, video, gaming, instant messaging, presence,
call control, etc.
17 July 2016
22
A Short History of SIP
• Internet Engineering Task Force (IETF) protocol
• Inventors: M. Handley, H. Schulzrinne, E. Schooler, and
J. Rosenberg
• Became “Proposed Standard” and RFC 2543 in March
1999 in MMUSIC WG.
• Separate SIP WG established in September 1999.
• Now new SIPPING (applications) and SIMPLE (presence
and instant messaging) WGs using SIP.
• RFC2543bis-09 I-D became RFC 3261 in June 2002
– Added four new authors: G. Camarillo, A. Johnston, J.
Peterson, and R. Sparks.
– Entire spec rewritten for clarity, but some new features
– Mostly backwards compatible with RFC 2543
17 July 2016
23
SIP Requests and
Responses
SIP Request types are
called “methods”
Methods in base spec:
INVITE
ACK
OPTIONS
CANCEL
BYE
REGISTER
SIP Responses use a
numerical code and a
“reason phrase”
Classes:
1xx
2xx
3xx
4xx
5xx
6xx
Informational
Final
Redirection
Client Error
Server Error
Global Failure
Example: 404 Not Found
17 July 2016
24
SIP Uniform Resource
Indicators (URIs)
Same form as email addresses: user@domain
 Two URI schemes:


sip:henry@siptest.wcom.com is a SIP URI
Most common form introduced in RFC 2543
 sips:henry@siptest.wcom.com is a Secure SIP URI
 New scheme introduced in RFC 3261
 Requires TLS over TCP as transport for security


Two types of SIP URIs:

Address of Record (AOR) (identifies a user)
sip:henry@wcom.com (Needs DNS SRV records to locate SIP Servers
for wcom.com domain)
 Fully Qualified Domain Name (FQDN) or Contact (identifies a
device)
 sip:henry@127.24.45.4 or sip:henry@cube43.lab.wcom.com (Which
needs no resolution for routing)

17 July 2016
25
Related Protocols
SDP – Session Description Protocol





Used to describe media session.
Carried as a message body in SIP messages.
Is a text-based protocol
Uses RTP/AVP Profiles for common media types
Defined by RFC 2327
RTP – Real-time Transport Protocol
 Used to transport media packets over IP
 RTP adds a bit-oriented header containing:







name of media source
timestamp
codec type
sequence number
Defined by H. Schulzrinne et al, RFC 1889.
Profiles defined by RFC 1890.
RTCP for exchange of participant and quality reports.
17 July 2016
26
SIP “Trapezoid”
DNS Server
Location
Server
DNS
Outbound
Proxy Server
SIP
Inbound
Proxy Server
SIP
SIP
SIP
Media (RTP)
User Agent A
17 July 2016
User Agent B
27
SIP Elements – User Agents
DNS Server
Location
Server
Capable of sending
and receiving SIP
requests.

DNS

UAC – User Agent Client
UAS – User Agent Server
End Devices
Outbound
Proxy Server
SIP
Inbound
Proxy Server
SIP
SIP
SIP phone
 PC/laptop with
SIP Client
 PDA
 mobile phone

PSTN Gateways
are a type of User
Agent
SIP
Media (RTP)
User Agent A
17 July 2016
User Agent B
28
SIP Elements – Proxy Servers
DNS Server
Location
Server
DNS
Forward or “proxy”
requests on behalf
of User Agents
Consult databases:
DNS
 Location Server

Outbound
Proxy Server
SIP
Inbound
Proxy Server
Types:
Stateless
 Transaction Stateful
 Call Stateful

SIP
SIP
No media capabilities
SIP
Media (RTP)
User Agent A
17 July 2016
Ignore SDP.
Normally bypassed once
dialog established, but
can Record-Route to
stay in path.

User Agent B
29
SIP Elements – Other Servers
DNS Server
Location
Server
DNS
Outbound
Proxy Server
SIP
Inbound
Proxy Server
SIP
Location Server
Database of locations of
SIP User Agents
Queried by Proxies in
routing
Updated by User
Agents by
Registration
SIP
DNS Server
SIP
Media (RTP)
User Agent A
17 July 2016
User Agent B
SRV (Service) Records
used to locate
Inbound Proxy
Servers
30
SIP Message Details
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
• First line of a SIP message is Start Line which contains:
– the method or Request type: INVITE (session setup request).
– the Request-URI which indicates who the request is for
sip:bob@biloxi.com
Note: Request-URI can be either an AOR or Contact (FQDN)
• This Request-URI is a AOR
• the SIP version number SIP/2.0
17 July 2016
31
SIP Message Details
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
• Via headers show the path the request has taken
– Additional Via headers are inserted by each proxy in the path
• The Via headers are used to route responses back the same way
• branch parameter is a transaction-ID
17 July 2016
32
SIP Message Details
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
• Max-Forwards is a count decremented by each proxy
that forwards the request.
• When count goes to zero, request is discarded and 483
Too Many Hops response is sent.
• Used for stateless loop detection.
17 July 2016
33
SIP Message Details
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
• Dialog (formerly called call leg) information is in headers:
– To tag, From tag, and Call-ID (Note: Not URIs)
• To and From URIs usually contain AOR URIs.
• All requests and responses in this call will use this same
Dialog information.
• Call-ID is unique identifier usually composed of
– pseudo-random string “@” hostname or IP Address
17 July 2016
34
SIP Message Details
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
• CSeq Command Sequence Number
– Initialized at start of call (1 in this example)
– Incremented for each subsequent request within the same
dialog
– Used to distinguish a retransmission from a new request
• Also contains the request type (method) - INVITE
17 July 2016
35
SIP Message Details
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
• Contact header contains a SIP FQDN URI for direct
communication between User Agents
– If Proxies do not Record-Route, they can be bypassed
• If Record-Route is present in 200 OK, then a Route header is
present in all future requests in this dialog.
• Contact header is also present in 200 OK response
17 July 2016
36
SIP Message Details
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
• Content-Type indicates the type of message body
attachment (others could be text/plain,
application/cpl+xml, etc.)
• Content-Length indicates the octet (byte) count of
the message body.
• Message body is separated from SIP header fields by a
blank line.
17 July 2016
37
SDP Message Body Details
v=0
o=Tesla 289084526 28904529 IN IP4 lab.high-voltage.org
s=c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000







Version number (ignored by SIP)
Origin (only version used by SIP - 28904529)
Subject (ignored by SIP)
Connection Data (IP Address for media - 100.101.102.103)
Time (ignored by SIP)
Media (type - audio, port - 49170, RTP/AVP Profile - 0)
Attribute (profile - 0, codec - PCMU, sampling rate – 8000 Hz)
17 July 2016
38
SIP Response Details
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=24019385
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@200.201.202.203>
Content-Type: application/sdp
Content-Length: 176
v=0
o=Bob 2452772446 2452772446 IN IP4 200.201.202.203
s=SIP Call
c=IN IP4 200.201.202.203
t=0 0
m=audio 56321 RTP/AVP 0
a=rtpmap:0 PCMU/8000
• Via, To, From, Call-ID, & CSeq are all copied from request.
– To now has a tag inserted by UAS
• Contact and Message Body contain UAS information.
17 July 2016
39
SIP Call Flow Scenarios






Simple Call - Successful
Call Attempt - Unsuccessful
Presence Subscription
Registration
Presence Notification
Call Setup – Successful
17 July 2016
40
Simple SIP call (Successful)
Alice’s softphone
biloxy.com
proxy
atlanta.com
proxy
Bob’s softphone
INVITE
100 Trying
INVITE
INVITE
100 Trying
180 ringing
180 ringing
180 ringing
200 ok
200 ok
200 ok
ACK
RTP Media
BYE
200 ok
17 July 2016
41
SIP Call Setup Attempt
Scenario
DNS Server
Inbound
Proxy Server
Outbound
Proxy Server
1. INVITE
Contact: A
SDP A
User Agent A
17 July 2016
Location
Server
2. 100 Trying
1. A “dials” SIP AOR
URI sip:B@wcom.com.
User Agent A sends
INVITE to outbound
Proxy Server.
2. Outbound Proxy
sends 100 Trying
response.
User Agent B
(Not Signed In)
42
SIP Call Setup Attempt
Scenario
DNS Server
3. DNS Query:
wcom.com?
4. Response: 1.2.3.4
Inbound
Proxy Server
Outbound
Proxy Server
1. INVITE
Contact: A
SDP A
User Agent A
17 July 2016
Location
Server
2. 100 Trying
3. Outbound Proxy
does DNS query to
find proxy server for
wcom.com domain
4. DNS responds with
IP address of
wcom.com Proxy
Server
User Agent B
(Not Signed In)
43
SIP Call Setup Attempt
Scenario
DNS Server
3. DNS Query:
wcom.com?
Outbound
Proxy Server
Location
Server
4. Response:
1.2.3.4
5. INVITE
Contact: A
SDP A
Inbound
Proxy Server
6. 100 Trying
1. INVITE
Contact: A
SDP A
User Agent A
17 July 2016
2. 100 Trying
5. Outbound Proxy
sends INVITE to
Inbound Proxy
Server.
6. Inbound Proxy
sends 100 Trying
response.
User Agent B
(Not Signed In)
44
SIP Call Setup Attempt
Scenario
DNS Server
3. DNS Query:
wcom.com?
Outbound
Proxy Server
4. Response:
1.2.3.4
7. LS Query: B?
5. INVITE
Contact: A
SDP A
Location
Server
8. Response: Not
Signed In
Inbound
Proxy Server
6. 100 Trying
1. INVITE
Contact: A
SDP A
User Agent A
17 July 2016
2. 100 Trying
7. Inbound Proxy
consults Location
Server.
8. Location Server
responds with “Not
Signed In.”
User Agent B
(Not Signed In)
45
SIP Call Setup Attempt
Scenario
DNS Server
3. DNS Query:
wcom.com?
Outbound
Proxy Server
1. INVITE
Contact: A
SDP A
4. Response: 7. LS Query: B?
1.2.3.4
Location
Server
8. Response:
Not Signed
In
5. INVITE
Contact: A
SDP A
Inbound
Proxy Server
6. 100 Trying
9. 480 Temporarily Unavailable
10. ACK
9. Inbound Proxy sends
480 Temporarily
Unavailable
response.
10. Outbound Proxy sends
ACK response.
2. 100 Trying
User Agent A
17 July 2016
User Agent B
(Not Signed In)
46
SIP Call Setup Attempt
Scenario
DNS Server
3. DNS Query:
wcom.com?
Outbound
Proxy Server
1. INVITE
Contact: A
SDP A
2. 100 Trying
Location
Server
4. Response: 7. LS Query: B?
1.2.3.4
8. Response:
Not Signed
In
5. INVITE
Contact: A
SDP A
Inbound
Proxy Server
6. 100 Trying
11. Outbound Proxy
forwards 480 response
to A.
12. A sends ACK response.
9. 480 Temporarily Unavailable
10. ACK
11. 480 Temporarily Unavailable
12. ACK
User Agent A
17 July 2016
User Agent B
(Not Signed In)
47
SIP Presence Example
DNS Server
Presence
Server
3. SUBSCRIBE
Outbound
Proxy Server
2. SUBSCRIBE
Inbound
Proxy Server
1. SUBSCRIBE
User Agent A
17 July 2016
1. A wants to be informed
when B signs on, so
sends a SUBSCRIBE
2. Outbound Proxy
forwards to Inbound
Proxy
3. Inbound Proxy
forwards to B’s
Presence Server
User Agent B
(Not Signed In)
48
SIP Presence Example
DNS Server
Presence
Server
3. SUBSCRIBE
2. SUBSCRIBE
Outbound
Proxy Server
1. SUBSCRIBE
User Agent A
17 July 2016
5. 200 OK
4. 200 OK
Inbound
Proxy Server
4. Presence Server
authorizes subscription
by sending a 200 OK.
5. & 6. 200 OK proxied
back to A.
6. 200 OK
User Agent B
(Not Signed In)
49
SIP Presence Example
DNS Server
Presence
Server
7. NOTIFY
<Not Signed In>
8. NOTIFY
<Not Signed In>
Outbound
Proxy Server
9. NOTIFY
<Not
Signed
In>
11. 200 OK
12. 200 OK
Inbound
Proxy Server
10. 200 OK
User Agent A
17 July 2016
7. Presence Server sends
NOTIFY containing
current presence status
of B (Not Signed In).
8. and 9. NOTIFY is
proxied back to A.
10. A acknowledges
receipt of notification
with 200 OK.
11. & 12. 200 OK is proxied
back to B’s Presence
Server.
User Agent B
(Not Signed In)
50
SIP Registration Example
DNS Server
Location
Server
2. Update database:
B = B@2.3.4.5
Outbound
Proxy Server
Outbound
Proxy Server
1. REGISTER
Contact: B@2.3.4.5
User Agent A
17 July 2016
1. B signs on to his SIP
Phone which sends a
REGISTER message
containing the FQDN
URI of B’s User Agent.
2. Database update is sent
to the Location Server
User Agent B
51
SIP Registration Example
DNS Server
2. Update database:
B = B@2.3.4.5
1. REGISTER
Contact: B@2.3.4.5
17 July 2016
3. OK
Outbound
Proxy Server
Outbound
Proxy Server
User Agent A
Location
Server
3. Location Server
database update is
confirmed.
4. Registration is
confirmed with a 200
OK response.
4. 200 OK
Contact: B@2.3.4.5
User Agent B
52
SIP Presence Example
DNS Server
Presence
Server
13. NOTIFY
<Signed In>
Outbound
Proxy Server
15. NOTIFY
<Signed In>
User Agent A
17 July 2016
14. NOTIFY
<Signed In>
17. 200 OK
16. 200 OK
13. Presence Server learns
of B’s new status from
18. 200 OK
the Location Server
and sends a NOTIFY
containing new status
Inbound
of B (Signed In).
Proxy Server
14. & 15. NOTIFY is
proxied back to A.
16. A acknowledges
receipt of notification
with 200 OK.
17. & 18. 200 OK is proxied
back to Presence
Server.
User Agent B
53
SIP Call Setup Attempt
Scenario
DNS Server
Location
Server
5. LS Query: B
Outbound
Proxy Server
3. INVITE
Contact: A
SDP A
6. Response:
sip:B@2.3.4.5
Inbound
Proxy Server
4. 100 Trying
1. INVITE
Contact: A
SDP A
User Agent A
17 July 2016
2. 100 Trying
7. INVITE
Contact: A
SDP A
1. to 5. A retries
INVITE to B which
routes through two
Proxy Servers.
6. Location Server
responds with the
FQDN SIP URI of B’s
SIP Phone.
7. Inbound Proxy Server
forwards INVITE to B’s
SIP Phone.
User Agent B
54
SIP Call Setup Scenario
DNS Server
Outbound
Proxy Server
Location
Server
9. 180 Ringing
Inbound
Proxy Server
8. User Agent B alerts
B and sends 180
Ringing response.
9. & 10. 180 Ringing
is proxied back to A.
10. 180 Ringing
8. 180 Ringing
User Agent A
17 July 2016
User Agent B
55
SIP Call Setup Scenario
DNS Server
Outbound
Proxy Server
10. 180 Ringing
User Agent A
17 July 2016
9. 180 Ringing
12. 200 OK
Contact: B
SDP B
13. 200 OK
Contact: B
8. 180 Ringing
SDP B
Location
Server
Inbound
Proxy Server
11. B accepts call and
User Agent B sends
200 OK response.
12. & 13. 200 OK is
proxied back to A.
11. 200 OK
Contact: B
SDP B
User Agent B
56
SIP Call Setup Scenario
DNS Server
Outbound
Proxy Server
10. 180 Ringing
9. 180 Ringing
12. 200 OK
Contact: B
SDP B
13. 200 OK
Contact: B
8. 180 Ringing
SDP B
Location
Server
Inbound
Proxy Server
14. ACK is sent by A to
confirm setup call
bypassing proxies.
Media session begins
between A and B!
11. 200 OK
Contact: B
SDP B
14. ACK
Media (RTP)
User Agent A
17 July 2016
User Agent B
57
Other SIP Methods in RFC
3261

CANCEL




Used to terminate a pending session
INVITE sent, and 1xx received, but no “final response”
Can be sent by a proxy or User Agent
Useful for “forking proxy”
Parallel search using multiple registration Contacts.
 First successful wins, rest are cancelled.

OPTIONS

Used to query capabilities of a Server or User Agent
17 July 2016
58
References
• International Telecommunications Union. ITU-T
Recommendation H.323
• J. Rosenberg et al., “SIP: Session Initiation
Protocol” – Request for Comments 3261
• B. Goode, “Voice over Internet Protocol (VOIP)” –
Proceedings of the IEEE, vol. 90, no. 9,
September 2002.
• http://www.packetizer.com
• http://www.pulver.com/
• http://www.voip-info.org
• http://voip.internet2.edu
17 July 2016
59
Introduction to VOIP
Security
17 July 2016
60
VOIP Security
• As in Data, VOIP Security is very important
in today’s context
• People would expect similar level of
security as PSTN system
• Physical access to PSTN/compromising PBX
is required to breach security in PSTN
• But breaching the securiy in IP based call
is much easier.
• Hence the VOIP protocols define security
framework
17 July 2016
61
Security in H323
• Call Establishment (H.225) Security
– Secured mode of communication should be
used (e.g.IPSEC or TLS) before exchange of
call connection message
• Call Control (H.245) Security
– H245 channel is secured using negotiated
privacy mechanism
– Typically done during H225 signaling
• Media Stream Privacy
– Media stream encoded using algorithm and
keys as presented during H245 signaling
17 July 2016
62
Security in H323
• H.235 specifies security aspects of H323
• Various security profiles recommended by
H.235
17 July 2016
63
Annex D Baseline Security
• Uses symmetric cryptography technique
• Applicable where subscribed
passwords/symmetric keys can be
assigned to H323 entities.
• Passwords used for authentication
• Symmetric keys used for encryption
• Confidentiality of media stream provided
by symmetric encryption
17 July 2016
64
Annex D Baseline Profile
RAS
H225
H245
Authentication
Shared secret
(password)
HMAC-SHA1-96
Shared secret
(password)
HMAC-SHA1-96
Shared secret
(password)
HMAC-SHA1-96
Integrity
Shared secret
(password)
HMAC-SHA1-96
Shared secret
(password)
HMAC-SHA1-96
Shared secret
(password)
HMAC-SHA1-96
Key
Management
17 July 2016
Subscription
Subscription
based password based password
assignment
assignment
65
Annex D Baseline Profile
• Uses CryptoH323Token field to send encrypted
message
• HMAC-SHA1-96 algorithm is used on the entire
message which includes a sequence number
(monotonically increasing), timestamp
• The GK upon receiving the encrypted message
verifies the authenticator based on
– Liveness of the timestamp
– Matching of the authenticator in the message with that
computed by the GK
*HMAC – Hash Message Authentication Code
17 July 2016
66
Annex E Signature Profile
• Uses asymmetric crypto techniques
• Certificates and Digital signatures used to
provide authentication and integrity
17 July 2016
67
Annex E Signature Profile
RAS
H225
H245
Authentication
SHA1/MD5
SHA1/MD5
SHA1/MD5
Digital signature Digital signature Digital signature
Integrity
SHA1/MD5
SHA1/MD5
SHA1/MD5
Digital signature Digital signature Digital signature
Key
Management
17 July 2016
Certificate
allocation
Certificate
allocation
68
Secured RAS Example
H323 terminal
gatekeeper
Digital signature
= MD5-RSA(
monotinally increasing
seq num, timestamp,
sender id, receiver id,
and few other fields)
Gatekeeper
verifies
signature
RCF
17 July 2016
69
Annex D Voice Encryption
Profile
• Provides confidentiality of the actual voice
media stream being transmitted.
• Uses Diffie-Hellman Key exchange during
connection set up
• This key is used to protect media keys that
are used to encrypt media (RTP) packets.
• Encryption algorithm chosen are 56bit
DES, 56-RC2, 168 bit triple DES, AES
17 July 2016
70
Use of IPSec/TLS in H323
• Can be used to provide authentication and
confidentiality at the IP layer
• This is independent of protocol run in the
upper layer
• Only policies at the end points should be
configured to use IPSec/TLS.
• RAS, H225 and H245 signaling can be
done over IPSec/TLS.
17 July 2016
71
Security in SIP
• SIP specification (RFC 3261) specifies
security for SIP protocol.
• Distributed nature of the protocol makes it
very susceptible to security compromise
– Hence the need to provide framework for
secured SIP signaling and media
17 July 2016
72
Attacks and Threat Models
• Registration hijacking
– Attacker successfully impersonates a party who
can register and de-register
– De-registers all the contacts for a URI and
register himself as the contact
– Now the attackers gets all the SIP requests
• Impersonating server
– A compromised server can easily be used to
direct request or consume resources illegally
17 July 2016
73
Attacks and Threat Models
• Tampering with message bodies
– Malicious proxy can change the message bodies
• Can redirect RTP packets to a wiretapping device
• Can launch “man-in-the-middle” attack to
compromise the integrity of the message
• Tearing down sessions
– If an attacker gets holds of the essential
parameters of a session (To tag, From tag
etc.), then it could forge a BYE request to end
the session
17 July 2016
74
Attacks and Threat Models
• Denial of Service
– Attacker can create bogus request that contain
falsified source address and a corresponding
via header set to a target host
• If these requests are sent to a large number of SIP
elements, then the host would be inundated with DOS
traffic
– Attacker can de-register legitimate users from
a proxy which would prevent any new sessions
for the users
– Attacker can register lots of bogus users to
deplete memory and disk resources
17 July 2016
75
HTTP Authentication
• SIP uses Digest authentication of http
– Challenge-response paradigm
– Provides message authentication and replay protection,
but not message integrity or confidentiality
– Each authentication is meaningful for a particular domain
(or realm)
– Any time a proxy or UA receives a message, it may
challenge the initiator of the request to provide
assurance of its identity
– Basic method of http (user name passwd passed in clear
text) is not allowed in SIP
– UAS uses 401 (not authorized) and proxy uses 407
(proxy authentication required) to challenge the initiator
17 July 2016
76
HTTP Digest
UAC
UAS
INVITE
Does not have credential
www-authenticate: Digest
nonce :
o
o
INVITE
(contains Digest)
Checks the credential
100 trying
17 July 2016
77
HTTP Digest
• UAS should not challenge two requests
– ACK
• Does not have a response
• UAC sending ACK would copy all the credentials sent
in INVITE
– CANCEL
• Cannot be resubmitted
• Generally accepted by a server if it comes from the
same hop that sent the request being cancelled
– Requires transport or network layer security support
17 July 2016
78
S/MIME
• SIP message carries MIME bodies
• MIME standard includes mechanism for
securing MIME contents (integrity and
confidentiality)
• S/MIME certificate used to identify end
user
• This certificate also has key that is used to
encrypt the bodies of the message.
• Bodies signed with private key of the
sender and encrypted with public key of
the recipient.
17 July 2016
79
Use of Network and
Transport Layer Security
• Transport and network layer security encrypts SIP
signaling traffic ensuring message confidentiality
and integrity.
• Two popular options are TLS and IPSec
• IPSec does not require tight integration with SIP
– Used in architectures in which a set of hosts have trust
relationship
• TLS provides security at the transport layer
– Used on hop by hop basis : Each hop can extend TLS
session to the next hop to achieve end-to-end security
17 July 2016
80
SIPS URI Scheme
• sips: can be used instead of sip: as AOR of
a user
• When used, it signifies that each hop over
which the request is forwarded must be
secured with TLS (until the domain portion
of the request URI)
• Once it reaches the domain in question, it
is handled by the local security and routing
policy
17 July 2016
81
Firewall/NAT Issues
• Firewall provide a central location for deploying
security policies.
– Relieves end points of maintaining security policies.
• Takes a lot of burden out of the VoIP infrastructure
• NAT is a powerful technology that can be used to
hide internal network addresses and enable
several endpoints in the network to share the
same external address
– From security view point, makes internal IP addresses
less accessible
• Attack against the network need be focused only at NAT
• But these come at a Price
– Few issues crop up for VoIP in NAT/Firewall environment
17 July 2016
82
VoIP with NAT/Firewall
17 July 2016
Source: National Institute of
Standards and Technology
83
Firewall/NAT Issues
• Firewall issues
– RTP ports used by VOIP are dynamically
decided during signaling
• Hence firewalls cannot statically open the ports
– Opening all the RTP ports is not a wise thing
• NAT issues
– The IP address and port information is carried
in the payload
– Once H323/SIP messages traverse a NAT, the
IP address would not be valid (NAT translates
the IP address only in the IP header)
17 July 2016
84
Firewall/NAT Solutions
• Stateful Firewalls
– Can investigate application data in a packet
• Open the dynamic RTP ports (pinhole) by peeking into
the H.323/SIP signaling messages
• Proxy placed at the border between two
domains
– Proxy would terminate sessions with both the
hosts and relay signaling as well as RTP media
streams
17 July 2016
85
Firewall/NAT Solutions
• Application Level Gateways (ALG)
– Examines and modifies application payload contents to
allow traversal through NAT/Firewall
• Simple Traversal of UDP through NAT (STUN)
– A simple client server protocol
– STUN client (usually embedded in applications) sends
binding request
– STUN client sends response which carries public IP and
port mapping generated by NAT
– Application needs to listen at the IP addr and port from
which binding request was sent
• Packets from remote hosts destined to public IP and port
will be received by the application
17 July 2016
86
References
• International Telecommunications Union.
ITU-T Recommendation H.235
• J. Rosenberg et al., “SIP: Session Initiation
Protocol” – Request for Comments 3261
• National Institute of Standards and
Technology, “Security Considerations for
Voice over IP Systems”- Special publication
800-58.
17 July 2016
87
Slides available at
http://www.it.iitb.ac.in/~sahoo/voip_security.ppt
17 July 2016
88