The call flows shown in this document were developed in the design of
a SIP IP communications network. They represent an example minimum
set of functionality.
It is the hope of the authors that this document will be useful for
SIP implementers, designers, and protocol researchers alike and will
help further the goal of a standard implementation of RFC 3261 [1].
These flows represent carefully checked and working group reviewed
scenarios of the most basic examples as a companion to the
specifications.
Johnston, et al. Best Current Practice [Page 2]
RFC 3665 SIP Basic Call Flow Examples December 2003
These call flows are based on the current version 2.0 of SIP in RFC
3261 [1] with SDP usage described in RFC 3264 [2]. Other RFCs also
comprise the SIP standard but are not used in this set of basic call
flows.
Call flow examples of SIP interworking with the PSTN through gateways
are contained in a companion document, RFC 3666 [5].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [4].
A number of architecture, network, and protocol assumptions underlie
the call flows in this document. Note that these assumptions are not
requirements. They are outlined in this section so that they may be
taken into consideration and to aid in the understanding of the call
flow examples.
The authentication of SIP User Agents in these example call flows is
performed using HTTP Digest as defined in [1] and [3].
Some Proxy Servers in these call flows insert Record-Route headers
into requests to ensure that they are in the signaling path for
future message exchanges.
These flows show TCP, TLS, and UDP for transport. See the discussion
in RFC 3261 for details on the transport issues for SIP.
Dashed lines (---) represent signaling messages that are mandatory to
the call scenario. These messages can be SIP or PSTN signaling. The
arrow indicates the direction of message flow.
Double dashed lines (===) represent media paths between network
elements.
Messages with parentheses around their name represent optional
messages.
Messages are identified in the Figures as F1, F2, etc. This
references the message details in the list that follows the Figure.
Comments in the message details are shown in the following form:
/* Comments. */
Johnston, et al. Best Current Practice [Page 3]
RFC 3665 SIP Basic Call Flow Examples December 2003
This document does not prescribe the flows precisely as they are
shown, but rather the flows illustrate the principles for best
practice. They are best practices usages (orderings, syntax,
selection of features for the purpose, handling of error) of SIP
methods, headers and parameters. IMPORTANT: The exact flows here
must not be copied as is by an implementer due to specific incorrect
characteristics that were introduced into the document for
convenience and are listed below. To sum up, the basic flows
represent well-reviewed examples of SIP usage, which are best common
practice according to IETF consensus.
For simplicity in reading and editing the document, there are a
number of differences between some of the examples and actual SIP
messages. For example, the HTTP Digest responses are not actual MD5
encodings. Call-IDs are often repeated, and CSeq counts often begin
at 1. Header fields are usually shown in the same order. Usually
only the minimum required header field set is shown, others that
would normally be present such as Accept, Supported, Allow, etc are
not shown.
Actors:
Element Display Name URI IP Address
------- ------------ --- ----------
User Agent Alice alice@atlanta.example.com 192.0.2.101
User Agent Bob bob@biloxi.example.com 192.0.2.201
User Agent bob@chicago.example.com 192.0.2.100
Proxy Server ss1.atlanta.example.com 192.0.2.111
Proxy/Registrar ss2.biloxi.example.com 192.0.2.222
Proxy Server ss3.chicago.example.com 192.0.2.233
ALG alg1.atlanta.example.com 192.0.2.128
Registration binds a particular device Contact URI with a SIP user
Address of Record (AOR).
Johnston, et al. Best Current Practice [Page 4]
RFC 3665 SIP Basic Call Flow Examples December 2003
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| 401 Unauthorized F2 |
|<------------------------------|
| REGISTER F3 |
|------------------------------>|
| 200 OK F4 |
|<------------------------------|
| |
Bob sends a SIP REGISTER request to the SIP server. The request
includes the user's contact list. This flow shows the use of HTTP
Digest for authentication using TLS transport. TLS transport is used
due to the lack of integrity protection in HTTP Digest and the danger
of registration hijacking without it, as described in RFC 3261 [1].
The SIP server provides a challenge to Bob. Bob enters her/his valid
user ID and password. Bob's SIP client encrypts the user information
according to the challenge issued by the SIP server and sends the
response to the SIP server. The SIP server validates the user's
credentials. It registers the user in its contact database and
returns a response (200 OK) to Bob's SIP client. The response
includes the user's current contact list in Contact headers. The
format of the authentication shown is HTTP digest. It is assumed
that Bob has not previously registered with this Server.
Message Details
F1 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0
Johnston, et al. Best Current Practice [Page 5]
RFC 3665 SIP Basic Call Flow Examples December 2003
F2 401 Unauthorized SIP Server -> Bob
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>;tag=1410948204
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth",
nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
opaque="", stale=FALSE, algorithm=MD5
Content-Length: 0
F3 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Authorization: Digest username="bob", realm="atlanta.example.com"
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
uri="sips:ss2.biloxi.example.com",
response="dfe56131d1958046689d83306477ecc"
Content-Length: 0
F4 200 OK SIP Server -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Content-Length: 0
Johnston, et al. Best Current Practice [Page 6]
RFC 3665 SIP Basic Call Flow Examples December 2003
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| 200 OK F2 |
|<------------------------------|
| |
Bob wishes to update the list of addresses where the SIP server will
redirect or forward INVITE requests.
Bob sends a SIP REGISTER request to the SIP server. Bob's request
includes an updated contact list. Since the user already has
authenticated with the server, the user supplies authentication
credentials with the request and is not challenged by the server. The
SIP server validates the user's credentials. It registers the user
in its contact database, updates the user's contact list, and returns
a response (200 OK) to Bob's SIP client. The response includes the
user's current contact list in Contact headers.
Message Details
F1 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: mailto:bob@biloxi.example.com
Authorization: Digest username="bob", realm="atlanta.example.com",
qop="auth", nonce="1cec4341ae6cbe5a359ea9c8e88df84f", opaque="",
uri="sips:ss2.biloxi.example.com",
response="71ba27c64bd01de719686aa4590d5824"
Content-Length: 0
F2 200 OK SIP Server -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>;tag=34095828jh
Johnston, et al. Best Current Practice [Page 7]
RFC 3665 SIP Basic Call Flow Examples December 2003
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Contact: <mailto:bob@biloxi.example.com>;expires=4294967295
Content-Length: 0
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| 200 OK F2 |
|<------------------------------|
| |
Bob sends a register request to the Proxy Server containing no
Contact headers, indicating the user wishes to query the server for
the user's current contact list. Since the user already has
authenticated with the server, the user supplies authentication
credentials with the request and is not challenged by the server.
The SIP server validates the user's credentials. The server returns
a response (200 OK) which includes the user's current registration
list in Contact headers.
Message Details
F1 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Authorization: Digest username="bob", realm="atlanta.example.com",
nonce="df84f1cec4341ae6cbe5ap359a9c8e88", opaque="",
uri="sips:ss2.biloxi.example.com",
response="aa7ab4678258377c6f7d4be6087e2f60"
Content-Length: 0
F2 200 OK SIP Server -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
;received=192.0.2.201
Johnston, et al. Best Current Practice [Page 8]
RFC 3665 SIP Basic Call Flow Examples December 2003
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>;tag=jqoiweu75
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Contact: <mailto:bob@biloxi.example.com>;expires=4294967295
Content-Length: 0
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| 200 OK F2 |
|<------------------------------|
| |
Bob wishes to cancel their registration with the SIP server. Bob
sends a SIP REGISTER request to the SIP server. The request has an
expiration period of 0 and applies to all existing contact locations.
Since the user already has authenticated with the server, the user
supplies authentication credentials with the request and is not
challenged by the server. The SIP server validates the user's
credentials. It clears the user's contact list, and returns a
response (200 OK) to Bob's SIP client.
Message Details
F1 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Expires: 0
Contact: *
Authorization: Digest username="bob", realm="atlanta.example.com",
nonce="88df84f1cac4341aea9c8ee6cbe5a359", opaque="",
uri="sips:ss2.biloxi.example.com",
response="ff0437c51696f9a76244f0cf1dbabbea"
Content-Length: 0
F2 200 OK SIP Server -> Bob
Johnston, et al. Best Current Practice [Page 9]
RFC 3665 SIP Basic Call Flow Examples December 2003
SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>;tag=1418nmdsrf
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Content-Length: 0
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| 401 Unauthorized F2 |
|<------------------------------|
| REGISTER F3 |
|------------------------------>|
| 401 Unauthorized F4 |
|<------------------------------|
| |
Bob sends a SIP REGISTER request to the SIP Server. The SIP server
provides a challenge to Bob. Bob enters her/his user ID and
password. Bob's SIP client encrypts the user information according
to the challenge issued by the SIP server and sends the response to
the SIP server. The SIP server attempts to validate the user's
credentials, but they are not valid (the user's password does not
match the password established for the user's account). The server
returns a response (401 Unauthorized) to Bob's SIP client.
Message Details
F1 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0
Johnston, et al. Best Current Practice [Page 10]
RFC 3665 SIP Basic Call Flow Examples December 2003
F2 Unauthorized SIP Server -> Bob
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>;tag=1410948204
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth",
nonce="f1cec4341ae6ca9c8e88df84be55a359",
opaque="", stale=FALSE, algorithm=MD5
Content-Length: 0
F3 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=JueHGuidj28dfga
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Authorization: Digest username="bob", realm="atlanta.example.com",
nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="",
uri="sips:ss2.biloxi.example.com",
response="61f8470ceb87d7ebf508220214ed438b"
Content-Length: 0
/* The response above encodes the incorrect password */
F4 401 Unauthorized SIP Server -> Bob
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=JueHGuidj28dfga
To: Bob <sips:bob@biloxi.example.com>;tag=1410948204
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth",
nonce="84f1c1ae6cbe5ua9c8e88dfa3ecm3459",
opaque="", stale=FALSE, algorithm=MD5
Content-Length: 0
Johnston, et al. Best Current Practice [Page 11]
RFC 3665 SIP Basic Call Flow Examples December 2003
This section details session establishment between two SIP User
Agents (UAs): Alice and Bob. Alice (sip:alice@atlanta.example.com)
and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or
SIP-enabled devices. The successful calls show the initial
signaling, the exchange of media information in the form of SDP
payloads, the establishment of the media session, then finally the
termination of the call.
HTTP Digest authentication is used by Proxy Servers to authenticate
the caller Alice. It is assumed that Bob has registered with Proxy
Server Proxy 2 as per Section 2 to be able to receive the calls via
the Proxy.
Alice Bob
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
| 200 OK F3 |
|<-----------------------|
| ACK F4 |
|----------------------->|
| Both Way RTP Media |
|<======================>|
| |
| BYE F5 |
|<-----------------------|
| 200 OK F6 |
|----------------------->|
| |
In this scenario, Alice completes a call to Bob directly.
Message Details
F1 INVITE Alice -> Bob
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Johnston, et al. Best Current Practice [Page 12]
RFC 3665 SIP Basic Call Flow Examples December 2003
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 180 Ringing Bob -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
Content-Length: 0
F3 200 OK Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Johnston, et al. Best Current Practice [Page 13]
RFC 3665 SIP Basic Call Flow Examples December 2003
F4 ACK Alice -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
/* RTP streams are established between Alice and Bob */
/* Bob Hangs Up with Alice. Note that the CSeq is NOT 2, since
Alice and Bob maintain their own independent CSeq counts.
(The INVITE was request 1 generated by Alice, and the BYE is
request 1 generated by Bob) */
F5 BYE Bob -> Alice
BYE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 BYE
Content-Length: 0
F6 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.201
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 BYE
Content-Length: 0
Johnston, et al. Best Current Practice [Page 14]
RFC 3665 SIP Basic Call Flow Examples December 2003
Alice ALG Proxy 2 Bob
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 F3 |--------------->| INVITE F4 |
|<---------------| 100 F5 |--------------->|
| |<---------------| 180 F6 |
| | 180 F7 |<---------------|
| 180 F8 |<---------------| |
|<---------------| | 200 F9 |
| | 200 F10 |<---------------|
| 200 F11 |<---------------| |
|<---------------| |
| ACK F12 | |
|--------------->| ACK F13 |
| |-------------------------------->|
| RTP Media | Both Way RTP Media |
|<==============>|<===============================>|
| BYE F14 | |
|--------------->| BYE F15 |
| |-------------------------------->|
| | 200 F16 |
| 200 F17 |<--------------------------------|
|<---------------| |
| | |
Alice completes a call to Bob through a ALG (Application Layer
Gateway) and a SIP Proxy. The routing through the ALG is
accomplished using a pre-loaded Route header in the INVITE F1. Note
that the media stream setup is not end-to-end - the ALG terminates
both media streams and bridges them. This is done by the ALG
modifying the SDP in the INVITE (F1) and 200 OK (F10) messages, and
possibly any 18x or ACK messages containing SDP.
In addition to firewall traversal, this Back-to-Back User Agent
(B2BUA) could be used as part of an anonymizer service (in which all
identifying information on Alice would be removed), or to perform
codec media conversion, such as mu-law to A-law conversion of PCM on
an international call.
Also note that Proxy 2 does not Record-Route in this call flow.
Johnston, et al. Best Current Practice [Page 46]
RFC 3665 SIP Basic Call Flow Examples December 2003
Message Details
F1 INVITE Alice -> SIP ALG
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Route: <sip:alg1.atlanta.example.com;lr>
Proxy-Authorization: Digest username="alice",
realm="biloxi.example.com",
nonce="85b4f1cen4341ae6cbe5a3a9c8e88df9", opaque="",
uri="sip:bob@biloxi.example.com",
response="b3f392f9218a328b9294076d708e6815"
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* Client for Alice prepares to receive data on port 49172 from the
network. */
F2 INVITE SIP ALG -> Proxy 2
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Proxy-Authorization: Digest username="alice",
realm="biloxi.example.com",
Johnston, et al. Best Current Practice [Page 47]
RFC 3665 SIP Basic Call Flow Examples December 2003
nonce="85b4f1cen4341ae6cbe5a3a9c8e88df9", opaque="",
uri="sip:bob@biloxi.example.com",
response="b3f392f9218a328b9294076d708e6815"
Content-Type: application/sdp
Content-Length: 150
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.128
t=0 0
m=audio 2000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F3 100 Trying SIP ALG -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* SIP ALG prepares to proxy data from port 192.0.2.128/2000 to
192.0.2.101/49172. Proxy 2 uses a Location Service function to
determine where Bob is located. Based upon location analysis the call
is forwarded to Bob */
F4 INVITE Proxy 2 -> Bob
INVITE sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
;received=192.0.2.128
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 68
Record-Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Content-Type: application/sdp
Johnston, et al. Best Current Practice [Page 48]
RFC 3665 SIP Basic Call Flow Examples December 2003
Content-Length: 150
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.128
t=0 0
m=audio 2000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F5 100 Trying Proxy 2 -> SIP ALG
SIP/2.0 100 Trying
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
;received=192.0.2.128
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
F6 180 Ringing Bob -> Proxy 2
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.222
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
;received=192.0.2.128
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Length: 0
F7 180 Ringing Proxy 2 -> SIP ALG
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
;received=192.0.2.128
Johnston, et al. Best Current Practice [Page 49]
RFC 3665 SIP Basic Call Flow Examples December 2003
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Length: 0
F8 180 Ringing SIP ALG -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Length: 0
F9 200 OK Bob -> Proxy 2
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.222
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
;received=192.0.2.128
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
Johnston, et al. Best Current Practice [Page 50]
RFC 3665 SIP Basic Call Flow Examples December 2003
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F10 200 OK Proxy 2 -> SIP ALG
SIP/2.0 200 OK
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
;received=192.0.2.128
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F11 200 OK SIP ALG -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.128
t=0 0
Johnston, et al. Best Current Practice [Page 51]
RFC 3665 SIP Basic Call Flow Examples December 2003
m=audio 1734 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* The ALG prepares to proxy packets from 192.0.2.128/
1734 to 192.0.2.201/3456 */
F12 ACK Alice -> SIP ALG
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bhh
Max-Forwards: 70
Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
F13 ACK SIP ALG -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bhh
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
/* RTP streams are established between Alice and the ALG and
between the ALG and B*/
/* Alice Hangs Up with Bob. */
F14 BYE Alice -> SIP ALG
BYE sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5
Max-Forwards: 70
Route: <sip:alg1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
Johnston, et al. Best Current Practice [Page 52]
RFC 3665 SIP Basic Call Flow Examples December 2003
CSeq: 2 BYE
Content-Length: 0
F15 BYE SIP ALG -> Bob
BYE sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
F16 200 OK Bob -> SIP ALG
SIP/2.0 200 OK
Via: SIP/2.0/UDP alg1.atlanta.example.com:5060;branch=z9hG4bK739578.1
;received=192.0.2.128
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
F17 200 OK SIP ALG -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
Johnston, et al. Best Current Practice [Page 53]
RFC 3665 SIP Basic Call Flow Examples December 2003
Alice Redirect Server Proxy 3 Bob
| | | |
| INVITE F1 | | |
|--------------->| | |
| 302 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE F4 | |
|-------------------------------->| INVITE F5 |
| 100 F6 |--------------->|
|<--------------------------------| 180 F7 |
| 180 F8 |<---------------|
|<--------------------------------| |
| | 200 F9 |
| 200 F10 |<---------------|
|<--------------------------------| |
| ACK F11 | |
|-------------------------------->| ACK F12 |
| |--------------->|
| Both Way RTP Media |
|<================================================>|
| | BYE F13 |
| BYE F14 |<---------------|
|<--------------------------------| |
| 200 F15 | |
|-------------------------------->| 200 F16 |
| |--------------->|
| | |
In this scenario, Alice places a call to Bob using first a Redirect
server then a Proxy Server. The INVITE message is first sent to the
Redirect Server. The Server returns a 302 Moved Temporarily response
(F2) containing a Contact header with Bob's current SIP address.
Alice then generates a new INVITE and sends to Bob via the Proxy
Server and the call proceeds normally. In this example, no SDP is
present in the INVITE, so the SDP is carried in the ACK message.
The call is terminated when Bob sends a BYE message.
Johnston, et al. Best Current Practice [Page 54]
RFC 3665 SIP Basic Call Flow Examples December 2003
Message Details
F1 INVITE Alice -> Redirect Server
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Content-Length: 0
F2 302 Moved Temporarily Redirect Proxy -> Alice
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@chicago.example.com;transport=tcp>
Content-Length: 0
F3 ACK Alice -> Redirect Server
ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
F4 INVITE Alice -> Proxy 3
INVITE sip:bob@chicago.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
Johnston, et al. Best Current Practice [Page 55]
RFC 3665 SIP Basic Call Flow Examples December 2003
CSeq: 2 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Length: 0
F5 INVITE Proxy 3 -> Bob
INVITE sip:bob@client.chicago.example.com SIP/2.0
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Length: 0
F6 100 Trying Proxy 3 -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 0
F7 180 Ringing Bob -> Proxy 3
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
;received=192.0.2.233
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:bob@client.chicago.example.com;transport=tcp>
Content-Length: 0
Johnston, et al. Best Current Practice [Page 56]
RFC 3665 SIP Basic Call Flow Examples December 2003
F8 180 Ringing Proxy 3 -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:bob@client.chicago.example.com;transport=tcp>
Content-Length: 0
F9 200 OK Bob -> Proxy 3
SIP/2.0 200 OK
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
;received=192.0.2.233
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:bob@client.chicago.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 148
v=0
o=bob 2890844527 2890844527 IN IP4 client.chicago.example.com
s=-
c=IN IP4 192.0.2.100
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F10 200 OK Proxy -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Johnston, et al. Best Current Practice [Page 57]
RFC 3665 SIP Basic Call Flow Examples December 2003
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:bob@client.chicago.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 148
v=0
o=bob 2890844527 2890844527 IN IP4 client.chicago.example.com
s=-
c=IN IP4 192.0.2.100
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* ACK contains SDP of Alice since none present in INVITE */
F11 ACK Alice -> Proxy 3
ACK sip:bob@client.chicago.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bq9
Max-Forwards: 70
Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 ACK
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F12 ACK Proxy 3 -> Bob
ACK sip:bob@client.chicago.example.com SIP/2.0
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bq9
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Johnston, et al. Best Current Practice [Page 58]
RFC 3665 SIP Basic Call Flow Examples December 2003
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 ACK
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* RTP streams are established between Alice and Bob */
/* Bob Hangs Up with Alice. */
F13 BYE Bob -> Proxy 3
BYE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com:5060;branch=z9hG4bKfgaw2
Max-Forwards: 70
Route: <sip:ss3.chicago.example.com;lr>
From: Bob <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 BYE
Content-Length: 0
F14 BYE Proxy 3 -> Alice
BYE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
;received=192.0.2.100
Via: SIP/2.0/TCP client.chicago.example.com:5060;branch=z9hG4bKfgaw2
Max-Forwards: 69
From: Bob <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 BYE
Content-Length: 0
F15 200 OK Alice -> Proxy 3
SIP/2.0 200 OK
Johnston, et al. Best Current Practice [Page 59]
RFC 3665 SIP Basic Call Flow Examples December 2003
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
;received=192.0.2.233
Via: SIP/2.0/TCP client.chicago.example.com:5060;branch=z9hG4bKfgaw2
;received=192.0.2.100
From: Bob <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 BYE
Content-Length: 0
F16 200 OK Proxy 3 -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.chicago.example.com:5060;branch=z9hG4bKfgaw2
;received=192.0.2.100
From: Bob <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 BYE
Content-Length: 0
Johnston, et al. Best Current Practice [Page 60]
RFC 3665 SIP Basic Call Flow Examples December 2003
Alice Proxy 2 Bob
| F1 INVITE | |
|------------------->| F2 INVITE |
| F3 100 Trying |------------------->|
|<-------------------| F4 180 Ringing |
| F5 180 Ringing |<-------------------|
|<-------------------| |
| | F6 200 OK |
| F7 200 OK |<-------------------|
|<-------------------| |
| F8 ACK |
|---------------------------------------->|
| Both Way RTP Media Established |
|<=======================================>|
| |
| Bob changes IP address |
| |
| F9 INVITE |
|<----------------------------------------|
| F10 200 OK |
|---------------------------------------->|
| F11 ACK |
|<----------------------------------------|
| New RTP Media Stream |
|<=======================================>|
| F12 BYE |
|---------------------------------------->|
| F13 200 OK |
|<----------------------------------------|
| |
This example shows a session in which the media changes midway
through the session. When Bob's IP address changes during the
session, Bob sends a re-INVITE containing a new Contact and SDP
(version number incremented) information to A. In this flow, the
proxy does not Record-Route so is not in the SIP messaging path after
the initial exchange.
Johnston, et al. Best Current Practice [Page 61]
RFC 3665 SIP Basic Call Flow Examples December 2003
Message Details
F1 INVITE Alice -> Proxy 2
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 INVITE Proxy 2 -> Bob
INVITE sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Johnston, et al. Best Current Practice [Page 62]
RFC 3665 SIP Basic Call Flow Examples December 2003
F3 100 Trying Proxy 2 -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
F4 180 Ringing Bob -> Proxy 2
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.222
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Length: 0
F5 180 Ringing Proxy 2 -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Length: 0
F6 200 OK Bob -> Proxy 2
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.222
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Johnston, et al. Best Current Practice [Page 63]
RFC 3665 SIP Basic Call Flow Examples December 2003
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F7 200 OK Proxy 2 -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F8 ACK Alice -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74b7b
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
Johnston, et al. Best Current Practice [Page 64]
RFC 3665 SIP Basic Call Flow Examples December 2003
/* RTP streams are established between Alice and Bob */
/* Bob changes IP address and re-INVITEs Alice with new Contact and
SDP */
F9 INVITE Bob -> Alice
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com:5060;branch=z9hG4bKlkld5l
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 14 INVITE
Contact: <sip:bob@client.chicago.example.com>
Content-Type: application/sdp
Content-Length: 149
v=0
o=bob 2890844527 2890844528 IN IP4 client.chicago.example.com
s=-
c=IN IP4 192.0.2.100
t=0 0
m=audio 47172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F10 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.chicago.example.com:5060;branch=z9hG4bKlkld5l
;received=192.0.2.100
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 14 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 150
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
Johnston, et al. Best Current Practice [Page 65]
RFC 3665 SIP Basic Call Flow Examples December 2003
m=audio 1000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F11 ACK Bob -> Alice
ACK sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com:5060;branch=z9hG4bKlkldcc
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 14 ACK
Content-Length: 0
/* New RTP stream established between Alice and Bob */
/* Alice hangs up with Bob */
F12 BYE Alice -> Bob
BYE sip:bob@client.chicago.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bo4
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
F13 200 OK Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bo4
;received=192.0.2.101
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
Johnston, et al. Best Current Practice [Page 66]
RFC 3665 SIP Basic Call Flow Examples December 2003
Since this document contains examples of SIP session establishment,
the security considerations in RFC 3261 [1] apply. RFC 3261
describes the basic threats including registration hijacking, server
impersonation, message body tampering, session modifying or teardown,
and denial of service and amplification attacks. The use of HTTP
Digest as shown in this document provides one-way authentication and
protection against replay attacks. TLS transport is used in
registration scenarios due to the lack of integrity protection in
HTTP Digest and the danger of registration hijacking without it, as
described in RFC 3261 [1]. A full discussion of the weaknesses of
HTTP Digest is provided in RFC 3261 [1]. The use of TLS and the
Secure SIP (sips) URI scheme provides a better level of security
including two-way authentication. S/MIME can provide end-to-end
confidentiality and integrity protection of message bodies, as
described in RFC 3261.
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
SDP", RFC 3264, April 2002.
[3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach,
P., Luotonen, A. and L. Stewart, "HTTP authentication: Basic and
Digest Access Authentication", RFC 2617, June 1999.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K.
Summers, "Session Initiation Protocol (SIP) Public Switched
Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December
2003.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
Johnston, et al. Best Current Practice [Page 91]
RFC 3665 SIP Basic Call Flow Examples December 2003
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
This document is has been a group effort by the SIP and SIPPING WGs.
The authors wish to thank everyone who has read, reviewed, commented,
or made suggestions to improve this document.
Thanks to Rohan Mahy, Adam Roach, Gonzalo Camarillo, Cullen Jennings,
and Tom Taylor for their detailed comments during the final review.
Thanks to Dean Willis for his early contributions to the development
of this document.
The authors wish to thank Kundan Singh for performing parser
validation of messages.
The authors wish to thank the following individuals for their
participation in the review of this call flows document: Aseem
Agarwal, Rafi Assadi, Ben Campbell, Sunitha Kumar, Jon Peterson, Marc
Petit-Huguenin, Vidhi Rastogi, and Bodgey Yin Shaohua.
The authors also wish to thank the following individuals for their
assistance: Jean-Francois Mule, Hemant Agrawal, Henry Sinnreich,
David Devanatham, Joe Pizzimenti, Matt Cannon, John Hearty, the whole
MCI WorldCom IPOP Design team, Scott Orton, Greg Osterhout, Pat
Sollee, Doug Weisenberg, Danny Mistry, Steve McKinnon, and Denise
Ingram, Denise Caballero, Tom Redman, Ilya Slain, Pat Sollee, John
Truetken, and others from MCI WorldCom, 3Com, Cisco, Lucent and
Nortel.
Johnston, et al. Best Current Practice [Page 92]
RFC 3665 SIP Basic Call Flow Examples December 2003
All listed authors actively contributed large amounts of text to this
document.
Alan Johnston
MCI
100 South 4th Street
St. Louis, MO 63102
USA
EMail: alan.johnston@mci.com
Steve Donovan
dynamicsoft, Inc.
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
USA
EMail: sdonovan@dynamicsoft.com
Robert Sparks
dynamicsoft, Inc.
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
USA
EMail: rsparks@dynamicsoft.com
Chris Cunningham
dynamicsoft, Inc.
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
USA
EMail: ccunningham@dynamicsoft.com
Kevin Summers
Sonus
1701 North Collins Blvd, Suite 3000
Richardson, TX 75080
USA
EMail: kevin.summers@sonusnet.com
Johnston, et al. Best Current Practice [Page 93]
RFC 3665 SIP Basic Call Flow Examples December 2003
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Johnston, et al. Best Current Practice [Page 94]