RFC 3665
Session Initiation Protocol (SIP) Basic Call Flow Examples
Network Working Group A. Johnston Request for Comments: 3665 MCI BCP: 75 S. Donovan Category: Best Current Practice R. Sparks C. Cunningham dynamicsoft K. Summers Sonus December 2003 Session Initiation Protocol (SIP) Basic Call Flow Examples Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.Abstract
This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. General Assumptions. . . . . . . . . . . . . . . . . . . 3 1.2. Legend for Message Flows . . . . . . . . . . . . . . . . 3 1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . 4 2. SIP Registration . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Successful New Registration. . . . . . . . . . . . . . . 5 2.2. Update of Contact List . . . . . . . . . . . . . . . . . 7 2.3. Request for Current Contact List . . . . . . . . . . . . 8 2.4. Cancellation of Registration . . . . . . . . . . . . . . 9 2.5. Unsuccessful Registration. . . . . . . . . . . . . . . . 10 3. SIP Session Establishment. . . . . . . . . . . . . . . . . . . 12 3.1. Successful Session Establishment . . . . . . . . . . . . 12 3.2. Session Establishment Through Two Proxies. . . . . . . . 15 3.3. Session with Multiple Proxy Authentication . . . . . . . 26 3.4. Successful Session with Proxy Failure. . . . . . . . . . 37 3.5. Session Through a SIP ALG. . . . . . . . . . . . . . . . 46 3.6. Session via Redirect and Proxy Servers with SDP in ACK . 54 3.7. Session with re-INVITE (IP Address Change) . . . . . . . 61 3.8. Unsuccessful No Answer . . . . . . . . . . . . . . . . . 67 3.9. Unsuccessful Busy. . . . . . . . . . . . . . . . . . . . 75 3.10. Unsuccessful No Response from User Agent . . . . . . . . 80 3.11. Unsuccessful Temporarily Unavailable . . . . . . . . . . 85 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 91 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.1. Normative References . . . . . . . . . . . . . . . . . . 91 5.2. Informative References . . . . . . . . . . . . . . . . . 91 6. Intellectual Property Statement. . . . . . . . . . . . . . . . 91 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 92 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 93 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 941. Overview
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.
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].1.1. General Assumptions
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.1.2. Legend for Message Flows
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. */
1.3. SIP Protocol Assumptions
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.1282. SIP Registration
Registration binds a particular device Contact URI with a SIP user Address of Record (AOR).
2.1. Successful New Registration
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
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
2.2. Update of Contact List
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
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: 02.3. Request for Current Contact List
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
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: 02.4. Cancellation of Registration
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
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
2.5. Unsuccessful Registration
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
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