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
LAN
LAN
SIP proxy
PSTN Gateway
PSTN
IP phone
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
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, SCTP, 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:wh@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159
• 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:wh@200.201.202.203
• Note: Request-URI can be either an AOR or Contact (FQDN)
• This Request-URI is a FQDN, but the initial Request-URI was an AOR
(same as To URI)
– the SIP version number SIP/2.0
17 July 2016
31
SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159
• Via headers show the path the request has taken
– The bottom Via header is inserted by the User Agent which initiated
the request
– Additional Via headers are inserted by each proxy in the path
• The Via headers are used to route responses back the same way
• Required branch parameter contains a “cookie” (z9hG4bK) then a
transaction-ID.
17 July 2016
32
SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159
• 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:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159
• 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:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159
• CSeq Command Sequence Number
– Initialized at start of call (1 in this example)
– Incremented for each subsequent request
– 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:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159
• 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:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159
• 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 (CRLF).
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 proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
To: Heisenberg <sip:w.heisenberg@munich.de>;tag=24019385
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:wh@200.201.202.203
Content-Type: application/sdp
Content-Length: 173
v=0
o=Heisenberg 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





Call Attempt - Unsuccessful
Presence Subscription
Registration
Presence Notification
Call Setup – Successful
Call Flows and full message details:
“SIP Basic Call Flow Examples” I-D by A. Johnston et al.
 “SIP Service Examples” I-D by A. Johnston et al.

17 July 2016
40
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)
41
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)
42
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)
43
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)
44
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)
45
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)
46
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)
47
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)
48
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)
49
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
50
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
51
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
52
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
53
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
54
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
55
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
56
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
57