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.
`
`Johnston, et al. Best Current Practice [Page 1]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`Page 1
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`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 . . . . . . . . . . . . . . . . . . . 94
`
`1. 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.
`
`Johnston, et al. Best Current Practice [Page 2]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`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].
`
`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. */
`
`Johnston, et al. Best Current Practice [Page 3]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`Page 3
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`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.128
`
`2. SIP Registration
`
` Registration binds a particular device Contact URI with a SIP user
` Address of Record (AOR).
`
`Johnston, et al. Best Current Practice [Page 4]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`Page 4
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`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
`
`Johnston, et al. Best Current Practice [Page 5]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`Page 6
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`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
`
`Johnston, et al. Best Current Practice [Page 7]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`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
`
`2.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
`
`Johnston, et al. Best Current Practice [Page 8]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`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
`
`2.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
`
`Johnston, et al. Best Current Practice [Page 9]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`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
`
`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
`
`Johnston, et al. Best Current Practice [Page 10]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`Page 11
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`3. SIP Session Establishment
`
` 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.
`
`3.1. Successful Session Establishment
`
` 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]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`Page 14
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`3.2. Session Establishment Through Two Proxies
`
` Alice Proxy 1 Proxy 2 Bob
` | | | |
` | INVITE F1 | | |
` |--------------->| | |
` | 407 F2 | | |
` |<---------------| | |
` | ACK F3 | | |
` |--------------->| | |
` | INVITE F4 | | |
` |--------------->| INVITE F5 | |
` | 100 F6 |--------------->| INVITE F7 |
` |<---------------| 100 F8 |--------------->|
` | |<---------------| |
` | | | 180 F9 |
` | | 180 F10 |<---------------|
` | 180 F11 |<---------------| |
` |<---------------| | 200 F12 |
` | | 200 F13 |<---------------|
` | 200 F14 |<---------------| |
` |<---------------| | |
` | ACK F15 | | |
` |--------------->| ACK F16 | |
` | |--------------->| ACK F17 |
` | | |--------------->|
` | Both Way RTP Media |
` |<================================================>|
` | | | BYE F18 |
` | | BYE F19 |<---------------|
` | BYE F20 |<---------------| |
` |<---------------| | |
` | 200 F21 | | |
` |--------------->| 200 F22 | |
` | |--------------->| 200 F23 |
` | | |--------------->|
` | | | |
`
` 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]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`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
`
` 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
`
` /* Proxy 1 challenges Alice for authentication */
`
` F2 407 Proxy Authorization Required Proxy 1 -> Alice
`
` SIP/2.0 407 Proxy Authorization Required
` Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
` ;received=192.0.2.101
` From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
` To: Bob <sip:bob@biloxi.example.com>;tag=3flal12sf
` Call-ID: 3848276298220188511@atlanta.example.com
` CSeq: 1 INVITE
` Proxy-Authenticate: Digest realm="atlanta.example.com", qop="auth",
` nonce="f84f1cec41e6cbe5aea9c8e88d359",
` opaque="", stale=FALSE, algorithm=MD5
` Content-Length: 0
`
`Johnston, et al. Best Current Practice [Page 16]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01384
`Page 16
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` F3 ACK Alice -> Proxy 1
`
` ACK sip:bob@biloxi.example.com SIP/2.0
` Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
` Max-Forwards: 70
` From: Alice <sip:alice@atl