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
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.
Johnston, et al. Best Current Practice [Page 1]
RFC 3665 SIP Basic Call Flow Examples December 2003
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
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
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.
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
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.
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
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
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
In this scenario, Alice completes a call to Bob using two proxies Proxy 1 and Proxy 2. The initial INVITE (F1) contains a pre-loaded Route header with the address of Proxy 1 (Proxy 1 is configured as a default outbound proxy for Alice). The request does not contain the Authorization credentials Proxy 1 requires, so a 407 Proxy Authorization response is sent containing the challenge information. A new INVITE (F4) is then sent containing the correct credentials and the call proceeds. The call terminates when Bob disconnects by initiating a BYE message.
Johnston, et al. Best Current Practice [Page 15]
RFC 3665 SIP Basic Call Flow Examples December 2003
Proxy 1 inserts a Record-Route header into the INVITE message to ensure that it is present in all subsequent message exchanges. Proxy 2 also inserts itself into the Record-Route header. The ACK (F15) and BYE (F18) both have a Route header.
Message Details
F1 INVITE Alice -> Proxy 1
INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 Max-Forwards: 70 Route: <sip:ss1.atlanta.example.com;lr> From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com> 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
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:ss2.biloxi.example.com;lr>, <sip:ss1.atlanta.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 21]
RFC 3665 SIP Basic Call Flow Examples December 2003
RFC 3665 SIP Basic Call Flow Examples December 2003
Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76 ;received=192.0.2.101 Max-Forwards: 68 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=314159 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 ACK Content-Length: 0
/* RTP streams are established between Alice and Bob */
/* Bob Hangs Up with Alice. */
/* Again, note that the CSeq is NOT 3. Alice and Bob maintain their own separate CSeq counts */
F18 BYE Bob -> Proxy 2
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 Route: <sip:ss2.biloxi.example.com;lr>, <sip:ss1.atlanta.example.com;lr> From: Bob <sip:bob@biloxi.example.com>;tag=314159 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 BYE Content-Length: 0
F19 BYE Proxy 2 -> Proxy 1
BYE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 Max-Forwards: 69 Route: <sip:ss1.atlanta.example.com;lr> From: Bob <sip:bob@biloxi.example.com>;tag=314159 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 23]
RFC 3665 SIP Basic Call Flow Examples December 2003
F20 BYE Proxy 1 -> Alice
BYE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 ;received=192.0.2.222 Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 Max-Forwards: 68 From: Bob <sip:bob@biloxi.example.com>;tag=314159 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 BYE Content-Length: 0
F21 200 OK Alice -> Proxy 1
SIP/2.0 200 OK Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 ;received=192.0.2.222 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=314159 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 BYE Content-Length: 0
F22 200 OK Proxy 1 -> Proxy 2
SIP/2.0 200 OK Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 ;received=192.0.2.222 Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.101 From: Bob <sip:bob@biloxi.example.com>;tag=314159 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 24]
RFC 3665 SIP Basic Call Flow Examples December 2003
F23 200 OK Proxy 2 -> 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=314159 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 25]
RFC 3665 SIP Basic Call Flow Examples December 2003
In this scenario, Alice completes a call to Bob using two proxies Proxy 1 and Proxy 2. Alice has valid credentials in both domains. Since the initial INVITE (F1) does not contain the Authorization credentials Proxy 1 requires, so a 407 Proxy Authorization response is sent containing the challenge information. A new INVITE (F4) is
Johnston, et al. Best Current Practice [Page 26]
RFC 3665 SIP Basic Call Flow Examples December 2003
then sent containing the correct credentials and the call proceeds after Proxy 2 challenges and receives valid credentials. The call terminates when Bob disconnects by initiating a BYE message.
Proxy 1 inserts a Record-Route header into the INVITE message to ensure that it is present in all subsequent message exchanges. Proxy 2 also inserts itself into the Record-Route header.
Message Details
F1 INVITE Alice -> Proxy 1
INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74b03 Max-Forwards: 70 Route: <sip:ss1.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 Content-Length: 151
RFC 3665 SIP Basic Call Flow Examples December 2003
In this scenario, Alice completes a call to Bob via a Proxy Server. Alice is configured for a primary SIP Proxy Server Proxy 1 and a secondary SIP Proxy Server Proxy 2 (Or is able to use DNS SRV records to locate Proxy 1 and Proxy 2). Alice has valid credentials for both domains. Proxy 1 is out of service and does not respond to INVITEs (it is reachable, but unresponsive). Alice then completes the call to Bob using Proxy 2.
Message Details
F1 INVITE Alice -> Proxy 1
INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK465b6d Max-Forwards: 70 Route: <sip:ss1.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 Content-Length: 151
F9 407 Proxy Authorization Required Proxy 2 -> Alice
SIP/2.0 407 Proxy Authorization Required Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74b8a ;received=192.0.2.101 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=2421452
Johnston, et al. Best Current Practice [Page 39]
RFC 3665 SIP Basic Call Flow Examples December 2003
ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74b8g Max-Forwards: 70 Route: <sip:ss2.biloxi.example.com;lr> From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=314159 Call-ID: 4Fde34wkd11wsGFDs3@atlanta.example.com CSeq: 2 ACK Content-Length: 0
F19 ACK Proxy 2 -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74b8g ;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: 4Fde34wkd11wsGFDs3@atlanta.example.com
Johnston, et al. Best Current Practice [Page 43]
RFC 3665 SIP Basic Call Flow Examples December 2003
CSeq: 2 ACK Content-Length: 0
/* RTP streams are established between Alice and Bob */
/* Bob Hangs Up with Alice. */
F20 BYE Bob -> Proxy 2
BYE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 Route: <sip:ss2.biloxi.example.com;lr> From: Bob <sip:bob@biloxi.example.com>;tag=314159 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 4Fde34wkd11wsGFDs3@atlanta.example.com CSeq: 1 BYE Content-Length: 0
F21 BYE Proxy 2 -> Alice
BYE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 Max-Forwards: 69 From: Bob <sip:bob@biloxi.example.com>;tag=314159 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 4Fde34wkd11wsGFDs3@atlanta.example.com CSeq: 1 BYE Content-Length: 0
F22 200 OK Alice -> Proxy 2
SIP/2.0 200 OK Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 ;received=192.0.2.222 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob <sip:bob@biloxi.example.com>;tag=314159 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 4Fde34wkd11wsGFDs3@atlanta.example.com CSeq: 1 BYE Content-Length: 0
Johnston, et al. Best Current Practice [Page 44]
RFC 3665 SIP Basic Call Flow Examples December 2003
F23 200 OK Proxy 2 -> Bob
SIP/2.0 200 OK Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob <sip:bob@biloxi.example.com>;tag=314159 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 4Fde34wkd11wsGFDs3@atlanta.example.com CSeq: 1 BYE Content-Length: 0
Johnston, et al. Best Current Practice [Page 45]
RFC 3665 SIP Basic Call Flow Examples December 2003
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
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 */
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
3.6. Session via Redirect and Proxy Servers with SDP in ACK
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
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
/* 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
In this scenario, Alice gives up on the call before Bob answers (sends a 200 OK response). Alice sends a CANCEL (F9) since no final response had been received from Bob. If a 200 OK to the INVITE had crossed with the CANCEL, Alice would have sent an ACK then a BYE to Bob in order to properly terminate the call.
Note that the CANCEL message is acknowledged with a 200 OK on a hop by hop basis, rather than end to end.
Johnston, et al. Best Current Practice [Page 67]
RFC 3665 SIP Basic Call Flow Examples December 2003
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:ss2.biloxi.example.com;lr>, <sip:ss1.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 CANCEL Alice -> Proxy 1
CANCEL 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> Route: <sip:ss1.atlanta.example.com;lr> Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0
F10 200 OK Proxy 1 -> 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> Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0
Johnston, et al. Best Current Practice [Page 71]
RFC 3665 SIP Basic Call Flow Examples December 2003
F11 CANCEL Proxy 1 -> Proxy 2
CANCEL sip:alice@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 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 CANCEL Content-Length: 0
F12 200 OK Proxy 2 -> Proxy 1
SIP/2.0 200 OK Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com> Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0
F13 CANCEL Proxy 2 -> Bob
CANCEL sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 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 CANCEL Content-Length: 0
F14 200 OK Bob -> Proxy 2
SIP/2.0 200 OK Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 ;received=192.0.2.222 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com> Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0
Johnston, et al. Best Current Practice [Page 72]
RFC 3665 SIP Basic Call Flow Examples December 2003
F15 487 Request Terminated Bob -> Proxy 2
SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 ;received=192.0.2.222 Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 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 Content-Length: 0
F16 ACK Proxy 2 -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 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
F17 487 Request Terminated Proxy 2 -> Proxy 1
SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 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 Content-Length: 0
Johnston, et al. Best Current Practice [Page 73]
RFC 3665 SIP Basic Call Flow Examples December 2003
F18 ACK Proxy 1 -> Proxy 2
ACK sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 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
F19 487 Request Terminated Proxy 1 -> Alice
SIP/2.0 487 Request Terminated 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
F20 ACK Alice -> Proxy 1
ACK 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>;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com Proxy-Authorization: Digest username="alice", realm="atlanta.example.com", nonce="ze7k1ee88df84f1cec431ae6cbe5a359", opaque="", uri="sip:bob@biloxi.example.com", response="b00b416324679d7e243f55708d44be7b" CSeq: 1 ACK Content-Length: 0
Johnston, et al. Best Current Practice [Page 74]
RFC 3665 SIP Basic Call Flow Examples December 2003
In this scenario, Bob is busy and sends a 486 Busy Here response to Alice's INVITE. Note that the non-2xx response is acknowledged on a hop-by-hop basis instead of end-to-end. Also note that many SIP UAs will not return a 486 response, as they have multiple line and other features.
In this example, there is no response from Bob to Alice's INVITE messages being re-transmitted by Proxy 2. After the sixth re-transmission, Proxy 2 gives up and sends a 480 No Response to Alice.
Message Details
F1 INVITE Alice -> Proxy 1
INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 Route: <sip:ss1.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="atlanta.example.com",
Johnston, et al. Best Current Practice [Page 80]
RFC 3665 SIP Basic Call Flow Examples December 2003
RFC 3665 SIP Basic Call Flow Examples December 2003
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
In this scenario, Bob initially sends a 180 Ringing response to Alice, indicating that alerting is taking place. However, then a 480 Unavailable is then sent to Alice. This response is acknowledged then proxied back to Alice.
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
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.